On which GPU types does this happen? Can you provide about:gpu from an affected system?

Is this a difference in behavior between some versions of desktop GL and GLES? The GL 4.5 spec (section 18.3.1, "Blitting Pixel Rectangles", p. 512) has the same text.

I saw that on almost all Mac GPUs.

The spec behavior is consistent in this area across multiple GL and GLES versions, so it is simply Mac doesn't obey the spec.

Thanks for the information. How difficult do we think it will be to emulate this behavior? It could require transforming one BlitFramebuffer call into 9 as far as I can tell.

We could use draw to emulate blitframebuffer, which should honor this clamp to edge behavior.  We probably will need an extra step to blit to a texture if the source is renderbuffer. (and yunchao is already putting in the structure for the draw emulation)

These two day, I took a deep look into this issue, found that it is Linux (and Windows ) have the issue. But MacOS almost has correct behavior for this feature. In addition, both native deqp and webgl deqp have wrong expectation against this feature. Linux and Windows implementations obey to the deqp test, but the test itself is wrong. So these implementations about this feature are wrong.

You can run these deqp tests deqp/functional/gles3/framebufferblit/default_framebuffer_*.html (say default_framebuffer_06.html) in MacOSX, it will clamp_to_edge when the pixels are out-of-bounds. But the ref pixel draw nothing for out-of-bounds pixels. So the test tell us that these out-of-bounds cases fail on MacOSX. 
If you run this test in Linux, both the rendering result and the ref pixels don't clamp to edge for out-of-bounds pixels. So the test is thought to be passed on Linux. You can show the rendering image and the ref image for default_framebuffer_06.html by remove the 'if' at https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/deqp/framework/common/tcuImageCompare.js#L723. 

In my oponion, it is that the ref pixel itself is wrong. So I compare the code in webgl deqp with that in native deqp, the native deqp is wrong too. 

Let's take a look into code how the ref pixels is rendered by CPU: it will intersect the src region with the read buffer bounds before rendering, so it never handle pixels out-of-bounds.
webgl deqp: https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/deqp/framework/opengl/simplereference/sglrReferenceContext.js#L3887. 
native deqp: https://android.googlesource.com/platform/external/deqp/+/deqp-dev/framework/opengl/simplereference/sglrReferenceContext.cpp#3152 

So, in my oponion, the test itself is wrong. And the implementations in Linux/Windows are wrong too. Both of them conflicts with GLES/OGL spec. 
 
In MacOSX, it also have some issue: if the width/height of src region is different from the width/width of dst region (filtering is a must during bliting), it can blit the out-of-bounds pixels correctly. Otherwise, it may do some optimization under the hood when src and dst region has the same width/height, the rendering result is wrong (at least on Mac Intel). See this test case: https://github.com/KhronosGroup/WebGL/pull/2065

Now that the test itself has issue, and the native deqp test has issues too. And they conflict with GLES/OGL spec. It is not easy to fix them in a short time. I'd like to add them into skip list: https://github.com/KhronosGroup/WebGL/pull/2066. 

Please correct me if I am wrong.

as @zmo said at #3, the spec behavior is consistent in this area across multiple GL and GLES versions. 

Attach one 'failed case' on MacOSX. But I think the result is correct, while the ref image is wrong. It blits from [-10, -15, 100, 63] to [53, 29, 136, 144]. 

You can see that the result clamped the out-of-bounds pixels to edge, while the ref image doesn't. 

Deleted: Screen Shot 2016-09-27 at 23.21.35.png 129 KB

	Screen Shot 2016-09-27 at 23.21.35.png 129 KB View Download

The spec is quite clear, and from the results, it does look like the ref image is incorrect.

This is rather unfortunate.

kbr, can you contact the deqp folks and see what they have to say about this?

I ran in the same issue a couple hours ago: the spec is a bit unclear bit I interpret it like this:
 - Because texels are located at 0.5 coordinates related to the rectangles given in argument to blitFramebuffer, filtering with GL_LINEAR might have to sample texels outside of the source rectangle. If that causes sampling outside of the framebuffer, than clamping is done.
 - The spec says "The actual region taken from the read framebuffer is limited to the intersection of the source buffers being transferred" which combined with "The command transfers a rectangle of pixel values from one region of the read framebuffer to another in the draw framebuffer." Can be interpreted as doing the blit only where the sample point is not outside of the source framebuffer.

I would be very surprised if dEQP had such an obvious bug.

For a fix, take a look at the fragment shader in https://chromium-review.googlesource.com/c/389853/ where we discard if the texcoord are out of bounds.

Also can you test your workaround by enabling it all the time and not only for SRGB, and running the relevant tests? I think it will be failing the blit.rect.nearest_consistency tests. The fix is to use a single triangle in the vertex shader.

The ES 3.04 Spec says (page 198): "If a linear filter is selected and the rules of LINEAR sampling (see section 3.8.10) would require sampling outside the bounds of a source buffer, it is as though CLAMP_TO_EDGE texture sampling were being performed. If a linear filter is selected and sampling would be required outside the bounds of the specified source region, but within the bounds of a source buffer, the implementation may choose to clamp while sampling or not."

This is quite clear what should happen and it seems to me Mac driver behavior is correct.

Yunchao: thanks for your analysis of this problem. I've emailed the dEQP authors and will update this bug with their feedback (unless they update it directly).

My understanding of the spec is the same as Mo's. I think the spec text:

"The actual region taken from the read framebuffer is limited to the intersection of the source buffers being transferred"

is handling the case where there are multiple draw buffers attached to the framebuffer of different sizes.

The behavior where the blit would sample values outside the range of the source buffer seems well defined per #12. There is still an ambiguity about the case where sampling would have to occur outside the range of the source region, and that is still in the bounds of the source buffer:

"If a linear filter is selected and sampling would be required outside the bounds of the specified source region, but within the bounds of a source buffer, the implementation may choose to clamp while sampling or not."

Not sure whether the tests are exercising this case.

Per reply from phaulos@google.com:

https://cvs.khronos.org/bugzilla/show_bug.cgi?id=3576

TL;DR the language was deemed to be ambiguous, and we voted on whether blit rectangle is first clipped to both source and destination framebuffers or not, and chose clipping option. dEQP tests and all current mobile GPUs conform to that decision. However, it appears that the spec language hasn't been updated and the bug remains open over 2 years later...

Yunchao, it seems to me we could easily work around any drivers that doesn't conform to this.  We can always clip the src/dst coordinates first.  Just need to be careful to always to the same clipping on both side (scale factor considered)

Thanks zmo@ for following up and to phaulos@ for the clarification.

Since it sounds like most native ES 3.0 implementations follow the dEQP's rules, I agree that the best thing to do would be to change Chrome's emulation of this call so that it discards pixels outside the source read buffer rather than enforcing the CLAMP_TO_EDGE behavior. It sounds like this would make the existing tests pass on all platforms.

Thanks for your following up, zmo@ and kbr@ and all. I will update BlitFramebuffer in Command buffer to emulate this feature, in order to discards pixels outside the read buffer instead of clamp_to_edge. 

What about the NEAREST filter? I added some tests to cover NEAREST filter against pixels lying out-of-bounds: https://github.com/KhronosGroup/WebGL/pull/2065. You can try it on Linux/Mac/Windows, I suppose that different OSes and/or GPU vendor may differ for NEAREST filter too (I am at home currently, can not test it on many devices. And it is mid-night at my side...)

I think the same clipping rules should apply for BlitFramebuffer calls using both the NEAREST and LINEAR filters. Can you see whether a rule like that passes the affected out-of-bounds dEQP tests?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da6af8ed7e3bf178abb356fc4c20502400c50469

commit da6af8ed7e3bf178abb356fc4c20502400c50469
Author: qiankun.miao <qiankun.miao@intel.com>
Date: Sun Oct 02 01:29:14 2016

Roll WebGL 1ded271..79ef088

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/1ded271..79ef088

BUG=644740,  650213 

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2390453002
Cr-Commit-Position: refs/heads/master@{#422337}

[modify] https://crrev.com/da6af8ed7e3bf178abb356fc4c20502400c50469/DEPS
[modify] https://crrev.com/da6af8ed7e3bf178abb356fc4c20502400c50469/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93f310271173a3d140d8820779610e8a756833ed

commit 93f310271173a3d140d8820779610e8a756833ed
Author: yunchao.he <yunchao.he@intel.com>
Date: Wed Oct 05 17:13:36 2016

suppress webgl2 expectation

BUG=644740
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2394803002
Cr-Commit-Position: refs/heads/master@{#423199}

[modify] https://crrev.com/93f310271173a3d140d8820779610e8a756833ed/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/917d6fa4999f072fd690d7c1ff6bed67f6367431

commit 917d6fa4999f072fd690d7c1ff6bed67f6367431
Author: yunchao.he <yunchao.he@intel.com>
Date: Tue Oct 11 16:49:05 2016

Roll WebGL a5f3d8b..1db74f6

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/a5f3d8b..1db74f6

BUG=644740

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2407123002
Cr-Commit-Position: refs/heads/master@{#424458}

[modify] https://crrev.com/917d6fa4999f072fd690d7c1ff6bed67f6367431/DEPS
[modify] https://crrev.com/917d6fa4999f072fd690d7c1ff6bed67f6367431/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6c1222980a7ed3761601d4a5455fa366eb134f6

commit b6c1222980a7ed3761601d4a5455fa366eb134f6
Author: yunchao.he <yunchao.he@intel.com>
Date: Wed Oct 19 12:07:00 2016

[Command buffer] Fix the bug when blitting pixels outside read framebuffer.
All related failures in deqp/ and conformance2/ can be fixed by this change.

BUG=644740

TEST=deqp/functional/gles3/framebufferblit/default_framebuffer_*.html,
      conformance2/rendering/blitframebuffer_filter_outofbounds.html,
     deqp/functional/gels3/framebufferblit/rect_02.html

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://chromiumcodereview.appspot.com/2409523002
Cr-Commit-Position: refs/heads/master@{#426155}

[modify] https://crrev.com/b6c1222980a7ed3761601d4a5455fa366eb134f6/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/b6c1222980a7ed3761601d4a5455fa366eb134f6/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/b6c1222980a7ed3761601d4a5455fa366eb134f6/gpu/command_buffer/service/gles2_cmd_decoder_unittest_framebuffers.cc
[modify] https://crrev.com/b6c1222980a7ed3761601d4a5455fa366eb134f6/gpu/config/gpu_driver_bug_list_json.cc
[modify] https://crrev.com/b6c1222980a7ed3761601d4a5455fa366eb134f6/gpu/config/gpu_driver_bug_workaround_type.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/216b32f465701e2c0b064c4993d501902c235904

commit 216b32f465701e2c0b064c4993d501902c235904
Author: geofflang <geofflang@chromium.org>
Date: Thu Oct 20 04:11:11 2016

Update WebGL 2 expectations for blit framebuffer on Linux/AMD.

The blitframebuffer-filter-outofbounds.html test has been failing (or was
added in) this WebGL roll: https://codereview.chromium.org/2407123002

TBR=zmo@chromium.org

BUG=644740
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://chromiumcodereview.appspot.com/2436653004
Cr-Commit-Position: refs/heads/master@{#426399}

[modify] https://crrev.com/216b32f465701e2c0b064c4993d501902c235904/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8b35131cc20dddd3b7d1260fea7f221b8c1c6035

commit 8b35131cc20dddd3b7d1260fea7f221b8c1c6035
Author: yunchao.he <yunchao.he@intel.com>
Date: Fri Oct 21 01:39:10 2016

Roll WebGL 4e6c509..b1aed3a

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/4e6c509..b1aed3a

BUG=644740

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://chromiumcodereview.appspot.com/2433293002
Cr-Commit-Position: refs/heads/master@{#426683}

[modify] https://crrev.com/8b35131cc20dddd3b7d1260fea7f221b8c1c6035/DEPS
[modify] https://crrev.com/8b35131cc20dddd3b7d1260fea7f221b8c1c6035/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/8b35131cc20dddd3b7d1260fea7f221b8c1c6035/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93f310271173a3d140d8820779610e8a756833ed

commit 93f310271173a3d140d8820779610e8a756833ed
Author: yunchao.he <yunchao.he@intel.com>
Date: Wed Oct 05 17:13:36 2016

suppress webgl2 expectation

BUG=644740
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2394803002
Cr-Commit-Position: refs/heads/master@{#423199}

[modify] https://crrev.com/93f310271173a3d140d8820779610e8a756833ed/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

[Automated comment] removing mislabelled merge-merged-2840

Move to WebGL conformance 2.0.1

Going to fix this in ANGLE, will re-assign after I'm done.

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/096fd623292260b3372a1ab35695cffb4a61fb57

commit 096fd623292260b3372a1ab35695cffb4a61fb57
Author: Jamie Madill <jmadill@chromium.org>
Date: Tue Sep 12 23:12:03 2017

Fix out-of-bounds reads in BlitFramebuffer.

This was a missing part of the validation. Makes us pass the WebGL
test conformance2/rendering/blitframebuffer-outside-readbuffer.

Was necessary for lazy robust resource init.

BUG= angleproject:2107 
BUG=chromium:644740

Change-Id: I54c50012fc09ec80a65a2e75f5bde05101c8a1a7
Reviewed-on: https://chromium-review.googlesource.com/663212
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>

[modify] https://crrev.com/096fd623292260b3372a1ab35695cffb4a61fb57/src/libANGLE/renderer/d3d/d3d11/Renderer11.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/11b54cadcd04ea3b5650839abff6a6060d63e978

commit 11b54cadcd04ea3b5650839abff6a6060d63e978
Author: Corentin Wallez <cwallez@chromium.org>
Date: Wed Sep 13 20:59:56 2017

Roll ANGLE 9df395c..715e7f1

https://chromium.googlesource.com/angle/angle.git/+log/9df395c..715e7f1

BUG=chromium:644740

TBR=geofflang@chromium.org

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Change-Id: Iaf95afa992cf7a9f32743847a23f220fd786814e
Reviewed-on: https://chromium-review.googlesource.com/665168
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501747}
[modify] https://crrev.com/11b54cadcd04ea3b5650839abff6a6060d63e978/DEPS

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e576154ffac06ecc3ee25cc7c383cfaca31aafbd

commit e576154ffac06ecc3ee25cc7c383cfaca31aafbd
Author: Kai Ninomiya <kainino@chromium.org>
Date: Sat Sep 16 04:06:43 2017

Fix adjust_src_dst_region_for_blitframebuffer for depth-only framebuffers

Bug: 731877, 644740
Test: conformance2/renderbuffers/multisampled-depth-renderbuffer-initialization.html
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I37f09a2bdbe4466cadd640abf76cacedaf364f31
Reviewed-on: https://chromium-review.googlesource.com/668568
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502486}
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/framebuffer_manager.cc
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/framebuffer_manager.h
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/gles2_cmd_decoder.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a5f88b7e35a567c40e25e21b285ec7e8c687e6d6

commit a5f88b7e35a567c40e25e21b285ec7e8c687e6d6
Author: James Darpinian <jdarpinian@chromium.org>
Date: Mon Nov 12 23:09:19 2018

Cleaning up WebGL test failure expectations.

Many of these are leftover failure expectations from fixed bugs.
Some were fixed on some platforms but not others. There are some
new failures that were hidden by previous broad suppressions. Also
some tests are only failing because we haven't updated the drivers
on the bots (http://crbug.com/887241).

Bug:  757097 ,  838133 ,  672380 , 625738,  angleproject:2325 
Bug:  534697 , 849572, 625738, 703779,  angleproject:2142 
Bug: 757098, 644740, 705865, 602688,  angleproject:2103 
Bug: 903903,  740769 , 662644,  680720 ,  angleproject:1932 
Bug:  709874 , 887241,  625365 , angleproject:2952
Change-Id: I4e39e5a09d31d788d8a8615ad06d1ec88f064f00
Reviewed-on: https://chromium-review.googlesource.com/c/1325197
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607367}
[modify] https://crrev.com/a5f88b7e35a567c40e25e21b285ec7e8c687e6d6/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/a5f88b7e35a567c40e25e21b285ec7e8c687e6d6/content/test/gpu/gpu_tests/webgl_conformance_expectations.py
[modify] https://crrev.com/a5f88b7e35a567c40e25e21b285ec7e8c687e6d6/content/test/gpu/gpu_tests/webgl_conformance_expectations_unittest.py

Yunchao: there is still a suppression for conformance2/rendering/blitframebuffer-outside-readbuffer.html in src/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py for Linux / Intel with ANGLE's OpenGL backend. Would you please investigate and fix it? Thanks.