Timothy Arceri <tarc...@itsqueeze.com> writes: >> On 19.07.18 11:47, Timothy Arceri wrote: >>> On 19/07/18 08:31, Eric Anholt wrote: >>>> Danylo Piliaiev <danylo.pilia...@gmail.com> writes: >>>> >>>>> After optimization passes and many trasfromations most of memory >>>> >>>> "transformations" >>>> >>>>> NIR holds is a garbage which was being freed only after shader >>>>> deletion. >>>> >>>> "is garbage" >>>> >>>>> Freeing it at the end of linking will save memory which would be useful >>>>> in case there are a lot of complex shaders being compiled. >>>>> The common case for this issue is 32bit game running under Wine. >>>>> >>>>> The cost of the optimization is around ~3-5% of compilation speed >>>>> with complex shaders. >>>>> >>>>> Signed-off-by: Danylo Piliaiev <danylo.pilia...@globallogic.com> >>>> >>>> This seems good, and I'm running it through the CTS now. >>>> >>> >>> The problem is this does the sweep too early. We still do lots of work >>> on NIR after this, I've thought about this a few times and it really >>> seems we should be able to call a driver specific function from the st >>> and pass it the IR so it can do what ever it wants (lowering opts etc) >>> and spits it back out. Once this is done we should then call sweep and >>> cache the IR. >>> >>> At the very least we should call sweep before we cache NIR rather than >>> where this patch places it. >> I debugged mesa once more and cannot see where else memory is allocated >> for NIR after this sweep. Could you point it to me? After this sweep the >> memory NIR holds never grows. Later this NIR is cloned from and these >> cloned NIRs are being sweeped in other place. > > Ah yes you are right. We do clone it when creating variants I'd > forgotten about that. In that case please ignore my comment.
I've gone ahead and pushed this patch now.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
