Age | Commit message (Collapse) | Author |
|
|
|
It's called in vbo_exec_invalidate_state too.
|
|
|
|
The current state is allowed to be undefined past DrawElements et al.
Consequently omit that copying at least in the display list code.
This pays us some percents performance.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Attribute 0 has no special meaning in GLES2. Add VertexAttrib4f_nopos
for that purpose and make _es_VertexAttrib* call the new function.
Rename _vbo_* to _es_* to avoid confusion. These functions are only
used by GLES, and now some of them (_es_VertexAttrib*) even behave
differently than vbo_VertexAttrib*.
|
|
There is no need to have a special version of ATTR for
!FEATURE_beginend, since 81ccb3e2ce708619f4c23537a237d61bdffdd35f.
|
|
Rebuilding the vertex format from scratch every time we see a new
vertex attribute is rather costly, new attributes can be appended at
the end avoiding a copy to current and then back again, and the full
attr pointer recalculation.
In the not so likely case of an already existing attribute having its
size increased the old behavior is preserved, this could be optimized
more, not sure if it's worth it.
It's a modest improvement in FlightGear (that game punishes the VBO
module pretty hard in general, framerate goes from some 46 FPS to 50
FPS with the nouveau classic driver).
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Conflicts:
src/mapi/glapi/glapi_sparc.S
src/mapi/glapi/glapi_x86.S
src/mapi/glapi/glapidispatch.h
src/mapi/glapi/glapioffsets.h
src/mapi/glapi/glprocs.h
|
|
The integers still get converted to floats. That'll have to change someday.
|
|
|
|
Use macros to access _glapi_table consistently. There is no functional
change.
|
|
We handle splitting of glDrawArrays() calls into two primitives here
so that drivers don't have to worry about it.
|
|
Just always check for FLUSH_UPDATE_CURRENT and call Driver.BeginVertices
when necessary. By using the unlikely() macros, this ends up as
a 10% performance improvement (for isosurf, anyway) over the old,
complicated function pointer swapping.
|
|
|
|
There was a check to only do the rebase if we didn't have everything
in VBOs, but nexuiz apparently hands us a mix of VBOs and arrays,
resulting in blocking on the GPU to do a rebase.
Improves nexuiz 800x600, high-settings performance on my Ironlake 41%
(+/- 1.3%), from 14.0fps to 19.7fps.
|
|
|
|
For GLX 1.3 drawables, we can destroy the DRI2 drawable when the GLX
drawable is destroyed. However, for legacy drawables, there os no
good way of knowing when the application is done with it, so we just
let the DRI2 drawable linger on the server. The server will destroy
the DRI2 drawable when it destroys the X drawable or the client exits
anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=30109
|
|
|
|
mtypes.h does not use any symbols from compiler.h.
Also add the required headers for files that depended on symbols from
compiler.h but were indirectly including compiler.h through mtypes.h.
|
|
|
|
_vbo_Materialf calls _vbo_Materialfv, which uses the params argument as
an array.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vbo/vbo_save* are the last members on the omit list. Test FEATURE_dlist
in the sources and remove the omit list.
|
|
|
|
This let's us drop stubs.c.
|
|
Fixes failed assertion from fd.o bug 27713.
The assertion was added with the new resource/transfer changes.
This patch could apply to the 7.8 branch but it's not essential.
|
|
|
|
vbo_split_copy was passing one past the max_index to draw function
which caused _tnl_draw_prims function to read uninitialized values
from copied array.
Bug was spoted in valgrind report of progs/tests/cva_huge.
|
|
Signed-off-by: Jeff Smith <whydoubt@yahoo.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
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.
|