[vbox-dev] Some guest gpu inconsistencies

[Jan Bruns]

Hallo.

I've noticed some inconsistencies in the d3d9 guest additions. I'm very 
unsure if I'll find the time to fix. But maybe talking that over could 
help some else to fix.

First, while trying to play the game Oblivion in a vbox (yay, that 
basically seems to work now!), but the game often crashed. The crash 
frequency correlated heavily with resolution and level of detail 
settings, and it was even possible to trade resolution against LOD. On 
the other hand, there was no obvious relationship with framerate or 
specific actions in the game.

The cause might be that the DX9 memory doesn't match the vbox setting 
(d3d9 reports fixed 64 MB here, and really counts down with resource 
allocation; so with a 2MPixel framebuffer setup including multiple back- 
and depth buffers, this vidmem was already substantially consumed).

Furthermore, another game refused to work and complained about missing 
"two-sided stencil support". This is also reported in the d3d9 caps.

The guest GL reports to be GL2.1 (which should include 2-sided stencil 
per core spec, I think) but doesn't mention corresponding extensions.

After having a first look at the vbox source, I'm suprised that my host 
gpu vendor seems to have found it's way into the guest. The last resort 
vendor guess for the directX to GL wrap is nvidia, but amd was chosen 
somehow, even though the guest GL is vbox specific, definetly nothing 
the wrapper could already be aware about.

The guest-host GL tunneling code (including state trackers) seems a bit 
complicated with respect to stencil states. Not sure if the stencil caps 
downgrade was already introduced there, or if making the DX runtime 
choose other virtual hardware would already fix.

The most interesting question for now is probably the way the gpu vendor 
name (amd) traveled into the vm. How does the guest addition know about 
that?

Gruss

Jan Bruns