[Mesa-dev] [PATCH 00/26] GLSL memory diet

Matt Turner mattst88 at gmail.com
Thu Sep 4 23:14:34 PDT 2014


On Fri, Jul 18, 2014 at 4:35 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Tue, Jul 15, 2014 at 10:37 AM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Mon, Jul 14, 2014 at 3:48 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> Most of these patches have been sent to the list already in one form or
>>> another.  There are a few changes, removals, and additions.  The series
>>> has also been re-ordered.
>>>
>>> - The extra memory accounting code has been removed.  This was suggested
>>>   by Ken.  Instead, all memory usage data is from Valgrind massiv.
>>>
>>> - The "store short names where padding would be" code is still there,
>>>   but many of the patches to shorten the names of temporaries has been
>>>   removed.  Those patches became unnecessary because...
>>>
>>> - In release builds (when MESA_GLSL is also unset), all temporaries get
>>>   the name "compiler_temp" that is in static storage.
>>>
>>> - A small set of names that frequently occur in shader-db are kept in
>>>   static storage.  When a variable is created with one of these names,
>>>   no additional storage is allocated.  We could probably give local
>>>   variables and post-linking globals the same treatment as temporaries,
>>>   but a lot of the frequently occuring names (that don't fit in padding)
>>>   are uniforms or shader inputs.  These need to keep their names.
>>>
>>> I suspect the last six patches will be contentious.  I'd like to get the
>>> first 20 (or at least the first two!) reviewed and landed sooner... then
>>> we can debate the last few more leisurely.
>>
>> The first 9 (so far) are
>>
>> Reviewed-by: Matt Turner <mattst88 at gmail.com>
>
> As are 10-20.
>
> Patch 22 should just mark the enum as packed, and then you can drop
> patch 21. With that, patch 22 is also R-b.

So you never committed any of these twenty patches I reviewed? Looks
like Ken committed three of them this week without my R-b attached.


More information about the mesa-dev mailing list