Age | Commit message (Collapse) | Author |
|
Be clearer that this is the number of generic vertex program/shader
attributes, not counting the legacy attributes (pos, normal, color, etc).
(cherry picked from commit 4a95185c9f30c2de7a03bb1a0653f51b53b1111d)
|
|
If we're running a vertex program to emulated fixed-function, we still need
to treat vertex arrays/attributes as if we're in fixed-function mode.
This should probably be back-ported to Mesa 7.5 after a bit more testing.
(cherry picked from commit dda82137d28aba846dda73da230871c115e30aaf)
|
|
I was rather confused when mesa_print_display_list didn't show any of
my glBegin()..glEnd(). Nothing but print_list appears to call
this function, so matching its behavior seems like a good idea.
|
|
Reverts part of commit d7ea9ddf5824556e47decac7ba200f37cf1e552f.
We were calling _mesa_reference_buffer_object() on some heap-allocated
memory that was uninitialized and could trigger an assertion.
We can actually go back to "looser" ref counting of the Null/default
buffer object in these cases.
|
|
|
|
|
|
This was sometimes seen when Glean exited upon test failure when using
Gallium.
|
|
Conflicts:
Makefile
src/mesa/main/version.h
src/mesa/shader/slang/slang_preprocess.c
src/mesa/state_tracker/st_cb_bufferobjects.c
|
|
|
|
We were adding references to the input arrays, but failing to drop
them on destruction. This could lead to a 64kb buffer being leaked
each context destruction.
|
|
|
|
|
|
|
|
|
|
Subtract 1 from _MaxElement to be clearer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a vertex shader uses generic vertex attribute 0, but not gl_Vertex,
we need to set attribute[16] to point to attribute[0]. We were setting the
attribute size, but not the pointer.
Fixes crash in glsl/multitex.c when using the VertCoord attribute instead
of gl_Vertex.
|
|
Be clearer that this is the number of generic vertex program/shader
attributes, not counting the legacy attributes (pos, normal, color, etc).
|
|
|
|
|
|
|
|
The generic_array[] is 16 elements in size, but the loop was doing 32
iterations. The out of bounds array write was clobbering the following
inputs[] array but as luck would have it, that didn't matter.
|
|
|
|
We don't really implement vertex weights but in the VBO code this
fixes and odd case for the legacy_array[] setup. Before, the
vbo->draw_prims() call was always indicating that the vertex weight
array was present/enabled when it really wasn't.
|
|
If we're running a vertex program to emulated fixed-function, we still need
to treat vertex arrays/attributes as if we're in fixed-function mode.
This should probably be back-ported to Mesa 7.5 after a bit more testing.
|
|
|
|
This value is per array object.
|
|
|
|
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
No-op the bad drawing command rather than go out of bounds and render
garbage. Print a warning to alert the developer to the bad drawing call.
|
|
|
|
|
|
And use GL_ELEMENT_ARRAY_BUFFER where appropriate.
|
|
Avoids repeated mapping of the VBO buffer on display list replay. We
need access to the final vertex in order to update the GL current attrib
values.
|
|
|
|
Previous change broke redbook/polys and probably others. I'm fairly
sure that drivers like r300 don't need to touch
ctx->Driver.NeedVertices, but this code is incredibly fragile and I'm
not confident about removing it from there. Hopefully this gets
things working again.
|
|
This variable is being used in the r300 driver to trigger a flush under
circumstances unrelated to the use in the vbo module. Tighten up the
checks in vbo so as to avoid conflict with r300.
Reported by Maciej Cencora <m.cencora@gmail.com>
|
|
|
|
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
|
|
|
|
This fixed a minor bug but broke everything else.
This reverts commit 579ef8ab1984d895867f547afa60b3bec4c4599a.
|
|
|
|
|