Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project. - Dan
Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project.
- Dan
On Windows the main task of dxdiag is to show some diagnostic info and to run some very basic network, sound and 3d tests. In case of Wine 3D testing would be the most important feature but I'm not sure if it is that useful. There are various causes of slowness e.g. no 3d drivers installed, indirect rendering, driver bugs (e.g. fglrx falling back to indirect rendering due to virtual memory issues in Wine), the use of a composition manager and more. Most of this information can't be retrieved using Win32 APIs or we would need internal APIs.
I think it would be better to write a 'wine3ddiag' script which uses glxinfo, glxgears and which can also check if lets say compiz is running.
Roderick
On Sunday 28 December 2008 03:02:34 am Roderick Colenbrander wrote:
On Windows the main task of dxdiag is to show some diagnostic info and to run some very basic network, sound and 3d tests. In case of Wine 3D testing would be the most important feature but I'm not sure if it is that useful. There are various causes of slowness e.g. no 3d drivers installed, indirect rendering, driver bugs (e.g. fglrx falling back to indirect rendering due to virtual memory issues in Wine), the use of a composition manager and more. Most of this information can't be retrieved using Win32 APIs or we would need internal APIs.
I think such a thing could still be useful. It'll help figure out what kind of info apps are getting from a given system, and help determine if problems are app-specific or more general system/wine-related. It can also serve as a basic interactive test bed for various DX functionality that even users can run and look at, instead of being delegated to the wine test suite only. Plus it can check DirectPlay and DirectSound (a couple other components prone to errors), instead of just Direct3D/DirectDraw.
Chris Robinson <chris.kcat <at> gmail.com> writes:
I think such a thing could still be useful. It'll help figure out what kind of info apps are getting from a given system, and help determine if problems are app-specific or more general system/wine-related. It can also serve as a basic interactive test bed for various DX functionality that even users can run and look at, instead of being delegated to the wine test suite only. Plus it can check DirectPlay and DirectSound (a couple other components prone to errors), instead of just Direct3D/DirectDraw.
Wine needs a dxdiag.exe as some apps expect it to be present, like for example GameShadow. I once gave it a shot already, see http://bugs.winehq.org/show_bug.cgi?id=14118. A builtin dxdiag.exe would aslo be nice addition to wine imo.
2008/12/28 Dan Kegel dank@kegel.com:
Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project.
- Dan
If the student in question is capable, sure. Like Chris already mentioned, I think the main use of such an application would be dumping information like supported caps, texture formats, etc in case of D3D and supported extensions, pixelformats, various limits, drivers strings, etc. for OpenGL. It would probably also be useful to dump some registry settings, like anything under HKCU\Software\Wine\Direct3D. We could add some tests to see if basic D3D is working, but on its own I don't think that adds much over glxinfo & glxgears.
On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet hverbeet@gmail.com wrote:
... I think the main use of such an application would be dumping information like supported caps, texture formats, etc in case of D3D and supported extensions, pixelformats, various limits, drivers strings, etc. for OpenGL.
OK. Can you list the main Win32 API calls you'd like such an app to use to retrieve information?
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
We could add some tests to see if basic D3D is working, but on its own I don't think that adds much over glxinfo & glxgears.
Ah, but it's easy and fun :-) Maybe they could throw in a shader test or something... - Dan
2008/12/28 Dan Kegel dank@kegel.com:
On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet hverbeet@gmail.com wrote:
... I think the main use of such an application would be dumping information like supported caps, texture formats, etc in case of D3D and supported extensions, pixelformats, various limits, drivers strings, etc. for OpenGL.
OK. Can you list the main Win32 API calls you'd like such an app to use to retrieve information?
For d3d9 that would probably be IDirect3D9::CheckDeviceFormat(), IDirect3D9::CheckDeviceMultiSampleType(), IDirect3D9::EnumAdapterModes(), IDirect3D9::GetAdapterIdentifier() and IDirect3D9::GetDeviceCaps(). Ddraw and d3d8 should have similar methods, I'm not completely sure about dxgi/d3d10.
For OpenGL there's DescribePixelFormat(), and glGetString() with various constants like GLRENDERER, GL_VENDOR, GL_VERSION and GL_EXTENSIONS. Limits are usually retrieved with glGetIntegerv() or glGetFloatv() and an appropriate constant.
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
I don't know, but if I were to guess I'd say it probably doesn't get that information from d3d, but from gdi32 or winex11.drv.
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
I don't know, but if I were to guess I'd say it probably doesn't get that information from d3d, but from gdi32 or winex11.drv.
I think it is a resource string in winex11.drv.
Concerning this topic, there are some apps that try to load the nvidia/ati specific driver files, and have vendor specific strings. City of Heroes tried to find nvogl.dll(or similar, don't remember exactly). I don't know what it tried to do with it, but this could potentially be a bigger problem than just a string in dxdiag.
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
I don't know, but if I were to guess I'd say it probably doesn't get that information from d3d, but from gdi32 or winex11.drv.
I think it is a resource string in winex11.drv.
Concerning this topic, there are some apps that try to load the nvidia/ati specific driver files, and have vendor specific strings. City of Heroes tried to find nvogl.dll(or similar, don't remember exactly). I don't know what it tried to do with it, but this could potentially be a bigger problem than just a string in dxdiag.
Most likely it attempted to load the OpenGL ICD driver directly and that way avoid using opengl32.dll / gdi32.dll.
Roderick
On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet hverbeet@gmail.com wrote:
... I think the main use of such an application would be dumping information like supported caps, texture formats, etc in case of D3D and supported extensions, pixelformats, various limits, drivers strings, etc. for OpenGL.
OK. Can you list the main Win32 API calls you'd like such an app to use to retrieve information?
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it.
Roderick
On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it.
OK, alternately, where should Wine's dxdiag.exe get that info? - Dan
On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag?
Native dxdiag is checking the name of the display driver which in our
case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it.
OK, alternately, where should Wine's dxdiag.exe get that info?
- Dan
The best thing would be to get it from the same place as Windows is doing but as mentioned that might not be good right now. Direct3D has info on the card we are emulating (it has emulated pci ids) but right now we only report a generic renderer string. At the moment the best way is to get this info from opengl. (glGetString(GL_RENDERER)
Roderick
I think we should stay as close to the way the windows tools work and avoid inventing too much wine-specific things. This is how I understand the windows tools:
* dxdiag.exe: Prints DLL information, has very simple tests for ddraw, d3d, dsound, dmusic, dplay. The tests just show that a device can be created and a cube can be rendered. This could detect if the opengl libs are missing, but it won't be able to tell direct rendering from indirect rendering. (really dxdiag can't say so via the win32 API).
*) dxcapsviewer.exe: This app lists all the capability flags advertised for ddraw, d3d8, dsound, etc. It is part of the dx sdk, but I don't see a problem with implementing it. Sooner or later we'll clone other tools from the dx sdk too, like vsa.exe, psa.exe and fxc.exe(shader assemblers and compiler)
Another feature idea is to enable ddraw, d3d8 and d3d9 to import a capability flag dump from dxcapsviewer to advertise exactly the same flags as on Windows. This can help to debug capability flag problems.
*) pixwin.exe is interesting too. It allows to record something similar to a +d3d9 trace on Windows, and save it for playback. The native version currently doesn't work on wine, but I think it is fixable. A similar tool could be useful to (1) see if a log recorded on windows produces the same output on Wine, and (2) to see if a windows app performs the same calls on Wine as it does on Windows(to detect caps problems for example)
On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < thunderbird2k@gmx.net> wrote:
Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it.
I'm not sure if this is exactly the same string you're looking at, but Fallout 3 currently requires a hack for the display driver information or it will just crash when you try to start a game ( http://bugs.winehq.org/show_bug.cgi?id=15839).
Erich Hoover ehoover@mines.edu
On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < thunderbird2k@gmx.net> wrote:
Native dxdiag is checking the name of the display driver which in our
case
winex11.drv and I guess this is just the identifier of Winex11.drv.
Inside
winex11.drv we don't really have the knowledge about the 3d hardware we
are
emulating. In the end we might need to duplicate some card detection
code
inside winex11.drv and show a real driver name like the Nvidia or ATI
ones.
It would be a lot of work and only be worth if apps really need it.
I'm not sure if this is exactly the same string you're looking at, but Fallout 3 currently requires a hack for the display driver information or it will just crash when you try to start a game ( http://bugs.winehq.org/show_bug.cgi?id=15839).
Erich Hoover ehoover@mines.edu
This is part of the info which we aren't reporting properly right now. Actually the best thing is to report a fake card and drivers as some games use this info to work around driver bus. Other class of programs are too stupid and need 100% correct info. Fallout3 is one of those cases. The registry changes are more or less fine.
Roderick
On Sunday 28 December 2008 07:43:57 am Roderick Colenbrander wrote:
Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it.
Are there any X functions that winex11.drv can use to get the strings used for a particular screen? Eg. in xorg.conf, I have:
Section "Device" ... Identifier "Card0" Driver "nvidia" VendorName "nVidia Corporation" BoardName "NV80 [GeForce 8600 GT]" EndSection
Section "Screen" Identifier "Screen0" Device "Card0" ... EndSection
I can't imagine that being inaccessible by X apps.. and I believe I've seen some apps report this info. It's something gdi32/user32 can then get for a particular screen/adapter by calling into winex11.drv (if not also something wined3d can use), instead of reporting "X Windows" for the card name.
I can't imagine that being inaccessible by X apps.. and I believe I've seen some apps report this info. It's something gdi32/user32 can then get for a particular screen/adapter by calling into winex11.drv (if not also something wined3d can use), instead of reporting "X Windows" for the card name.
I'm not sure, but I wouldn't expect these settings to be readable via some X11 API. There are X servers without an X config like that, e.g. the MacOS X server, or Windows X servers
On Sunday 28 December 2008 07:43:57 am Roderick Colenbrander wrote:
Native dxdiag is checking the name of the display driver which in our
case
winex11.drv and I guess this is just the identifier of Winex11.drv.
Inside
winex11.drv we don't really have the knowledge about the 3d hardware we
are
emulating. In the end we might need to duplicate some card detection
code
inside winex11.drv and show a real driver name like the Nvidia or ATI
ones.
It would be a lot of work and only be worth if apps really need it.
Are there any X functions that winex11.drv can use to get the strings used for a particular screen? Eg. in xorg.conf, I have:
Section "Device" ... Identifier "Card0" Driver "nvidia" VendorName "nVidia Corporation" BoardName "NV80 [GeForce 8600 GT]" EndSection
Section "Screen" Identifier "Screen0" Device "Card0" ... EndSection
I can't imagine that being inaccessible by X apps.. and I believe I've seen some apps report this info. It's something gdi32/user32 can then get for a particular screen/adapter by calling into winex11.drv (if not also something wined3d can use), instead of reporting "X Windows" for the card name.
Those strings were just generated by the tool which created your xorg.conf. These fields are only internal to X. Some of the info can be obtained from X. For instance I requested support for pci id reading in the nvidia drivers and that was added recently. I plan to work on that early next year.
Roderick
On Sa, 2008-12-27 at 23:20 -0800, Dan Kegel wrote:
Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program?
I think, that's a good Idea. When you ask a question in a Game related forum, you get most times a request for the logs of msinfo.exe and dxdiag.exe
And in addition to the DX7, DX8 and DX9 rendering tests, we could add - OpenGL rendering test - GDI32 rendering test - DX10 rendering test - the framerate for all rendering tests
Louis wrote:
Wine needs a dxdiag.exe as some apps expect it to be present, like for example GameShadow. I once gave it a shot already, see http://bugs.winehq.org/show_bug.cgi?id=14118
Thanks for the link. I refreshed your patch, and also added in the parsing for the commandline options used by GameShadow. That game needs a lot of overrides, and I never got it to run far enough to check the output of dxdiag. Does anyone know of other apps that require dxdiag.exe (as opposed to dxdiagn.dll)? - Dan
-
Chris Robinson -
Dan Kegel -
Detlef Riekenberg -
Erich Hoover -
Henri Verbeet -
Louis Lenders -
Roderick Colenbrander -
Stefan Dösinger