Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
reuse insert_WPOS_trailer function
|
|
|
|
|
|
|
|
|
|
|
|
Use proper fields for marking if fp is translated, and if is translated succesfully.
Now if fp gets translated (even unsuccesfully) fp->translated is true. If the translation failed (i.e. because we exceeded limit of
maximum texture indirections) the fp->error is set. With a little updated fallback function it prevents non native fragment programs
from beeing translated with every frame (the translation would fail anyway so there's no point to try again).
Also implement IsProgramNative function for GL_FRAGMENT_PROGRAM_ARB (it should give some performance boost in apps that checks if
program is native and falls back to simpler shader to meet hw limits if necessary) and cleanup indentation (remove whitespaces on empty
lines).
|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
|
|
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>
|
|
Makefile.template
|
|
|
|
Share almost all code with r500_fragprog now.
This also fixes Piglit's texrect-many test, which means that the compiz
bicubic plugin should work with hardware acceleration now.
|
|
|
|
|
|
This fixes a regression introduced by dea8719f0...
|
|
|
|
Missed the homogenous divide of R by Q before...
|
|
This new generic transform replaces "special" instructions by more generic
variants. Hopefully, we will be able to share this code between r300 and r500.
|
|
MOV, ADD and MUL do not fit the hardware as well as MAD, but they are less
complex and thus leave more room for future optimizations.
|
|
|
|
|
|
Streamlining source and destination registers, as well as texcoord scaling for
RECT textures is now done in a radeon_program based transformation.
The idea is that this will allow us to optimize away unnecessary indirections
more easily.
|
|
The idea/hope is that radeon_program will serve as an intermediate
representation for r3xx up to r6xx fragment and vertex programs.
Right now, it is nothing more than a simplistic wrapper around Mesa's
prog_instruction, together with the notion of clauses, taken from r6xx docs.
The clauses will eventually be used to represent the nodes that are used in
r300 family fragment programs.
|
|
|
|
|
|
Refactor so that r300_pfs_compile_state "owns"/holds a pointer to
r300_fragment_program instead of the other way round. This is more natural from
an object orientation point of view.
Move the compiled hardware state into r300_fragment_program_code, in
anticipation of on-the-fly program recompilation based on external OpenGL
state.
|
|
|
|
r500 code still used r300_pfs_compile_state, which contains some fields that
really only make sense on r3xx type hardware. In order to allow both fragprog
implementations to go forward without disturbing each other, I've pushed this
structure down into the respective r[3|5]00_fragprog.c
|
|
Setup fg_depth_src for depth writing programs and change early Z (ztop)
semantics.
Piglit's version of glean/fragprog test passes now (unlike Glean, its
dependency on EXT_fog_coord, which we don't support, is optional).
R3xx only at the moment, but should be straightforward to adapt to R5xx
(I don't own an R5xx, and I don't want to break anything.)
|
|
The KIL instruction only works if at least one texture unit is enabled
in hardware.
Texture instructions do not support swizzles, negations etc. natively,
so we now emit an explicit swizzling etc. operation when the texture coordinate
requires it.
This fixes the Piglit fp-kil test.
|
|
|
|
Includes fallback shader and a handful of working opcodes.
|
|
This bug was introduced by commit 978145a075255ae153ee05c2a037400e61558079.
|
|
|
|
Just for consistency; most of the code already uses __FUNCTION__.
|
|
|
|
|
|
|
|
d28f6d91760374e2eb71b541b0f259f81dd73c69.
|
|
Note there might be some calls to the old function names in conditionally
disabled code, but I think I've got them all.
|
|
|
|
|
|
|
|
|
|
The texture_rectangle fix introduced a bug where every texture instruction
caused a new indirection.
|
|
R300 hardware takes texcoords in the range 0..1 even for rectangle
textures. Previously, the necessary texcoord conversion was applied
to the texture coordinate during vertex processing in a render stage.
This is obviously wrong when fragment programs are used, which can
calculate arbitrary coordinates for TEX instructions. Therefore,
we now inject an appropriate MUL instruction before a TEX that
reference a rectangle texture.
|