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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
