[Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Marek Olšák]

On Oct 21, 2016 1:07 PM, "Tapani Pälli" <tapani.palli at intel.com> wrote:
>
>
>
> On 10/21/2016 12:51 PM, Marek Olšák wrote:
>>
>> On Fri, Oct 21, 2016 at 6:58 AM, Tapani Pälli <tapani.palli at intel.com>
wrote:
>>>
>>>
>>>
>>> On 10/20/2016 09:24 PM, Marek Olšák wrote:
>>>>
>>>>
>>>> On Thu, Oct 20, 2016 at 6:31 PM, Tapani Pälli <tapani.palli at intel.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 10/20/2016 06:55 PM, Marek Olšák wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 17, 2016 at 9:03 PM, Marek Olšák <maraeo at gmail.com>
wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The latest branch:
>>>>>>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=glsl-alloc-rework2
>>>>>>>
>>>>>>> It contains:
>>>>>>> - all review comments resolved
>>>>>>> - commits from Tapani's jenkins branch (fixes for glsl, nir, i965)
>>>>>>>
>>>>>>> My updated patches are also on the list if you wanna review them.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Since there are no other comments, it looks like it's ready to land.
>>>>>> i965 and Gallium were tested by Tapani and me, respectively. The
>>>>>> branch contains all fixes first, followed by the allocation changes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I haven't had time for further testing but it would make sense to try
>>>>> also
>>>>> with some benchmarks and steam games on i965. JP recalled there was
>>>>> something that got triggered by Manhattan earlier with his patches.
I'll
>>>>> try
>>>>> to get this testing done tomorrow.
>>>>
>>>>
>>>>
>>>> I suggest you put shaders from Manhattan into your shader-db, so that
>>>> you don't have to run the game under valgrind. Also in future, it's
>>>> better to use shader-db instead of running games for stuff like this.
>>>>
>>>
>>> Makes sense as ralloc is mostly used in compiler but I think some of
those
>>> rallocated structures get also accessed when app calls GL API. I'll run
at
>>> least gfxbench manually just as a paranoid check to see if there's
anything.
>>>
>>> About shader-db .. should we consider making a scripts folder there and
>>> start sharing some? It's used for instruction count analysis, memory
>>> analysis .. would be nice to have some sort of 'standard' skeleton
scripts
>>> for this which can be then modified for purposes.
>>
>>
>> Not sure what you mean. Our script for shader-db reporting is
si-report.py.
>>
>
> I mean scripts for comparing runs. For example for compile time
performance one might use Eric Anholt's compare-perf but that requires some
additional scripts that print correct output from run. Or maybe for leaks
it would be interesting to have a comparison summary script of memory leaks
between runs? Current scripts seem to only report instruction count
difference between 2 runs?

Well, it only reports instruction count difference for Intel. Our stats are
completely different.  I use the "time" command to measure compiler
performance. It seems to do the job well.

>
> I did run some valgrind comparisons with gfxbench4, your branch against
Mesa master. I did not spot anything obvious related to ralloc.
>
> On i965 there's a huge load of invalid writes's and read's in general but
this happens on master as well so maybe these are not 'valid hits'. There's
also some leaks both with master and your branch but your branch has less,
so it seems to fix some things.

It can't fix anything. Both allocators are hierarchical, so most code
doesn't care about freeing memory.

I usually don't see any invalid reads and writes with radeonsi.

Marek

>
> // Tapani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161021/ea0a0a2d/attachment-0001.html>