mhopf at suse.de
Mon Aug 22 10:58:15 PDT 2005
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."
Matthias Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
More information about the xorg