vmware3D

Support for 3D acceleration and RandR 1.2 in xf86-video-vmware

What's needed

• xf86-video-vmware >= 11.9.x. The stable release will be named 12.0.0
• A linux kernel with the post-staging version of the vmwgfx driver enabled. The vmwgfx kernel driver version should be 2.3.0 or higher.
• A Mesa release or checkout from the 8.0 branch with the dri-vmwgfx and xa-vmwgfx targets enabled.
• VMware Workstation 8.0.2, VMware Fusion 4.1.2 or VMware Player 4.0.2. Strictly the driver should run with Workstation 8.0, Fusion 4.0 or Player 4.0, but glxSwapBuffers will be very slow and there might be some additional rendering problems as well. In short: At least don't try to benchmark the driver performance withouth a recommended version of Workstation, Fusion or Player.
• libdrm does not need any specific vmware options enabled.

Generic User Notes

• Due to the way software- (2D) and accelerated (Video, 3D) contents are mixed, certain operations may be slow when both accelerated contents and software contents overlap. Mixing software- and accelerated contents in a virtual environment is tricky and we've tried to optimize the driver to give the best possible interactive experience for most use cases and the new 3D-enabled compositors.
• XRender will usually not be accelerated unless operating on previously rendered 3D- or video surfaces. Therefore setups that use XRender for big operations, like XRender-enabled compositing managers, may consume a lot of CPU on large screens. The interactivity feeling when running, for example Kwin with Xrender effects enabled should be fairly good, particularly if your processor is fast.
• On multi-monitor setups the glxSwapBuffers operations are still a bit slow. This will be addressed in future Workstation / Fusion releases. To somewhat work around this problem, it's possible to reduce the Workstation / Fusion GUI update frequency using the following .vmx file option: (The number is the minumum delay in microseconds between GUI updates).
  svga.frameRateLimitUS = 15000
• Applications that warp the cursor, like games or the Compiz spinning cube will not work well with VMmouse enabled, since it uses the host cursor. If this becomes a problem for you, please use the following .vmx file option to disable VMmouse, and use the VMware relative USB mouse instead: (Motion ungrab will be lost and you'll see a slightly increased cursor lag). mouse.vusb.enable = "TRUE"
• The VMware absolute USB mouse device may, on many distributions, be detected by the udev system as a joystick. This may lead to games moving the cursor to the upper left corner or the game constantly registering a leftward-upward motion. To work around this, please disable joystick use in the game's setup, or if you have another joystick, select that one instead.
• If you use fancy RandR 1.2 features, like rotation and / or scaling and at the same time use VMMouse, cursors may not behave as expected. In that case, set up the relative USB mouse as described above. The driver is only capable of displaying a single hardware cursor at a time, so if more cursors need to be displayed, like when cloning outputs, the driver will automatically revert to software cursors.

Generic Developer Notes

• What is SAA, and why wasn't EXA used? SAA or "Shadow Acceleration Architecture" is a simple acceleration architecture with combines code from both EXA and Intel's UXA. SAA is very simple and intended to be used by drivers that really don't want to accelerate everything, and if the driver needs to accelerate, SAA attempts to accurately track exactly what contents is accelerated. The idea behind this is that it's often more costly to set up the accelerator state than to perform the render operation in software on cached memory. The drawback is that large copies or render operations are slower. EXA and UXA aren't tracking rendered areas carefully enough, and modifying EXA to do that would have required invasive changes in internal- and driver EXA apis. However, it should, with a decent amount of work and testing, be possible to implement SAA as an EXA migration policy.
• Is xf86-video-vmware eventually going to accelerate 2D and XRender fully? Possibly, but in virtual environments, migration between guest contents (software rendered stuff) and hypervisor contents (accelerated stuff) is slow and painful. Creation and destruction of accelerated pixmaps is also a very slow operation. The fact that D3D9 doesn't support logicops is also a limiting factor. To fully support 2D and XRendeR operation means that we must be able to accelerate everything, and when there are fallbacks we need render in software and blend the result onto the destination, possibly using logicops and non-rectangular shapes for things like diagonal lines. The question then arises whether this will actually give better interactivity than the current mixing of software- and accelerated contents.
• What is XA and how is SAA and XA related? XA is a freestanding acceleration API that is intended to be useful for X acceleration architectures. The VMware driver is using it to handle acceleration requests from SAA, but it could also theoretically be interfaced with EXA or UXA. The XA version used by xf86-video-vmware is naturally using Gallium3D to accelerate, but it should also be possible to implement XA on top of EGL, for example. XA has support for XRender-like operations and YUV conversions. It's used by xf86-video-vmware to accelerate XRender when needed, for accelerated copies when needed (glxSwapBuffers or compositing of previously accelerated contents), and for the textured XVideo adaptor.