| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Fixes mysterious failures in glean glsl1 test.
|
|
|
|
|
|
|
|
Since Ian's patch of a few weeks ago, we can enable all three variations
of two-sided stencil. Update the state tracker to handle the extra back-
face state and turn on the EXT.
Note: there's a new Glean test for two-sided stencil now...
|
|
|
|
Back-face stencil operations didn't work correctly because this value was
zero. It needs to be 1 or 2. The only place it's set otherwise is in
glEnable/Disable(GL_STENCIL_TEST_TWO_SIDE_EXT).
|
|
|
|
|
|
Move the is_boolean/integer_type() calls out of the loops.
Move the is_sampler_type() function near the bool/int functions.
Add a bunch of comments.
|
|
We were off by one when checking for too many uniform values.
|
|
If the vertex shader writes to a varying array with a variable index,
mark all the elements of that array as being written.
For example, if the vertex shader does:
for (i = 0; i < 4; i++)
gl_TexCoord[i] = expr;
Mark all texcoord outputs as being written, not just the first.
Linking will fail if a fragment shader tries to read an input that's not
written by the vertex shader. Before this fix, this linker test could fail.
|
|
Obviously, the color of fragments produced by DrawPixels is not constant,
even if the current vertex array / vertex program state indicates that the
color for normal rendering will be constant. Therefore, we need to override
certain optimisations that have been added to texenvprogram.c
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
|
|
Old limit was 256. Note that no arrays are declared to this size.
The only place we have to be careful about raising this limit is the
prog_src/dst_register Index bitfields. These have been bumped up too.
Added assertions to check we don't exceed the bitfield in the future too.
|
|
This new issue was exposed by commit 6eabfc27f19a10dfc2663e99f9560966ba1ff697
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|
|
It looks like I resolved the merge conflicts but did not save my emacs
buffers before committing...
|
|
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
Note: the default value for EmitCondCodes is FALSE. This means the GLSL
compiler will emit code like this:
SEQ TEMP[0].x, A, B;
IF TEMP[0].x;
...
ENDIF
But if EmitCondCodes is TRUE, condition codes will be used instead:
SEQ.C TEMP[0].x, A, B;
IF (NE.xxxx);
...
ENDIF
|
|
The default for EmitCondCodes got flipped when gallium-0.2 was merged.
This fixes GLSL if/else/endif regressions.
Drivers that use GLSL should always explicitly set the flag to be safe.
|
|
|
|
R3xx/R5xx fragment program texture constants must come from a hardware
register instead of the constant file, so we redirect if necessary during
the native rewrite phase.
The symptoms of this bug started appearing when the Mesa fixed function
texenvprogram code started using STATE_CURRENT_ATTRIB constants for
texture coordinates when the corresponding attributes were constant across
all vertices.
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
Previously, the prog_instruction::Data field was used to map original Mesa
instructions to brw instructions in order to resolve subroutine calls. This
was a rather tangled mess. Plus it's an obstacle to implementing dynamic
allocation/growing of the instruction buffer (it's still a fixed size).
Mesa's GLSL compiler emits a label for each subroutine and CAL instruction.
Now we use those labels to patch the subroutine calls after code generation
has been done. We just keep a list of all CAL instructions that needs patching
and a list of all subroutine labels. It's a simple matter to resolve them.
This also consolidates some redundant post-emit code between brw_vs_emit.c and
brw_wm_glsl.c and removes some loops that cleared the prog_instruction::Data
fields at the end.
Plus, a bunch of new comments.
|
|
This doesn't effect correctness, but we were emitting an extraneous ADD.
|
|
|
|
|
|
|
|
|
|
It's done in the Mesa GLSL compiler. The only part of it that might
matter in drivers is the centroid sampling option for MSAA.
|
|
|
|
|
|
|
|
|
|
I'm committing this because it fixes a conform failure; the failure occurs
on the TextureProxy test, where the test attempts to create proxy textures
at every level, but fails at the last level (border == 1, width == 1,
height == 1) because it's beyond MAX_TEXTURE_LEVELS.
Eric's original comment was:
idr said that in his review swrast was ready for it, and the 965 driver is
advertising it already though it has been resulting in many crashes due to
arrays using these defines not being big enough.
|
|
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
|
|
|
|
|
The new array features, precision/invariant/centroid qualifiers, etc. were
done a while back. The glGetString(GL_SHADING_LANGUAGE_VERSION) query returns
"1.20" now (for drivers that support it anyway).
|
|
This fixes a bug found with swizzled array indexes such as in "array[index.z]"
where "index" is an ivec4.
|
|
Prints program parameter info
|
|
Not all cases were handled before.
|
|
This is a 2% win in fbo_firecube, and would avoid a sw fallback for
masked clears.
|
|
Noticed this with the fbotexture demo.
|
|
|
|
|
