I started this page during a frustrating nightly debugging session trying to isolate a driver issue in a MacOS driver. It describes a general approach how to debug an issue in a Game or any other application that uses Direct3D.
Is it a D3D Bug ?
The first question is if the bug is actually caused by Direct3D. Many crashes can result from any part of Wine, even broken graphics could come from incorrect file loading. To find a bug it is essential to locate the component it is located in.
A good way to test this is to test the application with WineD3D compiled for Win32 on Windows. wined3d.dll, d3d8.dll and d3d9.dll can be compiled for Win32 using mingw. ddraw.dll does not yet work unfortunately (refer to WineD3DOnWindows for details). If it still works, chances are that the bug is not in d3d. If it doesn't, the issue is most likely in WineD3D.
Driver bug vs Wine bug
Wine sits only in the middle of the game and the graphics driver. If the graphics driver is broken, Wine can't fix that. If a game runs on one card, but not on another, it can be, but does not have to be a bug in the driver. A card may trigger a broken codepath in WineD3D. Then the app runs on one card only, but not on the others, but the fault is still in WineD3D.
A useful test is to disable extensions on both cards. This can be done in directx.c, by commenting out lines on top of the table. Disable extensions that exist on the broken card, but not on good ones to prevent WineD3D from entering broken specialized codepaths. Disable specialized extensions on the good card to find out if a general codepath is broken and only the general one works. Disabling extensions may also isolate real driver issues.
When the feature is isolated, it has to be checked that WineD3D's behavior is according to the specification. If it is, try to isolate the problem in a stand alone OpenGL test application and report to the graphics driver. Otherwise, WineD3D is broken.
Capability flag problems
If an application does not work, WineD3D could execute the commands the application is calling incorrectly. Or WineD3D reports bad capability flags(see directx.c, IWineD3DImpl_GetDeviceCaps) or return values which cause the application to run into a broken codepath. PIX for Windows from the DirectX sdk is helpful to isolate this. It allows to record call logs similar to +d3d9 logs for D3D9 apps. Those can be compared to a +d3d9 log. If the application behaves differently, it can be a capability flag problem.
Note: Applications are often only aware of ATI and Nvidia cards, and caps from other drivers confuse them. Especially the reference rasterizer confuses applications. Some applications have been found to be broken in the reference rasterizer in the same way as they were on Wine.
Many more typical issues need descriptions. Vertex vs fragment processing issues; Crashes; Framebuffer assembly; Texture loading, using textures, texture addressing; State management state tracking issues; Performance problems; Debugging shader problems. Special tools provided by Nvidia, ATI and Apple, ...