¶3D acceleration under virtualization
On my last entry about a shader compiler, a commenter asked why I don't use 3D acceleration. One of the problems with this is availability. There are many reasons why 3D acceleration may not be viable, such as:
- No viable 3D acceleration available. This is particularly the case for video setups -- a Matrox Rainbow Runner makes a decent MJPEG capture device, but not a very good 3D one.
- Non-local session. If you're logged in via Terminal Services or Remote Desktop, you get no access to 3D hardware.
- Locked workstation.
- Headless execution environment. If you're running as a service for job scheduling reasons, you have no access to the 3D hardware.
The one that I forgot, however, is virtualization. Until recently, running in a virtualized CPU environment meant you got no 3D acceleration, because only a 2D display adapter was emulated. This was true for the two majors at the time, VMWare and VirtualPC. This is perhaps most annoying for testing -- I don't know about you, but I don't have any real systems left running Windows 98. Thus, your only options for running under these systems was to have a fallback where you used no 3D acceleration at all.
That's changed, now that both VMWare and Parallels have 3D acceleration support.
I've been curious as to how effective the 3D support is, so out of curiousity, I installed VMWare Player and dumped the Direct3D caps bits from it and my friend's MacBook running Parallels. Just for kicks, I'll throw in the caps from the system I ran VMWare Player on as well:
(Getting DXCapsViewer running on VMWare Player was a bit interesting, as for some reason it wouldn't run -- probably because I tried running it under Windows XP RTM. If you run into errors about problems with application configuration, open DXCapsViewer.exe in Visual Studio in Resource mode and delete the manifest resource.)
Analysis after the jump.
Now, this isn't a fair comparison between the solutions, since I was running VMWare Player on a different system instead of VMWare Fusion. Still, I find the differences between the two solutions interesting. Neither of them will virtualize a 3D card to the point of being usable for GPGPU, at least for Direct3D, but they're getting close. I believe both are translating Direct3D calls into OpenGL, which is going to cause problems that are very hard to fix -- for instance, the rules for which verts control interpolants for flat shaded primitives are very different between OpenGL and Direct3D.
Parallels was the one I looked at first. This was on an ATI Radeon X1300 Mobility:
- The most surprising thing is how the 3D virtualization was implemented. When I tried VirtualDub, it crashed within wined3d.dll. It's well known now that Parallels makes use of WINE code, but based on the call stack, it looks like what they do is hack processes to swap in wined3d for the regular Microsoft Direct3D runtime. Potentially this gives them a faster solution, but it's a bit hacky. Don't think this is workable to accelerate Aero Glass, but we'll see.
- Supports vertex shader 1.1 and pixel shader 1.4, putting it in DX8.1-class hardware. Not bad, plenty of games can work with this.
- It advertises 253 vertex shader constants... weird.
- Doesn't set any of the DeclTypes flags, so no UBYTE4, SHORT2, etc.
- Doesn't support D3DPRESENT_INTERVAL_ONE -- no vsync!
- Doesn't support D3DPRASTERCAPS_COLORPERSPECTIVE. Strange, hadn't seen this in a while.
- Sets D3DPTEXTURECAPS_NONPOW2CONDITIONAL but not D3DPTEXTURECAPS_POW2. This looks like a bug, because the latter has to be set for the former.
- Supports R8G8B8 for texturing and rendering. Very rare.
- Says it supports P8 for a render target. I have no idea how that is supposed to work.
- Sort of works in practice. I got my favorite D3D7 test app to work, "I've got some Balls." (Yes, that is a real program. It's a fun little game.) I don't think we had any luck with Titan Quest or Civ4, though.
VMWare Player 2 took a little coaxing to get working: (Native card is an NVIDIA GeForce Go 6800):
- It looks like VMWare wrote a proper Direct3D 9 display driver for their solution. This is a fairly clean way to do it, but it's a lot of work (the DDI is a mess). They'd also have to redo it completely for Windows Vista if they wanted to support WDDM for Aero Glass.
- Seems a bit unstable. Both VirtualDub in D3D mode and I've got some Balls caused the driver to blue-screen. DXDiag ran, but I got massive flickering on the D3D9 test. VirtualDub in OpenGL mode had redraw problems whenever I brought up the display pane context menu, but it did work.
- No shaders at all. Not going to run a lot of modern 3D software.
- Doesn't support PUREDEVICE.
- COLORPERSPECTIVE is also cleared here.
- Doesn't support BLENDFACTOR for a destination blend factor.
- Doesn't support NONPOW2CONDITIONAL. That may break some UIs.
- Doesn't support BORDER texture addressing.
- Says it can antialias lines, even though the native D3D driver can't.
- Doesn't support the MULTIPLYADD or LERP texture stage modes. That will probably break stuff.
- Only supports the UBYTE4 decl type.
- Very restricted in render target formats. In fact, if you are running with a 32-bit display mode, you can only use A8R8G8B8 and X8R8G8B8, whereas if you are running 16-bit, you only get R5G6B5. This applies to both windowed and full screen modes. This is going to break stuff.
- Supports DXT1, DXT3, and DXT5 for texture formats, but not DXT2 or DXT4... WTF?? The only difference between DXT2 and DXT3, and between DXT4 and DXT5 is... the FOURCC itself. They're supposed to distinguish between textures that have precomposited and non-precomposited alpha. The hardware doesn't care, so I'm curious why DXT2 and DXT4 weren't supported. Not that I believe anyone uses them anyway....
So, basically... whether you can get Direct3D-based software running on these is hit-or-miss, considering that the reported feature sets are quite different from what you'd find on real video cards. I haven't dug into OpenGL much, although I suspect it'd be a bit more stable given that it'd be more of a pass-through. Still, even though it's not really viable at this point, it is good to see some progress made on the 3D virtualization front.
(Now, back to CPU land for me....)