Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • baryluk
    replied
    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.
    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.

    Leave a comment:


  • Quackdoc
    replied
    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).
    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.

    Leave a comment:


  • baryluk
    replied
    Originally posted by Quackdoc View Post
    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).

    Leave a comment:


  • leipero
    replied
    Originally posted by timofonic View Post
    glxgears...

    what about vkgears with shaders, tesselation, raytracing and all cool stuff?

    https://github.com/SaschaWillems/Vulkan
    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).

    Leave a comment:


  • onlyLinuxLuvUBack
    replied

    An interesting phoronix benchmark could be:

    zink running the raylib gl demos with maybe patches for fps counting, and then nvidia driver vs radeon ?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by kpedersen View Post
    To be fair, QEMU can't even properly emulate MS-DOS yet:

    Wine as a project is considerably more complex than MS-DOS emulation and much less funded.
    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.

    Wine own internal dos emulation is not that good. Wine project started external project called dosbox most of the time they have specailised in dos application compatibility then after while the default action for wine came use dosbox and only use wine own implementation if that did not work.

    A few years latter we are using 64 bit systems the v86 mode of the Linux kernel is gone so wine own internal dos emulation cannot be run for dos applications because v86 mode is a required feature so it works. So wine own dos emulation sitting their for win3.x and before applications so now when you run dos applications with wine is basically a proxy to dosbox and dosbox has picked up a few features to work better with wine.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by StarterX4 View Post
    Just like Wine being able to run many latest games, but some software from 2000's still don't work.
    To be fair, QEMU can't even properly emulate MS-DOS yet: https://bugs.launchpad.net/qemu/+bug/1574246

    Wine as a project is considerably more complex than MS-DOS emulation and much less funded.

    Leave a comment:


  • Quackdoc
    replied
    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

    Leave a comment:


  • Calinou
    replied
    Zink is now ready for the year of glxgears gaming.

    Leave a comment:


  • timofonic
    replied
    glxgears...

    what about vkgears with shaders, tesselation, raytracing and all cool stuff?

    Examples and demos for the new Vulkan API. Contribute to SaschaWillems/Vulkan development by creating an account on GitHub.
    Last edited by timofonic; 27 April 2021, 08:37 AM.

    Leave a comment:

Working...
X