| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
This value is per array object.
|
|
|
|
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
No-op the bad drawing command rather than go out of bounds and render
garbage. Print a warning to alert the developer to the bad drawing call.
|
|
|
|
|
|
And use GL_ELEMENT_ARRAY_BUFFER where appropriate.
|
|
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.
|
