Xgl/Xegl future?

[Brian Paul]

Matthias Hopf wrote:
> On Aug 22, 05 10:52:36 -0600, Brian Paul wrote:
> 
>>Matthias Hopf wrote:
>>
>>>On Aug 21, 05 20:53:34 -0400, Adam Jackson wrote:
>>>
>>>
>>>>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.
>>>
>>>
>>>The even more crucial problem is that one process would like to render
>>>into this buffer (the application, direct rendering), and another
>>>process would like to bind this buffer to a texture (composition
>>>manager, when using direct rendering, or the Xserver, when using
>>>indirect rendering for composition or no composition at all).  Currently
>>>there is no OpenGL extension for sharing offscreen buffers (or anything
>>>else!) between processes, there is only a notion for sharing between
>>>contextes of the same process.
>>
>>That's not really correct.  PBuffers, for example, are named with an 
>>XID.  That basically means that any process that has access to the ID 
>>can render to it (ignoring security), just like X windows.
> 
> 
> 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.

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

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.

-Brian