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 09:01:01 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2117145402==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id F2DDD6EC1F for ; Fri, 26 May 2017 09:01:00 +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 --===============2117145402== Content-Type: multipart/alternative; boundary="14957892603.D2EF9F.28328"; charset="UTF-8" --14957892603.D2EF9F.28328 Date: Fri, 26 May 2017 09:01:00 +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 #7 from Gert Wollny --- Now, just multiplying two constants/uniforms not necessarily trigger the b= ug. With a simple shader program like=20 uniform vec4 base_color; uniform vec4 test; uniform vec4 test2; uniform vec4 test3; void main() { vec4 h1 =3D base_color * test; vec4 h2 =3D test2 * test3; gl_FragColor =3D h1 * h2; } for both const-const multiplications one constant is always addressed via a GPR, i.e. I get=20 1: MUL TEMP[0], CONST[0], CONST[1] r600_shader.c:3986 tgsi_op2_s - About to multiply two constants r600_shader.c:4000 tgsi_op2_s - ctx->src[0]:=20 sel:7 // this is a GPR address=20 swizzle:0 1 2 3 neg:0 abs:0 rel:0 kc_bank:0 kc_rel:0 value:0 0 0 0 r600_shader.c:4000 tgsi_op2_s - ctx->src[1]:=20 sel:513 // this is a cfile address=20 swizzle:0 1 2 3 neg:0 abs:0 rel:0 kc_bank:0 kc_rel:0 value:0 0 0 0 and then check_vector/reserve_cfile can successfully assign the read ports = via cfile because only 4 values need to be read.=20 However, for a more complicated shader I get the following:=20=20 250: MUL TEMP[11], CONST[26], CONST[23] r600_shader.c:3986 tgsi_op2_s - About to multiply two constants r600_shader.c:4000 tgsi_op2_s - ctx->src[0]:=20 sel:160 // cfile kcache after translation=20 swizzle:0 1 2 3 neg:0 abs:0 rel:0 kc_bank:0 kc_rel:0 value:0 0 0 0 r600_shader.c:4000 tgsi_op2_s - ctx->src[1]:=20 sel:535 // cfile kcache before translation=20 swizzle:0 1 2 3 neg:0 abs:0 rel:0 kc_bank:0 kc_rel:0 value:0 0 0 0 r600_asm.c:472 check_vector - bs->hw_cfile_addr:[-1 -1] bs->hw_cfile_elem: [-1 -1] bank_swizzle:0 num_src:2 r600_asm.c:494 check_vector - src 0: sel:160 elem:0 r600_asm.c:423 reserve_cfile - res=3D0: bs->hw_cfile_addr:-1 bs->hw_cfile_elem:-1 sel:160 chan:0 r600_asm.c:494 check_vector - src 1: sel:535 elem:0 r600_asm.c:423 reserve_cfile - res=3D0: bs->hw_cfile_addr:160 bs->hw_cfile_elem:0 sel:535 chan:0 r600_asm.c:423 reserve_cfile - res=3D1: bs->hw_cfile_addr:-1 bs->hw_cfile_elem:-1 sel:535 chan:0 r600_asm.c:472 check_vector - bs->hw_cfile_addr:[160 535] bs->hw_cfile_el= em: [0 0] bank_swizzle:0 num_src:2 r600_asm.c:494 check_vector - src 0: sel:160 elem:1 r600_asm.c:423 reserve_cfile - res=3D0: bs->hw_cfile_addr:160 bs->hw_cfile_elem:0 sel:160 chan:0 r600_asm.c:494 check_vector - src 1: sel:535 elem:1 r600_asm.c:423 reserve_cfile - res=3D0: bs->hw_cfile_addr:160 bs->hw_cfile_elem:0 sel:535 chan:0 r600_asm.c:423 reserve_cfile - res=3D1: bs->hw_cfile_addr:535 bs->hw_cfile_elem:0 sel:535 chan:0 r600_asm.c:472 check_vector - bs->hw_cfile_addr:[160 535] bs->hw_cfile_el= em: [0 0] bank_swizzle:0 num_src:2 r600_asm.c:494 check_vector - src 0: sel:160 elem:2 r600_asm.c:423 reserve_cfile - res=3D0: bs->hw_cfile_addr:160 bs->hw_cfile_elem:0 sel:160 chan:1 r600_asm.c:423 reserve_cfile - res=3D1: bs->hw_cfile_addr:535 bs->hw_cfile_elem:0 sel:160 chan:1 r600_asm.c:436 reserve_cfile - All cfile read ports are used, cannot refere= nce vector element. In summary allocating a read port for elem >=3D 2 fails, because it would m= ean reading more than four values in one instruction group, and this is ot poss= ible according to the AMD Evergreen-Family instruction set manual 4.7.5. --=20 You are receiving this mail because: You are the assignee for the bug.= --14957892603.D2EF9F.28328 Date: Fri, 26 May 2017 09:01:00 +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= # 7 on bug 99349<= /a> from Gert Wollny 
Now, just  multiplying two constants/uniforms not necessarily =
trigger the bug.
With a simple shader program like=20

uniform vec4 base_color;
uniform vec4 test;
uniform vec4 test2;
uniform vec4 test3;

void main()
{
 vec4 h1 =3D base_color * test;
 vec4 h2 =3D test2 * test3;
 gl_FragColor =3D h1 * h2;
}

for both const-const multiplications one constant is always addressed via a
GPR, i.e. I get=20

  1: MUL TEMP[0], CONST[0], CONST[1]
r600_shader.c:3986 tgsi_op2_s - About to multiply two constants
r600_shader.c:4000 tgsi_op2_s -  ctx->src[0]:=20
                  sel:7   // this is a GPR address=20
              swizzle:0 1 2 3
                  neg:0
                  abs:0
                  rel:0
              kc_bank:0
               kc_rel:0
                value:0 0 0 0

r600_shader.c:4000 tgsi_op2_s -  ctx->src[1]:=20
                  sel:513  // this is a cfile address=20
              swizzle:0 1 2 3
                  neg:0
                  abs:0
                  rel:0
              kc_bank:0
               kc_rel:0
                value:0 0 0 0

and then check_vector/reserve_cfile can successfully assign the read ports =
via
cfile because only 4 values need to be read.=20


However, for a more complicated shader I get the following:=20=20

250: MUL TEMP[11], CONST[26], CONST[23]
r600_shader.c:3986 tgsi_op2_s - About to multiply two constants
r600_shader.c:4000 tgsi_op2_s -  ctx->src[0]:=20
                  sel:160  // cfile kcache after  translation=20
              swizzle:0 1 2 3
                  neg:0
                  abs:0
                  rel:0
              kc_bank:0
               kc_rel:0
                value:0 0 0 0

r600_shader.c:4000 tgsi_op2_s -  ctx->src[1]:=20
                  sel:535 // cfile kcache before  translation=20
              swizzle:0 1 2 3
                  neg:0
                  abs:0
                  rel:0
              kc_bank:0
               kc_rel:0
                value:0 0 0 0

r600_asm.c:472 check_vector -  bs->hw_cfile_addr:[-1 -1]  bs->hw_cfil=
e_elem:
[-1 -1] bank_swizzle:0  num_src:2
r600_asm.c:494 check_vector -  src 0: sel:160 elem:0
r600_asm.c:423 reserve_cfile -   res=3D0: bs->hw_cfile_addr:-1
bs->hw_cfile_elem:-1 sel:160 chan:0
r600_asm.c:494 check_vector -  src 1: sel:535 elem:0
r600_asm.c:423 reserve_cfile -   res=3D0: bs->hw_cfile_addr:160
bs->hw_cfile_elem:0 sel:535 chan:0
r600_asm.c:423 reserve_cfile -   res=3D1: bs->hw_cfile_addr:-1
bs->hw_cfile_elem:-1 sel:535 chan:0
r600_asm.c:472 check_vector -  bs->hw_cfile_addr:[160 535]  bs->hw_cf=
ile_elem:
[0 0] bank_swizzle:0  num_src:2
r600_asm.c:494 check_vector -  src 0: sel:160 elem:1
r600_asm.c:423 reserve_cfile -   res=3D0: bs->hw_cfile_addr:160
bs->hw_cfile_elem:0 sel:160 chan:0
r600_asm.c:494 check_vector -  src 1: sel:535 elem:1
r600_asm.c:423 reserve_cfile -   res=3D0: bs->hw_cfile_addr:160
bs->hw_cfile_elem:0 sel:535 chan:0
r600_asm.c:423 reserve_cfile -   res=3D1: bs->hw_cfile_addr:535
bs->hw_cfile_elem:0 sel:535 chan:0
r600_asm.c:472 check_vector -  bs->hw_cfile_addr:[160 535]  bs->hw_cf=
ile_elem:
[0 0] bank_swizzle:0  num_src:2
r600_asm.c:494 check_vector -  src 0: sel:160 elem:2
r600_asm.c:423 reserve_cfile -   res=3D0: bs->hw_cfile_addr:160
bs->hw_cfile_elem:0 sel:160 chan:1
r600_asm.c:423 reserve_cfile -   res=3D1: bs->hw_cfile_addr:535
bs->hw_cfile_elem:0 sel:160 chan:1
r600_asm.c:436 reserve_cfile - All cfile read ports are used, cannot refere=
nce
vector element.

In summary allocating a read port for elem >=3D 2 fails, because it woul=
d mean
reading more than four values in one instruction group, and this is ot poss=
ible
according to the AMD Evergreen-Family instruction set manual 4.7.5.

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