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
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
