[PATCH 1/4] dix: Provide means to report exact sizes of resources.

Rami Ylimäki rami.ylimaki at vincit.fi
Fri Nov 5 08:07:47 PDT 2010


  On 11/03/2010 07:48 PM, Daniel Stone wrote:
> Hi,
>
> On Thu, Oct 28, 2010 at 01:23:41PM +0300, Rami Ylimäki wrote:
>> +/**
>> + * Override the default function that calculates resource size. For
>> + * example, video driver knows better how to calculate pixmap memory
>> + * usage and can therefore wrap or override size calculation for
>> + * RT_PIXMAP.
>> + *
>> + * @param[in] type     Resource type used in size calculations.
>> + *
>> + * @param[in] sizeFunc Function to calculate the size of a single
>> + *                     resource.
>> + */
>> +void
>> +SetResourceTypeSizeFunc(RESTYPE type, SizeType sizeFunc)
>> +{
>> +    resourceTypes[type&  TypeMask].sizeFunc = sizeFunc;
>> +}
> So, I guess the intention here would be to call
> SetResourceTypeSizeFunc(RT_PIXMAP, my_driver_how_big_is_the_pixmap); ?

Yes.

> In that case, it falls apart in the multi-screen case (yeah, I know, it
> barely works).  dixFreePixmap and FreeWindowResources get around this by
> calling the corresponding ScreenRec hook: would the intention be to add
> one to make the sizing work correctly for multiple drivers, or?

I overlooked the case that multiple drivers could be in use. Would it 
make sense to require cooperation from drivers to make this work? A 
driver would call GetResourceTypeSizeFunc to save the old function 
before registering its own. Then the driver can check if the resource is 
associated with a screen, what screen it is associated with and either 
calculate the size or just forward the calculation to the original function.

To be honest I'm not exactly sure what is meant by this multi-screen 
case. Does that mean that each screen could have its own driver that is 
then responsible of calculating the size of those pixmaps whose 
pixmap->drawable.pScreen matches the driver screen?

> Other than that, looks good to me, but one thing to bear in mind if we
> keep on extending resource usage would be to add a size argument to
> AddResource(), as well as a new ResourceSizeChanged(), rather than
> having to call back for every resource.  The callbacks will work fine
> for the pixmap/window/etc case as drivers already have all the relevant
> size information, but we might end up with resource types in the future
> where you'd need a great deal of unnecessary bookkeeping just for these
> callbacks.

Makes sense to have these alternative ways of reporting the resource 
size. Every resource object would have a size associated with it. If the 
size happens to be zero (not given) try to call the size callback.

> Cheers,
> Daniel

-- Rami



More information about the xorg-devel mailing list