Xgl/Xegl future?

[Adam Jackson]

On Sunday 21 August 2005 20:17, Michel Dänzer wrote:
> On Sun, 2005-08-21 at 18:07 -0400, Adam Jackson wrote:
> > First is that for any sort of decent performance for image- or
> > texture-intensive GL clients, Xgl will need to gain support for the DRI
> > protocol.  This is real close to trivial.  The GLX backend would actually
> > have it toughest since it would have to translate the cliprects, window
> > positions, etc. by the Xglx window's position, and there might be some
> > other issues with the nesting there that I haven't thought through yet. 
> > But for Xegl it shouldn't be difficult at all.  There's one or two latent
> > dependencies in the libdri code in the server on things in the xfree86
> > ddx, but nothing huge.
>
> I'm afraid you're oversimplifying things. E.g., how will Xgl know the
> locations of redirected windows in the framebuffer for passing them on
> to the client-side driver as rendering buffer locations?

Depends.  Are you direct-rendering or not?  If you're not doing direct 
rendering then that's trivial, the server already knows where those buffers 
are because the server's the one drawing into them.  This is how 
GLX_MESA_render_texture in Xglx works today.

If you are direct rendering, then you need some cooperation over the protocol: 
the server needs to tell the client to render offscreen rather than to the 
front buffer, and the client needs to inform the server of the offscreen 
buffer's location.  The only challenge is deciding what channel to do that 
over, SAREA or DRI protocol or maybe GLX protocol + DRM interface.

> I can 
> definitely see this being solvable via vendor specific extensions, but I
> think this will be tricky to do in a vendor neutral way. Maybe something
> like sharing framebuffer objects between the server and clients (is that
> possible with just GL_EXT_framebuffer_object?), but we're still quite a
> way from supporting fbos at all in the free drivers...

I don't think that would be a hard _spec_ to write.  You'd want some new 
global GLX objects - call it a picture pool, eg - and then a way to bind 
various drawables to pictures in the pool.

The implementation would be entertaining, certainly, and for full 
orthogonality you'd want a way to expose these pictures through the Render 
extension as well.  But getting the pictures shared in a vendor neutral way 
should really just be a matter of sitting down and writing a GLX extension.

> > But, backing up from simple issues of GL performance, I think the real
> > reason toolkits are attempting to go through the GL path is because you
> > can fake Render in terms of GL (hence glitz), and the normal Render path
> > through the protocol is dog-slow because it's effectively all software. 
> > If we had a fast Render path on the server side, toolkits would use that
> > instead of invoking the pain of full GL.
>
> I'm not sure it's that simple. E.g., using GL directly also gives you
> direct rendering, which while probably not crucial for most
> applications, may be for some, e.g. the compositing manager.

Sure, and direct rendering is obviously an important feature to maintain going 
forward.  But it's important to note that, eg for cairo, the app has to pick 
its backend.  The compmgr might know that it wants the GL backend, so it just 
picks it.  The rest of gtk generally won't be doing things that fall in the 
(GL and not Render) set, so it'll use the Render backend.

I really don't see the concepts here being that difficult.  Just the 
engineering part.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050821/67ae1334/attachment.pgp>