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
