OpenSCAD rendering incorrect and inconsistent on radeonsi
This whole conversation started out as an OpenSCAD bug report but at the moment the leading theory over there is that it may be a Mesa 24.*-with-radeonsi issue.
There's more data in the OpenSCAD ticket, but I'll reproduce most of the important things here.
I used the following script:
#!/bin/bash
bn='base_left_slim'
infile="${bn}"'.scad'
outfile1="${bn}"'_1_apitrace.png'
outfile2="${bn}"'_2_apitrace.png'
tracefile1="${bn}"'_1.apitrace'
tracefile2="${bn}"'_2.apitrace'
DISPLAY=:0 apitrace trace --output "${tracefile1}" ~/install/openscad/openscad/build/openscad -o "${outfile1}" "${infile}"
DISPLAY=:0 apitrace trace --output "${tracefile2}" ~/install/openscad/openscad/build/openscad -o "${outfile2}" "${infile}"
With that particular .scad file, the issue is inconsistent. (With other files, it's consistent. With other files, it doesn't seem reproducible at all. With this particular file, how frequent the issue apparently depends on the alignment of the planets. Just in the last few runs, it probably was reproduced seven out of ten times or so.) I just re-ran the script several times until I happened to get a single run where the first of the two runs in this file did not reproduce the issue and the second did reproduce the issue.
The issue is reproducible both when rendering to PNG and when rendering in the OpenSCAD GUI.
I'm not sure you'd be interested in the source code from the base_left_slim.scad file referenced in the above bash script, but here it is if you want it.
Here's the expected PNG output when the issue is not reproduced:
And the associated apitrace: base_left_slim_1.apitrace
Here's the glitched PNG output when the issue is reproduced:
And the associated apitrace: base_left_slim_2.apitrace
(I tried diffing the api trace dumps from the two apitrace files and didn't find anything that would explain the inconsistent PNG output. Not that I'd really know what to look for. Heh.)
This issue is reproducible on Mesa 24.0.0, 24.0.2, and 24.0.3 . It's not reproducible on Mesa 23.X . And it seems to be a radeonsi-specific issue.
System information
inxi -GSC -xx
output:
System:
Host: wickedcool Kernel: 6.7.9-arch1-1 arch: x86_64 bits: 64 compiler: gcc
v: 13.2.1
Desktop: Sway v: 1.9 dm: N/A Distro: Arch Linux
CPU:
Info: quad core model: AMD Ryzen 3 1300X bits: 64 type: MCP arch: Zen rev: 1
cache: L1: 384 KiB L2: 2 MiB L3: 8 MiB
Speed (MHz): avg: 2239 high: 2986 min/max: 1550/3500 boost: enabled cores:
1: 1357 2: 2983 3: 1630 4: 2986 bogomips: 27952
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3
Graphics:
Device-1: AMD Curacao XT / Trinidad [Radeon R7 370 R9 270X/370X]
vendor: PC Partner / Sapphire driver: amdgpu v: kernel arch: GCN-1 pcie:
speed: 8 GT/s lanes: 4 ports: active: DP-1,HDMI-A-1 empty: DVI-D-1,DVI-I-1
bus-ID: 26:00.0 chip-ID: 1002:6810 temp: 55.0 C
Device-2: Sunplus Innovation ezcap U3 capture
driver: snd-usb-audio,uvcvideo type: USB rev: 2.1 speed: 480 Mb/s lanes: 1
bus-ID: 1-5:2 chip-ID: 1bcf:2c99
Display: wayland server: X.org v: 1.21.1.11 with: Xwayland v: 23.2.4
compositor: Sway v: 1.9 driver: X: loaded: amdgpu unloaded: modesetting,vesa
alternate: fbdev dri: radeonsi gpu: amdgpu d-rect: 3280x1848 display-ID: 1
Monitor-1: DP-1 pos: primary,top-left model: HP 24mh res: 1920x1080
dpi: 93 diag: 604mm (23.8")
Monitor-2: HDMI-A-1 pos: bottom-r model: ELEFT326 res: 1360x768 dpi: 49
diag: 801mm (31.5")
API: EGL Message: EGL data requires eglinfo. Check --recommends.
This issue is reproducible both on xorg-server with i3-gaps and Wayland (Sway, specifically) via Xwayland.
Here's the line in lspci
corresponding with my graphics card:
26:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X]
And here's my dmesg
output in case it's helpful: dmesg.txt
Oh, and none of RADV_DEBUG
, ACO_DEBUG
, or RADV_PERFTEST
are set on my system. RADV_DEBUG=llvm
has no effect.
Please let me know if I can provide any other information. And thanks for taking a look.