Updates to GLX_EXT_texture_from_pixmap

[James Jones]

On Thursday 23 March 2006 12:11 am, Ian Romanick wrote:
> 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 overall desired behave was to give the effect
> > of conceptually having bind make a copy of the texture.
>
> When I first stuck my nose into this discussion, I guess I didn't
> fully grok the interaction that was happening.  I've thought
> about this a bit more today, and the wording currently in the
> spec *and* the proposed behavior here are not feasable.

Ian, completely disallowing rendering is not the intention I had 
when I wrote up that paragraph.  Did you see the updated version I 
sent out in response to your original reply?  It should clear up 
that discrepancy.  Rendering just results in the texture having 
undefined content.

> Disallowing rendering while a drawable is bound to a texture
> would require one of the following scenarios.  Each is either
> undesirable or unimplementable.
>
> 1a. If a drawable is bound for drawing, generate an error at
> BindTexImage.  If a drawable is bound for texturing, generate an
> error at MakeCurrent.  This is doable, but requires some
> synchronization that may be difficult in the direct rendering
> case.  It is undesirable because the server will nearly always
> want to use the drawable for texturing when the application has
> it bound for drawing.
>
> 1b. If a drawable is bound for texturing (in any thread),
> generate an error at glBegin.  If I even have to explain why this
> would suck rocks...
>
> I'm not exactly sure what "rendering to a drawable while it is
> being bound as a texture would be blocked" means.  I assume that
> it means the drawable has an implicit read-write lock of sorts. 
> My guess is that BindTexImage grabs the lock for reading, and
> glBegin grabs the lock for writing (or something morally
> equivalent).  This has problems of it's own.
>
> 2a. It would be easy to implement in the direct rendering case,
> but would add unnessary overhead when BindTexImage is never used.
>  Since this is by far the more common case, this seems like a
> poor trade off.
>
> 2b. The indirect rendering case just gets ugly.  The server would
> have to buffer commands from the client until the lock was
> released.  I don't think this is really any better than 1b above.
>
> 2c. Like 1a above, we could have the lock be acquired in
> MakeCurrent and BindTexImage.  However, this ends up having the
> same set of problems, except now the server could get blocked ad
> infinitum wanting for the client to unbind the drawab.e
>
> 2d. It seems like there's a possability for deadlock here, but I
> can't quite put my finger on it.

Right, and this still wouldn't be sufficient.  Since these drawables 
can be rendered to by X, all types of rendering, not just GL 
rendering, would need to be blocked.  Xlib clients, direct/indirect 
GL clients, direct/indirect XvMC clients, etc.

Thanks,
-James Jones

> The nearest functionality that compares to this today is
> MakeContextCurrent / MakeCurrentRead.  If one thread has a
> drawable bound for drawing and another has it bound for reading,
> "there is a race condition between threads that read and update
> the depth buffer" (page 29 (35 of the PDF) of the GLX 1.4 spec).
>
> In addition, section 4.4.3 of the EXT_framebuffer_object says the
> following:
>
>     Special precautions need to be taken to avoid attaching a
> texture image to the currently bound framebuffer while the
> texture object is currently bound and enabled for texturing. 
> Doing so could lead to the creation of a "feedback loop" between
> the writing of pixels by the GL's rendering operations and the
> simultaneous reading of those same pixels when used as texels in
> the currently bound texture.  In this scenario, the framebuffer
> will be considered framebuffer complete (see section 4.4.4), but
> the values of fragments rendered while in this state will be
> undefined.  The values of texture samples may be undefined as
> well, as described in section 3.8.8.
>
> The clear precident is that it is perfectly valid to have the
> same thing bound for reading and writing in multiple contexts /
> threads.  However, when this is done, there is no guarantee that
> the reader will get the data that it expects.
>
> In practice, would this behavior be a problem?
>
> > To disallow user rendering while the drawable is bound as a
> > texture makes the entire extension unusable. What happens to
> > rendering that is sent to the drawable while it is bound? Is it
> > discarded? Does it generate an error? 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. Not only that, the restriction of disallowing drawing
> > during texturing is not even needed for devices on which the
> > bind does a real copy.
> >
> > 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.