I have just some comments below. On Wed, May 28, 2014 at 8:37 PM, Eric Anholt <e...@anholt.net> wrote: > Here's a series I started back in January as a little experiment. > Basically, I feel guilty for pushing GLSL IR into the driver, and wish I'd > just fixed up Mesa IR back in the day. But, given that we're still > feeding Mesa IR into drivers as well (ARB programs and fixed function > vertex programs), it made me think: What if I fixed it up now, and got > Mesa IR to the point that we could just garbage collect the GLSL IR input > paths to drivers? > > Mesa IR has a bunch of weaknesses that need to get sorted out if it's > going to be useful: > > - It's a single giant array of instructions, making modifications of the > instruction stream (instruction lowering, optimization, etc.) more > expensive in code and CPU time than it should be.
A giant array of instructions is great if you don't expect people to change it, which is why TGSI is an array too (it's actually one continuous buffer). > - It doesn't have any variable declarations, so if you have dynamic array > indexing, optimization just shuts down (plus, no annotation on the > temps, so debugging is irritating). TGSI supports arrays for the temporary file and that makes it more usable than Mesa IR. > - It doesn't have integer instructions or anything else post-GLSL-1.30. One thing that may be surprising about TGSI (and this may be needed for Mesa IR too) is that it has 2 IF opcodes. The first one "IF" expects a floating-point condition, which is true if condition != 0.0f. The second one "UIF" (unsigned integer if) is the typical "if" from C. Since registers are untyped, you'll need typed instructions. > - The optimization passes for it are totally ad-hoc and fairly weak. > - It's not SSA. > > I'm interested in fixing all of these. How do people feel about this > goal? I don't really have an opinion, because everything is TGSI to me. This will probably have very little impact on Gallium drivers except maybe those which don't have an optimizing shader backend. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev