VirtualBox

Ticket #2940 (closed enhancement: fixed)

Opened 5 years ago

Last modified 4 years ago

VirtualBox should support Direct3D through WineD3D

Reported by: JeremyVisser Owned by:
Priority: major Component: 3D support
Version: VirtualBox 2.1.0 Keywords: direct3d
Cc: Guest type: Windows
Host type: other

Description

Currently, Wine makes Direct3D apps work on Linux by wrapping the Direct3D in OpenGL. This code can be reused in VirtualBox to add Direct3D support to the already working OpenGL acceleration system.

The following DLLs from Wine need to be compiled and added to the guest OS:

  • libwine.dll
  • wined3d.dll
  • d3d8.dll
  • d3d9.dll

These DLLs would be shipped and installed with the guest additions.

Currently, these DLLs can be produced manually by following  directions posted on the Wine wiki.

By installing these DLLs on a native (host) Windows system, one can successfully use Direct3D applications that are wrapped in OpenGL.  (Reference)

There is still some work to be done. In my testing, Direct3D applications still do not run correctly when these DLLs are added to the guest system. However, they do report that Direct3D is supported (without these DLLs present, they claim that Direct3D acceleration is unavailable), but fail upon initialisation.

Most of the heavy work is done -- the Wine project has been wrapping Direct3D games for years, and VirtualBox has some awesome OpenGL support. All that is needed now is to make WineD3D play nice with VirtualBox, and we will have Direct3D support on Windows guests.

Binaries built straight from the Wine 1.1.10 source are available for  download. If anybody has success with these DLLs, please speak up!

See also

Attachments

chromium_wined3d.jpeg Download (370.0 KB) - added by rmh 5 years ago.
chromium_getstring_passthru.diff Download (4.3 KB) - added by rmh 5 years ago.
vbox_opengl_workarounds.diff Download (2.1 KB) - added by rmh 5 years ago.
vbox_opengl_workarounds.2.diff Download (3.9 KB) - added by baskanov 5 years ago.

Change History

comment:1 Changed 5 years ago by JeremyVisser

I should add that Parallels uses this technique to achieve Direct3D support in its products, so we know we can get it working.

comment:2 Changed 5 years ago by sandervl73

Thanks for the interesting tip. I prefer plugging in wrapper code in a d3d graphics driver, but this could be a good first step.

comment:3 Changed 5 years ago by sandervl73

We already had plans to use the Wine D3D code as there's no point in reinventing the wheel. :)

comment:4 follow-up: ↓ 17 Changed 5 years ago by rmh

Hi,

I got a snapshot from wine git today, built wine d3d as per instructions in  http://wiki.winehq.org/WineD3DOnWindows, and built d3d9_test.exe in the same environment (make -C dlls/d3d9/tests). Problems I found in the opengl implementation:

  • Calling wglGetExtensionsStringARB or wglGetPixelFormatAttribivARB (or apparently, any opengl function that relies on the handler returned by pwglGetCurrentDC() results in segfault).
  • glGetString(GL_VENDOR) returns "Microsoft Corporation", but wine expects it to return a name that identifies the chip vendor.
  • glGetString(GL_RENDERER) returns "GDI Generic", but wine uses a set of heuristics to figure out which card model is this (which is used to determine the amount of video memory, or otherwise fallback to 64 MB).
  • An undetermined issue with extension detection (see workaround patch).

Should I open separate bugs/tickets for those?

I made a few workarounds to wine that get d3d9_test.exe to pass a few tests:

d3d9ex and surface pass 100%, query, shader, vertexdeclaration and volume pass with a few failures, and the others have lots of failures or segfault/crash.

dxdiag recognises direct3d support, but its testsuite also fails with a variety of errors. I haven't found any application that succesfuly uses this d3d.

comment:5 follow-up: ↓ 18 Changed 5 years ago by rmh

Also worthy of interest:

 http://wiki.winehq.org/Parallels

comment:6 Changed 5 years ago by rmh

Sander, would you consider publishing your wined3d work tree so that others can also play with it?

comment:7 Changed 5 years ago by sandervl73

We haven't started yet. As soon as we do, it will show up in SVN.

comment:8 follow-up: ↓ 9 Changed 5 years ago by sandervl73

Are you sure you have enabled 3d acceleration by the way? Both GL_VENDOR and GL_RENDERER should be different. Looks like you're using MS's software fallback.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 19 Changed 5 years ago by rmh

Replying to sandervl73:

We haven't started yet. As soon as we do, it will show up in SVN.

Cool :-)

Replying to sandervl73:

Are you sure you have enabled 3d acceleration by the way? Both GL_VENDOR and GL_RENDERER should be different. Looks like you're using MS's software fallback.

I installed vbox 2.1.2 OSE (from debian experimental archive), then enabled the 3D acceleration checkbox before installing Windows. After that, I installed the guest drivers (I used the default CD image that vbox downloaded from Sun). Then I tested OpenGL using WGLGears.exe from  http://www2.cs.uidaho.edu/~jeffery/win32/index.html .

opengl32.dll looks very much like MS' version. Should the vbox guest add-ons be providing an alternate version which I've missed somehow?

comment:10 follow-up: ↓ 11 Changed 5 years ago by JeremyVisser

rmh, may be an obvious question, but are you sure the d3d{8,9}.dll and *wine*.dll files are in the same directory as the d3d9_test.exe file, or in the system %PATH%? That may explain the anomaly.

comment:11 in reply to: ↑ 10 Changed 5 years ago by rmh

Replying to JeremyVisser:

rmh, may be an obvious question, but are you sure the d3d{8,9}.dll and *wine*.dll files are in the same directory as the d3d9_test.exe file, or in the system %PATH%? That may explain the anomaly.

Completely. Wine DLLs spit a lot of output (specially since I set WINEDEBUG=+all), and I added a few traces of my own for debugging.

comment:12 follow-up: ↓ 13 Changed 5 years ago by sandervl73

rmh: Attach your VBox.log please. That should include some Opengl related messages.

comment:13 in reply to: ↑ 12 Changed 5 years ago by rmh

Replying to sandervl73:

rmh: Attach your VBox.log please. That should include some Opengl related messages.

There are none. See:  http://www.virtualbox.org/ticket/3224

Changed 5 years ago by rmh

comment:14 Changed 5 years ago by rmh

We have Direct3D now, see screenshot :-)

I added proper Chromium detection and removed some of the workarounds that no longer apply. Remaining issues:

  • How can we detect size of video memory? I searched a bit and it appears that there's no portable way to do this. For now I hardcoded it to 12 MB which was the default in VBox.
  • Calling wglGetExtensionsStringARB results in segfault (notice that glXQueryExtensionsString worked fine).
  • Calling wglGetPixelFormatAttribivARB results in segfault. Note that Parallels' code ( http://wiki.winehq.org/Parallels) some pixelformat-related stuff, though I doubt it could be related.

comment:15 Changed 5 years ago by JeremyVisser

w00t! Thanks for your work, rmh!

comment:16 Changed 5 years ago by sandervl73

rmh: Would you be able to get it building with kbuild? That way we could import it directly into SVN and publish it. We kindly ask you to sign our contributors agreement or release any changes you made under the MIT license. The original Wine sources will keep their LGPL license of course.

See  http://www.virtualbox.org/wiki/Contributor_information for details.

Thanks!

comment:17 in reply to: ↑ 4 Changed 5 years ago by Roderick

Replying to rmh:

Hi,

I got a snapshot from wine git today, built wine d3d as per instructions in  http://wiki.winehq.org/WineD3DOnWindows, and built d3d9_test.exe in the same environment (make -C dlls/d3d9/tests). Problems I found in the opengl implementation:

  • Calling wglGetExtensionsStringARB or wglGetPixelFormatAttribivARB (or apparently, any opengl function that relies on the handler returned by pwglGetCurrentDC() results in segfault).
  • glGetString(GL_VENDOR) returns "Microsoft Corporation", but wine expects it to return a name that identifies the chip vendor.
  • glGetString(GL_RENDERER) returns "GDI Generic", but wine uses a set of heuristics to figure out which card model is this (which is used to determine the amount of video memory, or otherwise fallback to 64 MB).
  • An undetermined issue with extension detection (see workaround patch).

Should I open separate bugs/tickets for those?

I made a few workarounds to wine that get d3d9_test.exe to pass a few tests:

d3d9ex and surface pass 100%, query, shader, vertexdeclaration and volume pass with a few failures, and the others have lots of failures or segfault/crash.

dxdiag recognises direct3d support, but its testsuite also fails with a variety of errors. I haven't found any application that succesfuly uses this d3d.

We have registry keys in Wine to set the amount of video memory and the pci id. The gpu detection based on opengl info is just to set some reasonable defaults. When I have time I will extend the code with other backends like e.g. NV-CONTROL in case of Nvidia.

comment:18 in reply to: ↑ 5 Changed 5 years ago by Roderick

Replying to rmh:

Also worthy of interest:

 http://wiki.winehq.org/Parallels

The Parallels code is junk and isn't really useful. When I ported WineD3D over to WGL I didn't use any of their hacky code.

comment:19 in reply to: ↑ 9 Changed 5 years ago by Roderick

Replying to rmh:

Replying to sandervl73:

We haven't started yet. As soon as we do, it will show up in SVN.

Cool :-)

Replying to sandervl73:

Are you sure you have enabled 3d acceleration by the way? Both GL_VENDOR and GL_RENDERER should be different. Looks like you're using MS's software fallback.

I installed vbox 2.1.2 OSE (from debian experimental archive), then enabled the 3D acceleration checkbox before installing Windows. After that, I installed the guest drivers (I used the default CD image that vbox downloaded from Sun). Then I tested OpenGL using WGLGears.exe from  http://www2.cs.uidaho.edu/~jeffery/win32/index.html .

opengl32.dll looks very much like MS' version. Should the vbox guest add-ons be providing an alternate version which I've missed somehow?

In the end I would recommend to ship your own opengl32.dll for instance use the one shipped with ReactOS which is based on Mesa. The reason why you should use your own opengl32.dll is to allow wine's ddraw.dll (directdraw + <= d3d7) to work. I explained on the wine wiki that native opengl32.dll uses ddraw and that prevents ddraw / d3d from working. I haven't found a solution yet. (Though directly loading a ICD driver could work but that isn't nice and I believe it will unleash all sorts of issues)

comment:20 Changed 5 years ago by sandervl73

I don't see the point of shipping our own opengl since the ICD model is perfectly fine. Replacing DirectDraw as well is a really bad idea. I know Wine has come a long way in providing compatibility, but replacing more MS dlls is just asking for trouble.

The best solution is to not replace the system files at all but implement D3D extensions in the display driver. The big question is of course how well that interface maps to the existing Wine code.

comment:21 Changed 5 years ago by Roderick

In the end Parallels moved to writing their own display driver which implements direct3d somehow using opengl I think but writing a real display driver is first of all a lot of work, second the driver model is different for different windows version (9x, XP, Vista). The driver model is quite different from what Wine is doing and basically you would have to restart from scratch. I don't know if you the manpower for that is around and if you really want to go that way.

comment:22 follow-up: ↓ 34 Changed 5 years ago by leonid

My 5 cents: wglGetExtensionsStringARB - is an extension function which doesn't have to be exported at all, thus return value of getprocaddress should be checked before calling it :) Though, I've added it to exports list of vbox ICD. Same applies to wglGetPixelFormatAttribivARB.

Regading ICD/opengl32.dll ways: If you want ... you can use VBox ICD as the opengl32.dll because it have all needed exports and will work that way. Just rename VBoxOGL.dll into opengl32.dll and that's it. But I'd agree with Sander that ICD model suits all our needs so far. Also, regarding DDraw and opengl, there's a plan to use some of DDraw functionality inside our driver. There's already some disabled code which just need bit of debugging.

comment:23 Changed 5 years ago by sandervl73

We'll soon commit Wine code that builds in our system, so no need to worry about that right now.

comment:24 follow-ups: ↓ 26 ↓ 28 Changed 5 years ago by rmh

Replying to JeremyVisser:

w00t! Thanks for your work, rmh!

Credit should go to the WineD3D developers. I just came and added the missing piece, but all the big stuff was there already.

Replying to sandervl73:

rmh: Would you be able to get it building with kbuild?

I can take a look. But I think integrating the WineD3D build into VBox can be a bit messy, specially if you intend the build to work on win32.

That way we could import it directly into SVN and publish it. We kindly ask you to sign our contributors agreement or release any changes you made under the MIT license. The original Wine sources will keep their LGPL license of course.

See  http://www.virtualbox.org/wiki/Contributor_information for details.

I'm fine with assigning copyright to Sun. I'll have to look at the specific terms. Is there any contact address I may contact if I have questions/doubts about them?

Replying to Roderick:

We have registry keys in Wine to set the amount of video memory and the pci id. The gpu detection based on opengl info is just to set some reasonable defaults. When I have time I will extend the code with other backends like e.g. NV-CONTROL in case of Nvidia.

Is it possible Chromium has such backend? If not, maybe we could add it.

Replying to Roderick:

In the end I would recommend to ship your own opengl32.dll for instance use the one shipped with ReactOS which is based on Mesa. The reason why you should use your own opengl32.dll is to allow wine's ddraw.dll (directdraw + <= d3d7) to work. I explained on the wine wiki that native opengl32.dll uses ddraw and that prevents ddraw / d3d from working. I haven't found a solution yet. (Though directly loading a ICD driver could work but that isn't nice and I believe it will unleash all sorts of issues)

So we could avoid replacing ddraw.dll like Sander said, but we still want to replace d3d7.dll if possible. Does the infinite loop still happen if you replace d3d7.dll only?

Replying to leonid:

My 5 cents: wglGetExtensionsStringARB - is an extension function which doesn't have to be exported at all, thus return value of getprocaddress should be checked before calling it :) Though, I've added it to exports list of vbox ICD. Same applies to wglGetPixelFormatAttribivARB.

I'll look into why WineD3D isn't checking it. Anyway, which commit exported those functions? I can give that a try.

comment:25 Changed 5 years ago by Roderick

Note that ddraw is both DirectDraw and Direct3D. Providing plain directdraw isn't that hard I think but you don't want to reinvent the wheel for Direct3D.

comment:26 in reply to: ↑ 24 Changed 5 years ago by Roderick

So we could avoid replacing ddraw.dll like Sander said, but we still want to replace d3d7.dll if possible. Does the infinite loop still happen if you replace d3d7.dll only?

That's the whole problem there is no such thing as a d3d3.dll / d3d5.dll / d3d6.dll / d3d7.dll it is all ddraw.dll. Most of the time I have to touch wined3d.dll itself but I haven't hacked ddraw.dll directly in a while. For the most part it uses COM-stuff, so it might be possible to create 1 wrapper dll which uses the windows driver model for some of the 2d stuff and wine's ddraw stuff when 3d is involved but this won't work well as most games use both 2d and 3d (a lot of functions are just the same).

comment:27 follow-up: ↓ 29 Changed 5 years ago by sandervl73

Everything has been exported to SVN. Feel free to supply patches.

comment:28 in reply to: ↑ 24 Changed 5 years ago by leonid

Replying to rmh:

I'll look into why WineD3D isn't checking it. Anyway, which commit exported those functions? I can give that a try.

It's there for quite some time, see r16220. Also kmk for wine is in svn too now.

comment:29 in reply to: ↑ 27 Changed 5 years ago by rmh

Replying to sandervl73:

Everything has been exported to SVN. Feel free to supply patches.

You probably want to merge this one:  http://bugs.winehq.org/show_bug.cgi?id=17193

The wglGetExtensionsStringARB part would be unnecessary, but there's also wglGetPixelFormatAttribivARB. Or perhaps it's easier to just export that one if you have already implemented it.

comment:30 Changed 5 years ago by rmh

I wrote a simple WineD3D installer, see:  http://bugs.winehq.org/show_bug.cgi?id=17194

It's meant to be general-purpose, but you could use it as reference for the VBox installer. Btw, I couldn't find .nsi files in VBox svn, are you using NSIS?

comment:31 Changed 5 years ago by rmh

For those who don't have a build environment handy:  http://aybabtu.com/rmh/wined3d/wined3d.exe

(built using wine git and the patch from bug 17193, known to work on vbox 2.1 ose)

comment:32 Changed 5 years ago by Technologov

Very interesting thread. Added myself :)

-Technologov, 02.02.2009

Changed 5 years ago by rmh

comment:33 follow-up: ↓ 54 Changed 5 years ago by rmh

chromium_getstring_passthru.diff modifies Chromium so it will report GL_VENDOR, GL_VERSION and GL_RENDERER from the host. This is much preferred as explained in  http://bugs.winehq.org/show_bug.cgi?id=17190 since some applications make unportable use of this info.

Note: I've been unable to test this code, because I don't have a native win32 build environment for the guest additions, but I'm reasonably sure it should DTRT.

comment:34 in reply to: ↑ 22 ; follow-ups: ↓ 35 ↓ 36 Changed 5 years ago by rmh

Replying to leonid:

Regading ICD/opengl32.dll ways: If you want ... you can use VBox ICD as the opengl32.dll because it have all needed exports and will work that way. Just rename VBoxOGL.dll into opengl32.dll and that's it.

Tried that, but it won't work without some changes. Currently VboxOGL.dll gets a handle to opengl32.dll and tries to register its functions in it. See crLoadOpenGL in VBox/GuestHost/OpenGL/spu_loader/glloader.py.

I'll try the ReactOS version as Roderick suggested. Unlike MS opengl32, this one is completely a stub, and only relies on the ICD driver or on mesa32 for software rendering.

comment:35 in reply to: ↑ 34 Changed 5 years ago by rmh

Replying to rmh:

I'll try the ReactOS version as Roderick suggested. Unlike MS opengl32, this one is completely a stub, and only relies on the ICD driver or on mesa32 for software rendering.

Tried ReactOS opengl32.dll (btw, you can get it quickly by mounting their livecd and copying it from /mnt/reactos/system32/). Btw note that dropping it to the current directory won't work, since Chromium insists in using c:\windows\system32. For some reason the lack of PixelFormat export causes more breakage than before. Basically nothing works untill I replaced VBoxOGL.dll with Mesa32.dll from ReactOS.

At this point OpenGL apps work (very slowly since we have software rendering now), and wine's ddraw.dll even passes most of its D3D-related tests!! (976 out of 991)

So the Wine ddraw.dll + ReactOS opengl32.dll + ReactOS mesa32.dll stack seems pretty usable. I'd expect if VBoxOGL.dll exported the PixelFormat bits it could fit well there.

Is a new build of the guest additions being rolled soon? Unfortunately I can't build these myself .

comment:36 in reply to: ↑ 34 Changed 5 years ago by leonid

Replying to rmh:

Replying to leonid:

Regading ICD/opengl32.dll ways: If you want ... you can use VBox ICD as the opengl32.dll because it have all needed exports and will work that way. Just rename VBoxOGL.dll into opengl32.dll and that's it.

Tried that, but it won't work without some changes. Currently VboxOGL.dll gets a handle to opengl32.dll and tries to register its functions in it. See crLoadOpenGL in VBox/GuestHost/OpenGL/spu_loader/glloader.py.

2 easy ways to solve it:

  1. Put VBoxOGL*.dll into some folder like c:\vboxogl, cp VBoxOGL.dll c:\vboxogl\opengl32.dll and add c:\vboxogl to PATH environment variable.
  2. Or, put original MS's opengl32.dll to some place and add the path to CR_SYSTEM_GL_PATH env.

Changed 5 years ago by rmh

comment:37 follow-up: ↓ 38 Changed 5 years ago by baskanov

missing wglGetPixelFormatAttribivARB can be partially replaced by DescribePixelFormat. this gives better results(e.g. dxdiag's test works).

comment:38 in reply to: ↑ 37 ; follow-up: ↓ 39 Changed 5 years ago by rmh

Replying to baskanov:

missing wglGetPixelFormatAttribivARB can be partially replaced by DescribePixelFormat.

Could you be more specific? Is DescribePixelFormat supposed to be a dropin replacement (same api)? If not, what changes did you do?

this gives better results(e.g. dxdiag's test works).

Cool. I didn't get any of dxdiag's test to work. Which one did you try?

comment:39 in reply to: ↑ 38 Changed 5 years ago by baskanov

Replying to rmh:

Replying to baskanov:

this gives better results(e.g. dxdiag's test works).

Cool. I didn't get any of dxdiag's test to work. Which one did you try?

I tried Direct3D 8 and 9 tests. The d3d9 test works fine, but it is very slow. The d3d8 test works the same way, except the first attempt, at which it fails with error message.

Changed 5 years ago by baskanov

comment:40 follow-ups: ↓ 41 ↓ 42 Changed 5 years ago by baskanov

I've found a way to speed things up: compiling wine with WINE_NO_DEBUG_MSGS defined. This disables error checking through glGetError. It seems like opengl calls are really slow with chromium.

comment:41 in reply to: ↑ 40 Changed 5 years ago by leonid

Replying to baskanov:

I've found a way to speed things up: compiling wine with WINE_NO_DEBUG_MSGS defined. This disables error checking through glGetError. It seems like opengl calls are really slow with chromium.

glGetError is a blocking call, it forces guest vm to send command buffer and wait for reply from host gpu drivers.

comment:42 in reply to: ↑ 40 ; follow-up: ↓ 43 Changed 5 years ago by rmh

baskanov, it seems your patch fixes wine bug 17193. I just sent a reference to it:

 http://bugs.winehq.org/show_bug.cgi?id=17193#c4

You might want to followup there.

Replying to baskanov:

I've found a way to speed things up: compiling wine with WINE_NO_DEBUG_MSGS defined. This disables error checking through glGetError. It seems like opengl calls are really slow with chromium.

I'll add this to my builds ( http://aybabtu.com/rmh/wined3d/), as well as your patch. Nice work!

comment:43 in reply to: ↑ 42 Changed 5 years ago by BearTM

Replying to rmh:

baskanov, it seems your patch fixes wine bug 17193. I just sent a reference to it:

 http://bugs.winehq.org/show_bug.cgi?id=17193#c4

You might want to followup there.

Replying to baskanov:

I've found a way to speed things up: [snip] It seems like opengl calls are really slow with chromium.

I'll add this to my builds ( http://aybabtu.com/rmh/wined3d/), as well as your patch. Nice work!

An aside - installing the latest build version (Feb 15) into a WindowsXP SP3 VirtualBox VM hosted on Ubuntu Intrepid 8.10 (2.6.27-11 / AMD64 / Gnome 2.24.1 / Compiz enabled), permitted iTunes Coverflow to work! It's not quite moving at the speed of light, but works 100% properly, without fault on my system. Amazing! Very nice work.

comment:44 follow-up: ↓ 45 Changed 5 years ago by ajmas

For those of us on the sidelines, given where the progress is, are you in a position to estimate when this work will make itself into a 'public beta'? I would like to test this, but I don't want to jump on board too soon, as not to report bugs before you want to know about them.

BTW My hat off to all those involved in getting thus far. Well done.

comment:45 in reply to: ↑ 44 Changed 5 years ago by rmh

Replying to ajmas:

For those of us on the sidelines, given where the progress is, are you in a position to estimate when this work will make itself into a 'public beta'? I would like to test this, but I don't want to jump on board too soon, as not to report bugs before you want to know about them.

I think I mentioned this before, but there's a site with public builds of wined3d for use on XP:

 http://aybabtu.com/rmh/wined3d/

this works on VBox and possibly others as well. Additionally, some improvements are expected in next version of VBox that will make wined3d run better.

comment:46 Changed 5 years ago by paulmai

As requested, I am submitting a review of my experience so far...

Using Virtualbox on the following system spec

Host: Dual (Not dual core..2 physical CPU's) Xeon 2.66 GHZ Processor 2GB Ram Nvidia FX5200 Ubuntu 8.04 (Hardy Heron)

Guest: Windows XP Professional SP3 1GB Ram Host additions installed 'Auto resize' feature is being used.

I installed the latest build as per the links above, enabled D3d emulation for (DirectX 8 & 9)

I then performed the following tests:

Test #1: Check that OpenGL is working correctly in VM A quick run of 'Armagetron' managed to prove this, game was running nice and fast with full effects.

Test #2: Check Direct 3D usage: Open DXDiag, click on display, run Direct3D tests, skipping the DX7 test (as this leads to a nasty freeze up), ran the DX8 and 9 tests, these ran, although a little jumpy. I also noticed that the D3D surface was the same size as the host desktop windowed resolution setting.

Test #3: Check Direct 3D usage: Downloaded 'Winamp', while playing some music, used the 'Milkdrop' Visualisation feature (as this makes use of Direct3D. Some graphical glitches were evident, but some visualizations played well (albeit, again a little jumpy and slow). Again the resolution issue from test #2 was encountered.

Observation: Is the resolution issue something that could be resolved by communication between the host additions and the customized Wine driver?

Also, could someone send me an explicit link to the latest, customized and improved version?

comment:47 Changed 5 years ago by ajmas

I decided to test this, using Google Earth in D3D mode, but no luck. It suggests I should try OpenGL instead (GoogleEarth works in OpenGL). What I did:

I ran dxdiag and this told me that DirectDraw acceleration was available, but not Direct3D. The files mentioned at the original comment of this ticket were indeed in C:\windows\system32. In dxdiag the wined3d.dll is not listed under the files tab.

VirtualBox 2.1.4, Host: MacOS X 10.5.6, Guest: Windows XP SP3

comment:48 Changed 5 years ago by raevol

I've got the same behavior as ajmas, no D3D detected. Also, under the files tab, and in the file properties when I browse to them, d3d8.dll and d3d9.dll report all the original microsoft information, should they be doing that? Is this a problem we should take up with wined3d? Please let me know if it is so I can go poke them.

comment:49 follow-ups: ↓ 50 ↓ 51 Changed 5 years ago by raevol

I got mine working. The wineD3D files need to be installed while windows is booted into safe mode.

Dxdiag complains about the files being out of date, and only one of the D3D tests actually shows the spinning cube, and it rotates too fast to see well. It will actually display though!

Tried running Half-Life, in D3D. It runs! It runs unplayably slow and has lots of graphical errors, but it runs!

comment:50 in reply to: ↑ 49 Changed 5 years ago by baskanov

Replying to raevol:

Tried running Half-Life, in D3D. It runs! It runs unplayably slow and has lots of graphical errors, but it runs!

Half-Life uses d3d version <= 7, which is not working yet in wined3d. I suppose it was working through Microsoft's d3d in software emulation.

comment:51 in reply to: ↑ 49 ; follow-up: ↓ 53 Changed 5 years ago by ajmas

Replying to raevol:

I got mine working. The wineD3D files need to be installed while windows is booted into safe mode.

I confirm this appears to be the approach to use, though it should not be necessary. Is this a bug in the installer?

Now trying Google Earth again in D3D my Windows XP VM crashes. I see nothing in the system event log of my guest OS.

Running the Direct 3D tests in dxdiag:

  • Direct3D 7 fails - this is normal since it is not enabled
  • Direct3D 8 fails at step 4 (EnumAdapterModes) HRESULT=0x8876086c (error code).
  • Direct3D 9 passes, but the cube is spinning extremely fast (confirming comment 49)

comment:52 Changed 5 years ago by ajmas

I have also tested with  Florensia. This allows me to almost get to the character creation screen before I experience a crash - the crash happens when I click on the new character button. I am using this as a test partly because I have it and partly because this a (currently) freely available game in D3D. This what I see in the crash log of the application:

----------------------------------------------------------------------
*** System ***
Windows XP Home Edition (5.1, Build 2600) Service Pack 3
Intel(R) Core(TM)2 Duo CPU     T9400  @ 2.53GHz, 1024MB RAM
DirectX 9.0c (4.09.0000.0904)
CodePage : 1252VGA: VirtualBox Graphics Adapter, 32.0 MB/32.0 MB
----------------------------------------------------------------------
*** Fault Reason ***
FlorensiaEn.bin caused an: < EXCEPTION_ACCESS_VIOLATION >
In module: FlorensiaEn.bin at: < 001B:00DB5084 >}}}

comment:53 in reply to: ↑ 51 Changed 5 years ago by rmh

Replying to ajmas:

Replying to raevol:

I got mine working. The wineD3D files need to be installed while windows is booted into safe mode.

I confirm this appears to be the approach to use, though it should not be necessary. Is this a bug in the installer?

No, it's a "bug" in Windows. Sometimes running in normal mode also works, but there's no garantee (depends on a race).

Anyone knows how to check for safe mode in NSIS? I think the installer should just abort and prompt the user to reboot when needed.

Running the Direct 3D tests in dxdiag:

  • Direct3D 7 fails - this is normal since it is not enabled
  • Direct3D 8 fails at step 4 (EnumAdapterModes) HRESULT=0x8876086c (error code).
  • Direct3D 9 passes, but the cube is spinning extremely fast (confirming comment 49)

D3D 8 works the second time you try.

comment:54 in reply to: ↑ 33 ; follow-up: ↓ 55 Changed 5 years ago by rmh

Replying to rmh:

chromium_getstring_passthru.diff modifies Chromium so it will report GL_VENDOR, GL_VERSION and GL_RENDERER from the host. This is much preferred as explained in  http://bugs.winehq.org/show_bug.cgi?id=17190 since some applications make unportable use of this info.

Note: I've been unable to test this code, because I don't have a native win32 build environment for the guest additions, but I'm reasonably sure it should DTRT.

Any comments on this patch for VBox? I think it should notably improve compatibility. Unfortunately I don't have the environment to build & test the guest additions myself.

comment:55 in reply to: ↑ 54 ; follow-up: ↓ 57 Changed 5 years ago by leonid

Replying to rmh: Any comments on this patch for VBox? I think it should notably improve compatibility. Unfortunately I don't have the environment to build & test the guest additions myself.

This wouldn't help unfortunately, it's doubtfull that application which tightly rely on those string would be happy to recieve em from MacOS/Linux host gpu drivers...

comment:56 follow-up: ↓ 58 Changed 5 years ago by TheCyberXP

Hi, I have some problem with VB 2.1.4 and WineD3D, I need to play with World Of Warcraft on my WinXP guest system (Linux Host) so I installed the Guest Addition, directX 9.0c and WineD3D.

The game lunch but when I try to put on my login and password the VM craches and will be avorted.

Do you know how can I fix this?

Thank,

comment:57 in reply to: ↑ 55 Changed 5 years ago by rmh

Replying to leonid:

Replying to rmh: Any comments on this patch for VBox? I think it should notably improve compatibility. Unfortunately I don't have the environment to build & test the guest additions myself.

This wouldn't help unfortunately, it's doubtfull that application which tightly rely on those string would be happy to recieve em from MacOS/Linux host gpu drivers...

Actually, it's WineD3D itself who does. It uses the info to fake PCI id information. Some applications rely heavily on the latter. See:

 http://bugs.winehq.org/show_bug.cgi?id=17190#c2

comment:58 in reply to: ↑ 56 Changed 5 years ago by rmh

Replying to TheCyberXP:

Hi, I have some problem with VB 2.1.4 and WineD3D, I need to play with World Of Warcraft on my WinXP guest system (Linux Host) so I installed the Guest Addition, directX 9.0c and WineD3D.

WineD3D is a replacement for DirectX; you don't want to install both.

The game lunch but when I try to put on my login and password the VM craches and will be avorted.

Do you know how can I fix this?

This is still experimental. Some problems are due to limitations of the OpenGL implementation, some are due to integration between it and WineD3D. A few would be due to bugs in WineD3D, but not this one.

comment:59 Changed 5 years ago by coolphoenix

i'm not completely sure how to enable wined3d 'the right way' in my windows-xp-vm (linux gentoo-x86_64 host, latest vbox-ose-trunk, additions installed from version 2.1.4): is it enough to replace the .dll in the vm by these from  http://aybabtu.com/rmh/wined3d/? by this i get direct3d-support, but the vm crashes very often while entering or exiting 3d-mode (i assume that is what is just is for now).

the patches provided here: they are for the additions as i see, do they improve the stability or what are they for? how can i build my own additions myself with these patches (is there anywhere a wiki-entry for building additions?) or are there anywhere prebuild additions from latest trunk? will these patches be included in trunk/next vbox-release?

and finally :) is there some progress in making things more stable or is this currently stalled, finishing up more important things?

thanks for your answers!

comment:60 follow-up: ↓ 61 Changed 5 years ago by ajmas

Does anyone have any issues with me posting instructions on how to install WineD3D in the "Windows Guests", warning of its "work in progress" status? I would essentially be repeating the instructions mentioned in comment 47.

comment:61 in reply to: ↑ 60 Changed 5 years ago by rmh

Replying to ajmas:

Does anyone have any issues with me posting instructions on how to install WineD3D in the "Windows Guests", warning of its "work in progress" status? I would essentially be repeating the instructions mentioned in comment 47.

I'm fine with that, but the instructions in comment 47 are wrong. The right instructions are:

  • Get a working OpenGL setup (this is documented elsewhere)
  • Get/mount the latest wined3d build from  http://aybabtu.com/rmh/wined3d/
  • Reboot in safe mode and run the installer

comment:62 follow-ups: ↓ 63 ↓ 64 Changed 5 years ago by rmh

This bug got a bit confusing. It has lots of disconnected information. I rechecked it, and aside from a few comments asking for user help (please use the forums!), I found the following relevant tasks where attention is needed:

  • Discussion about using ReactOS' opengl32.dll to provide d3d7 support. I would suggest opening a new bug, although I'm not particularly interested in pushing for this one myself.
  • Improving the installer builds I'm providing ( http://aybabtu.com/rmh/wined3d/). The most significant problem there is that the installer should detect when it's not being run in safe mode. When the install process depends on a race, user support can be a PITA. This doesn't belong in either BTS though, feel free to contact me directly if you can help.

I would recommend that this bug is closed. Direct3D support is already provided by using a third party add-on (WineD3D). Some improvements can be done on VirtualBox side and some can be done in Wine side, but it'll be much easier to track them as separate issues IMO.

comment:63 in reply to: ↑ 62 Changed 5 years ago by rmh

Replying to rmh:

  • Improving the installer builds I'm providing ( http://aybabtu.com/rmh/wined3d/). The most significant problem there is that the installer should detect when it's not being run in safe mode. When the install process depends on a race, user support can be a PITA. This doesn't belong in either BTS though, feel free to contact me directly if you can help.

Btw, this is done now, starting with the 1.1.17 builds.

comment:64 in reply to: ↑ 62 ; follow-up: ↓ 66 Changed 5 years ago by remco47

Replying to rmh:

This bug got a bit confusing.

I'm confused too. On which Windows guests does this patch work? Does it work on XP, Vista, 7? Does it work on 32bit, 64bit?

And will VirtualBox eventually make this work as easily as OpenGL?

comment:65 follow-up: ↓ 67 Changed 5 years ago by ajmas

There is a forum thread for anyone wanting support information, with regards to WineD3D on VirtualBox:

 http://forums.virtualbox.org/viewtopic.php?f=2&t=15436

BTW rmh, is there any chance you could indicate the version number of the latest version of WineD3D on the  http://www.nongnu.org/wined3d/ page. This should help users with feedback and issue reporting.

comment:66 in reply to: ↑ 64 Changed 5 years ago by rmh

Replying to remco47:

Replying to rmh:

This bug got a bit confusing.

I'm confused too. On which Windows guests does this patch work?

It's no patch. There were some patches which are being merged in official Wine tree. As new releases of Wine come out, they'll have other improvements that benefit VirtualBox, but this is a constant process.

Does it work on XP, Vista, 7?

I only tested it on XP. It should work on Vista/7 too, although it might give trouble with Aero (specially if DX10 is used).

Does it work on 32bit, 64bit?

i386 only. For amd64 support a mingw64 toolchain is needed, which is in experimental stage now, and so is amd64 support in wine. Intel 64 (Itanium) is out of the question.

And will VirtualBox eventually make this work as easily as OpenGL?

I hope so. I proposed this patch which will make it very easy to install WineD3D on a VirtualBox guest:

 http://www.virtualbox.org/ticket/3639

but I haven't received response from VirtualBox maintainers yet (such things can take time to evaluate).

comment:67 in reply to: ↑ 65 Changed 5 years ago by rmh

Replying to ajmas:

There is a forum thread for anyone wanting support information, with regards to WineD3D on VirtualBox:

 http://forums.virtualbox.org/viewtopic.php?f=2&t=15436

Nice. Note you don't need to install Microsoft DirectX (WineD3D replaces it).

BTW rmh, is there any chance you could indicate the version number of the latest version of WineD3D on the  http://www.nongnu.org/wined3d/ page. This should help users with feedback and issue reporting.

Sorry, the builds are automated and changing the website would be a bit cumbersome. Currently, you can check the version by browsing the public directory (there's a link) or simply by reading the text when you run the installer.

Perhaps we could include the version string when registering the install (so it displays in Add/Remove apps dialog). But please use the Savannah BTS to discuss such things.

comment:68 follow-up: ↓ 69 Changed 5 years ago by cruiseoveride

The 1.1.20 release from  http://www.nongnu.org/wined3d/ doesnt seem to pass the dxdiag tests. Vbox complains about something to do with 16bit/32bit colour. Then dxdiag dies.

Using ATi catalyst 9.4 on the host.

comment:69 in reply to: ↑ 68 Changed 5 years ago by rmh

Replying to cruiseoveride:

The 1.1.20 release from  http://www.nongnu.org/wined3d/ doesnt seem to pass the dxdiag tests.

It does for me, but only with guest additions from Vbox 2.1.4, not 2.2.0.

comment:70 follow-up: ↓ 71 Changed 5 years ago by rmh

Btw can this bug be closed? WineD3D builds for VirtualBox are available now, and this bug entry only makes people use it as a dumping zone for bug reports that would belong elsewhere (as standalone reports here, or in winehq).

comment:71 in reply to: ↑ 70 ; follow-up: ↓ 72 Changed 5 years ago by JeremyVisser

Replying to rmh:

Btw can this bug be closed?

I agree. While the original intention of this bug report was for it to be included with the Guest Additions, I think that will happen inevitably anyway when they are sufficiently mature. Future problems and polishing issues should definitely go in other bug reports.

comment:72 in reply to: ↑ 71 ; follow-up: ↓ 73 Changed 5 years ago by rmh

Replying to JeremyVisser:

I agree. While the original intention of this bug report was for it to be included with the Guest Additions, I think that will happen inevitably anyway when they are sufficiently mature. Future problems and polishing issues should definitely go in other bug reports.

I don't think WineD3D belongs in Guest Additions, it's a userland library that sits on top of OpenGL, not something intimately tied to VirtualBox emulated hardware. There's no point in tiing it to the VirtualBox release engineering process, that would only archieve that users of an old VirtualBox will also use old WineD3D.

comment:73 in reply to: ↑ 72 ; follow-up: ↓ 74 Changed 5 years ago by JeremyVisser

Replying to rmh:

I don't think WineD3D belongs in Guest Additions, it's a userland library that sits on top of OpenGL.

From a user experience (completely non-technical) point of view, the distinction between the Guest Additions and WineD3D (and thus OpenGL and Direct3D) is a very artificial one. VirtualBox is very big on breaking down artificial barriers between technologies -- hence the Seamless Mode, which allows your Windows apps to run in harmony with your Linux desktop (and vice versa, I believe).

OpenGL and Direct3D is another such barrier that the user should not have to think about or distinguish between. It should be...seamless.

comment:74 in reply to: ↑ 73 Changed 5 years ago by rmh

Replying to JeremyVisser:

Replying to rmh:

I don't think WineD3D belongs in Guest Additions, it's a userland library that sits on top of OpenGL.

From a user experience (completely non-technical) point of view, the distinction between the Guest Additions and WineD3D (and thus OpenGL and Direct3D) is a very artificial one. VirtualBox is very big on breaking down artificial barriers between technologies -- hence the Seamless Mode, which allows your Windows apps to run in harmony with your Linux desktop (and vice versa, I believe).

OpenGL and Direct3D is another such barrier that the user should not have to think about or distinguish between. It should be...seamless.

You're comparing apples and oranges. Being seamless to install has nothing to do with coupling WineD3D with with the VirtualBox guest drivers. There are many ways in which install of both things can be automated without the user having to notice anything about it.

comment:75 Changed 5 years ago by ajmas

The way I see it, is that while the effort done on WineD3D has been put into providing VirtualBox with support for Direct3D, the WineD3D MS-Windows DLL can easily be used in other contexts. These contexts would include another VM solution, or even a host MS-Windows installation.

At the same time while having WineD3D available as part of the Guest Additions is attractive, as RMH says, the development of WineD3D is independent to the build cycle of VirtualBox. This suggests there may be a third possibility that could be offered: Contributed Guest Additions, with net install. This would allow the user to be able to get certain extra additions without being limited by VirtualBox's build cycle. Think of this in the same way as the relationship between Firefox and the extensions available for it.

comment:76 Changed 5 years ago by ajmas

Just for note, I have opened ticket  3904 for the discussion of the concept I suggest in the previous comment, independent to WineD3D, in case there is any interest in it.

comment:77 Changed 5 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed

Let's continue the discussion there then.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use