| Age | Commit message (Collapse) | Author |
|---|
|
This fixes some mesa demos such as fslight/engine in wireframe mode.
|
|
This follows the changes done for the FS alongside the EU emit code.
|
|
While the actual IF instructions were fixed by Zhenyu, we were still
flattening them to conditional moves.
|
|
At this point, piglit tests for fragment shader loops are working.
|
|
There are now two targets: the hop-to-end-of-block target, and the
target for where to resume execution for active channels.
|
|
There's no more DO since there's no more mask stack, and WHILE has
been shuffled like IF was.
|
|
|
|
Fixes piglit test glsl-fs-discard-03.
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
There were a few places where we were using the wrong opcodes
on evergreen. arl still needs to be fixed on evergreen; see
r600g for reference.
NOTE: This is a candidate for the 7.9 branch.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Needed for st/vega.
|
|
Like Eric's workaround patch of commit 490c23ee6be2e8531b5a14d42f808de83d401130.
This forces to align1 mode for math2 too.
|
|
Fixes glsl-fs-fragdata-1, and hopefully Eve Online where I noticed
this bug in the generated shader. Bug #31952.
|
|
This code was for the old GLcore build of the software rasteriser. The
X server switched to a DRI driver for software indirect GLX long ago.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
The compiler seriously needs a cleanup as far as the arrangement of functions
is concerned. It's hard to know whether some function was implemented or not
because there are so many places to search in and it can be anywhere and
named anyhow.
|
|
|
|
|
|
It looks like the function was originally written for ARB_fragment_program.
NOTE: This is a candidate for the 7.9 branch.
|
|
Fixes this GCC warning with linux-x86 build.
radeon_pair_regalloc.c: In function ‘compute_live_intervals’:
radeon_pair_regalloc.c:222: warning: ISO C90 forbids mixed declarations and code
|
|
Fixes this GCC warning with linux-x86 build.
radeon_pair_regalloc.c: In function ‘compute_live_intervals’:
radeon_pair_regalloc.c:221: warning: ISO C90 forbids mixed declarations and code
|
|
This fixes incorrect behaviour when the stencil clear value exceeds
the size of the stencil buffer, for example, when set with:
glClearStencil (~1); /* Set a bit pattern of 111...11111110 */
glClear (GL_STENCIL_BUFFER_BIT);
The clear value needs to be masked by the value 2^m - 1, where m is the
number of bits in the stencil buffer. Previously, we passed the value
masked with 0x7fffffff to _mesa_StencilFuncSeparate which then clamps,
NOT masks the value to the range 0 to 2^m - 1.
The result would be clearing the stencil buffer to 0xff, rather than 0xfe.
Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
This was really just for testing purposes.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=31894
|
|
Fixes bugzilla #31832
NOTE: This is a candidate for the 7.9 branch.
|
|
Cuts the extra CMP instruction that used to precede SEL.
|
|
|
|
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=31193
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
In addition, the rename_reg pass has been rewritten to use
rc_get_readers().
|
|
Previously, presubtract operations where only being used by instructions
with less than three source source registers.
|
|
|
|
|
|
|
|
|
|
When the result of the alpha instruction is being replicated to the RGB
destination register, we do not need to use alpha's destination register.
This fixes an invalid "Too many hardware temporaries used" error in
the case where a transcendent operation writes to a temporary register
greater than max_temp_regs.
NOTE: This is a candidate for the 7.9 branch.
|
|
This fixes an invalid "Too many hardware temporaries used" error in the
case where a source reads from a temporary register with an index greater
than max_temp_regs and then the source is marked as unused before the
register allocation pass.
NOTE: This is a candidate for the 7.9 branch.
|
|
Reads of registers that where not written to within the same block were
not being tracked. So in a situations like this:
0: IF
1: ADD t0, t1, t2
2: MOV t2, t1
Instruction 2 didn't know that instruction 1 read from t2, so
in some cases instruction 2 was being scheduled before instruction 1.
NOTE: This is a candidate for the 7.9 branch.
|
|
NOTE: This is a candidate for the 7.9 branch.
|
|
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
|
|
|
|
|
|
This is quite common for multitexture sampling, and not only cuts down
on the second and later set of MOVs, but typically also allows
compute-to-MRF on the first set.
No statistically siginficant performance difference in nexuiz (n=3),
but it reduces instruction count in one of its shaders and seems like
a good idea.
|
|
We were skipping it if the instruction producing the value we were
going to compute-to-mrf used its result reg as a source reg. This
meant that the typical "write interpolated color to fragment color" or
"texture from interpolated texcoord" shader didn't compute-to-MRF.
Just don't check for the interference cases until after we've checked
if this is the instruction we wanted to compute-to-MRF.
Improves nexuiz high-settings performance on my laptop 0.48% +- 0.08%
(n=3).
|
