[Bug 58483] New: Burnout Paradise has rendering issues
http://bugs.winehq.org/show_bug.cgi?id=58483 Bug ID: 58483 Summary: Burnout Paradise has rendering issues Product: Wine Version: 10.1 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: z.figura12(a)gmail.com Regression SHA1: 96fb128efdbf8d92f6b4d63a7db0346659b08969 Distribution: --- Created attachment 78933 --> http://bugs.winehq.org/attachment.cgi?id=78933 examples Some scenes are black rendered. -- 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=58483 --- Comment #1 from Zeb Figura <z.figura12(a)gmail.com> --- I might need some clarification here, what's the top and bottom in that image? I'm not seeing anything that obviously looks wrong to me when testing... -- 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=58483 --- Comment #2 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Top image captured before mentioned commit while bottom image after that. This is the first screen after intro video. Reproduces on both AMD and NVIDIA machines for me. -- 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=58483 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com --- Comment #3 from Stefan Dösinger <stefan@codeweavers.com> --- Is this the original game from 2008 or the remastered edition from 2018? -- 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=58483 --- Comment #4 from Andrey Gusev <andrey.goosev@gmail.com> --- This is original version from 2008. -- 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=58483 --- Comment #5 from Stefan Dösinger <stefan@codeweavers.com> --- I can reproduce this. It actually affects the initial loading screen already. As far as I can see the game creates a managed d3d9 texture and maps it with D3DLOCK_READONLY: 01a0:trace:d3d9:d3d9_device_CreateTexture iface 039CE8F8, width 2048, height 1024, levels 1, usage 0, format 0x35545844, pool 0x1, texture 0350F98C, shared_handle 00000000. ... 01a0:trace:d3d9:d3d9_device_CreateTexture Created texture 2BFC7960. 01a0:trace:d3d9:d3d9_texture_2d_LockRect iface 2BFC7960, level 0, locked_rect 0350F9B4, rect 00000000, flags 0x810. But it actually writes data into it. The copy is d3d9's doing, where it copies data from the sysmem wined3d texture into the default pool one. After the read-only lock the source texture has LOCATION_CLEARED | LOCATION_SYSMEM, and the code prior to commit 96fb128efd would pick up the sysmem copy, which happens to contain the data the game wrote. Now it propagates the CLEARED location, which is still considered valid because the game promised not to write any data. I vaguely remember similar issues in other situations. Maybe we should ignore the readonly flag on managed resources. Afair d3d<=9 managed resources can't ever be updated on the GPU side, so there's little use in a game really doing a read-only map. -- 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=58483 --- Comment #6 from Stefan Dösinger <stefan@codeweavers.com> --- Created attachment 79949 --> http://bugs.winehq.org/attachment.cgi?id=79949 d3d9: Ignore map flags on managed resources This patch fixes the problem for me. It is one possible solution. The other possibility, already hinted by d3d9/visual.c, add_dirty_rect_test(), is that a newly created managed texture is considered dirty, so whatever is in the sysmem copy on the first draw should be uploaded to the GPU. In practical terms we can probably limit this hack to the first map after creation, device::EvictManagedResources() and device::Reset(). I'll try to write some tests and see what Windows does. -- 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=58483 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79949|0 |1 is obsolete| | --- Comment #7 from Stefan Dösinger <stefan@codeweavers.com> --- Created attachment 79951 --> http://bugs.winehq.org/attachment.cgi?id=79951 Add a dirty region on texture creation This patch is probably more correct than attachment 79949. It adds a dirty region to the texture on creation. That fixes the game without ignoring read only maps and without breaking the AddDirtyRect test. The invisible issue is that this means managed and sysmem resources have a system memory copy allocated on creation, increasing the VM size even if the texture is never used. -- 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=58483 --- Comment #8 from Andrey Gusev <andrey.goosev@gmail.com> --- (In reply to Stefan Dösinger from comment #7)
Created attachment 79951 [details] Add a dirty region on texture creation
This patch is probably more correct than attachment 79949 [details]. It adds a dirty region to the texture on creation. That fixes the game without ignoring read only maps and without breaking the AddDirtyRect test.
The invisible issue is that this means managed and sysmem resources have a system memory copy allocated on creation, increasing the VM size even if the texture is never used.
Works for me too. -- 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=58483 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |769e0e2f4a90e12213cf2addee3 | |ccddfb322c9f9 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Stefan Dösinger <stefan@codeweavers.com> --- This should be fixed by 769e0e2f4a90e12213cf2addee3ccddfb322c9f9. -- 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=58483 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.0-rc3. -- 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 (3)
-
WineHQ Bugzilla -
WineHQ Bugzilla -
WineHQ Bugzilla