Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. It should? I read the opposite in this quote from the GL 3.0 spec: Linking will also fail if one or more of the shader objects, attached to program are not compiled successfully, or if more active uniform or active sampler variables are used in program than allowed (see section 2.20.3). If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Thanks, I hadn't questioned that the test might be wrong, but now I agree with you. Also, the same phrasing is found in the OpenGL ES 2.0.25 spec page 30: If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Reporting this to the WebGL mailing list. I did find this gem later: If that program object that is in use is re-linked unsuccessfully, the link status will be set to FALSE, but existing executable and associated state will remain part of the current rendering state until a subsequent call to UseProgram removes it from use. Maybe they're testing that. I wonder what possible use was imagined for forcing that sort of complexity on driver developers. pgpItOMxZLE7V.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message - On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. It should? I read the opposite in this quote from the GL 3.0 spec: Linking will also fail if one or more of the shader objects, attached to program are not compiled successfully, or if more active uniform or active sampler variables are used in program than allowed (see section 2.20.3). If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Thanks, I hadn't questioned that the test might be wrong, but now I agree with you. Also, the same phrasing is found in the OpenGL ES 2.0.25 spec page 30: If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Reporting this to the WebGL mailing list. I did find this gem later: If that program object that is in use is re-linked unsuccessfully, the link status will be set to FALSE, but existing executable and associated state will remain part of the current rendering state until a subsequent call to UseProgram removes it from use. Maybe they're testing that. I wonder what possible use was imagined for forcing that sort of complexity on driver developers. Yes, the public_webgl list got a reply quoting that sentence as the reason for the unit test's behavior. I must say I sympathize with you on this, but since it's what the spec says and what a majority of GL implementations do, let's keep it that way. Cheers, Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On 04/24/2012 01:57 AM, Eric Anholt wrote: On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacobbja...@mozilla.com wrote: - Original Message - On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. It should? I read the opposite in this quote from the GL 3.0 spec: Linking will also fail if one or more of the shader objects, attached to program are not compiled successfully, or if more active uniform or active sampler variables are used in program than allowed (see section 2.20.3). If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Thanks, I hadn't questioned that the test might be wrong, but now I agree with you. Also, the same phrasing is found in the OpenGL ES 2.0.25 spec page 30: If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Reporting this to the WebGL mailing list. I did find this gem later: If that program object that is in use is re-linked unsuccessfully, the link status will be set to FALSE, but existing executable and associated state will remain part of the current rendering state until a subsequent call to UseProgram removes it from use. Maybe they're testing that. I wonder what possible use was imagined for forcing that sort of complexity on driver developers. I have a theory that may or may not be valid. Program objects are shared. The behavior implied by this bit of spec language is that relinking a program in one context won't break rendering in another context that is using that program. It's also possible that the language was written with the assumption that there was no such thing as state-dependent recompiles. Linking the program generates an executable, and you're done, right? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. It should? I read the opposite in this quote from the GL 3.0 spec: Linking will also fail if one or more of the shader objects, attached to program are not compiled successfully, or if more active uniform or active sampler variables are used in program than allowed (see section 2.20.3). If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed Create and attach depthStencil renderbuffer PASS depthStencilBuffer = gl.createRenderbuffer() is non-null. PASS getError was expected value: NO_ERROR : PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is width PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is height FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0. [ and 2 others of this sort ] I bet this will be our failure. We don't have test coverage for GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix. Cool, let me know. I wrote a test that checked that for all the internalformats we knew of for renderbuffers, the RB had that GL_RENDERBUFFER_INTERNAL_FORMAT. The test passed. I'll need to poke at the webgl testcase to figure out where to look next. pgpI5S8HfEMJc.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message - On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob bja...@mozilla.com wrote: conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. It should? I read the opposite in this quote from the GL 3.0 spec: Linking will also fail if one or more of the shader objects, attached to program are not compiled successfully, or if more active uniform or active sampler variables are used in program than allowed (see section 2.20.3). If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Thanks, I hadn't questioned that the test might be wrong, but now I agree with you. Also, the same phrasing is found in the OpenGL ES 2.0.25 spec page 30: If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program. Reporting this to the WebGL mailing list. Benoit conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed Create and attach depthStencil renderbuffer PASS depthStencilBuffer = gl.createRenderbuffer() is non-null. PASS getError was expected value: NO_ERROR : PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is width PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is height FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0. [ and 2 others of this sort ] I bet this will be our failure. We don't have test coverage for GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix. Cool, let me know. I wrote a test that checked that for all the internalformats we knew of for renderbuffers, the RB had that GL_RENDERBUFFER_INTERNAL_FORMAT. The test passed. I'll need to poke at the webgl testcase to figure out where to look next. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed Create and attach depthStencil renderbuffer PASS depthStencilBuffer = gl.createRenderbuffer() is non-null. PASS getError was expected value: NO_ERROR : PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is width PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is height FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0. [ and 2 others of this sort ] I bet this will be our failure. We don't have test coverage for GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix. Cool, let me know. I wrote a test that checked that for all the internalformats we knew of for renderbuffers, the RB had that GL_RENDERBUFFER_INTERNAL_FORMAT. The test passed. I'll need to poke at the webgl testcase to figure out where to look next. Does this test pass in Chromium? Does this driver support the EXT_packed_depth_stencil extension? Firefox only supports DEPTH_STENCIL buffers when the EXT_packed_depth_stencil or OES_packed_depth_stencil is supported (note that EXT_packed_depth_stencil is mandatory at least in OpenGL 3.1). So if Mesa doesn't support this extension, that would explain the failure, and that would be a Firefox bug (though likely a WONTFIX one). I believe that Chromium doesn't require EXT_packed_depth_stencil support. Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
Here's an update on the status of these failures. Scroll down to the part about program-test.html for the real news. i965 driver: Results: (8866 of 8879 passed) Failures: conformance/context/context-attributes-alpha-depth-stencil-antialias.html: 1 tests failed The part that was Firefox's bug should now be fixed in today's nightly build (2012-04-21): https://bugzilla.mozilla.org/show_bug.cgi?id=746296 But we'll still fail that test as long as Mesa returns MAX_SAMPLES 1 without actually doing MSAA. conformance/programs/program-test.html: 1 tests failed PASS linking should fail with in-use formerly good program, with new bad shader attached FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a valid program shouldn't generate a GL error This sounded like it was going to be a Mesa bug, but this testcase passes: This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue. Here is a small testcase that reproduces the issue for me on Mesa 7.11 (Ubuntu 11.10, r600g): http://people.mozilla.org/~bjacob/link-failure-should-leave-valid-program-intact.html Is it possible to run just a subtest? The way I debugged this is I did 'view source' (ctrl+U), searched for some message that got printed just before the error, which pointed me to the relevant part of the code. To reduce a testcase, check out the webgl repository so you can modify these tests locally: svn checkout https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl To run tests locally without running into the strict origin policy, either use a http server, like python -m SimpleHTTPServer or go to about:config and set security.fileuri.strict_origin_policy=false but that is a rather insecure thing to do (do it only on a dedicated test profile). conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed Create and attach depthStencil renderbuffer PASS depthStencilBuffer = gl.createRenderbuffer() is non-null. PASS getError was expected value: NO_ERROR : PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is width PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is height FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0. [ and 2 others of this sort ] I bet this will be our failure. We don't have test coverage for GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix. Cool, let me know. conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8 tests failed I'm not sure what code path this is. This was a bug in the test itself, which we fixed (the 1.0.1 tests are not finalized until multiple implementations pass them all, which is only starting to happen now). The bug was that this test assumed no color management. I bet your system is color-managed. Fixed. Now that multiple browsers/OSes/drivers pass all tests, it is likely that the conformance test suite will be officialized soon (maybe in a week or two). It would be great to be able to add Mesa and open-source drivers to the list of known-to-pass GL implementations. It seems that we're extremely close! Cheers, Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? The lying about MSAA came about from a last-minute oh crap, GL 3.0 guarantees GL_MAX_SAMPLES of 4, but we don't do MSAA. What do we do? We resolved to lie about GL_MAX_SAMPLES so that GL 3.0 applications would at least run even though they would render single-sampled, and add MSAA as soon as possible. Paul's been working on it, and he's got a prototype up and running. Mostly we're limited by how hard it is to write all the tests we need for msaa functionality. pgp7VyO1OA364.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Wed, 18 Apr 2012 15:43:07 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1? It returns the lie. pgpCRp8B2gGnI.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? -Jeff - Original Message - From: Benoit Jacob bja...@mozilla.com To: Eric Anholt e...@anholt.net, Jeff Gilbert jgilb...@mozilla.com Cc: mesa-dev@lists.freedesktop.org Sent: Tuesday, April 17, 2012 7:41:33 PM Subject: Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers 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. Thanks for that information. WebGL antialiasing relies in multisample renderbuffers (ARB_framebuffer_multisample), not on multisample GLX visuals. So GL_MAX_SAMPLES is really what we care about. If the value returned by Mesa for getIntegerv(GL_MAX_SAMPLES) can't be used to tell whether multisample renderbuffers are actually supported, then how can we determine that? Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1? -Jeff - Original Message - From: Eric Anholt e...@anholt.net To: Jeff Gilbert jgilb...@mozilla.com, Benoit Jacob bja...@mozilla.com Cc: mesa-dev@lists.freedesktop.org Sent: Wednesday, April 18, 2012 3:07:17 PM Subject: Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert jgilb...@mozilla.com wrote: It depends how much of the spec its in violation of. Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it with 0 or 1 sample(s). Per spec, this is not okay, since RENDERBUFFER_SAMPLES is guaranteed to be = the 'samples' value used at allocation, but at least 0 or 1 would reflect reality. However, since the spec requires that it gives at least what was requested, there's no reason the user should check the value afterwards, if all they care about is the minimum. I think the most spec-safe way to signal it would be to trigger GL_OUT_OF_MEMORY in response to requests for renderbuffers with samples1 of any size. This is at least theoretically plausible, since no amount of memory will give what was requested. This doesn't give a great indication of what happened, since the assumption will be that it's actually OOM, but seems technically compliant. At least this would give some indication something exceptional or unexpected is happening. It seems (at least for 3.3) that specification of what multisampled sampling requires is pretty minimally-defined, result-wise. If it's as 'up to the implementation' as it seems, it could technically 'multisample' by 'checking' the pixel in the same place N times, so long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives back the same center-of-pixel (0.5,0.5) location for each. This seems to be technically correct in the worst sort of way, but is checkable by the user, and doesn't appear to be otherwise-guaranteed. The spec is long though, so I am quite possibly missing something. Also, is there a bug open against Mesa for this? The lying about MSAA came about from a last-minute oh crap, GL 3.0 guarantees GL_MAX_SAMPLES of 4, but we don't do MSAA. What do we do? We resolved to lie about GL_MAX_SAMPLES so that GL 3.0 applications would at least run even though they would render single-sampled, and add MSAA as soon as possible. Paul's been working on it, and he's got a prototype up and running. Mostly we're limited by how hard it is to write all the tests we need for msaa functionality. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob bja...@mozilla.com
wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests fully
passing on multiple, real drivers, before we can claim that WebGL has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or 8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html: 1
tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false, alpha: false,
antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available? If it's looking for MSAA
visuals, we don't expose those and it would be webgl's problem. If it's
looking for msaa renderbuffers, we're lying about those and it's our
problem. But either way, we're working on exposing MSAA as a high
priority task currently.
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with new bad
shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest? It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I won't be
able to find where the failure was in the trace.
conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is
width
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is
height
FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0.
[ and 2 others of this sort ]
I bet this will be our failure. We don't have test coverage for
GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix.
conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8
tests failed
I'm not sure what code path this is.
---
text results summary:
WebGL Conformance Test Results
Version 1.0.1
---
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120417
Firefox/14.0a1
WebGL VENDOR: Mozilla
WebGL VERSION: WebGL 1.0
WebGL RENDERER: Mozilla
Unmasked VENDOR: undefined
Unmasked RENDERER: undefined
WebGL R/G/B/A/Depth/Stencil bits (default config): 8/8/8/8/24/0
---
Test Summary (8879 total tests):
Tests PASSED: 8866
Tests FAILED: 13
Tests TIMED OUT: 0
---
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html: 1
tests failed
conformance/programs/program-test.html: 1 tests failed
conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed
conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8 tests failed
---
Complete Test Results (total / pass / fail / timeout):
conformance/attribs/gl-enable-vertex-attrib.html: 3 / 3 / 0 / 0
conformance/attribs/gl-vertex-attrib-zero-issues.html: 14 / 14 / 0 / 0
conformance/attribs/gl-vertex-attrib.html: 515 / 515 / 0 / 0
conformance/attribs/gl-vertexattribpointer-offsets.html: 451 / 451 / 0 / 0
conformance/attribs/gl-vertexattribpointer.html: 782 / 782 / 0 / 0
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false, alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in the test: in
WebGL, anti-aliasing is a hint, not a requirement. We'll fix this very soon in
the WebGL conformance tests, but it's too late for the 1.0.1 version
unfortunately. Very unfortunate that we didn't catch this earlier.
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without editing the
pages. That's fairly easy though. Just svn checkout the test suite:
svn checkout https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your browser to
be lax with the same-origin policy. In Firefox, go to about:config and set
security.fileuri.strict_origin_policy=false. Alternatively, a better solution
is to run your own HTTP server, which is very simple: in the directory you want
to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I won't
be
able to find where the failure was in the trace.
So you could edit the testcase by running it locally as explained above; in
addition to triming it, you could insert dummy unusual GL calls as markers,
e.g. using webgl.polygonOffset().
conformance/renderbuffers/framebuffer-object-attachment.html: 3
tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_WIDTH) is width
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_HEIGHT) is height
FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0.
[ and 2 others of this sort ]
I bet this will be our failure. We don't have test coverage for
GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix.
Notice that Firefox implements WebGL DEPTH_STENCIL renderbuffer using OpenGL
DEPTH24_STENCIL8 renderbuffers. This isn't 100% universally supported, as in
theory
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too late
for the 1.0.1 version unfortunately. Very unfortunate that we didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is purely a
Firefox bug. What happens is that this test is checking that the actual context
attributes match reality. They should. Firefox's bug is that it's returning the
context creation attributes (which have antialias=true) instead of the actual
context attributes. Will fix. Nothing to be done or worry about on your end.
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your
browser to be lax with the same-origin policy. In Firefox, go to
about:config and set security.fileuri.strict_origin_policy=false.
Alternatively, a better solution is to run your own HTTP server,
which is very simple: in the directory you want to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I
won't
be
able to find where the failure was in the trace.
So you could edit the testcase by running it locally as explained
above; in addition to triming it, you could insert dummy unusual GL
calls as markers, e.g. using webgl.polygonOffset().
conformance/renderbuffers/framebuffer-object-attachment.html: 3
tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_WIDTH) is width
PASS
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message - Is it possible to run just a subtest? It would be nice to apitrace what's going on in this testcase, but if I run the whole test I won't be able to find where the failure was in the trace. apitrace/scripts/retracediff.py allows to run against a software renderer, and quickly spot what call the rendering diverges, but given that all available software renderers are based from Mesa, odds are many bugs will appear on both, so not that useful. One of these day's I'll add SSH support to retracediff.py, so that one can eaily compare the rendering against a remote machine (running, e.g., NVIDIA OpenGL), or even a different OS. Of course, this only works if both implementations support the functionality recorded in the trace. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that
WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests
on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your end.
Sorry for ping-ponging on this but looking closer into this, I'm not so sure
anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g driver.
So I'm wondering if this could actually be an issue with the Intel driver, or
with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
An APItrace of this test would give the answer.
Benoit
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program,
with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION :
drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this
testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source,
NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your
browser to be lax with the same-origin policy. In Firefox, go to
about:config and set security.fileuri.strict_origin_policy=false.
Alternatively, a better solution is to run your own HTTP server,
which is very simple: in the directory you want to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going on in this
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance
tests
fully
passing on multiple, real drivers, before we can claim that
WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests
on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important
fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is
non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation
attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your
end.
Sorry for ping-ponging on this but looking closer into this, I'm not
so sure anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g
driver.
So I'm wondering if this could actually be an issue with the Intel
driver, or with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
It just occurred to me that a 1 here really means no antialiasing, and we're
currently mis-interpreting it.
Filed Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=746296
Benoit
An APItrace of this test would give the answer.
Benoit
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program,
with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION :
drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this
testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source,
NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout
the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 12:41:21 -0700 (PDT), Jose Fonseca jfons...@vmware.com wrote: - Original Message - Is it possible to run just a subtest? It would be nice to apitrace what's going on in this testcase, but if I run the whole test I won't be able to find where the failure was in the trace. apitrace/scripts/retracediff.py allows to run against a software renderer, and quickly spot what call the rendering diverges, but given that all available software renderers are based from Mesa, odds are many bugs will appear on both, so not that useful. One of these day's I'll add SSH support to retracediff.py, so that one can eaily compare the rendering against a remote machine (running, e.g., NVIDIA OpenGL), or even a different OS. Of course, this only works if both implementations support the functionality recorded in the trace. The issue in question was that a GL_INVALID_OPERATION was thrown at a point that it shouldn't have been, so it wouldn't show up as rendering. Whacking the HTML sounds like a better way to isolate the failure. pgppq3Sqetkmz.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 12:53:12 -0700 (PDT), Benoit Jacob bja...@mozilla.com
wrote:
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your end.
Sorry for ping-ponging on this but looking closer into this, I'm not so sure
anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g driver.
So I'm wondering if this could actually be an issue with the Intel driver, or
with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
An APItrace of this test would give the answer.
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.
pgpvJRVIpms1M.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
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. Thanks for that information. WebGL antialiasing relies in multisample renderbuffers (ARB_framebuffer_multisample), not on multisample GLX visuals. So GL_MAX_SAMPLES is really what we care about. If the value returned by Mesa for getIntegerv(GL_MAX_SAMPLES) can't be used to tell whether multisample renderbuffers are actually supported, then how can we determine that? Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
