GLES2.0 command buffers version 0.00001

There's a HUGE amount of TODO here that I will do in
following CLs but I wanted to get this in so people
can comment and see progress. Assuming there are no 
bugs (cough) it should be possible to get a GLES2.0 
program up with this assuming setup is implemented. 

A few things:

*) Many files are auto geneated. They are generally
made as _autogen.h files and inlcuded into .cc files.
That way, as .h files they can be added to gyp but
not get compiled and it leaves the parts that
are better hand edtied outside of the auto generated
files.

*) there is a special switch to generate the 
id tests. That's because the IDs MUST NOT CHANGE
and so therefore should not be auto generated.

*) I'm deliberately choosing to checkin the auto
generated files. I think it's important that changes
be explicitly reviewed instead of just reviewing
the generator. So, the generator is run manaually
for now.

*) I will end up most likely copying and pasting 
the relavent lines from GLES2/gl2.h direclty
into the builder. The problem with reading it
directly is that changing the gl2.h file changes
the commands but commands are NOT ALLOWED TO CHANGE
once we ship and putting the lines directly in
the builder will make this more explicit.

TODOs:

*) Wrap glGetError with our own error bits so
some of our commands can set those bits.

*) Auto generate unit_tests. I'll work on this
once I get a demo working because I want to be
able to let others use this ASAP.

*) I want to change a few low level things
related to immediate commands. One of the problems
with this system is the commands are generated
from gl2.h instead of designed like they were
with O3D. In O3D, each command that passes
data has an explicit size. In GL, some sizes
are implicit like glTexImage2D.  For an
Immediate cmd, a command where the data
follows the cmd, the cmd needs to know the size
of the data.

This is a problem because that size needs to be
known in 3 places. (1) where space is allocated
in the command buffer to write the command (2)
when the header to the command is filled out and
(3) When the address of the next command is 
computed when not using the GLES2CmdHelper. 

Currently it is computed in all 3 places instead
of just once. I need to think about how to refactor 
so that that info is only computed once.

It might mean one more level of indirection. So,
for example, you look at 
BindAttribLocationImmediate you'll see it
takes a const char* and inserts the name into
the command buffer for you. It might need to be
that that structure expects you to put it in 
yourself and some higher-level thing like the
GLES2CmdHelper deals with putting the data in?
I'm not sure. I like the idea that calling
Cmd::Init or Cmd::Set makes the command perfect, 
no outside stuff needed.

Thoughts are welcome.

*) We need to change the CMD header to either
a 32bit command followed by a 32bit size OR
a 10-11bit command followed by a 21-22bit size. 
That would allow for say 256 common commands and
768 specific commands. Enough?  The
issue is that the Immediate commands are
FAR MORE EASY TO USE because no synchronization
is required. So for things like 
BindAttribLocation it's much much easier to use
the Immediate version. The problem is, with an
8bit size, the largest amount of data you can 
pass is 1024 bytes.  That's not large enough
for a shader and certainly not enough for a 
buffer or texture and it would be nice
to be able to to use those commands as often
as possible in NaCl apps.

*) I need to track glPixelStore

*) Need to fix several commands that need
a size.

*) Need a ton of work on validation. We
need to make sure no enums not specified
by GLES2.0 can make it through to the
underlying GL. Also many places need
to check that the size of data about to be
accessed is valid for the given shared
memory or immediate data.

*) I'm planning to implement a named bucket system.
The specific issue is that some commands take
an arbitarily large amount of data. glBufferData,
glTexImage2D, glShaderSource, glGetShaderSource,
etc.

Right now if your command buffer or shared memory
segment is too small to transfer the data you'd
have to allocate a bigger one.  Rather than
force that solution on you I want to implement
versions of those commands that use named buckets.

The bucket commands would let you Set a bucket
or append to a bucket and then you could reference
those buckets with the commands above. Example

int bucket_id = 123
cmdSetBucket(bucket_id, "first part of shader text");
cmdAppendBucket(bucket_id, "next part of shader text");
cmdShaderSourceByBucket(shaderId, bucket_id);

These bucket management commands would be added to the
common command buffer stuff so they could be used with
any command buffer. This is mostly useful for GLES2
emuliation and exposing command buffers stuff to 
JavaScript like WeBGL. If you are writing a NaCl app 
and talking direclty to the command buffers then you
can allocate your own shader memory the size of the
largest piece you need, or use other methods but
for example in the case of WebGL or GLES2 emu there
are no limits.
buffers

*) Should we add some kind of error reporter to 
the service that the client can get
a handle on so that you can easily check for
errors? I suppose calling glGetError once a
frame is good enough? The advantage of a
service side is that it could more easily
tell you about "mal-formed command" and other
parse / validation errors that don't fit
glGetError. 

*) There are several unimplemented commands.

Questions:

*) Should I separate calling GL from decoding the
same way O3D decodes, then calls GAPI? At this
point and it would slow down the decoder so I 
don't really see a point but I can put
it on a low-prioirty todo if we want it later.

*) Should we support client side indices with
glDrawElements. They would have to be copied
to the server and verified every single call to
glDrawElements so it wouldn't be useful except
for porting code. The argument against is that
glVertexAttribPointer can also take client side
data and yet I don't think that data is used
at the call and therefore can not be validated
so if we can't do one maybe there's no point in
doing the other.


Review URL: http://codereview.chromium.org/394013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32109 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions