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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
