Updates to GLX_EXT_texture_from_pixmap

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEIlhFX1gOwKyEAw8RAiPGAJ4krpzrZPAV6RG2bD6XAeL5KyvDtACfZ1fm
gCCxbcY138oTzR94+bCJQ3M=
=J7lz
-----END PGP SIGNATURE-----