Updates to GLX_EXT_texture_from_pixmap

[James Jones]

On Monday 03 April 2006 03:24 pm, Deron Johnson wrote:
> James Jones wrote On 03/31/06 15:05,:
> > LockDrawables would not always be a synchronous request.  It
> > only needs to be synchronous if the composite manager is using
> > direct rendering.  Note that the example I suggested accounted
> > for this. Alternatively, LockDrawables could take a boolean
> > argument making it optionally synchronous.
>
> How can a lock operation not be a synchronous request? By the
> very definition of a lock the process trying to acquire a lock
> must block until the lock is granted. If the LockDrawables
> request is not always synchronous, the client could end up
> accessing the drawable when it is not actually locked.

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.

> > However, If locking semantics were added, they would introduce
> > the same limitations as the proposed LockDrawables.  For direct
> > rendering composite managers, BindTexImage would be forced to
> > send protocol and require a sync.  For indirect rendering, the
> > lock could happen in band.
>
> This is not necessarily true. It is not necessary that
> BindTexImage send X protocol in order to implement locking
> semantics. Direct rendering library routines are allowed to
> bypass the X protocol in order to lock server objects. This is
> fundamental to the concept of direct rendering. I have
> implemented many such direct rendering routines that do exactly
> that.

It is true that direct rendering clients can lock server objects.  
However, for this to be viable, the X server must also acquire a 
lock when using these objects.  This is generally done for a few 
heavyweight operations like window moves.  For this to work as you 
describe, the X server would need to acquire a lock on these 
drawables before rendering to them.

Admittedly, the LockDrawable proposal has the same drawback, but I 
think it would be worse with the lock you propose.  As far as I 
know, every driver that wanted to implement EXT_texture_from_pixmap  
would need to wrap every FB layer call and acquire this lock before 
it executed the FB call, then unlock afterwards.  My hope is that 
by moving this functionality into a core X extension, the 
interception of rendering commands could occur at a higher level 
that would introduce much less overhead, and not require as much 
modification to every driver.

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.

Thanks,
-James Jones

(again, ignore the below)

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------