Hi guys,
>>On 04/12/11 16:28, Thomas Block wrote:
>> Does anyone have an idea regarding the creation of a pre-allocated
>> buffer (from system RAM) surface that would allow that buffer to be
>> passed into my gfxdriver? I guess an equivalent question
>would be: how do I get read/write access flags set in the
>surface buffer pools for this pre-allocated buffer surface?
>(That seems to be the point of failure in dfb_surface_pools_negotiate).
On Tuesday, April 12, 2011 8:06 AM, Denis Oliver Kropp wrote:
>I'm not 100% sure yet, how to fix it, but I think the
>preallocated surface pool should be removed.
>
>Instead the system memory pool should pick up the memory with
>a flag for not freeing it by itself.
>The type flag CSTF_PREALLOCATED should then be removed,
>otherwise other pools fail as they don't support that flag.
>
>Regarding the system memory pool being accessible by the GPU,
>there has been a proposal from Timothy Strelchun, maybe he can
>elaborate.
For our UMA-based SoC, to allow a DFB graphics driver to render system
memory (local/shared) and pre-allocated memory surface buffers we added
a function to the core (called dfb_surface_pool_gfx_driver_update) that
adds extra access flags to each of the registered surface buffer pools
that match the type specified. That then allowed the graphics driver
to explicit say/indicate/specify that it supports receiving buffers
from certain specified additional types of pools. Then the graphics
driver's driver_init_driver function just makes a call to this function
to identify all of the additional supported functionality to be added
to the various already registered surface buffer pools. For example:
bool wasAdded;
wasAdded = dfb_surface_pool_gfx_driver_update(
CSTF_INTERNAL | CSTF_PREALLOCATED,
CSAID_GPU,
CSAF_READ | CSAF_WRITE);
D_ASSERT( wasAdded == true );
The graphics driver will then be given the opportunity (in CheckState
and SetState) to handle surface buffers from the local surface pool,
shared surface pool and pre-allocated surface pool. :)
We still let each surface buffer pool handle it's own deallocation.
If the graphics driver allocates any resources for CoreSurfaceBuffers,
it registers to receive notification from the core when they are about
to be destroyed (using a new buffer allocation destroy message that's
broadcasted during surface destruction).
I was planning to prepare a patch within the next week or two for
consideration (maybe two patches since I had forgotten about the need
for sharing the additional surface notification message also).
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
