Age | Commit message (Collapse) | Author |
|
|
|
|
|
Start adding some new pipe_transfer code.
Texturing is totally broken at this point but non-texture programs
seem to run OK.
|
|
Update framebuffer color/z/stencil mapping/unmapping.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
compile and behave like it did before the gallium-texture-transfer merge
|
|
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
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_vs_aos.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.
|
|
|
|
|
|
Suggested by Jonathan Adamczewski. There may be more places to do this...
|
|
Makes it a bit more manageable to read through the console logs.
|
|
|
|
|
|
|
|
"git stash": The cause of, and solution to, all my problems.
|
|
|
|
This is the last bit of Gallium-side plumbing for drawing things.
From this point on, the only missing parts should be in r3xx-specific
code areas...
|
|
This is a register that is in r300_demo but not r300_surface, so adding it in
to see if it helps.
|
|
|
|
|
|
|
|
Don't use SCISSORS_OFFSET since we're DRI2,
and don't forget to set scissors in clear.
|
|
Some fixes from glisse, moar swtcl emit setup, cleanup a bunch of regs,
properly do clear flush, and BEGIN_CS count fixes.
|
|
|
|
Man, util/u_math just gets better by the day.
|
|
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>
|
|
This cleans up some of the cruft from the old DRI setup, and
it turns out that only the GLSL extensions are still off if we
let st_extensions.c handle the setup instead.
|
|
|