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

[Marcello Maggioni]

This sounds like a very sensible solution if the direction the driver wants
to go is having SB as the only backend

Marcello

On Sunday, 20 April 2014, Grigori Goronzy <greg at chown.ath.cx> wrote:

> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140420/a639169d/attachment-0001.html>