Announcement

Collapse
No announcement yet.

VMware Goes For Mainline Inclusion Of Its DRM

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

  • VMware Goes For Mainline Inclusion Of Its DRM

    Phoronix: VMware Goes For Mainline Inclusion Of Its DRM

    VMware is preparing to propose that its "vmwgfx" DRM kernel driver be pushed into the mainline DRM tree and in turn will then be pulled into the mainline Linux kernel -- as soon as the Linux 2.6.33 kernel. VMware's Jakob Bornecrantz (formerly of Tungsten Graphics) is calling for comments on the two patches that introduce the vmwgfx C header file and then the Direct Rendering Manager code itself...

    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
    Can some of this code be used for the Radeon Gallium code?

    Comment


    • #3
      probably not. The state-trackers are shared between all gallium drivers (so radeon will benefit from G3D work done for vmware), but this is about DRM code which is hardware-specific.

      The abstraction layers is something like this:

      Application -> API/"State tracker" (opengl, opencl, dx, ...) -> G3D IR -> G3D driver -> hardware interface (on linux: kernel DRM)

      The last two are hardware specific. Most of the shareable code doesn't go into the kernel, anyway.
      Last edited by rohcQaH; 10 December 2009, 07:38 AM.

      Comment


      • #4
        Originally posted by rohcQaH View Post
        probably not. The state-trackers are shared between all gallium drivers (so radeon will benefit from G3D work done for vmware), but this is about DRM code which is hardware-specific.
        Does that mean, that VMware have chosen a favourite hardware vendor which they only will support?

        Originally posted by rohcQaH View Post
        The abstraction layers is something like this:

        Application -> API/"State tracker" (opengl, opencl, dx, ...) -> G3D IR -> G3D driver -> hardware interface (on linux: kernel DRM)

        The last two are hardware specific. Most of the shareable code doesn't go into the kernel, anyway.
        Ok, thanks for clearing that out

        Comment


        • #5
          Originally posted by Louise View Post
          Does that mean, that VMware have chosen a favourite hardware vendor which they only will support?
          It means that vmware had to come up with specifications for a virtual display card that is to be used by the guest OS which can piggyback through to the HOST OS and use standard hardware acceleration functions regardless of what hardware the host is equipped with. The idea here is that if you have vmware installed on a host system that supports some form of accelerated graphics, that a LINUX GUEST will be able to MAKE USE of the host's graphics accelerator with the objective that major linux distros will support vmware virtual hardware *out of the box* (i.e., not making any major compromises or placing a burden on the distros to support this).

          Though quite honestly, I wouldn't touch vmware with a 10 foot pole. They used to be the only game in town, but with all the qemu based alternatives (i.e. virtualbox), there is really no reason to stick with a closed source (despite a few open source components) system for virtualization.

          Comment


          • #6
            Originally posted by droidhacker View Post
            It means that vmware had to come up with specifications for a virtual display card that is to be used by the guest OS which can piggyback through to the HOST OS and use standard hardware acceleration functions regardless of what hardware the host is equipped with. The idea here is that if you have vmware installed on a host system that supports some form of accelerated graphics, that a LINUX GUEST will be able to MAKE USE of the host's graphics accelerator with the objective that major linux distros will support vmware virtual hardware *out of the box* (i.e., not making any major compromises or placing a burden on the distros to support this).
            Ahhh. So it is a pseudo graphics card driver for the guest. Clever

            So regardsless of what the actual graphics card is on the host, it will just expose a pesudo graphics card to the guests.

            Originally posted by droidhacker View Post
            Though quite honestly, I wouldn't touch vmware with a 10 foot pole. They used to be the only game in town, but with all the qemu based alternatives (i.e. virtualbox), there is really no reason to stick with a closed source (despite a few open source components) system for virtualization.
            So let's say that Red Hat wanted to have the same functionality with KVM.

            Could they just use this VMware DRM?
            Would there be legal problems?
            Lack of API specification?
            Or is VMware's pseudo graphics card closed source?

            Comment


            • #7
              they can use the driver, but they'd have to emulate a virtual gfx card that's compatible to the virtual vmware SVGA adapter. qemu seems to offer a compatible card already, and the driver works (after slight modifications):

              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


              not sure about any further details. It will probably take more work to make the virtual GPU use the physical GPU instead of doing plain software-rendering.

              Comment


              • #8
                I've used the svga qemu configuration, which is suppose to be compatible with the Vmware one.

                I never really got it to work very well. With newer Linux guests it suppose to be working, but I tried it with Windows XP and had a few issues. It should offer a significant graphical boost for guests in KVM when it does work.

                This is probably one of those good reasons to prefer Vmware over Qemu-KVM for the time being. Hopefully the Qemu-KVM folks will be able to catch up.

                ----------------------

                On a side note.. for Linux guests in KVM I just setup them up to allow xdmcp logins.

                That way I can simply go to my normal desktop applet on my host system, select 'switch user', go to the GDM login screen, do remote login to the guest, and then use X over TCP. This combined with pulseaudio for network audio gives me indirect OpenGL acceleration, EXA stuff, and that sort of thing.

                It's a bit of a hassle to setup sometimes, but it works out pretty well and it's fast enough to play full screen movies most of the time. The network overhead can be a bit much, but as long as your using Virtio PV drivers for efficient virtual network then it should be 'ok'.

                This, of course, is on the private virtual network I have setup for my guests to use on my host system. XDMCP and any unencrypted X11 stuff is a security threat on a open network.

                If you want security then you can login through X over SSH, but you pay a penalty in the encryption overhead and increased latency.
                Last edited by drag; 10 December 2009, 11:49 AM.

                Comment


                • #9
                  Originally posted by rohcQaH View Post
                  they can use the driver, but they'd have to emulate a virtual gfx card that's compatible to the virtual vmware SVGA adapter. qemu seems to offer a compatible card already, and the driver works (after slight modifications):

                  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


                  not sure about any further details. It will probably take more work to make the virtual GPU use the physical GPU instead of doing plain software-rendering.
                  So that was that patch all about

                  It will be very interesting if Red Hat decides it is a valid business direction to go in.

                  Comment


                  • #10
                    Originally posted by drag View Post
                    This is probably one of those good reasons to prefer Vmware over Qemu-KVM for the time being. Hopefully the Qemu-KVM folks will be able to catch up.
                    VMware very likely have a customer already for it, so I suspect Red Hat only will follow up, if they can get a customer as well.

                    I think it was in the KVM blog where I was a video where a Red Hat engineer showed a example of cloud computing using RHEV. It was for an animation studio.

                    So maybe Pixar, Dreamworks, Blue Sky, etc is a Red Hat customer, that could be interested in this sort of thing?

                    Originally posted by drag View Post
                    That way I can simply go to my normal desktop applet on my host system, select 'switch user', go to the GDM login screen, do remote login to the guest, and then use X over TCP. This combined with pulseaudio for network audio gives me indirect OpenGL acceleration, EXA stuff, and that sort of thing.
                    How do you start X over SSH?

                    I have never got that "export DISPLAY" thing to work

                    Comment

                    Working...
                    X