[Bug 44590] New: incorrect rendering in The Witness (ATOC?)
https://bugs.winehq.org/show_bug.cgi?id=44590 Bug ID: 44590 Summary: incorrect rendering in The Witness (ATOC?) Product: Wine Version: 3.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: notasas(a)gmail.com Distribution: --- Created attachment 60571 --> https://bugs.winehq.org/attachment.cgi?id=60571 bad rendering The Witness is still not rendering correctly in some cases (as of 7be8beab68c5): - objects in the water reflections are missing transparencies regardless of MSAA - all objects are missing transparencies with MSAA off perhaps these problems are related. Here is d3d apitrace (different from screenshot, can make a better one if that helps): https://drive.google.com/file/d/1fFCVytDdybsVgZqiTIKS5XseegIO5yzc/view?usp=s... -- 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=44590 --- Comment #1 from Grazvydas Ignotas <notasas(a)gmail.com> --- Created attachment 60572 --> https://bugs.winehq.org/attachment.cgi?id=60572 good rendering -- 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=44590 Józef Kucia <joseph.kucia(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia(a)gmail.com Status|UNCONFIRMED |NEW Summary|incorrect rendering in The |The Witness needs ATOC |Witness (ATOC?) |without multisampling Ever confirmed|0 |1 --- Comment #2 from Józef Kucia <joseph.kucia(a)gmail.com> --- Thanks for the bug report. I haven't debugged the water reflections problem, but yes, those problems might be related. I think the source of the issue is ATOC. In OpenGL ATOC can be used only with multisampling while in Direct3D ATOC can also be used without multisampling. I haven't given it much thought, but it's probably hard to fix in any reasonable way in OpenGL. An OpenGL extension might be helpful. -- 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=44590 --- Comment #3 from Józef Kucia <joseph.kucia(a)gmail.com> --- Created attachment 60573 --> https://bugs.winehq.org/attachment.cgi?id=60573 Mesa ATOC hack The attached Mesa patch fixes both issues with radeonsi. -- 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=44590 --- Comment #4 from Grazvydas Ignotas <notasas(a)gmail.com> --- It indeed does, thanks again. It would be nice to propose a GL_MESA_ extension for this, looks like most work would be writing the .spec file as the implementation would be trivial? I guess you could do it better but I could give that a try someday if you don't want to. This is of course only if the wine project isn't against using such MESA extension. -- 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=44590 --- Comment #5 from Józef Kucia <joseph.kucia(a)gmail.com> --- (In reply to Grazvydas Ignotas from comment #4)
It would be nice to propose a GL_MESA_ extension for this, looks like most work would be writing the .spec file as the implementation would be trivial? I guess you could do it better but I could give that a try someday if you don't want to. This is of course only if the wine project isn't against using such MESA extension.
We could use such MESA extension. We already use other MESA extensions, e.g. GLX_MESA_query_renderer. -- 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=44590 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- 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=44590 --- Comment #6 from Matteo Bruni <matteo.mystral(a)gmail.com> --- (In reply to Józef Kucia from comment #2)
Thanks for the bug report.
I haven't debugged the water reflections problem, but yes, those problems might be related. I think the source of the issue is ATOC. In OpenGL ATOC can be used only with multisampling while in Direct3D ATOC can also be used without multisampling. I haven't given it much thought, but it's probably hard to fix in any reasonable way in OpenGL. An OpenGL extension might be helpful.
Would it be an option to use multisample rendering with SAMPLES=1? AFAIK that's a thing in OpenGL, although I'm not sure how we would decide between that and normal, non multisampled rendering / render targets and if that would break other things. -- 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=44590 --- Comment #7 from Józef Kucia <joseph.kucia(a)gmail.com> --- (In reply to Matteo Bruni from comment #6)
Would it be an option to use multisample rendering with SAMPLES=1? AFAIK that's a thing in OpenGL, although I'm not sure how we would decide between that and normal, non multisampled rendering / render targets and if that would break other things.
I don't think that OpenGL implementations support multisample textures with samples=1. An OpenGL implementation is allowed to allocate more samples. Most drivers probably return a multisample texture with 2 samples. Even if drivers would support multisample textures with 1 sample, then multisample textures are quite limited. A special instruction has to be used to fetch samples from a multisample texture, so you would have to transfer data between multisample and non-multisample texture to emulate other operations. -- 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=44590 Pavlo Alkhimov <alkhimov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alkhimov(a)gmail.com --- Comment #8 from Pavlo Alkhimov <alkhimov(a)gmail.com> --- The thread seems to be abandoned yet the problem remains. Is it possible to get the correct behavior with some combination of registry settings etc.? -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla