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

[Marcello Maggioni]

Hi Marek,

I tried doing what you suggested and the game runs , but when the offending
shader is loaded the game FPS drop to like 0.1 making everything
unplayable. Other parts of the game (that don't make use of that shader,
like menus and most of the levels) are fine though.

With the check in place instead the performance is acceptable (I guess
because the shader that fails to compile is not run altogether)

Marcello


2014-04-20 2:02 GMT+01:00 Marek Olšák <maraeo at gmail.com>:

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