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

[Eric Anholt]

Connor Abbott <cwabbott0 at gmail.com> writes:

> On Wed, May 28, 2014 at 2: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?
>>
>> 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.
>> - 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).
>> - It doesn't have integer instructions or anything else post-GLSL-1.30.
>> - 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 know much about Mesa IR, but this seems like a huge pile of
> work... is this any easier than just making GLSL IR flatter, like with
> my flatland idea that I posted a while ago? Also, iirc, there was an
> effort a while ago to make ARB programs go through GLSL IR but it was
> abandoned - why was it so difficult? I'm skeptical that basically
> bringing an older IR from 1999 to 2014 is going to be less effort than
> modifying a newer one that had some good ideas and some bad ones.

The thing is that I want basically all the ways that GLSL IR is
different from Mesa IR to go back to Mesa IR, except for size
declarations on temps.  It was a mistake.  From there I want new stuff,
but building new stuff doesn't feel that hard when it's incremental
changes.

i965 faces a non-incremental change if it was to choose to follow this
path: flipping everything over to brw_*_[vf]p.cpp.  That doesn't look
pleasant, and it has some challenges (like its MOV-happy swizzle
handling in brw_fs_fp.cpp).

> By the way, correct me if I'm wrong, but I think you're still missing
> a bullet point there. You've changed Mesa IR to be a list of
> instructions, but it's still just one list. Ideally, you'd have both
> the graph structure (the basic blocks) and the tree structure (if
> statements and loops) available in the IR, since both of them are
> going to be needed for different reasons, especially with converting
> to SSA (or doing basically any non-trivial optimization). As of now,
> GLSL IR has the former (I think Ian had some patches to introduce the
> latter through an analysis pass as part of an experiment with
> introducing def-use chains to GLSL IR...) but Mesa IR has neither - in
> the end, I think it's much more practical to have a tree of if
> statements and loops like in GLSL IR than a simple list of
> instructions. Again, I don't think it's less effort than just fixing
> GLSL IR.

We absolutely need a CFG handy to do optimization well, but I disagree
on having the tree structure in the IR for flow-control constructs.  I
recently wrote a CFG constructor for GLSL IR, and found that trying to
correctly walk the tree (particularly for dataflow analysis, but also to
an extent for just building a CFG) was way harder than it was in i965's
IR and I definitely don't trust the resulting code anything like I do
for the i965 stuff (you can find that work on the deadcode branch of my
tree).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140528/1c6e9bc1/attachment.sig>