1372181 - WebGL 2 conformance test conformance2/rendering/blitframebuffer-filter-outofbounds.html failures

Status: NEW

(Core :: Graphics: CanvasWebGL, enhancement, P2)

Description

[Jukka Jylänki]

Running

https://www.khronos.org/registry/webgl/sdk/tests/conformance2/rendering/blitframebuffer-filter-outofbounds.html?webglVersion=2&quiet=0

was tested to fail on
 - Apple Mac Mini (Late 2012) - Ubuntu 16.04 Xenial, Kernel 4.4.0-78-generic 64-bit - Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics 4000, Intel Mesa DRI Ivybridge Mobile, OpenGL 3.3 (Core Profile) Mesa 12.0.6
 - Apple Mac Pro (Late 2013) - OS X El Capitan 10.11.6 - Firefox 55.0a1 (2017-05-22) (64-bit) - AMD FirePro D500 4.1 ATI-1.42.15
 - Apple MacBook Pro 13" 2016 - macOS Sierra 10.12.3 - Firefox Nightly 55.0a1 (2017-05-21) (64-bit) - Intel Iris Graphics 550 1536 MB 4.1 INTEL-10.22.29
 - Google Pixel XL - Android 7.1.2, Kernel 3.18.31-g416bf43 (marlin N2G47O), Fennec 55.0a1 (2017-05-19) - Qualcomm Adreno 530, OpenGL ES 3.2 V@145.0 (GIT@Idb2b4cb785)

to error messages like
failed: pixel at [1, 1] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [2, 1] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [3, 1] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [1, 2] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [1, 3] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [7, 7] should be (0,0,0,0), but the actual color is (32,32,32,255)
failed: pixel at [2, 2] should be (0,0,0,0), but the actual color is (32,32,32,255)

The test passed on
 - HP Notebook 14-am009no 14" - Windows 10 Home - Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics (Intel HD 400?) Direct3D 11, 20.19.15.4509 9-1-2016, OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
 - Haswell - Windows 10 Home 64-bit - Firefox 55.0a1 (2017-05-22) (64-bit) - 2x ASUS NVidia GeForce GTX 1080 Ti Direct3D 11, v22.21.13.8189 (4-19-2017), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
 - Intel NUC6i7KYB Skull Canyon - Windows 10 Pro 10.0.14393 64-bit, Firefox 55.0a1 (2017-05-22) (64-bit) - Intel Iris Pro Graphics 580, 21.20.16.4534 (10-7-2016), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
 - Supermicro X10DAX 1.02 - Linux Mint 18 Sarah, Kernel 4.4.0-36-generic 64-bit, Firefox 55.0a1 (2017-05-22) (64-bit) - ASUS GeForce GTX 1060 OpenGL 3.2.0, NVIDIA 370.28
 - Microsoft Surface Pro 2 - Windows 10 Pro, Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics 4400 Direct3D11 v20.19.15.4331 (11-18-2015), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
 - Samsung Galaxy S7 Edge SM-G935F - Android 7.0, Kernel 3.18.14-11104523 (NRD90M), Fennec 55.0a1 (2017-05-19), ARM Mali-T880, OpenGL ES 3.2 v1.r12p1-03dev0.228ab63cced004f840e7dd47b762a1d0
 - Huawei P10 Plus - Android 7.0, Kernel 4.1.18-gfd75bbb (VKY-L29), Fennec 55.0a1 (2017-05-19) - ARM Mali-G71, OpenGL ES 3.2 v1.r2p0-02dev0.f7269486f3e0e3b308edf85872e361f4

Comment 1

[Kelsey Gilbert [:jgilbert]]

Spec:

For any source pixel lying outside the read framebuffer, the corresponding destination pixel remains untouched.

I don't think this is actually implementable...

I'm tempted to try making OOB reads here an INVALID_OP and see if we get any compat bugs.