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
I added the google site to my apt sources, and installed the unstable chrome. The version installed was:
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.
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
> 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.
We also use "firefox-trunck + Mesa driver" to test this case, it also fails.
thanks for the information, we can reproduce this now.
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.
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?
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?
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();
var colorImage = gl.createTexture();
gl.texImage2D(gl.TEXTURE_2D, 0, RGB565, width, height, 0,
RGB, UNSIGNED_BYTE, null);
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,
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?
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
This html passes on latest mesa driver. I think it resolved at 8c56ff64
--- 8< ---
Author: Haixia Shi <email@example.com>
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
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.
Signed-off-by: Haixia Shi <firstname.lastname@example.org>
Reviewed-by: Chad Versace <email@example.com>
Reviewed-by: Jason Ekstrand <firstname.lastname@example.org>
Cc: Stéphane Marchesin <email@example.com>