[Bug 55981] New: Dragon Age Origins: Runs slowly when using the experimental wow64 mode
https://bugs.winehq.org/show_bug.cgi?id=55981 Bug ID: 55981 Summary: Dragon Age Origins: Runs slowly when using the experimental wow64 mode Product: Wine Version: 8.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: berillions(a)gmail.com Distribution: --- Created attachment 75572 --> https://bugs.winehq.org/attachment.cgi?id=75572 Dragon Age : Origins main menu with new wow64 + OpenGL renderer Dragon Age : Origins works with the new wow64 experimental mode but it's very slowly and unplayable. This bug affect "Beyond Good & Evil" too. Use DXVK fix this issue so something wrong with new wow64 + opengl 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=55981 Maxime <berillions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #75572|0 |1 is obsolete| | -- 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=55981 --- Comment #1 from Maxime <berillions(a)gmail.com> --- Created attachment 75573 --> https://bugs.winehq.org/attachment.cgi?id=75573 New wow64 mode + OpenGL renderer I attach .mp4 video to show the issue. Download the file and watch it. -- 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=55981 --- Comment #2 from Maxime <berillions(a)gmail.com> --- Created attachment 75574 --> https://bugs.winehq.org/attachment.cgi?id=75574 New wow64 mode + DXVK -- 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=55981 Maxime <berillions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Dragon Age Origins: Runs |D3D9 games run slowly when |slowly when using the |using the experimental |experimental wow64 mode |wow64 mode -- 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=55981 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |opengl CC| |z.figura12(a)gmail.com Ever confirmed|0 |1 Summary|D3D9 games run slowly when |GL applications (and d3d |using the experimental |applications using the GL |wow64 mode |backend) are slow in new | |wow64 --- Comment #3 from Zeb Figura <z.figura12(a)gmail.com> --- This is unfortunately expected. It's a problem at the GL level; we can't map buffers into the low 32 bits (and can't give a 64-bit pointer to a 32-bit application). For Vulkan it's less of a problem since we use EXT_external_memory_host, but this comes with its own limitations. In order to solve it we'll need extensions that let us control mapped buffer placement. One is in progress (and possibly even done?) for Vulkan, but as far as I'm aware nobody has even started work on such an extension for 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.
https://bugs.winehq.org/show_bug.cgi?id=55981 --- Comment #4 from Rafał Mużyło <galtgendo(a)o2.pl> --- What's your take on mr3460 in this context ? -- 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=55981 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- 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=55981 --- Comment #5 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...also mr3047 by the same author ? (not sure whether or not those two are independent) -- 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=55981 --- Comment #6 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Rafał Mużyło from comment #4)
What's your take on mr3460 in this context ?
I don't have any opinions on it. -- 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=55981 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zwoho55(a)protonmail.com --- Comment #7 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 56220 has been marked as a duplicate of 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.
https://bugs.winehq.org/show_bug.cgi?id=55981 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, performance, | |wow64 URL| |https://cncnz.com/games/tib | |erium-wars/demo-information | |-download/ -- 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=55981 Shmerl <shtetldik(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik(a)gmail.com -- 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=55981 --- Comment #8 from Shmerl <shtetldik(a)gmail.com> --- Did anyone plan to draft an OpenGL proposal for it? Would it need be some Mesa specific extension first? -- 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=55981 nerdistmonk <nerdistmonk(a)fastmail.fm> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nerdistmonk(a)fastmail.fm --- Comment #9 from nerdistmonk <nerdistmonk(a)fastmail.fm> --- Some enhancements to this bug: This is based on the current configuration of Wine 9.11 compiled in wow64 mode, using DXVK + vkd3d-proton (latest versions of both), Directx June 2010, Nvidia Physx, Wine Mono and Wine Gecko are installed on a fresh prefix. I tested a total of 112 games, all of which were 32-bit architecture, out of that, 97 of them are working as designed, a few needed either ddrawcompat (version 0.4.0 is the only one working on my wine right now) or dgvoodoo2 (version 2.79.1 is the only one working on my wine right now). The ones that did not work have no rhythm or reason to them, they ranged from as old as 1997 and as new as 2010. Games that used directx7 like Operation Flashpoint (Now known as Arma Cold War assault) Games that used directx8 like TOCA Race Driver 2 Games that used directx9 like Alpha Protocol Games that used directx10/11 like Red Faction Guerilla (the steam version, not the remaster, not the GFW Live version) -- 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=55981 --- Comment #10 from nerdistmonk <nerdistmonk(a)fastmail.fm> --- (Yes I am aware that I am not on wined3d/opengl, clearly I am on vulkan for any game that uses directX 9 and up, but it appears to be the same bug all the same) Call of Juarez is exhibiting this bug also in both Directx10 and Directx9 modes, separate executables for each mode, which seems to lend credence to the only pattern I can see here: This isn't a graphics related bug, it's something else, because the OP is using opengl, I am using vulkan, yet the same issue is present, and it's present in such a wide era of gaming, all of which use different APIs. (and yes, CoJ has the bug even with dgvoodoo) -- 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=55981 --- Comment #11 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to nerdistmonk from comment #10)
(Yes I am aware that I am not on wined3d/opengl, clearly I am on vulkan for any game that uses directX 9 and up, but it appears to be the same bug all the same)
Call of Juarez is exhibiting this bug also in both Directx10 and Directx9 modes, separate executables for each mode, which seems to lend credence to the only pattern I can see here: This isn't a graphics related bug, it's something else, because the OP is using opengl, I am using vulkan, yet the same issue is present, and it's present in such a wide era of gaming, all of which use different APIs.
(and yes, CoJ has the bug even with dgvoodoo)
This is a different bug then, please file it separately. -- 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=55981 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28(a)yahoo.es -- 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=55981 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m1m1k4tz(a)protonmail.com --- Comment #12 from Fabian Maurer <dark.shadow4(a)web.de> --- *** Bug 55213 has been marked as a duplicate of 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.
https://bugs.winehq.org/show_bug.cgi?id=55981 --- Comment #13 from Shmerl <shtetldik(a)gmail.com> --- Any news on that OpenGL extension that's required for it? I think it would be neat for Mesa to get GL_MESA_... one first if no one else would do it so far. -- 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=55981 Stephen Griffiths <computing(a)stevegriff.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |computing(a)stevegriff.com -- 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=55981 Chiitoo <chiitoo(a)gentoo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chiitoo(a)gentoo.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.
http://bugs.winehq.org/show_bug.cgi?id=55981 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erwiniosef(a)gmail.com --- Comment #14 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 58081 has been marked as a duplicate of 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.
http://bugs.winehq.org/show_bug.cgi?id=55981 --- Comment #15 from Shmerl <shtetldik(a)gmail.com> --- For the reference if anyone was searching, there was some idea of an extension: GL_MESA_placed_allocation. Not sure how far that progressed though, it didn't get to Khronos it seems. -- 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=55981 --- Comment #16 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 58081 has been marked as a duplicate of 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.
http://bugs.winehq.org/show_bug.cgi?id=55981 Matthew <mawesome960(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mawesome960(a)gmail.com --- Comment #17 from Matthew <mawesome960(a)gmail.com> --- This seems to be the thread for the issue I ran into earlier this week trying to get the Warcraft 3 map editor running. It's a 32-bit application that uses DirectX9, I was using the version from version 1.30 of the game (downloaded off the Hive and using my old CD keys). Running without dxvk resulted in the application getting around two frames per second and being borderline unusable. The logs contained a fixme "Doing a copy of a mapped buffer (expect performance issues)", which I traced to unix_wgl.c in the opengl32 dll wine source code. If that's the same root cause as other issues in this thread, it sounds unavoidable for now. Using DXVK caused the application to crash shortly after opening with a "DxvkMemoryAllocator: Memory allocation failed" message in the logs; research suggested that was related to 32-bit applications running out of address space for vulkan objects and was essentially unavoidable for my situation. I eventually got the application working by making a fresh win32 wine prefix and running under that. It ran fine and it works for me for now. Mostly posting this because I saw the recent Brodie Robertson youtube video "Maybe Fedora Linux Was Right All Along" which raised the possibility of all gaming being funneled through WoW64, and wanted to bring up the warcraft 3 world editor as an example of software for which that still doesn't work and workarounds like dxvk also don't work. The video was ambiguous over whether win32 Wine prefixes would be dropped entirely; I got the impression they weren't but wasn't sure. -- 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=55981 --- Comment #18 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Matthew from comment #17)
Mostly posting this because I saw the recent Brodie Robertson youtube video "Maybe Fedora Linux Was Right All Along" which raised the possibility of all gaming being funneled through WoW64, and wanted to bring up the warcraft 3 world editor as an example of software for which that still doesn't work and workarounds like dxvk also don't work. The video was ambiguous over whether win32 Wine prefixes would be dropped entirely; I got the impression they weren't but wasn't sure.
The new wow64 mode requires a 64-bit prefix so you need to reinstall the apps. If a distribution decides to keep 32-bit support alive then you could also just stay on an old wow64 build. -- 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=55981 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #19 from Jacek Caban <jacek(a)codeweavers.com> --- This should fix most of wow64 performance problems: https://gitlab.winehq.org/wine/wine/-/merge_requests/9032 -- 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=55981 Trass3r <trass3r(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trass3r(a)gmail.com --- Comment #20 from Trass3r <trass3r(a)gmail.com> --- (In reply to Zeb Figura from comment #3)
we'll need extensions that let us control mapped buffer placement. One is in progress (and possibly even done?) for Vulkan
https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_map_m... (In reply to Shmerl from comment #15)
GL_MESA_placed_allocation. Not sure how far that progressed though, it didn't get to Khronos it seems.
https://gitlab.winehq.org/dlesho/wine/-/compare/master...wow64_placed_alloc?... (In reply to Matthew from comment #17)
The logs contained a fixme "Doing a copy of a mapped buffer (expect performance issues)", which I traced to unix_wgl.c in the opengl32 dll
Exactly. I took a perf trace of DK2 and most of the time was spent copying 512KB of streaming buffer back and forth just for a few vertices for every DrawIndexedPrimitive.
From what I can tell it's a combination of several problems.
It uses the glMapBufferRange code path: https://github.com/wine-mirror/wine/blob/master/dlls/wined3d/context_gl.c#L2... Because ARB_buffer_storage is not supported in wow64, see the previous comment and https://gitlab.winehq.org/etaash.mathamsetty/wine/-/compare/master...cursed-... It always maps the whole streaming buffer even though it tracks the changed parts and flushes them correctly: https://gitlab.winehq.org/wine/wine/-/commit/793ac83d5b7fc0bc440714b218d607a... wow64_map_buffer does skip the copy if you use GL_MAP_INVALIDATE_* flags but wined3d fails to properly set these flags. But then you still have the copy at unmap which happens cause it doesn't track the flush range calls done by wined3d. https://github.com/wine-mirror/wine/compare/master...Trass3r:wine:map-buffer... -- 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=55981 --- Comment #21 from Chiitoo <chiitoo(a)gentoo.org> --- (In reply to Jacek Caban from comment #19)
This should fix most of wow64 performance problems: https://gitlab.winehq.org/wine/wine/-/merge_requests/9032
So far looking good with regards to PlayOnline Viewer / Final Fantasy XI Online. Thank you! -- 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=55981 Rimiz <cramea(a)proton.me> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cramea(a)proton.me --- Comment #22 from Rimiz <cramea(a)proton.me> --- (In reply to Jacek Caban from comment #19)
This should fix most of wow64 performance problems: https://gitlab.winehq.org/wine/wine/-/merge_requests/9032
Do you need to have a certain level of Vulkan/OpenGL support for this fix to work? What about drivers that only support up to Vulkan 1.2 and OpenGL 4.2? -- 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=55981 --- Comment #23 from Jacek Caban <jacek(a)codeweavers.com> --- The core Vulkan driver version doesn’t matter, the patch uses 1.0 with specific extensions enabled for maximum compatibility. Of the required extensions, the most demanding one is VK_EXT_map_memory_placed, which was designed to solve an analogous problem on the Vulkan side. It’s supported by most modern drivers, with the notable exception of llvmpipe. There’s also VK_KHR_external_memory_fd, which is widely supported across Unix systems (except on macOS, but macOS doesn’t support GL persistent storage anyway). On the GL side, the patch only makes sense if the driver supports buffer storage. That feature is core since 4.4, though earlier versions may expose it as an extension. If it’s not available, you’ll see the same performance issues with wined3d in old wow64 builds as well. Other than that, it requires the GL_EXT_memory_object_fd 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.
http://bugs.winehq.org/show_bug.cgi?id=55981 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a2906847c0c94c119b74c94f0fc | |606ca9e9f140d Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Jacek Caban <jacek(a)codeweavers.com> --- Vulkan-based GL persistent memory support has been merged. This should resolve the majority of issues, particularly those affecting the wined3d GL backend. Resolving the bug. If problems remain, please file a new 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.
http://bugs.winehq.org/show_bug.cgi?id=55981 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #25 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.18. -- 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=55981 im.tech.tac+wine(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |im.tech.tac+wine(a)gmail.com --- Comment #26 from im.tech.tac+wine(a)gmail.com --- Can still reproduce on wine-staging 10.18 as my system doesn't support Vulkan -- 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=55981 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|FIXED |--- --- Comment #27 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Tech-Tac from comment #26)
Can still reproduce on wine-staging 10.18 as my system doesn't support Vulkan
Reopening for this. -- 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=55981 --- Comment #28 from Rimiz <cramea(a)proton.me> --- Even if your system supports up to Vulkan 1.2, if your OpenGL version doesn't support the buffer storage, you still get 2 fps gaming. -- 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=55981 --- Comment #29 from Jacek Caban <jacek(a)codeweavers.com> --- I created MR with an alternative based on GL_AMD_pinned_memory: https://gitlab.winehq.org/wine/wine/-/merge_requests/9610 With that, most MESA drivers should be covered. Other than that, there is https://gitlab.freedesktop.org/mesa/mesa/-/issues/14254 for a potentially better solution. -- 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=55981 --- Comment #30 from Jacek Caban <jacek(a)codeweavers.com> --- GL_AMD_pinned_memory MR is merged. With that, we should be able to use the fallback on most Mesa drivers when sufficient Vulkan support isn't available. I think that's about as much as we can do on existing drivers. Ideally, wined3d will eventually use Vulkan by default, at which point it wouldn't need VK_EXT_map_memory_placed, which would relax driver requirements a bit. Other than that, there's the new extension. (In reply to Zeb Figura from comment #27)
Reopening for this.
I'm not sure what the criteria for resolving this bug should be then. There will always be some unsupported configurations. If users still hit this issue, it would be useful to know the exact configuration, etc, but I'm not sure we want to repurpose this bug for that. It's also possible we'll uncover more specific issues, especially with GL applications. For those, separate application-specific bugs would seem more appropriate. -- 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=55981 --- Comment #31 from Trass3r <trass3r(a)gmail.com> --- What about the more specific wined3d mapping inefficiencies described in https://bugs.winehq.org/show_bug.cgi?id=55981#c20 ? -- 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=55981 --- Comment #32 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to Trass3r from comment #31)
What about the more specific wined3d mapping inefficiencies described in https://bugs.winehq.org/show_bug.cgi?id=55981#c20 ?
They don't apply when wined3d uses persistent memory mappings (and it's now able to do so). -- 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=55981 --- Comment #33 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Jacek Caban from comment #30)
I'm not sure what the criteria for resolving this bug should be then. There will always be some unsupported configurations. If users still hit this issue, it would be useful to know the exact configuration, etc, but I'm not sure we want to repurpose this bug for that.
Well, presumably when user configurations are supported. Practically speaking, I think that means we need to implement and use a GL extension to allow 32-bit mapping. (Frankly I'm still rather confused at why we wrote an extension for Vulkan, but have been pursuing literally every other avenue than an extension for GL. Fortunately, Derek has been actually trying to do this.) -- 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)
-
WineHQ Bugzilla -
WineHQ Bugzilla