FGLRX Pixel Buffer support

[sandain]

Everything I read indicates that pbuffers have been pretty much replaced by FBOs over the last few years. I haven't looked at the two in detail but at first glance it seems that using FBOs in WINE would be the way to go.

This is not a Wine issue, it is a driver issue. FGLRX does not support opengl extensions in use by popular programs that otherwise work perfectly under Wine.

Ideally, Blizzard would update their opengl code to utilize FBOs instead of pbuffers. Unfortunately, their opengl code works just fine on the two platforms it was designed for, OSX and Windows, so they have little incentive to make this change just to support Linux.

Again, with FGLRX having a common code base with the Windows driver, what is holding the devs back from implementing this in Linux?

Thank you.

[bridgman]

Let's be clear here - we're saying that fglrx may not support a WGL-specific opengl extension in use by popular WINDOWS programs, correct ?

Are you sure that NVidia implements the WGL extension in the Linux driver, or is it more likely that WINE successfully translates the call to an appropriate GLX extension but doesn't handle that properly on ATI cards ? I'm not necessarily disagreeing with you, just asking.

[sandain]

To clarify, FGLRX does not support a WGL-specific extension used in a Windows program. This means WoW run under Wine does not properly render using AMD hardware.

The Nvidia binary blob does not support this WGL-specific extension in Linux. However, Wine still properly renders WoW on Nvidia hardware.

Edit: Nvidia drivers do not export WGL-specific extensions, Wine handles this.

[sandain]

Are you sure that NVidia implements the WGL extension in the Linux driver, or is it more likely that WINE successfully translates the call to an appropriate GLX extension but doesn't handle that properly on ATI cards ? I'm not necessarily disagreeing with you, just asking.

To clarify, AFAIK, Wine's OpenGL implementation does no translation, it is just a wrapper that passes calls 1:1 to the driver.

[bridgman]

Actually that's wrong. It looks like NVidia does not implement the extension either. WINE maps the WGL call onto a different, experimental extension called GLX_SGIX_pbuffer (proposed in 1997 but never accepted) and that's what seems to be implemented in the NVidia driver. I suspect we also implemented it in our old OpenGL code (which would have been active back in 1997) but did not implement it in the new code base.

http://bugs.winehq.org/show_bug.cgi?id=11826

It sounds like the Wine devs also feel this should be mapped onto FBOs and would if they had time.

[sandain]

Hrm...

I'll have to verify that the Nvidia drivers actually export this extension when I get home. Everything I have read and experienced support my claim that they do.

Edit: I found the section of code in winex11.drv that maps the pbuffers, and you are right, they are mapped to GLX_SGIX_pbuffer (which glxinfo reports as being availiable with FGLRX). Here is a comment from the code that points out the problem:

/* In general pbuffer functionality requires support in the X-server. The functionality is
* available either when the GLX_SGIX_pbuffer is present or when the GLX server version is 1.3.
* All display drivers except for Nvidia's use the GLX module from Xfree86/Xorg which only
* supports GLX 1.2. The endresult is that only Nvidia's drivers support pbuffers.
*
* The only other drive which has pbuffer support is Ati's FGLRX driver. They provide clientside GLX 1.3 support
* without support in the X-server (which other Mesa based drivers require).
*
* Support pbuffers when the GLX version is 1.3 and GLX_SGIX_pbuffer is available. Further pbuffers can
* also be supported when GLX_ATI_render_texture is available. This extension depends on pbuffers, so when it
* is available pbuffers must be available too. */

So, part of what is needed is already implemented, what is missing is support for GLX server 1.3. Any chance we will be seeing this any time soon?

Again, thanks for your patience.

[bridgman]

Could be... I'm just going by the dev posts -- although it was Stefan D. posting and he does know this stuff pretty well.

It might turn out to be something trivial; one of the earlier posts in the Wine log implied they hadn't done much testing on ATI cards because neither the SGIX nor FBO calls were behaving properly at the time. If we are exposing the SGIX extension then this might just need a tweak in Wine.

[RealNC]

I'm not following here. If WoW uses this extension, but the driver doesn't implement it, how on earth does it render correctly in Windows in the first place?

[bridgman]

As I understand it, there is a pbuffers extension for Windows (WGL_ARB_pbuffers) but the corresponding X extension was never approved so exists only as the experimental GLX_SGIX_pbuffers, and nobody cares because most apps use FBOs instead of the older pbuffers anyways.

The apps which do use pbuffers have more trouble running on another OS because pbuffers is officially a Windows-only extension.

Sandain, it looks like we already have client-side support for GLX 1.3 but the server code only supports 1.2 (presumably because we don't overwrite that part of the X stack, not sure). What's not clear is if Wine and the app actually require server side support, or whether the statement "in general, pbuffers require server-side support" is just a generality. This is getting into a level of X-specific nuance I don't fully understand.

Anyways, this is something I can ask about.

[sandain]

Well now that I'm home, I've verified that the Nvidia drivers do not export the WGL_ARB_pbuffer extension as I had previously thought. I really should be careful about spreading FUD.. gah!

I'm currently cloning the wine git repo, and I'll start playing around with the code shortly. I have very little experience working with OpenGL, but I have a theory that I'd like to test. If I change the code to remove the check for glxRequireVersion(3), what happens?

I'll be back with a report when I know.