[Bug 47883] New: Enable explicit large address aware override
https://bugs.winehq.org/show_bug.cgi?id=47883 Bug ID: 47883 Summary: Enable explicit large address aware override Product: Wine Version: 4.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Some 32-bit games like Dragon Age: Origins start without sound in recent Wine versions (see for example bug 43685), due to running out of 2 GB memory limitations. One workaround is to use a patcher on the binary to enable large address aware bit. Such as: https://github.com/randomstuff/pe-set-laa This is cumbersome however. Please enable some explicit workaround (like some Wine environment variable for example), to avoid using patching on the binaries. -- 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=47883 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- How does it behave on Windows? -- 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=47883 --- Comment #2 from Shmerl <shtetldik(a)gmail.com> --- (In reply to Austin English from comment #1)
How does it behave on Windows?
Good question, I haven't test it personally. But it's quite possible that due to different underlying libraries and different allocations, on Windows the same program won't run out of virtual memory limit for 32-bit. Another common case is for example using d9vk instead of wined3d. The former might run out of RAM faster due to doing different allocations for Vulkan use case. Since authors of such games didn't anticipate all these cases, they didn't flip that LAA flag on the binary. Doing it with a patcher is a fix, but the point is to have a a simpler option to force such behavior regardless of the flag. It would provide an easy to access workaround. -- 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=47883 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com Severity|normal |enhancement --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Austin English from comment #1)
How does it behave on Windows?
The request is to add a generic configurable workaround for a bug that cannot be properly fixed in a generic sense. The workaround is generic but not universal, either because applications truncate the high bit(s) [which is why the LAA flag exists] or because it's simply not enough to alleviate address space pressure. There isn't really anything comparable on Windows; it "works" because there just isn't that much pressure (except when there is). -- 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=47883 --- Comment #4 from Rafał Mużyło <galtgendo(a)o2.pl> --- So, as I've mentioned on irc, recently gstreamer began to hang some of wine apps (that were running fine before) by running out of resources. A hint by zf suggested those resources is actually address space. That led me to an experiment: I've set large address aware bit on the executable in question. Given that the hang was randomly triggered and took quite a bit of time, I can't be sure it *definitely* solved the problem, but for the time being it does seem 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.
https://bugs.winehq.org/show_bug.cgi?id=47883 soredake <gi85qht0z(a)relay.firefox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gi85qht0z(a)relay.firefox.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=47883 --- Comment #5 from Rafał Mużyło <galtgendo(a)o2.pl> --- Finally got the app running long enough to get a valid result. Now, again, I can't say I'm certain the crash is gone, but it didn't happen in quite awhile. Yet, winegstreamer is leaking something somewhere. After a long enough run, 'too many allocated handles, not caching' from wine server becomes quite common in the output. -- 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=47883 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch --- Comment #6 from mirh <mirh(a)protonmail.ch> --- This is how proton does it. https://github.com/ValveSoftware/wine/commit/9de03fa9a529298d698b4be4c380739... I guess it becomes kind of a very handy shortcut when you have programs (well, games) starved for virtual memory left and right.. but if bug 44375 was to be fixed then the use case would be just as "niche" as it already is on Windows. -- 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=47883 --- Comment #7 from Shmerl <shtetldik(a)gmail.com> --- (In reply to mirh from comment #6)
This is how proton does it. https://github.com/ValveSoftware/wine/commit/ 9de03fa9a529298d698b4be4c380739c68958d00
I guess it becomes kind of a very handy shortcut when you have programs (well, games) starved for virtual memory left and right.. but if bug 44375 was to be fixed then the use case would be just as "niche" as it already is on Windows.
It would be good to upstream that variable override to Wine from Proton. And I doubt such thing can be fixed in a generic fashion as above that will help all use cases. Wine doesn't handle something like overrides with dxvk / vkd3d-proton and such which can have their own RAM needs that differ from how Windows does things. So simply having a switch gives some flexibility for those who need it and it's easier than patching binaries. -- 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=47883 --- Comment #8 from mirh <mirh(a)protonmail.ch> --- As explained in bug 33858 (not really sure what that is eventually about tbh), there's nothing to "fix" to begin with. I *guess* that if some of the apis wine uses was proven to be "inherently and inevitably" bigger, this evaluation may be subject to change then.. but for the time being the mood seems to be that you are more likely to find bugs against individual components that need improvement. Even the infamous dxvk memory penalty was allegedly fixed last week, just with some brain put on the allocation strategy. (as for vkd3d, it seems a pretty bad example to make given that I can hardly think to 32-bit dx12 applications) -- 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=47883 soredake <broaden_acid002(a)simplelogin.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002(a)simplelogin | |.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.
participants (1)
-
WineHQ Bugzilla