Originally posted by Quackdoc
View Post
Zink OpenGL-On-Vulkan Now Correctly Rendering... Glxgears
Collapse
X
-
-
-
Originally posted by baryluk View Post
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).
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.
Comment
-
-
Originally posted by Quackdoc View Post
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.
Comment
-
-
Originally posted by baryluk View Post
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.
Comment
-
-
Originally posted by leipero View Post
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).
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.
Originally posted by baryluk View Post
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 see half baked efforts. I understand it may be difficult to achieve, but VMWare did something similar.Last edited by timofonic; 28 April 2021, 10:55 AM.
Comment
-
-
Originally posted by oiaohm View Post
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.
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).
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.
Comment
-
-
Originally posted by kpedersen View PostSo 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.
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.
Comment
-
-
Originally posted by oiaohm View PostBasically you have a cursed problem where everyone on one hand is right yet its wrong at the same time.
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.
Comment
-
-
Originally posted by ms178 View Post
I hoped this future would be here already as these features were meant to be ready by Q1/2020.
Comment
-
-
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.Last edited by Clive McCarthy; 28 April 2021, 11:22 PM.
Comment
-
Comment