| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
FencedAllocator to manage the transfer buffer
with less waiting.
Also updates glBufferData to use glBufferSubData
to send data as well as glTexImage2D to use
glTexSubImage2D. These make it possible to
pass any size image or buffer data.
Review URL: http://codereview.chromium.org/436020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32949 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
This excersized more code and found several
bugs.
Review URL: http://codereview.chromium.org/437020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32891 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/434012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32864 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/415004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32576 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if I should check the demo in or not.
I expect it will be moved or deleted but I'd like
to get it in.
This demo currently only runs on Windows because
of a few setup issues. All it does is clear the screen
purple then yellow.
It shows a tiny C segment including only gl2.h and
calling a GL function. Also a tiny C++ segment
including only gl2.h and calling a GL function.
The setup code is currently in the gles2_demo.cc.
I'd like to move to gles2_lib.cc but it needs
to be NaCl specific for that since that's the use
case for generic setup.
WebGL and unit tests will have to do custom setup I
think.
Also, I found out glGetAttribLocation and
glGetUniformLocation were not implemented. For now
I mostly subbed them out. The quickest solution
was to add class GetGLcharHandler to the
code generator but my next step will be to delete
class GetGLcharHandler and GLcharHandler given
that they only represent 3 functions total that
code should be written manually.
Review URL: http://codereview.chromium.org/399108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32546 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/404035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32433 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
and fix includes so service side and compile
with system GL and client side can compile
with Command Buffer GL.
Review URL: http://codereview.chromium.org/407006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32429 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
interface.
Moved np_utils classes into new np_utils namespace.
Removed some of the command_buffer dependencies on NPAPI.
CommandBuffer(Server) is no longer an NPObject.
Review URL: http://codereview.chromium.org/387063
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32119 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31859 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
to move to Chrome tree.
Review URL: http://codereview.chromium.org/392017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31854 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31692 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31682 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
gpu/gpu.gyp
gpu/command_buffer/...
gpu/gpu_plugin/...
gpu/np_utils/...
And fixed up paths and header sentry macros. Also merged command_buffer.gyp into gpu.gyp.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31676 0039d316-1c4b-4281-b951-d872f2087c98
|
