Updates to GLX_EXT_texture_from_pixmap

Deron Johnson Deron.Johnson at Sun.COM
Fri Apr 7 10:31:40 PDT 2006

Jamey Sharp wrote On 04/03/06 16:24,:
> On Mon, Apr 03, 2006 at 03:24:03PM -0700, 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.
> If the compositing manager uses pure X protocol (no direct rendering)
> then the X server can just stop processing the compositor's request
> stream until the lock is acquired. That's different from forcing the
> client to wait for a round-trip, which is what is usually meant by
> "synchronous requests" in X. For XCB we've taken to calling these
> "non-void requests" instead, since XCB makes all requests somewhat
> asynchronous from the client's point of view.

Regardless of how you implement it, the key behavior is that the
call to LockDrawables must not return until the lock has been acquired.

> For direct rendering compositors, this same approach, of freezing
> processing of the compositor's request stream, should work as well.
> However a round-trip is necessary in that case, so such a client needs
> to call XSync or make some other round-trip request after the
> LockDrawable request, as James Jones originally described.

I'm still having a hard time understanding why it is necessary to
add X protocol overhead to a GL extension implemented via direct
rendering. That is not typically how one implements GL extensions.
But if everyone is for it and it doesn't introduce significant overhead
then I'm not going to oppose it.

More information about the xorg mailing list