Need to add the 'offset' parameter when indexing the parameter array.
Before, if we were setting arrays of samplers, we were actually only
setting the 0th sampler's value.
Because of how progs/glsl/samplers.c is constructed, this wasn't showing
up as a failure in the samplers_array output.
If a fragment program only parameter was queried of a vertex program
(e.g., GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB) no error would be set and
a random value would be returned. This caused 'glxinfo -l' to show
the same values for GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB,
GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB as for
GL_MAX_PROGRAM_ENV_PARAMETERS_ARB. This is confusing and incorrect.
(cherry picked from master, commit 4bccd693a7)
When a single-buffered window was resized the new window size was never
detected. This fix that, but there's still a bug which causes window
contents corruption for certain window sizes...
When adding a new bitmap to the cache we have to check if the Z value is
changing and flush first if it is.
This is a modified version of a patch from Justin Dou <justin.dou@intel.com>
SOA dependencies can happen when a register is used both as a source and
destination and the source is swizzled. For example:
MOV T, T.yxwz; would expand into:
MOV t0, t1;
MOV t1, t0;
MOV t2, t3;
MOV t3, t2;
The second instruction will produce the wrong result since we wrote to t0
in the first instruction. We need to use an intermediate temporary to fix
this.
This will take more work to fix for all TGSI instructions. This seems to
happen with MOV instructions more than anything else so fix that case now
and warn on others.
Fixes piglit glsl-vs-loop test (when not using SSE). See bug 23317.
This prevents the driver from discarding a buffer when the whole buffer
is mapped for writing, but only a portion is effectively written.
This is a temporary fix, because WRITE shouldn't imply DISCARD.
The full fix implies using PIPE_BUFFER_USAGE_DISCARD, throughout
the code, and will go only into master.
This previously was used only for decomposed (POINT/LINE/TRI) primitives,
but for some time a full range of primitives could end up in here.
Fixes trivial/lineloop-clip on softpipe, among others.
(cherry picked from commit 87cd8a3b8a2407b30916be418ff2f95dfea5d2ad)
This fixes crash in r200 KMS driver when pSAREA was set to 1 randomly because of memory wasn't cleared.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
We now handle the case of blitting Z+stencil to/from combined Z/stencil
surfaces. But Z-only or stencil-only and separate depth/stencil surfaces
are not yet implemented.
Need to check for Y inversion separately for src/dest buffers.
If both the src and dest regions are upside down, make them right-side
up for a better chance at a fast path.
progs/tests/copypixrate -blit is much faster now.
The comment disagreed with the code, and nicely drew my eyes to what was
going wrong.
Bug #21774 (blender)
Bug #21788 (readpix)
(cherry picked from master, commit fd65418f60)
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
(cherry picked from master, commit 0828579a65)
Funny thing is I annotated this dependency in
e5f63c403b, but didn't actually use it.
(cherry picked from master, commit 03187571b6)
Conflicts:
src/mesa/main/state.c
Compiling mesa on a system with no X headers installed in the default
include paths fails due to missing X11 includes. The header includes are
picked up by configure but not applied.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 5358e54d1a)
Windows opengl32.dll calls glFinish prior to every swapbuffers, which
makes it pretty hard to get decent performance...
Work around by mapping finish to flush on PIPE_OS_WINDOWS. This is
conformant, though it might confuse poorly-written benchmarks which
attempt to measure a single event rather than figuring out the rate of
continuous processing.
