[Mesa-dev] [PATCH 2/3] st: Sweep NIR after linking phase to free held memory

Timothy Arceri tarceri at itsqueeze.com
Thu Jul 19 09:30:05 UTC 2018


> On 19.07.18 11:47, Timothy Arceri wrote:
>> On 19/07/18 08:31, Eric Anholt wrote:
>>> Danylo Piliaiev <danylo.piliaiev at 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.piliaiev at 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.


More information about the mesa-dev mailing list