http://bugs.winehq.org/show_bug.cgi?id=33552
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Summary|Dragon Age 2 doesn't detect |BioWare 'DragonAge2Config' |my graphic card VRAM and |tool doesn't detect |driver |graphics card VRAM properly Ever Confirmed|0 |1
--- Comment #11 from Anastasius Focht focht@gmx.net 2013-12-06 08:08:58 CST --- Hello Henri
--- quote --- Most of the actual APIs like IDirectDraw7::GetAvailableVidMem() and IDirect3DDevice9::GetAvailableTextureMem() return a number of bytes in a DWORD or UINT, which should work up to about 4 GiB. --- quote ---
it seems the tool uses more than one method to query the card properties (device name, -id, description, manufacturer, refresh rate, resolution, vram) ... from a quick glance:
- WMI - DXGI - dxdiag - DirectDraw/D3D9
For example WMI:
--- snip --- ... trace:wbemprox:wbem_services_ExecQuery 0x1fabc8, L"WQL", L"SELECT * FROM Win32_VideoController", 0x00000030, (nil), 0xe1cbb8 trace:wbemprox:grab_table returning 0x7c780230 trace:wbemprox:parse_query wql_parse returned 0 fixme:win:EnumDisplayDevicesW ((null),0,0xe1c100,0x00000000), stub! trace:wbemprox:fill_videocontroller created 1 rows trace:wbemprox:EnumWbemClassObject_create (nil), 0xe1cbb8 trace:wbemprox:EnumWbemClassObject_create returning iface 0x1cc2d0 trace:wbemprox:enum_class_object_Next 0x1cc2d0, -1, 1, 0xe1cbb0, 0xe1cbb4 trace:wbemprox:create_class_object L"Win32_VideoController", 0xe1cbb0 trace:wbemprox:create_class_object returning iface 0x1cc2e8 trace:wbemprox:class_object_Get 0x1cc2e8, L"PNPDeviceID", 00000000, 0xe1cba0, (nil), (nil) trace:wbemprox:class_object_Get 0x1cc2e8, L"AdapterRAM", 00000000, 0xe1cb88, (nil), (nil) trace:wbemprox:enum_class_object_Next 0x1cc2d0, -1, 1, 0xe1cbb0, 0xe1cbb4 trace:wbemprox:wbem_services_Release destroying 0x1fabc8 trace:wbemprox:wbem_locator_Release destroying 0x1fa950 fixme:win:EnumDisplayDevicesW ((null),0,0xe1db30,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\.\DISPLAY1",0,0xe1c8b4,0x00000000), stub! trace:wbemprox:class_object_Release destroying 0x1cc2e8 trace:wbemprox:enum_class_object_Release destroying 0x1cc2d0 ... --- snip ---
--- snip --- Wine-dbg>b fill_videocontroller
Wine-dbg>p desc {Description={0x4e, 0x56, 0x49, 0x44, 0x49, 0x41, 0x20, 0x47, 0x65, 0x46, 0x6f, 0x72, 0x63, 0x65, 0x20, 0x38, 0x38, 0x30, 0x30, 0x20, 0x47, 0x54, 0x58, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, VendorId=0x10de, DeviceId=0x191, SubSysId=0, Revision=0, DedicatedVideoMemory=0x7a200000, DedicatedSystemMemory=0, SharedSystemMemory=0, AdapterLuid={LowPart=0x3f6, HighPart=0}} --- snip ---
-> 2048917504
The WMI value seems to be ignored/skipped for some reason.
In "dxdiag" case it queries "szDisplayMemoryEnglish" property as "2048.9 MB" and converts this to float and later back to int?
At one point it calls StrFormatByteSizeW() API (non-overflow case with 1953 MiB)
--- snip --- 0024:Call shlwapi.StrFormatByteSizeW(7ffe6680,00000000,00921ad8,00000020) ret=00437ef8 0024:Call KERNEL32.GetLocaleInfoW(00000400,20000012,0033f4ec,00000002) ret=7e7491a6 0024:Ret KERNEL32.GetLocaleInfoW() retval=00000002 ret=7e7491a6 0024:Call KERNEL32.GetLocaleInfoW(00000400,20001010,0033f4ec,00000002) ret=7e7491cf 0024:Ret KERNEL32.GetLocaleInfoW() retval=00000002 ret=7e7491cf 0024:Call KERNEL32.GetLocaleInfoW(00000400,0000000e,0033f4d8,00000008) ret=7e7491fd 0024:Ret KERNEL32.GetLocaleInfoW() retval=00000002 ret=7e7491fd 0024:Call KERNEL32.GetLocaleInfoW(00000400,0000000f,0033f4c8,00000008) ret=7e749222 0024:Ret KERNEL32.GetLocaleInfoW() retval=00000002 ret=7e749222 0024:Call KERNEL32.GetLocaleInfoW(00000400,00000010,0033f40c,00000040) ret=7e749267 0024:Ret KERNEL32.GetLocaleInfoW() retval=00000004 ret=7e749267 0024:Call KERNEL32.GetNumberFormatW(00000400,00000000,0033f500 L"1.990000",0033f4e8,00921ad8,00000020) ret=7e749501 0024:Ret KERNEL32.GetNumberFormatW() retval=00000005 ret=7e749501 0024:Ret shlwapi.StrFormatByteSizeW() retval=00921ad8 ret=00437ef8 0024:Call user32.SetWindowTextW(000100b2,00921ad8 L"1.99 GB") ret=00437f21 0024:Call window proc 0x4a7b85 (hwnd=0x100b2,msg=WM_SETTEXT,wp=00000000,lp=00921ad8) --- snip ---
0x7FFE6680,0x00000000 = 2147378816
--- snip --- Address Hex dump UNICODE 00963D40 31 00 2E 00|39 00 39 00|20 00 47 00|42 00 00 00| 1.99 GB. --- snip ---
For the overflow case:
--- snip --- 0009:trace:shell:StrFormatByteSizeW (0xffffffff80000000,0x9592d8,32) --- snip ---
0x80000000,0xFFFFFFFF = -2147483648
--- snip --- Address Hex dump UNICODE 00963EF0 2D 00 32 00|31 00 34 00|37 00 34 00|38 00 33 00| -2147483 00963F00 36 00 34 00|38 00 20 00|62 00 79 00|74 00 65 00| 648 byte 00963F10 73 00 00 00| s. --- snip ---
Not sure where this integer overflow comes from. Maybe some internal conversion went wrong.
Another thing I noticed the tool tries to match (dx) device id from multiple query sources (dxgi, wmi, ...) and this somehow doesn't work out. Maybe there is an inconsistency (incomplete/fake data) somewhere so the app skips some code paths, discarding some values it earlier retrieved.
Regards