GPU detection logic in wined3d

Ken Thomases ken at codeweavers.com
Thu May 5 11:46:24 CDT 2016


Hi,

Now that the WGL_WINE_query_renderer extension is implemented for Mesa and OS X, I want to reconsider the logic for detecting the GPU in wined3d.  See wined3d_adapter_init_gl_caps() and query_gpu_description() in dlls/wined3d/directx.c.

First, let's assume that query_renderer is available and the user has not overridden the vendor or device IDs via the registry:

If query_renderer provides vendor and device IDs, I think that those should carry a lot of weight.  They are almost certainly the real values.  So, if that combination isn't found in wined3d's tables, it should emit a winediag ERR.  We want to update the tables to account for the devices, especially for Macs where there are relatively few GPUs and they're common to a lot of machines.  Currently, the failure to find them is just silently ignored.

If the combination isn't found or if query_renderer provided a vendor but no device, and the vendor is one of the known ones (i.e. from card_vendor_table), then it should be used to constrain the guessing.  Wined3d should not attempt to guess the vendor.  Currently, the vendor provided by query_renderer is just ignored in that case.

If query_renderer provides a device ID but no vendor, then that's basically useless and should be ignored.

If the user has overridden both the vendor and device in the registry but that combination is not in the tables, then we should go back to the values from query_renderer.  Basically, this is user error to specify useless values in the override and it should be ignored.  Currently, the overrides replace the values from query_renderer and they are lost.

If the user has overridden just the vendor, then it should be used iff it's one of the known ones.  This is the user telling us the vendor of their GPU.  If it doesn't match the vendor provided by query_renderer, then any device provided by query_renderer should be ignored.  It doesn't make sense to combine a device ID from one vendor with a different vendor.  Wined3d will have to guess the device.

If the user has overridden just the device, then it should be used with the vendor from query_renderer.  If that combination is not found, then it should be ignored.  The user presumably saw on some previous occasion that wined3d determined the right vendor but the wrong device and just corrected the device.  If the combination is not found, then either the vendor has changed or the user did it wrong by specifying a device that's not known to wined3d.


If people (mostly Henri) generally like the above proposed logic, I can work up a patch.

-Ken




More information about the wine-devel mailing list