[Bug 27534] New: Call of Duty 4 MW: Graphical glitches when shooting
http://bugs.winehq.org/show_bug.cgi?id=27534 Summary: Call of Duty 4 MW: Graphical glitches when shooting Product: Wine Version: 1.3.22 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: wylda(a)volny.cz If you remember bug 21962 especially its comment #56 ;) then you know this picture, which striked again in wine-1.3.22-193-g68b15bc: http://bugs2.winehq.org/attachment.cgi?id=27333 This time tested on nVidia GT240 1GB v275.09.07 1. I did a regression test between 1.3.22 and 1.3.22-203-gac90c1b: commit 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f Author: Stefan Dösinger <stefan(a)codeweavers.com> 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 caused major performance problems. If the user is using an older driver we now drop the VBO instead of using doublebuffered loading, which means that we fall back to the current behavior (no dynamic VBO) as needed. Dynamic VBOs are needed on Nvidia drivers for GL_ARB_instanced_arrays. :040000 040000 0cada15043b731febf2ef2a673aaaecc4af75f8d c474ade74a8db2a9c547674dbb4c809841087a3d M dlls 2. Right now no other bug report suffers from this commit. 3. Revert of this patch on top of 1.3.22-203-gac90c1b makes that problem go away. --private keyword: bisected -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Wylda <wylda(a)volny.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |stefandoesinger(a)gmx.at --- Comment #1 from Wylda <wylda(a)volny.cz> 2011-06-19 03:40:07 CDT --- Filling keyword and CC. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #2 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-19 07:29:44 CDT --- Ya, I was afraid this bug would come back. You can enable strict draw ordering to get rid of it, but that costs a lot of performance(10% on Nvidia drivers). I'll see if I find a better way, but I doubt it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #3 from Wylda <wylda(a)volny.cz> 2011-06-19 08:25:54 CDT ---
You can enable strict draw ordering
How can i do that ;) ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2011-06-19 16:22:55 CDT --- (In reply to comment #3)
You can enable strict draw ordering
How can i do that ;) ?
http://wiki.winehq.org/UsefulRegistryKeys - Direct3d/StrictDrawOrdering -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com --- Comment #5 from Austin English <austinenglish(a)gmail.com> 2011-06-19 23:23:38 CDT --- Also affects Duke Nukem Forever, though it appears to have two bugs. The first screens when starting a new game 'kick ass/chew bubble gum' flicker. Enabling strict draw ordering here doesn't help. But disabling it does (wth?), albeit with a gray background for the first screen instead of black. Once in game, however, flickering remains with strict draw ordering disabled. Enabling it fixes the flicker in game (again, splash screens remain broken). OpenGL renderer string: GeForce GTX 480/PCI/SSE2 OpenGL version string: 4.1.0 NVIDIA 270.41.03 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #6 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-20 05:50:45 CDT --- Can you attach a screenshot? Also, what is the best way to get DNF running in Wine? I hear that there are various versions(Demo, Steam, ???), and not all of them work. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #7 from Austin English <austinenglish(a)gmail.com> 2011-06-20 06:14:41 CDT --- (In reply to comment #6)
Can you attach a screenshot? Also, what is the best way to get DNF running in Wine? I hear that there are various versions(Demo, Steam, ???), and not all of them work.
The demo doesn't work under wine, seems to use the same protection as Portal 2 (bug 26835). The full version semi-works, watch out for bug 27472. Screenshot is incoming. Note that the screenshot came out poor, the graphics aren't corrupted, just flickering horizontally.. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #8 from Austin English <austinenglish(a)gmail.com> 2011-06-20 06:14:59 CDT --- Created an attachment (id=35209) --> (http://bugs.winehq.org/attachment.cgi?id=35209) screenshot -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Cedric Heintz <cedric(a)ced117.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cedric(a)ced117.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #9 from Wylda <wylda(a)volny.cz> 2011-06-20 13:55:27 CDT ---
You can enable strict draw ordering
Is this properly set by??: [HKEY_CURRENT_USER\Software\Wine\Direct3D] "StrictDrawOrdering"="enabled" If yes, then this does not help. My graphics reported by Austin's way: 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #10 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-20 14:16:17 CDT --- Yes, it looks like you enabled strict draw ordering correctly. Please make sure you don't have an AppDefault key setting it back to disabled for iw4sp.exe and iw4mp.exe. If such a key doesn't exist I'm afraid this bug is different from what I thought :-/ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #11 from Wylda <wylda(a)volny.cz> 2011-06-20 15:40:02 CDT ---
Please make sure you don't have an AppDefault key setting it back to disabled for iw4sp.exe
I'm not aware of such setting. I was carefully watching and saw a difference, so registry setting was applied correctly. The tiny difference is when i use "StrictDrawOrdering"="enabled" then in most cases on a first shot or shots with long pause in between do not show artifacts (but won't produce smoke either). When "disabled", then first shot produces graphical glitches and it's also much more visible. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #12 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-21 11:20:52 CDT --- I can't get duke nuken forever running, it always shows a EXCEPTION_SINGLE_STEP error. Unlike what is mentioned in bug 27472, the game never starts after I dismiss this dialog. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #13 from Wylda <wylda(a)volny.cz> 2011-06-24 23:18:11 CDT --- This regression (bisected) is still present in wine-1.3.23. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 DL <dredgingthelake(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dredgingthelake(a)gmail.com --- Comment #14 from DL <dredgingthelake(a)gmail.com> 2011-06-27 04:53:08 CDT --- This bug affects Deus Ex Human Revolution (beta) also. Reverting the commit fixes the issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Vincas Miliūnas <vincas.miliunas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vincas.miliunas(a)gmail.com --- Comment #15 from Vincas Miliūnas <vincas.miliunas(a)gmail.com> 2011-06-27 05:36:37 CDT --- *** Bug 27600 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Berillions <berillions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions(a)gmail.com --- Comment #16 from Berillions <berillions(a)gmail.com> 2011-07-10 12:55:31 CDT --- This bug affect "Lara Croft and the Guadians of Light" on Steam also. Reverting the commit fixes the issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #17 from Wylda <wylda(a)volny.cz> 2011-07-15 12:17:45 CDT --- This regression (bisected) is still present in wine-1.3.24-174-g4b4dd30. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #18 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-07-28 13:53:55 CDT --- Created an attachment (id=35730) --> (http://bugs.winehq.org/attachment.cgi?id=35730) wined3d: Reapply stream sources in other contexts after modifying buffers Can you give this patch a try? It fixes the issue for me. Before I send it in I want to check the OpenGL spec for the cases when a buffer(or texture) has to be rebound. I think it is needed for all changes, but maybe it is only necessary when the object has been reallocated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #19 from Wylda <wylda(a)volny.cz> 2011-07-28 15:31:25 CDT ---
Can you give this patch a try?
Cant apply on top of wine-1.3.25-195-g5e941f8: patching file dlls/wined3d/buffer.c Hunk #1 FAILED at 1018. 1 out of 1 hunk FAILED -- saving rejects to file dlls/wined3d/buffer.c.rej -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #20 from Wylda <wylda(a)volny.cz> 2011-07-28 15:48:57 CDT --- OK, i went one day back to avoid Henri's changes. Unfortunately this patch did not help. A can not see any difference when the patch is applied. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35730|0 |1 is obsolete| | --- Comment #21 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-02 14:03:39 CDT --- Created an attachment (id=35788) --> (http://bugs.winehq.org/attachment.cgi?id=35788) wined3d: use glBufferData(NULL) instead of GL_MAP_INVALIDATE_BUFFER_BIT This is another debug attempt. This patch has worked for me so far, but the bug has been unreliable on my system. The patch uses glBufferData(NULL) instead of GL_MAP_INVALIDATE_BUFFER_BIT, which are conceptually the same thing, but might use different codepaths in the driver. If this fixes the issue this may indicate a bug in the driver, but I can't be sure until I know more. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #22 from Wylda <wylda(a)volny.cz> 2011-08-02 15:09:49 CDT ---
wined3d: use glBufferData(NULL) instead of GL_MAP_INVALIDATE_BUFFER_BIT
Yay :-D I'm happy to say, that this patch fixes the issue for me. I'm glad you kept the patience job and fouond causes of the bug :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #23 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-03 04:13:06 CDT --- No, I haven't found the cause, I've just found a supposedly no-op change that happens to avoid the bug. That's not a fix, just another factoid for debugging. The next steps will be testing on other drivers(AMD...), checking if the same issue occurs on OSX(different codepath, uses GL_APPLE_flush_buffer_range) and see if the bug occurs there. Another candidate is testing Windows+Nvidia with wined3d. If all those platforms show the bug it's likely it is our issue. Either way I'll have to find out what the game is doing that triggers it, but other games don't trigger it. So still a long way to go. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #24 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-03 14:27:57 CDT --- fglrx doesn't have this bug. It does have another bug that is triggered by using VBOs for dynamic buffers, with or without GL_ARB_mapped_buffer_range. GL_MAP_INVALIDATE_BUFFER_BIT is unrelated to the fglrx issue. That's another data pointer towards an issue in the nvidia driver, even though it's a weak one. We may screw something up at a more fundamental level. The visual symptoms of the nvidia and amd bugs look very similar, but if you know at which details to look you see differences(e.g. the heardbeat sensor in the "cliffhanger mission") fglrx had some multithreading issues, e.g. in Team Fortress 2 it would show old frames. This may or may not be related. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #25 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-03 16:54:19 CDT --- Created an attachment (id=35801) --> (http://bugs.winehq.org/attachment.cgi?id=35801) wined3d: disable dynamic vertex buffers This is another debug attempt: This patch disables dynamic vertex buffers. If the bug goes away(as it does for me), the issue concerns one or more vertex buffers, but index buffers work as they should. If it doesn't, index buffers are affected too, and we have to test the reverse and disable index buffers to find out more about vertex buffers. Fwiw, I think the game is doing something odd with one of its buffers. I don't know what, it may be legal, but it triggers problems in the drivers. Isolating the buffer(s) that are broken is necessary to find out what the game is doing to break them. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Henrik Holst <henrik.holst2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |henrik.holst2(a)gmail.com --- Comment #26 from Henrik Holst <henrik.holst2(a)gmail.com> 2011-08-03 18:26:07 CDT --- I'm on fglrx and while I don't see the graphical glitches that are in the screenshots something in 1.3.23 (and still present in 1.3.25) made COD4 and MW2 dog slow. Could this be related (since the regression happened at the same release) or should I file a separate bug? The only glitches that I have seen is that some graphics is slower than others, for example when you move around the "hands and weapons" takes much longer to move than the background. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #27 from Wylda <wylda(a)volny.cz> 2011-08-04 00:35:47 CDT ---
Created an attachment (id=35801)
--> (http://bugs.winehq.org/attachment.cgi?id=35801) [details]
This is another debug attempt: This patch disables dynamic vertex buffers. If the bug goes away(as it does for me), the issue concerns one or more vertex buffers, but index buffers work as they should.
It fixes the problem for me too. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #28 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-04 07:47:59 CDT --- (In reply to comment #26)
I'm on fglrx and while I don't see the graphical glitches that are in the screenshots something in 1.3.23 (and still present in 1.3.25) made COD4 and MW2 dog slow. What's "dog slow"? My guess is that the game runs at 10-20 fps on my core i7 + radeon hd 5770 system. That's highest settings in a 800x600 window. It is horribly slow compared to Windows, just wondering what you're seeing.
And no, I doubt it is related. This game has always been slow on both Nvidia and AMD cards.
The only glitches that I have seen is that some graphics is slower than others, for example when you move around the "hands and weapons" takes much longer to move than the background. Yes, I see that too. I think this is related to dynamic buffers. Afair it goes away when you disable dynamic buffers. The issue stays if you disable ARB_map_buffer_range, but force VBOs for dynamic buffers.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #29 from Henrik Holst <henrik.holst2(a)gmail.com> 2011-08-04 09:04:45 CDT --- Sorry about beeing so unspecific Stefan, I'm talking about a regression. In 1.3.22 (and previous versions) I have like 30-50 FPS on my system (core i5 + hd4870 in 1920x1080) but in 1.3.23+ I get like 1-2 FPS. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #30 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-04 12:35:41 CDT --- I isolated one of the buffers involved in this bug and I have a theory what may be happening: The buffer in question is a 512k vertex buffer. The game always maps the entire buffer from thread A with D3DLOCK_DISCARD and uses the buffer from thread B to dispatch a number of draw calls without changing the buffer in between. Nothing wrong with that. The buffer isn't assigned to a stream source while it is mapped, and it is assigned after unmap, so thread B should properly notice the changes to the buffer. I suspect that the driver checks if the buffer is in use somewhere when GL_MAP_INVALIDATE_BUFFER_BIT(the GL equivalent of D3DLOCK_DISACRD) is used. If it is, a new buffer is allocated(or recycled) to avoid waiting for those scheduled commands to finish. If it isn't, the flag is ignored since allocating a new buffer isn't free. My guess now is that when the driver checks if the buffer is busy it only checks the current context. Thus it reuses the existing buffer and the game overwrites data that is required for old, not yet executed draw commands. If this theory is correct a glFinish() before a INVALIDATE_BUFFER_BIT map combined with strict draw ordering should do it. I'll attach a patch for that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35801|0 |1 is obsolete| | --- Comment #31 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-04 13:09:01 CDT --- Created an attachment (id=35807) --> (http://bugs.winehq.org/attachment.cgi?id=35807) wined3d: call glFinish before performing a discard map This is a test patch to confirm my theory from comment 30. Note that you have to enable strict draw ordering for this patch to work. If my theory is correct this patch(without any other patches) should fix the flickering. Note that this is not a proper fix. It has a pretty big performance impact. In fact it has a bigger performance impact than simply ignoring D3DLOCK_DISCARD. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #32 from Wylda <wylda(a)volny.cz> 2011-08-05 02:46:39 CDT ---
Created an attachment (id=35807)
--> (http://bugs.winehq.org/attachment.cgi?id=35807) [details] I took clean wine-1.3.25-451-g3353261 tree and applied this patch, then set "StrictDrawOrdering"="enabled". This did NOT fixed the issue. During that the wine console says all the time: fixme:d3d:resource_check_usage Unhandled usage flags 0x8. Then i tried to run the same wine environment through schedtool, ie: schedtool -a 0x1 -e /build/wine-git_build/wine iw3sp.exe and this fixed the problem, but console output is totally different saying all the time: err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElementsBaseVertex @ drawprim.c / 46 Dunno if it could take different code path or whether one core vs eight make some timing difference. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #33 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-05 09:14:18 CDT --- Can you modify my patch to call wglFinish unconditionally before mapping? Maybe there is also a problem with regular buffer maps. This is what I suspect is going on on fglrx, maybe the nvidia bug extends beyond INVALIDATE_BUFFER_BIT. What happens if you run the game on an unmodified wine on one core, maybe by disabling the cores in /sys/devices/system/cpu/cpu*/enable? I'll give the game a try on my quadcore machine rather than the dualcore laptop, maybe that helps to reproduce the bug sooner. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #34 from Wylda <wylda(a)volny.cz> 2011-08-06 17:10:42 CDT --- I gave it try on vanilla wine-1.3.26 just modified the run command: * wine iw3sp.exe +set sys_smp_allowed 1 //shows the reported bug, console output repeats "fixme:d3d:resource_check_usage Unhandled usage flags 0x8." * wine iw3sp.exe +set sys_smp_allowed 0 //"fixes" the problem even if StrictDrawOrdering is set to disabled or enabled. Console output is changed and repeats "err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElementsBaseVertex @ drawprim.c / 46" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #35 from Wylda <wylda(a)volny.cz> 2011-08-06 17:15:34 CDT --- Added another testcase: * schedtool -a 0x1 -e wine iw3sp.exe +set sys_smp_allowed 1 //"fixes" the problem, CoD console truly reports sys_smp_allowed 1, wine console output repeats "fixme:d3d:resource_check_usage Unhandled usage flags 0x8." -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #36 from Wylda <wylda(a)volny.cz> 2011-08-06 17:48:33 CDT ---
Can you modify my patch to call wglFinish unconditionally before mapping? Maybe there is also a problem with regular buffer maps. This is what I suspect is going on on fglrx, maybe the nvidia bug extends beyond INVALIDATE_BUFFER_BIT.
On top of 1.3.26 i applied: @@ -1028,6 +1028,9 @@ if (gl_info->supported[ARB_MAP_BUFFER_RANGE]) { GLbitfield mapflags = buffer_gl_map_flags(flags); + LEAVE_GL(); + wglFinish(); + ENTER_GL(); buffer->resource.allocatedMemory = GL_EXTCALL(glMapBufferRange(buffer->buffer_type_hint, and run: * wine iw3sp.exe +set sys_smp_allowed 1 CoD still shows the problem in both StrictDrawOrdering cases (enabled or disabled). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #37 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-07 16:25:20 CDT --- On the quadcode CPU the bug is much easier to reproduce - it starts right away rather than after 15 minutes of playing. The CPU(some core i7 one) has hyperthreading, so it is actually advertising 8 cores. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35807|0 |1 is obsolete| | Status|NEW |ASSIGNED AssignedTo|wine-bugs(a)winehq.org |stefandoesinger(a)gmx.at --- Comment #38 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-07 16:35:34 CDT --- Created an attachment (id=35869) --> (http://bugs.winehq.org/attachment.cgi?id=35869) wined3d: call glFinish around buffer maps / unmaps This is a slightly modified version of attachment 35807, it takes the idea to an extreme and synchronizes around every buffer map/unmap operation. The issues disappear for me, can you verify this? This debug hack by itself doesn't give too much information, it mostly just says "yeah, if you force a sync everywhere things work". I'll dig into the details to see where the exact issues are. I suspect that we are fighting two separate issues here, e.g. one being incorrect synchronization by the driver and the other missing re-binds of the buffer in other contexts by us. Or something like that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35869|0 |1 is obsolete| | --- Comment #39 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-07 16:53:54 CDT --- Created an attachment (id=35870) --> (http://bugs.winehq.org/attachment.cgi?id=35870) wined3d: call glFlush after updating a buffer After another glimpse at the code the issue seemed kinda obvious. We weren't flushing after unmaping the buffer, so the actual buffer upload might happen after other threads draw from it. Adding the flush fixes the issue for me. Head, meet wall. Wall, meet head... Can you give the patch a try? Strict draw ordering has to be enabled, otherwise this won't work. I marked the previous patch(35869) obsolete, if this one doesn't work please give the old patch a try. Unfortunately there's no way around strict draw ordering here without a change in the OpenGL API. Maybe something like GLX_MESA_multithread_makecurrent might help, but I'm not sure. The flushes needed for strict draw ordering cause quite a big performance impact, this is why we made this a setting and disabled it by default. This is a possible argument for arguing that GL_ARB_map_buffer_range isn't worth using from a performance point of view. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #40 from Wylda <wylda(a)volny.cz> 2011-08-08 01:13:34 CDT ---
Created an attachment (id=35870)
--> (http://bugs.winehq.org/attachment.cgi?id=35870)
Can you give the patch a try? Strict draw ordering has to be enabled...
This patch fixes the issue for me too :) Few questions about that, if i can for historical and future use: * Not calling GLflush was introduced by the commit in comment #0 or it was a hidden problem already before? Or the commit just speed some part up and made this visible on SMP machines? * Do we (you;) know why comment #21 & comment #25 fixes the issue? * Should i remember that there are two issues (for future use;) or is it already shrinked to one not calling issue? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #41 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-08 07:41:01 CDT --- (In reply to comment #40)
* Not calling GLflush was introduced by the commit in comment #0 or it was a hidden problem already before? Or the commit just speed some part up and made this visible on SMP machines? It has been a hidden problem before, and it might cause the problems on fglrx(haven't tested that, just a guess). The GL_ARB_map_buffer_range commit just made is use opengl buffers for more vertex buffers, so the problem was uncovered.
* Do we (you;) know why comment #21 & comment #25 fixes the issue? 25 is easy: It reverts to not using opengl buffers for most dynamic d3d buffers. That way the application just writes data into a system memory location managed by Wine. After unlock the data is in there. When the other thread draws from this d3d buffer it looks like a draw from system memory for opengl. The drawbacks are that the data is uploaded right before the draw rather than in parallel, and that opengl has to make some effort to figure out which data to grab from wined3d's memory before it returns from the draw call. Those are generic issues which lead to the introduction of dynamic buffers to the d3d and gl APIs. Since the flush calls are so horribly expensive we don't see any advantage from dynamic buffers in this game however.
21 is harder to answer. I don't know, but I suspect it has something to do how the driver handles INVALIDATE_BUFFER_BIT vs glBufferData(NULL) + map + unmap internally. That #21 helped lead me into a wrong direction.
* Should i remember that there are two issues (for future use;) or is it already shrinked to one not calling issue? No, it looks like this bug was caused by the missing flush alone.
I'll send the patch to wine-patches once AJ is back from vacation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #42 from Henri Verbeet <hverbeet(a)gmail.com> 2011-08-08 09:02:44 CDT --- I'm not sure if just flushing is enough to fix this, if you go by the spec at least. You don't necessarily know the unmap has completed unless you use either a fence or Finish(), and even after it has completed you don't necessarily get the new contents until you rebind. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #43 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-08 16:15:27 CDT --- (In reply to comment #42)
You don't necessarily know the unmap has completed unless you use either a fence or Finish(), If the buffer change isn't picked up by other contexts until after it has been done(rather than scheduled) we're lost anyway.
and even after it has completed you don't necessarily get the new contents until you rebind. Yes, that problem exists, and not just with buffers but also with textures, but it isn't what causes this bug. The game has a different buffer bound while updating those dynamic buffers and rebinds the dynamic buffer before drawing. That way we'll rebind it on the GL side.
Either way the only ways I see to fix this properly are some changes in opengl or handling threading ourselves via a worker thread. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv(a)dawncrow.de Regression SHA1| |68b15bc5ffe6ddf5d08cbc13479 | |eaf718ad5e39f -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #44 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-08-24 16:45:17 CDT --- The glFlush patch is in, can you retest this bug? the game should work now with strict draw rendering enabled. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |stefan(a)codeweavers.com Resolution| |FIXED --- Comment #45 from Stefan Dösinger <stefan(a)codeweavers.com> 2011-10-15 09:04:08 CDT --- I'm marking this bug fixed. It is fixed for me by 5d1d07abcf3deab4397a0008ae8c44493a721c6a on both nvidia and amd gpus. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5d1d07abcf3deab4397a0008ae8 | |c44493a721c6a -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #46 from Alexandre Julliard <julliard(a)winehq.org> 2011-10-21 13:50:17 CDT --- Closing bugs fixed in 1.3.31. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #47 from Wylda <wylda(a)volny.cz> 2011-12-02 16:51:15 CST ---
game should work now with strict draw rendering enabled.
Hi Stefan, yes it is fixed in 1.3.34, but only when StrictDrawOrdering is enabled. If disabled, i can still see the problem. So maybe this bug should remain opened?? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 --- Comment #48 from Stefan Dösinger <stefan(a)codeweavers.com> 2011-12-04 14:11:30 CST --- No, this will never work without strict draw ordering in the way multithreading in wined3d currently works. The only thing that will make this game work at a decent speed is a command stream of our own that will give us better control over the draw order. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27534 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Elias.vds(a)gmail.com --- Comment #49 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-08 07:58:10 CST --- *** Bug 32397 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=27534 Wylda <wylda(a)volny.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian --- Comment #50 from Wylda <wylda(a)volny.cz> --- Works properly now in wine-2.7 and with "winetricks csmt=on". Thank you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=27534 michi(a)michi7x7.at changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michi(a)michi7x7.at --- Comment #51 from michi(a)michi7x7.at --- *** Bug 42914 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org