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
