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 <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
APPLE_vertex_array_object support was removed in 7927d0378f.
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: 7927d0378f ("mesa: drop APPLE_vertex_array_object support")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Shared context support for VAOs was dropped in 0b2750620b.
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 <nicolai.haehnle@amd.com>
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 <nicolai.haehnle@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This pattern was only useful when we used mutex locks, which the previous
commit removed.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
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 <nicolai.haehnle@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
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 <nicolai.haehnle@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
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 <anuj.phogat@gmail.com>
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 <mathias.froehlich@web.de>
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 <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Implement the equivalent of vbo_all_varyings_in_vbos for
vertex array objects.
v2: Update comment.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
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 <laura@jlekstrand.net>
This is a convenience function that generates GL_INVALID_OPERATION
when the array object doesn't exist.
Reviewed-by: Laura Ekstrand <laura@jlekstrand.net>
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 <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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 <imirkin@alum.mit.edu>
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 <kenneth@whitecape.org>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
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 1ccef926be).
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 <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Roland Scheidegger <sroland@vmware.com>
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 <brianp@vmware.com>
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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
_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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
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 <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
update_array() and update_array_format() are changed to update the new
attrib and binding states, and the client arrays become derived state.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will become derived state as part of the ARB_vertex_attrib_binding
support.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
