Graphics performance is absolutely dismal, to the point of unusability

[Kevin L Mitchell]

I use Fedora 29 with the Cinnamon desktop (runs in X, requires 3D acceleration). I have been having pretty dismal graphics performance, to the point where I have to stop typing and let the application catch up with me so that I can spot stuck keys and dropped keystrokes. It appears numerous X events get dropped in some fashion; often, my shift key gets stuck, as if the key_release event was missed, but that's not the only key that'll get stuck. I have the same issue with mouse clicks, too, which makes it a bit difficult to cut and paste text or select options in menus. For the record, this is a freshly created VM utilizing the VMSVGA driver, scaled by 175%, with 3D acceleration activated; resolution is 1920x1200. When I upgraded from a 6.0.5 pre-release and updated the guest tools, Cinnamon started complaining about using software rendering, although I can see the vmwgfx and vboxvideo drivers loaded. If I run glxinfo, I see "OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)" in the output. I've also started to node, with the 6.0.6 release, that the Menu is getting randomly activated, as if I hit the Windows key.

(Host is osX.)

[Kevin L Mitchell]

VBox.log for affected guest

[Michael Thayer]

Subscribe.

[boxer01]

Maybe this is the same issue as in my ticket? #18592

[Kevin L Mitchell]

Actually, I think my issue could be related to #18529, where redraws inside the VM result in some sort of redraw storm on the host side. The only discrepancy is that the reporter of #18529 reports that disabling 2D acceleration resolved the issue for him, but I don't have 2D acceleration enabled on my VM.

[ferdek]

VoidLinux+VBoxSVGA slow graphics

[ferdek]

I confirm the issue reported by the OP. Here's my take on this.

Host: MacOS 10.14.4
GPU: AMD Radeon Pro 560
VBox version: 6.0.6

Guest No1:
VoidLinux x86_64 with GLIBC library, GAs installed from ISO shipped with installed VBox version. No "Desktop Environment", just clean X11+i3WM, enough to "startx", open up terminal and/or glxgears.

Guest No2:
Ubuntu 19 LiveCd

Issue: No matter which Graphics Adapter I choose in machine settings, running "glxgears" reports 150-600 FPS (depending on adapter and resolution). From the perspective of Guest machine, everything is fine.

However, on the host, the rendered graphics has at most 15FPS, keyboard and mouse events are passed to the guest with HUGE delays (10-15s), and even the VirtualBox host's window slows down to the point that I cannot open up the menu. Yes, the top menu with the Apple symbol lags heavily for the VBox app when 3d graphics is rendered; everything's fine for other apps at the same time.

Please find attached VBox.log for VoidLinux and VboxSVGA graphics adapter.

I've found multiple forum posts that might be related to the same issue, but they were all blamed on the users for wrong configuration without any real investigation.

[ferdek]

Also mod/op - please re-assign correct "Guest" and "Host" tags. Host is MacOS, Guests are Linux.

[Kevin L Mitchell]

For clarity, I'm seeing the issue with VMSVGA, rather than VboxSVGA, but I suspect the root cause is probably the same.

[Kevin L Mitchell]

I tried installing 6.0.8 to see if it resolved the issue. However, it wouldn't install on my Mac--see #18657.

[boxer01]

Any changes because of the latest corrections in the code?

[Michael Thayer]

So to be clear, this affects

• macOS host.
• Linux guests.
• Both VBoxSVGA and VMSVGA.

Does it also happen without scaling?

[Michael Thayer]

Does Cinnamon report software rendering for both graphics devices?

[Michael Thayer]

And note that only VMSVGA is expected to be accelerated for recent Linux guests.

[Samuel H.]

I have a problem with the Graphics Controller VMSVGA with a Ubuntu guest. The login screen never appears.
3D Acceleration is enabled.
VBoxSVGA works fine and in Glxgear, I get about 780 FPS.
Using VBoxVGA, I found an other bug. I can move the window of the VM, but the screen does not follow, and in glxgear, I get about 60 FPS.

My Host: Mac OS 10.14.5
VirtualBox: 6.0.8
Guest: Ubuntu 18.04.2 LTS

I tested VMSVGA with a different Linux guest(MX Linux 18-3 64bit) with 3D Acceleration also enabled and everything worked fine.

[Kevin L Mitchell]

I have not yet had a chance to test with 6.0.8; I intend to do that at the earliest opportunity. Cinnamon is not reporting software rendering with VMSVGA, and glxinfo seems to be indicating an appropriate driver, and yet the performance is extremely dismal; #18529 may be related, as it concerns a redraw storm, and the Linux apps with the worst performance perform the most redraws. And for the record, I have tried both with and without scaling, with no clear difference.

I'll post an update as soon as I'm able to get updated to 6.0.8.

[Kevin L Mitchell]

OK, I have tested with 6.0.8. It has made 0 difference to the graphics performance. Some of the apps continue to have such dismal performance that I have to stop typing, for minutes at a time sometimes, to watch for the app to catch up...and then I have to go and edit out all the duplicated characters caused by dropped events. In short, I cannot detect any difference between 6.0.6 and 6.0.8.

[Kevin L Mitchell]

As another point of information, I just installed htop on my mac and began looking at it. Immediately after switching back from the running VM (so I could see the htop display), I found that VirtualBox was using 50% of my CPU to run my idle VM. While sitting on the mac side, it's showing ~30-35% CPU with excursions much higher (I saw 100+%). All this time, the VM was idle.

15 minute load average on the mac is 3.56. 15 minute load average on the guest is 0.69.

[ferdek]

Replying to Vek:

While sitting on the mac side, it's showing ~30-35% CPU with excursions much higher (I saw 100+%). All this time, the VM was idle.

15 minute load average on the mac is 3.56. 15 minute load average on the guest is 0.69.

This is consistent with what I've observed and described above, no matter which graphics driver you choose or which distribution you run. There is definitively something bad going on NOT with the hypervisor or video drivers, but in the way input events are handled by the VirtualBox and/or rendering of the video coming from the guest.

If anyone happens to know performance analysis tools available on Mac (something like perf for linux) and is willing to describe in short how to launch them properly for VirtualBox guest window profiling, I would be grateful.

[Kevin L Mitchell]

Can we get an update on the effort to investigate this bug? This is a major usability issue for VirtualBox and really should have some reasonable level of priority. Is there something we can do to help debug the issue? Is there a fix in a pre-release that we can help test?

[Michael Thayer]

While we do have sporadic reports of graphics problems on Mac hosts (might this be the same as #16436?) we don't have enough evidence of large numbers of people being affected to justify diverting time from other issues which affect more people. So for now, users investigating themselves is probably the way to go. One of our developers suggested the OpenGL profiling tool in XCode, but warned that it tends to produce so much information that it is hard to impossible to distil something useful out of it.

[Kevin L Mitchell]

I doubt this is the same as #16436, because this problem really only started affecting me somewhere around 5.2.20 or so, whereas that issue has been opened for 2 years. Prior to upgrading my guest to the 5.x series kernels, I had to downgrade VirtualBox to that 5.2.x-series version to get acceptable performance. Since my distribution went to the 5.x series kernels--forcing me to go with the 6.x series of VirtualBox--the performance has been abysmal. I've even tried rebuilding the guest, only to experience the same issue, so I'm not sure why ya'll seem to be having difficulty reproducing it--it's been extremely consistent for me. There have even been other reports of similar issues (e.g., #18529, which, although for a different guest type and a different acceleration type, correlates with my experience of the worst performing guest apps) which may point to the underlying problem, and yet has no developer comments at all.

I'm grateful, though, that you pointed out the developer suggestion of the OpenGL profiling tool in XCode. I wish it had been pointed out in this thread earlier, so that we could begin to look into utilizing it to acquire the data you need to debug the problem...

[Kevin L Mitchell]

For the record, I just tried 6.0.10; there is no change to the performance.

[Kevin L Mitchell]

I just tried turning off 3D acceleration on my VM. Although the interactive performance is unchanged, the load when idle on the mac side seems to be substantially reduced; I'm seeing CPU usage around 10% and 15 minute load averages around 1.5. It's almost as if 3D acceleration is only good for increasing the system load, and otherwise is having no effect.

[Kevin L Mitchell]

Upgraded to 6.0.12. No change in performance, with or without 3D acceleration. I also tried, based on something mentioned in another bug thread, turning off MagicPrefs, which I use to ensure I can trigger a middle click; quitting that app (which I did prior to starting VirtualBox after the upgrade) had no effect on the performance.

[Kevin L Mitchell]

Upgraded to 6.0.14. No change in performance, with or without 3D acceleration. I am still having key events dropped if 3D acceleration is turned on. This is most egregious with the shift key, as I'll literally end up with entire sentences converted to uppercase. As you can imagine, this is...not exactly ideal for a software developer when working in CamelCased languages. Apps also lag behind quite a bit while typing, as before.

As an additional piece of input: I have added a variant of gfxCardStatus, an app that monitors whether the mac is utilizing the integrated graphics card or the discrete one, a Radeon card in the case of my macbook. This variant of the app allows forcing the macbook to use one or the other card. I have found that, left to its own devices, running a VirtualBox VM with 3D acceleration enabled will cause the macbook to switch from integrated to the Radeon card; however, the performance is identical regardless of whether I force the use of integrated or Radeon.

I have to point out that 3D acceleration has not worked for me for _any_ release of 6.0, completely across the board. The last version of VirtualBox for which acceleration worked was 5.2.22. I'm sure you can understand my frustration at not having acceptable video performance for the past 9 months...

[Kevin L Mitchell]

Just upgraded to 6.1.0. No change in performance, with or without 3D acceleration; I still have dropped key events. Yes, it's actually slower to use the 3D acceleration option than it is to have the guest using software rendering.

[Kevin L Mitchell]

Just upgraded to 6.1.2. I still have the same problem: huge performance penalties and key events getting lost. Again, this is "button up" events going missing, causing keys to repeat or--the biggest culprit--the shift key to get stuck, causing several upper-case characters until I hit the shift key again.

The lost key events also happen without 3D acceleration, but are not anywhere near as prevalent as when 3D acceleration is enabled.

For the record, I've been complaining about problems with 3D acceleration for a year, starting in #18378. The last comment from someone other than me on this bug report is from 6 months ago. What can I do to get someone to help me resolve this issue?

[dcohen]

I have this same problem. Just attached "Ubuntu 16-2020-02-14-19-01-03.log". Virtualbox 6.1 is unusable because its GUI is too slow when I used any other 3D accel than VboxVGA, which is deprecated on 6.1.

[Kevin L Mitchell]

Just upgraded to 6.1.4. Still have the same problem. It is actually faster to use software rendering than it is to try to enable 3D acceleration!

[Kevin L Mitchell]

I'm still encountering the same problem with 6.1.6. For reference, I just tried to type the following text into a Slack window running in a Fedora VM with a partially transparent terminal window overlayed, using the Cinnamon desktop: "This is a test to see if we have missing keystrokes. I'm seeing exactly the same symptoms as before, so yes, the problem is still present." This is what actually appeared in Slack: "This is a test to see if we have missing keystrokes. ng exactly the same symptoms as before, so yes, the problem is still present." The keystrokes slowly appeared one by one, with about a half-second between them, after I finished actually typing; and, as you can see, several keystrokes after the "Shift" to get the "I" (including the "I" itself) were lost. I know this is lack of performance is not coming from the guest, because turning off 3D acceleration in the VirtualBox settings does seem to largely correct the missing keystrokes.

[ashetos]

I've got the same issue and have figured out some patterns in the behaviour. This problem is true for both Linux and Windows 10 hosts. It's always when using hardware acceleration with VMSVGA. It doesn't matter what linux guest is using the VMSVGA device, the problem is the same. Same applies for Virtualbox versions 6.1 and 6.0.

All the measurements I'm going to talk about are with Windows 10 hosts and Ubuntu 18.04 guests. I have 2 different host machines:

1. Intel Core i5 2500 CPU - AMD Radeon R9 280 GPU - 2560x1440 monitor - Virtualbox 6.1
2. Intel Core i7 4790 CPU - AMD Radeon RX 550 CPU - 3840x2160 monitor - Virtualbox 6.0

Here are some very reproducible observations:

1. The framerate is always dependent to the number of pixels in the guest VM resolution. Im machine A, setting the VM resolution to 1280x800 gives ~60fps in glxgears. Setting it to 2560x1600 gives ~18fps.
2. The GPU utilization in Windows task manager is very high, over 95% for machine A and over 60% for machine B. This also depends on the VM resolution but in a less linear way.
3. Setting full screen VM windows has pretty bad performance with those 2 monitors, machine A gives ~20fps and machine B gives ~80fps. Machine A in particular is unusable and can perform better with software rendering.
4. Interesting experiment with machine A.
   1. Set guest VM resolution to 1920x1200.
   2. Observe glxgears hit ~30fps.
   3. Swap the monitor cable from the discrete GPU to the integrated Intel HD 2000 graphics GPU.
   4. Without rebooting the host, observe that the active GPU driver has switched.
   5. Repeat the experiment, observe glxgears hit ~80fps!

It's clear that one of the reasons for bad performance is inefficient use of the host GPU driver. AMD Radeon R9 280 should be at least 10 times more powerful than Intel HD 2000.

Moreover, the correlation of fps to guest VM resolution shouldn't be so direct.

This is a real problem and I hope somebody gets to take a look at it.

[aim]

Do you need some logs for

Host: MacBook Pro (Retina, 13-inch, Early 2015) El Capitan 10.11.6 (15G22010) 2guests: archlinux 32bit and 64bit

?

[Kevin L Mitchell]

I honestly don't think anyone's paying any attention to this bug report. It's been open for a year and a half with no sign of interest from the developers and no sign of improvement (and it's been a problem for much longer than that!). I'm not even bothering with checking to see if the issue continues in 6.1.14, although I'm now seeing the same keyboard buffering issue without any acceleration that I was seeing before only with 3D acceleration. I've looked around at other virtualization software, but I've been told that they all have similar terrible acceleration performance, so I've stopped bothering.

It's really a shame; if that assertion about acceleration performance in other virtualization software is true, VBox could really differentiate themselves in the marketplace by looking into and addressing this performance problem, but instead they just seem to be ignoring this bug report about it. I wish I knew something about graphics acceleration and Virtualbox, and that I had the time to look into it myself, but unfortunately, I have none of that :( All I know is that there is a problem, and that it's a serious one...

[adamf]

This issue has been going on for all 6.x releases. vmsvga is still unuseable in VB 6.1.36.