Age | Commit message (Collapse) | Author |
|
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.
|
|
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)
|
|
This was sometimes seen when Glean exited upon test failure when using
Gallium.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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>
|
|
|
|
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
|
|
|
|
This fixed a minor bug but broke everything else.
This reverts commit 579ef8ab1984d895867f547afa60b3bec4c4599a.
|
|
|
|
|
|
Add asserts for expected values on wakeup and flush. Remove cases where
this flag is set or cleared except when waking up and flushing vbo module.
|
|
|
|
|
|
Conflicts:
scons/gallium.py
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/include/pipe/p_defines.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
|
|
Previously would have to allocate a new VBO after firing a draw command
as subsequent call to Map() on old VBO might block if the driver had
submitted the commands to hardware.
|
|
Provides notification to the VBO modules prior to the first immediate call.
Pairs with FlushVertices()
|
|
|
|
Only VBO uses the evaluator code so call _math_init_eval() there.
Only TNL uses the transform/translate code so call _math_init_transformation()
and _math_init_translate9) there.
This is a step toward resolving some symbol collisions between Mesa's and
gallium's x86 codegen.
Have VBO and TNL modules call _math_init_transformation()
|
|
Merge commit 'origin/gallium-0.2' into gallium-master-merge
Conflicts:
Makefile
docs/relnotes-7.4.html
docs/relnotes.html
src/mesa/drivers/dri/i965/brw_wm.h
src/mesa/main/imports.c
src/mesa/main/mtypes.h
src/mesa/main/texcompress.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_save_draw.c
|
|
Only 15 actually worked before since we always reserved generic[0] as an
alias for vertex position.
The case of vertex attribute 0 is tricky. The spec says that there is no
aliasing between generic vertex attributes 0..MAX_VERTEX_ATTRIBS-1 and the
conventional attributes. But it also says that calls to glVertexAttrib(0, v)
are equivalent to glVertex(v). The distinction seems to be in glVertex-mode
versus vertex array mode.
So update the VBO code so that if the shader uses generic[0] but not gl_Vertex,
route the attribute data set with glVertex() to go to shader input generic[0].
No change needed for the glDrawArrays/Elements() path.
This is a potentially risky change so regressions are possible. All the usual
tests seem OK though.
|
|
Rename some structs and fields to be more consistant with the rest of mesa.
|
|
Should help to solve failed assertion in i965 driver (see bug 19708)
|
|
Conflicts:
src/gallium/auxiliary/gallivm/instructionssoa.cpp
src/gallium/auxiliary/gallivm/soabuiltins.c
src/gallium/auxiliary/rtasm/rtasm_x86sse.c
src/gallium/auxiliary/rtasm/rtasm_x86sse.h
src/mesa/main/texenvprogram.c
src/mesa/shader/arbprogparse.c
src/mesa/shader/prog_statevars.c
src/mesa/state_tracker/st_draw.c
src/mesa/vbo/vbo_exec_draw.c
|
|
Also, fix up some comments to be doxygen style.
|
|
|
|
Keep track of enabled/active vertex attributes.
Keep track of potential vertex program outputs.
When generating fragment program, replace references to fragment attributes
which are effectively non-varying and non-computed passthrough attributes with
references to the new CURRENT_ATTRIB tracked state value.
Only downside is slight ugliness in VBO code where we need to validate state
twice in succession.
|
|
|
|
Conflicts:
src/mesa/vbo/vbo.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
The VBO module may use a real VBO or a malloc'd buffer for vertex storage.
Be careful not to accidentally replace the later with the former when drawing.
Check if using a real VBO at destroy time to prevent a double-free.
|
|
Also use BufferData(NULL) to get fresh storage and avoid synchronous
operation where we would have to flush and wait for the fence after each
draw because of the map.
This will chew through a whole load of buffer space on small draws, so
it isn't a proper solution. Need to support a no-fence or append mapping
mode to do this right, or use user buffers.
|
|
put into bufferobjects
|
|
(cherry picked from commit 026e7731e549e0777c010348460fd48b3d75a843)
|
|
(cherry picked from commit 8a369b909a6648ae7a5a0c2dcb972a2f96f99a80)
|
|
|
|
|
|
Also, check the FEATURE flags in many places.
(cherry picked from commit 40d1a40f294f1ed2dacfad6f5498322fc08cc2d1)
Conflicts:
src/mesa/main/config.h
src/mesa/main/context.c
src/mesa/main/texobj.c
src/mesa/main/texstate.c
src/mesa/main/texstore.c
|