Updates to GLX_EXT_texture_from_pixmap

[Deron Johnson]

James Jones wrote On 04/03/06 16:32,:

> The definition of this particular "lock" operation is that after it 
> is processed by the server, no rendering should be allowed to the 
> drawables specified.  So, if the application taking the lock does 
> not directly access the contents of the drawable, but rather issues 
> further commands in the same serialized command stream as the lock, 
> it only needs to be guaranteed that the lock executes in the proper 
> order.  In other words, the lock has the same semantics as a server 
> grab.  It is processed when it reaches the server, and subsequent 
> commands are processed afterwards.  Therefore, the subsequent 
> commands are guaranteed to execute while the lock is held.  This 
> will work fine asynchronously, just as XGrabServer does now.
>
> For users of both LockDrawable and XGrabServer that require direct 
> rendering access to be synchronized with these locks, an XSync must 
> be done to ensure the lock has been actually processed/taken by the 
> server.  I think this is the case you are  thinking of.

It is true that you can delay the blocking-for-the-lock until the
compositor's first access to the drawable (which will usually be a
rendering operation that uses the drawable as a texture). This seems
to me to be a micro-optimization and an implementation detail.
>From the user's point of view, he conceptually holds the lock when the
lock request returns. Documenting in any other way to the user
just introduces unnecessary confusion.

> 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, 
> 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.

Like I said in my earlier mail, I am willing to test a lockless
version of tfp in Looking Glass and see how it works. If you want to
provide locking in a different extension, that's fine with me.