Another round of gcc fixes for GPU command buffers.

Another round of gcc fixes for GPU command buffers.

This actually gets command_buffer_common_unittests building and passing.

BUG=n/a
TEST=n/a

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=34595

[scherkus (not reviewing), 2009-12-11 00:03:36]

Hooray!!  format tests passing on linux and windows

I switched to using xor so we get a bit-exact comparison between the CommandId
enum and the uint-bitfield in the CommandHeader struct -- otherwise we rely on
casting either the enum or the bitfield.  Let me know if you're comfortable with
this change.

I also had to add in override types for GLint and GLsizei.  They're defined on
linux's gl.h to be plain ints, hence the override to int32.  Let me know if
you're also comfortable with this change.

[scherkus (not reviewing), 2009-12-11 00:11:36]

including gman

[greggman, 2009-12-11 07:00:06]

http://codereview.chromium.org/488011/diff/1002/2001
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

http://codereview.chromium.org/488011/diff/1002/2001#newcode461
gpu/command_buffer/build_gles2_cmd_buffer.py:461: file.Write("  cmd.Set(\n")
this needs to stay as it was. If the issue is that next_cmd is causing an unused
variable warning then next_cmd needs to be checked with something along the
lines of 

EXPECT_EQ(static_cast<char*>(next_cmd), 
          static_cast<char*>(&cmd) + sizeof(cmd));

That will work for non immediate commands. Immediate commands will require more
work.

same for all the rest below.

http://codereview.chromium.org/488011/diff/1002/2001#newcode470
gpu/command_buffer/build_gles2_cmd_buffer.py:470: file.Write(" 
EXPECT_FALSE(%s::kCmdId ^ cmd.header.command);\n" % func.name)
I'm curious why this change is needed. We want to know the IDs match and that is
== not ^. Maybe I'm missing something but if you're using ^ here then any 2
integer tests in the entire code base should be tested this way no? Am I missing
something that makes this test special and other integer values not special?

same for all the rest below

[scherkus (not reviewing), 2009-12-11 18:39:42]

thanks for the review!

http://codereview.chromium.org/488011/diff/1002/2001
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

http://codereview.chromium.org/488011/diff/1002/2001#newcode461
gpu/command_buffer/build_gles2_cmd_buffer.py:461: file.Write("  cmd.Set(\n")
On 2009/12/11 07:00:06, greggman wrote:
> this needs to stay as it was. If the issue is that next_cmd is causing an
unused
> variable warning then next_cmd needs to be checked with something along the
> lines of 
> 
> EXPECT_EQ(static_cast<char*>(next_cmd), 
>           static_cast<char*>(&cmd) + sizeof(cmd));
> 
> That will work for non immediate commands. Immediate commands will require
more
> work.
> 
> same for all the rest below.

Cool -- I'll figure something out.

http://codereview.chromium.org/488011/diff/1002/2001#newcode470
gpu/command_buffer/build_gles2_cmd_buffer.py:470: file.Write(" 
EXPECT_FALSE(%s::kCmdId ^ cmd.header.command);\n" % func.name)
On 2009/12/11 07:00:06, greggman wrote:
> I'm curious why this change is needed. We want to know the IDs match and that
is
> == not ^. Maybe I'm missing something but if you're using ^ here then any 2
> integer tests in the entire code base should be tested this way no? Am I
missing
> something that makes this test special and other integer values not special?
> 
> same for all the rest below

kCmdId is an enum (signed 32/64-bit)
cmd.header.command is an unsigned 11-bit number

I was talking this over with someone and we either need to cast kCmdId to
unsigned, cast cmd.header.command to signed, or do some other form of
comparison.  We weren't sure how different compilers would promote an 11-bit
number to a 32/64-bit number for comparison, so we thought xor would a safer
bet.

I'm *pretty sure* that casting one or the other would still work the same, so if
you think that'll be clearer I'll make the change.

[scherkus (not reviewing), 2009-12-11 20:26:30]

now use static_cast<uint32>(kCmdId) for equality check

added tests for next_cmd

[greggman, 2009-12-15 18:44:26]

LGTM

http://codereview.chromium.org/488011/diff/2006/2007
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

http://codereview.chromium.org/488011/diff/2006/2007#newcode1361
gpu/command_buffer/build_gles2_cmd_buffer.py:1361: file.Write("               
sizeof(data));\n")
I think this and the ones below should change to use
RoundSizeToMultipleOfEntries. There is some chance that we will change the
command header to 64 bits before we go public.

[scherkus (not reviewing), 2009-12-15 20:22:39]

good suggestion -- fixed, unit tests still passing!

committing!!!

[apatrick, 2009-12-15 21:04:39]

Are the unit tests passing on linux as well now?

On Tue, Dec 15, 2009 at 12:22 PM, <scherkus@chromium.org> wrote:

> good suggestion -- fixed, unit tests still passing!
>
> committing!!!
>
>
> http://codereview.chromium.org/488011
>

[scherkus (not reviewing), 2009-12-15 21:50:12]

Sort of... a few of your latest patches introduced more gcc brokenness.
 Expect another patch soon!

On Tue, Dec 15, 2009 at 4:04 PM, Alastair Patrick <apatrick@google.com>wrote:

> Are the unit tests passing on linux as well now?
>
>
> On Tue, Dec 15, 2009 at 12:22 PM, <scherkus@chromium.org> wrote:
>
>> good suggestion -- fixed, unit tests still passing!
>>
>> committing!!!
>>
>>
>> http://codereview.chromium.org/488011
>>
>
>