| Summary: | radv: corruption issues with Tangrams demo on Polaris | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Christoph Haag <haagch> |
| Component: | Drivers/Vulkan/radeon | Assignee: | mesa-dev |
| Status: | RESOLVED NOTOURBUG | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | corruption at small resolutions | ||
|
Description
Christoph Haag
2018-06-14 21:05:00 UTC
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.