Mesa 22.1 Released With Many Vulkan Improvements, Kopper For Zink, Imagination Driver

[phoronix]

Phoronix: Mesa 22.1 Released With Many Vulkan Improvements, Kopper For Zink, Imagination Driver

Mesa 22.1 is out today as the newest, quarterly feature update to the open-source OpenGL/Vulkan graphics driver stack that also supports video acceleration and other GPU features on the Linux desktop...

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.1-Released

[polarathene]

I was given the impression that 22.1 would address an issue that'd fix/improve performance with virgl, but I must have misunderstood.

I had tested 22.2-devel(git) recently and while Zink finally worked without crashing for glmark2 and unigine-heaven on my nvidia 1070 (performance was not great vs non-free OpenGL though.. but 2-5x better than virgl guests), it did not seem to make any difference with glmark2 and unigine-heaven VMs using virgl.

---

SDL and GTK displays for QEMU worked the best, but roughly had similar Unigine Heaven (extreme preset) scores when compared to EGL Headless display option (paired with VNC or SPICE), but glmark2 (including glmark2-wayland, I tried each X11 and Wayland host/guest combination) was always poor. That was only with nvidia GPU with virgl however, the intel iGPU performance was much better IIRC.

I'm guessing it's because nvidia doesn't have proper DMA BUF support yet maybe...? (they have a roughly compatible alternative AFAIK) Or something else between Mesa and their proprietary drivers? Oddly while my virgl VM guests only managed 10% Unigine Heaven score vs host native score, I had reports from a 3080 owner that they were getting 60% vs native for the same benchmark. Is that due to some hardware or driver differences?

The iGPU isn't very powerful (Skylake i5-6500) but was managing around 5-7FPS which was about half the performance of the 1070 at Unigine Heaven in the VM guests... it performed similarly on host. I hadn't tried a less demanding preset to see if there was a larger overhead for Intel mesa compared to nvidia non-free, glmark2 had a more noticeable difference IIRC.

I attempted to run QEMU with Zink, but this did not seem like it was working. The nvidia benchmark scores remained the same, maybe if I tried using the Zink ENV via login shell profile instead of only for the QEMU command it might work? If anyone knows how to properly get virgl to go through Zink on the host instead that'd be great. I'm curious if that would work better. I've heard AMD GPUs have much better virgl performance.

Eventually QEMU will get blob resources support merged and we can use Venus (with Zink routing OpenGL in the guests?). Meanwhile VMware is providing 60% vs native 3D accel on Heaven and for glmark2 the scores are double SDL/GTK, or 20x what EGL Headless (Spice) manages.

I also booted the host with Wayland and both iGPU and dGPU active, if running glmark2 from the display not connected to the primary GPU that would be used, it resulted in similar low glmark2 scores that I saw in the VM virgl EGL Headless guests (llvmpipe actually scores much better instead). I'm not sure if that's due to CPU copies, but assume this is the case, it may not be an issue when both drivers are mesa based with DMA-BUF support?

---

On the plus side, at least with Fedora 36 and mesa 22.2-devel, I was able to actually use virglrender-devel with nvidia. The current release was April 2021, but trying to use the latest git build from AUR with mesa 22.0 was resulting in no guest viewport contents (black display). I assume it'll work with mesa 22.1 too, but the Fedora 36 host + guest testing didn't show any improvements at least with nvidia + virgl, so a new release of virglrenderer doesn't matter so much in my case until I can test with AMD

[tuxd3v]

polarathene
you have being in a mission,
Good work, thanks for the reporting

[rene]

I was given the impression that 22.1 would address an issue that'd fix/improve performance with virgl, but I must have misunderstood.

I had tested 22.2-devel(git) recently and while Zink finally worked without crashing for glmark2 and unigine-heaven on my nvidia 1070 (performance was not great vs non-free OpenGL though.. but 2-5x better than virgl guests), it did not seem to make any difference with glmark2 and unigine-heaven VMs using virgl.

---

SDL and GTK displays for QEMU worked the best, but roughly had similar Unigine Heaven (extreme preset) scores when compared to EGL Headless display option (paired with VNC or SPICE), but glmark2 (including glmark2-wayland, I tried each X11 and Wayland host/guest combination) was always poor. That was only with nvidia GPU with virgl however, the intel iGPU performance was much better IIRC.

I'm guessing it's because nvidia doesn't have proper DMA BUF support yet maybe...? (they have a roughly compatible alternative AFAIK) Or something else between Mesa and their proprietary drivers? Oddly while my virgl VM guests only managed 10% Unigine Heaven score vs host native score, I had reports from a 3080 owner that they were getting 60% vs native for the same benchmark. Is that due to some hardware or driver differences?

The iGPU isn't very powerful (Skylake i5-6500) but was managing around 5-7FPS which was about half the performance of the 1070 at Unigine Heaven in the VM guests... it performed similarly on host. I hadn't tried a less demanding preset to see if there was a larger overhead for Intel mesa compared to nvidia non-free, glmark2 had a more noticeable difference IIRC.

I attempted to run QEMU with Zink, but this did not seem like it was working. The nvidia benchmark scores remained the same, maybe if I tried using the Zink ENV via login shell profile instead of only for the QEMU command it might work? If anyone knows how to properly get virgl to go through Zink on the host instead that'd be great. I'm curious if that would work better. I've heard AMD GPUs have much better virgl performance.

Eventually QEMU will get blob resources support merged and we can use Venus (with Zink routing OpenGL in the guests?). Meanwhile VMware is providing 60% vs native 3D accel on Heaven and for glmark2 the scores are double SDL/GTK, or 20x what EGL Headless (Spice) manages.

I also booted the host with Wayland and both iGPU and dGPU active, if running glmark2 from the display not connected to the primary GPU that would be used, it resulted in similar low glmark2 scores that I saw in the VM virgl EGL Headless guests (llvmpipe actually scores much better instead). I'm not sure if that's due to CPU copies, but assume this is the case, it may not be an issue when both drivers are mesa based with DMA-BUF support?

---

On the plus side, at least with Fedora 36 and mesa 22.2-devel, I was able to actually use virglrender-devel with nvidia. The current release was April 2021, but trying to use the latest git build from AUR with mesa 22.0 was resulting in no guest viewport contents (black display). I assume it'll work with mesa 22.1 too, but the Fedora 36 host + guest testing didn't show any improvements at least with nvidia + virgl, so a new release of virglrenderer doesn't matter so much in my case until I can test with AMD

yeah, I recently also tested Qemu w/ VirGL and things where not yet running as smoothly as I would have hoped :-/ https://www.youtube.com/watch?v=6VqsATmqgso

[polarathene]

I recently also tested Qemu w/ VirGL and things where not yet running as smoothly as I would have hoped :-/

Looks like you had a much worse time! I only recall having problems with Fedora 36 GNOME Wayland, mouse position was offset weirdly in the GTK display, but SDL display was fine as long as I didn't resize the window. I can't recall if this was an issue on Arch KDE Wayland. Other than that, helps to have latest packages (especially mesa) in guest and host.

Regarding glxgears at the end, I recall reading about a regression introduced in mesa 21.3 that was resolved for 22.1 that just got released, so you probably experienced that. glxgears is useful to quickly test basic OpenGL is working, but not performance.

qemu-system-x86_64 \
 -machine pc-q35,usb=off,vmport=off,dump-guest-core=off \
 -accel kvm \
 -cpu host -smp 4 \
 -m 4G \
 -device virtio-tablet-pci \
 -drive if=pflash,format=raw,readonly=on,file=/vm/test/ovmf/OVMF_CODE.fd \
 -drive if=pflash,format=raw,file=/vm/test/ovmf/OVMF_VARS.fd \
 -drive if=virtio,format=qcow2,file=/vm/test/disk/os-disk.qcow2 \
 -drive id=boot-disk,if=none,format=qcow2,file=/vm/test/disk/boot.qcow2 \
 -device virtio-blk-pci,drive=boot-disk,bootindex=1 \
 -boot strict=on \
  -vga none -device virtio-gpu-gl-pci -display sdl,gl=on

This is what I've been testing with, or slight variations of. I'm not sure if UEFI helps, but it probably makes a bit of a difference? The 1st read-only ovmf file is usually the one from the package install since it's not written to and will get updates that way. I just wanted to have a copy while I experimented and learned the QEMU CLI config.

The separate boot disk is a vfat partition with boot flag and I've copied over rEFInd to that as a convenient way to boot various disks, it's not important and could be ignored. I have shared it show alternative syntax for providing a bootindex with strict boot. That prevents an issue with UEFI boots when the config changes and rewrites the boot order to prefer fallback EFI shell over your bootable disks.

I use a virtio tablet instead of the USB one and that should take priority over the default PS/2 mouse, while the PS/2 keyboard is used IIRC. I generally didn't have any input issues, except when the window viewport wasn't 1:1 pixel represenation (scaled zoomed in/out view) or when I tried multi-monitor and had two windows.

Last line removes the default VGA device which is required for `virtio-gpu-gl-pci` to work, otherwise there is `virtio-vga-gl` like you used but on my system did not seem to like working with X11 host with SDL display unless I also used `-vga none` and something else that `-nodefaults` removed to make it work for `gl=on`, as `gl=es` would work but not be ideal.. On Wayland I think it was less sensitive to whatever made it unhappy, and GTK display worked on Wayland IIRC, whereas on X11 it would just be black and not display anything. On Fedora 36 with mesa 22.2-devel + virglrenderer-devel, I recall less issues here, and GTK display worked on X11 host.

You can also use Spice display (nvidia requires egl-headless as well to work with it) if you're having issues with the SDL or GTK displays. egl-headless can be worse performance but it's not clear exactly why, perhaps due to extra copies moving around or something? If you only have one GPU then this should work, otherwise adjust the rendernode to the one matching your preferred GPU (or for non-nvidia GPU just try omitting the display portion):

-spice unix=on,addr=/tmp/spice.sock,disable-ticketing=on -display egl-headless,rendernode=/dev/dri/renderD128

Then connect over `remote-viewer` app to `spice+unix:///tmp/spice.sock`. Extra features of Spice need additional configuration to work, virt-manager sets that up with libvirt by default for reference.

For my testing setup, I use Ventoy with the vtoyboot feature which lets you turn a virtual VM disk into a bootable OS for the host. I did this for Fedora 36, preparing my guest VM, adding a copy to my external USB disk (Samsung T7) to boot from and then installing nvidia drivers and QEMU + virglrenderer. The nvidia drivers install broke the grub config (on the virtual disk I was booting) but that was easy enough to fix by referencing the earlier virtual disk used for the guest to see what it deleted/changed.

I find that easier than messing around on my main OS install, especially when I wanted to try latest mesa instead of waiting and it was convenient to do so via Fedora

[rene]

Updated: https://www.youtube.com/watch?v=F-oceawPCrI

[arun54321]

Updated: https://www.youtube.com/watch?v=F-oceawPCrI

Is it some sort of youtube channel advertisement?

[rene]

Is it some sort of youtube channel advertisement?

behind the scenes open source / Linux distribution development, ...