glFlush() blocks until close to GPU completion on Radeon R9 270
System information
System:
Host: workstation Kernel: 6.5.12-300.fc39.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 2.40-13.fc39 Desktop: GNOME v: 45.1 tk: GTK v: 3.24.38
wm: gnome-shell dm: GDM Distro: Fedora release 39 (Thirty Nine)
CPU:
Info: quad core model: Intel Xeon W3520 bits: 64 type: MT MCP arch: Nehalem
rev: 5 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 1599 high: 1600 min/max: 1596/2661 boost: enabled cores:
1: 1597 2: 1600 3: 1600 4: 1600 5: 1600 6: 1600 7: 1600 8: 1600
bogomips: 42668
Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: AMD Curacao PRO [Radeon R7 370 / R9 270/370 OEM] vendor: ASUSTeK
driver: amdgpu v: kernel arch: GCN-1 pcie: speed: 5 GT/s lanes: 16 ports:
active: DVI-D-1,HDMI-A-1 empty: DP-1,DVI-I-1 bus-ID: 02:00.0
chip-ID: 1002:6811 temp: 52.0 C
Device-2: Logitech HD Pro Webcam C920 driver: snd-usb-audio,uvcvideo
type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 3-3:4 chip-ID: 046d:082d
Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.2
compositor: gnome-shell driver: X: loaded: radeon
unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: 0
Monitor-1: DVI-D-1 model: LG (GoldStar) IPS FULLHD res: 1920x1080 dpi: 102
diag: 551mm (21.7")
Monitor-2: HDMI-A-1 model: LG (GoldStar) ULTRAWIDE res: 2560x1080 dpi: 97
diag: 730mm (28.8")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: swrast
gbm: drv: kms_swrast surfaceless: drv: radeonsi wayland: drv: radeonsi x11:
drv: radeonsi
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.2.1 glx-v: 1.4
direct-render: yes renderer: AMD Radeon R9 200 Series (pitcairn LLVM 16.0.6
DRM 3.54 6.5.12-300.fc39.x86_64) device-ID: 1002:6811 display-ID: :0.0
Describe the issue
On @nekohayo's Radeon R9 270, glFlush()
calls inside Mutter block until the GPU work is almost done. They work normally (block only briefly for command submission) on other AMD and Intel GPUs I tested (RX 6700M, 680M, Ryzen 5 3500U).
This blocking is a bit of a problem because it delays KMS update submission, which means that some frames, that would otherwise make it in time for VBlank, are dropped.
I've investigated the situation with the Tracy profiler. During the block, gdrv0 and rcs0 threads are going back and forth between each other.
The backtrace of the block is pretty much the same every time.
We then tried running GNOME Shell with all GL threads disabled (mesa_glthread=false GALLIUM_THREAD=0 RADEON_THREAD=0
), and got this backtrace for the block. It seems that the block had moved to the glDrawElements()
calls instead of glFlush()
.
We also tried radeon.si_support=0 amdgpu.si_support=1
kernel arguments in addition to disabling the GL threads, which had the same general behavior:
For comparison, here's what it looks like on a Ryzen 5 3500U where it works as expected. Here you can see the GPU work happening asynchronously and not causing CPU stalls.
Regression
Not that I know of, but I also noticed it only recently, on F39.