From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 99349] Failed to build shader (translation from TGSI) Date: Fri, 26 May 2017 13:31:12 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0604152614==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id 278FE6ED4B for ; Fri, 26 May 2017 13:31:12 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0604152614== Content-Type: multipart/alternative; boundary="14958054720.88DECB.29820"; charset="UTF-8" --14958054720.88DECB.29820 Date: Fri, 26 May 2017 13:31:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D99349 --- Comment #9 from Gert Wollny --- It turns out that in r600_shader.c:tgsi_split_constant the constants should= be moved to the GPR range, but for large shaders this is not sufficient, since= the temporary registers used there may be beyond 127 which is the limit for GPR= s.=20 tgsi_split_constant doesn't move all constants and if an operator uses the = same constant as source more than once, then one of the instances of the constan= ts is moved to a new address, and this may even be counter productive.=20 Now to fix this bug, a partial workaround is in the repo I've given above, = the patch changes the register handling to reserve a few registers in the low r= ange and moves constants there if necessary. Note, however, that it also contains additional debugging output.=20 However, for the instruction=20 LRP TEMP[0].xyz, CONST[31].wwww, CONST[31].xyzz, TEMP[0].xyzz check_and_set_bank_swizzle still fails. (This is, by the way, one such case where=20 tgsi_split_constant moves one of the instances of CONST[31] to another plac= e.)=20 I will try to correct tgsi_split_constant to not move the values around if they are originally from the same source and see whether this fixes the problem. --=20 You are receiving this mail because: You are the assignee for the bug.= --14958054720.88DECB.29820 Date: Fri, 26 May 2017 13:31:12 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comment= # 9 on bug 99349<= /a> from Gert Wollny
It turns out that in r600_shader.c:tgsi_split_constant the con=
stants should be
moved to the GPR range, but for large shaders this is not sufficient, since=
 the
temporary registers used there may be beyond 127 which is the limit for GPR=
s.=20

tgsi_split_constant doesn't move all constants and if an operator uses the =
same
constant as source more than once, then one of the instances of the constan=
ts
is moved to a new address, and this may even be counter productive.=20

Now to fix this bug, a partial workaround is in the repo I've given above, =
the
patch changes the register handling to reserve a few registers in the low r=
ange
and moves constants there if necessary. Note, however, that it also contains
additional debugging output.=20

However, for the instruction=20

 LRP TEMP[0].xyz, CONST[31].wwww, CONST[31].xyzz, TEMP[0].xyzz

check_and_set_bank_swizzle still fails. (This is, by the way, one such case
where=20
tgsi_split_constant moves one of the instances of CONST[31] to another plac=
e.)=20

I will try to correct  tgsi_split_constant to not move the values around if
they are originally from the same source and see whether this fixes the
problem.


You are receiving this mail because:
  • You are the assignee for the bug.
= --14958054720.88DECB.29820-- --===============0604152614== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0604152614==--