| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
This was sometimes seen when Glean exited upon test failure when using
Gallium.
|
|
Conflicts:
Makefile
src/mesa/main/version.h
src/mesa/shader/slang/slang_preprocess.c
src/mesa/state_tracker/st_cb_bufferobjects.c
|
|
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.
|
|
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
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>
|
|
|
|
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()
|
|
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.
|
|
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
|
|
|
|
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.
|
|
put into bufferobjects
|
|
(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
|
|
gallium-0.2
Conflicts:
src/mesa/drivers/dri/i915/intel_ioctl.c
src/mesa/main/texstore.c
src/mesa/tnl/t_vp_build.c
src/mesa/vbo/vbo_exec_draw.c
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Also, check the FEATURE flags in many places.
|
|
Cherry-picked from master.
|
|
rendering
Revert commit d08cd68d3f5456b69ad504ede2b090c0bb6474db
This change caused some glean tests to fail. The alpha value of colors was
always 1.0 instead of the value from glColor4fv(). The mesa color array
found in st_draw() has size=3 instead of size=4.
|
|
Often these are mixed in with draw arrays calls, etc. Try not to get
the whole immediate rendering state machine going when we receive one
of these on their own.
|
|
|
|
|
|
put into bufferobjects
|
