Updates to GLX_EXT_texture_from_pixmap

[James Jones]

On Friday 31 March 2006 12:43 pm, Kristian Høgsberg wrote:
> Deron Johnson wrote:
> > James Jones wrote On 03/30/06 12:30,:
> >> I still would
> >> like to make this [drawable locking] part of a separate
> >> extension though.  As I've mentioned before, people may need
> >> it in cases where
> >> texture_from_pixmap isn't applicable.  It also seems like
> >> something better implemented mostly in core X, with some
> >> support from drivers, rather than entirely in drivers as part
> >> of
> >> texture_from_pixmap.
> >
> > I am concerned that LockDrawables will introduce unnecessary
> > overhead in the tfp bind process. Since the composite manager
> > should not access the contents of the drawable until it is
> > known to be locked, and LockDrawables is an X request, it is
> > necessary that LockDrawables be a synchronous request, that is
> > to say, it requires a round trip to the server.

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.

> > My 
> > understanding of tfp bind, on the other hand, is that it is a
> > direct-access opengl routine which bypasses the X protocol and
> > requires less overhead.

Currently, yes, TFP BindTexImage does not necessarily need to be 
synchronous.  It doesn't even need to send protocol in the direct 
rendering case.

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.

So, both methods have the exact same limitations.  The only 
additional overhead a LockDrawables call would introduce over the 
implicit lock you propose is the cost of a few words in the command 
stream.

> > Having a separate LockDrawables extension for other uses is
> > okay, but I don't think we should rely on it for tfp bind. I
> > recommend that tfp bind/unbind include their own locking
> > semantics with no need to make separate locking calls.
>
> So wouldn't it make sense to keep the locking out of tfp and
> leave it to the compositing manager as originally suggested? 
> What your describe above is basically the rationale for keeping
> the behaviour undefined - it relies on a mechanism outside tfp to
> stop applications from rendering to the pixmap.  We can
> investigate different mechanisms, from brute force server grabs
> to protocols for fine grained client/compmgr interaction, but
> through all of that we can use the same tfp extension.

Amen.

Thanks,
-James Jones

> Kristian

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