| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Previously, MultiDrawElements just called DrawElements a bunch of times.
By sending several primitives down the pipeline at once, we avoid a bunch
of validation. On my GL demo, this improves fps by 2.5% (+/- .41%) and
reduces CPU usage by 70.5% (+/- 2.9%) (n=3).
Reviewed by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
We would end up with the offset from the start of the mapping rather than
the offset from the start of the buffer.
|
|\ |
|
| |
| |
| |
| | |
Fixes bug 23489.
|
| |
| |
| |
| | |
Fixes bug 23489.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win (50-100% in my app)
because even though we let the indices stay in both CPU and GPU caches, we
still end up waiting for the GPU to be done with the buffer before reading
from it.
Drivers that want the min/max_index fields must now check index_bounds_valid
and use vbo_get_minmax_index before using them.
|
| | |
|
|\| |
|
| |
| |
| |
| | |
Based on a patch by [email protected]
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| | |
| | |
| | | |
Switch over to specialized enum lookup for primitives
|
| | |
| | |
| | |
| | |
| | | |
Fixes segfaults with radeon winsys.
(Probably libdrm_radeon doing something that it shouldn't.)
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | | |
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
| |/
| |
| |
| | |
As prescribed by ARB_map_buffer_range.
|
| |
| |
| |
| |
| |
| | |
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.
|