Announcement

Collapse
No announcement yet.

Mesa 23.2 Virgl Lands Support For OpenGL 4.6 Inside Virtual Machines

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

  • Mesa 23.2 Virgl Lands Support For OpenGL 4.6 Inside Virtual Machines

    Phoronix: Mesa 23.2 Virgl Lands Support For OpenGL 4.6 Inside Virtual Machines

    The Virgl driver within Mesa for allowing open-source OpenGL support within virtualized environments in conjunction with the Virglrenderer is now capable of exposing OpenGL 4.6...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I just realized this but: is there a Vulkan equivalent to VirGL? Because imagine the overhead of trying to play a DX12 game in a VM, where you have to go from your bare-metal Mesa driver to VirGL, which has to communicate to the VM's VirGL, which then depends on Zink for Vulkan support, and then you use DXVK to translate that into DX12.

    Of course, it'd be a lot easier to just do PCI passthrough if you really wanted to play games in a VM.

    Comment


    • #3
      Still hoping that someone will develop a VirGL Windows guest driver one day. That would finally allow QEMU to run 3D-accelerated Windows guests VMs. It was promised years ago, and I don't understand why Red Hat has never invested any serious money and resources into that.

      A macOS guest driver would also be amazing, but considering that no other virtualization solution has been able to offer Quartz Extreme acceleration in macOS guests yet, I'm definitely not holding my breath for that to become available any time soon.

      Comment


      • #4
        Originally posted by schmidtbag View Post
        I just realized this but: is there a Vulkan equivalent to VirGL?

        Yes, but I don't remember the name and I think it's still considered experimental.

        Originally posted by SteamPunker View Post
        Still hoping that someone will develop a VirGL Windows guest driver one day.
        Me too. Actually it would be more useful for the Vulkan equivalent.
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Will the performance be better than Venus+Zink?

          Comment


          • #6
            Originally posted by edxposed View Post
            Will the performance be better than Venus+Zink?
            Venus, that's how the Vulkan equivalent of VirGL was called. And yes, AFAIK Venus+Zink is supposed to be faster than VirGL.
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Originally posted by edxposed View Post
              Will the performance be better than Venus+Zink?
              Probably not, Venus (Vulkan equivalent of VirGL) has a much lower overhead than VirGL, so much that even pilling Zink on top provides heaps more performance.
              This may depend on the performance of the host GL driver of course and what the host can expose.

              In my tests in an arm 64 chrometab with mali graphics, using venus+zink offers me an higher opengl version (3.x vs 2.1) and 30% more performance. Most of this can be attributed to the crappy support of the official binary mali driver (oth the vulkan support is a bit better). In any case for Arm based fun I don't recommend mali graphics (panfrost is stuck in OGL 3.1 and PanVK appears to be dead and not even exposing Vulkan 1.0), Adreno offers you much better mesa support which also translates into better VM support. For AMD and Intel, anything current should be fine (except DG2 i guess).

              Comment


              • #8
                Originally posted by schmidtbag View Post
                I just realized this but: is there a Vulkan equivalent to VirGL? Because imagine the overhead of trying to play a DX12 game in a VM, where you have to go from your bare-metal Mesa driver to VirGL, which has to communicate to the VM's VirGL, which then depends on Zink for Vulkan support, and then you use DXVK to translate that into DX12.

                Of course, it'd be a lot easier to just do PCI passthrough if you really wanted to play games in a VM.
                there are actually a couple now, We have vulkan venus and then we have gfxstream, but as far as I know there is no mesa driver for gfxstream.​

                Originally posted by SteamPunker View Post
                Still hoping that someone will develop a VirGL Windows guest driver one day. That would finally allow QEMU to run 3D-accelerated Windows guests VMs. It was promised years ago, and I don't understand why Red Hat has never invested any serious money and resources into that.

                A macOS guest driver would also be amazing, but considering that no other virtualization solution has been able to offer Quartz Extreme acceleration in macOS guests yet, I'm definitely not holding my breath for that to become available any time soon.
                I would rather see venus + zink and then see d3d10umd (and an eventual d3d11umd) ported to zink as a solution. I presume that would be quite a bit faster.​

                Originally posted by fahrenheit View Post

                Probably not, Venus (Vulkan equivalent of VirGL) has a much lower overhead than VirGL, so much that even pilling Zink on top provides heaps more performance.
                This may depend on the performance of the host GL driver of course and what the host can expose.

                In my tests in an arm 64 chrometab with mali graphics, using venus+zink offers me an higher opengl version (3.x vs 2.1) and 30% more performance. Most of this can be attributed to the crappy support of the official binary mali driver (oth the vulkan support is a bit better). In any case for Arm based fun I don't recommend mali graphics (panfrost is stuck in OGL 3.1 and PanVK appears to be dead and not even exposing Vulkan 1.0), Adreno offers you much better mesa support which also translates into better VM support. For AMD and Intel, anything current should be fine (except DG2 i guess).
                Virgl preformance has a lot of overhead on desktop graphics too. it doesn't help that virgl is more or less an emulated graphics card while venus as far as I can tell is more or less vulkan command passthrough.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  I just realized this but: is there a Vulkan equivalent to VirGL? Because imagine the overhead of trying to play a DX12 game in a VM, where you have to go from your bare-metal Mesa driver to VirGL, which has to communicate to the VM's VirGL, which then depends on Zink for Vulkan support, and then you use DXVK to translate that into DX12.

                  Of course, it'd be a lot easier to just do PCI passthrough if you really wanted to play games in a VM.
                  I tought the same! What about VirVK someday? What about the same for Direct3D and such too?

                  Comment


                  • #10
                    Originally posted by SteamPunker View Post
                    Still hoping that someone will develop a VirGL Windows guest driver one day. That would finally allow QEMU to run 3D-accelerated Windows guests VMs. It was promised years ago, and I don't understand why Red Hat has never invested any serious money and resources into that.
                    ...
                    I've always been curious about this as well. I'm not sure how many people need a host Linux system with a Linux guest and accelerated video. However many people have to buy a secondary GPU to run Windows guests to play games or run other software requiring video acceleration. Perhaps I'm wrong, and it's unclear if Virgl could fill in for a passthrough GPU anyway, but it would be nice if users could at least give it a whirl. But the only thing I've ever seen is a very old, and limited, proof of concept Windows driver.

                    Comment

                    Working...
                    X