ajax at nwnk.net
Sun Aug 21 17:53:34 PDT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg