| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Jeff Smith <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
glapi/dispatch.h is a core Mesa header file. Move the header file to
main/ to make this clear. It also becomes clear after this change that
IN_DRI_DRIVER is only used in core Mesa to enable the remap table.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
|
|
| |
Seems to be a regression from commit 60b08eb1fdf287d28ec66b9282513ab35a61aee0.
(cherry picked from commit c5a4cfb03ff17955c049f16ac805f5837ea4b633)
|
|
|
|
|
|
|
|
| |
This object can be shared with another context, so we cannot just
delete it when the owning context is being destroyed.
Ensuring that buffer objects are properly refcounted guarantees
NullBufferObj is destroyed when all references to it are removed.
|
|
|
|
|
|
|
|
| |
Always use _mesa_reference_buffer_object, and never call
ctx->Driver.DeleteBuffer() directly to prevent dangling pointers to the
null buffer object.
This fixes crash/assertions in sharedtex_mt and Autodesk Mudbox.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The in-place splitting code wasn't dealing with index buffers at all
(and it was being called from vbo_split_prims for too big index
buffers, causing some occasional corruption).
Additionally, it wasn't taking into account primitives arrays with
non-contiguous indices (e.g. given prim[0].start = 0 and prim[1].start
= max_verts, it would happily call back the driver with (max_index -
min_index) still greater than max_verts, causing infinite recursion).
It still doesn't handle too large indexed vertex buffers: use
vbo_split_copy for that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2708ddfb06a36d8568e2aa130bf1f7d551fcd309 caused a few regressions.
We need to check/validate state after calling bind_arrays() because
it might set the _NEW_ARRAYS flag if the varying VP inputs change.
The symptom of this problem was some attribute arrays being ignored
(or interpreted as constant-valued) in glDrawRangeElements or
glMultiDrawElements.
A follow-on patch will add some additional asserts to try to catch
this kind of thing in the future.
(cherry picked from commit 3cba779e16935f7c3a0bfd8af48bd5e015068e96)
|
|
|
|
|
|
|
|
|
|
|
|
| |
builds.
The driver (or preferably the hardware) should handle out of bounds
indices.
If there are problems then it's better to detect those in the debug
builds.
(cherry picked from commit e3257912e006120f6ab611e77005eed1a464030a)
|
|
|
|
| |
Reported by Karl Schultz.
|
|
|
|
|
| |
If we determine that the 'end' parameter to glDrawElements() is out of
bounds, clamp it to the max legal index value.
|
|
|
|
|
| |
Some apps are sloppy with their start/end values. Clamp them to
max possible values to prevent problems later.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Fixes bug 25525.
Plus, the GL_NV_vertex_program evaluators alias and override the
convential evaluator maps, so set their state after the conventional
maps.
|
| |
| |
| |
| | |
This fixes invalid failed assertions when running multi-threaded apps.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/windows/gdi/mesa.def
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The exec->vtx.inputs[] array was being written past its end. This was
clobbering the following vbo_exec_context::eval state. Probably not noticed
since evaluators and immediate mode rendering don't happen at the same time.
Fixed the loop in vbo_exec_vtx_init().
Changed the size of the vbo_exec_context::vtx.arrays[] array.
Added a bunch of debug-build assertions.
Issue found by Vinson Lee.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
_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.
|