[Mesa-dev] [PATCH] glsl: optimize list handling in opt_dead_code

Dave Airlie airlied at gmail.com
Tue Oct 18 01:02:53 UTC 2016


On 18 October 2016 at 08:45, Thomas Helland <thomashelland90 at gmail.com> wrote:
>
> 18. okt. 2016 00.07 skrev "Jan Ziak" <0xe2.0x9a.0x9b at gmail.com>:
>>
>> This patch replaces the ir_variable_refcount_entry's linked-list
>> with an array-list.
>>
>> The array-list has local storage which does not require ANY additional
>> allocations if the list has small number of elements. The size of this
>> storage is configurable for each variable.
>>
>> Benchmark results for "./run -1 shaders" from shader-db[1]:
>>
>> - The total number of executed instructions goes down from 64.184 to
>> 63.797
>>   giga-instructions when Mesa is compiled with "gcc -O0 ..."
>> - In the call tree starting at function do_dead_code():
>>   - the number of calls to malloc() is reduced by about 10%
>>   - the number of calls to free() is reduced by about 30%
>>
>> [1] git://anongit.freedesktop.org/mesa/shader-db
>
> Nice find. I would not be surprised if there are more cases of
> inappropriate data structures being used, causing overhead.
> I can't quite tell, as Gmail tends to mangle whitespace stuff,
> but it looks like there might be some style issues with
> not everything following the three-space indent, no tabs
> policy that mesa tries to stick to.
>
> On the subject of this patch, some thoughts that came to mind:
> I think it would be preferred if the implementation was in C.
> Using this in NIR, which tries to be C only, might be a possibility?
> I also seem to recall that I reviewed some patches that
> Jason wrote back a good while ago for NIR that implemented a
> dynamically resizing array of sorts that might be of interest.

Not sure but maybe look at the u_vector code I've extracted from the anv driver
and posted a few days ago.

Dave.


More information about the mesa-dev mailing list