Hi Ilyes, >Out of curiosity, is that blitter MMU kind of "shared" with >the CPU's MMU? or do you guys provide your own replacements >for malloc()/realloc()/free(), for DirectFB?
It is not shared with the CPU MMU and is instead part of the GPU unit on our different SOCs. We do not provide replacements for DFB's memory allocation functions. The underlying graphics drivers used by our DFB graphics drivers handle setting up the needed GPU MMU mappings for the malloc'd memory pages (which are locked and cannot move) and hide that complexity from the DFB layer. Cheers, Timothy >-----Original Message----- >From: Ilyes Gouta [mailto:ilyes.go...@gmail.com] >Sent: Wednesday, June 22, 2011 1:19 AM >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, > >Out of curiosity, is that blitter MMU kind of "shared" with >the CPU's MMU? or do you guys provide your own replacements >for malloc()/realloc()/free(), for DirectFB? > >Thanks, > >-Ilyes > >On Tue, Jun 21, 2011 at 11:31 PM, Strelchun, Timothy ><timothy.strelc...@intel.com> wrote: >> 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
