Updates to GLX_EXT_texture_from_pixmap

[Deron Johnson]

James Jones wrote On 03/22/06 16:13,:
> Hi Deron,
>
> 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.

I don't know the details of your driver implementation but in the
drivers I have worked with it would not be all that hard to block
the rendering process. First of all, it's easy to block X core
protocol and GLX rendering clients. For direct clients, they
are required to acquire a lock to access device resources (such
as direct access to the screen or DMA buffers). You just hold
off granting them the lock if their current drawable is bound.
Even if they've already grabbed a DMA buffer, don't let it be
posted to the hardware command buffer until the drawable is unbound.
Again, I don't know the details of your driver implementation, but
there usually is a way to do put rendering clients to sleep.

Andy seemed to think that there was a way to do the blocking
in our discusssion at the X developers conference. What changed?

It may be tricky, it may even be difficult, but it has to be achieved.
Otherwise you end up implementing an extension that no composite manager
can reasonably use.

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

Yes. Arguments were made to that effect. But if we really want
to minimize the appearance of partial updates in redirected
GL rendering, we need these semantics. The group as a whole agreed
to this. I don't want to see us back pedal now.

> I think the best compromise is to guarantee copy on write 
> only if no other rendering occurs. 

This is equivalent to no guarantee at all. This is the same as
saying that the contents during the bind are completely undefined.

But I do know that no guaranteed of stable contents is light years
better than causing client rendering errors. Some clients die when they
receive rendering errors. We don't clients randomly dying because
the composite manager happened to hold a lock on their drawables
at the time.

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

If you are going to make the stable-while-bound semantic
platform specific, then you will need some way for the client
to figure out whether or not it is supported.

If my composite manager encounters a device that doesn't support
stable-while-bound, I probably will just not use the tfp extension
on that device, choosing instead to revert to using the
damage/copy mechanism I use now. I would rather have slower,
artifact-free rendering than fast rendering that has artifacts.

And, if only copy-on-bind devices can provide the stable-while-bound
semantic, then unless they provide a significant speed up over
the current damage/copy mechanism (which I doubt) then I won't
end up using the extension at all.

Before proceeding further, I would suggest that you implement a version
of the extension in the nvidia driver that does not implement
stable-while-bound and let's plug it into Looking Glass and see
how it looks. This will tell us whether it's worth jumping through hoops
to achieve the stable-while-bound semantic. Once we know how bad it is
then we will know better how to proceed.