RX 480 mesa radv 41dabdc4753 llvm 7svn 165520 The demo is for windows only and I think closed source but it runs well with the most recent amdvlk. On radv it crashes. You can get it here: http://www.pouet.net/prod.php?which=76464 Make a 64 bit wine prefix, run wine64 Tangrams.exe, click demo and it immediately crashes with this message: LLVM ERROR: Cannot select: 0x7e8d8750: i16 = bitcast 0x7e8d8af8 0x7e8d8af8: f32,ch = BUFFER_LOAD<(dereferenceable load 4 from custom TargetCustom7, align 1, addrspace 4)> 0x7d433f78, 0x7e8d7430, Constant:i32<0>, 0x7e8d7638, Constant:i1<0>, Constant:i1<0> 0x7e8d7430: v4i32,ch = load<(dereferenceable invariant load 16 from %ir.56, addrspace 6)> 0x7d433f78, 0x7e8d72f8, undef:i32 0x7e8d72f8: i32 = add 0x7e8ce2c8, Constant:i32<48> 0x7e8ce2c8: i32,ch = CopyFromReg 0x7d433f78, Register:i32 %100 0x7e8ce260: i32 = Register %100 0x7e8d3e40: i32 = Constant<48> 0x7e8cebb8: i32 = undef 0x7e8ceb50: i32 = Constant<0> 0x7e8d7638: i32 = add 0x7e8d73c8, Constant:i32<2> 0x7e8d73c8: i32 = mul 0x7e96cb20, Constant:i32<6> 0x7e96cb20: i32 = add 0x7e96c918, 0x7e96c9e8 0x7e96c918: i32 = mulhs 0x7e8ce810, Constant:i32<1431655766> 0x7e8ce810: i32 = add 0x7e8ce538, 0x7e8ce398 0x7e8ce538: i32,ch = CopyFromReg 0x7d433f78, Register:i32 %103 0x7e8ce4d0: i32 = Register %103 0x7e8ce398: i32,ch = CopyFromReg 0x7d433f78, Register:i32 %101 0x7e8ce330: i32 = Register %101 0x7e8d7290: i32 = Constant<1431655766> 0x7e96c9e8: i32 = srl 0x7e96c918, Constant:i32<31> 0x7e96c918: i32 = mulhs 0x7e8ce810, Constant:i32<1431655766> 0x7e8ce810: i32 = add 0x7e8ce538, 0x7e8ce398 0x7e8ce538: i32,ch = CopyFromReg 0x7d433f78, Register:i32 %103 0x7e8ce4d0: i32 = Register %103 0x7e8ce398: i32,ch = CopyFromReg 0x7d433f78, Register:i32 %101 0x7e8ce330: i32 = Register %101 0x7e8d7290: i32 = Constant<1431655766> 0x7e96c980: i32 = Constant<31> 0x7e8d7360: i32 = Constant<6> 0x7e8d75d0: i32 = Constant<2> 0x7e8d3b68: i1 = Constant<0> 0x7e8d3b68: i1 = Constant<0> In function: main
Can reproduce a LLVM error here.
If this is any indication it may just be not checking exts: SPIR-V WARNING: In file ../mesa/src/compiler/spirv/spirv_to_nir.c:3312 Unsupported SPIR-V capability: SpvCapabilityInt16 28 bytes into the SPIR-V binary SPIR-V WARNING: In file ../mesa/src/compiler/spirv/spirv_to_nir.c:3394 Unsupported SPIR-V capability: SpvCapabilityStorageBuffer16BitAccess 36 bytes into the SPIR-V binary SPIR-V WARNING: In file ../mesa/src/compiler/spirv/spirv_to_nir.c:3394 Unsupported SPIR-V capability: SpvCapabilityUniformAndStorageBuffer16BitAccess 44 bytes into the SPIR-V binary Since we don't support these. (or the undef is messing things up, let me find out where it gets introduced)
So top level is a f32 -> i16 bitcast: Cannot select: 0x7e8d8750: i16 = bitcast 0x7e8d8af8 which is not allowed. Is in LLVM source: %76 = call float @llvm.amdgcn.buffer.load.f32(<4 x i32> %75, i32 0, i32 %74, i1 false, i1 false) #3 %77 = bitcast float %76 to i16 Happens in the nir: vec1 16 ssa_115 = intrinsic load_ssbo (ssa_113, ssa_114) () () I'm really inclined to say it is our lacking 16-bit support.
After seeing https://www.phoronix.com/scan.php?page=news_item&px=RADV-VK_KHR_16bit_storage I thought I'd try again. I now get a much clearer error: SPIR-V WARNING: In file ../src/compiler/spirv/spirv_to_nir.c:3436 Unsupported SPIR-V capability: SpvCapabilityInt16 28 bytes into the SPIR-V binary The application then (unsurprisingly) crashes.
Missing 16-bit integer support.
The demo should now work if you apply: https://patchwork.freedesktop.org/series/49701/ https://patchwork.freedesktop.org/series/49710/
Created attachment 141569 [details] corruption at small resolutions Nice, with the patches it runs without crashing. At 1920x1080 it looks good, but when choosing smaller resolutions, corruption appears. In the default 720x400 it's pretty bad. I have no idea if the corruption is in any way related to the 16 bit support though. RX 480, llvm 8.0.0svn_r169421, latest radv git + patches
Thanks for checking. Apparently the corruption is Polaris specific. On vega it works nice, if you have the hardware can you confirm?
I pushed both series but still need to figure out the problem on Polaris.
So, this demo has several problems: - Not enough memory allocated in a pool which ends up by crashing with RADV. It does work with AMDVLK because they always allocate more space than needed. I pushed a change for that this week, but it was actually wrong and has been reverted. So, expect a crash anyway. - Use of 16-bit integers without checking if shaderInt16 is supported. - Possibly a missing barrier which might explain the rendering glitches on GFX8 (syncing GFX shaders and invalidating L2 seems to fix the problem). Tangrams is buggy in many ways and I don't think it's worth trying to investigate more.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.