[Mesa-dev] Mesa IR as a list of instructions

[Ilia Mirkin]

On Fri, May 30, 2014 at 3:22 PM, Eric Anholt <eric at anholt.net> wrote:
> Marek Olšák <maraeo at gmail.com> writes:
>
>> I have just some comments below.
>>
>> On Wed, May 28, 2014 at 8:37 PM, Eric Anholt <eric at 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?
>
>>> - 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.
>
> Cool.  I agree with the way TGSI has handled integers -- not putting the
> type on the declaration, but on the instructions.  It maps well to how
> our hardware works, at least.
>
>>> - 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.
>
> I really want to get to the point where we're building useful shared
> code for optimization -- for example, right now, we've got dead code
> eliminators in:
>
> - GLSL IR (2 of them, both garbage)
> - Mesa IR (2 of them, both garbage)
> - i965 FS (actually kinda decent)
> - i965 VS (awful)
> - st_glsl_to_tgsi (didn't look).

nouveau/codegen (which actually does SSA/folding/etc too)
presumably r600/sb, but I didn't check

>
> That's not cool.  I'd love for us to be able to work together somehow,
> and I'm trying to figure out how to.
>
> However, talking yesterday about SSA and vector representations, we
> again failed to come up with anything that sounded compelling -- it
> appears that SSA is going to make obvious optimizations like dead code
> elimination in a vec4 IR harder.  Ken and Matt pretty well convinced me
> that any new IR we work on should probably be scalar -- 965 is mostly
> scalar getting more so, my next project is scalar, and as far as I know
> current radeon and nouveau is scalar.
>
> Is anyone working on hardware with vector instructions these days?

nv30/nv40 use vector instructions (GeForce FX, 6, 7 series) -- all
relatively old, but supported

Some nv50+ instructions are also "vector", in that they take in and
return sequences of registers (like the tex family of instructions --
it'll take just one source for the coordinates, e.g. r0, but then
expect data in r0,r1,r2,r3, and will output the color values to a
sequence of registers as well). There are also wide loads/stores. All
fp64 operations assume a double-wide register (e.g. r0/r1 pair). These
are largely concerns for register allocation though, not dead code. At
least with the fp64 stuff, they should also be single values at the IR
level. Nouveau deals with all this by having split/merge pseudo-ops.

AFAIK at least some Adreno stuff is vector-based too, perhaps Rob can
comment more.

  -ilia