Age | Commit message (Collapse) | Author |
|
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.
|
|
This feature corresponds to the Begin/End paradigm. Disabling this
feature also eliminates the use of GLvertexformat completely.
|
|
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.
|
|
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
|
Fixes segfaults with radeon winsys.
(Probably libdrm_radeon doing something that it shouldn't.)
|
|
Need this to pick up fixes for per-vertex materials.
|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
As prescribed by ARB_map_buffer_range.
|
|
Switch over to specialized enum lookup for primitives
|
|
|
|
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.
|
|
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
|
|
|
|
This fixed a minor bug but broke everything else.
This reverts commit 579ef8ab1984d895867f547afa60b3bec4c4599a.
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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 8a369b909a6648ae7a5a0c2dcb972a2f96f99a80)
|
|
Use new _mesa_reference_buffer_object() function wherever possible.
Fixes buffer object/display list crash reported in ParaView.
|
|
Use new _mesa_reference_buffer_object() function wherever possible.
Fixes buffer object/display list crash reported in ParaView.
|
|
|
|
This fixes problems with incorrect material coefficients when glMaterial
is called per-vertex.
|
|
This fixes problems with incorrect material coefficients when glMaterial
is called per-vertex.
|
|
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
|
|
of -I flags.
|
|
|
|
|
|
NV_vertex_program implementation has slightly incorrect aliasing
behaviour. I think this is reasonable given the simplification and
the fact that the mainstream ARB_vp continues to have the correct
behaviour.
|
|
|
|
rather than VBO's - VBOs are easy but need to look closer at the
driver interface. The trivial/tri demo works.
|