DRI2 Protocol Spec Draft

[Michel Dänzer]

On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote:
> On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote:
> 
> > GLX_EXT_texture_from_pixmap needs the real front buffer.
> 
> Sure, but that's not through DRI2, this just references the object as an
> X pixmap.

I don't understand what you mean. How would a direct rendering,
zero-copy implementation of GLX_EXT_texture_from_pixmap work without
getting the pixmap buffer ID via DRI2GetBuffers?


> > Some GLX synchronization extensions provide information about whether a
> > buffer swap hit or missed the target.
> 
> We could have the request return an error if the sequence target could
> not be met.

So in order to find out the effective sequence number, the client would
need to keep incrementing the target number and check for the error?
Doesn't sound very appealing to me.

Not to mention X protocol errors tend to be a PITA.


> > Generally, if DRI2CopyRegion seriously wants to be useful for
> > synchronization purposes, it probably needs to provide at least the same
> > functionality as the DRM vblank related ioctls.
> 
> Certainly the combination of DRI2CopyRegion and DRM should be able to
> provide sufficient synchronization. The question is what portion of this
> task belongs in the extension and what portion belongs in the DRM kernel
> API.

If the GLX implementation is to use DRI2CopyRegion for synchronization
purposes, then the interface of the latter needs to be at least as
expressive as the DRM synchronization interfaces currently used by the
former.


> > Of course, for redirected windows it should really synchronize to the
> > compositing manager rather than to the display hardware directly, but
> > I'm not sure that matters at this point.
> 
> For redirected windows, the CopyRegion will not block, and the
> compositing manager will get a Damage event when it occurs. At that
> point, it's up to the compositing manager to 'do the right thing' to get
> contents sync'd to the screen (presumably by using CopyRegion itself).

Eventually there will need to be some kind of synchronization mechanism
between direct rendering clients and the compositing manager, or smooth
animation at the display framerate isn't possible with redirected
windows. That mechanism could be basically the same as the existing
sync-to-vblank mechanisms, but with 'vertical blank' replaced by
'compositing manager screen update'. So it would provide the client with
a way to express the display frame at which the buffer swap should take
effect and to synchronize to the compositing manager making it so.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer