• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    CHROMIUM_map_sub
4
5Name Strings
6
7    GL_CHROMIUM_map_sub
8
9Version
10
11    Last Modifed Date: July 22, 2011
12
13Dependencies
14
15    OpenGL ES 2.0 is required.
16
17Overview
18
19    This extension allows for more efficiently uploading of buffer or texture
20    data through Chromium's OpenGL ES 2.0 implementation.
21
22    For security reasons Chromium accesses the GPU from a separate process. User
23    processes are not allowed to access the GPU directly. This multi-process
24    architechure has the advantage that GPU operations can be secured and
25    pipelined but it has the disadvantage that all data that is going to be
26    passed to GPU must first be made available to the separate GPU process.
27
28    Chromium's OpenGL ES 2.0 implementation hides this issue when using the
29    standard OpenGL functions BufferData, BufferSubData, TexImage2D, and
30    TexSubImage2D by first copying the user's data to shared memory and then
31    telling the GPU process to use that shared memory to upload the data.
32
33    This extension helps avoid that extra copy from user memory to shared memory
34    in a safe and secure manner.
35
36Issues
37
38    This extension was designed for only 2 common use cases.
39
40    #1) Dynamic textures. A good example would be a video player that needs to
41    upload video into a texture.
42
43    #2) CPU based skinning.
44
45    The common feature of these 2 use cases is the size of the texture in the
46    first case and the size of the buffer in the second case do not change
47    often. The implemenation of this extension is currently designed to never
48    free shared memory and re-use previously allocated shared memory that is no
49    longer in use.
50
51    This design fits the 2 use cases above but it does not fit uploading lots of
52    arbitrarily sized pieces of data and so, at least in it's current
53    implemenation it should really be only used for cases similar to those
54    described above.
55
56New Tokens
57
58    None
59
60New Procedures and Functions
61
62    void* MapBufferSubDataCHROMIUM (GLuint target, GLintptr offset,
63                                    GLsizeiptr size, GLenum access)
64
65    Returns a pointer to shared memory of the requested <size> or NULL if the
66    request can not be honoured.
67
68    <target>, <offset> and <size> use the exact same parameters as
69    BufferSubData. <access> must be WRITE_ONLY.
70
71    INVALID_ENUM is generated if <access> is not WRITE_ONLY
72
73    INVALID_VALUE is generated if <offset> or <size> is negative
74
75    void  UnmapBufferSubDataCHROMIUM (const void* mem)
76
77    Calling this function effectively calls BufferSubData with the parameters
78    that were specified when originally calling MapBufferSubData. Note that
79    after calling UnmapBufferSubDataCHROMIUM the application should assume that
80    the memory pointed do by <mem> is off limits and is no longer writable by
81    the application. Writing to it after calling UnmapBufferSubDataCHROMIUM will
82    produce undefined results. No security issues exist because of this but
83    which data makes it to the GPU will be unknown from the point of view of
84    the user program.
85
86    <mem> is a pointer previously returned by calling MapBufferSubData and not
87    yet unmapped.
88
89    INVALID_VALUE is generated if <mem> is not a value previously returned by
90    MapBufferSubData or if it has already been passed to
91    UnmapBufferSubDataCHROMIUM.
92
93    Other errors are the same errors that would be returned by BufferSubData.
94
95    void* MapTexSubImage2DCHROMIUM (GLenum target, GLint level,
96                                    GLint xoffset, GLint yoffset,
97                                    GLsizei width, GLsizei height,
98                                    GLenum format, GLenum type, GLenum access)
99
100    Returns a pointer to shared memory that matches the image rectangle
101    described by <width>, <height>, <format>, <type> and the current PixelStorei
102    UNPACK_ALIGNMENT setting or NULL if the request can not be honoured.
103
104    So for example, a width 3, height 4, format RGB, type UNSIGNED_BYTE,
105    UNPACK_ALIGNMENT 4 would return a pointer to a piece of memory 45 bytes
106    in size. Width 3 at RGB is 9 bytes. Padded to an UNPACK_ALIGNMENT of 4 means
107    12 bytes per row. The last row is not padded.
108
109    <target>, <level>, <xoffset>, <yoffset>, <width>, <height>, <format>, and
110    <type> use the exact same parameters as TexSubImage2D. <access> must be
111    WRITE_ONLY.
112
113    INVALID_ENUM is generated if <access> is not WRITE_ONLY
114
115    INVALID_VALUE is generated if <xoffset>, <yoffset>, <width>, <height> or
116    <level> is negative
117
118    void  UnmapTexSubImage2DCHROMIUM (const void* mem)
119
120    Calling this function effectively calls TexSubImage2D with the parameters
121    that were specified when originally calling MapTexSubImage2D. Note that
122    after calling UnmapTexSubImage2DCHROMIUM the application should assume that
123    the memory pointed do by <mem> is off limits and is no longer writable by
124    the application. Writing to it after calling UnmapTexSubImage2DCHROMIUM will
125    produce undefined results. No security issues exist because of this but
126    which data makes it to the GPU will be unknown from the point of view of the
127    user program.
128
129    <mem> is a pointer previously returned by calling MapTexSubImage2D and not
130    yet unmapped.
131
132    INVALID_VALUE is generated if <mem> is not a value previously returned by
133    MapTexSubImage2D or if it has already been passed to
134    UnmapTexSubImage2DCHROMIUM.
135
136    Other errors are the same errors that would be returned by TexSubImage2D.
137
138Errors
139
140    None.
141
142New State
143
144    None.
145
146Revision History
147
148    7/22/2011    Documented the extension
149