On Wed, May 28, 2014 at 2: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. > - 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. 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. > > 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. > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
