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

[Kenneth Graunke]

On 05/28/2014 11:37 AM, Eric Anholt 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'm still really skeptical of this goal.

I don't think reusing the existing Mesa IR backend code will save you
much effort.  In i965, it's roughly ~1400 lines of code total, and quite
simple; I think I wrote the brw_vec4_vp.cpp code in a day or two.

Our Mesa IR adapters are missing features and have bad assumptions.  For
example, the VP code doesn't do texturing at all.  The FP code assumes
texture units/sampler units work like ARB programs.  Neither do control
flow at all.  Neither do integer types.  They also generate terrible
code with piles of temporaries.

You could fix all of these things, but it would entail writing a lot of
code.  And when you're done, you still have to throw the "big switch"
where you decide to use the new path instead of the GLSL IR path.

On top of that, you risk breaking i915, r200, and ARB vp/fp on i965 at
every step...and Piglit has very few ARB vp/fp tests.

Steps 1-4 of your plan would bring Mesa IR to a level where it might be
on par with GLSL IR, but there's still a pile of work to get to where we
want.  You want basic blocks, CFG, UD-chains (or U-chains in SSA),
interference graphs, and so on.  That's a lot of work.

I really think the best plan is to start fresh, and create a new IR
which learns from Mesa IR, GLSL IR, and TGSI.  Build the infrastructure
optimization passes will want, such as reasoning about CFGs, walking
through uses of a variable, or looking at the interference graph.  At
least enough to "prove" the design of the IR, so you don't find out it's
awful to work with.  Converting to/from GLSL IR would let us hook into
the existing front-end and back-ends, and gradually move more to the new
IR.  New drivers can use the new IR directly, and I'll gladly rewrite
i965 to use it as well.

Maybe the new thing looks a lot like Mesa IR.  But, we wouldn't be
saddled by the legacy and the burden of keeping everything working.  We
can design it to be as clean as possible.  I do want to consider using
C99 for the new IR instead of C++.  With a flat IR, it seems much more
feasible.

Obviously, I want you to be involved in building the new compiler
infrastructure, if you have time.  I think you have a lot to contribute.

> This series fixes the first bullet point above.  Patch 15 is huge, but I
> didn't see a way to chop it up smaller without maintaining the list
> alongside the array for some intermediate patches.  I'd be willing to do
> so if needed, though, to make review doable.  You can also find the
> changes in the "mesa-ir" branch of my git tree.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140528/0f96dedd/attachment.sig>