DMX and 3D Compositing Questions

[Kevin E Martin]

On Fri, Jul 25, 2008 at 02:06:21PM +0200, Christian Pirchheim wrote:
> Hi,
> 
> Creating large tiled displays using multiple distributed X-servers can
> be done using the DMX-server [1]. DMX integrates with Xinerama extension
> to pretend a single large display to client applications which are
> actually rendered on multiple displays. Each of these X-displays is
> provided by one backend X-server, DMX opens a fullscreen window on each
> of the displays and manages I/O. DMX is often combined with Chromium
> which allows for rendering fullscreen 3D applications.
> 
> Now, here comes my question: What does it take to make DMX compatible
> with 3D compositing window managers? Background of my question is, that
> we would like to create large seamless displays combining multiple
> overlapping projectors. Within the composite window manager, the desktop
> geometry and window textures are available, allowing to compensate for
> geometric and photometric distortions.
> 
> The basic steps in 3D compositing are (1) redirection of window pixmaps
> to off-screen buffers (Composite), (2) access those pixmaps as GL
> textures (EXT_texture_from_pixmap) and (3) render the composite desktop
> via OpenGL calls (GLX/OpenGL) indirectly or directly.
> 
> First, obviously, each backend X-server for itself must be
> 3D-compositing capable, including convenient graphics hardware and
> drivers, providing the required X extensions (Composite, Damage, RandR,
> XSync) and GL extensions (GL_EXT_texture_from_pixmap,
> GL_ARB_texture_non_power_of_two, GL_EXT_framebuffer_object) and direct
> rendering support.
> 
> But then? For (1), the Composite extension is required, which is
> currently not supported by neither, Xinerama nor DMX. I assume,
> Composite needs to be integrated in both. According to [1] DMX
> implements GLX and supports both indirect and direct rendering on its
> multiple backend servers. That fact sounds great, but what does it mean
> concerning (2) and (3). Does AIGLX (indirect accelerated rendering) have
> any relevance in this context?
> 
> I would be glad about any comments concerning these issues which will
> help to understand the problem and also the correlations between the
> various technologies.

Hi Christian,

I think you've got a good handle on the problem space.  The main issues
as you noted are that the Composite extension is not supported by either
DMX or Xinerama.  It should not be difficult to implement Composite
support in DMX, but Xinerama might be more challenging.  You might also
want to look at RandR 1.2, since it implements a different strategy
inside the X server than Xinerama for tying multiple screens together
into a single desktop.

Note that the glxProxy implementation from SGI only supports indirect
rendering currently.  Our original plan was to implement both direct and
indirect rendering, but glxProxy fit the customer's needs at the time,
so we concentrated on other tasks.  Using Chromium is also possible, but
I expect that will be more complicated to implement.  If you really need
direct rendering to the back-end servers, it's certainly possible, but
it's not required to run a compositing manager.  glxProxy will redirect
the compositing manager's GLX requests to the back-end servers, which
should be sufficient for most situations.  The obvious case where this
will be an issue is if you're doing lots of large data transfers between
the back-end servers and the typical apps you'll be running -- i.e., the
typical argument for direct vs indirect rendering.

As to your question about AIGLX, AIGLX is all about accelerating
indirect GLX rendering, so it's really only relevant to the back-end
servers in this context.  The front-end DMX server does not render the
GL request, and just forwards those requests to the back-end servers as
needed via glxProxy.

You'll also need to look at adding support for the GLX extensions you've
listed above in glxProxy.  They need to be forwarded to the back-end
servers, so they'll need to be decoded, and repackaged a la what
glxProxy does with the other GLX requests.  This could get a little
tricky for extensions like EXT_texture_from_pixmap, depending on how you
implement Xinerama/RandR 1.2 support in your compositing manager since
the different pixmaps will be stored on each of the back-end servers.

The other issue here is that if you're looking at compensating for
various distortions and have a non-planar display surface, then don't
forget about the input side.  You'll need a way to translate input
events to the appropriate window coordinates, and if those windows are
out of the standard display plane that the X server assumes, you'll need
to compensate.  Various people have discussed the options here, but I
have not seen much activity recently.

Hope this helps...
Kevin