From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 95438] Elemental demo compute shader takes ages to compile Date: Tue, 17 May 2016 02:30:52 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0199609984==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 93BF06E5F6 for ; Tue, 17 May 2016 02:30:52 +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 --===============0199609984== Content-Type: multipart/alternative; boundary="14634522520.84EF8B3CA.18583"; charset="UTF-8" --14634522520.84EF8B3CA.18583 Date: Tue, 17 May 2016 02:30:52 +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=3D95438 --- Comment #1 from Bas Nieuwenhuizen --- Last I looked at the elemental demo, we have multiple issues: - The shared array (1024 elements) get wrongly promoted to a private array. There is a fix for that at https://lists.freedesktop.org/archives/mesa-dev/2016-April/113832.html - in radeonsi we compile arrays to vectors with insert/extract element. This pretty much results in the array being SSA version, which results in a very large program. - a 1024 element vector does not fit in 256 VGPR's so LLVM tries to load and spill around every operation and therefore every versioned array element ta= kes scratch space. - As a result I needed 7 MiB of scratch space per wave, or 6,7 GiB in total= .=20 This overflows the 32-bit buffer size and we only allocate a smaller buffer. - This resulted in hangs (or maybe long long shader execution times, not really sure...). So not sure how long a long long time is, last I tried (which admittedly is some weeks ago) I certainly could get past the compilation stage. If you did get past that and did not get hangs, I'm not sure why. Fixing the first problem also circumvents problems 2 & 3, although it would= be nice to get those fixed as well. --=20 You are receiving this mail because: You are the assignee for the bug.= --14634522520.84EF8B3CA.18583 Date: Tue, 17 May 2016 02:30:52 +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= # 1 on bug 95438<= /a> from Bas Nieuwenhuizen 
Last I looked at the elemental demo, we have multiple issues:

- The shared array (1024 elements) get wrongly promoted to a private array.
There is a fix for that at
https://lists.freedesktop.org/archives/mesa-dev/2016-April/113832.h=
tml

- in radeonsi we compile arrays to vectors with insert/extract element. This
pretty much results in the array being SSA version, which results in a very
large program.

- a 1024 element vector does not fit in 256 VGPR's so LLVM tries to load and
spill around every operation and therefore every versioned array element ta=
kes
scratch space.

- As a result I needed 7 MiB of scratch space per wave, or 6,7 GiB in total=
.=20
This overflows the 32-bit buffer size and we only allocate a smaller buffer.

-  This resulted in hangs (or maybe long long shader execution times, not
really sure...).

So not sure how long a long long time is, last I tried (which admittedly is
some weeks ago) I certainly could get past the compilation stage. If you did
get past that and did not get hangs, I'm not sure why.

Fixing the first problem also circumvents problems 2 & 3, although it w=
ould be
nice to get those fixed as well.

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