[Bug 46304] New: Fog handling seems to be off in Prince of Persia
https://bugs.winehq.org/show_bug.cgi?id=46304 Bug ID: 46304 Summary: Fog handling seems to be off in Prince of Persia Product: Wine Version: 3.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: gw.fossdev(a)gmail.com Distribution: --- Created attachment 63028 --> https://bugs.winehq.org/attachment.cgi?id=63028 apitrace dump of frame that contains shader: Hello, I came across this by trying out Prince of Persia with virgl ad a driver and comparing it to the host. Initially I thought it was a virgl bug, but it seems to be proper wine where things go wrong: Here are my findings: When I run "wine PrinceOfPersia.exe" on the host (r600) the game is playable but when run with the virgl driver there is not contrast in the images. However, a apitrace created with virgl as driver and replayed on host also renders wrong, where a apitrace recorded on the host and run via virgl renders correctly (only op-side down, because virgl doesn't support GL_ARB_clip_control, but disabling this extension when recording the apitrace makes it possible to get exactly the same output like when run on the r600 host. The difference between the two runs in the apitrace is that when run on r600 I get a vertex shader that does: R6.w = (R6.w * vs_c[20].z); R6.w = (vs_c[20].z + -R6.w); vs_out[11].x = (vs_c[16].y + -R6.w); vs_out[10].xyzw = (R8.xyzw); setup_vs_output(vs_out); The same shader created via virgl does: R6.w = (vs_c[16].y + -R6.w); vs_out[11].x = (R6.w * vs_c[20].z); vs_out[10].xyzw = (R8.xyzw); setup_vs_output(vs_out); ffp_varying_fogcoord = gl_Position.z; gl_Position.y = gl_Position.y * pos_fixup.y; The value ffp_varying_fogcoord is not assigned a value with the r600 version. However, the following fragment shader uses this value in both cases: float fog = (ffp_fog.end - ffp_varying_fogcoord) * ffp_fog.scale; ps_out[0].xyz = mix(ffp_fog.color.xyz, ps_out[0].xyz, clamp(fog, 0.0, 1.0)); In the r600 version ffp_fog.end=0 and ffp_fog.scale=-1, and I assume that this results in clamp(fog, 0.0, 1.0) returning 1.0, and in the scene the fog effect seems to be generated differently. In the virgl version the values are ffp_fog.end=1 and ffp_fog.scale=1, and I can only assume that gl_Position too large so that clamp(fog, 0.0, 1.0) returns very small values (or even 0) and the scene gets rendered in the fog colour overlayed by some post processing effects. I have not yet investigated why wine creates different code path for the two drivers, I guess that it depends on some extension(s) that may or may not be available. The initial but report for virglrenderer can be found here: https://gitlab.freedesktop.org/virgl/virglrenderer/issues/62 -- 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=46304 --- Comment #1 from Gert <gw.fossdev(a)gmail.com> --- Created attachment 63029 --> https://bugs.winehq.org/attachment.cgi?id=63029 apitrace dump of the frame recorded on r600 that contains the shaders -- 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=46304 Gert <gw.fossdev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63028|apitrace dump of frame that |apitrace dump of frame that description|contains shader: |contains shader recorded on | |virgl -- 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=46304 --- Comment #2 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to Gert from comment #0)
I have not yet investigated why wine creates different code path for the two drivers, I guess that it depends on some extension(s) that may or may not be available.
I'm mostly on vacation, so haven't really looked at this, but part of the difference in the generated code is due to ARB_clip_control being available or not. (I.e., see the condition on the shader_glsl_fixup_position() call in shader_glsl_generate_vs_epilogue().) Are you sure those are from the same D3D source shader though? The code is very similar, but reordering e.g. vs_c[20] vs. vs_c[16] is not something wined3d would do. This also sounds suspiciously similar to bug 17423, any chance it's the same issue? -- 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=46304 --- Comment #3 from Gert <gw.fossdev(a)gmail.com> --- ARB_clip_control I disabled on the host, it made the rendering of the host strace in the guest appear up-side down, since there it is not available :) Indeed, it seems to be the same issue like the one in #17423, one difference between running the game on the host and via virgl is that on the guest it reports "wined3d_guess_card_vendor Received unrecognized GL_VENDOR "Red Hat". Returning HW_VENDOR_NVIDIA" the host is actually an AMD card with the mesa driver and virgl should also act as mesa driver. I tried to patch wine to override this and get MESA as vendor, but then it doesn't find the PCI ID, identifies the card based on supported extensions and again falls back to a Nvidia card. By setting the VideoPci*IDs to match my host card the game is rendered correctly again. I think, the best way to tackle this would be to add a video card table for virgl that that lists something that is not an Nvidia card, e.g. something that is Mesa/Gallium. Since I don't know the internals of wine how certain things are picked I'm not sure what would be the best approach here. Getting something that enabled features and quirks only by basing it on the available OpenGL version and extensions would probably be best. I'll change the title of the bug to reflect that this is not exactly a duplicate of #17423, because it can be fixed by adding something for virgl that should probably be added anyway. -- 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=46304 Gert <gw.fossdev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fog handling seems to be |The virgl driver is |off in Prince of Persia |identified as Nvidia vendor | |but should be MESA and it | |should probably not fall | |back to any Nvidia card -- 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=46304 --- Comment #4 from Gert <gw.fossdev(a)gmail.com> --- Created attachment 63061 --> https://bugs.winehq.org/attachment.cgi?id=63061 Add "Red Hat" to vendors for MESA The patch is against wine-3.21, it does not solve the problem that "virgl" doesn't have a PCI ID and wine still falls back to NVIDIA. -- 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=46304 --- Comment #5 from Gert <gw.fossdev(a)gmail.com> --- Actually virgl provides VENDOR_ID: 0x1af4; DEVICE_ID:0x1010 that should somewhere be added. -- 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=46304 --- Comment #6 from Henri Verbeet <hverbeet(a)gmail.com> --- What does it return for GL_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=46304 --- Comment #7 from Gert <gw.fossdev(a)gmail.com> --- GL_RENDERER is virgl -- 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=46304 --- Comment #8 from Henri Verbeet <hverbeet(a)gmail.com> --- Created attachment 63169 --> https://bugs.winehq.org/attachment.cgi?id=63169 patch It took me a while to get back to this. Does this patch help? -- 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=46304 --- Comment #9 from Gert <gw.fossdev(a)gmail.com> --- I get a message 0009:fixme:dxdiag:vendor_id_to_manufacturer_string Unknown PCI vendor ID 0x1af4 but then 0009:fixme:dxdiag:vendor_id_to_manufacturer_string Unknown PCI vendor ID 0x1af4 0009:warn:d3d:wined3d_adapter_gl_init Couldn't create an OpenGL 4.4 context, trying fallback to a lower version. 0009:trace:d3d:wined3d_adapter_init_gl_caps adapter 0x1d5868. 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_RENDERER: "virgl". 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_VENDOR: "Red Hat". 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_VERSION: "3.3 (Core Profile) Mesa 19.0.0-devel (git-61ff73bc07)". 0009:trace:d3d:wined3d_parse_gl_version Found OpenGL version 3.3. the a dialog shows up informing me that "Red Hat VirtIO GPU" is not supported and that there might be issues, but then the game renders fine. -- 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=46304 --- Comment #10 from Henri Verbeet <hverbeet(a)gmail.com> --- Created attachment 63173 --> https://bugs.winehq.org/attachment.cgi?id=63173 dxdiagn patch (In reply to Gert from comment #9)
I get a message
0009:fixme:dxdiag:vendor_id_to_manufacturer_string Unknown PCI vendor ID 0x1af4
but then
0009:fixme:dxdiag:vendor_id_to_manufacturer_string Unknown PCI vendor ID 0x1af4 0009:warn:d3d:wined3d_adapter_gl_init Couldn't create an OpenGL 4.4 context, trying fallback to a lower version. 0009:trace:d3d:wined3d_adapter_init_gl_caps adapter 0x1d5868. 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_RENDERER: "virgl". 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_VENDOR: "Red Hat". 0009:trace:d3d:wined3d_adapter_init_gl_caps GL_VERSION: "3.3 (Core Profile) Mesa 19.0.0-devel (git-61ff73bc07)". 0009:trace:d3d:wined3d_parse_gl_version Found OpenGL version 3.3.
the a dialog shows up informing me that "Red Hat VirtIO GPU" is not supported and that there might be issues, but then the game renders fine.
That seems in line with what'd be expected, I think. I've sent this in, and hopefully it'll make it into wine-4.0-rc5 later today. I've also attached a patch that should make the vendor_id_to_manufacturer_string() FIXME go away, but it probably doesn't make much of a difference in terms of application behaviour. -- 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=46304 --- Comment #11 from Henri Verbeet <hverbeet(a)gmail.com> --- This is fixed by 86c773fc66021b9de0dd816ce368bc879e0df1e9 and 472aa033fbeff678b9e770d0e8ff58a4388dbc59, right? -- 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=46304 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #12 from joaopa <jeremielapuree(a)yahoo.fr> --- Patches were committed by Henri. No news from the reporter since... Can an administrator close this bug as FIXED? -- 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=46304 --- Comment #13 from joaopa <jeremielapuree(a)yahoo.fr> --- Again, Henri sent a fix for this bug. Reporter did not bother to confirm. Can an administrator close this bug as FIXED? -- 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=46304 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |472aa033fbeff678b9e770d0e8f | |f58a4388dbc59 Resolution|--- |FIXED --- Comment #14 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- I think we've waited long enough, marking FIXED. -- 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=46304 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.0-rc6. -- 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=46304 --- Comment #16 from Saulius K. <saulius2(a)gmail.com> --- (In reply to joaopa from comment #13)
Reporter did not bother to confirm.
Let's think he confirmed it in the virglrenderer repo: https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/62#note_106024 --- quote --- Gert Wollny @gerddie 2 years ago | Jan 21, 2019 2:31pm GMT+0200 This seems to be fixed by wine upstream (should be included in wine 4.0) Gert Wollny @gerddie closed 2 years ago --- quote --- -- 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