 Chromium Code Reviews
 Chromium Code Reviews Issue 14456004:
  GPU client side changes for GpuMemoryBuffers  (Closed) 
  Base URL: https://chromium.googlesource.com/chromium/src.git@glapi
    
  
    Issue 14456004:
  GPU client side changes for GpuMemoryBuffers  (Closed) 
  Base URL: https://chromium.googlesource.com/chromium/src.git@glapi| Index: gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer.txt | 
| diff --git a/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer.txt b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer.txt | 
| new file mode 100644 | 
| index 0000000000000000000000000000000000000000..9f610a57d8a9500327518a89ab806e887fbdf61e | 
| --- /dev/null | 
| +++ b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer.txt | 
| @@ -0,0 +1,80 @@ | 
| +Name | 
| + | 
| + CHROMIUM_gpu_memory_buffer | 
| + | 
| +Name Strings | 
| + | 
| + GL_CHROMIUM_gpu_memory_buffer | 
| + | 
| +Version | 
| + | 
| + Last Modifed Date: April 26, 2013 | 
| + | 
| +Dependencies | 
| + | 
| + OpenGL ES 2.0 is required. | 
| + | 
| +Overview | 
| + | 
| + This extension allows for more efficiently uploading of buffer or texture | 
| + data through Chromium's OpenGL ES 2.0 implementation. | 
| + | 
| + For security reasons Chromium accesses the GPU from a separate process. User | 
| + processes are not allowed to access the GPU directly. This multi-process | 
| + architechure has the advantage that GPU operations can be secured and | 
| + pipelined but it has the disadvantage that all data that is going to be | 
| + passed to GPU must first be made available to the separate GPU process. | 
| + | 
| + Chromium's OpenGL ES 2.0 implementation hides this issue when using the | 
| + standard OpenGL functions BufferData, BufferSubData, TexImage2D, and | 
| + TexSubImage2D by first copying the user's data to shared memory and then | 
| + telling the GPU process to use that shared memory to upload the data. | 
| + | 
| + This extension helps avoid that extra copy from user memory to shared memory | 
| 
greggman
2013/05/03 23:48:01
This extension is, at least at the moment, specifi
 
kaanb
2013/05/06 18:20:53
I'll go over this document once we finalize the na
 | 
| + in a safe and secure manner by allowing the client to directly allocate | 
| + GPU memory. After allocating the memory the client of this interface | 
| + can use methods in CHROMIUM_map_sub extension to map the GPU buffer into | 
| + the user memory and modify the pixels. | 
| + | 
| +Issues | 
| + | 
| + The initial use of this extension was designed for the single process | 
| + mode of Chromium where OpenGL ES 2.0 and GPU implementations share the | 
| + same process. Some additions may be required to support the case where | 
| + OpenGL ES 2.0 and GPU implementations live in different processes. | 
| + | 
| +New Tokens | 
| + | 
| + None | 
| + | 
| +New Procedures and Functions | 
| + | 
| + void ImageBufferDataCHROMIUM (GLenum target, GLsizei width, GLsizei height, | 
| + GLenum format, GLenum type) | 
| + | 
| + Allocates GPU memory for the currently bound buffer with width equal to | 
| + <width> and height equal to <height>. If any memory was previously allocated | 
| + to the bound buffer it is freed before new GPU memory is allocated. If | 
| + <width> and <height> are both 0 no allocation takes place. Similarly if no | 
| + buffer was bound with a call to BindBuffer this method returns immediately | 
| + without allocating any buffers. | 
| + | 
| + INVALID_ENUM is generated if <target> is not GL_IMAGE_BUFFER_CHROMIUM | 
| + | 
| + INVALID_VALUE is generated if <width> or <height> is negative | 
| + | 
| + INVALID_ENUM is generated if <format> is not GL_RGBA | 
| + | 
| + INVALID_ENUM is generated if <type> is not GL_UNSIGNED_BYTE | 
| + | 
| +Errors | 
| + | 
| + None. | 
| + | 
| +New State | 
| + | 
| + None. | 
| + | 
| +Revision History | 
| + | 
| + 4/26/2013 Documented the extension |