Results 1 to 10 of 12

Thread: VMware Goes For Mainline Inclusion Of Its DRM

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,638

    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
    784

    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 07: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
    2,145

    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?

Posting Permissions

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