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@winehq.org Reporter: notasas@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...
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #1 from Grazvydas Ignotas notasas@gmail.com --- Created attachment 60572 --> https://bugs.winehq.org/attachment.cgi?id=60572 good rendering
https://bugs.winehq.org/show_bug.cgi?id=44590
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@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@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #3 from Józef Kucia joseph.kucia@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #4 from Grazvydas Ignotas notasas@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #5 from Józef Kucia joseph.kucia@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #6 from Matteo Bruni matteo.mystral@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
--- Comment #7 from Józef Kucia joseph.kucia@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.
https://bugs.winehq.org/show_bug.cgi?id=44590
Pavlo Alkhimov alkhimov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alkhimov@gmail.com
--- Comment #8 from Pavlo Alkhimov alkhimov@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.?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla