Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

xda-developers.com

Post reply on HN
Print view View original

211–220 of 512 posts

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#211

Post by Dystakruul »

gpderetta wrote: post #143
ToucanLoucan wrote: post #123

Earlier quoted context omitted.

So, what's the relationship between Wine and Proton? Is Proton just the SteamOS/Valve name for it, or is it actually it's own project?

More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.

There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.

I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.

[1] https://github.com/GloriousEggroll/proton-ge-custom

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#212

Post by em-bee »

seba_dos1 wrote: post #197
em-bee wrote: post #183

Earlier quoted context omitted.

The only problem with this approach is that glibc cannot have multiple versions running at once that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning. this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workaro…

You compile in a container/chroot with the userspace you target. Done. In the context of games, that will likely be Steam Runtime.

it's not that simple. you want to be able to use a modern toolchain (compilers that support the latest standards) but build a binary that runs on older systems.

the only way to achieve that is to get the older libraries installed on a newer system, or you could try backporting the new toolchain to the older system. but that's a lot harder.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#213

Post by kvemkon »

watashiato wrote: post #19

Before anyone gets too excited about ntsync, the performance gains are (with few exceptions) mild, usually in the lower single percentage range. These extreme gains are the result of benching against vanilla wine without fsync, anyone playing demanding games on linux would have been doing so using fsync. This is mentioned in the article but treated like a side note. I've been running benchmarks between both and while…

> usually in the lower single percentage range

Is it worth to compare Wayland vs X11?

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#214

Post by orbital-decay »

alilikestech wrote: post #176
tombert wrote: post #16

Wine is a project that I've grown a near-infinite level of respect for. I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product. The fact that Wine runs…

With AI, you can automate all the grunt work.

AI unreliability aside, Microsoft suing the hell out of them was always a concern. They do clean room reimplementation to insulate themselves from legal risks as much as possible, another incentive is not what anyone wants.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#215

Post by ElectricalUnion »

torginus wrote: post #190
bmenrigh wrote: post #24

Earlier quoted context omitted.

Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases). That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests. (And it case it's not clear, ntsync is https://docs.kernel.org/…

Do they have any other usecase behind Wine? My guess would be MS SQL server, but is that correct?

Starting with SQL Server 2017, native Linux support exists. Probably because of Azure.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#216

Post by bombcar »

usrusr wrote: post #207
coldpie wrote: post #142

Earlier quoted context omitted.

> It is interesting that these are harder to get working than games. Games are mostly just doing their own thing, only interacting with the system for input & output. MS Office is using every single corner of Windows: every feature in the XML libraries, tons of .NET type stuff, all the OLE and COM and typelib and compound storage features, tons of Explorer integrations, auto-updating stuff via Windows patching mechan…

So that's what's keeping Microsoft from just running WINE on an MS-flavored Linux or perhaps a clean slate kernel as their next OS. I've been wondering for a while, this is by far the best explanation.

The Windows Kernel (and arguably the Windows APIs) are the only good part of Windows; they should dump everything else and run Linux above it; wait they did do that and then changed it to a boring VM.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#217

Post by akdev1l »

em-bee wrote: post #183
akdev1l wrote: post #168

Earlier quoted context omitted.

Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work >If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. Not really a show stopper, vendo…

The only problem with this approach is that glibc cannot have multiple versions running at once that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning. this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workaro…

glibc must match the linker so you would need a separate linker and the binaries usually have a hardcoded path to the system linker (and you need to binary patch the stuff - https://stackoverflow.com/questions/847179/multiple-glibc-li...)

So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#218

Post by Levitating »

bmenrigh wrote: post #24
hu3 wrote: post #15

> Dirt 3 went from 110.6 FPS to 860.7 FPS > Resident Evil 2 jumped from 26 FPS to 77 FPS > Call of Juarez went from 99.8 FPS to 224.1 FPS > Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS Amazing. I don't understand the low level details on how such a massive speed gain was ripe for the picking but I welcome! I guess thanks Valve for pouring money into Proton.

Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases). That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests. (And it case it's not clear, ntsync is https://docs.kernel.org/…

Though like the article mentions, fsync doesn't work out of the box (requiring kernel patches).

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#219

Post by sneak »

tombert wrote: post #16

Wine is a project that I've grown a near-infinite level of respect for. I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product. The fact that Wine runs…

It’s astounding how badly Microsoft had to fumble their complete and unassailable monopoly on the standard video game runtime (ie Windows) for an upstart like Valve to be able to get WINE/Proton into a place where this is now possible.

The mind reels. They had the biggest moat in tech, and now small shops are easily tossing homemade ladders across the gap. AAA gaming is an industry larger than all of Hollywood, and Windows is no longer a critical component. This is incompetence on an unthinkable scale.

I wonder when and how Excel’s stranglehold will eventually be cracked, and if I will live to see it. Perhaps the new agentic universe will cause someone to finally make the Pixelmator of Excel.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#220

Post by akdev1l »

genthree wrote: post #122
kelnos wrote: post #92

Earlier quoted context omitted.

I would assume most of them? I'd be surprised if distros like Debian, Ubuntu, Fedora, etc. would ship non-mainline kernel features like that. Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream ? Probably not. Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close…

Last I checked, every distro of note had its own patchset that included stuff outside the vanilla kernel tree. Did that change? I admit I haven't looked at any of that in... oh, 15 years or so.

Depends on the distro.

Fedora looks like it carries a whooping 2 patches on top of upstream

Post reply on HN