Announcement

Collapse
No announcement yet.

VMware Prepares Linux Driver For Next-Gen Virtual GPU

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

  • #21
    Originally posted by MadeUpName View Post
    Don't be so sure. I upgraded the CPU in my server about a year ago and none of the VMs would boot as the existing Virtual CPUs weren't compatible with the new real CPU. Dropping the existing virtual CPUs and adding them back in got me going again but the new virtual CPUs had different instructions than the old ones. Agreed you have a better chance in a virtual environment. But it isn't guaranteed.
    Oh, certainly... but I'm not talking about that level of "drop in and go" compatibility. It's nice, but I accept that it's likely to only happen with something like DOSBox.

    Heck, I don't trust VMWare and VirtualBox-style VMs particularly because they tend to involve guest drivers that aren't guaranteed to retain compatibility for both old OSes and new versions of the VM host at the same time. They're not intended for keeping old stuff alive. They're intended to broaden the scope of things you can do within the "support window" paradigm that already applies to your native software.

    Comment


    • #22
      Originally posted by caligula View Post
      I've seen many cases where the VirtualBOX SVGA driver can't resize the window. In order to achieve best compatibility, their own vbox video is still recommended.
      No it isn't, and it hasn't been for years.

      You may have *a* case where one specific user or subset of users had some problem with the SVGA driver (it's certainly not free of them) and *you/they* recommended changing it, but to translate that to "is recommended" is highly dishonest, since that is absolutely NOT the position of the VBox developers, nor of the vast majority of users.

      Comment


      • #23
        Originally posted by MadeUpName View Post
        Don't be so sure. I upgraded the CPU in my server about a year ago and none of the VMs would boot as the existing Virtual CPUs weren't compatible with the new real CPU. Dropping the existing virtual CPUs and adding them back in got me going again but the new virtual CPUs had different instructions than the old ones. Agreed you have a better chance in a virtual environment. But it isn't guaranteed.
        Sorry, but it IS guaranteed, and this is blatantly a case of YOU screwing up and then trying to blame the software. Let me guess: Saved States.

        In short: If you'd shut down the VMs properly instead of effectively Hibernating them, you wouldn't have had any problems bringing the images up on a different machine. (That's half the POINT of virtualisation software, after all).

        Comment


        • #24
          Originally posted by S.Pam View Post

          Not at all. I run it over tcp. It's just a limit of virt-manager GUI, not libvirt or qemu.

          Here, running virt-view from a Windows client. https://paste.tnonline.net/files/UPU...-05_183523.png

          To add spice with OpenGL/VirGL support you have to replace the graphics section in the VM definition with the following code. Use virsh from a shell to do it.
          #virsh edit fedora34:
          Code:
          <graphics type='spice' autoport='yes' listen='192.168.0.1'>
          <listen type='address' address='192.168.0.1'/>
          <image compression='auto_glz'/>
          <streaming mode='filter'/>
          <clipboard copypaste='yes'/>
          <filetransfer enable='yes'/>
          </graphics>
          <graphics type='egl-headless'>
          <gl rendernode='/dev/dri/renderD128'/>
          </graphics>
          This brings both AUDIO and VIDEO to the Spice client
          O-M-G. Do you have the slightest idea how many times I've asked something like this in the past few years? Didn't know about egl-headless, thank you very much!
          ## VGA ##
          AMD: X1950XTX, HD3870, HD5870
          Intel: GMA45, HD3000 (Core i5 2500K)

          Comment


          • #25
            Originally posted by darkbasic View Post

            O-M-G. Do you have the slightest idea how many times I've asked something like this in the past few years? Didn't know about egl-headless, thank you very much!
            Credits should go to #gentoo user Jannik2099

            Comment


            • #26
              Originally posted by darkbasic View Post

              O-M-G. Do you have the slightest idea how many times I've asked something like this in the past few years? Didn't know about egl-headless, thank you very much!
              Why didn't you just read the libvirt documentation? if you have any questions like that, documentation should be your first go to

              Comment


              • #27
                Originally posted by Quackdoc View Post

                Why didn't you just read the libvirt documentation? if you have any questions like that, documentation should be your first go to
                Documentation says that spice over tcp is simply not supported, can you please point me to where it says that I should use egl-headless in order to get it working?
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #28
                  Originally posted by darkbasic View Post

                  Documentation says that spice over tcp is simply not supported, can you please point me to where it says that I should use egl-headless in order to get it working?




                  Spice may provide accelerated server-side rendering with OpenGL. You can enable or disable OpenGL support explicitly with the gl element, by setting the enable property. (QEMU only, since 1.3.3 ). Note that this only works locally, since this requires usage of UNIX sockets, i.e. using listen types 'socket' or 'none'. For accelerated OpenGL with remote support, consider pairing this element with type egl-headless (see below). However, this will deliver weaker performance compared to native Spice OpenGL support.

                  Comment


                  • #29
                    Originally posted by xxmitsu View Post
                    Hope VMware won't forget about opensourcing their D3D10/11 state tracker..

                    it is dead code as besides nouveau and svga no driver tries to handle it and there is simply now way to generate a TGSI with those anyway.

                    This change adds a gallium D3D10 state tracker that works as a WDDM UMD software driver, similar to Microsoft WARP, but using llvmpipe/softpipe. The final deliverable...


                    Comment


                    • #30
                      Originally posted by S.Pam View Post

                      Not at all. I run it over tcp. It's just a limit of virt-manager GUI, not libvirt or qemu.

                      Here, running virt-view from a Windows client. https://paste.tnonline.net/files/UPU...-05_183523.png

                      To add spice with OpenGL/VirGL support you have to replace the graphics section in the VM definition with the following code. Use virsh from a shell to do it.
                      #virsh edit fedora34:
                      Code:
                      <graphics type='spice' autoport='yes' listen='192.168.0.1'>
                      <listen type='address' address='192.168.0.1'/>
                      <image compression='auto_glz'/>
                      <streaming mode='filter'/>
                      <clipboard copypaste='yes'/>
                      <filetransfer enable='yes'/>
                      </graphics>
                      <graphics type='egl-headless'>
                      <gl rendernode='/dev/dri/renderD128'/>
                      </graphics>
                      This brings both AUDIO and VIDEO to the Spice client
                      I wonder if I can somehow get it working via ovirt....

                      - Gilboa
                      oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                      oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                      oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                      Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                      Comment

                      Working...
                      X