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 <g...@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 <haya...@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@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >>> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev