- User Since
- Jan 4 2017, 12:11 PM (141 w, 2 d)
Jul 11 2019
Thanks for the quick fix Matt!
; ModuleID = 'mesa-shader' source_filename = "mesa-shader" target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-ni:7" target triple = "amdgcn-mesa-mesa3d"
Is this expected that a bunch of tests with Mesa now crash because amdgcn.s.waitcnt is not found?
This change introduced CTS regressions with RADV like dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_3.atan2_frag and friends.
Can you investigate ?
Jun 28 2019
Do you plan to fix it? It breaks a bunch of games.
Jun 26 2019
Jun 14 2019
Sorry for the noise.
Should be fixed with https://patchwork.freedesktop.org/patch/310419/?series=62097&rev=1
Do we need to update the intrinsic name from mesa?
Btw, it's not related to RADV, RadeonSI is probably affected too because the LLVM backend is common.
This change introduces a bunch of failures with CTS on GFX8/GFX9. Looks like the IR validation fail now, see below:
Jun 5 2019
I have updated the change ttps://reviews.llvm.org/D62614 this Sunday.
The new one takes completely different approach. I'd appreciate very much If you could try it.
Jun 3 2019
May 27 2019
May 16 2019
Thank you too!
Can you eventually push the patch for me? I think I no longer have commit access since the LLVM relicense stuff.
v3: - remove most of the LLVM IR
May 15 2019
May 9 2019
Yes, it did fix the problem.
Do you plan to backport to LLVM 8?
May 8 2019
May 7 2019
May 6 2019
Apr 30 2019
Apr 26 2019
SI is still broken without this patch.
Apr 22 2019
Apr 21 2019
Apr 9 2019
This fixes the SI regression with RADV.
Thanks a lot Tim.
Mar 28 2019
This change breaks SI, at least with RADV.
Here's how to reproduce: ./deqp-vk --deqp-case=dEQP-VK.glsl.builtin.function.integer.bitfieldreverse.ivec3_highp_tess_control
Mar 26 2019
Thanks for the quick fix Matt!
This introduces a regression with this LLVM IR https://hastebin.com/yuzomezazi
It crashes inside llvm::SIInstrInfo::areLoadsFromSameBasePtr for some reasons.
Do you have the cmpswap fix somewhere?
Jan 9 2019
Thanks for the fix!
Dec 21 2018
Please have look at https://bugs.llvm.org/show_bug.cgi?id=40129
Dec 14 2018
Unfortunately, I can't get any LLVM IR because it crashes too early in the process. You can also reproduce the problem with RadeonSI btw.
Dec 13 2018
Yes, it does fix the issue. Thanks!
This patch breaks RADV (and probably RadeonSI as well). Here's a backtrace of the problem:
Dec 11 2018
Did you get a chance to look into this?
Dec 6 2018
This change breaks most of the subgroups tests with RADV (ie. dEQP-VK.subgroups.arithmetic.*).
Dec 4 2018
Oct 31 2018
This regresses the following tests on RADV:
Oct 17 2018
Thank you for this really important fix!
Aug 22 2018
Should I push the patch as is? Or does it need another revision?
Aug 21 2018
v5: rename MAX_COMMON_ADDRESS to MAX_AMDGPU_ADDRESS
Aug 20 2018
Both patches (r340171 and r340172) have been reverted with r340202 because it will be easier for a backport.
This new version squashes these two and includes the alias rules table fix (ie. out of bounds access).
v2: add a test with swapped parameters
v3: use static_assert()
Aug 17 2018
v2: add a very simple test for 32-bit addr space
May 25 2018
May 23 2018
May 3 2018
Without this patch, it appears to me that we are selecting
the wrong operand when inverting conditions. In the attached
test, it will select %tmp3 instead of %tmp4. To fix it, just
use 'A' as everywhere.
May 2 2018
Apr 25 2018
Any news on the revert? Thanks!
Apr 13 2018
Apr 9 2018
Apr 6 2018
Apr 3 2018
- init EnableDS128 in the constructor
Mar 30 2018
- use a return ternary operator
- fix feature format
- add small test load-local-f32-no-ds128.ll
Mar 29 2018
Mar 28 2018
Mar 15 2018
Mar 7 2018
- add a sanity check when a block is looping over itself
- cosmetic changes
- replace the LLVM IR testcase with a MIR one
- remove one unused variable in isLoopBottom()
- do not rely on block numbfer in isLoopBottom()
Mar 6 2018
v6: fix the multiple back-edges case and update the testcase
v5: run -dce to remove redundant phis
Mar 5 2018
v4: - run 'opt -S -deadarghaX0r -strip -strip-debug -strip-dead-prototypes -instnamer'
- remove RFC on the subject
v3: reduced testcase
Mar 2 2018
So, the expcnt(0) is generated because there is a buffer_atomic_add in that test case, which actually makes sense to me. Looks like this patch also fixes that case.