Initial version

1 files changed, 21 insertions, 1 deletions

diff --git a/vmware/vmware3D.moin b/vmware/vmware3D.moin
index 2b041a05..48be322d 100644
--- a/vmware/vmware3D.moin
+++ b/vmware/vmware3D.moin
@@ -1 +1,21 @@
-Support for 3D acceleration and RandR12 in xf86-video-vmware

+= Support for 3D acceleration and RandR12 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-stagin version of the vmwgfx driver enabled. The vmwgfx 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 or VMware Fusion 4.1.2. Strictly the driver should run with Workstation 8.0 or Fusion 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 or Fusion.

+ * 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. A good such example is shaped windows on top of 3D or video. (Xine with unscaled OSD). 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 not perform well on large screens.

+ * 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 option:

+ * 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 option to disable VMmouse, and use the VMware relative USB mouse instead:

+ * The VMware absolute USB mouse device may be detected by the kernel 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 RandR12 features, like rotation and / or scaling and at the same time use VMMouse, cursors may don't 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.

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