diff options
author | gman@chromium.org <gman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-17 19:24:18 +0000 |
---|---|---|
committer | gman@chromium.org <gman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-17 19:24:18 +0000 |
commit | b1d2dcb6ca00ca1aab7017702a882f9df9eeaa5f (patch) | |
tree | 724b4744870f078601c0fef591e538fcc28b22bb /gpu/command_buffer/docs | |
parent | 8d84301ae5bbb424b8c3e0f22c69841519324f10 (diff) | |
download | chromium_src-b1d2dcb6ca00ca1aab7017702a882f9df9eeaa5f.zip chromium_src-b1d2dcb6ca00ca1aab7017702a882f9df9eeaa5f.tar.gz chromium_src-b1d2dcb6ca00ca1aab7017702a882f9df9eeaa5f.tar.bz2 |
Makes shader translation a runtime switch.
For WebGL the shader translation is off. For Pepper
and other processes it is on. This will
be removed and the tranlator will always be on
at some point in the future
TEST=More conformance tests pass, manually ran WebGL demos in Chrome.
BUG=none
Review URL: http://codereview.chromium.org/2127001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47441 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'gpu/command_buffer/docs')
-rw-r--r-- | gpu/command_buffer/docs/gles2_cmd_format_docs.txt | 34 |
1 files changed, 19 insertions, 15 deletions
diff --git a/gpu/command_buffer/docs/gles2_cmd_format_docs.txt b/gpu/command_buffer/docs/gles2_cmd_format_docs.txt index ee6eb98..67306ab 100644 --- a/gpu/command_buffer/docs/gles2_cmd_format_docs.txt +++ b/gpu/command_buffer/docs/gles2_cmd_format_docs.txt @@ -1,32 +1,32 @@ //! \file //! -//! The public interface for 3D graphics is based on a commmand buffer. +//! The public interface for 3D graphics is based on a command buffer. //! -//! This was choosen because it provides an easy way to separate the process -//! writing commands from the process reading those commands without requiring -//! too much overhead to keep the two processes in sync. +//! This was chosen because it provides an easy way to separate the process of +//! writing commands from the process of reading those commands without +//! requiring too much overhead to keep the two processes in sync. //! //! You can use this info to write commands yourself. Most developers will use //! the provided OpenGL ES 2.0 implementation that issues these commands for //! them. //! -//! Each command starts with a header. The header is 32 bits where the first 21 +//! Each command starts with a header. The header is 32 bits, where the first 21 //! bits define the number of 32 bit entries, including the header, the command -//! represnts. The last 11 bits specify the specific command. +//! represents. The last 11 bits specify the command. //! //! Commands that send a variable amount of data have 1 to 3 ways to send that //! data. //! -//! For many commands they can send their data in shared memory. The command -//! will take an id of the shared memory and an offset into that shared memory -//! of where the data lives. Commands are executed asynchronously so the client +//! Many commands can send their data in shared memory. The command will take +//! an id of the shared memory and an offset into that shared memory of where +//! the data lives. Commands are executed asynchronously, so the client //! program must be careful to leave the data available until the command has //! executed. //! //! Some commands have an 'immediate' version where the data appears directly //! after the command in memory. //! -//! A 3rd way of passing data is through Buckets. Buckets are indentified by +//! A 3rd way of passing data is through Buckets. Buckets are identified by //! number. You create a bucket with the command SetBucketSize, you can then //! fill the bucket with SetBucketData commands. Once you've sent all your //! data you can then issue a command that uses the bucket and takes a bucket @@ -81,7 +81,7 @@ struct CommandHeader { //! the command failed its result size will 0. You must set the size to 0 //! before issuing the command. //! -//! To retreive the data you might do something like this pseudo code: +//! To retrieve the data you might do something like this pseudo code: //! //! GetAttachedShaders::Result* result = address-of-shared-memory //! int num_results = result->size / sizeof(GLuint); // the type returned @@ -123,7 +123,7 @@ struct Jump { //! The JumpRelative command jumps to another place in the command buffer //! relative to the end of this command. In other words. JumpRelative with an -//! offset of zero is effectively a noop. +//! offset of zero is effectively a no-op. struct JumpRelative { static const CommandId kCmdId = 4; @@ -2247,12 +2247,16 @@ struct RegisterSharedIds { uint32 ids_shm_offset; //!< uint32 }; -//! Command that enables or disables command buffer specific features. +//! Command that enables features. The bucket should contain the feature string. struct CommandBufferEnable { static const CommandId kCmdId = 442; + typedef GLint Result; + CommandHeader header; - uint32 cap; //!< GLenum - uint32 enable; //!< GLboolean + uint32 bucket_id; //!< GLuint + uint32 result_shm_id; //!< uint32 + uint32 result_shm_offset; //!< uint32 }; + |