Live data from Hacker News

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

xda-developers.com

21–30 of 512 posts

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

#21

Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.

Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.

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

#22
post #3

it seems if you want the same on macOS, this is the place to contribute: https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...

That's interesting. I thought the point was that it needed to be in-kernel for performance reasons; if it works in userspace why did linux not do that?

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

#24
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/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)

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

#25

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…

>These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux uses

Not for anyone using a kernel without these patches. Which would be most people.

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

#26

Earlier quoted context omitted.

Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.

I wouldn't be surprised if Wine eventually becomes more stable than Windows.

It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).

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

#28
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.

* when not using esync nor fsync

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

#29

Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.

Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.

Building against the Steam runtime containers seems like the other route, which also gets you more stability.
Post reply on HN