On Thu, Dec 31, 2015 at 12:05 PM, Connor Abbott <cwabbo...@gmail.com> wrote: > On Thu, Dec 31, 2015 at 10:16 AM, Rob Clark <robdcl...@gmail.com> wrote: >> On Tue, Dec 29, 2015 at 10:32 AM, Rob Clark <robdcl...@gmail.com> wrote: >>>>>> If you do this, you'll be back to always needing a mutable copy. Most >>>>>> lowering and optimization passes die the moment they see a register. >>>>>> You'll >>>>>> either have to go fix a bunch of stuff up to no-op properly or run >>>>>> vars_to_regs after doing your NIR lowering but before going into your >>>>>> backend IR. This means that your "gold copy" still has variables and you >>>>>> always need to lower them to registers before you go into the backend. >>>>> >>>>> ugg.. but good point, thanks for pointing that out before I wasted >>>>> another afternoon on yet another dead-end for handling deref's.. >>>>> >>>>> Ok, I guess I need to think of a better name than load/store_var2 for >>>>> the new intrinsics ;-) >>>> >>>> I don't think that "you should throw away registers and use your own >>>> thing" is what Jason wanted you to get out of that. >>> >>> perhaps.. I was considering switching to registers for arrays. >>> Although it would end up forcing an extra clone in the common case >>> where there would otherwise not be one... a bit of a tough pill to >>> swallow.. >> >> >> I've been thinking through this a bit, and the whole load/store >> intrinsic for var access (vs. potentially being the src and/or dst of >> any other instruction, with registers) is pretty damn convenient for >> me.. >> >> Not all instructions support indirect dst and/or src, and some support >> indirect in certain src positions, but not others. I have similar >> constraints with const (uniform), fwiw. >> >> In addition to avoiding a lot of churn in nir->ir3 I think it would be >> easier to deal with these kind of constraints by always starting out >> with a move, and then let an ir3 backend pass collapse that into the >> instruction(s) that consumes the mov when possible, similar to what we >> do already with uniforms. >> >> So thinking of introducing load/store_global and load/store_local >> intrinsics, and lowering to them in lower_io. >> >> BR, >> -R > > The thng about that is, starting out with a separate instruction is > much harder than splitting it out. Splitting out an indirect access > can be done easily, and in your case, on the fly as you convert from > NIR, whereas inlining accesses is a lot more painful, since you're > essentially back to not having the full SSA information. We want to > (eventually) solve that problem in NIR, and not in everyone's backend. > For that reason, you're likely going to be the only user of these new > intrinsics/derefs/whatever. Both Jason and I are confused as to why > you don't want to make the minor changes needed to adopt the thing > that is designed to do exactly what you want to do, rather than > rewrite core NIR for something that would save maybe <50 lines of code > in your backend (and really, that's what we're talking about).
Folding back an unneeded mov is actually pretty trivial, esp since I still have it in SSA form at that point. (I guess you are basing your claim on an assumption that I wasn't in SSA at that point??) Not to mention that I already have to do this for const's anyways, so might as well be consistent. It would be a pretty simple extension of the same logic to handle it for indirect's. Basically, the way uniforms (and inputs and outputs) work for direct/indirect works pretty well for me. And handling arrays in the same way is attractive. Fwiw, with the tgsi f/e I handled all these special cases in the frontend, inserting extra mov's. I'm happier with the approach I took w/ the nir f/e where I'm not handling that in the f/e. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
