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.

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

> 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?

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?

 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?

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
Thank you.

--- 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