summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Set the "Integer" field of gl_client_array properly.Paul Berry2011-11-021-0/+1
| | | | | | | | | | | This patch ensures that gl_client_array::Integer is properly set to GL_TRUE for vertex attributes specified using glVertexAttribIPointer, and to GL_FALSE for vertex attributes specified using glVertexAttribPointer, so that the vertex attributes can be interpreted properly by driver back-ends. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* vbo: Clean up unused variables in the vbo module.Mathias Froehlich2011-10-223-16/+1
| | | | | Remove some unused or unused but set variables from the vbo module.
* vbo: Redeclare bind_array() as non-static vbo_bind_array()Chad Versace2011-10-182-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is necessary because i965 will need to call vbo_bind_array() when cleaning up after a buffer resolve meta-op. Detailed Explanation -------------------- The vbo module tracks vertex attributes separately from the gl_context. Specifically, the vbo module maintins vertex attributes in vbo_exec_context::array::inputs, which is synchronized with gl_context::Array::ArrayObj::VertexAttrib by vbo_bind_array(). vbo_draw_arrays() calls vbo_bind_array() to perform the synchronization before calling the real draw call, vbo_context::draw_arrays. Intel hardware accomplishes buffer resolves with a meta-op. Frequently, that meta-op must be performed within glDraw* in the moment immediately before the draw occurs (The hardware designers hate us...). After performing the meta-op, but before calling vbo_bind_array(), the gl_context's vertex attributes will have been restored to their original state (that is, their state before the meta-op began), but the vbo module's vertex attribute are those used in the last meta-op. Therefore we must manually synchronize the two with vbo_bind_array() before continuing with the original draw command (that is, the one requested with glDraw*). See brw_predraw_resolve_buffers(), which will be added in a future commit. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: Add dd_function_table::PrepareExecBeginChad Versace2011-10-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This hook allows the driver to prepare for a glBegin/glEnd. i965 will use the hook to avoid avoid recursive calls to FLUSH_VERTICES during a buffer resolve meta-op. Detailed Justification ---------------------- When vertices are queued during a glBegin/glEnd block, those vertices must of course be drawn before any rendering state changes. To enusure this, Mesa calls FLUSH_VERTICES as a prehook to such state changes. Therefore, FLUSH_VERTICES itself cannot change rendering state without falling into a recursive trap. This precludes meta-ops, namely i965 buffer resolves, from occuring while any vertices are queued. To avoid that situation, i965 must satisfy the following condition: that it queues no vertex if a buffer needs resolving. To satisfy this, i965 will use the PrepareExecBegin hook to resolve all buffers on entering a glBegin/glEnd block. -------- v2: Don't add dd_function_table::CleanupExecEnd. Anholt and I discovered that hook to be unnecessary. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa/vbo: Treat attribute 0 and vertex as the sameIan Romanick2011-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is supported by the pseudo-code on pages 27 and 28 (pages 41 and 42 of the PDF) of the OpenGL 2.1 spec. The last part of the implementation of ArrayElement is: if (generic attribute array 0 enabled) { if (generic vertex attribute 0 array normalization flag is set, and type is not FLOAT or DOUBLE) VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element i); else VertexAttrib[size][type]v(0, generic vertex attribute 0 array element i); } else if (vertex array enabled) { Vertex[size][type]v(vertex array element i); } Page 23 (page 37 of the PDF) of the same spec says: "Setting generic vertex attribute zero specifies a vertex; the four vertex coordinates are taken from the values of attribute zero. A Vertex2, Vertex3, or Vertex4 command is completely equivalent to the corresponding VertexAttrib* command with an index of zero." Fixes piglit test attribute0. NOTE: This is a candidate for stable branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Revert "vbo: Don't discount stride == 0 for testing all varyings in VBOs."Eric Anholt2011-10-011-1/+2
| | | | | | | | | | | | | | | | | This reverts commit d631c19db47181129811080bfa772b210d762d4d. The commit was broken, and ended up returning false all the time because nobody in the world binds every single possible vertex array. On further reflection, we don't want to discount stride == 0: This function is just used for deciding to calculate whether to compute the bonuds on the index, and there's no sense in computing index bounds when stride == 0. For the separate question of "how much data do I upload for this vertex element?", the i965 driver was fixed to upload the data. Fixes a regression of about 2x in 3DMMES, and most importantly, makes Hammerfight playable.
* mesa: s/INLINE/inline/Brian Paul2011-10-014-12/+12
| | | | | | | INLINE is still seen in some files (some generated files, etc) but this is a good start. Acked-by: Kenneth Graunke <[email protected]>
* mesa: check glBegin()/glDrawArrays()/etc mode with _mesa_valid_prim_mode()Brian Paul2011-09-211-0/+7
| | | | | | | | | We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was done in Yuanhan Liu's original patch. Take geometry shaders support into account too. Reviewed-by: Yuanhan Liu <[email protected]>
* mesa: fix error handling for glMaterial*Yuanhan Liu2011-09-201-1/+12
| | | | | | | | | | | | | | | Trigger GL_INVALID_ENUM error if the face paramter is not a valid value. Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side [0, ctx->Constant.MaxShiniess]. v2: fix the max shininess value. v3: suggested by Brian, move the face check into glMaterialfv function to reduce code duplicate. Also, refactor the error message. Signed-off-by: Yuanhan Liu <[email protected]> Signed-off-by: Brian Paul <[email protected]>
* mesa/vbo: s/inline/INLINE/Vinson Lee2011-09-061-6/+6
| | | | MSVC does not support inline keyword.
* mesa/vbo: add ARB_vertex_type_2_10_10_10_rev APIs.Dave Airlie2011-09-063-2/+490
| | | | | | | | | | | | | | | This adds the vertex processing paths for the 2101010 types. It converts the attributes to floats for all the immediate entry points, some entrypoints are normalised and the attrib APIs take a normalized parameter. There are four main paths, ui10 -> float unnormalized i10 -> float unnormalized ui10 -> float normalized i10 -> float normalized along with the ui2/i2 equivs. Signed-off-by: Dave Airlie <[email protected]>
* mesa/tnl_dd: Remove unused header file t_dd_rendertmp.hIan Romanick2011-08-261-2/+1
| | | | | | | | | | Acked-by: Kristian Høgsberg <[email protected]> Acked-by: Marek Olšák <[email protected]> Acked-by: Alan Coopersmith <[email protected]> Acked-by: Jakob Bornecrantz <[email protected]> Acked-by: Dave Airlie <[email protected]> Build-Tested-by: Jakob Bornecrantz <[email protected]> Tested-by: Eugeni Dodonov <[email protected]>
* vbo: remove unused var, remove unneeded local varBrian Paul2011-08-241-4/+1
|
* mesa: Only map the necessary buffer range in vbo_get_minmax_indexIan Romanick2011-08-231-4/+19
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Eliminate dd_function_table::MapBufferIan Romanick2011-08-236-31/+35
| | | | | | | | | | Replace all calls to dd_function_table::MapBuffer with appropriate calls to dd_function_table::MapBufferRange, then remove all the cruft. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::FlushMappedBufferRangeIan Romanick2011-08-231-2/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::MapBufferRangeIan Romanick2011-08-231-2/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::GetBufferSubDataIan Romanick2011-08-231-1/+1
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::MapBufferIan Romanick2011-08-236-18/+7
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Remove target parameter from dd_function_table::UnmapBufferIan Romanick2011-08-237-17/+12
| | | | | | | | | | No driver used that parameter, and most drivers ended up with a bunch of unused-parameter warnings because it was there. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: fix !FEATURE_GL buildChia-I Wu2011-08-211-18/+18
| | | | | | | Move vbo_exec_FlushVertices_internal out of FEATURE_beginend. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* vbo: do not call _mesa_max_buffer_index in debug buildsMarek Olšák2011-08-051-3/+1
| | | | | | | | | That code drops performance in Unigine Heaven and Tropics by a factor of 10. That's too crazy even for a debug build. NOTE: This is a candidate for the 7.11 branch. Reviewed-by: Brian Paul <[email protected]>
* vbo: minor optimisation in vbo_exec_DrawRangeElementsDave Airlie2011-07-141-3/+3
| | | | | | | | this moves getting the context into the debug in this function, just spotted it trawling callgrind traces for other things. Signed-off-by: Dave Airlie <[email protected]>
* vbo: Don't discount stride == 0 for testing all varyings in VBOs.Eric Anholt2011-06-231-2/+1
| | | | | | | | | | | | | | | | | In fixed function, stride == 0 (e.g. glColor4f() outside of the draw call) would get turned into uniform inputs, which is why it was ignored originally in this test. For shaders, drivers end up seeing a need to upload stride == 0 data, and get confused by needing to upload when vbo_all_varyings_in_vbos() returned true. In the 965 driver case, it wouldn't bother to compute the min/max index, and uploaded nothing if the min/max wasn't known. We've talked about removing the ff stride=0-into-uniforms code, so this check shouldn't be missed once that's gone. Fixes ARB_vertex_buffer_object/mixed-immediate-and-vbo Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37934 Reviewed-by: Brian Paul <[email protected]>
* vbo: Don't bother checking for stride == 0 for "any varying in a VBO".Eric Anholt2011-06-231-2/+1
| | | | | | | We would still want to consider that data as being in a VBO even if we managed to produce this case, which as far as I know we can't. Reviewed-by: Brian Paul <[email protected]>
* vbo: minor simplification in print_draw_arrays() debug functionBrian Paul2011-06-131-4/+4
|
* vbo: run 'indent' on vbo_save_api.cBrian Paul2011-06-081-362/+456
|
* vbo: rename DO_FALLBACK -> dlist_fallbackBrian Paul2011-06-081-9/+9
|
* vbo: remove node->count > 0 test in vbo_save_playback_vertex_list()Brian Paul2011-06-081-9/+11
| | | | | | | | | | | | | | See piglit dlist-fdo31590.c test and http://bugs.freedesktop.org/show_bug.cgi?id=31590 In this case we had node->prim_count=1 but node->count==0 because the display list started with glBegin() but had no vertices. The call to glEvalCoord1f() triggered the DO_FALLBACK() path. When replaying the display list, the old condition basically no-op'd the call to vbo_save_playback_vertex_list call(). That led to the invalid operation error being raised in glEnd(). NOTE: This is a candidate for the 7.10 branch.
* vbo: check array indexes to prevent negative indexingBrian Paul2011-06-082-10/+13
| | | | | | See the piglit dlist-fdo31590.c test NOTE: This is a candidate for the 7.10 branch.
* vbo: added a commentBrian Paul2011-06-081-1/+1
|
* mesa: add implementation of glDrawElementsInstancedBaseVertexPierre-Eric Pelloux-Prayer2011-06-021-1/+26
| | | | Signed-off-by: Brian Paul <[email protected]>
* vbo: init prim[] array with memset()Brian Paul2011-04-151-6/+2
| | | | This fixes a Coverity warning about uninitialized data.
* mesa: Update _ElementSize in a few more places.José Fonseca2011-04-073-0/+5
|
* mesa: Update _ElementSize.Brian Paul2011-04-074-0/+5
|
* mesa/st: Prevent 'end' < 'start' in vbo_exec_DrawRangeElementsBaseVertex()José Fonseca2011-04-071-1/+6
| | | | | | | | We adjust 'end' to fit into _MaxElement, but that may result into a 'start' value bigger than 'end' being passed downstream, causing havoc. This could be seen with arb_robustness_draw-vbo-bounds, due to an application bug.
* vbo: mark vertex arrays as dirty when re-bindingMarek Olšák2011-03-081-1/+12
| | | | | This fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34378
* vbo: fix error parameterBrian Paul2011-03-021-1/+1
| | | | Spotted by Ian.
* vbo: add vbo_always_unmap_buffers()Brian Paul2011-03-013-1/+22
| | | | | | Drivers can call this function as needed. It tells the VBO module to always unmap the current glBegin/glEnd VBO when we flush. Otherwise it's possible to be in a flushed state but still have the VBO mapped.
* vbo: generate GL_INVALID_VALUE for bad glVertexAttrib indexBrian Paul2011-03-013-26/+26
|
* vbo: silence unused var warningBrian Paul2011-02-281-0/+1
|
* vbo: added vbo_check_buffers_are_unmapped() debug functionBrian Paul2011-02-222-0/+19
|
* vbo: removed unused #defines, add commentsBrian Paul2011-02-221-3/+6
|
* vbo: simplify NeedFlush flag clearingBrian Paul2011-02-221-4/+1
|
* vbo: use ctx intstead of exec->ctxBrian Paul2011-02-221-8/+8
|
* vbo: more commentsBrian Paul2011-02-211-0/+5
|
* vbo: make vbo_exec_FlushVertices_internal() staticBrian Paul2011-02-212-22/+20
|
* vbo: remove old debug code, add commentsBrian Paul2011-02-211-4/+8
|
* vbo: rename, document function paramsBrian Paul2011-02-211-5/+5
|
* vbo: commentsBrian Paul2011-02-211-0/+8
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 04:24:32 +0000