Connor Abbott <cwabbo...@gmail.com> writes: > 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.
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).
pgpUhs47IzPDk.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
