Xgl page - http://www.freedesktop.org/Software/Xgl

[Ian Romanick]

Michel Dänzer wrote:
> On Fri, 2005-03-11 at 13:26 -0800, Ian Romanick wrote:
> 
>>Basically, this is why I stopped working on the new memory manager.  It 
>>is 100% legal (and *must* be supported) for a client to create a 
>>direct-rendering context and an indirect-rendering context and "share" a 
>>pbuffer between them (just like can be done with a window).  
> 
> So that's possible, but does it make any sense? :) And does it preclude
> clients that only need them for direct rendered contexts from using them
> when they're only supported on the client side? And does this even work
> for windows now?
> 
>>Until the same driver can be loaded on the client-side & the server-side 
>>(or there is no client-side driver), pbuffers are DOA.
> 
> Why can't the client-side and server-side implementations cooperate on
> this even if they're not the same? Even if the server side can load the
> same drivers as the client side, there will be no guarantee that the
> client side loads (exactly) the same driver as the server side did.

The big difference, and the thing that makes it just work for windows, 
is that the client and the server know where display memory is and how 
to read data from it.  It's all on the screen.  With a pbuffer (or any 
off-screen rendering target), you don't have that luxury.

With the existing server-side GL implementation, there isn't any way for 
the server to know where the client put the pbuffer in graphics memory, 
much less how to read / interpret the data.  The same is true the other 
way around.  If the server uses malloc to get a buffer for "off-screen" 
rendering, the client can't access it at all.

As long as the client-side driver and the server-side driver are similar 
enough (they don't have to be the identical version, etc.), they can 
have some internal way to agree on that sort of thing.