| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Previously, we'd be branching based on whatever condition code happened to be
laying around.
(cherry picked from commit 7007f8b352763af89805f287153cb7972bff0523)
|
| |
|
|
|
|
|
| |
Bug #20821
(cherry picked from commit 191e028de20b2f954621b652aa77b06d0e93652a)
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec. Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be. This
gets us the 90% solution.
Bug #19911.
(cherry picked from commit d7430d942f6c7950a92367aeb13b80cf76ccad78)
|
|
|
|
|
|
|
| |
See comment on Vertex URB Entry Read Length for VS_STATE.
This, combined with the previous three commits, fixes #22945.
(cherry picked from commit e340d4f9866db4bae391288e83a630a310b0dd2b)
|
|
|
|
|
|
|
| |
This fix is just from code and docs inspection, but it may fix hangs on
some applications.
(cherry picked from commit e93848e595176ae0bad3bfe64e0ca63fd089bb72)
|
|
|
|
|
|
|
|
|
|
| |
It appears that sometimes Mesa (and I suppose a VS could as well) emits
a program which references no vertex data, and thus we end up with
nr_enabled == 0 even though some VBs are enabled. We'd end up emitting
VB/VE packet headers of 0xffffffff in that case, leading to GPU hangs.
Bug #22945 (wine with an uncompiled VS)
(cherry picked from commit d1fbfd0f962347e4153db3852292d44de5aea863)
|
|
|
|
|
| |
The code duplication bothered me.
(cherry picked from commit 9b9cb30d128fc5f1ba77287696ecd508e640efde)
|
|
|
|
|
| |
It's the last addressable byte, not the byte after the end of the buffer.
(cherry picked from commit b72dea5441e8e9226dabf1826fa3bc129c7bc281)
|
|
|
|
| |
(cherry picked from commit 840c09fc71542fdfc71edd2a2802925d467567bb)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If the renderbuffer orientation is Y=0=TOP we need to invert the dstY
position.
|
|
|
|
|
|
|
|
|
|
|
|
| |
State tracker currently backs GL_RGB textures with RGBA almost always.
This means we need to maintain A==1 in these textures to give correct GL_RGB
sampling results.
This change offloads the RGBA->RGB copy to hardware using the new writemask
version of u_blit_pixels.
More src/dstLogical/dstActual triples could be shifted to hardware by
this technique in future patches.
|
|
|
|
| |
Values outside the writemask are set in the destination to {0,0,0,1}
|
| |
|
|
|
|
| |
See bug 21267.
|
|
|
|
|
| |
This fixes a conform selection/feedback regression introduced by commit
8f4d66c5f893b49eb3973aa3b31a856314c045c7
|
|
|
|
|
|
| |
If the fragment program uses KIL, we have to execute it before z/stencil
testing. Otherwise, deferred texture/shading lets us skip shading for
pixels that fail z/stencil testing.
|
| |
|
|
|
|
|
|
| |
We need to clamp/saturate after each texenv stage, not just the last one.
Fixes glean texEnv failure for softpipe (and probably other fragment program-
based drivers).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When cross compiling on a 64bit machine, gen_matypes.c is build
for the host machine (64bit) but must generates code for the target
machine (32bit). This causes wrong offsets all over the place and
crashes googleearth on my machine. Solution is to add -m32 when
cross compiling.
Attached patch is compatible with linux-x86-32 and autoconf based
builds.
|
|
|
|
| |
Fixes progs/xdemos/glxpixmap modified to use direct rendering.
|
| |
|
| |
|
|
|
|
| |
See bug 16866.
|
| |
|
|
|
|
| |
Fixes glean/texture_srgb failure, bug #23449.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Now the left half is yellow and the right half is red, with the gradients
going in opposite directions.
|
|
|
|
|
|
|
|
|
| |
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 4bccd693a72a0b42dffc849034263a68e779ca91)
|
| |
|
|
|
|
|
|
| |
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...
|
|
|
|
| |
Fixes bug 23489.
|
| |
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
| |
Fall back to interpreter for now. This doesn't happen very often.
|