blob: 71cfca05a4d0ac2f5688be181cbdaed62b5715e6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# Generic Optimization for EXT_compiled_vertex_array
It should be possible to provide generic optimization for [[compiled vertex arrays|http://www.opengl.org/registry/specs/EXT/compiled_vertex_array.txt]]. These optimizations should be implementable for both indirect rendering and direct rendering. For the direct rendering case, Mesa should provide generic paths that drivers can enable or disable. These paths are only useful for drivers that implement [[vertex buffer objects|http://www.opengl.org/registry/specs/ARB/vertex_buffer_object.txt]] and have hardware T&L units.
When glLockArraysEXT is called, a buffer is created that is large enough to hold all of the currently known array state. All arrays for which data has been set (e.g., via glVertexPointer, glColorPointer, etc) is included in the calculation. It is possible that the application may enable or disable additional arrays. The calculated size includes only the range specified by the "count" parameter of glLockArraysEXT.
At this time, a flag is set within libGL to note that the library is in the special CVA mode. If any pointer function is called, the buffer object is destroyed and the flag is cleared.
In the CVA case, all element data will come from client memory either via calls to glArrayElement, glDrawArrays, or the pointer supplied to glDrawElements. This implies that all the indexes will pass through libGL. When the data passes through libGL, the library can re-base the data from the "first" parameter of glLockArraysEXT. The net effect is that the library will tell the server that "first" is element zero in all arrays. This implies, of course, that elements less than "first" won't work. This is not a problem since the EXT_compiled_vertex_array specification clearly states this may not work.
When a draw call made and the CVA flag is set, buffer object protocol is used to perform the drawing.
|
