| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
| |
_mesa_alloc_instruction() sounded like it was related to vertex/fragment
program instructions, but it wasn't.
|
|
|
|
|
| |
This feature corresponds to the Begin/End paradigm. Disabling this
feature also eliminates the use of GLvertexformat completely.
|
|
|
|
|
| |
As shown in mfeatures.h, this allows users of dlist.h to work without
knowing if the feature is available.
|
|
|
|
|
| |
As shown in mfeatures.h, this allows users of eval.h to work without
knowing if the feature is available.
|
|
|
|
| |
This allows the removal of AEcontext.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/vbo/vbo_exec_array.c
|
| |
| |
| |
| | |
Otherwise some apps will emit tons of warnings.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the 'end' index is out of bounds issue a warning as before. But instead
of just no-op'ing the draw call, examine the actual array indices to see
if they're OK. If the max array index is out of bounds, issue another
warning and no-op the draw call. Otherwise, draw normally. This is a
debug build-only feature since it could impact performance.
This "fixes" the missing torus in the OGL Distilled / Picking demo.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was introduced with commit 92d7ed8a20d4a018ce5324e6537ae7b478b9e5bf.
It causes rendering of stray polygons (with sw rendering at least) when
running the OGL Distilled / Picking demo (click on an object).
This needs additional debugging to fix/restore.
Found one suspect thing: in _tnl_draw_prims() there's some mixed signed/
unsigned arithmetic/comparing at line 422 that may be incorrect.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the 'end' index is out of bounds issue a warning as before. But instead
of just no-op'ing the draw call, examine the actual array indices to see
if they're OK. If the max array index is out of bounds, issue another
warning and no-op the draw call. Otherwise, draw normally. This is a
debug build-only feature since it could impact performance.
This "fixes" the missing torus in the OGL Distilled / Picking demo.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|