On Wed, Aug 20, 2014 at 12:17 PM, Tom Stellard <t...@stellard.net> wrote: > On Tue, Aug 19, 2014 at 05:19:15PM -0700, Connor Abbott wrote: >> On Tue, Aug 19, 2014 at 3:57 PM, Tom Stellard <t...@stellard.net> wrote: >> > On Tue, Aug 19, 2014 at 01:37:56PM -0700, Connor Abbott wrote: >> >> On Tue, Aug 19, 2014 at 11:40 AM, Francisco Jerez <curroje...@riseup.net> >> >> wrote: >> >> > Tom Stellard <t...@stellard.net> writes: >> >> > >> >> >> On Tue, Aug 19, 2014 at 11:04:59AM -0400, Connor Abbott wrote: >> >> >>> On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer <mic...@daenzer.net> >> >> >>> wrote: >> >> >>> > On 19.08.2014 01:28, Connor Abbott wrote: >> >> >>> >> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer >> >> >>> >> <mic...@daenzer.net> wrote: >> >> >>> >>> On 16.08.2014 09:12, Connor Abbott wrote: >> >> >>> >>>> I know what you might be thinking right now. "Wait, *another* >> >> >>> >>>> IR? Don't >> >> >>> >>>> we already have like 5 of those, not counting all the >> >> >>> >>>> driver-specific >> >> >>> >>>> ones? Isn't this stuff complicated enough already?" Well, there >> >> >>> >>>> are some >> >> >>> >>>> pretty good reasons to start afresh (again...). In the years >> >> >>> >>>> we've been >> >> >>> >>>> using GLSL IR, we've come to realize that, in fact, it's not >> >> >>> >>>> what we >> >> >>> >>>> want *at all* to do optimizations on. >> >> >>> >>> >> >> >>> >>> Did you evaluate using LLVM IR instead of inventing yet another >> >> >>> >>> one? >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> -- >> >> >>> >>> Earthling Michel Dänzer | >> >> >>> >>> http://www.amd.com >> >> >>> >>> Libre software enthusiast | Mesa and X >> >> >>> >>> developer >> >> >>> >> >> >> >>> >> Yes. See >> >> >>> >> >> >> >>> >> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html >> >> >>> >> >> >> >>> >> and >> >> >>> >> >> >> >>> >> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html >> >> >>> > >> >> >>> > I know Ian can't deal with LLVM for some reason. I was wondering if >> >> >>> > *you* evaluated it, and if so, why you rejected it. >> >> >>> > >> >> >>> > >> >> >>> > -- >> >> >>> > Earthling Michel Dänzer | >> >> >>> > http://www.amd.com >> >> >>> > Libre software enthusiast | Mesa and X >> >> >>> > developer >> >> >>> >> >> >>> >> >> >>> Well, first of all, the fact that Ian and Ken don't want to use it >> >> >>> means that any plan to use LLVM for the Intel driver is dead in the >> >> >>> water anyways - you can translate NIR into LLVM if you want, but for >> >> >>> i965 we want to share optimizations between our 2 backends (FS and >> >> >>> vec4) that we can't do today in GLSL IR so this is what we want to use >> >> >>> for that, and since nobody else does anything with the core GLSL >> >> >>> compiler except when they have to, when we start moving things out of >> >> >>> GLSL IR this will probably replace GLSL IR as the infrastructure that >> >> >>> all Mesa drivers use. But with that in mind, here are a few reasons >> >> >>> why we wouldn't want to use LLVM: >> >> >>> >> >> >>> * LLVM wasn't built to understand structured CFG's, meaning that you >> >> >>> need to re-structurize it using a pass that's fragile and prone to >> >> >>> break if some other pass "optimizes" the shader in a way that makes it >> >> >>> non-structured (i.e. not expressible in terms of loops and if >> >> >>> statements). This loss of information also means that passes that need >> >> >>> to know things like, for example, the loop nesting depth need to do an >> >> >>> analysis pass whereas with NIR you can just walk up the control flow >> >> >>> tree and count the number of loops we hit. >> >> >>> >> >> >> >> >> >> LLVM has a pass to structurize the CFG. We use it in the radeon >> >> >> drivers, and it is run after all of the other LLVM optimizations which >> >> >> have >> >> >> no concept of structured CFG. It's not bug free, but it works really >> >> >> well even with all of the complex OpenCL kernels we throw at it. >> >> >> >> >> >> Your point about losing information when the CFG is de-structurized is >> >> >> valid, but for things like loop depth, I'm not sure why we couldn't >> >> >> write an >> >> >> LLVM analysis pass for this (if one doesn't already exist). >> >> >> >> >> > >> >> > I don't think this is such a big deal either. At least the >> >> > structurization pass used on newer AMD hardware isn't "fragile" in the >> >> > way you seem to imply -- AFAIK (unlike the old AMDIL heuristic >> >> > algorithm) it's guaranteed to give you a valid structurized output no >> >> > matter what the previous optimization passes have done to the CFG, >> >> > modulo bugs. I admit that the situation is nevertheless suboptimal. >> >> > Ideally this information wouldn't get lost along the way. For the long >> >> > term we may want to represent structured control flow directly in the IR >> >> > as you say, I just don't see how reinventing the IR saves us any work if >> >> > we could just fix the existing one. >> >> >> >> It seems to me that something like how we represent control flow is a >> >> pretty fundamental part of the IR - it affects any optimization pass >> >> that needs to do anything beyond adding and removing instructions. How >> >> would you fix that, especially given that LLVM is primarily designed >> >> for CPU's where you don't want to be restricted to structured control >> >> flow at all? It seems like our goals (preserve the structure) conflict >> >> with the way LLVM has been designed. >> >> >> > >> > I think it's important to distinguish between LLVM IR and the tools >> > available to manipulate it. LLVM IR is meant to be a platform >> > independent program representation. There is nothing about the IR that >> > would prevent someone from using it for hardware that required structured >> > control flow. >> >> Right - when I said that structured control flow was a fundamental >> part of the IR, I meant that in the sense that it's a constraint that >> all optimization passes have to follow. I was also thinking of NIR, >> where it actually is a fundamental part of the IR datastructures - all >> control flow consists of a tree of loops, if statements, and basic >> blocks and there are no jump statements in the IR except for break, >> continue, and return. There are helpers to mutate the control flow >> tree (adding an if after an instruction, deleting a loop, etc.) so >> that you can more or less pretend you're operating on something like >> GLSL IR, while the CFG is being updated for you, basic blocks are >> being created and deleted, etc. >> >> > >> > The tools (mainly the optimization passes) are where decisions about >> > things like preserving structured control flow are made. There are >> > currently two strategies available for using the tools to produce programs >> > with structured control flow: >> > >> > 1. Use the CFG structurizer pass >> > >> > 2. Only use transforms that maintain the structure of the control flow. >> >> I'm a little confused about how this strategy would work. I'm assuming >> that the control flow structure (i.e. the tree of loops and ifs) is >> stored in some kind of metadata or fake instruction on top of the IR - >> I haven't looked into this much, so correct me if I'm wrong. If so, >> wouldn't you still have to make every optimization pass that touches >> the CFG properly update that metadata to avoid it going stale, since >> the optimizations themselves are operating on a list of basic blocks >> which is a little lower-level? >> > > There is no CFG metadata. If you want to collect some information about the > CFG, you would use an analysis pass to do this. For example, LLVM has an > analysis pass for computing the dominator tree. If an optimization > wants to use this analysis it would add this analysis as a pass dependency > and then LLVM would run the dominator tree analysis before the optimizations > pass. > > Once the analysis has been run, the result is cached for other passes to use. > However, the base assumption is that optimization passes invalidate > all analysis information, so passes are required to report which analysis > passes > or which features of the program are preserved. So, if a pass reports > that it preserves the CFG, then the dominator tree analysis is still > considered > valid. > > This a high level overview of how it works, but to get back to your question, > if you wanted to use strategy number 2, you could just choose to only run > optimizations that preserved the CFG. > > -Tom
Ah, I see, that makes sense. That does seem like a rather terrible solution though, since not being able to change the CFG seems rather harsh. >> > >> > -Tom >> > >> >> > >> >> >>> * LLVM doesn't do modifiers, meaning that we can't do optimizations >> >> >>> like "clamp(x, 0.0, 1.0) => mov.sat x" and "clamp(x, 0.25, 1.0) => >> >> >>> max.sat(x, .25)" in a generic fashion. >> >> >>> >> >> >> >> >> >> The way to handle this with LLVM would be to add intrinsics to >> >> >> represent >> >> >> the various modifiers and then fold them into instructions during >> >> >> instruction selection. >> >> >> >> >> > >> >> > IMHO this is a feature. One of the things I don't like about NIR is >> >> > that it's still vec4-centric. Most drivers are going to want something >> >> > else and different to each other, we cannot please all of them with one >> >> > single vector addressing model built into the core instruction set, so >> >> > I'd rather have modifiers, writemasks and swizzles represented as the >> >> > composition of separate instructions/intrinsics with simple and >> >> > well-defined semantics, which can be coalesced back into the real >> >> > instruction as Tom says (easy even if you don't use LLVM's instruction >> >> > selector as long as it's SSA form). >> >> >> >> While NIR is vec4-centric, nothing's stopping you from splitting up >> >> instructions and doing optimizations at the scalar level for scalar >> >> ISA's - in fact, that's what I expect to happen. And for backends that >> >> really do need to have swizzles and writemasks, coalescing these >> >> things back into the original instruction is not at all trivial - in >> >> fact, going into and out of SSA without introducing extra copies even >> >> in situations like: >> >> >> >> foo.xyz = ... >> >> ... = foo >> >> foo.x = ... >> >> >> >> is a problem that hasn't been solved yet publicly (it seems doable, >> >> but difficult). So while we might not need swizzles and writemasks for >> >> most backends, for the few that do need it (like, for example, the >> >> i965 vec4 backend) it will be very nice to have one common lowering >> >> pass that solves this hard problem, which would be impossible to do >> >> without having swizzles and writemasks in the IR. And it's very likely >> >> that these backends, which probably aren't using SSA due to the >> >> aforementioned difficulties, will also benefit from having modifiers >> >> already folded for them - this is something that's already a problem >> >> for i965 vec4 backend and that NIR will help a lot. >> >> >> >> > >> >> >>> * LLVM is hard to embed into other projects, especially if it's used >> >> >>> as anything but a command-line tool that only runs once. See, for >> >> >>> example, http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html >> >> >>> under "Linking WebKit with LLVM" - most of those problems would also >> >> >>> apply to us. >> >> >>> >> >> >> >> >> >> You have to keep in mind that the way webkit uses LLVM is totally >> >> >> different than how Mesa would use LLVM if LLVM IR was adopted as a >> >> >> common IR. >> >> >> >> >> >> webkit is using LLVM as a full JIT compiler, which means it depends >> >> >> on almost all of the pieces of the LLVM stack, the IR manipulation, >> >> >> optimization passes, one or more of the code gen backends, as well >> >> >> as the entire JIT layer. The JIT layer in particular is missing a lot >> >> >> of >> >> >> functionality in the C API, which makes it more difficult to work with. >> >> >> >> >> >> If Mesa were to adopt LLVM IR as a common IR, the only LLVM library >> >> >> functionality it would need would be the IR manipulation and the >> >> >> optimizations passes. >> >> >> >> >> >>> * LLVM is on a different release schedule (6 months vs. 3 months), has >> >> >>> a different review process, etc., which means that to add support for >> >> >>> new functionality that involves shaders, we now have to submit patches >> >> >>> to two separate projects, and then 2 months later when we ship Mesa it >> >> >>> turns out that nobody can actually use the new feature because it >> >> >>> depends upon an unreleased version of LLVM that won't be released for >> >> >>> another 3 months and then packaged by distros even later... we've >> >> >>> already had problems where distros refused to ship newer Mesa releases >> >> >>> because radeon depended on a version of LLVM newer than the one they >> >> >>> were shipping, and if we started using LLVM in core Mesa it would get >> >> >>> even worse. Proprietary drivers solve this problem by just forking >> >> >>> LLVM, building it with the rest of their driver, and linking it in as >> >> >>> a static library, but distro packagers would hate us if we did that. >> >> >>> >> >> >> >> >> >> If Mesa were using LLVM IR as a common IR I'm not sure what features >> >> >> in Mesa would be tied to new additions in LLVM. As I said before, >> >> >> all Mesa would be using would be the IR manipulations and the >> >> >> optimization passes. The IR manipulations only require new features >> >> >> when something new is added to LLVM IR specification, which is rare. >> >> >> It's possible there could be some lag in new features that go into >> >> >> the optimization passes, but if there was some optimization that was >> >> >> deemed really critical, it could be implemented in Mesa using the IR >> >> >> manipulators. >> >> >> >> >> >> -Tom >> >> >> >> >> >>> I wouldn't completely rule out LLVM, and I do think they do a lot of >> >> >>> things right, but for now it seems like it's not the path that the >> >> >>> Intel team wants to take. >> >> >>> >> >> >>> Connor >> >> >>> _______________________________________________ >> >> >>> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
