Updates to GLX_EXT_texture_from_pixmap

[Deron Johnson]

Michel Dänzer wrote On 04/04/06 00:06,:
> On Mon, 2006-04-03 at 15:32 -0800, James Jones wrote:
> 
>>I have limited knowledge of X internals though.  Should it turn out 
>>that there exists or can be implemented an easy way for drivers to 
>>cause the server to take a driver-managed lock before rendering, 
> 
> 
> AFAIK EXA calls the driver before and after each rendering operation to
> or from a pixmap, accelerated or not.
> 
> 
>>I'm once again going to propose more or less the same compromise:  
>>We could write a separate GLX extension to do the locking.  This 
>>would still have the advantage of keeping EXT_texture_from_pixmap 
>>as simple and lean as possible and provide the semantics & 
>>performance you're looking for.  To support such an extension, I'd 
>>still need to be convinced it was reasonable to implement such a 
>>lock and we would have to measure a large enough performance hit 
>>from the currently proposed methods to justify it.  
>>
>>Note that if we agree on this separate extension approach in any 
>>form, we could have a period where a completely specified version 
>>of texture_from_pixmap is available and implemented in several 
>>drivers, and various developers could actually peform tests to 
>>determine exactly what kind of performance enhancements and locking 
>>semantics are needed.  They can then be added without breaking the 
>>existing extension.  It would be much more painful to remove 
>>unproven locking semantics found to be unreasonable or inadequit 
>>(for whatever reason) from a finished, shipping extension.
> 
> 
> I agree, and it's my impression that so does pretty much everybody else
> except Deron.

I have no problem with the lock being a separate extension. The most
important thing is that such a locking mechanism exist and that it
provide good performance. Whether it is a part of the tfp extension or
separate is immaterial.