Updates to GLX_EXT_texture_from_pixmap

[James Jones]

Hi Deron,

Good to see you're tracking the changes.  Responses below.

On Wednesday 22 March 2006 03:23 pm, Deron Johnson wrote:
> James Jones wrote On 03/09/06 14:09,:
> >     Rendering to the drawable, either using the GL or other
> > means, while it is bound to a texture is not allowed.  It is
> > the responsibility of the user to enforce this constraint.  If
> > the drawable is rendered to while it is bound as a texture, the
> > contents become undefined.
>
> This is very different from what we discussed at the X
> developer's conference. I thought we agreed that rendering to a
> drawable while it is being bound as a texture would be blocked,
> and that the rendering would proceed as soon as the drawable was
> unbound.

The problem here is, how do you block the rendering?  It would be 
nice if we could put clients who wanted to render to a particular 
drawable to sleep.  However, this would be very hard to do.  The 
current dispatch mechanism isn't capable of this.

As an alternative, we could save off rendering commands in the 
driver or in the hardware's command buffer in some way.  At the 
least, this would add a lot of overhead in the driver.  Also, when 
this gets to a point where there is no space left to batch and the 
drawable is still bound to a texture, what do we do?  We'd have to 
punt back to disallowing commands from clients trying to render to 
bound drawables, and we'd be right back where we started.

This only leaves the possibility of performing a copy-on-write type 
of operation, which would ruin any benefit gained from this 
extension, and again, would be very difficult to implement.

> The overall desired behave was to give the effect of
> conceptually having bind make a copy of the texture.

Is this really the overall desire?  Others have argued that Bind 
operations will be too slow, and they would rather the contents 
were just updated on the fly with no need to bind more than once.

I've argued both sides of this point at various times.  It's a hard 
problem.  I think the best compromise is to guarantee copy on write 
only if no other rendering occurs.  This allows the same semantics 
discussed at XDevConf, but places the burden of synchronization on 
the user, which is what OpenGL and GLX usually do in "hard" cases 
like this.  In the long run binds will need to be fast and we wil 
need a better method for clients in general and composite managers 
in particular to perform this synchronization.

> To disallow user rendering while the drawable is bound as a
> texture makes the entire extension unusable.

The spec does not disallow user rendering while the drawable is 
bound.  It allows the implementors to choose whether or not to 
support it.  This is a compromise.  It makes the extension 
reasonable to specify, implement, and use.  Implementations that 
choose to not handle rendering to bound drawables won't work with 
many existing applications.  In the short term, all the 
implementations we know of support it to some degree.  Again, in 
the long term, better synchronization solutions are needed.

> What happens to 
> rendering that is sent to the drawable while it is bound? Is it
> discarded? Does it generate an error?

Yes, unfortunately, it does whatever the implementation wants it to 
do, including any of the suggestions you make.

> Either way, there is no way 
> that the client rendering to the drawable can synchronize with
> the composite manager to make sure that this doesn't happen.

There is a way, albeit a bad one, to ensure clients don't render to 
a drawable while it is bound to a texture.  See the issues section 
of the spec.  As stated earlier, there should be a better way.  
However, that problem is beyond the scope of this extension.  We 
need a solution to coordinate composite operations and rendering 
operations such that they don't overlap, without using a costly 
server grab.  This problem is not specific to texture_from_pixmap, 
and needs to be solved in the general case.

> Not 
> only that, the restriction of disallowing drawing during
> texturing is not even needed for devices on which the bind does a
> real copy.

Right.  And for implementations that can render to and texture from 
the same memory, the "undefined results" will already be exactly 
what users want.  Intermediate results of the rendering that was 
requested.  Arguments of "this isn't needed for some cases, why do 
we need it at all?" are just ignoring half the problem.

> I think we should go back to the semantics we agreed upon at the
> X developer conference and have implementions hold off rendering
> to the drawable while it is bound, if necessary.

I appreciate your input, but unfortunately I'm still not convinced.

My overall opinion is that this spec should describe a lightweight 
mechanism that allows texturing from a drawable.  Desktop 
compositing is a very difficult problem.  The best way to solve 
difficult problems is to break them up into manageable pieces.

This extension should be viewed as part of a broader framework that 
includes the existing composite and damage extensions and some 
currently unspecified synchronization mechanism to provide 
rock-solid OpenGL-based desktop compositing for the X window 
system.

Thanks,
-James Jones