[Mesa-dev] The way r600g handles shaders that use more than available GPRs

[Grigori Goronzy]

On 20.04.2014 03:02, Marek Olšák wrote:
> It looks like the check is not needed with SB, because SB performs
> register allocation. What happens if you comment out the conditional
> which fails?
>

SB takes the machine code generated by the "classic" compiler as input, 
so the check is still needed. The best solution for this problem would 
be to integrate Vadim's tgsi-to-sb branch, which goes directly from TGSI 
to SB's internal representation, without the classic compiler as a 
middle man.

As far as I know, even with SB there is no spilling implemented, but it 
should only be a problem with really crazy shaders. SB optimizes 
register usage quite well.

Grigori

> Marek
>
> On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni <hayarms at gmail.com> wrote:
>> Hello,
>>
>> I realized while playing Diablo III on my machine that some shaders seem to
>> run out of available GPRs using r600g with my Macbook Pro with a HD6750m.
>> If the driver tries to do something to handle this case, but I couldn't find
>> any part inside the code that has to do with "spilling".
>>
>> There are some register related passes in SB, but none seems to be related
>> to possible spilling (anyway, the failing I get is in r600_shader.c:2148
>> inside "r600_shader_from_tgsi()" which makes shader compiling failing
>> altogether skipping SB).
>>
>> How does r600g handle out of register situations? If it doesn't there are
>> plans to add this?
>>
>> Cheers,
>> Marcello
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>