blob: b9f79d08bff61a8d9018348d49929b7d45ce8944 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
performance: 0.995
graphic: 0.965
device: 0.793
debug: 0.768
architecture: 0.703
semantic: 0.700
peripherals: 0.674
PID: 0.595
KVM: 0.588
x86: 0.497
user-level: 0.493
permissions: 0.471
arm: 0.375
i386: 0.345
risc-v: 0.319
ppc: 0.306
virtual: 0.298
mistranslation: 0.266
vnc: 0.242
socket: 0.238
kernel: 0.208
boot: 0.175
VMM: 0.166
register: 0.163
TCG: 0.157
files: 0.116
network: 0.088
hypervisor: 0.054
assembly: 0.039
Bisected: 176e3783f2ab14 results in a heavy performance regression with the SDL interface
Description of problem:
With the patch 176e3783f2ab14 a significant 3D performance regression was introduced when using the SDL gui and VirGL. Before the patch glxgears runs at about 4000 FPS on my machine, with the patch this drops to about 150 FPS, and if one moves the mouse the reported frame rate drops even more.
Steps to reproduce:
1. Run the qemu like given above with a current Debian-SID guest
2. Start glxgears from a terminal
3. Move the mouse continuously to see the extra drop in frame rate
Additional information:
* (Guest) OpenGL Renderer string: virgl (AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 18.1.8 ...)
* Reverting the commit 176e3783f2ab14 fixes the problem on SDL
* I don't think the host kernel version is an issue here (namely the KVM patches that are required to run Venus on discrete graphics cards)
* I've seen a similar issue when using GTK, but other that with SDL it's already present in version 7.2.11 (the one I used as a "good" base when I was bisecting the regression) - so I was not able to bisect yet.
* I've looked around in the code and I'm aware the that commit *shouldn't* have the impact it seems to have. I can only assume that there is some unexpected side effect when creating the otherwise unused renderer.
|