Previously all 19 subtests passed, now only 17 or 18 (random) pass. This is with latest mesa, r300g driver (RV530), Firefox 9.0.1 https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/textures/texture-mips.html 5d67d4fbebb7c7d6582c4c92fc5cea4a8e6a60ab is the first bad commit commit 5d67d4fbebb7c7d6582c4c92fc5cea4a8e6a60ab Author: Brian Paul <brianp@vmware.com> Date: Wed Jan 4 13:30:35 2012 -0700 st/mesa: remove st_TexImage(), use core Mesa code instead The core Mesa code does the equivalent memory allocation, image mapping, storing and unmapping. We just need to call prep_teximage() first to handle the 'surface_based' stuff. The other change is to always use the level=0 mipmap image when accessing individual mipmap level images that are stored in resources/buffers. Apparently, we were always using malloc'd memory for individual mipmap images, not resource buffers, before. Signed-off-by: Brian Paul <brianp@vmware.com>
This regression can be also reproduced with llvmpipe, however you need to set webgl.force-enabled to true in about:config (Firefox doesn't enable webgl for llvmpipe by default).
I think this should get fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=696495 . My understanding is that the OpenGL spec is loose there, so for WebGL we tightened it, which means that the WebGL impl has to do extra work to pass the test suite on all valid OpenGL impls.
Erm, looking back at it, that looks more like a driver bug work-around. I may misremember.
*** Bug 48935 has been marked as a duplicate of this bug. ***
Forget comment 2, I dont have any idea of how to work around this driver bug, and it works in other drivers. Really hope for a driver fix here. This is the last WebGL 1.0.1 conformance test page failing with the r600g driver. It passes with the Intel driver on Mesa 8.0.
CC'ing Brian due to regressing changeset identified in comment 0.
Is it possible for you to make an apitrace of this issue? I don't have time to install/setup a WebGL browser ATM.
(In reply to comment #7) > Is it possible for you to make an apitrace of this issue? I don't have time to > install/setup a WebGL browser ATM. For what it's worth, you probably are using a WebGL browser right now: any recent (less than 15 months old) Firefox, Chromium/Chrome, Opera or Safari would work.
Firefox on my main machine is a bit old but I have a new enough Firefox in one of my Linux VMs so I'm doing some WebGL testing/fixing with that.
Created attachment 65392 [details] apitrace I'm not familiar with how to use apitrace, so I can only hope that this is useful to someone. $ ./build/apitrace trace --api gl /usr/bin/firefox https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/texture-mips.html $ glxinfo|grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD SUMO OpenGL version string: 2.1 Mesa 8.1-devel (git-6404095 precise-oibaf-ppa) OpenGL shading language version string: 1.30 OpenGL extensions: $ firefox --version Mozilla Firefox 14.0.1
When I run the test here using the svga driver or llvmpipe I get: """ conformance/textures/texture-mips.html (26 of 29 passed) failed: getError expected: INVALID_OPERATION. Was NO_ERROR : for generateMipmap with mip 0 is 0x0 failed: getError expected: INVALID_OPERATION. Was NO_ERROR : for generateMipmap with mip 0 is 0x0 failed: texture that is only using the smallest 2 mips should draw with green """ I have a patch that fixes the first two failures. Though, I haven't found any OpenGL spec language that indicates GL_INVALID_OPERATION should be generated in this case. It seems logical, but I haven't found any supporting documentation yet. After fixing that, I get two failures: """ failed: texture that is only using the smallest 2 mips should draw with green failed: texture that is only using smallest mips should draw with cyan """ Is this what you're getting with the r300g driver?
(In reply to comment #10) > Created attachment 65392 [details] > apitrace > > I'm not familiar with how to use apitrace, so I can only hope that this is > useful to someone. > > $ ./build/apitrace trace --api gl /usr/bin/firefox > https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/texture-mips.html Unfortunately, the trace doesn't contain anything useful.
(In reply to comment #10) > Created attachment 65392 [details] > apitrace > > I'm not familiar with how to use apitrace, so I can only hope that this is > useful to someone. This wasn't :-) To get something more useful: 1) Either ensure that you don't have any firefox process already running; or create a new profile (firefox -P -no-remote, click Create Profile...) and you can then run directly using that profile by selecting it from the command line: firefox -P mytestprofile -no-remote. The -no-remote prevents attaching to an existing firefox session, which is likely the problem you've run into. 2) On startup there are two firefox processes: the main one (which you want) and another one that just queries GL strings. This will give you two trace files, e.g. firefox.trace and firefox.1.trace. The bigger of the two is typically what you want. 3) if you already have .trace files in this directory, it's going to get confusing quickly.
Created attachment 65393 [details] new trace (In reply to comment #11) > After fixing that, I get two failures: > > """ > failed: texture that is only using the smallest 2 mips should draw with > green > failed: texture that is only using smallest mips should draw with cyan > """ > > Is this what you're getting with the r300g driver? Yeah, this is what I get with either r300g or llvmpipe.
Created attachment 65395 [details] apitrace I wondered if having firefox already open would mess it up! Oops! :) Hopefully this is more helpful! I'm working on figuring out how to do a build in a pbuilder environment so that I can build packages for my Ubuntu box from git rather than use the rather out of date PPA from Oibaf. $ ./build/apitrace trace --api gl /usr/bin/firefox -P test -no-remote https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/texture-mips.html $ glxinfo|grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD SUMO OpenGL version string: 2.1 Mesa 8.1-devel (git-6404095 precise-oibaf-ppa) OpenGL shading language version string: 1.30 OpenGL extensions: $ firefox --version Mozilla Firefox 14.0.1
Both Pavel's and Jason's apitraces are correctly recorded, show the GL calls corresponding to the WebGL test.
Looking at it in qapitrace, the problem seems to occur when a new base level is added which is consistent with the pre-existing smaller levels. Looks like st/mesa doesn't (correctly) merge the two parts in that case, and the pre-existing smaller levels end up with garbage.
Michel, I think you're right. I started digging into this a few weeks ago but haven't had time to get back to it. I think I'll need a couple hours of quality time to really get to the bottom of it and come up with a patch...
commit c2e37b1d2e1b8014475c7d2698fba317c9082d70 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Fri Oct 19 11:59:35 2012 +0200 st/mesa: Fix source miptree level for copying data to finalized miptree. Fixes WebGL texture mips conformance test, no piglit regressions.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.