http://bugs.winehq.org/show_bug.cgi?id=29573
Bug #: 29573 Summary: Battle.net System Check reports zero (0) megabytes of video RAM Product: Wine Version: 1.3.36 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ehoover@mines.edu Classification: Unclassified
I recently got a new computer and I'm looking to update my Battle.net profile. I discovered that my Video RAM is incorrect and I've tried with my memory both at the Wine default and it's actual value (1.5 GB).
Battle.net System Checker Reports: Video Card: NVIDIA GeForce GTX 560 (ID 4609) 0 MB
WINEDEBUG="+d3d" (no VideoMemorySize) trace:d3d:InitAdapters Emulating 1024MB of texture ram
WINEDEBUG="+d3d" (VideoMemorySize = 1536) trace:d3d:InitAdapters Emulating 1536MB of texture ram
http://bugs.winehq.org/show_bug.cgi?id=29573
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #1 from Austin English austinenglish@gmail.com 2012-01-09 14:16:42 CST --- I wouldn't be surprised if it's using wmi to figure out the available video memory instead of directx..
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #2 from Erich Hoover ehoover@mines.edu 2012-01-09 14:39:08 CST --- (In reply to comment #1)
I wouldn't be surprised if it's using wmi to figure out the available video memory instead of directx..
That's what I thought at first, but I couldn't find any evidence of that. It doesn't link to wmi and I couldn't find anything wmi-related in a relay log. I may not know what to look for though. It does dynamically load nvapi, but it doesn't look like it's pulling the video memory from there.
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #3 from Erich Hoover ehoover@mines.edu 2012-01-10 11:31:14 CST --- Oh! I forgot to mention that I also checked to see if the application looked for the video memory in the registry (HardwareInformation.MemorySize) and it does not appear to be looking there either. Clearly it's not using d3d9's GetAvailableTextureMem or d3d7's GetAvailableVidMem or we wouldn't be having this discussion ;)
http://bugs.winehq.org/show_bug.cgi?id=29573
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #4 from Erich Hoover ehoover@mines.edu 2012-09-03 15:43:03 CDT --- Created attachment 41566 --> http://bugs.winehq.org/attachment.cgi?id=41566 Fix for the system checker reporting no RAM
I finally figured out the problem here (see attached patch), apparently this app is VERY picky. Comments are appreciated.
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2012-09-03 16:34:31 CDT --- That probably makes sense. You should use wined3d_get_adapter_identifier() to retrieve both of those though. (And this probably applies to DirectDrawEnumerateA() as well.)
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #6 from Erich Hoover ehoover@mines.edu 2012-09-04 11:38:05 CDT --- Created attachment 41569 --> http://bugs.winehq.org/attachment.cgi?id=41569 Fix for the system checker reporting no RAM [v2]
(In reply to comment #5)
That probably makes sense. You should use wined3d_get_adapter_identifier() to retrieve both of those though. (And this probably applies to DirectDrawEnumerateA() as well.)
How does the attached look? It looks like the DirectDrawEnumerateA callback is incompatible with the DirectDrawEnumerateExA callback, should I maybe make an internal function for both routines to call so that it can handle both?
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2012-09-04 12:19:42 CDT --- (In reply to comment #6)
How does the attached look? It looks like the DirectDrawEnumerateA callback is
Looks ok, though the adapter index is supposed to be unsigned, and I'd probably have done something like this for the loop in there:
for (adapter = 0;; ++adapter) { ... if (FAILED(hr)) break; ... }
incompatible with the DirectDrawEnumerateExA callback, should I maybe make an internal function for both routines to call so that it can handle both?
Maybe, although I'm not sure if it'll end up really being worth it. You could perhaps also do something similar to ddraw_surface4_EnumAttachedSurfaces() and similar functions.
http://bugs.winehq.org/show_bug.cgi?id=29573
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41566|0 |1 is obsolete| | Attachment #41569|0 |1 is obsolete| |
--- Comment #8 from Erich Hoover ehoover@mines.edu 2012-09-04 14:00:31 CDT --- Created attachment 41571 --> http://bugs.winehq.org/attachment.cgi?id=41571 Fix for the system checker reporting no RAM [v3]
(In reply to comment #7)
... Looks ok, though the adapter index is supposed to be unsigned, and I'd probably have done something like this for the loop in there: ...
How about the attached?
... Maybe, although I'm not sure if it'll end up really being worth it. You could perhaps also do something similar to ddraw_surface4_EnumAttachedSurfaces() and similar functions.
Oh, I like that - please see the attached patch. I envision this patch being split into two parts for submission, DirectDrawEnumerateA as part 1/2 and the DirectDrawEnumerateExA as part 2/2, does that sound ok to you?
http://bugs.winehq.org/show_bug.cgi?id=29573
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #9 from Erich Hoover ehoover@mines.edu 2012-09-04 15:20:41 CDT --- Ok, after talking with Henri on IRC and some comments from Bruno Jesus I've submitted a pair of patches to fix this issue: [1/2] http://source.winehq.org/patches/data/89583 [2/2] http://source.winehq.org/patches/data/89584
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #10 from André H. nerv@dawncrow.de 2012-09-15 10:06:43 CDT --- Seems the patches are still NEW...
http://bugs.winehq.org/show_bug.cgi?id=29573
--- Comment #11 from Erich Hoover ehoover@mines.edu 2012-09-15 19:06:05 CDT --- (In reply to comment #10)
Seems the patches are still NEW...
Yup, maybe he'll read them this week? *crosses fingers*
http://bugs.winehq.org/show_bug.cgi?id=29573
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b0cefe897c6dbd846b0525e3f3a | |ab59cae75eb6d Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #12 from Erich Hoover ehoover@mines.edu 2012-09-18 16:04:36 CDT --- Fixed as of commit b0cefe897c6dbd846b0525e3f3aab59cae75eb6d.
http://bugs.winehq.org/show_bug.cgi?id=29573
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2012-09-28 13:44:03 CDT --- Closing bugs fixed in 1.5.14.
-
wine-bugs＠winehq.org