This sounds like a very sensible solution if the direction the driver wants to go is having SB as the only backend<div> </div><div>Marcello On Sunday, 20 April 2014, Grigori Goronzy <<a href="mailto:greg@chown.ath.cx">greg@chown.ath.cx</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20.04.2014 03:02, Marek Olšák wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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? </blockquote> 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 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Marek On Sun, Apr 20, 2014 at 1:30 AM, Marcello Maggioni <<a>hayarms@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <a>mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> _______________________________________________ mesa-dev mailing list <a>mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> </blockquote></div>