Hi Ilyes, >Is your h/w blitter able to cope with the virtual addresses >(as seen within the user-space process) of the DirectFB surfaces?
Yes, that is correct. Any graphics driver that reports support for system memory surfaces would need to have a way to deal with the non-physically contiguous (virtual) memory associated with them (such as via their own MMU that's setup by the driver). Cheers, Timothy >-----Original Message----- >From: Ilyes Gouta [mailto:ilyes.go...@gmail.com] >Sent: Tuesday, June 21, 2011 3:20 PM >To: Strelchun, Timothy >Cc: directfb-dev@directfb.org >Subject: Re: [directfb-dev] [PATCH] GPU system memory support >mods for aligned buffer directfbrc commands (was RE: [PATCH] 3 >patch set...) > >Hi Timothy, > >Is your h/w blitter able to cope with the virtual addresses >(as seen within the user-space process) of the DirectFB surfaces? > >-Ilyes > >On Tue, May 31, 2011 at 6:35 AM, Strelchun, Timothy ><timothy.strelc...@intel.com> wrote: >> I just realized there was another helpful set of changes (creating >> aligned buffers!) for the previous set related to enabling a >graphics >> driver to handle system memory buffer allocations. >> >> Here are the details from patch: >> >> ----------------------- >> Subject: [PATCH] GPU system memory support mods for aligned >buffer directfbrc commands. >> Added the directfbrc commands system-surface-base-alignment and >> system-surface-pitch-alignment. If the graphics driver supports >> system memory, these commands >> are used to sets the byte alignment for the system memory based >> surface's base address and >> pitch, or zero for no alignment (which is the default). Aligning >> these allows pixel data to >> travel more efficiently through the CPU and across the >memory bus to >> increase performance, >> and meet GPU requirements (if any). >> >> Updated the system memory surface pools to use these values for >> creating surface buffers when they are non-zero. The local surface >> pool will use the posix_memalign function and the shared >surface pool will bloat the size to allow for base address to >be aligned. >> >> ----------------------- >> >> Note: I set the minimum base address and pitch alignment >size to very >> small values since different graphics drivers will have different >> requirements (some may be larger than others). >> >> Cheers, >> Timothy >> >>>-----Original Message----- >>>From: Strelchun, Timothy >>>Sent: Sunday, May 15, 2011 3:36 AM >>>To: 'directfb-dev@directfb.org' >>>Subject: [PATCH] 3 patch set with core changes made to enable gfx >>>drivers to handle system memory buffer allocations >>> >>>Well it took longer than anticipated to find some spare time to yank >>>out the key changes from our custom DFB 1.4.3 core, but it's >done now. >>>Attached are the patches against the latest 1.5 tip that my >team made >>>to enable GPU-based support for malloc memory based surfaces. >>> >>>Note: Aside from validation compilation with the latest 1.5 >code, we >>>have only done runtime tests with these changes on our >custom systems >>>and graphics driver(s), and not with the standard DFB solution. It >>>would be good to hear of any issues with it, improvements and/or >>>successes. >>> >>>Here are the details from the patches: >>> >>>--------------------1 of 3 >>>Subject: [PATCH] Allow graphic drivers to get buffers from >any surface >>>pools. >>> This was done by adding the >>>dfb_surface_pool_gfx_driver_update function to update any surface >>>pools that match the specified types (such as >>> CSTF_INTERNAL/PREALLOCATED) to by adding the specified >>>CSAF_READ/WRITE flags to the indicated accessor (such as >CSAID_GPU). >>>It is intended to be called by a graphics driver from its >>>driver_init_driver function. >>> >>>On a platform with a UMA, this now allows a graphics driver >to say it >>>also supports the local surface pool, shared surface pool, and/or >>>pre-allocated surface pool. >>> >>>-----------------------2 of 3 >>>Subject: [PATCH] Added buffer alloc destroy notify message. >>> Added a surface notification message sent for each buffer >allocation >>>that is destroyed. It is sent by the dfb_surface_pool_deallocate >>>function using a new notify function called dfb_surface_pool_notify. >>> >>>A graphics driver that allocates custom shared/local resources for a >>>buffer allocation from any surface pool (such as the pre-allocated >>>memory one) should register to receive this new buffer allocation >>>destruction message. This will give the graphics driver (in each >>>registered process) an opportunity to destroy those >associated custom >>>shared/local resources. >>> >>>-----------------------3 of 3 >>>Subject: [PATCH] GPU system memory support cache flushing mods. >>> Made changes necessary in the dfb_surface_buffer_lock function to >>>handle GPU based reading or writing support for local and system >>>memory based surface buffers (as well ones in user pre-allocated >>>memory). Previously, when a GPU read/write was requested, the CPU >>>memory cache was not flushed when the CPU had only read from the >>>memory. Changes require validation on traditional non-UMA based >>>graphics drivers. >>> >>>Updated the dfb_surface_pool_allocate function to alway mark >brand new >>>CoreSurfaceAllocations as having been both read and written >to by the >>>CPU. Updated the allocation_update_copy function to track that the >>>CPU wrote to the destination buffer allocation and that it read from >>>the source buffer allocation so that proper cache flushing >will occur. >>> >>>----------------------- >>> >>>Cheers, >>>Timothy >>> >>>-- >>> >>>Timothy Strelchun >>>CE Software Engineering >>>Digital Home Group >>>Intel Corporation >> _______________________________________________ >> directfb-dev mailing list >> directfb-dev@directfb.org >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> >> > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
