[Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v4

[Vadim Girlin]

On 04/02/2013 12:48 AM, Vincent Lejeune wrote:
> Btw where can I find some more info on stack_size ?
> I assumed it should represent the amout of max stacked exec_mask,
> but it looks like it is possible to have much more "manually" pushed exec_mask level
> than reported by nstack (iiuc a push count as much as a 1/4 of a loop level).

Yes, different instructions consume different amount of stack space. 
There is an explanation in the ISA docs, section "3.6.5 Stack 
Allocation", it's basically correct but don't expect it to be precise 
regarding the special cases (e.g. in the cayman isa doc comments in the 
table 3.6 look like a copy-paste from r600/r700 docs instead of the 
cayman-specific comments). I've added the additional info that I have 
regarding the special cases for chip generations and my notes as the 
comments in the patch (see callstack_update_max_depth function).

Vadim

>
>
>
>
> ----- Mail original -----
>> De�: Vadim Girlin <vadimgirlin at gmail.com>
>> �: Vincent Lejeune <vljn at ovi.com>
>> Cc�: Alex Deucher <alexdeucher at gmail.com>; "mesa-dev at lists.freedesktop.org" <mesa-dev at lists.freedesktop.org>
>> Envoy� le : Dimanche 31 mars 2013 22h34
>> Objet�: Re: [Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v4
>>
>> On 04/01/2013 12:00 AM, Vincent Lejeune wrote:
>>>   Hi Vadim,
>>>
>>>   Does this patch work ? (It's still not pushed)
>>
>> It works for me on evergreen, but I'm not sure about other chip generations.
>> I wanted to ask somebody to test it, but the problem is that the piglit coverage
>> for this is not enough (e.g. initial version of this patch had no regressions
>> with piglit but resulted in artifacts with Heaven). I thought about adding more
>> control flow tests but haven't written them yet. The same algorithm
>> seemingly works in my r600-sb branch with other chips, but the test coverage
>> with that branch is even lower due to the if-conversion that eliminates most of
>> the conditional control flow.
>>
>> I usually prefer not to push any patches until I'm sure that they are not
>> breaking anything. But well, possibly in this case it's easier to simply
>> push it and wait for the bug reports. I think I'll check if it needs
>> rebasing and push it in a day or two if there are no objections.
>>
>> Vadim
>>
>>>   I'm working on doing native control flow for llvm and intend to port
>> your patch on the control flow reservation.
>>>
>>>   Vincent
>>