Surprise! I stumbled upon the need for a fourth patch I had missed (our custom development branch did not have a general solution implemented for graphics drivers to report full support for system memory based surfaces using the CCF flags yet).
Here are the details from this FOURTH patch:
-----------------------
Subject: [PATCH] Updated dfb_gfxcard_check_state to check for
full system memory support.
Added CCF_WRITESYSMEM so that a graphics driver can fully
report that it supports reading and writing to system memory
based surfaces, and updated the dfb_gfxcard_check_state
function to use that data to determine if acceleration is
possible when the back buffer policy is system only.
-----------------------
Regarding usage: With these four patches, for a UMA-based
graphics driver to support system memory surface (and
preallocated ones) it just needs to make the following call
from the driver_init_driver function:
dfb_surface_pool_gfx_driver_update(
CSTF_INTERNAL | CSTF_PREALLOCATED,
CSAID_GPU,
CSAF_READ | CSAF_WRITE );
and from the driver_init_device function add support for
reading and writing system memory surfaces to the flags
already specified:
device_info->caps.flags |= CCF_READSYSMEM | CCF_WRITESYSMEM;
Then make sure the driver handles all of the different
types of surface buffers and allocations that it will
receive in the CheckState and SetState functions.
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
0004-Updated-dfb_gfxcard_check_state-to-check-for-full-sy.patch
Description: 0004-Updated-dfb_gfxcard_check_state-to-check-for-full-sy.patch
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
