On Tue, Nov 3, 2015 at 2:08 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 2 November 2015 at 19:41, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> On Mon, Nov 2, 2015 at 9:33 AM, Connor Abbott <cwabbo...@gmail.com> wrote: >>> On Mon, Nov 2, 2015 at 8:35 AM, Emil Velikov <emil.l.veli...@gmail.com> >>> wrote: >>>> Hi all, >>>> >>>> From a quick look, it seems that NIR copies (almost ?) all the state >>>> from GLSL IR even if it doesn't use it. >>>> >>>> The particular piece that I'm thinking about is nir_variable::data. >>>> Afaict this is a remnant from the early days, when the intent was to >>>> kill off the GLSL IR and use NIR directly. If so should we just nuke >>>> it, or (if there is someone working on it) add some comments "Keepme: >>>> WIP work by XXX to use this and kill the glsl IR one". >>>> >>>> The (not that distant) GLSL IR memory optimisations by Ian, seems to >>>> have missed NIR. Was that intentional or were those worked upon before >>>> NIR got merged ? Perhaps it's worth porting them over ? >>>> >>>> >>>> Thanks >>>> Emil >>>> _______________________________________________ >>>> mesa-dev mailing list >>>> mesa-dev@lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >>> Hi Emil, >>> >>> Indeed, nir_variable was copied from ir_variable before Ian's memory >>> optimizations landed. Also, as you noticed, there are a number of >>> fields only used by the GLSL linker, so they're unused until/unless we >>> do linking in NIR. I wouldn't be opposed to nuking those, since we can >>> always revert the commit if/when we get to that. >> >> Agreed. If you want to nuke some of them, feel free to send the >> patch. If you do, please CC me. There are some things that we're >> using for SPIR-V so I might request that you keep a field or two. >> However, cleaning it up would definitely be a good idea. >> >> One thing I will note though is that you should consider this a >> cleanup and not an optimization. The reason why Ian's stuff helped >> GLSL IR so much is that it uses variables extensively. The average >> NIR shader only has about half a dozen variables by the time you get >> done optimizing so it's not nearly as much of a problem. > Ack. Thanks guys. So currently no-one is pursuing move the linking to NIR ?
I have no plans to do full-blown GLSL-style linking in NIR. Those linking rules are nuts and that's what we have a GLSL compiler for. If we do any linking in NIR, it'll be much simpler. Like I said, delete at will and, if I want you to keep anything, I'll say so when you send the patches. --Jason > On the optimisation vs cleanup note - it'll be tiny bit of both. > > -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
