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
0001-Allow-graphic-drivers-to-get-buffers-from-any-pool.patch
Description: 0001-Allow-graphic-drivers-to-get-buffers-from-any-pool.patch
0002-Added-buffer-alloc-destroy-notify-message.patch
Description: 0002-Added-buffer-alloc-destroy-notify-message.patch
0003-GPU-system-memory-support-cache-flushing-mods.patch
Description: 0003-GPU-system-memory-support-cache-flushing-mods.patch
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
