[Mesa-dev] Down to 1 single WebGL 1.0.1 test failure with Intel driver

[Benoit Jacob]

Hi,

We're now at the finish line of passing WebGL 1.0.1 test on real drivers. 

We landed a work-around for the glLinkProgram issue, as it was happening on many drivers across many OSes.

Now the very last conformance failure on the Intel driver / Mesa 8.0.2 is the one in this test page,

 https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/context/context-attributes-alpha-depth-stencil-antialias.html

Which is caused by the Intel driver lying about GL_MAX_SAMPLES, as explained by Eric in the "WebGL WG interested in 1.0.1 conformance test results on real drivers" thread on this list:

Eric Anholt wrote:
> GL_MAX_SAMPLES tells you how many samples you can ask for from a
> multisample renderbuffer (GL 3.0 spec page 285), while to ask about
> the
> number of samples in a particular GLX visuals you have to check the
> GLX_SAMPLE_BUFFERS_ARB of the visual (GL_ARB_multisample spec).  We
> currently expose GL_MAX_SAMPLES of 4 (GL 3.0 spec page 391), but
> that's
> a lie and if you ask for a 4-sample renderbuffer we don't actually
> multisample it.  We don't expose any GLX visuals with nonzero
> GLX_SAMPLE_BUFFERS_ARB, which is conformant but disappointing.


The question is how can we work around it?

 - Has this been fixed already in trunk? If yes, can you run the WebGL 1.0.1 conformance tests on this driver, using Firefox Nightly 17.0a1 (nightly.mozilla.org), and report?
   https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html

 - Is there a simple version check that will tell us whether we should trust GL_MAX_SAMPLES or assume 0 instead?

 - Or is there a reasonable way that we can query the actual value, even in driver versions where GL_MAX_SAMPLES lies?

Thanks,
Benoit