http://bugs.winehq.org/show_bug.cgi?id=27600
Summary: Screen fills with visual artifacts in World of Tanks. Product: Wine Version: unspecified Platform: x86 URL: http://game.worldoftanks.eu/update OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: vincas.miliunas@gmail.com CC: stefan@codeweavers.com
Created an attachment (id=35280) --> (http://bugs.winehq.org/attachment.cgi?id=35280) Output log, but doesn't show anything important.
Time to report an another WINE regression for World of Tanks, in this one screen fills with a mixture of triangles and font textures.
The regression was brought by: commit 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f Author: Stefan Dösinger Date: Tue Apr 19 21:24:26 2011 +0200
wined3d: Give GL_ARB_map_buffer_range another try.
Nvidia's 270.xx.yy driver series fix the glMapBuffer alignment issues that c performance problems. If the user is using an older driver we now drop the V doublebuffered loading, which means that we fall back to the current behavio needed. Dynamic VBOs are needed on Nvidia drivers for GL_ARB_instanced_array
(the patch was actually committed on Jun 14)
The bug can be reproduced by logging in an account and clicking on the depot, store, statistics or other tabs in the garage.
Alt-tabing in and out resets the screen back to normal (using virtual desktop).
During the actual gameplay, the frame rate is a lot lower then normal. Notable fixme for gameplay is: fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting
Using WINEDEBUG=+d3d the frame rate is very low in the garage, the bug does not manifests itself.
Configuration: ATI Radeon HD 3650, fglrx 11.5 DirectDrawRenderer: opengl UseGLSL: disabled
The game is free to download and play - http://game.worldoftanks.eu/update
http://bugs.winehq.org/show_bug.cgi?id=27600
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
http://bugs.winehq.org/show_bug.cgi?id=27600
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at 2011-06-25 19:29:28 CDT --- We may be running into the fglrx bug that motivated disabling ARB_map_buffer_range a year ago. It would be interesting to see if this issue occurs on Nvidia cards as well.
http://bugs.winehq.org/show_bug.cgi?id=27600
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #2 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-06-27 05:36:34 CDT --- The regression was already reported in http://bugs.winehq.org/show_bug.cgi?id=27534
(In reply to comment #1)
We may be running into the fglrx bug that motivated disabling ARB_map_buffer_range a year ago. It would be interesting to see if this issue occurs on Nvidia cards as well.
In the bug 27534 people report this issue with nVidia cards as well.
*** This bug has been marked as a duplicate of bug 27534 ***
http://bugs.winehq.org/show_bug.cgi?id=27600
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|DUPLICATE |
--- Comment #3 from Stefan Dösinger stefandoesinger@gmx.at 2011-06-27 07:01:07 CDT --- *This* bug, as in in the same game? There are two different issues with ARB_map_buffer_range, I think this bug shouldn't be closed as a duplicate yet. Not unless someone can confirm that this specific game is broken on Nvidia too.
http://bugs.winehq.org/show_bug.cgi?id=27600
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35280|application/octet-stream |text/plain mime type| | Attachment #35280|output.log |output.txt filename| |
http://bugs.winehq.org/show_bug.cgi?id=27600
surfing86 surfing86@live.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |surfing86@live.it
--- Comment #4 from surfing86 surfing86@live.it 2011-07-01 16:37:56 CDT --- Vincas Miliūnas, can you post a screenshot of the bug please?
Thank you
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #5 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-07-01 17:27:03 CDT --- Created an attachment (id=35394) --> (http://bugs.winehq.org/attachment.cgi?id=35394) Screenshots of the visual corruption
It's not easy to capture, because after losing window focus, it resets back to normal.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #6 from Stefan Dösinger stefandoesinger@gmx.at 2011-07-01 18:02:03 CDT --- I didn't yet get around to writing a test to see if we can isolate this problem in fglrx. If anyone wants to do so, this would be the first test setup I'd try:
1) Create a big VBO(probably 4*sizeof(float)*65536), and a second one with 65536 float3s with position data. Maybe even try a bigger buffer. 2) Fill the VBO with float4(1, 0, 0, 0), red 3) Draw something with the two FBOs to make the driver load them(using an indexed draw to force the driver to load the entire buffer) 4) call glFinish() 5) Map the color FBO with MAP_UNSYNCHRONIZED_BIT | MAP_FLUSH_EXPLICIT_BIT 6) Fill the buffer with float4(0, 1, 0, 0), green 7) flush the entire range 8) Unmap it 9) Draw a quad with it using an indexed draw, try various indices. Of course the position buffer, shader and stream sources have to be set up correctly.
If the driver behaves correctly, the draw will alawys read float4(0, 1, 0, 0) from the color VBO. If the driver misbehaves in the way I suspect it does it will sometimes read float4(1, 0, 0, 0).
http://bugs.winehq.org/show_bug.cgi?id=27600
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #7 from Wylda wylda@volny.cz 2011-07-08 14:54:21 CDT --- (In reply to comment #1)
It would be interesting to see if this issue occurs on Nvidia cards as well.
(In reply to comment #3)
Not unless someone can confirm that this specific game is broken on Nvidia too.
Well although i have the problem with the commit pointed out by comment #0 (see bug 27534), i can't reproduce the graphical problems after clicking on the depot, store, statistics tabs. Everything seems OK here.
Possible differences: * OpenGL renderer string: GeForce GT 240/PCI/SSE2 * OpenGL version string: 3.3.0 NVIDIA 275.09.07 * OpenGL shading language version string: 3.30 NVIDIA via Cg compiler * Debian Squeeze 32bit * wine-1.3.23-192-g39684c7 + Vincas' patches 76056 .. 76065 * WoT v0.6.5 patch (i was forced to update from v0.6.4)
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #8 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-07-17 03:24:47 CDT --- The graphical artifacts were fixed by http://source.winehq.org/git/wine.git/commit/cf421e1b3f29c0df242f43bc235dab1...
However, the noted in the original post performance degradation is still present and it's the same fixme message that comes with the poor performance: fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting
Disabling GL_ARB_map_buffer_range or it's usage fixes the problem.
It also looks like it's present only in some of the maps, because the 1-2fps slowdown occurred only in the second map I played.
http://bugs.winehq.org/show_bug.cgi?id=27600
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Screen fills with visual |Performance degradation of |artifacts in World of |1-2fps in World of Tanks |Tanks. |
http://bugs.winehq.org/show_bug.cgi?id=27600
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Performance degradation of |Performance degradation in |1-2fps in World of Tanks |World of Tanks
http://bugs.winehq.org/show_bug.cgi?id=27600
K1773R K1773R@darkgamex.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |K1773R@darkgamex.ch
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #9 from K1773R K1773R@darkgamex.ch 2011-07-20 00:19:24 CDT --- (In reply to comment #8)
The graphical artifacts were fixed by http://source.winehq.org/git/wine.git/commit/cf421e1b3f29c0df242f43bc235dab1...
However, the noted in the original post performance degradation is still present and it's the same fixme message that comes with the poor performance: fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting
Disabling GL_ARB_map_buffer_range or it's usage fixes the problem.
It also looks like it's present only in some of the maps, because the 1-2fps slowdown occurred only in the second map I played.
disabling GL_ARB_map_buffer_range dosnt fix it for me (still getting huge fps slowdown), there is a patch for that :) http://dl.dropbox.com/u/6901628/remove-GL_ARB_map_buffer_range.patch
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #10 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-07-20 12:26:01 CDT --- (In reply to comment #9)
disabling GL_ARB_map_buffer_range dosnt fix it for me (still getting huge fps slowdown), there is a patch for that :) http://dl.dropbox.com/u/6901628/remove-GL_ARB_map_buffer_range.patch
The ways I knew to get rid of using GL_ARB_map_buffer_range: 1. Remove from the usable extension list (the patch I made you linked, thanks for Stefan for suggesting this) 2. Revert the patch that enabled usage of the extension (git revert --no-edit 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f)
I wasn't aware about the registry as an another option and yet it didn't work for you :P. Good thing the patch helped.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #11 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-08-04 01:10:57 CDT --- The performance degradation is not present using the patch from bug 27534 - 0003-wined3d-disable-dynamic-vertex-buffers.patch
http://bugs.winehq.org/show_bug.cgi?id=27600
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |68b15bc5ffe6ddf5d08cbc13479 | |eaf718ad5e39f
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #12 from Stefan Dösinger stefan@codeweavers.com 2011-12-08 14:36:03 CST --- I've downloaded the game and I'm trying to reproduce this, but so far I am not successful. A few questions:
1) Does the performance problem only occur on fglrx, or is Nvidia affected too? 2) How do you benchmark WoT? Or is the performance drop big enough that simply looking at the rendering is enough to be certain that it is there(or isn't)? 3) If you have precise benchmarks, how big is the drop? Vincas talks about "1-2 fps", K1773R says "huge drop".
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #13 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-12-08 18:26:00 CST --- The new patch 0.7.0 has a replay feature, so now it's also possible to reproduce this issue offline.
Currently it's available in the client of the test server, so one needs to install the test patches from here - http://forum.worldoftanks.eu/index.php?/topic/68358-v70-public-test-4/
I'll give a sample of a replay - http://dl.dropbox.com/u/6901628/20111207_2251_ussr-S-51_lakeville.wotreplay
To run it, one needs to pass the reply file location as parameter - WINEPREFIX=.../wot-test .../wine WorldOfTanks.exe .../20111207_2251_ussr-S-51_lakeville.wotreplay
I use this patch to workaround the issue - http://dl.dropbox.com/u/6901628/disable-dynamic-vertex-buffers.patch
Also the "fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting" message is irrelevant, because in the current configuration it doesn't appear, while the slowdowns are still there.
To reproduce the issue, once the replay is loaded, press left mouse button to enable free look, then turn 20 degrees right from the line where cannon's barrel is pointing at. Having the dynamic vertex buffers disabled (patched) results in smooth 26-30 fps, while having them enabled (no patch) results in 8-10 fps with shuttering.
I use this game configuration (login info was removed) - http://dl.dropbox.com/u/6901628/preferences.xml . It's stored at .../drive_c/users/$USER/Application Data/Wargaming.net/WorldOfTanks
Configuration: AMD Radeon HD 6770, fglrx 11.11 Default WINE registry settings (GLSL enabled), only winetricks corefonts installed.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #14 from K1773R K1773R@darkgamex.ch 2011-12-09 05:19:22 CST --- (In reply to comment #12)
I've downloaded the game and I'm trying to reproduce this, but so far I am not successful. A few questions:
- Does the performance problem only occur on fglrx, or is Nvidia affected too?
- How do you benchmark WoT? Or is the performance drop big enough that simply
looking at the rendering is enough to be certain that it is there(or isn't)? 3) If you have precise benchmarks, how big is the drop? Vincas talks about "1-2 fps", K1773R says "huge drop".
1) i dont know, i only tested it on fglrx (ati sucks...) 2) you can see how many fps you have, if the game is lagging badass there is even an input lag who you can feel. 3) well with patch i got around 30-20 fps (i got a old graphic card), without i had 1-2 or even 0 fps, so for me it is a huge drop. newer graphic cards got more power so the drop isnt so hard (maybe?).
http://bugs.winehq.org/show_bug.cgi?id=27600
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #15 from Alexey Loukianov mooroon2@mail.ru 2012-02-12 07:20:33 CST --- Just FYI: Recently a friend of mine who plays Perfect World MMORPG under Wine had tried to switch from using Wine 1.2.3 into using Wine 1.4-rc2 and sent me a message complaining about major performance drop. I had spent two hours reproducing problem on my rig (Phenom II X4 955, GeForce GTX 550 Ti 1GB VRAM, 6GB RAM, 32bit Linux, nVIDIA drivers 295.17) and then bisecting it. Looks like between 1.2.3 and 1.4-rc2 there had been at least two performance regressions, one of which bissected down to the commit this bug report is about.
Stats are something like this (starting PW in window, maximized on 1680x1050 screen) for game login screen - measurements are as displayed by WINEDEBUG="+fps":
Wine 1.2.3 - FPS ~17 Wine 1.4-rc2 - FPS ~10 Wine 1.40rc2 with commit 68b15bc5 reverted - FPS ~14
I'm still tracking down an another commit that caused FPS drop from 17 to 14.
What I want to ask is: should I file another bug report about performance regression in Perfect World game client caused by commit 68b15bc5 or not? I mean, it seems that the problem with FPS drop in WoT due to commit 68b15bc5 is - probably - just the same as I had tracked down for PW game client, so maybe it's not convenient to track them as a separate bug report entries.
Stefan, Dmitry, what do you think?
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #16 from Stefan Dösinger stefan@codeweavers.com 2012-02-12 15:27:21 CST --- Thanks for bisecting this. If a new bug is the way to go depends on where the regression occurred. If it's in the d3d code we may stick to this report, if it's some other library a new bug report is better. Please CC me on the new bug if you file one.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #17 from K1773R K1773R@darkgamex.ch 2012-02-12 15:32:31 CST --- me too please ;)
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #18 from Stefan Dösinger stefan@codeweavers.com 2012-02-12 15:34:20 CST --- Actually, just post a line here in this bug report with the new bug number, then everyone who's interested can CC himself :-)
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #19 from Stefan Dösinger stefan@codeweavers.com 2012-02-27 08:33:57 CST --- Can you try attachmeht 39097 from bug 30019?
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #20 from Vincas Miliūnas vincas.miliunas@gmail.com 2012-02-27 12:23:09 CST --- (In reply to comment #19)
Can you try attachmeht 39097 from bug 30019?
I've tested it in World of Tanks 0.7.1 using the replay linked above. The results of in-game FPS at the start of the battle countdown are:
master: 16 fps disable-dynamic-vertex-buffers: 38 fps Do-not-use-double-buffered-dynamic-buffers: 38 fps
The new patch does fix the performance degradation problem.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #21 from Vincas Miliūnas vincas.miliunas@gmail.com 2012-03-02 07:33:35 CST --- After running the game again I have found that the Do-not-use-double-buffered-dynamic-buffers patch does not prevent the performance degradation the first time you run the game (after a restart or start up). Only after relaunching the game you get proper performance.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #22 from Alexey Loukianov mooroon2@mail.ru 2012-03-08 11:56:37 CST --- (In reply to comment #19)
Can you try attachmeht 39097 from bug 30019?
Stefan, is the "ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic" patch required prior to applying "wined3d: Do not use double-buffered dynamic buffers"? I want to test the latter one with "Perfect World" to check if it fixes the FPS drop that had been caused by 68b15bc5 commit, but I'm not sure whether should I use both patched or not. Thanks in advance for clarifications.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #23 from Stefan Dösinger stefan@codeweavers.com 2012-03-08 15:43:46 CST --- If it is a ddraw game, then the ddraw patch is required, otherwise it should not have an influence.
http://bugs.winehq.org/show_bug.cgi?id=27600
Ákos Maróy akos@maroy.hu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |akos@maroy.hu
--- Comment #24 from Ákos Maróy akos@maroy.hu 2012-04-29 10:14:20 CDT --- I seem to have the same problem (using nvidia cards), after having compiled wine from the git source tree.
I wonder, among the patches scattered among the comments in this bug, which is the definitive one to use? :)
http://bugs.winehq.org/show_bug.cgi?id=27600
Gojko Kukobat gojkok@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gojkok@mail.ru
--- Comment #25 from Gojko Kukobat gojkok@mail.ru 2012-11-28 23:28:47 CST --- I have ASUS N53SV CPU: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz Memory: 8GB; Graphic: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 540M/PCIe/SSE2 OpenGL version string: 4.3.0 NVIDIA 310.14 OpenGL shading language version string: 4.30 NVIDIA via Cg compiler
Average frame rate in Wot is: 15fps
Debug log: ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. fixme:advapi:RegisterTraceGuidsA (0x7721212f, 0x7724bfc0, {0cfe0455-93ba-440d-a3fe-553973d0b723}, 1, 0x33fce8, (null), (null), 0x7724bfc8,): stub fixme:advapi:RegisterTraceGuidsA (0x7721212f, 0x7724bfe0, {797fabac-7b58-4796-b924-d51178a59ce4}, 1, 0x33fce8, (null), (null), 0x7724bfe8,): stub fixme:advapi:EventRegister {43d1a55c-76d6-4f7e-995c-64c711e5cafe}, 0x7723dc30, (nil), 0x7724b738 fixme:win:EnumDisplayDevicesW ((null),0,0x114c0f8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),1,0x114c0f8,0x00000000), stub! fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33fcf4 63 C) semi-stub fixme:msvcp:locale__Locimp__Makexloc (0x33fcf4 63 0x156da0 (nil)) semi-stub fixme:msvcp:locale__Locimp__Makewloc (0x33fcf4 63 0x156da0 (nil)) semi-stub fixme:msvcp:locale__Locimp__Makeushloc (0x33fcf4 63 0x156da0 (nil)) semi-stub fixme:win:EnumDisplayDevicesW ((null),0,0x33eaf0,0x00000000), stub! fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33e95c 1 C) semi-stub fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33e78c 1 C) semi-stub fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:win:EnumDisplayDevicesW ((null),0,0x33e3d0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33e1a4,0x00000000), stub! fixme:dxgi:dxgi_output_GetDesc iface 0x3600bd0, desc 0x33e640 stub! fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:client_security_SetBlanket 0xf6e9cf68, 0x358f7c8, 10, 0, (null), 3, 3, (nil), 0x00000000 fixme:wbemprox:client_security_Release 0xf6e9cf68 fixme:win:EnumDisplayDevicesW ((null),0,0x33d75c,0x00000000), stub! fixme:d3d:wined3d_swapchain_set_gamma_ramp Ignoring flags 0x1. fixme:d3d9:d3d9_device_CheckDeviceState iface 0x37df628, dst_window (nil) stub! fixme:d3d:resource_check_usage Unhandled usage flags 0x8. ALSA lib dlmisc.c:236:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so ALSA lib dlmisc.c:236:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0xec6e9ec): stub fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:msvcr90:MSVCRT_type_info_name_internal_method type_info_node parameter ignored ImportError: No module named BWAutoImport fixme:win:EnumDisplayDevicesW ((null),0,0x339fcc,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\.\DISPLAY1",0,0x33a314,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\.\DISPLAY1",1,0x33a314,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),1,0x339fcc,0x00000000), stub! fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:win:EnumDisplayDevicesW ((null),0,0x33ee84,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33ec58,0x00000000), stub! fixme:dxgi:dxgi_output_GetDesc iface 0x8646180, desc 0x33f0f4 stub! fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:client_security_SetBlanket 0xf6e9cf68, 0x4882da0, 10, 0, (null), 3, 3, (nil), 0x00000000 fixme:wbemprox:client_security_Release 0xf6e9cf68 fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33e8f4 1 C) semi-stub fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33e9a4 1 C) semi-stub fixme:imm:NotifyIME NI_CLOSECANDIDATE fixme:imm:ImmReleaseContext (0x3003c, 0x13a00d28): stub fixme:win:EnumDisplayDevicesW ((null),0,0x33e9b4,0x00000000), stub! fixme:d3d9:Direct3DShaderValidatorCreate9 stub fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of other threads
And most common message is: fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #26 from Stefan Dösinger stefan@codeweavers.com 2012-12-11 07:19:05 CST --- This bug should be fixed since 1835e2f5baa376eab95c760951fcc6a3612aa6cd. Can you retest?
If the game is still slow, please check if your graphics card and driver support GL_ARB_instanced_arrays.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #27 from Vincas Miliūnas vincas.miliunas@gmail.com 2012-12-11 16:30:48 CST --- I tested using http://mwreplays.com/replay/4DVYFZ381463/ (version 8.1) replay with the default config, looking at the in-game FPS at 20 seconds before the start of the battle.
pre-patch with workaround = 18-19 in-game FPS pre-patch without workaround = 6-7 in-game FPS post-patch with workaround = 18-19 in-game FPS post-patch without workaround = 6 in-game FPS
The workaround is http://dl.dropbox.com/u/6901628/disable-dynamic-vertex-buffers.patch
Nothing's changed on my machine. Just to mention, my low settings config give me twice the FPS when running natively in Windows (vs WINE w/ workaround).
I am running an AMD Radeon HD 6770 w/ fglrx 12.10. glxinfo does list GL_ARB_instanced_arrays in OpenGL extensions.
http://bugs.winehq.org/show_bug.cgi?id=27600
--- Comment #28 from Henri Verbeet hverbeet@gmail.com 2013-06-12 06:43:47 CDT --- Mostly out of curiosity, does anyone have numbers for r600g as well?
https://bugs.winehq.org/show_bug.cgi?id=27600
mateusz2238@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mateusz2238@outlook.com
--- Comment #29 from mateusz2238@outlook.com --- Please send wine log
https://bugs.winehq.org/show_bug.cgi?id=27600
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM
--- Comment #30 from Vincas Miliūnas vincas.miliunas@gmail.com --- I've been out of the loop with things related to World of Tanks or WINE for almost two years. But I did a test to check if the issue is still present.
Radeon driver on the 3.17.4-200.fc20.x86_64 kernel only rendered WoT as a collage of random graphics memory with music playing in the background.
I ran the newest WINE git wine-1.7.33 as well as the previously affected 1835e2f5baa376eab95c760951fcc6a3612aa6cd and older commits. With and without using the workaround - http://dl.dropbox.com/u/6901628/disable-dynamic-vertex-buffers.patch
My old post says WoT 0.7.0 needed only winetricks corefonts, however the current WoT 0.9.4 requires winetricks d3dx9 (looks like it no longer bundles the dx dll). Testing was done with a clean WINEPREFIX otherwise.
With the same AMD Radeon HD 6770 and the newest 14.12 fglrx driver I cannot reproduce the performance degradation issue (in fact the workaround reduces performance). In every setup I get ~20+ FPS looking at a geometry-rich scene in two replays tested, which is the same or slightly better compared to what I as getting two years ago with the workaround. Could be a change in newer WoT versions, or a fixed bug in fglrx, or maybe the influence of winetricks d3dx9.
Well, as for a performance level, I would say that the two year old commits around the time of 1835e2f5baa376eab95c760951fcc6a3612aa6cd give ~1-2 FPS more than wine-1.7.33.
Anyways, it doesn't look like a WINE bug, I would say RESOLVED/UPSTREAM is fitting here.
https://bugs.winehq.org/show_bug.cgi?id=27600
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=27600
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #31 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=27600
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #32 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
-
wine-bugs＠winehq.org