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@winehq.org ReportedBy: wylda@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@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
http://bugs.winehq.org/show_bug.cgi?id=27534
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |stefandoesinger@gmx.at
--- Comment #1 from Wylda wylda@volny.cz 2011-06-19 03:40:07 CDT ---
Filling keyword and CC.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #2 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #3 from Wylda wylda@volny.cz 2011-06-19 08:25:54 CDT ---
You can enable strict draw ordering
How can i do that ;) ?
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #4 from Austin English austinenglish@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
http://bugs.winehq.org/show_bug.cgi?id=27534
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #5 from Austin English austinenglish@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
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #6 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #7 from Austin English austinenglish@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..
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #8 from Austin English austinenglish@gmail.com 2011-06-20 06:14:59 CDT --- Created an attachment (id=35209) --> (http://bugs.winehq.org/attachment.cgi?id=35209) screenshot
http://bugs.winehq.org/show_bug.cgi?id=27534
Cedric Heintz cedric@ced117.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cedric@ced117.net
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #9 from Wylda wylda@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
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #10 from Stefan Dösinger stefandoesinger@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 :-/
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #11 from Wylda wylda@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #12 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #13 from Wylda wylda@volny.cz 2011-06-24 23:18:11 CDT ---
This regression (bisected) is still present in wine-1.3.23.
http://bugs.winehq.org/show_bug.cgi?id=27534
DL dredgingthelake@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dredgingthelake@gmail.com
--- Comment #14 from DL dredgingthelake@gmail.com 2011-06-27 04:53:08 CDT --- This bug affects Deus Ex Human Revolution (beta) also. Reverting the commit fixes the issue.
http://bugs.winehq.org/show_bug.cgi?id=27534
Vincas Miliūnas vincas.miliunas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vincas.miliunas@gmail.com
--- Comment #15 from Vincas Miliūnas vincas.miliunas@gmail.com 2011-06-27 05:36:37 CDT --- *** Bug 27600 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=27534
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #16 from Berillions berillions@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #17 from Wylda wylda@volny.cz 2011-07-15 12:17:45 CDT ---
This regression (bisected) is still present in wine-1.3.24-174-g4b4dd30.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #18 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #19 from Wylda wylda@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
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #20 from Wylda wylda@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35730|0 |1 is obsolete| |
--- Comment #21 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #22 from Wylda wylda@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 :)
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #23 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #24 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #25 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Henrik Holst henrik.holst2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |henrik.holst2@gmail.com
--- Comment #26 from Henrik Holst henrik.holst2@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #27 from Wylda wylda@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #28 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #29 from Henrik Holst henrik.holst2@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #30 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35801|0 |1 is obsolete| |
--- Comment #31 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #32 from Wylda wylda@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #33 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #34 from Wylda wylda@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"
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #35 from Wylda wylda@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."
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #36 from Wylda wylda@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).
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #37 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35807|0 |1 is obsolete| | Status|NEW |ASSIGNED AssignedTo|wine-bugs@winehq.org |stefandoesinger@gmx.at
--- Comment #38 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35869|0 |1 is obsolete| |
--- Comment #39 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #40 from Wylda wylda@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?
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #41 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #42 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #43 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Regression SHA1| |68b15bc5ffe6ddf5d08cbc13479 | |eaf718ad5e39f
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #44 from Stefan Dösinger stefandoesinger@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |stefan@codeweavers.com Resolution| |FIXED
--- Comment #45 from Stefan Dösinger stefan@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5d1d07abcf3deab4397a0008ae8 | |c44493a721c6a
http://bugs.winehq.org/show_bug.cgi?id=27534
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #46 from Alexandre Julliard julliard@winehq.org 2011-10-21 13:50:17 CDT --- Closing bugs fixed in 1.3.31.
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #47 from Wylda wylda@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??
http://bugs.winehq.org/show_bug.cgi?id=27534
--- Comment #48 from Stefan Dösinger stefan@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.
http://bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Elias.vds@gmail.com
--- Comment #49 from Stefan Dösinger stefan@codeweavers.com 2012-12-08 07:58:10 CST --- *** Bug 32397 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=27534
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
--- Comment #50 from Wylda wylda@volny.cz --- Works properly now in wine-2.7 and with "winetricks csmt=on". Thank you.
https://bugs.winehq.org/show_bug.cgi?id=27534
michi@michi7x7.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michi@michi7x7.at
--- Comment #51 from michi@michi7x7.at --- *** Bug 42914 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org