January 2018 - Wine-Bugs - list.winehq.org

[Bug 28863] SecuROM 8.xx: games require activation on each start

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=28863 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch -- 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.

Jan. 9, 2018

[Bug 44330] Some WinSCP buttons are black when Windows version is set to Windows 7

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44330 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal -- 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.

Jan. 9, 2018

[Bug 44330] Some WinSCP buttons are black when Windows version is set to Windows 7

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44330 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Some WinSCP buttons are |Some WinSCP buttons are |black |black when Windows version | |is set to Windows 7 -- 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.

Jan. 9, 2018

[Bug 44330] Some WinSCP buttons are black

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44330 Artem S. Tashkinov <t.artem(a)mailcity.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | --- Comment #4 from Artem S. Tashkinov <t.artem(a)mailcity.com> --- (In reply to Fabian Maurer from comment #3) > Doesn't seem to be a regression, it does work with version set to XP, but > not with version set to Win7. Can you confirm these findings? I concur. That's weird because I was under the impression that rendering code paths for different OS'es in Wine match. -- 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.

Jan. 9, 2018

[Bug 43590] Rise of Nations Thrones & Patriots weird graphics

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43590 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d --- Comment #7 from Matteo Bruni <matteo.mystral(a)gmail.com> --- I spent some time on this and I think I know what's going on. Chatty log of the debugging process follows, feel free to skip to the end. I'll start by mentioning that I tested the game on Windows and it does work fine there. I couldn't find anything wrong from the logs + OpenGL apitrace so I decided to take a d3d8 apitrace on Windows and figure out which draw breaks on Wine. To my surprise, replaying the d3d8 trace on Windows showed pretty much the same artifacts as Wine. That suggests either there is something drawing "out of channel" or apitrace somehow missed out on something, exactly as Wine. Back to Linux, I see no evidence of the former. I then go back staring at the draw I found the most suspicious. Essentially the game draws all the tiles of the map normally, then this draw "darkens" some of the tiles by blending in some semitransparent black triangles. In the log that is: 0009:trace:d3d8:d3d8_device_DrawIndexedPrimitive iface 0x130468, primitive_type 0x4, min_vertex_idx 0, vertex_count 2150, start_idx 0, primitive_count 2752. Hmm, that seems a lot of triangles to draw so few black spots (after you move the camera around a bit, at least). Checking the contents of the index and vertex buffers doesn't show anything clearly wrong. But then I happen to notice how the vertex buffer is updated: 0009:trace:d3d:wined3d_buffer_map buffer 0x57f00b0, offset 0, size 5000, data 0x32dde0, flags 0. For the records the vertex stride is 20 bytes. That means only 250 vertices are updated. Which would be all fine and good, except that's how the buffer is mapped ALL the times, including the first time. It turns out that the game updates the buffer outside of the mapped area. That apparently works on Windows (my guess is that the whole buffer is mapped regardless of the size - it's a DYNAMIC, WRITEONLY buffer FWIW) while in current wined3d that works only for the initial buffer upload but obviously fails for subsequent updates. Hacking the buffer map to e.g. replace size == 5000 with 100000 does avoid the bug. I initially tried to hack a DISCARD flag into the map but that didn't quite work right, which I guess means that the game doesn't overwrite the entire (used portion of the) buffer on each update. It would be interesting to know if there are more applications doing the same. I don't see obvious generic workarounds we can do to fix this. It's worth mentioning that persistent buffer maps from ARB_buffer_storage could potentially avoid 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.

Jan. 9, 2018

[Bug 44315] Buffer maps cause CPU-GPU synchronization (Guild Wars 2)

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44315 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor Summary|Guild Wars 2 - Slow |Buffer maps cause CPU-GPU |Performance since Wine 2.1 |synchronization (Guild Wars | |2) --- Comment #6 from Matteo Bruni <matteo.mystral(a)gmail.com> --- (In reply to Henri Verbeet from comment #5) > (In reply to Matteo Bruni from comment #4) > > I think you're spot on. It looks like wine-staging 2.0 was the last version > > with the CSMT buffer map optimization hacks which, in some cases, could > > reduce CPU-GPU synchronization significantly and thus improve game > > performance. > > > > We'll probably introduce something non-hacky to the same effect in wined3d > > at some point in the future. > > It's a bit awkward to have this as a bug against the Wine product though, > since it basically amounts to "D3D performance could be better". Wine never > had those hacks—and for good reason—so GW2 performance in Wine shouldn't be > any worse than it ever was. (If it is, please do a regression test.) At the > same time, it doesn't seem al that likely that Staging would be willing to > take this as their bug and work on bringing those hacks back in an > acceptable form. Right, I guess I effectively rechristened this bug to mean "introduce a buffer map optimization". Let me update the bug to make that official. Unless you think that's not useful either. -- 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.

Jan. 9, 2018

[Bug 44330] Some WinSCP buttons are black

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44330 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |dark.shadow4(a)web.de --- Comment #3 from Fabian Maurer <dark.shadow4(a)web.de> --- Doesn't seem to be a regression, it does work with version set to XP, but not with version set to Win7. Can you confirm these findings? -- 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.

Jan. 9, 2018

[Bug 44315] Guild Wars 2 - Slow Performance since Wine 2.1

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44315 --- Comment #5 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to Matteo Bruni from comment #4) > I think you're spot on. It looks like wine-staging 2.0 was the last version > with the CSMT buffer map optimization hacks which, in some cases, could > reduce CPU-GPU synchronization significantly and thus improve game > performance. > > We'll probably introduce something non-hacky to the same effect in wined3d > at some point in the future. It's a bit awkward to have this as a bug against the Wine product though, since it basically amounts to "D3D performance could be better". Wine never had those hacks—and for good reason—so GW2 performance in Wine shouldn't be any worse than it ever was. (If it is, please do a regression test.) At the same time, it doesn't seem al that likely that Staging would be willing to take this as their bug and work on bringing those hacks back in an acceptable form. -- 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.

Jan. 9, 2018

[Bug 43748] Dead or Alive Last Round crashes on Wine newer than 1.8.7 under Linux, but not in OS X

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43748 --- Comment #15 from Henri Verbeet <hverbeet(a)gmail.com> --- Yeah, I guess. I'd be curious what the Windows driver for that hardware does. I'm inclined to mostly blame this on the application, but wouldn't necessarily be opposed to some kind of quirk for 2xMSAA. At the same time, such a quirk would somewhat defeat the point of having a per sample count query, as opposed to just a maximum like classic GL. -- 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.

Jan. 9, 2018

[Bug 43748] Dead or Alive Last Round crashes on Wine newer than 1.8.7 under Linux, but not in OS X

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43748 Józef Kucia <joseph.kucia(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia(a)gmail.com --- Comment #14 from Józef Kucia <joseph.kucia(a)gmail.com> --- (In reply to Matteo Bruni from comment #13) > I'm not sure. AFAIU it's a specific combination of: > > - GPU driver advertising 4x+ multisampling but not 2x multisampling > - game expecting 2x multisampling once 4x is supported > If Windows drivers support 2x multisampling once 4x is supported, then one could argue that it's our 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.

Jan. 9, 2018