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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
