[PATCH xserver 07/13] glx: Use __glXInitExtensionEnableBits in all backends

Adam Jackson ajax at redhat.com
Wed Mar 30 14:41:06 UTC 2016


On Wed, 2016-03-30 at 12:48 +0100, Emil Velikov wrote:

> Similar to patch 5 - we assume that things will be fine if the base
> implementation lacks the WGL extensions. As this can cause the
> occasional wtf moment - wouldn't it be better to have a big fat
> warning for each of these (three so far) missing extensions alongside
> the proposed behaviour ?

Excluding make_current_read I don't think it can make much difference.
To trigger a failure mode here you'd need an application that already
works _without_ pbuffers or multisampling, that optionally supports
them, but that will fail fatally if the extension string is found but
not a matching fbconfig (instead of just falling back to the mode in
which it already works). Apps are dumb, but I've yet to find one _that_
dumb.

> Jon, any ideas how (un)common it is for WGL_ARB_make_current_read,
> WGL_ARB_pbuffer and/or WGL_ARB_multisample to be missing ?

I had this exact question! Some kind soul on #dri-devel (I forget who,
but thank you) pointed me to:

http://opengl.gpuinfo.org/gl_extensions.php

It's not the best search interface, but we can draw some conclusions
anyway. To a first approximation, all WGL implementations supply
WGL_ARB_extensions_string (as otherwise you can't query for extensions
at all); 1036 reports in that db support it, and 201 do not. Of those
201, there are two that are WGL (and not GLES) implementations anyway:
the GDI Generic implementation included with Windows (which isn't
accelerated, so we wouldn't get here anyway) and VirtualBox's chromium-
based driver. The same set is the set of drivers not supporting
WGL_ARB_pbuffer.

WGL_ARB_make_current_read is unsupported by 207 reports. Beyond the
above, the affected drivers are: vmware with what looks to be llvmpipe
(for shame!), Intel GMA5/600, PowerVR SGX545, Matrox M-series, and XGI
Volari.

WGL_ARB_multisample is unsupported by 252 reports. Beyond the non-
pbuffer set this seems to be true of R200-era radeons, geforce 4 and
below, and pretty much any Intel chip in compatibility contexts.

- ajax


More information about the xorg-devel mailing list