| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Use an abstracted instruction scheduling and register allocation algorithm
that we will be able to share with r300_fragprog.
Unlike the original emit code, this code tries to pair instructions that
only use the RGB part of the ALU with instructions that only use the alpha
part. However, the pairing algorithm still has some shortcomings;
for example, it doesn't generate optimal code for the emulation of LIT.
|
|
|
|
. There is both a per-texture unit and a per-texture object (at least for
OpenGL 1.4); this should now be supported properly.
. The LOD bias calculation in r300_state has been simplified and corrected
(need to multiply by 32 instead of 31, and ensure clamping)
. do not clamp LOD bias in TexEnv, as that behaviour conflicts with what
the spec says
. set Const.MaxTextureLodBias properly
. remove the no_neg_lod_bias property; if somebody can explain what
it's good for, we can add it back in, but according to Google, nobody
seems to use it
. removed some dead code and unused variables
|
|
|
|
tests/bug_3195 doesn't render right, but at least it doesn't segfault this way.
|
|
Yes, I know it's massive. Imagine how I felt, auditing 3000 lines of code.
|
|
|
|
|
|
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
|
|
This also fixes a bug with Zfunc set to GL_NEVER in glean/paths.
|
|
This variable was only ever written to, but nobody used its value.
|
|
Thanks to nh for the r3xx version.
|
|
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.)
|
|
|
|
Also remove some unused bits of the r500 fragprog struct
|
|
Not sure if this is a good or bad plan, it certainly doesn't make things worse here.
|
|
|
|
|
|
This is not the same as r3xx indexing. It only tries to protect inputs on
the pixel stack from getting clobbered by temps or texs.
Texs don't need special treatment since they read from special input regs
and write to the same temp regs as ALU/FC instructions.
|
|
We don't appear to update max_temp_idx yet anywhere though
|
|
Includes fallback shader and a handful of working opcodes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I've no idea if this code might break something or how it should interact
with vertex shaders, it makes the clip demo work for me
|
|
Construct the vertprog instruction in the 4 DWORD parts...
DWORD 0: Opcode and Output.
DWORD 1: First Argument.
DWORD 2: Second Argument.
DWORD 3: Third Argument.
Allow the opcode translation functions to generate more than one instruction;
useful for when an instruction must be emulated. FLR, XPD, etc.
|
|
|
|
|
|
|
|
|
|
Possibly performance may improve by setting it to the last instruction that
writes result.position, rather than the last instruction in the vertex program.
|
|
|
|
|
|
These registers are per-pixel and per-vertex X and Y clipping planes.
|
|
The VTXFMT code was broken by the new VBO branch and the OPTIMIZE_ELTS path
relied on the VTXFMT code...
I'm not even sure if the OPTIMIZE_ELTS path ever worked; the testing that I did
after minimizing the code duplication would have taken the same path as the
non-OPTIMIZE_ELTS code.
|
|
|
|
|
|
|
|
|
|
|
|
|
