Announcement

Collapse
No announcement yet.

VMWGFX Enables DRM Render Nodes Support

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

  • VMWGFX Enables DRM Render Nodes Support

    Phoronix: VMWGFX Enables DRM Render Nodes Support

    VMware's VMWgfx virtual graphics driver stack has picked up some new capabilities...

    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
    Having objects and resources located on the guest GPU is important to avoid bottlenecks.
    Last edited by plonoma; 25 March 2014, 04:19 PM.

    Comment


    • #3
      Does VMware's graphics drivers passthrough/translate hardware video acceleration (DXVA for Windows guests, VAAPI, VDPAU, etc.) to guests for their hosted solutions (Workstation/Player)? Maybe even the encode stuff too.

      Comment


      • #4
        Guest Backed Objects is a slightly strange thing. We call it Guest Backed Objects because the guest is responsible for maintaining a memory backing for all objects that it creates.

        On our currently released products, the memory behaviour is most like a discrete GPU. There's a chunk of "aperture" memory that both the GPU and CPU can access but most of the memory is on the other side of a "wall": our virtual PCI bus. The host has a copy of the surface but the guest CPU can't access it directly; just like the framebuffer memory on a physical GPU. Updating either the host's or the guests's view of a texture involves simulated DMA operations to copy the surface data across the bus (this happens quickly since it's all shared memory). There are ways on the current architecture of expanding the effective size of that aperture but in general it's pretty limiting.

        Under Guest Backed Objects, the memory is treated more like what you'd see on an embedded, shared memory GPU. The guest makes an allocation inside it's own system memory that the host can use to perform operations on. This has the advantage of giving the guest a lot more flexibility about how much memory is needed to support graphics operations; previously everything had to be allocated up front so you had a fixed sized hole in your guest's available memory. That's still there but its much smaller in the new world. It also lets the host have more flexibility as the host now has somewhere it can page graphics objects out to if the host encounters memory pressure. This is important for environments where the host is memory constrained as we can start pushing things back into the guest to relieve that pressure. We still have commands that are used to ensure coherency between the guest and host views of the memory but it's a lot more free-flowing.

        Originally posted by pumahove View Post
        Does VMware's graphics drivers passthrough/translate hardware video acceleration (DXVA for Windows guests, VAAPI, VDPAU, etc.) to guests for their hosted solutions (Workstation/Player)? Maybe even the encode stuff too.
        Nope, but it is on our radar.

        Comment

        Working...
        X