| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When an input is marked in gl_program.InputsRead but is not actually read
in the final program (due to dead-code elimination or whatever), the order
of input registers must still match gl_program.InputsRead. This is done
even more explicitly now.
|
|
This fixes the last r500 bug related to glean/fragProg1.
|
|
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.
|
|
In addition, this pass fixes non-native swizzles.
|
|
|
|
based on info from hw team
|
|
|
|
|
|
|
|
|
|
|
|
This fixes a regression introduced by dea8719f0...
|
|
Use the common facilities to convert non-native instructions into native ones.
Worked hard to make the code easier to read (hopefully), by using helper
functions instead of direct manipulation of the machine code.
Fixes two bugs related to FLR and XPD.
|
|
|
|
|
|
|
|
|
|
Missed the homogenous divide of R by Q before...
|
|
multisample enable is enabled by default, however gl mandates multisample
rendering rules only apply if there's also a multisampled buffer.
|
|
This isn't complete yet. It does cover the two most common usage cases,
though, and at least the third one (POINT_DISTANCE_ATTENUATION) is possible,
so I'll do that later.
|
|
|
|
. 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
|
|
Okay, this time it's for real, and for good. This should be a perma-fix.
|
|
|
|
|
|
Per airlied's suggestion.
|
|
tests/bug_3195 doesn't render right, but at least it doesn't segfault this way.
|
|
Oooops. Hehe.
|
|
Properly set t->filter_1 for r300_state to emit.
Expect buggies as people see LOD bias enabled for the first time...
|
|
Not like it matters, though, since it's not taking effect yet.
|
|
Needs a bit more work on submission.
|
|
I don't like PROGRAM_BUILTIN; could we either patch Mesa or just use a different constant?
|
|
r5xx should fallback if it encounters a bad FP.
TODO: Re-enable the dumb shader so we don't have to completely fallback.
|
|
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.
|
|
|
|
Add the code emission source file, and comment out unneeded tex de-swizzling.
|
|
Yes, I know it's massive. Imagine how I felt, auditing 3000 lines of code.
|
|
*Pulls paper bag down over head*
|
|
|
|
|
|
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
|
|
|
