[Mesa-dev] [PATCH v3] glsl: fix some strict aliasing issues in exec_list

Davin McCall davmac at davmac.org
Wed Jul 1 14:50:24 PDT 2015


On 01/07/15 16:46, Eero Tamminen wrote:
> Hi,
>
> On 06/30/2015 01:15 AM, Davin McCall wrote:
>> This is the third iteration of a patch to resolve a strict aliasing
>> problem in the exec_list structure.
>>
>> At the suggestion of Francisco Jerez this is a return to the original
>> (v1) style of the patch, which replaces the three 'exec_node *' members
>> in the list with two 'struct exec_node' members.
>>
>> Some performance/memory measurements (made by replaying a Dota 2 trace,
>> using i965 driver with INTEL_NO_HW=1). All values are averages over 5
>> runs. "MRSS" is maximum resident set size as reported by GNU "time" (I'm
>> not sure I trust its value, but I believe it's indicative of relative
>> memory use).
>
> While RSS gives rough estimate of relative change, resident set size is affected by other running processes (they can cause pages to be dropped due to memory pressure or cause pages for parts of libs you're not using to get paged in).
>
> When you want to track how much memory allocations take from the system, it's better (but more work) to sum private dirty values from /proc/PID/smaps, as heap & stack are not shared with other processes. E.g. smem tool can do that for you.

Thanks - I'll check out smem. (It seems like there's a need for another tool here - something that takes smem-like snapshots regularly, and calculates average and maximum usage of a program while it runs. Maybe I'll try to put something together when I have some time).

I think the measurements I've already done, while perhaps not super precise, are at least indicative. (I did 5 runs of each test, and the deviation of values wasn't particularly high between runs of the same test).

Davin



More information about the mesa-dev mailing list