virtualbox.org

BETA3 changelog: "Devices/graphics: enable support for VMSVGA graphics device emulation by default"
Why ?
It could improve compatibility with VMware or why is it needed ?

Because it has improved capabilities perhaps. The VMSVGA is the improved 3D support that was mentioned for quite some time now.

+1

AFAIK there would have to be improved drivers before the improvement was available to the guest. How is this new feature to be used?

The VMSVGA was there since 5.0.0, it simply wasn't enabled by default because it was "not optimal". No documentation, not a mention. The only place that you'd see it, and if you still have any 5.0|1|2.x hanging around, just try to modify any VM with:

• VBoxManage modifyvm <VM> --graphicscontroller none|vboxvga|vmsvga

There is no need for new drivers on the guest, if that's what you mean Don. You simply modify the VM either with the above command, or (new for b3) from the VM Settings » Display. In there, you'll see another new one, VBoxSVGA. I think it's a hybrid of the new and the old ones. I have no clue why 3 options are needed, but hey, the more the merrier.

I did a quick and dirty test with an Ubuntu 16.04 VM and "glxgears". With the VBoxVGA (old one), I was getting ~65fps. Simply shutting down the VM and switching to VMSVGA (new), I was getting ~430fps.

The "drawback" was my CPU with the VBoxVGA was at 3-4%, with the VMSVGA at 100%, but to be honest, glxgears *is* supposed to max out the CPU.

Shouldn't glxgears max out the GPU, not the CPU? Is the version of OpenGL presented in the guest any different?

>Shouldn't glxgears max out the GPU, not the CPU? Is the version of OpenGL presented in the guest any different?

3D graphics often maxes out both GPU and CPU (on 3D games).

====

So now we have 3 graphics cards:
-VBoxVGA
-VBoxSVGA
-VMSVGA

Why 3 ? Why do we need so much ?

- From tests performed so far with 6.0 Beta 3 and its Guest Additions

VBoxVGA - for guests which refuse to work with newer SVGA modes.
VMSVGA - for GNU/Linux guests to allow all features. VBoxSVGA works, but only with standard guest resolutions / limited resolutions, no auto resizing.
VBoxSVGA - for Windows guests (tried 7 and 10) to allow all features. VMSVGA works, but with standard guest resolutions, no auto resizing.

On the plus side, VMSVGA and VBoxSVGA fix, or circumvent NVIDIA display re-paint & flickering issues, so line below is no longer required (unless switching back & forth with VBoxVGA). VMSVGA also seems to fix the Linux Mint 19 Cinnamon DE display 'bloom' issue.

With the new modes, it seems full guest display re-paints are currently happening, which may explain higher CPU usage while testing glxgears? Especially seen with full screen applications, such as Linux version of Kodi, the UI is a bit slow, desktop mouse pointer isn't hidden, and kodi large pointer follows a few ms after the main pointer (rubber band effect). Another reason for suspecting this, glxgears gave higher scores while using lower guest window resolutions.

So far, unable to test Manjaro Cinnamon edition with the new modes, tried kernel 4.19 and 4.14 (GA reinstalled each time, just in case).
Also unable to test ReactOS with new modes, blue screens while trying to install 6.0 Beta 3 GA. Realise ReactOS is alpha, so will keep it on working 5.2.23 GA.

Above comments are not complaints, just observations.

auto resizing is a killer feature for me; so VboxVGA all the way I guess ?

Shalom Technologov,

As long as VMSVGA is used for Linux guests, and VBoxSVGA for Windows guests, everything seems to work as expected (including resizing). This may change for newer beta's/final release.
Edited my original post to help clarify.

The VBoxVGA will be in any case the one used for previously created VMs. Just like the "Legacy" in the Paravirtualization options. But for newer guests, I guess at some point they might follow the model that "Dave B" talks about; VMSVGA for Linux, VBoxSVGA for Win*.

Edit: Forget the "at some point", it does that already

Ah, thanks! Other than creating a ReactOS vm to test (which defaults to VBoxVGA), only experimented with previously created vm's.

Besides 'Null', wonder if it would help users if only two options appeared in VirtualBox UI, VBoxVGA and VBoxSVGA?

- Under the hood
VBoxSVGA = VMSVGA if General -> Basic -> Type = Linux (and others requiring this mode)
VBoxSVGA = VBoxSVGA if General -> Basic -> Type = Windows (plus others requiring this mode)

For power users, VMSVGA and VBoxSVGA would still be available for use from the command line.

Dave B wrote:Besides 'Null'

Something tells me that this 'Null' computer lingo, will be soon 'None' in human lingo...

Dave B wrote:if only two options appeared in VirtualBox UI, VBoxVGA and VBoxSVGA?

So, why skip a clearly valid VMSVGA that Linux users have heard. Two instead of three? What if I changed it manually from the command line? What would the GUI said then?

I don't think that such a complicated workaround simply to take one option out doesn't make sense. IMHO...

You raise a good point! Furthermore, if reducing entries, should have also simplified names, such as VGA + SVGA (don't read too hard into this!)

Fun aside. Just noticed vbox UI mini Preview issues, only while using VMSVGA, garbled display, double width preview even with one virtual monitor.
Anyone else seeing the same on GNU/Linux flavours?

- Hardware
NVIDIA GPU (driver 390.77)

- Software
VirtualBox 6.0.0 BETA3, Linux Mint 19 Cinnamon host, 19.1 guest (also tried 19 guest)

socratis wrote:Something tells me that this 'Null' computer lingo, will be soon 'None' in human lingo...

While realise the 6.0.0 Beta / Release Candidate Feedback phase is over and posts should be in the main section. Noticing the following made me smile remembering your above reply.

Dave B wrote:Noticing the following made me smile remembering your above reply.

You remembering that "Null Audio Driver" made me smile too!
That's been there for... ages actually! Time for a ticket...