Xgl/Xegl future?

[Matthias Hopf]

> >No. They have a name that is consistent, but you cannot use them in
> >multiple contextes from different processes.  I talked quite a bit to
> >the NVidia guys, and having truely shared contextes is a complex issue
> >(potentially overlapping memory maps, etc.)
> >
> >The glx specs say (Sect. 2.3 - Direct Rendering and Address Spaces):
> >
> >"One of the basic assumptions of the X protocol is that if a client can
> >name an object, then it can manipulate that object. GLX introduces the
> >notion of an Address Space. A GLX object cannot be used outside of the
> >address space in which it exists."
> >
> >"With indirect rendering contexts, the client context state is kept in
> >the client's address space and the server context state is kept in the
> >address space of the X server.  In this case the server context state is
> >stored in an X resource; it has an associated XID and may potentially be
> >used by another client process."
> 
> That discussion is for "rendering contexts", not pbuffers or drawing 
> surfaces.  I'd bet that section of the spec hasn't been updated since 
> Pbuffers were added either.

Sigh. This is GLX 1.3 (so already pretty old, 1.4 is about to be
released).

2.1 Rendering Contexts and Drawing Surfaces:

'In X, a rendering surface is called a Drawable. X provides two types
of Drawables: Windows which are located onscreen and Pixmaps which are
maintained offreen. The GLX equivalent to a Window is a GLXWindow
and the GLX equivalent to a Pixmap is a GLXPixmap. GLX introduces
a third type of drawable, called a GLXPbuffer, for which there is no X
equivalent.'

'As long as the compatibility constraint is satisfied (and the address
space requirement is satisfied), applications can render into the same
GLXDrawable, using different rendering contexts.'

Together with the definition of the "address space requirement" (see
above) I perfectly read this as: the content of pBuffers cannot be
shared - by no means - between processes. I haven't read of a single
exception to the address space requirement so far.
Which makes sense. Why should the contents of windows be considered
different to pBuffers, if they share the same memory (GfxCard memory)
space? Not thinking about security ATM, though.

> A rendering context is not a drawing surface.  Don't confuse them.

I won't. But you have to take a look at both in order to understand all
scenarios and their implications. That's why we won't have any problems
at all when using indirect rendering only, and we currently cannot do
direct rendering in neither the composite manager nor the application
w/o an extension for sharing data (textures, surfaces, whatever) between
processes.

> When you talked to NVIDIA, were you specifically talking about 
> rendering contexts or drawing surfaces?  I totally understand why 
> sharing rendering contexts between processes would be hard, but not 
> drawing surfaces.

We never ever talked about sharing contextes, that doesn't make any
sense. You would need too fine-granular locks in order to implement that
(and you don't want to have *any* locks at all).
It was on the Xorg developer conference in Boston, BTW.

We were talking about *any* way to let one process access pixel data
that has been rendered by another process w/o transfering it to main
memory and back. The major problem is that the whole graphics memory is
mapped by each process, and there are subtle issues with the mapping.

I guess their memory manager hasn't been programmed with overlapping
maps in mind (how come - four years ago nobody thought about that being
a problem)...

They didn't say it is impossible, no, just that implementing an
extension for that is non-trivial. They were very interested in doing
so, but we would need to know *exactly* what we need first. So first we
should think, then write an extension proposal, then (let) implement.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de