Zink OpenGL-On-Vulkan Now Correctly Rendering... Glxgears

[baryluk]

I have a feeling this is going to be really necessary when virglrenderer vulkan rolls out. I can't wait for qemu support, guess I have to figure out crosvm, and compile mesa, oh well.

but i think virgl vulkan to zink, will be faster than just regular virgl

One of the big issues with virgl OpenGL is that all OpenGL apps on the virtualized guest, do share single OpenGL context on the host and single queue between the two. This causes a lot of stutter when one more than 1 OpenGL is running on the guest. For example, running Unigine Heaven I get about 95 fps, but if I also run glxgears (with vsync 60 Hz), the Unigine Heaven performance drops A LOT, to about 45 fps, and there is visible stutter. virgl vulkan will solve this problem, by using multiple queues and logical devices, which are easily supported by Vulkan API and drivers, even from a single userspace process (like qemu). The zink itself does of course isn't 100% performance of the native OpenGL drivers (like radeonsi), but it is pretty close. In fact in some benchmarks and tests, for example supertuxkart, zink+radv gets 99-102% of radeonsi, which is amazing). In most others, the 65% is average I see across many benchmarks and titles (usually 55%-75%, with very few benchmarks where it gets more or less than that).

[Quackdoc]

One of the big issues with virgl OpenGL is that all OpenGL apps on the virtualized guest, do share single OpenGL context on the host and single queue between the two. This causes a lot of stutter when one more than 1 OpenGL is running on the guest. For example, running Unigine Heaven I get about 95 fps, but if I also run glxgears (with vsync 60 Hz), the Unigine Heaven performance drops A LOT, to about 45 fps, and there is visible stutter. virgl vulkan will solve this problem, by using multiple queues and logical devices, which are easily supported by Vulkan API and drivers, even from a single userspace process (like qemu). The zink itself does of course isn't 100% performance of the native OpenGL drivers (like radeonsi), but it is pretty close. In fact in some benchmarks and tests, for example supertuxkart, zink+radv gets 99-102% of radeonsi, which is amazing). In most others, the 65% is average I see across many benchmarks and titles (usually 55%-75%, with very few benchmarks where it gets more or less than that).

This is off topic, but for me one of the big things that would be the final big game changer, would be vulkan video. imagine having accelerated video playback in your virtual machine.

for the longest time I've wanted a Linux phone, that would run Android in a VM. with respectable performance. And Vulkan video is pretty much the last big thing that would be needed for that.

of course assuming that the android guest could use zink. virtio can handle literally every else. then you could swap between a linux environment and an android one. with very little preformance overhead.

[baryluk]

This is off topic, but for me one of the big things that would be the final big game changer, would be vulkan video. imagine having accelerated video playback in your virtual machine.

for the longest time I've wanted a Linux phone, that would run Android in a VM. with respectable performance. And Vulkan video is pretty much the last big thing that would be needed for that.

of course assuming that the android guest could use zink. virtio can handle literally every else. then you could swap between a linux environment and an android one. with very little preformance overhead.

So, Khronos just released h264 and h265 extensions for Vulkan for decoding done mostly by AMD, and finialized by Nvidia and Intel's help, and encoding and other formats are coming soon. Nvidia already have beta drivers supporting this. It should be relatively easy to make it work in virgl / venus, and write user space libraries (like vaapi / vdpau), that use this new vulkan api to do decoding. The future is bright here.

[ms178]

So, Khronos just released h264 and h265 extensions for Vulkan for decoding done mostly by AMD, and finialized by Nvidia and Intel's help, and encoding and other formats are coming soon. Nvidia already have beta drivers supporting this. It should be relatively easy to make it work in virgl / venus, and write user space libraries (like vaapi / vdpau), that use this new vulkan api to do decoding. The future is bright here.

I hoped this future would be here already as these features were meant to be ready by Q1/2020.

[timofonic]

If I understand you correctly, you are suggesting that there should be a "demo" for vulkan included in mesa-demos (or whatever the name of the package is)? If that is the case, I agree.
The issue is that vulkan is still optional, however, what may be smart (I don't know?) is to build a tree or for package maintainers to make group "mesa3d" for example (or something like that) that would include all implementations (GL, VK, CL etc.) while allowing separate installation as it is the case now. Just trowing this out there, maybe it's a good idea, maybe terrible.

In that case, for compatibility purposes I guess mesa3d-demos would be a name that would include all demos for example. Or simply include it in mesa-demos (at the risk of having non-functional demo in the group).

Yes, that's what I meant.

What's optional? That's relative. They can modularize the code.

The sooner they support Vulkan as a first class citizen, the better for everyone.

One of the big issues with virgl OpenGL is that all OpenGL apps on the virtualized guest, do share single OpenGL context on the host and single queue between the two. This causes a lot of stutter when one more than 1 OpenGL is running on the guest. For example, running Unigine Heaven I get about 95 fps, but if I also run glxgears (with vsync 60 Hz), the Unigine Heaven performance drops A LOT, to about 45 fps, and there is visible stutter. virgl vulkan will solve this problem, by using multiple queues and logical devices, which are easily supported by Vulkan API and drivers, even from a single userspace process (like qemu). The zink itself does of course isn't 100% performance of the native OpenGL drivers (like radeonsi), but it is pretty close. In fact in some benchmarks and tests, for example supertuxkart, zink+radv gets 99-102% of radeonsi, which is amazing). In most others, the 65% is average I see across many benchmarks and titles (usually 55%-75%, with very few benchmarks where it gets more or less than that).

I stopped trust VirGL developers, really. That should be done for everyone. Also, it would be nice if using Wine/DXVK as a basis for Microsoft Windows 2D and 3D support.

I see half baked efforts. I understand it may be difficult to achieve, but VMWare did something similar.

[kpedersen]

qemu supports more than one BIOS image. Turns out that bug you pointed to is in fact replication how real hardware with a Seabios behaves as well. So a failure with qemu and seabios described in that bug is qemu correctly emulating real hardware.

Quite possibly. However, I believe there might be something more to it because every BIOS I have tried in Qemu exhibits the same behaviour. And Seabios on i.e Bochs doesn't.

There was a patch for (open-source) DJGPP / CSDPMI programs here (I integrated it into Vim (incl pmode/dj if you remember that!) on that same thread).

https://www.vogons.org/viewtopic.php?p=938609

Since there has been a patch for Seabios that fixes it but only on a specific version of Qemu.

So in short, something isn't quite right (perhaps in both projects) and DOS unfortunately isn't quite an attractive platform for the kind of technical developer required.

[oiaohm]

So in short, something isn't quite right (perhaps in both projects) and DOS unfortunately isn't quite an attractive platform for the kind of technical developer required.

Its more of a mess. Seabios on real hardware will do it and need the patch so djgpp will work. Then you have real hardware keyboard controllers that are not djgpp compatible either.

Bochs and QEMU are emulating different generations of hardware in the keyboard controller. Welcome to hell. Qemu is correctly replicating how some real server x86 hardware behaves and bochs is correct emulating how some other hardware behaves.

1) Seabios bug on particular keyboard controllers is problem one.
2) Particular modern keyboard controllers in real modern chipsets also behave how qemu does in the new version. So they fixed a bug in emulation to match modern hardware now the it breaks again.
3) Boch has a keyboard controller that behaves like a keyboard controller from when dos was dominate so is the legacy design.

The fact that qemu behavour is right for particular hardware so it correct emulation of that hardware that makes the fix tricker.

This is a case there was a bug in Seabios, There is a issue in modern hardware keyboard controllers vs legacy hardware keyboard controllers that show self with old dos programs. The modern version of keyboard controller does result in less emulation overhead running Linux,freebsd and windows in qemu.

Basically you have a cursed problem where everyone on one hand is right yet its wrong at the same time.

[kpedersen]

Basically you have a cursed problem where everyone on one hand is right yet its wrong at the same time.

Hmm, I see. I did suspect as much.

In terms of digital preservation, QEMU seems perfect on the surface but its main interests really do lay in chasing the most modern platforms (and KVM mostly).
Perhaps added flexibility of specifying the exact hardware keyboard controller could be a solution but it is adding more complexity.

[Quackdoc]

I hoped this future would be here already as these features were meant to be ready by Q1/2020.

Fingers crossed. I have been using android x86 in a qemu VM for a little while now, I am too impatient for qemu to pick up support for the vulkan patch. Hopefully it is soon.

[Clive McCarthy]

I'm an old guy. I have zero interest in games. I'm an artist and I have software (about 400k lines of C) for my artwork. I use OpenGL but not in complex ways beyond a couple of shaders. Nobody would describe OpenGL as elegant, I think.

I fear that OpenGL is somehow threatened by Vulkan. I bought a Vulkan book and instantly got lost in it's object oriented nonsense. If it is that hard to get GLXgears working it doesn't speak well of Vulkan as a language.

What I mean is that GLXgears doesn't use much of OpenGL so translating all of OpenGL calls to Vulkan is going to be very difficult.