summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Drop the always-software-primitive-restart paths.Eric Anholt2014-09-302-42/+8
| | | | | | | The core sw primitive restart code is still around, because i965 uses it in some cases, but there are no drivers that want it on all the time. Reviewed-by: Rob Clark <[email protected]>
* mesa: Set correct array element in vbo_exec_vtx_init.Kenneth Graunke2014-09-241-1/+1
| | | | | | | | | | | I'm not familiar with this code, but this sure appears to be a typo. It looks like the intent is to set each array element, not arrays[0] each time. Notably, the loop just below uses "array", not "arrays". Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Fredrik Höglund <[email protected]> Reviewed-by: Brian Paul <[email protected]> Cc: [email protected]
* mesa: Delete VAO _MaxElement code and index buffer bounds checking.Kenneth Graunke2014-09-194-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx->Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* Eliminate several cases of multiplication in arguments to callocCarl Worth2014-09-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | In commit 32f2fd1c5d6088692551c80352b7d6fa35b0cd09, several calls to _mesa_calloc(x) were replaced with calls to calloc(1, x). This is strictly equivalent to what the code was doing previously. But for cases where "x" involves multiplication, now that we are explicitly using the two-argument calloc, we can do one step better and replace: calloc(1, A * B); with: calloc(A, B); The advantage of the latter is that calloc will detect any overflow that would have resulted from the multiplication and will fail the allocation, (whereas the former would return a small allocation). So this fix can change potentially exploitable buffer overruns into segmentation faults. Reviewed-by: Matt Turner <[email protected]>
* mesa: Expose vbo_exec_DrawArraysInstanced as _mesa_DrawArraysInstanced.Kenneth Graunke2014-08-151-0/+6
| | | | | | | So we can use it in meta.c. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* mesa: fix crash in st/mesa after deleting a VAOMarek Olšák2014-07-112-33/+4
| | | | | | | | | | This happens when glGetMultisamplefv (or any other non-draw function) is called, which doesn't invoke the VBO module to update _DrawArrays and the pointer is invalid at that point. However st/mesa still dereferences it to setup vertex buffers ==> crash. Reviewed-by: Brian Paul <[email protected]>
* mesa: check constant before null checkTimothy Arceri2014-05-221-3/+3
| | | | | | | For most drivers this if statement is always going to fail so check the constant value first. Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: add extra null checks in vbo_rebase_prims()Juha-Pekka Heikkila2014-05-021-2/+21
| | | | | | | | v2 [idr]: Move declarations before code to prevent MSVC build breaks. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Ian Romanick <[email protected]>
* mesa: Use location VERT_ATTRIB_GENERIC0 for vertex attribute 0Anuj Phogat2014-05-011-22/+23
| | | | | | | | | | | | | | | | | | | In OpenGL 3.1 attribute 0 becomes non-magic, just like in OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0 exclusively for vertex position. V2: Add a utility function _mesa_attr_zero_aliases_vertex() in varray.h Fixes 4 Khronos OpenGL CTS failures: glGetVertexAttrib depth24_basic depth24_precision rgb8_rgba8_rgb Cc: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: allow buffers to be mapped multiple timesMarek Olšák2014-02-258-56/+81
| | | | | | | | | | | | | | | | | | | OpenGL allows a buffer to be mapped only once, but we also map buffers internally, e.g. in the software primitive restart fallback, for PBOs, vbo_get_minmax_index, etc. This has always been a problem, but it will be a bigger problem with persistent buffer mappings, which will prevent all Mesa functions from mapping buffers for internal purposes. This adds a driver interface to core Mesa which supports multiple buffer mappings and allows 2 mappings: one for the GL user and one for Mesa. Note that Gallium supports an unlimited number of buffer and texture mappings, so it's not really an issue for Gallium. v2: fix unmapping in xm_dd.c, remove the GL errors there v3: fix the intel driver (by Fredrik) Reviewed-by: Fredrik Höglund <[email protected]>
* mesa: allow buffers mapped with the persistent flag to be used by the GPUMarek Olšák2014-02-251-2/+2
| | | | | | v2: also fixed InvalidateBufferData, added citations from the 4.4 spec Reviewed-by: Fredrik Höglund <[email protected]>
* mesa: add storage flags parameter to Driver.BufferDataMarek Olšák2014-02-253-3/+13
| | | | | | | It will be used by glBufferStorage. The parameters are chosen according to ARB_buffer_storage. Reviewed-by: Fredrik Höglund <[email protected]>
* mesa: Rename ElementArrayBufferObj to IndexBufferObj.Kenneth Graunke2014-02-032-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | DirectX and most hardware documentation use the term "Index Buffer" to refer to a buffer containing indexes into arrays of vertex data, which allows random access to vertex data, rather than sequential access. OpenGL uses a different term for this concept: "Element Array Buffer". However, "Index Buffer" has become much more widespread. A quick Google search shows 29,300 hits for "Element Array Buffer" vs. 82,300 hits for "Index Buffer." Arguably, "Index Buffer" is clearer: an "element of an array" (or list) usually refers to an actual item stored in the array, not the index used to refer to it. The terminology is also already used in Mesa: some VBO module code for dealing with ElementArrayBufferObj names local variables "ib". Completely generated by: $ find . -type f -print0 | xargs -0 sed -i \ 's/ElementArrayBufferObj/IndexBufferObj/g' Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Rename "struct gl_array_object" to gl_vertex_array_object.Kenneth Graunke2014-02-031-2/+2
| | | | | | | | | | | | | | | | | | I considered replacing it with "gl_vao", but spelling it out seemed to fit better with Mesa's traditional style. Mesa doesn't shy away from long type names - consider gl_transform_feedback_object, gl_fragment_program_state, gl_uniform_buffer_binding, and so on. Completely generated by: $ find . -type f -print0 | xargs -0 sed -i \ 's/gl_array_object/gl_vertex_array_object/g' v2: Rerun command to resolve conflicts with Ian's meta patches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Rename "arrayObj" local variables to "vao".Kenneth Graunke2014-02-031-8/+8
| | | | | | | | | | | | | Now that the field is named "VAO" instead of "ArrayObj", it makes sense to call the local variables "vao" instead of "arrayObj". Completely generated by: $ find . -type f -print0 | xargs 0 sed -i 's/arrayObj/vao/g' Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Rename ArrayObj to VAO and DefaultArrayObj to DefaultVAO.Kenneth Graunke2014-02-032-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When reading through the Mesa drawing code, it's not immediately obvious to me that "ArrayObj" (gl_array_object) is the Vertex Array Object (VAO) state. The comment above the structure explains this, but readers still have to remember this and translate accordingly. Out of context, "array object" is a fairly vague. Even in context, "array" has a lot of meanings: glDrawArrays, vertex data stored in user arrays, gl_client_arrays, gl_vertex_attrib_arrays, and so on. Using the term "VAO" immediately associates these fields with the OpenGL concept, clarifying the situation and aiding programmer sanity. Completely generated by: $ find . -type f -print0 | xargs -0 sed -i \ -e 's/ArrayObj;/VAO;/g' \ -e 's/->ArrayObj/->VAO/g' \ -e 's/Array\.ArrayObj/Array.VAO/g' \ -e 's/Array\.DefaultArrayObj/Array.DefaultVAO/g' v2: Rerun command to resolve conflicts with Ian's meta patches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* s/Tungsten Graphics/VMware/José Fonseca2014-01-1719-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the old copyright name is creating unnecessary confusion, hence this change. This was the sed script I used: $ cat tg2vmw.sed # Run as: # # git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed # # Rename copyrights s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g /Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./ s/TUNGSTEN GRAPHICS/VMWARE/g # Rename emails s/[email protected]/[email protected]/ s/[email protected]/[email protected]/g s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/ s/jrfonseca\[email protected]/[email protected]/g s/keithw\[email protected]/[email protected]/g s/[email protected]/[email protected]/g s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/ s/[email protected]/[email protected]/ # Remove dead links s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g # C string src/gallium/state_trackers/vega/api_misc.c s/"Tungsten Graphics, Inc"/"VMware, Inc"/ Reviewed-by: Brian Paul <[email protected]>
* mesa: modified _mesa_align_free() to accept NULL pointerSiavash Eliasi2013-12-041-5/+4
| | | | | | | | | | | So that it acts like ordinary free(). This lets us remove a bunch of if statements where the function is called. v2: - Avoiding compile error on MSVC and possible warnings on other compilers. - Added comment regards passing NULL pointer being safe. Reviewed-by: Brian Paul <[email protected]>
* vbo: map indirect buffer and extract params if doing sw primitive restartChris Forbes2013-11-251-0/+33
| | | | | | | | | V2: Check for mapping failure (thanks Brian) V3: - Change error on mapping failure to OUT_OF_MEMORY (Brian) - Unconst; remove casting away of const. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: pass indirect buffer to sw primitive restartChris Forbes2013-11-253-3/+5
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: Flesh out implementation of indirect drawsChris Forbes2013-11-251-0/+218
| | | | | | | | | Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: add indirect_offset, is_indirect to _mesa_primChris Forbes2013-11-254-1/+12
| | | | | | | | | V3: Add missing cases V4: Add indirect_offset here too Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glapi: add plumbing for GL_ARB_draw_indirect and GL_ARB_multi_draw_indirectChris Forbes2013-11-251-0/+35
| | | | | | | | Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: add indirect drawing buffer parameter to draw functionsChristoph Bumiller2013-11-258-12/+13
| | | | | | | | | | | | Split from patch implementing ARB_draw_indirect. v2: Const-qualify the struct gl_buffer_object *indirect argument. v3: Fix up some more draw calls for new argument. v4: Fix up rebase conflicts in i965. v5: Undo const-qualification Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: add 10_11_11 support to vbo_attrib_tmpChris Forbes2013-11-081-6/+26
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Rename gl_array_object::VertexAttrib to _VertexAttribFredrik Höglund2013-11-071-6/+6
| | | | | | | | This will become derived state as part of the ARB_vertex_attrib_binding support. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add a new GetTransformFeedbackVertexCount() driver hook.Kenneth Graunke2013-10-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DrawTransformFeedback() needs to obtain the number of vertices written to a particular stream during the last Begin/EndTransformFeedback block. The new driver hook returns exactly that information. Gallium drivers already implement this by passing the transform feedback object to the drawing function, counting the number of vertices written on the GPU, and using draw indirect. This is efficient, but doesn't always work: If vertex data comes from user arrays, then the VBO module needs to know how many vertices to upload, so we need to synchronously count. Gallium drivers are currently broken in this case. It also doesn't work if primitive restart is done in software. For normal drawing, vbo_draw_arrays() performs software primitive restart, splitting the draw call in two. vbo_draw_transform_feedback() currently doesn't because it has no idea how many vertices need to be drawn. The new driver hook gives it that information, allowing us to reuse the existing vbo_draw_arrays() code to do everything right. On Intel hardware (at least Ivybridge), using the draw indirect approach is difficult since the hardware counts primitives, rather than vertices, which requires doing some simple math. So we always use this hook. Gallium drivers will likely want to use this hook in some cases, but want to use the existing draw indirect approach where possible. Hence, I've added a flag to allow drivers to opt-in to this call. v2: Make it possible to implement this hook but only use this path when necessary (suggested by Marek). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* vbo: fix MSVC double->float conversion warningsBrian Paul2013-10-311-2/+2
|
* vbo: access VBO memory more efficiently when building display listsBrian Paul2013-10-161-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use GL_MAP_INVALIDATE_RANGE, UNSYNCHRONIZED and FLUSH_EXPLICIT flags when mapping VBOs during display list compilation. This mirrors what we do for immediate-mode VBO building in vbo_exec_vtx_map(). This improves performance for applications which interleave display list compilation with execution. For example: glNewList(A); glBegin/End prims; glEndList(); glCallList(A); glNewList(B); glBegin/End prims; glEndList(); glCallList(B); Mesa's vbo module tries to combine the vertex data from lists A and B into the same VBO when there's room. Before, when we mapped the VBO for building list B, we did so with GL_MAP_WRITE_BIT only. Even though we were writing to an unused part of the buffer, the map would stall until the preceeding drawing call finished. Use the extra map flags and FlushMappedBufferRange() to avoid the stall. Reviewed-by: José Fonseca <[email protected]>
* vbo: assorted minor clean-upsBrian Paul2013-10-114-14/+14
| | | | | Use GL_TRUE/FALSE instead of 1/0. Remove extraneous parentheses. Remove trailing whitespace.
* vbo: Implement new gs prim types in vbo_count_tessellated_primitives.Paul Berry2013-09-091-0/+12
| | | | Reviewed-by: Matt Turner <[email protected]>
* mesa: Rename gl_context::swtnl_im to vbo_context; use proper type.Kenneth Graunke2013-09-032-3/+3
| | | | | | | | | | | | | | | The main GL context's swtnl_im field is the VBO module's vbo_context structure. Using the name "swtnl" in the name is confusing since some drivers use hardware texturing and lighting, but still rely on the VBO module for drawing. v2: Forward declare the type and use that instead of void * (suggested by Eric Anholt). v3: Remove unnecessary cast (pointed out by by Topi Pohjolainen). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa/main: Check for 0 size draws after validation.Fabian Bieler2013-08-271-0/+12
| | | | | | | | | | | | | | | | | | | When validating draw parameters move check for 0 draw count last (drawing with count 0 is not an error), so that other parameters (e.g.: the primitive type) are validated and the correct errors (if applicable) are generated. >From the OpenGL 3.3 spec page 33 (page 48 of the PDF): "[Regarding DrawArraysOneInstance, in terms of which other draw operations are defined:] If count is negative, an INVALID_VALUE error is generated." This patch also changes the bahavior of MultiDrawElements to perform the draw operation if some primitive's index counts are zero. Signed-off-by: Fabian Bieler <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* mesa/vbo: Fix handling of attribute 0 in non-compatibilty contextsIan Romanick2013-08-151-23/+59
| | | | | | | | | | | | | | | | It is only in OpenGL compatibility-style contexts where generic attribute 0 and GL_VERTEX_ARRAY have a bizzare, aliasing relationship. Moreover, it is only in OpenGL compatibility-style contexts and OpenGL ES 1.x where one of these attributes provokes the vertex. In all other APIs each implicit call to glArrayElement provokes a vertex regardless of which attributes are enabled. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Robert Bragg <[email protected]> Cc: "9.0 9.1 9.2" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55503 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66292 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67548
* mesa: add const qualifier to glMultiDrawElementsEXT() indices paramBrian Paul2013-06-262-2/+2
| | | | | | | | | | The 20130624 version of glext.h changed this to match the glMultiDrawElements() function which already had the extra const qualifier. Fixes warnings/errors that seem to vary from one compiler to the next. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: remove outdated version lines in commentsRico Schüller2013-06-0513-13/+0
| | | | Signed-off-by: Brian Paul <[email protected]>
* vbo: Use the new primitive restart index helper function.Kenneth Graunke2013-05-292-2/+3
| | | | | | | | | | | This gets the correct restart index for unsigned byte/short types when using GL_PRIMITIVE_RESTART_FIXED_INDEX. NOTE: This is a candidate for the 9.1 branch. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* vbo: Ignore PRIMITIVE_RESTART_FIXED_INDEX for glDrawArrays().Kenneth Graunke2013-05-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | The derived _PrimitiveRestart enable flag combines the PrimitiveRestart and PrimitiveRestartFixedIndex enable flags. However, DrawArrays is not supposed to do FixedIndex restart: From the OpenGL 4.3 Core specification, section 10.3.5 (page 302): "If PRIMITIVE_RESTART_FIXED_INDEX is enabled, primitive restart is not performed for array elements transferred by any drawing command not taking a type parameter, including all of the *Draw* commands other than *DrawElements*." The OpenGL ES 3.0 specification agrees by omission: "When DrawElements, DrawElementsInstanced, or DrawRangeElements transfers a set of generic attribute array elements to the GL..." Notably, DrawArrays is not included in the list of draw calls that take PRIMITIVE_RESTART_FIXED_INDEX into consideration. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: skip _MaxElement computation unless driver needs strict bounds checkingMarek Olšák2013-05-111-3/+23
| | | | | | | | | | | | If Const.CheckArrayBounds is false, the only code using _MaxElement is glDrawRangeElements, so I changed it and explained in the code why _MaxElement is not very useful there. BTW, the big magic number was copied to the letter from _mesa_update_array_max_element. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: add comments, const qualifiersBrian Paul2013-05-032-9/+24
| | | | Reviewed-by: José Fonseca <[email protected]>
* vbo: use new no-op ArrayElement in _mesa_noop_vtxfmt_init()Brian Paul2013-05-031-2/+7
| | | | | | As we do for the other commands which can appear between glBegin/End. Reviewed-by: José Fonseca <[email protected]>
* mesa; change ctx->Driver.SaveNeedFlush to boolean, and document it.Brian Paul2013-05-031-4/+4
| | | | Reviewed-by: José Fonseca <[email protected]>
* vbo: update comments for vbo_save_NotifyBegin()Brian Paul2013-05-031-2/+10
| | | | Reviewed-by: José Fonseca <[email protected]>
* vbo: implement primitive merging for glBegin/End sequencesBrian Paul2013-05-032-14/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A surprising number of apps and benchmarks have poor code like this: glBegin(GL_LINE_STRIP); glVertex(v1); glVertex(v2); glEnd(); // Possibly some no-op state changes here glBegin(GL_LINE_STRIP); glVertex(v3); glVertex(v4); glEnd(); // repeat many, many times. The above sequence can be converted into: glBegin(GL_LINES); glVertex(v1); glVertex(v2); glVertex(v3); glVertex(v4); glEnd(); Similarly for GL_POINTS, GL_TRIANGLES, etc. Merging was already implemented for GL_QUADS in the display list code. Now other prim types are handled and it's also done for immediate mode. In one case: before after ----------------------------------------------- number of st_draw_vbo() calls: 141 45 number of _mesa_prims issued: 7520 632 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* vbo: create a few utility functions for merging primitivesBrian Paul2013-05-032-0/+109
| | | | | | | To be used by following commit. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* mesa: remove GLvertexformat::EvalMesh1(), EvalMesh2()Brian Paul2013-05-024-146/+107
| | | | | | See previous commit comments. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: remove GLvertexformat::Rectf()Brian Paul2013-05-024-49/+22
| | | | | | As with the glDraw* functions, this doesn't have to be in GLvertexformat. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: simplify dispatch for glDraw* functionsBrian Paul2013-05-025-272/+0
| | | | | | | | | | | | Remove all the glDraw* functions from the GLvertexformat structure. The point of that dispatch struct is to handle all the functions which dispatch differently depending on whether we're inside glBegin/End. glDraw* are never allowed inside glBegin/End so we can remove those entries. This simplifies the code paths and gets rid of quite a bit of code. Reviewed-by: Jose Fonseca <[email protected]>
* vbo: add new vbo_initialize_exec_dispatch(), vbo_initialize_save_dispatch()Brian Paul2013-05-023-0/+68
| | | | | | First step in simplifying the vertex array / glDraw dispatch code. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: remove _MESA_INIT_EVAL_VTXFMT() macroBrian Paul2013-05-023-3/+24
| | | | Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 07:42:36 +0000