| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Conflicts:
src/gallium/drivers/nv10/nv10_state.c
src/gallium/drivers/nv20/nv20_state.c
src/gallium/drivers/nv50/nv50_program.c
|
|
Don't need sprite coord origin per coord.
Also, don't need separate sprite enable bit - if all coords have it diabled,
then there are no point sprites (technically, there's a distinction in pre-GL3,
but it only differs in having more leniency in clamping to max size, something
the state tracker would need to handle and the hardware won't bother anyway).
Also, use packed field for the per-coord enables.
All in all, should save 3 dwords in rasterizer state (from 10 down to 7).
|
|
|
|
"unsafe" is never initialized, but used
(found by valgrind)
|
|
|
|
Fixes lockup triggered by this ingenious shader:
1: CALL :3
2: END
3: BGNSUB ...
|
|
|
|
Too bad we don't have hw array divisors or a method for
setting startInstance.
|
|
|
|
|
|
Vertex data in geometry programs is located in p[] space.
The base address in p[] for vertex i is located in vertex
attribute space, i.e. a[i << 2].
This means p[] is always accessed with an address register,
and I had to to mess with their allocation once again.
Also fixes negative offsets e.g. CONST[ADDR[0].x - 3].
|
|
|
|
|
|
|
|
|
|
Otherwise we risk overwriting them with temporary GPRs if
they're not used immediately after the CALL.
|
|
|
|
|
|
|
|
|
|
|
|
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour should match what libdrm_nouveau does closely.
- The solution remains statically sized, but when debugging is on it will check
for abuse.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
|
|
|
|
|
|
The immediate's bits eat the condition bits.
|
|
Cannot change hw reg assigned to a TGSI TEMP on the fly if
we are in a loop, conditional, or can jump around wildly.
|
|
Not that they make much sense on nv50, but we also do LIT ...
|
|
|
|
If we create multiple instances of an nv50_reg referencing
them same resource, register allocation from alloc_reg has
to be done with the original nv50_reg.
|
|
Also fixes RSQ of negative sources.
|
|
This negation would only be triggered in situations
where it's incorrect.
The caller of set_immd should negate the immediate value
in the instruction itself if desired, and will also know
if it's a float or an int.
ADD TEMP[0], CONST[0], -IMMD[0] would load the immediate
into extra TEMP, negated, and set the negate flag in add
as well - double negation.
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
It doesn't seem to be possible to set the egdeflag in the
vertex shader, so we need to fallback to pushing vertices
through the FIFO and use method 0x15e4 if they are used.
This only works if VP does MOV OUT[X] IN[Y] where X is the
edgeflag output, and Y is saved so we can tell the correct
input later.
The VP still writes the useless values to wasted outputs
as punishment.
|
|
The state tracker now does the correct thing, so
interpret negation normally.
|
|
Before I tried to distinguish int +0 and -0, and regs
relative to $a1 would have been considered reserved
for TGSI.
This would probably never occur, let it be fixed even so.
|
|
This is easier, we don't have to record all the BRK branches
to fill in the address at ENDLOOP - which wasn't done before
and thus made all but the last BRK branch jump to the start.
Also, we don't risk reactivting threads that already left
the loop if we join threads after a conditional with a BRK
(although it might be wiser to remove the join altogether
in such cases).
|
|
|
|
Trying to free part of nv50_pc->reg_instances[] for an
nv50_reg representing an indirect constant resulted in
a segmentation fault.
|
|
Sometimes we want non-float immediates, hacking them into
floats isn't nice.
Sorry, this should have already been committed before.
|
|
|
|
If lod or bias can be non-constant across a quad of fragments,
we need to execute TEX separately for each value.
Don't ask why.
|
|
... and don't set the 'live' flag for TEX anymore, we'd
have to know if results affect the inputs for another TEX,
and I'm not going to do that kind of analysis now.
|
|
|
|
So we can use the 'mod' member without concern
if a source is used multiple times in 1 insn.
|
|
Conflicts:
src/gallium/drivers/r300/r300_vs.c
|
|
For each FP input, don't assume that the VP output will be
at the same position, but scan the semantics instead, then
put the correct output reg indices into VP_RESULT_MAP.
Position is still assumed to be the first output/input.
See 07fafc7c9346aa260829603bf3188596481e9e62, which renders
previous assumptions incorrect.
|
|
|
