Update ES3 enums for texture parameters.

Update ES3 enums for texture parameters.

This affetcs TexImage*D, TexStorage*D, CopyTexImage2D.

Note that this is working progress to allow these ES3 enums.  More validation
code needs to be modified to make them work.

BUG=429053
TEST=gpu_unittests
R=sievers@chromium.org

Committed: https://crrev.com/47e01c44489b0c7e498df6e09987c401d7592b2c
Cr-Commit-Position: refs/heads/master@{#320612}

[Zhenyao Mo, 2015-03-12 22:12:18]

sievers: another one.
Others: FYI

[Zhenyao Mo, 2015-03-12 22:16:38]

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

https://codereview.chromium.org/1007523002/diff/20001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder.cc:9114: GL_INVALID_ENUM,
This is correct because such format is not one of the allowed internalformat.

The old codepath follows ANGLE_depth_texture, explicitly requires an
INVALID_OPERATION, which is incorrect.  I will file a ticket to update the ANGLE
extension spec.

[no sievers, 2015-03-12 22:37:05]

Do you think it'd be easy to do the revert separately, and then rebase the new
changes on top?

I think that would make a better patch history.

https://codereview.chromium.org/1007523002/diff/20001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

https://codereview.chromium.org/1007523002/diff/20001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1372: 'GL_RGBA32I',
maybe put a comment that these are not supported for CopyTexImage and rejected
at runtime?

[Zhenyao Mo, 2015-03-12 22:39:17]

OK, sounds good.  Will revert.

https://codereview.chromium.org/1007523002/diff/20001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

https://codereview.chromium.org/1007523002/diff/20001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1372: 'GL_RGBA32I',
On 2015/03/12 22:37:05, sievers wrote:
> maybe put a comment that these are not supported for CopyTexImage and rejected
> at runtime?

Done.

[Zhenyao Mo, 2015-03-12 22:54:01]

sievers: please take another look.

This CL combined the reverted one.

[no sievers, 2015-03-13 00:15:55]

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
File gpu/command_buffer/cmd_buffer_functions.txt (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
gpu/command_buffer/cmd_buffer_functions.txt:136: GL_APICALL void        
GL_APIENTRY glReadPixels (GLint x, GLint y, GLsizei width, GLsizei height,
GLenumReadPixelFormat format, GLenumReadPixelType type, void* pixels);
Wait, so this was accidentally not used before?

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc:2112:
EXPECT_EQ(GL_INVALID_ENUM, GetGLError());
Shouldn't this still be INVALID_OPERATION according to the spec?

[Zhenyao Mo, 2015-03-13 02:38:33]

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
File gpu/command_buffer/cmd_buffer_functions.txt (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
gpu/command_buffer/cmd_buffer_functions.txt:136: GL_APICALL void        
GL_APIENTRY glReadPixels (GLint x, GLint y, GLsizei width, GLsizei height,
GLenumReadPixelFormat format, GLenumReadPixelType type, void* pixels);
On 2015/03/13 00:15:54, sievers wrote:
> Wait, so this was accidentally not used before?

Look at the build_*.py, it is overwritten in the ReadPixels command, so this bug
is never active.

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc:2112:
EXPECT_EQ(GL_INVALID_ENUM, GetGLError());
On 2015/03/13 00:15:54, sievers wrote:
> Shouldn't this still be INVALID_OPERATION according to the spec?

According to the core spec, any internalformat not in the list should generate
an INVALID_ENUM.  I think the ANGLE_depth_texture spec is incorrect.

[Zhenyao Mo, 2015-03-13 19:39:01]

Bots are all green now.  Please take another look.

[no sievers, 2015-03-13 19:44:18]

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (left):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1228: 'GL_INT',
Note that GLES2DecoderTest.ReadPixelsInvalidArgs verifies that GL_INT is invalid
(it's a manually written test).
Which means this test would fail if you ran it with the underlying version set
to ES3.

Which brings up the general question of what's to become of the decoder
unittests with ES3 underneath? If validation moves to Angle a lot of tests
become invalid. For those that are still valid, we'll eventually have to
separate them out and run them with different version strings.

Otherwise, it seems that all other commands that use this are manual (or specify
unit_test = false).

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1459: 'invalid_es3': [
Ok, I think now I find this slightly confusing because of the name.

'invalid' means that it should generate a unit test if possible.
Otherwise you don't need to specify invalid ones because 'is not in valid list'
implies invalid.

Should this really be called 'deprecated_es3'?

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
File gpu/command_buffer/cmd_buffer_functions.txt (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/cmd_...
gpu/command_buffer/cmd_buffer_functions.txt:136: GL_APICALL void        
GL_APIENTRY glReadPixels (GLint x, GLint y, GLsizei width, GLsizei height,
GLenumReadPixelFormat format, GLenumReadPixelType type, void* pixels);
On 2015/03/13 02:38:33, Zhenyao Mo wrote:
> On 2015/03/13 00:15:54, sievers wrote:
> > Wait, so this was accidentally not used before?
> 
> Look at the build_*.py, it is overwritten in the ReadPixels command, so this
bug
> is never active.

Ah, got it, the code that validates this is custom, not autogenerated.

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc:2112:
EXPECT_EQ(GL_INVALID_ENUM, GetGLError());
On 2015/03/13 02:38:33, Zhenyao Mo wrote:
> On 2015/03/13 00:15:54, sievers wrote:
> > Shouldn't this still be INVALID_OPERATION according to the spec?
> 
> According to the core spec, any internalformat not in the list should generate
> an INVALID_ENUM.  I think the ANGLE_depth_texture spec is incorrect.


OK looks like OpenGL 4 indeed says:
" An invalid value specified for internalformat
generates the error INVALID_ENUM"


But ES3 says this:
'Table 3.15 summarizes the
valid framebuffer and texture base internal format combinations. If the
combination
is not valid, an INVALID_OPERATION error is generated.'

ANGLE_depth_texture says:

    "CopyTexImage2D and CopyTexSubImage2D generate the INVALID_OPERATION 
    error if the base internal format of the destination texture is 
    DEPTH_COMPONENT or DEPTH_STENCIL_OES.

And WebGL says nothing about it.

So I guess it doesn't matter :)

[Zhenyao Mo, 2015-03-13 20:25:14]

OK, revised.  Please check again.  Thanks.

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (left):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1228: 'GL_INT',
On 2015/03/13 19:44:17, sievers wrote:
> Note that GLES2DecoderTest.ReadPixelsInvalidArgs verifies that GL_INT is
invalid
> (it's a manually written test).
> Which means this test would fail if you ran it with the underlying version set
> to ES3.
> 
> Which brings up the general question of what's to become of the decoder
> unittests with ES3 underneath? If validation moves to Angle a lot of tests
> become invalid. For those that are still valid, we'll eventually have to
> separate them out and run them with different version strings.
> 
> Otherwise, it seems that all other commands that use this are manual (or
specify
> unit_test = false).

Once we switch to MANGLE, all the command buffer unit tests with invalid enums
will have to be deleted.  Note that it's exactly the case for commands with
'unsafe' set to True, where the code generator bypasses all the invalid test
generation.

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/buil...
gpu/command_buffer/build_gles2_cmd_buffer.py:1459: 'invalid_es3': [
On 2015/03/13 19:44:18, sievers wrote:
> Ok, I think now I find this slightly confusing because of the name.
> 
> 'invalid' means that it should generate a unit test if possible.
> Otherwise you don't need to specify invalid ones because 'is not in valid
list'
> implies invalid.
> 
> Should this really be called 'deprecated_es3'?

Done.

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc (right):

https://codereview.chromium.org/1007523002/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/gles2_cmd_decoder_unittest_textures.cc:2112:
EXPECT_EQ(GL_INVALID_ENUM, GetGLError());
On 2015/03/13 19:44:18, sievers wrote:
> On 2015/03/13 02:38:33, Zhenyao Mo wrote:
> > On 2015/03/13 00:15:54, sievers wrote:
> > > Shouldn't this still be INVALID_OPERATION according to the spec?
> > 
> > According to the core spec, any internalformat not in the list should
generate
> > an INVALID_ENUM.  I think the ANGLE_depth_texture spec is incorrect.
> 
> 
> OK looks like OpenGL 4 indeed says:
> " An invalid value specified for internalformat
> generates the error INVALID_ENUM"
> 
> 
> But ES3 says this:
> 'Table 3.15 summarizes the
> valid framebuffer and texture base internal format combinations. If the
> combination
> is not valid, an INVALID_OPERATION error is generated.'
> 
> ANGLE_depth_texture says:
> 
>     "CopyTexImage2D and CopyTexSubImage2D generate the INVALID_OPERATION 
>     error if the base internal format of the destination texture is 
>     DEPTH_COMPONENT or DEPTH_STENCIL_OES.
> 
> And WebGL says nothing about it.
> 
> So I guess it doesn't matter :)

Done.

[no sievers, 2015-03-13 20:32:56]

lgtm

[Zhenyao Mo, 2015-03-13 20:52:31]

The CQ bit was checked by zmo@chromium.org

[commit-bot: I haz the power, 2015-03-13 20:52:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1007523002/60001

[commit-bot: I haz the power, 2015-03-14 00:15:41]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-03-14 00:17:17]

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