aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/main/arrayobj.c
Commit message (Collapse)AuthorAgeFilesLines
* mesa: inline save_array_object()Samuel Pitoiset2017-07-201-14/+1
| | | | | | | | No need to check if ID is not 0 because _mesa_HashFindFreeKeyBlock() can't generate this value. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: inline remove_array_object()Samuel Pitoiset2017-07-201-15/+1
| | | | | | | | No need to check if ID is not 0 because _mesa_lookup_vao() already prevents this to happen. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: tidy up _mesa_DeleteVertexArrays()Samuel Pitoiset2017-07-201-13/+12
| | | | | Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: simplify _mesa_IsVertexArray()Samuel Pitoiset2017-06-201-6/+1
| | | | | | | | | _mesa_lookup_vao() already returns NULL if id is zero. v2: - change the conditional (Ian) Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]> (v1)
* mesa: Remove GL_APPLE_vertex_array_object stubsIan Romanick2017-05-231-16/+0
| | | | | | | | | | | | | | | | | | Mark the functions 'exec="skip"' in the XML instead. libGL will still have the functions, but the driver won't try to use them. I verified that this commit works with piglit's 'object-namespace-pollution glClear vertex-array' on x64 with a driver built from mesa-12.0.3 tag. In fairness, this test also works with a libGL built from 7927d03. I believe it continues to work because on non-Windows platforms we generate some extra, dummy dispatch functions that can be used when a driver requests a function unknown to libGL. This was done to provide some "forward" compatibility with drivers that need more functions. This doesn't work on Windows because the Windows calling convention is for the callee to clean up the stack. That's the theory anyway. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: add APPLE_vertex_array_object stubsTimothy Arceri2017-05-221-0/+16
| | | | | | | | | | | APPLE_vertex_array_object support was removed in 7927d0378fc7. However it turns out we can't remove the functions because this can cause issues when libglapi is used together with DRI drivers built prior to said commit Fixes: 7927d0378fc ("mesa: drop APPLE_vertex_array_object support") Reviewed-by: Emil Velikov <[email protected]>
* mesa: tidy up left over APPLE_vertex_array_object semanticsTimothy Arceri2017-04-261-10/+1
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: inline bind_vertex_array() helperTimothy Arceri2017-04-261-17/+6
| | | | | | The previous commit removed the only other user of this function. Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: drop APPLE_vertex_array_object supportTimothy Arceri2017-04-261-53/+10
| | | | | | | | | | | | | | | | | | | | | Shared context support for VAOs was dropped in 0b2750620b65. From the ARB_vertex_array_object spec: "This extension differs from GL_APPLE_vertex_array_object in that client memory cannot be accessed through a non-zero vertex array object. It also differs in that vertex array objects are explicitly not sharable between contexts." Nobody should be using this extension over ARB_vertex_array_object anymore so just drop it rather than adding locking back just for VAOs created from these functions. For reference the Nvidia blob doesn't expose this extension. Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: don't lock hashtables that are not shared across contextsTimothy Arceri2017-04-221-4/+4
| | | | | | | | | | | | | | | | | | | From Chapter 5 'Shared Objects and Multiple Contexts' of the OpenGL 4.5 spec: "Objects which contain references to other objects include framebuffer, program pipeline, query, transform feedback, and vertex array objects. Such objects are called container objects and are not shared" For we leave locking in place for framebuffer objects because the EXT fbo extension allowed sharing. We could maybe just replace the hash with an ordinary hash table but for now this should remove most of the unnecessary locking. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa: Remove deleteFlag pattern from container objects.Matt Turner2017-04-221-3/+1
| | | | | | | | This pattern was only useful when we used mutex locks, which the previous commit removed. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa: Remove unnecessary locking from container objects.Matt Turner2017-04-221-6/+0
| | | | | | | | | | | | | | | | | | | From Chapter 5 'Shared Objects and Multiple Contexts' of the OpenGL 4.5 spec: "Objects which contain references to other objects include framebuffer, program pipeline, query, transform feedback, and vertex array objects. Such objects are called container objects and are not shared" For we leave locking in place for framebuffer objects because the EXT fbo extension allowed sharing. V2: (Timothy Arceri) - rebased and dropped changes to framebuffer objects Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa: remove fallback RefCount == 0 patternTimothy Arceri2017-04-221-10/+4
| | | | | | | | We should never get here if this is 0 unless there is a bug. Replace the check with an assert. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa: rename gl_client_array -> gl_vertex_arrayBrian Paul2016-10-281-2/+2
| | | | | | | | | | | The term "client array" is a legacy thing dating back to the pre-VBO era when _all_ vertex arrays lived in client memory. Nowadays, it only contains vertex array state which is derived from gl_array_attributes and gl_vertex_buffer_binding. It's used by the VBO module and some drivers. Reviewed-by: Anuj Phogat <[email protected]>
* mesa: code clean-up in _mesa_update_vao_client_arrays()Brian Paul2016-10-281-8/+5
| | | | | | Init vars where declared, use const qualifiers. Reviewed-by: Anuj Phogat <[email protected]>
* mesa: rename gl_vertex_array_object::VertexBinding to BufferBindingBrian Paul2016-10-281-6/+6
| | | | | | To be a little more understandable. Reviewed-by: Anuj Phogat <[email protected]>
* mesa: rename gl_vertex_attrib_array gl_array_attributesBrian Paul2016-10-131-4/+4
| | | | | | | The structure contains the attributes of a vertex array. The old name was kind of confusing. Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa: rename gl_vertex_attrib_array::VertexBindingBrian Paul2016-10-131-4/+4
| | | | | | | | | Rename to gl_vertex_attrib_array::BufferBindingIndex because this field is an index into the array of buffer binding points. This makes some code a little easier to follow since there's also a "VertexBinding" field in gl_vertex_array_object. Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa: rename some vars in arrayobj.cBrian Paul2016-10-131-24/+31
| | | | | | | Use 'vao' instead of 'obj' to be consistent with other code. Plus, add a comment. Reviewed-by: Mathias Fröhlich <[email protected]>
* mesa: Move _mesa_all_buffers_are_unmapped to arrayobj.c.Mathias Fröhlich2016-08-151-0/+28
| | | | | | | | | | Move the function to check if all vao buffers are unmapped into the vao implementation file. Rename the function to _mesa_all_buffers_are_unmapped. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Implement _mesa_all_varyings_in_vbos.Mathias Fröhlich2016-07-311-0/+35
| | | | | | | | | | Implement the equivalent of vbo_all_varyings_in_vbos for vertex array objects. v2: Update comment. Signed-off-by: Mathias Fröhlich <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Make use of u_bit_scan{,64}.Mathias Fröhlich2016-06-141-3/+3
| | | | | | Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa: remove old comments in arrayobj.cBrian Paul2015-11-111-5/+0
|
* mesa: remove Driver.BindArrayObjectMarek Olšák2015-10-031-4/+0
| | | | | | | Nothing sets it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.DeleteArrayObjectMarek Olšák2015-10-031-4/+2
| | | | | | | Nothing reimplements it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.NewArrayObjectMarek Olšák2015-10-031-3/+2
| | | | | | | Nothing reimplements it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Remove debugging code from _mesa_reference_*.Matt Turner2015-09-251-8/+0
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Revert "mesa: Add ARB_direct_state_access checks in VAO functions"Ian Romanick2015-05-281-22/+0
| | | | | | | This reverts commit 36b05793372b86b914d9b95d0188f5f387e01d68. Acked-by: Fredrik Höglund <[email protected]> Cc: "10.6" <[email protected]>
* mesa: Add ARB_direct_state_access checks in VAO functionsFredrik Höglund2015-05-141-0/+22
| | | | | Signed-off-by: Fredrik Höglund <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* mesa: Implement GetVertexArrayivFredrik Höglund2015-05-081-0/+34
| | | | Reviewed-by: Laura Ekstrand <[email protected]>
* mesa: Implement VertexArrayElementBufferFredrik Höglund2015-05-081-0/+41
| | | | | | v2: Add a doxygen comment. Reviewed-by: Laura Ekstrand <[email protected]>
* mesa: Keep track of the last looked-up VAOFredrik Höglund2015-05-081-13/+24
| | | | | | | | | | | | | | | This saves the cost of repeated hash table lookups when the same vertex array object is referenced in a sequence of calls such as: glVertexArrayAttribFormat(vao, ...); glVertexArrayAttribBinding(vao, ...); glEnableVertexArrayAttrib(vao, ...); ... Note that VAO's are container objects that are not shared between contexts. Reviewed-by: Laura Ekstrand <[email protected]>
* mesa: Add _mesa_lookup_vao_errFredrik Höglund2015-05-081-0/+47
| | | | | | | This is a convenience function that generates GL_INVALID_OPERATION when the array object doesn't exist. Reviewed-by: Laura Ekstrand <[email protected]>
* mesa: Implement CreateVertexArraysFredrik Höglund2015-05-081-8/+28
| | | | | | v2: Update the documentation for gen_vertex_arrays(). Reviewed-by: Laura Ekstrand <[email protected]>
* mesa/vbo: add support for 64-bit vertex attributes. (v1)Dave Airlie2015-05-081-0/+1
| | | | | | | | | | | | This adds support in the vbo and array code to handle double vertex attributes. v0.2: merge code to handle doubles in vbo layer. v1: don't use v0, merge api_array elt code. Acked-by: Ilia Mirkin <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa/main: replace Elements() with ARRAY_SIZE()Brian Paul2015-03-021-3/+3
| | | | | | | | We've been using a mix of these two macros for a while now. Let's just use the later everywhere. It seems to be the convention used by other open-source projects. Acked-by: Ilia Mirkin <[email protected]>
* mesa: Use assert() instead of ASSERT wrapper.Matt Turner2015-02-231-5/+5
| | | | Acked-by: Eric Anholt <[email protected]>
* mesa: Use VertexArray, not _VertexArray, in array size expressions.Kenneth Graunke2014-09-241-1/+1
| | | | | | | | | Both sizes are VERT_ATTRIB_MAX, so this has no effect. But it drops a few trivial uses of the derived state. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Fredrik Höglund <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Delete VAO _MaxElement code and index buffer bounds checking.Kenneth Graunke2014-09-191-46/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: fix crash in st/mesa after deleting a VAOMarek Olšák2014-07-111-0/+15
| | | | | | | | | | 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: switch to c11 mutex functionsBrian Paul2014-03-031-6/+6
| | | | Reviewed-by: José Fonseca <[email protected]>
* mesa: Drop unnecessary (void) ctx from VAO code.Kenneth Graunke2014-02-031-1/+0
| | | | | | | | | ctx is always used, even on release builds. 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: Remove "APPLE" from some VAO error messages.Kenneth Graunke2014-02-031-3/+3
| | | | | | | | | Chances are, people will be using the core names these days. 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: Update some comments relating to VAOs.Kenneth Graunke2014-02-031-1/+4
| | | | | | | 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 ElementArrayBufferObj to IndexBufferObj.Kenneth Graunke2014-02-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 _mesa_lookup_arrayobj to _mesa_lookup_vao.Kenneth Graunke2014-02-031-4/+4
| | | | | | | | | | | | | For consistency with the previous renames. Completely generated by: $ find . -type f -print0 | xargs -0 sed -i \ 's/_mesa_lookup_arrayobj/_mesa_lookup_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 _mesa_..._array_obj functions to _mesa_..._vao.Kenneth Graunke2014-02-031-16/+16
| | | | | | | | | | | | | | | _mesa_update_vao_client_arrays() is less of a mouthful than _mesa_update_array_object_client_arrays(), and generally clearer. Generated by: $ find . -type f -print0 | xargs -0 sed -i \ 's/_mesa_\([^_]*\)_array_object/_mesa_\1_vao/g' with manual whitespace and indentation fixes applied. 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-23/+23
| | | | | | | | | | | | | | | | | | 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-22/+22
| | | | | | | | | | | | | 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-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-13 11:06:56 +0000