OpenGL programs use the same info as shown by glxinfo for detecting the OpenGL/GLX capabilities. Roughly speaking GLX is used for setting up OpenGL. Most programs barely use the GLX capabilities (games in general use SDL which handle it) and programs that directly use GLX in general only use its basics. (e.g. creating a GLX context and attaching some X drawable to it for drawing) The problem is that the GLX information reported by the ATI drivers isn't entirely correct which confuses programs like Wine which use GLX to its limits.
In case of GLX you can get information about what the Xserver supports (version/vendor/extensions; in general this is SGI), you can get information about what the client supports (version/vendor/extensions). The largest common demoninator between the client and server info is then shown as the 'main' GLX version and list of extensions. Programs are only allowed to look at the 'main' GLX information for querying what's available. (For instance client extensions don't have to be available even if they are listed)
The problem is that ATI's drivers report a recent GLX version (1.3 in the current drivers and 1.4 in the 8.41.x drivers). In GLX version 1.3 GLX extensions like GLX_SGIX_fbconfig and GLX_SGIX_pbuffer became part of GLX. Version number 1.3 implies that both features are supported but because this is neither reflected in the 'main' version (this is because the SGI module is still 1.2) or the 'main' GLX extension list the availability can't be assumed. Other drivers (standard DRI / Nvidia) nicely report the GLX extension names and because of that the functions can be detected. The end-result for the missing extensions is less GLX functionality in programs that try to use GLX correctly. In Wine we are using a very hacky ATI-check to get at least fbconfig support which we require (everything else has reported this for years)
The main changes that are needed in the drivers are to at least report the GLX extensions in the 'main' extension list until Xorg's GLX is 1.3 or higher too. But even then also advertise the extensions. This will also be needed in the future for GLX_EXT_texture_from_pixmap.
Hopefully this problem will be addressed in the future. It will make the life of developers easier (no ugly hacks and very strange bugs) but it will also offer users more functionality (on Wine actually some functionality isn't available right now due to the GLX madness; workarounds aren't accepted in Wine and even if we added those they would break for Mesa or other drivers)
In case of GLX you can get information about what the Xserver supports (version/vendor/extensions; in general this is SGI), you can get information about what the client supports (version/vendor/extensions). The largest common demoninator between the client and server info is then shown as the 'main' GLX version and list of extensions. Programs are only allowed to look at the 'main' GLX information for querying what's available. (For instance client extensions don't have to be available even if they are listed)
The problem is that ATI's drivers report a recent GLX version (1.3 in the current drivers and 1.4 in the 8.41.x drivers). In GLX version 1.3 GLX extensions like GLX_SGIX_fbconfig and GLX_SGIX_pbuffer became part of GLX. Version number 1.3 implies that both features are supported but because this is neither reflected in the 'main' version (this is because the SGI module is still 1.2) or the 'main' GLX extension list the availability can't be assumed. Other drivers (standard DRI / Nvidia) nicely report the GLX extension names and because of that the functions can be detected. The end-result for the missing extensions is less GLX functionality in programs that try to use GLX correctly. In Wine we are using a very hacky ATI-check to get at least fbconfig support which we require (everything else has reported this for years)
The main changes that are needed in the drivers are to at least report the GLX extensions in the 'main' extension list until Xorg's GLX is 1.3 or higher too. But even then also advertise the extensions. This will also be needed in the future for GLX_EXT_texture_from_pixmap.
Hopefully this problem will be addressed in the future. It will make the life of developers easier (no ugly hacks and very strange bugs) but it will also offer users more functionality (on Wine actually some functionality isn't available right now due to the GLX madness; workarounds aren't accepted in Wine and even if we added those they would break for Mesa or other drivers)
Comment