Re: [Mesa3d-users] question about client glx vs server glx

[Brian P. <bri...@tu...>]

R. Steven Rainwater wrote:
> On Fri, 2006-04-28 at 11:03, Brian Paul wrote:
> 
>>R. Steven Rainwater wrote:
>>
>>> server glx version string: 1.2
>>> client glx version string: 1.4
>>>What I'm not clear on is exactly which piece of software is the "server
>>>glx" that's reporting as GLX v1.2.
>>
>>There's actually two server-side pieces to GLX: the GLX X server 
>>extension and the OpenGL renderer.
>>
>>The GLX X server extension 
>>(/usr/X11R6/lib/modules/extensions/libglx.so) extends the X server so 
>>that it understands the GLX protocol.  If you run xdpyinfo you should 
>>see "GLX" in the list of extensions.
>>
>>The GLX X server extension receives GLX messages and dispatches them 
>>to the OpenGL renderer 
>>(/usr/X11R6/lib/modules/extensions/libGLcore.so) when using indirect 
>>rendering.
>>
>>In the past, this renderer has been based on Mesa and used no hardware 
>>acceleration.  More recently, the libGLcore module can load/use the 
>>DRI hardware drivers.  I think this'll be in X.org 7.1.
>>
>>The "client-side glx" is basically the libGL.so library.
> 
> 
> Thanks! That helps clear up some of my confusion. So libGL.so is the
> client glx that's reporting v1.4. And, if I understand what you're
> saying above, libGLcore.so is the part of the server glx that's
> reporting as version 1.2? (I assume the libglx.so just reports the
> version that libGLcore.so supports?)

No, libglx.so needs to specifically implement the GLX 1.x features. 
Though, libGLcore typically also needs to implement certain things for 
GLX (like Pbuffers).


>>>If that's the case, is it
>>>possible to upgrade Mesa to get support for GLX v1.3? 
>>
>>The question is: "upgrading the server-side GLX module to support GLX 
>>1.3".  This involves implementing some features like FBConfigs and 
>>PBuffers.  This hasn't been done yet.
> 
> 
> Is 1.3 support in the works for a future version? Sounds like this may
> be a non-trivial exercise. 

If it were easy it would have been done long ago.  The main thing 
missing right now is Pbuffer support.  We've taken a step toward that 
with recent work on the new DRM memory manager.


> Looks my best alternative then is patching wine to use the 1.2 api
> rather than 1.3. Wine only started requiring 1.3 very recently and the
> change has apparently caused some regressions in cases like mine where a
> previously working Windows app has stopped working because a 1.3 glx
> server isn't available. I've been looking at the code and it may not be
> too much work to revert the changes. It looks like most of it was the
> switch to glXChooseFBConfig from 1.2 stuff like glXChooseVisual.
>
> I haven't done any Mesa/OpenGL programming before but it seems to me
> that it would make sense for an app to query GLX and find out if the
> server supports 1.2 or 1.3 and then use the appropriate functions to
> render. Perhaps there's some reason why Wine doesn't do this.

Yes.  Wine should be checking the GLX version and only calling the 
functions which are supported by the version.  Your app should do the 
same thing.  If either component isn't doing that, all bets are off.


>>Since you're using NVIDIA hardware, you could install the NVIDIA 
>>driver package which fully supports GLX 1.3.
> 
> 
> The NVIDIA drivers, are proprietary, non-free software, which I'd prefer
> to avoid if possible. Anyway, improving the free software alternative to
> make this work would benefit others as well hopefully.

Sure.  I personally don't have anything against the NVIDIA drivers and 
frequently use them myself for various projects.


> There is a free software effort underway to add 3D acceleration support
> for Nvidia cards (which I assume means OpenGL support). It's not yet
> usable but seems to be making progress:
> 
>  http://nouveau.sourceforge.net/
> 
> -Steve

-Brian