| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
|
Fixes segfaults with radeon winsys.
(Probably libdrm_radeon doing something that it shouldn't.)
|
|
Where vbo save nodes are terminated with a call to DO_FALLBACK(), as in
the case of a recursive CallList which is itself within a Begin/End pair,
there two problems:
1) The display list node's primitive information was incorrect, stating
the cut-off prim had zero vertices
2) On replay, we would get confused by a primitive that started in a
node, but was terminated by individual opcodes.
This change fixes the first problem by correctly terminating the last
primitive on fallback, and the second by forcing the display list to
use the Loopback path, converting all nodes into immediate-mode rendering.
The loopback fix is a performance hit, but avoiding this would require
a fairly large rework of this code.
|
|
Need this to pick up fixes for per-vertex materials.
|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
As prescribed by ARB_map_buffer_range.
|
|
Switch over to specialized enum lookup for primitives
|
|
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>
|
|
|
