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