Bug 44912 - [bisected] WebGL conformance/textures/texture-mips tests fails
[bisected] WebGL conformance/textures/texture-mips tests fails
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Mesa core
git
Other All
: medium normal
Assigned To: mesa-dev
https://cvs.khronos.org/svn/repos/reg...
: regression
: 48935 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-18 12:42 UTC by Pavel Ondračka
Modified: 2012-10-19 16:07 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
apitrace (40.87 KB, application/octet-stream)
2012-08-10 16:01 UTC, Jason Wood
Details
new trace (56.46 KB, application/octet-stream)
2012-08-10 17:15 UTC, Pavel Ondračka
Details
apitrace (56.85 KB, application/octet-stream)
2012-08-10 18:01 UTC, Jason Wood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2012-01-18 12:42:30 UTC
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>
Comment 1 Pavel Ondračka 2012-01-23 08:40:47 UTC
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).
Comment 2 Benoit Jacob 2012-01-23 08:54:45 UTC
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.
Comment 3 Benoit Jacob 2012-01-23 08:59:41 UTC
Erm, looking back at it, that looks more like a driver bug work-around. I may misremember.
Comment 4 Andreas Boll 2012-08-08 15:35:58 UTC
*** Bug 48935 has been marked as a duplicate of this bug. ***
Comment 5 Benoit Jacob 2012-08-09 02:48:31 UTC
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.
Comment 6 Benoit Jacob 2012-08-09 14:33:58 UTC
CC'ing Brian due to regressing changeset identified in comment 0.
Comment 7 Brian Paul 2012-08-09 15:12:44 UTC
Is it possible for you to make an apitrace of this issue?  I don't have time to install/setup a WebGL browser ATM.
Comment 8 Benoit Jacob 2012-08-10 15:13:28 UTC
(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.
Comment 9 Brian Paul 2012-08-10 15:28:11 UTC
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.
Comment 10 Jason Wood 2012-08-10 16:01:15 UTC
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
Comment 11 Brian Paul 2012-08-10 16:38:51 UTC
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?
Comment 12 Brian Paul 2012-08-10 16:40:20 UTC
(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.
Comment 13 Benoit Jacob 2012-08-10 16:45:22 UTC
(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.
Comment 14 Pavel Ondračka 2012-08-10 17:15:37 UTC
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.
Comment 15 Jason Wood 2012-08-10 18:01:03 UTC
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
Comment 16 Benoit Jacob 2012-08-10 21:52:09 UTC
Both Pavel's and Jason's apitraces are correctly recorded, show the GL calls corresponding to the WebGL test.
Comment 17 Michel Dänzer 2012-09-03 15:36:29 UTC
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.
Comment 18 Brian Paul 2012-09-04 18:45:48 UTC
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...
Comment 19 Michel Dänzer 2012-10-19 16:07:35 UTC
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.