Presently, if an ATI card uses open-source DRI drivers from the Mesa project ( http://dri.freedesktop.org/wiki/ATI ), Wine will report it to Windows applications as being some generic nVIDIA model, based on D3D capabilities of the card.
This patch adds detection of the used ATI video card, based on Mesa DRI module name, which is returned by drivers in GL Renderer string. In my opinion, returning even an approximate ATI card model should be better, than the present condition, disguising the ATI card as some equally generic model from nVIDIA. Also, the patch adds detection of VENDOR_MESA
from GL Renderer string, as Mesa DRI drivers may have various things as
GL Vendor, but the GL Renderer name always contains the string "Mesa". This patch resolves the bug #7267, "Lineage 2 complains about outdated NVIDIA drivers using ATI card with Mesa drivers" - http://bugs.winehq.org/show_bug.cgi?id=7267 .
The idea behind the whole code is that we detect a 'compatible' card based on the OpenGL capabilites. That stuff is done using the D3DX_CAPABLE() macros. The extension I check directly correspond to D3D functionality. In the end the result is further refind by checking the opengl renderer string.
The reason why it is all done this way is because we need to detect the card based on OpenGL / GLX information and they don't export the pci id (which is good) but bad for D3D. Retrieving the real card name and so on from /proc or whatever isn't guaranteed to get good results and it also doesn't scale with remote X and if the system uses multiple videocards. It is very tricky.
I would really ask you to use the D3DX_CAPABLE() macros as not using them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension.
The reason we default to Nvidia cards is that they are very generic and have quite solid drivers, so from an application point of view that is nice. Second games don't really need the exact GPU but they just use the info to get an impression of the features / performance. You can debate whether reporting Nvidia or ATI on totally different drivers matters (I would say no).
So at least use the D3DX_CAPABLE macros as those are correct.
Roderick
Roderick Colenbrander wrote:
I would really ask you to use the D3DX_CAPABLE() macros as not using them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension.
You certainly do have a point. I will redo the patch a bit later, but before that, I have a couple of questions.
1) Checking real capabilities surely can be a good way to approximate the level of used hardware. But could these D3DX_CAPABLE() macros be considered reliable enough to use just them alone (and not the DRI module names) for conceiving the card model? If this is so, then checking of the Mesa renderer string could remain only for detection that the card is from ATI (because it does not give any precise info anyway).
2) Are there any plans to add D3D9B_CAPABLE and D3D9C_CAPABLE (and maybe D3D10_CAPABLE too)? These would immensely help to identify the newer cards. Currently, without such macros, the detection code can't safely report that a card is anything more than the ATI's Direct3D 9 lowest-common denominator, Radeon 9500. (See http://en.wikipedia.org/wiki/Radeon for a table of models and their DirectX versions).
Thanks for the reply, Roman.
Roderick Colenbrander wrote:
I would really ask you to use the D3DX_CAPABLE() macros as not using
them can result in bad problems. E.g. a game assuming a certain d3d functionality is there while it isn't backed by any GL extension.
You certainly do have a point. I will redo the patch a bit later, but before that, I have a couple of questions.
- Checking real capabilities surely can be a good way to approximate
the level of used hardware. But could these D3DX_CAPABLE() macros be considered reliable enough to use just them alone (and not the DRI module names) for conceiving the card model? If this is so, then checking of the Mesa renderer string could remain only for detection that the card is from ATI (because it does not give any precise info anyway).
I have done a lot of tests to come to this list of extensions and it is quite good. So the purpose of the macros is to get an impression of what roughly the d3d capabilities of a card are and using GL info (vendor / renderer string) a more exact match is found. But this is not needed. Also note that thanks to this mechanism even if the card isn't known it is at least reported as a card with the same minimum requirements. (A geforce10 or whatever would default to some basic d3d9 card but that is better than nothing)
- Are there any plans to add D3D9B_CAPABLE and D3D9C_CAPABLE (and maybe
D3D10_CAPABLE too)? These would immensely help to identify the newer cards. Currently, without such macros, the detection code can't safely report that a card is anything more than the ATI's Direct3D 9 lowest-common denominator, Radeon 9500. (See http://en.wikipedia.org/wiki/Radeon for a table of models and their DirectX versions).
D3d10 support is relatively easy to add (check for the geometry shader extension) but only nvidia exports that yet. Checking for d3d9b/d3d9c is more complicated as the differences lie in the number of shader constants and things like that. Perhaps I will extend it with that but I need to dive back into the numbers (some drivers aren't clear about their specifications and that makes it hard)
Note that d3d10 doesn't export the gpu capabilities and device name anymore, so it is only needed for <=d3d9.
Roderick
-
Roderick Colenbrander -
Roman Mamedov