Announcement

Collapse
No announcement yet.

Virglrenderer Sees Some New Micro-Optimizations

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

  • Virglrenderer Sees Some New Micro-Optimizations

    Phoronix: Virglrenderer Sees Some New Micro-Optimizations

    Virglrenderer that is part of the open-source Linux effort to provide accelerated OpenGL to guest virtual machines has been enjoying some new micro-optimizations...

    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
    Yeah.. upgrade from 0.82 to 0.91 resulted in a black screen in my arch machine.. thanks..

    Comment


    • #3
      I don't know if this exactly fits here, but I would love to see some sort of pass-through thing for Windows guests on Linux hosts, whatever the effective virtualization platform might be. I know this can be done, but to make it more performant. Here is my envisioned setup...

      I still need to use Windows for work, and to be honest use to as my main boot most of the time. But would be happy to use more Linux. It would be cool to have a minimalist Linux install with say some sort of tiling window manager, and then on one of the virtual desktops launch the Windows guest as full-screen. I know this can already be done, would just like to see more performant with some graphics pass-through stuff, etc.!

      Comment


      • #4
        Originally posted by ehansin View Post
        I don't know if this exactly fits here, but I would love to see some sort of pass-through thing for Windows guests on Linux hosts, whatever the effective virtualization platform might be. I know this can be done, but to make it more performant. Here is my envisioned setup...

        I still need to use Windows for work, and to be honest use to as my main boot most of the time. But would be happy to use more Linux. It would be cool to have a minimalist Linux install with say some sort of tiling window manager, and then on one of the virtual desktops launch the Windows guest as full-screen. I know this can already be done, would just like to see more performant with some graphics pass-through stuff, etc.!
        Virgl preforms way to bad to even attempt making wddm drivers for it, Vulkan stuff is in mesa-git and virglrenderer-git. and should be multitudes more preformant maybe even using zink.

        maybe then, pair that with dxvk on a systemwide basis, and Maybe a wddm driver might be viable then. indirectly related, VMware is opensourcing their D3D10/11 gallium state tracker for LLVMpipe. this by itself is not big news, but is a step in the right direction.

        Comment


        • #5
          Originally posted by Quackdoc View Post
          VMware is opensourcing their D3D10/11 gallium state tracker for LLVMpipe. this by itself is not big news, but is a step in the right direction.
          Speaking of, once the state tracker is merged, isn't it a matter of implementing functions in each gallium driver for it to be supported on GPUs? Given nine works on basically all gallium drivers, shouldn't it be "free"/near "free" for AMD/Intel, and possibly Zink?

          Comment


          • #6
            Originally posted by Snaipersky View Post

            Speaking of, once the state tracker is merged, isn't it a matter of implementing functions in each gallium driver for it to be supported on GPUs? Given nine works on basically all gallium drivers, shouldn't it be "free"/near "free" for AMD/Intel, and possibly Zink?
            I think it's missing WINE support, so in it's current state it's only useful on windows. Plus it's DX10 only, which is a pretty limited set of games. But it would be a good starting point for anyone wanting to bring that support to linux drivers.

            Comment


            • #7
              Originally posted by Snaipersky View Post

              Speaking of, once the state tracker is merged, isn't it a matter of implementing functions in each gallium driver for it to be supported on GPUs? Given nine works on basically all gallium drivers, shouldn't it be "free"/near "free" for AMD/Intel, and possibly Zink?
              I haven't read the driver code to any meaningful degree, so take this all with a grain of salt. also apologies for the mini essay.

              First and foremost this won't be useful for wine, at all. and most likely never will. this is a DX10 software rasterizer (Equivalent to Microsoft warp) written in llvmpipe and softpipe, (Im at this point not sure if it uses both, or if one can be an alternative to another). this this at most could be compared to a dx-> OGL library. But first and foremost, it is a software rasterizer for d3d10 for virtual machines. that is all it is. DXVK and wined3d will still be far more performant than this. and in 99% of the cases will be the one that should be used. this would only be used (For wine) in edge cases, where both preformance isn't important, and DXVK/wined3d does not work

              This doesn't even provide a paravirtualized gpu interface.

              HOWEVER. this is still an opensource WDDM compliant driver for d3d10. while this doesn't mean a lot for the linux side of things, this is a full blueprint on making a d3d10 driver for linux, that runs using opengl (I think anyways, I don't see any other reason to use llvmpipe but their could be some). and if the importance has already clicked, no need to read on. even if that isnt accurate, the next part still holds mostly true.

              A couple months ago work on a WDDM-DOD driver was re-started for virgl, this is a display only driver. this means in therory, a skilled dev, could port this WDDM-UMD driver from this to virtio-gpu and get acceleration. THIS DOESN'T MATTER. it would still be extremely slow usage. Best case scenario it would be a Dx10 -> ogl -> zink -> vulkan virtio-gpu

              I need to make this as clear as I can, this in no way means this is happening, no indication of interest from any dev has been shown, and it would still be a shit ton of work, so do not get your hopes up, BUT. this in theory could be ported to a vulkan interface, in which the new virtio-vulkan, and lavapipe could be used. and in which case we could see highly performant GPU paravirt for windows guests.

              First things, what does this standalone mean.
              Not too much. Software rendering should be a bit more preformant (Dpending on cpu) to quite a bit more.
              it could be more compatible (I dont think this is likely, but ive ever used microsoft warp)

              Now, that we know the mythical unicorn in the far off distance, Lets be more reasonable predictions

              1. Someone could implement paravirtualization driver as is, this would still be far more preformant than what we have. so this is good, this would probably be less performant than VMware's enterprise solution. but way more than what we have. this would still be way down the line.

              2. this could at some point down the line become a "reference" implementation for wine (maybe even for virtualized gpus)

              Comment


              • #8
                To clarify, since 2 people have immediately assumed I was referring to wine usage, I was referring to VM acceleration. I also haven't dug that deep, but if this is a gallium state tracker, then it is akin to the various opengl state trackers and nine (llvmpipe being a software driver makes it easier to be more correct when implementing a given gallium function, as I understand it). My understanding of Virgl/virtio-gpu is that commands from the paravirt driver are sent to the metal host to process, and the resultant state is returned to the paravirt driver. On Linux, we effectively only ever use the opengl state trackers in Virgl, but if a WDDM driver could function as the Linux paravirt driver does, then we should get a similar effect, but accelerating directx. There shouldn't ever be a need for opengl to enter there picture, as it should be DX->gallium commands->shm->gallium driver->kernel driver. Since llvmpipe is a gallium driver, if Iris, radeonsi and Zink can take llvmpipe's place, then we could actually get decent accelerated VMs for various applications

                Comment


                • #9
                  Originally posted by Snaipersky View Post
                  To clarify, since 2 people have immediately assumed I was referring to wine usage, I was referring to VM acceleration. I also haven't dug that deep, but if this is a gallium state tracker, then it is akin to the various opengl state trackers and nine (llvmpipe being a software driver makes it easier to be more correct when implementing a given gallium function, as I understand it). My understanding of Virgl/virtio-gpu is that commands from the paravirt driver are sent to the metal host to process, and the resultant state is returned to the paravirt driver. On Linux, we effectively only ever use the opengl state trackers in Virgl, but if a WDDM driver could function as the Linux paravirt driver does, then we should get a similar effect, but accelerating directx. There shouldn't ever be a need for opengl to enter there picture, as it should be DX->gallium commands->shm->gallium driver->kernel driver. Since llvmpipe is a gallium driver, if Iris, radeonsi and Zink can take llvmpipe's place, then we could actually get decent accelerated VMs for various applications
                  First of all, I had a massive brain crap and completely ignored gallium. dunno why I did, but I did. but in the end, it doesn't really change much. the issue is, virgl.

                  the short story, it wouldn't be useful. not to any meaningful degree. not for VM acceleration accept one path. zink. BUT, its certainly not a smoking gun. Venus on the otherhand should preform much better, but I certainly don't think it will be a free port. Note that Im betting the performance would be equivalent to OGL virgl. it could be higher... but I dunno. I have my doubts.

                  Virgl from my experience is about 30~ performance vs Venus (the virgl equivalent, I know its not virgl, but I keep doing it anyway lol ) which is about 80-95% supposedly. so it is a much better contender.

                  this would still only directly benefit software rasterizers and vmware-svga and virgl I think. im not sure if there are other gallium based drivers.

                  Comment


                  • #10
                    Originally posted by Quackdoc View Post

                    First of all, I had a massive brain crap and completely ignored gallium. dunno why I did, but I did. but in the end, it doesn't really change much. the issue is, virgl.

                    the short story, it wouldn't be useful. not to any meaningful degree. not for VM acceleration accept one path. zink. BUT, its certainly not a smoking gun. Venus on the otherhand should preform much better, but I certainly don't think it will be a free port. Note that Im betting the performance would be equivalent to OGL virgl. it could be higher... but I dunno. I have my doubts.

                    Virgl from my experience is about 30~ performance vs Venus (the virgl equivalent, I know its not virgl, but I keep doing it anyway lol ) which is about 80-95% supposedly. so it is a much better contender.

                    this would still only directly benefit software rasterizers and vmware-svga and virgl I think. im not sure if there are other gallium based drivers.
                    Venus? I'm not familiar, and Google isn't my friend.
                    ​​​​​​

                    Comment

                    Working...
                    X