[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should be untouched

[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should be untouched

BUG=636987, 631934
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

Committed: https://crrev.com/4f4547bc67a3ef3cb41208606885fb236e964f7b
Cr-Commit-Position: refs/heads/master@{#412271}

[yunchao, 2016-08-10 16:14:38]

Description was changed from

==========
[Command buffer] Copying pixels out of bound read framebuffer should be
initialized to 0

BUG=
==========

to

==========
[Command buffer] Copying pixels out of bound read framebuffer should be
initialized to 0

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

[yunchao, 2016-08-10 16:15:10]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-10 16:15:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-10 16:35:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-10 16:35:35]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[yunchao, 2016-08-11 15:21:38]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-11 15:22:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[yunchao, 2016-08-11 15:23:26]

Description was changed from

==========
[Command buffer] Copying pixels out of bound read framebuffer should be
initialized to 0

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

to

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be initialized to 0

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

[yunchao, 2016-08-11 16:07:42]

Description was changed from

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be initialized to 0

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

to

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be initialized to 0

BUG=636987, 631934
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
==========

[yunchao, 2016-08-11 16:07:42]

yunchao.he@intel.com changed reviewers:
+ kbr@chromium.org, piman@chromium.org, qiankun.miao@intel.com, zmo@chromium.org

[yunchao, 2016-08-11 16:10:54]

PTAL. Thanks!

The conformance test is almost ready by Yizhou, but we need to improve it a
little. Will send it to review soon. 

I have verified this CL against the conformance test locally.

[Zhenyao Mo, 2016-08-11 16:35:21]

On 2016/08/11 16:10:54, yunchao wrote:
> PTAL. Thanks!
> 
> The conformance test is almost ready by Yizhou, but we need to improve it a
> little. Will send it to review soon. 
> 
> I have verified this CL against the conformance test locally.

I am out of office until next Monday.  piman, can you review this?

[commit-bot: I haz the power, 2016-08-11 16:43:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-11 16:43:47]

Dry run: This issue passed the CQ dry run.

[Ken Russell (switch to Gerrit), 2016-08-11 18:09:44]

Thanks for writing the test for this and for this patch. A couple of questions.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13308: if
(!EnsureGPUMemoryAvailable(pixels_size)) {
I don't think this call is necessary. The texture's storage is already
allocated. This is just a (Copy)TexSubImage3D call, not a TexImage3D call which
would perform allocation.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13317: width, height, 1, format,
type, zero.get());
This sort of manual zeroing of the pixels that are outside the framebuffer isn't
done in DoCopyTexSubImage2D, for example -- what's the essential difference
between the 2D and 3D cases? Why doesn't the usual texture clearing code handle
this case?

[piman, 2016-08-11 18:16:31]

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13294: if (!format || !type) {
This shouldn't happen, the internal_format was selected previously with either a
TexImage3D, or a TexStorage3D.
For TexStorage3D it's always a sized internal format, so no problem.
For TexImage3D we validated that the internal format, if unsized, is a valid one
that corresponds to a valid format/type pair.

So maybe replace with a DCHECK?

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13308: if
(!EnsureGPUMemoryAvailable(pixels_size)) {
I don't think this is needed - we're not allocating new GPU memory, only writing
it.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13325: height);
We want to adjust xoffset/yoffset/width/height to copyX/Y/Width/Height here if
we have to clip. The pixels read outside the framebuffer are undefined - not
necessarily unwritten to the destination - so even if we clear them above, we
may end up with undefined values overwriting the 0's.

Note that we need to do that independently of whether the texture needed to be
cleared.

[piman, 2016-08-11 18:33:16]

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13317: width, height, 1, format,
type, zero.get());
On 2016/08/11 18:09:44, Ken Russell wrote:
> This sort of manual zeroing of the pixels that are outside the framebuffer
isn't
> done in DoCopyTexSubImage2D, for example -- what's the essential difference
> between the 2D and 3D cases? Why doesn't the usual texture clearing code
handle
> this case?

The 2D clearing code can deal with tracking partially filled textures, whereas
it doesn't for 3D.

That being said, it is true that we are inconsistent here. In CopyTexSubImage2D
we define the pixels-outside-of-the-FB to be unwritten, whereas here we define
them to be 0.
Following the 2D case would be consistent, and probably a bit simpler overall.
So +1, let's not do this, instead make sure we first clear the level if needed,
and second just clip the copy region.

[yunchao, 2016-08-12 01:58:32]

The CQ bit was unchecked by yunchao.he@intel.com

[yunchao, 2016-08-12 02:19:02]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-12 02:19:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[yunchao, 2016-08-12 02:53:15]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-12 02:53:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[yunchao, 2016-08-12 03:28:26]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-12 03:28:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-12 04:10:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-12 04:10:20]

Dry run: This issue passed the CQ dry run.

[yunchao, 2016-08-12 15:33:08]

Patchset #3 (id:40001) has been deleted

[yunchao, 2016-08-12 15:33:18]

Patchset #3 (id:60001) has been deleted

[yunchao, 2016-08-12 15:42:46]

Thanks for your review, piman and kbr. The code has been updated accordingly.
PTAL.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13294: if (!format || !type) {
On 2016/08/11 18:16:31, piman OOO back 2016-8-15 wrote:
> This shouldn't happen, the internal_format was selected previously with either
a
> TexImage3D, or a TexStorage3D.
> For TexStorage3D it's always a sized internal format, so no problem.
> For TexImage3D we validated that the internal format, if unsized, is a valid
one
> that corresponds to a valid format/type pair.
> 
> So maybe replace with a DCHECK?

Done.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13308: if
(!EnsureGPUMemoryAvailable(pixels_size)) {
On 2016/08/11 18:16:31, piman OOO back 2016-8-15 wrote:
> I don't think this is needed - we're not allocating new GPU memory, only
writing
> it.

Done.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13317: width, height, 1, format,
type, zero.get());
On 2016/08/11 18:33:16, piman OOO back 2016-8-15 wrote:
> On 2016/08/11 18:09:44, Ken Russell wrote:
> > This sort of manual zeroing of the pixels that are outside the framebuffer
> isn't
> > done in DoCopyTexSubImage2D, for example -- what's the essential difference
> > between the 2D and 3D cases? Why doesn't the usual texture clearing code
> handle
> > this case?
> 
> The 2D clearing code can deal with tracking partially filled textures, whereas
> it doesn't for 3D.
> 
> That being said, it is true that we are inconsistent here. In
CopyTexSubImage2D
> we define the pixels-outside-of-the-FB to be unwritten, whereas here we define
> them to be 0.
> Following the 2D case would be consistent, and probably a bit simpler overall.
> So +1, let's not do this, instead make sure we first clear the level if
needed,
> and second just clip the copy region.

Yes. The spec is not consistent between CopyTexSubImage2D and CopyTexSubImage3D
if pixels are outside of read framebuffer. This change suppose that the spec is
correct for CopyTexSubImage3D and follows the spec, in which the pixels outside
of read framebuffer should be initialized to 0.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13325: height);
On 2016/08/11 18:16:31, piman OOO back 2016-8-15 wrote:
> We want to adjust xoffset/yoffset/width/height to copyX/Y/Width/Height here if
> we have to clip. The pixels read outside the framebuffer are undefined - not
> necessarily unwritten to the destination - so even if we clear them above, we
> may end up with undefined values overwriting the 0's.
> 
> Note that we need to do that independently of whether the texture needed to be
> cleared.

Done.

[Ken Russell (switch to Gerrit), 2016-08-12 17:39:16]

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13317: width, height, 1, format,
type, zero.get());
On 2016/08/12 15:42:45, yunchao wrote:
> On 2016/08/11 18:33:16, piman OOO back 2016-8-15 wrote:
> > On 2016/08/11 18:09:44, Ken Russell wrote:
> > > This sort of manual zeroing of the pixels that are outside the framebuffer
> > isn't
> > > done in DoCopyTexSubImage2D, for example -- what's the essential
difference
> > > between the 2D and 3D cases? Why doesn't the usual texture clearing code
> > handle
> > > this case?
> > 
> > The 2D clearing code can deal with tracking partially filled textures,
whereas
> > it doesn't for 3D.
> > 
> > That being said, it is true that we are inconsistent here. In
> CopyTexSubImage2D
> > we define the pixels-outside-of-the-FB to be unwritten, whereas here we
define
> > them to be 0.
> > Following the 2D case would be consistent, and probably a bit simpler
overall.
> > So +1, let's not do this, instead make sure we first clear the level if
> needed,
> > and second just clip the copy region.
> 
> Yes. The spec is not consistent between CopyTexSubImage2D and
CopyTexSubImage3D
> if pixels are outside of read framebuffer. This change suppose that the spec
is
> correct for CopyTexSubImage3D and follows the spec, in which the pixels
outside
> of read framebuffer should be initialized to 0.

Thanks for pointing out that inconsistency; it's an oversight. CopyTexSubImage2D
was changed some time ago to not force the pixels outside the framebuffer to be
cleared, and this change was never propagated to the WebGL 2.0 spec.

https://github.com/KhronosGroup/WebGL/pull/1965 updates the WebGL 2.0 spec.
Let's make this CL implement that new behavior.

[Ken Russell (switch to Gerrit), 2016-08-12 17:50:27]

https://codereview.chromium.org/2234923002/diff/80001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/80001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13311: width, height, 1, format,
type, zero.get());
Per comments above and on the bug: let's change the spec of CopyTexSubImage3D in
WebGL 2.0 to match the spec of CopyTexSubImage2D in WebGL 1.0 -- i.e., leave the
pixels outside the framebuffer untouched.
https://github.com/KhronosGroup/WebGL/pull/1965 will make this change.

[yunchao, 2016-08-12 23:51:58]

Description was changed from

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be initialized to 0

BUG=636987, 631934
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
==========

to

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be untouched

BUG=636987, 631934
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
==========

[yunchao, 2016-08-12 23:52:13]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-12 23:52:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[yunchao, 2016-08-12 23:59:43]

@kbr and @piman, I have updated the code accordingly. Please take another look.
It is pretty simple now.

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13317: width, height, 1, format,
type, zero.get());
On 2016/08/12 17:39:15, Ken Russell wrote:
> On 2016/08/12 15:42:45, yunchao wrote:
> > On 2016/08/11 18:33:16, piman OOO back 2016-8-15 wrote:
> > > On 2016/08/11 18:09:44, Ken Russell wrote:
> > > > This sort of manual zeroing of the pixels that are outside the
framebuffer
> > > isn't
> > > > done in DoCopyTexSubImage2D, for example -- what's the essential
> difference
> > > > between the 2D and 3D cases? Why doesn't the usual texture clearing code
> > > handle
> > > > this case?
> > > 
> > > The 2D clearing code can deal with tracking partially filled textures,
> whereas
> > > it doesn't for 3D.
> > > 
> > > That being said, it is true that we are inconsistent here. In
> > CopyTexSubImage2D
> > > we define the pixels-outside-of-the-FB to be unwritten, whereas here we
> define
> > > them to be 0.
> > > Following the 2D case would be consistent, and probably a bit simpler
> overall.
> > > So +1, let's not do this, instead make sure we first clear the level if
> > needed,
> > > and second just clip the copy region.
> > 
> > Yes. The spec is not consistent between CopyTexSubImage2D and
> CopyTexSubImage3D
> > if pixels are outside of read framebuffer. This change suppose that the spec
> is
> > correct for CopyTexSubImage3D and follows the spec, in which the pixels
> outside
> > of read framebuffer should be initialized to 0.
> 
> Thanks for pointing out that inconsistency; it's an oversight.
CopyTexSubImage2D
> was changed some time ago to not force the pixels outside the framebuffer to
be
> cleared, and this change was never propagated to the WebGL 2.0 spec.
> 
> https://github.com/KhronosGroup/WebGL/pull/1965 updates the WebGL 2.0 spec.
> Let's make this CL implement that new behavior.

Done.

https://codereview.chromium.org/2234923002/diff/80001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/80001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13311: width, height, 1, format,
type, zero.get());
On 2016/08/12 17:50:27, Ken Russell wrote:
> Per comments above and on the bug: let's change the spec of CopyTexSubImage3D
in
> WebGL 2.0 to match the spec of CopyTexSubImage2D in WebGL 1.0 -- i.e., leave
the
> pixels outside the framebuffer untouched.
> https://github.com/KhronosGroup/WebGL/pull/1965 will make this change.

Acknowledged.

[commit-bot: I haz the power, 2016-08-13 01:33:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-13 01:33:56]

Dry run: This issue passed the CQ dry run.

[Zhenyao Mo, 2016-08-15 17:47:32]

https://codereview.chromium.org/2234923002/diff/100001/gpu/command_buffer/ser...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/100001/gpu/command_buffer/ser...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13284:
texture_manager()->ClearTextureLevel(this, texture_ref, target, level);
This might return false.  Can you follow the lead in DoCopyTexSubImage2D and
generate an OUT_OF_MEMORY if it's returning false?

[Ken Russell (switch to Gerrit), 2016-08-15 23:51:25]

Thanks for updating the code. LGTM from my standpoint with Mo's concern
addressed.

[yunchao, 2016-08-16 01:44:33]

The CQ bit was checked by yunchao.he@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-16 01:44:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-16 02:51:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-16 02:51:46]

Dry run: This issue passed the CQ dry run.

[yunchao, 2016-08-16 03:15:04]

Thanks for your review, Zhenyao and Ken. Code has been updated. Could you take
another look?

https://codereview.chromium.org/2234923002/diff/100001/gpu/command_buffer/ser...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (right):

https://codereview.chromium.org/2234923002/diff/100001/gpu/command_buffer/ser...
gpu/command_buffer/service/gles2_cmd_decoder.cc:13284:
texture_manager()->ClearTextureLevel(this, texture_ref, target, level);
On 2016/08/15 17:47:32, Zhenyao Mo wrote:
> This might return false.  Can you follow the lead in DoCopyTexSubImage2D and
> generate an OUT_OF_MEMORY if it's returning false?

Done.

[piman, 2016-08-16 04:20:13]

lgtm

[Zhenyao Mo, 2016-08-16 17:19:02]

lgtm

[Zhenyao Mo, 2016-08-16 17:19:59]

The CQ bit was checked by zmo@chromium.org

[Zhenyao Mo, 2016-08-16 17:20:00]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org
Link to the patchset: https://codereview.chromium.org/2234923002/#ps120001
(title: "addressed zmo@'s feedback")

[commit-bot: I haz the power, 2016-08-16 17:20:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-16 17:23:46]

Description was changed from

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be untouched

BUG=636987, 631934
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
==========

to

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be untouched

BUG=636987, 631934
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
==========

[commit-bot: I haz the power, 2016-08-16 17:23:48]

Committed patchset #5 (id:120001)

[commit-bot: I haz the power, 2016-08-16 17:25:20]

Description was changed from

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be untouched

BUG=636987, 631934
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
==========

to

==========
[Command buffer] CopyTexSubImage3D: Copying pixels outside of framebuffer should
be untouched

BUG=636987, 631934
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

Committed: https://crrev.com/4f4547bc67a3ef3cb41208606885fb236e964f7b
Cr-Commit-Position: refs/heads/master@{#412271}
==========

[commit-bot: I haz the power, 2016-08-16 17:25:20]

Patchset 5 (id:??) landed as
https://crrev.com/4f4547bc67a3ef3cb41208606885fb236e964f7b
Cr-Commit-Position: refs/heads/master@{#412271}