Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
* The constant buffer emission is separated from RC state variables emission.
* The immediates are emitted with FS code.
|
|
|
|
|
|
We really need to get these into bug reports.
|
|
r300compiler doesn't handle half swizzles for vert shaders, which don't
have them. So, for now, disable them.
|
|
This entire codepath needs to be cleaned to be more pliant towards
shader failure.
|
|
|
|
|
|
Oh look, more gears. Seems to work just fine though.
|
|
This is to differentiate it from its unsigned version, TGSI_OPCODE_USHR.
|
|
|
|
SrcRegister -> Register
SrcRegisterInd -> Indirect
SrcRegisterDim -> Dimension
SrcRegisterDimInd -> DimIndirect
|
|
DstRegister -> Register
DstRegisterInd -> Indirect
|
|
InstructionPredicate -> Predicate
InstructionLabel -> Label
InstructionTexture -> Texture
FullSrcRegisters -> Src
FullDstRegisters -> Dst
|
|
It would be nice if these drivers built under the linux-debug header
so that these types of interface changes can be minimally propogated
into those drivers by people without the hardware. They don't have to
generate a working driver -- though a command-dumping winsys would be
an excellent for regression checking.
|
|
Likewise, the extended negate functionality hasn't been
used since mesa switched to using tgsi_ureg to build programs,
and has been translating the SWZ opcode internally to a single MAD.
|
|
These haven't been used by the mesa state tracker since the
conversion to tgsi_ureg, and it seems that none of the
other state trackers are using it either.
This helps simplify one of the biggest suprises when starting off with
TGSI shaders.
|
|
Provide a dummy implementation in the GL state tracker (move 0.5 to
the destination regs).
At some point, a motivated person could add a better
implementation of noise. Currently not even the nvidia
binary drivers do anything more than this. In any case, the
place to do this is in the GL state tracker, not the poor
driver.
|
|
Conflicts:
src/gallium/drivers/r300/r300_tgsi_to_rc.c
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
So I didn't touch r300compiler, but r300g now compiles after having
declarations and code untangled. As nha so gently points out, we shouldn't
have to do this just to comply with MSVC compilers.
|
|
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
Note that control flow instruction support isn't actually fully functional yet.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
There were additional non-textual conflicts.
Conflicts:
src/gallium/drivers/r300/r300_tgsi_to_rc.c
src/mesa/drivers/dri/r300/compiler/r3xx_vertprog.c
src/mesa/drivers/dri/r300/compiler/radeon_program.c
src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
|
|
|
|
Can be implemented with CMP src2, src1, src0
|
|
In particular, this removes the dependency on prog_instruction, which
unfortunately creates some code duplication, but also opens a path towards
adding some hardware-specific things in there.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
This is entirely untested on R500, and needs more testing on R300.
|
|
|