Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: VMware Goes For Mainline Inclusion Of Its DRM

  1. #1
    Join Date
    Jan 2007
    Posts
    13,430

    Default 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...

    http://www.phoronix.com/vr.php?view=Nzc4Ng

  2. #2
    Join Date
    May 2008
    Posts
    598

    Default

    Can some of this code be used for the Radeon Gallium code?

  3. #3
    Join Date
    Nov 2008
    Posts
    755

    Default

    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; 12-10-2009 at 06:38 AM.

  4. #4
    Join Date
    May 2008
    Posts
    598

    Default

    Quote 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?

    Quote 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

  5. #5
    Join Date
    Oct 2009
    Posts
    1,987

    Default

    Quote 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.

  6. #6
    Join Date
    May 2008
    Posts
    598

    Default

    Quote 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.

    Quote 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?

  7. #7
    Join Date
    Nov 2008
    Posts
    755

    Default

    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):

    http://www.phoronix.com/scan.php?pag...item&px=Nzc2OA

    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.

  8. #8
    Join Date
    Sep 2006
    Posts
    714

    Default

    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; 12-10-2009 at 10:49 AM.

  9. #9
    Join Date
    May 2008
    Posts
    598

    Default

    Quote 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):

    http://www.phoronix.com/scan.php?pag...item&px=Nzc2OA

    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.

  10. #10
    Join Date
    May 2008
    Posts
    598

    Default

    Quote 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?

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •