Bug 94345 - WebGL conformance2/reading/read-pixels-from-fbo-test.html fails
Summary: WebGL conformance2/reading/read-pixels-from-fbo-test.html fails
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-01 08:20 UTC by xinghua
Modified: 2016-09-02 08:25 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description xinghua 2016-03-01 08:20:23 UTC
Steps:
1. Install latest unstable google chrome, details:
   add "deb http://dl.google.com/linux/chrome/deb/ stable main" to your computer software source list(/etc/apt/sources.list).
   sudo apt-get update
   sudo apt-get install google-chrome-unstable

2. Run chrome in the terminal, you can specify your Mesa driver and run with some options,
   [LD_LIBRARY_PATH=<mesa_lib>:$LD_LIBRARY_PATH LIBGL_DRIVERS_PATH=<mesa_lib>/dri] google-chrome-unstable --enable-unsafe-es3-apis -- use-gl=egl

3. Please check chrome revision ("chrome://version"), it must be newer than #376886

4. Open the link, https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?version=2.0.0 (should be 2.0.0(beta))

5. Search case "conformance2/reading/read-pixels-from-fbo-test.html", and run this case.

Result: This case will fail. This case succeeds on nvidia driver.

Expected: This case passes on Mesa driver. 

Notes: We test the case on below devices based on mesa driver, it also fails.
Pixel 2013 - IVB Chromebook, Mesa version 11.0.2
Acer C720 - HSW Chromebook, Mesa version 11.0.2
Acer C910 - BDW Chromebook, Mesa version 11.0.2
Comment 1 Mark Janes 2016-03-01 17:38:35 UTC
I added the google site to my apt sources, and installed the unstable chrome.  The version installed was:

google-chrome-unstable (50.0.2657.0-1)

Checking chrome://version, I get 376886, which is less than I expected based on the repro steps.

Attempting to open the v2.0.0 conformance tests, I get "This browser does not appear to support the selected version of WebGL".

Please tell me what I am doing wrong.
Comment 2 xinghua 2016-03-02 01:57:12 UTC
Hi, Mark,
The OpenGL version or OpenGL ES version must be higher than 4.2 or 3.0 respectively to support WebGL2.0.0 test cases.
Get latest Mesa driver and build it, we found that OpenGL version is only 3.3. So should use OpenGL ES path, the option "--use-gl=egl" is used to specify this path.

In step2, there is a redundant blank of "-- use-gl=egl", please remove it to start the chrome.
[LD_LIBRARY_PATH=<mesa_lib>:$LD_LIBRARY_PATH LIBGL_DRIVERS_PATH=<mesa_lib>/dri] google-chrome-unstable --enable-unsafe-es3-apis --use-gl=egl
Comment 3 Yang Gu 2016-03-02 02:36:34 UTC
> Checking chrome://version, I get 376886, which is less than I expected based
> on the repro steps.

#376886 is the latest version we can get now. With this version, we can repro the bug.
Comment 4 xinghua 2016-03-02 02:42:47 UTC
We also use "firefox-trunck + Mesa driver" to test this case, it also fails.
Comment 5 Mark Janes 2016-03-02 21:27:03 UTC
thanks for the information, we can reproduce this now.
Comment 6 Kenneth Graunke 2016-03-03 01:42:40 UTC
I think there may be a bug in the test.

The (RGB5_A1, RGBA, UNSIGNED_BYTE) case is giving this:
FAIL Expected color = 127.5,0,178.5,255, was = 123,0,173,255

The first suspicious aspect is that these are 8-bit UNORM values, which are supposed to be integers between 0 and 255.  But it's expecting 127.5 and 178.5...which are not integers.

Reading the test, denormalizeColor() has a tolerance of 5 (tol = 5) for this case.  178.5 vs 173 would pass with a tolerance of 6.  In other cases (unsigned short/int) it raises the tolerance to 40 to allow NVIDIA to pass.  Also, with a 5-bit source value, being off by 1 results in a delta of 8.  I think the tolerance should be raised.
Comment 7 Yang Gu 2016-03-07 15:15:03 UTC
I don't have too much background on gfx driver, so please correct me if my understanding is wrong.
In following description, let's just take the case you mentioned as example. This case is to map RGB5_A1 format (write) to RBGA format (read). The value of B is 0.7, and the output of Intel driver is 173, while it's 181 for NVidia driver.
First, I don't think a float number used as expection has problem, as it always comes together with a tolerance value. In this case, any value in input may map to output with 8 different values. For example, 0 in 5-bit format might map to [0, 7] in 8 bit format, and we can simply write the expection+torlence as 3.5+3.5, which can cover the range well in a convenient way.
Then let's just try to get ideal result with math calculation. 0.7*31=21.7, so the value of B should be 22 in 5-bit format. If we map 22 in 5-bit format to 8-bit format representation, we can get the range [176, 183], and the result from NVidia driver falls into this range. To be precise, 21.7*8=173.6, and NVidia's result is very close. 
Could you please give me more details why Intel driver reports 173 (Note that 21 maps to [168, 175])? 
Will 0.7 be converted by driver to 22 first, then be fed to hardware? Or driver can simply feed hardware with 0.7?
Anyway, I think Intel driver doesn't match the ideal expectation well. Can we do some changes?
Comment 8 xinghua 2016-06-28 10:05:20 UTC
Mark,
Please help to re-check these issue.
Kenneth Graunke had advised us to raise the tolerance value(The value is 5 now), and I tried to raise the tolerance value( raise it to 10). I also found it works correctly on Mesa 12.1.0 without raising the tolerance value.
But there are still other two cases failed in this html file. The root casue is, when calling
gl.getParameter(gl.IMPLEMENTATION_COLOR_READ_FORMAT) return GL_BGR(or GL_BGR_EXT),
gl.getParameter(gl.IMPLEMENTATION_COLOR_READ_TYPE) return GL_UNSIGNED_SHORT_5_6_5_REV,

I had checked GL_BGR enum, it only exists on GL context, does not exist GLES context. Why Mesa return GL_BGR type when my context is GLES context?
Comment 9 xinghua 2016-07-27 08:57:24 UTC
 Hi, Kenneth, please help to re-check this case, if this is not mesa issue, assign it to me again. Thank you.
 There is only one issue in this case now, test case is as below,

  var fbo = gl.createFramebuffer();
  gl.bindFramebuffer(gl.FRAMEBUFFER, fbo);
  var colorImage = gl.createTexture();
  gl.bindTexture(gl.TEXTURE_2D, colorImage);
  gl.texImage2D(gl.TEXTURE_2D, 0, RGB565, width, height, 0,
                RGB, UNSIGNED_BYTE, null);
  gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,
                          gl.TEXTURE_2D, colorImage, 0);
  var implFormat = gl.getParameter(gl.IMPLEMENTATION_COLOR_READ_FORMAT);
  var implType = gl.getParameter(gl.IMPLEMENTATION_COLOR_READ_TYPE);

Start chrome with --use-gl=egl, so it creates a OpenGL ES context, but return values of implFormat and implType are,
implFormat: GL_BGR
implType: GL_UNSIGNED_SHORT_5_6_5_REV
According to es_3.0/3.1_spec, ES context did not support these format/type, it only exists in OpenGL context. Does mesa confuse these format/type between OpenGL and OpenGL ES?
Comment 10 Tapani Pälli 2016-09-02 07:47:46 UTC
this test is passing for me with current Mesa master (at ea7b475) when testing on HSW and chrome-unstable google-chrome-unstable-54.0.2840.6-1.x86_64
Comment 11 xinghua 2016-09-02 08:22:03 UTC
This html passes on latest mesa driver. I think it resolved at 8c56ff64
Thank you.
Comment 12 Tapani Pälli 2016-09-02 08:25:17 UTC
--- 8< ---

commit 8c56ff643b1d6d18d81d82a4d23103a1cd51500a
Author: Haixia Shi <hshi@chromium.org>
Date:   Fri Aug 12 15:34:09 2016 -0700

    mesa: change state query return value for RGB565
    
    The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
    OpenGL ES 3.2 (or earlier) specification, and there are no known extensions
    in the Khronos registry that would add these enums as valid responses for
    glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE) and
    glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_FORMAT) queries.
    
    Note that this patch does not change the bit layout returned by the query. As
    defined by the GL spec, the bit layout of GL_RGB + GL_UNSIGNED_SHORT_5_6_5 and
    GL_BGR + GL_UNSIGNED_SHORT_5_6_5_REV are identical.
    
    TEST=dEQP-GLES3.functional.state_query.integers.*
    
    Signed-off-by: Haixia Shi <hshi@chromium.org>
    Reviewed-by: Chad Versace <chadversary@chromium.org>
    Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
    Cc: Stéphane Marchesin <marcheu@chromium.org>
    Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6


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.