That sounds absolutely incredible if it’s pulled off. It would certainly make gaming on Linux even more accessible to people not comfortable with Linux.
Who could have possibly seen that coming? It’s almost like anything other than server side anticheat is conceptually broken! (See the monitors with ML map assist and the past 20 years of client exploits). And that’s ignoring the currently strong financial incentives of breaking these things…
Any chance someone can ELI5 this for me? I've been trying to game on Linux and I'm frustrated / confused enough with wine / lutris / proton an debugging their weird setups and interactions as it is.
Right now it’s a PoC (proof of concept, a rough implementation of an idea), to emulate launching games from other stores as if they were launched from steam using proton.
What this could be used for is to create a new Linux launcher, where you setup proton once, and launch all games using this launcher.
This simplifies usage for you as the end user, since you would only need to install the launcher, and it sets up ProtonGE, and you’re done. It also enables simple Proton usage for other games (Epic, Lutris, whatever).
Additionally it helps unifying development. Windows games under Linux have a lot of moving parts: there’s Proton as a compatibility layer. There’s integration between steam, proton and your system (sniper/vessel). There’s protonfixes which is game specific changes in proton. Each of which itself consists of components and stuff I’ve missed. In short, it’s complicated. Unifying all this components with one tool, with one battle tested installation and compatibility and with a single source of truth in development could be another big step in Linux gaming.
TLDR - potentially a new launcher for games under the Linux, enabling any game to be played using proton, when supported, not only steam games.
I’m guessing it would be a CLI launcher that Heroic, Lutris, etc would use internally. As in, it wouldn’t replace those tools, it would just make running games more consistent across those tools.
So you’d still use Heroic, Lutris, or whatever you’re happy with, the experience would just be more consistent across those services so you could file bug reports in one place.
I don’t think that the current tools will be using it internally, since this would require the tools actually supporting the CLI launcher, and in the best case we would have something like the proton config in steam in every tool separately again.
I think that you will need to have your launcher installed, but you will have this new launcher as your entry point, from which you will start your games using proton from the linked project.
But - it’s a PoC right now, maybe both ways will be possible.
From a wishful perspective, it would be super neat if this new launcher would hook into the installed regular tools, and automagically make those use the preconfigured proton runtime it brings. Shouldn’t this be possible using LD_PRELOAD?
I’m mostly interested in hopefully not having multiple copies of Proton/WINE installed. I’d have maybe 3-4 for compat, instead of copies for each launcher I happen to use (e.g. Heroic vs Steam vs Lutris, etc).
Its basically bugfixes for specific games through proton. Different fames need different fixes, so you cant just make a general fix for some bugs if they only exist in one game. The new launcher promises to make one database for those fixes where all the launchers can fetch their data from instead of everyone having to do their own thing and having to fix each game separately.
Wine attempts to translate Windows calls into Linux, its developed by Codeweavers whose focus is/was application compatibility.
Valve took Wine and modify it to best support games, the result is called Proton. For example:
Someone built a library to convert DirectX 9-11 calls and turn them into Vulkan ones, it was written in C++ and is called DxVK.
Wine has strict rules on only C code and their directx library handles odd behaviour from old CAD applications.
Valve doesn't care about that, they care that the Wine DirectX library is slow and buggy and DxVK isn't. So they pull out Wines and use DxVK.
There are lots of smaller changes, these are 'Proton Fixes', sometimes Proton Fixes are passed on to Wine. Sometimes they can't but discussion happens and a Wine fix is developed.
It’s nice that we could see more rust in the kernel beyond drivers.
Though looking at his code/documentation, it seems that the big win here is moreso giving higher time-slice values to applications that identify themselves as “interactive”.
This is a similar concept to what I’ve seen happen in MacOS, where even running unit tests for my work application doesn’t bog down the rest of the system. In windows, however, a single heavy process can bring the whole system down to a crawl.
Rust does have the benefit of being 1. safer on memory (though it uses unsafe blocks here) and 2. a lot easier to parse compared to (imo) archaic versions of C. Even this hobby project has some pretty impressive readability compared to some parts of the kernel that I’ve tried to read for the fun of it.
I wouldn’t be surprised if this was essentially just a common result of refactoring code. Rust might help compile to more efficient C than the stuff people write on their own? But my code is always more performant after a refactor. Surely writing this in another language would cause someone to look deeper at the choices being made during development. Even the scheduler might have some technical debt.
The main improvement Rust provides is memory safety. It’s very easy to make mistakes in C where you could overrun a buffer or something, introducing unexpected crashing and making it vulnerable to exploitation by malware or whatever. Rust eliminates a whole category of issues with their clever memory management paradigm. The improvements in this schedule probably have more to do with the strategy used than code efficiency.
C and Rust are low level languages, suitable for interacting directly with the hardware. C++ might be described as C with some object oriented stuff bolted on, making it excellent for videogame development. C# is a lot more like Java. It’s great for line of business apps because it handles the complexity of memory management for you and provides an excellent framework and excellent libraries for a lot of common tasks. But it’s not suitable for low level work.
Linux has quite a few schedulers. The performance of this new one is almost certainly a result of different algorithms used, not an effect of refactoring the existing ones, nor the language it’s written in.
I don’t think I’ll dig in to the code just now, but if it turns out to have much practical value, perhaps we’ll eventually see an article about the design.
Yeah, a scheduler just decided which processes get CPU time and takes up a very small part of total execution time. So yeah, I wouldn’t expect compiler optimizations to matter much.
sched-ext is the proof of concept. It has a demo video if you follow the link to the mailing list in the article showing it improving performance in games that are normally CPU bottlenecked when the CPU is given a heavy background task.
It’s scheduler improvements though, so it’s not really a measurable improvement (or at least not easily measurable) to performance as a whole but it can result is a more responsive system under load.
The Wine team is proud to announce that the stable release Wine 9.0 is now available.
This release represents a year of development effort and over 7,000 individual changes. It contains a large number of improvements that are listed below. The main highlights are the new WoW64 architecture and the experimental Wayland driver.
Wine is available thanks to the work of many people. See the file AUTHORS for the complete list.
What’s new in Wine 9.0
WoW64
All transitions from Windows to Unix code go through the NT syscall interface. This is a major milestone that marks the completion of the multi-year re-architecturing work to convert modules to PE format and introduce a proper boundary between the Windows and Unix worlds.
All modules that call a Unix library contain WoW64 thunks to enable calling the 64-bit Unix library from 32-bit PE code. This means that it is possible to run 32-bit Windows applications on a purely 64-bit Unix installation. This is called the new WoW64 mode, as opposed to the old WoW64 mode where 32-bit applications run inside a 32-bit Unix process.
The new WoW64 mode is not yet enabled by default. It can be enabled by passing the –enable-archs=i386,x86_64 option to configure. This is expected to work for most applications, but there are still some limitations, in particular:
Lack of support for 16-bit code.
Reduced OpenGL performance and lack of ARB_buffer_storage extension support.
The new WoW64 mode finally allows 32-bit applications to run on recent macOS versions that removed support for 32-bit Unix processes.
Wayland driver
There is an experimental Wayland graphics driver. It’s still a work in progress, but already implements many features, such as basic window management, multiple monitors, high-DPI scaling, relative motion events, and Vulkan support.
The Wayland driver is not yet enabled by default. It can be enabled through the HKCUSoftwareWineDrivers registry key by running:
and then making sure that the DISPLAY environment variable is unset.
ARM64
The completion of the PE/Unix separation means that it’s possible to run existing Windows binaries on ARM64.
The loader supports loading ARM64X and ARM64EC modules.
The 32-bit x86 emulation interface is implemented. No emulation library is provided with Wine at this point, but an external library that exports the interface can be used, by specifying its name in the HKLMSoftwareMicrosoftWow64x86 registry key. The FEX emulatorimplements this interface when built as PE.
There is initial support for building Wine for the ARM64EC architecture, using an experimental LLVM toolchain. Once the toolchain is ready, this will be used to do a proper ARM64X build and enable 64-bit x86 emulation.
Graphics
The PostScript driver is reimplemented to work from Windows-format spool files and avoid any direct calls from the Unix side.
WinRT theming supports a dark theme option, with a corresponding toggle in WineCfg.
The Vulkan driver supports up to version 1.3.272 of the Vulkan spec.
A number of GdiPlus functions are optimized for better graphics performance.
Direct3D
The multi-threaded command stream sleeps instead of spinning when not processing rendering commands. This lowers power consumption in programs which do not occupy the command stream’s entire available bandwidth. Power consumption should be comparable to when the multi-threaded command stream is disabled.
Direct3D 10 effects support many more instructions.
Various optimizations have been made to core WineD3D and the Vulkan backend.
The Vulkan renderer properly validates that required features are supported by the underlying device, and reports the corresponding Direct3D feature level to the application.
D3DXFillTextureTX and D3DXFillCubeTextureTX are implemented.
The legacy OpenGL ARB shader backend supports shadow sampling via ARB_fragment_program_shadow.
The HLSL compiler supports matrix majority compilation flags.
D3DXLoadMeshHierarchyFromX and related functions support user data loading via ID3DXLoadUserData.
Audio / Video
The foundation of several of the DirectMusic modules is implemented. Many tests are added to validate the behavior of the dmime sequencer and the dmsynth MIDI synthesizer.
DLS1 and DLS2 sound font loading is implemented, as well as SF2 format for compatibility with Linux standard MIDI sound fonts.
MIDI playback is implemented in dmsynth, with the integration of the software synthesizer from the FluidSynth library, and using DirectSound for audio output.
Doppler shift is supported in DirectSound.
The Indeo IV50 Video for Windows decoder is implemented.
DirectShow
The Windows Media Video (WMV) decoder DirectX Media Object (DMO) is implemented.
The DirectShow Audio Capture filter is implemented.
The DirectShow MPEG‑1 Stream Splitter filter supports video and system streams as well as audio streams.
The DirectShow MPEG‑1 Video Decoder filter is implemented.
Input devices
DirectInput action maps are implemented, improving compatibility with many old games that use this to map controller inputs to in-game actions.
Desktop integration
URL/URI protocol associations are exported as URL handlers to the Linux desktop.
Monitor information like name and model id are retrieved from the physical monitor’s Extended Display Identification Data (EDID).
In full-screen desktop mode, the desktop window can be closed through the “Exit desktop” entry in the Start menu.
Internationalization
IME implementation is improved, with better support for native Windows IME implementations. Many tests are added to validate the expected behavior of these custom IMEs.
Linux IME integration is improved, using over-the-spot or on-the-spot input styles whenever possible, and more accurate IME message sequences.
Locale data is generated from the Unicode CLDR database version 44. The following additional locales are supported: bew-ID, blo-BJ, csw-CA, ie-EE, mic-CA, prg-PL, skr-PK, tyv-RU, vmw-MZ, xnr-IN, and za-CN.
The user interface is translated to Georgian, bringing the total of full translations to 16 languages, with partial translations to another 31 languages.
Unicode character tables are based on version 15.1.0 of the Unicode Standard.
The timezone data is generated from the IANA timezone database version 2023c.
Locales using a script name, like zh-Hans, are also supported on macOS.
Kernel
The default Windows version for new prefixes is set to Windows 10.
Address space layout randomization (ASLR) is supported for modern PE binaries, to avoid issues with address space conflicts. Note that the selected load addresses are not yet properly randomized.
The Low Fragmentation Heap (LFH) is implemented for better memory allocation performance.
The virtual memory allocator supports memory placeholders, to allow applications to reserve virtual space.
The 64-bit loader and preloader are built as position-independent executables (PIE), to free up some of the 32-bit address space.
Stack unwinding works correctly across NT syscalls and user callbacks.
Internet and networking
All builtin MSHTML objects are proper Gecko cycle collector participants.
Synchronous XMLHttpRequest mode is supported in MSHTML.
WeakMap object is implemented in JScript.
The Gecko engine is updated to version 2.47.4.
Network interface change notifications are implemented.
Cryptography and security
Smart cards are supported in the Winscard dll, using the Unix PCSClite library.
The WineDump tool supports printing the contents of Windows registry files (REGF format), as well as printing data for both architectures in hybrid x86/ARM64 PE files.
The composable, default_overload, deprecated, and protected attributes are supported in the IDL compiler.
The libwine.so library is removed. It was no longer used, and deprecated since Wine 6.0. Winelib ELF applications that were built with Wine 5.0 or older will need a rebuild to run on Wine 9.0.
Bundled libraries
The FluidSynth library version 2.3.3 is bundled and used for DirectMusic.
The math library of Musl version 1.2.3 is bundled and used for the math functions of the C runtime.
The Zydis library version is 4.0.0 is bundled and used for x86 disassembly support.
Vkd3d is updated to the upstream release 1.10.
Faudio is updated to the upstream release 23.12.
LDAP is updated to the upstream release 2.5.16.
LCMS2 is updated to the upstream release 2.15.
LibMPG123 is updated to the upstream release 1.32.2.
LibPng is updated to the upstream release 1.6.40.
LibTiff is updated to the upstream release 4.6.0.
LibXml2 is updated to the upstream release 2.11.5.
LibXslt is updated to the upstream release 1.1.38.
Zlib is updated to the upstream release 1.3.
External dependencies
The Wayland client library, as well as the xkbcommon and xkbregistry libraries, are used when building the Wayland driver.
The PCSClite library is used for smart card support. On macOS, the PCSC framework can be used as an alternative to PCSClite.
For PE builds, a cross-compiler that supports .seh directives for exception handling is required on all platforms except i386.
Finally not having to enable 32bit support just for Steam won’t be necessary anymore. Now distros might actually be able to drop 32 bit packages, without anyone caring.
It should do the job just fine. I have the TUF from 2023 and it took a while for the keyboard drivers to reach the kernel, but yours should be there on any recent distro.
Stating your experience level and distros that you’re interested in would be helpful, but in lieu of that, here’s my recommendation.
Make a windows restore USB, so you can restore your system if either of these distros don’t seem to work out for you.
First, try Linux Mint. Install it, try to exist in it for a while and see if all of your hardware functions the way it should. Learn some stuff. Mint makes it easy for the most part. Drivers are simple and everything can be done in the GUI.
If Mint has hardware issues, try endeavourOS. It’s a rolling release, running on a fresher version of the kernel, with possibly better support for your hardware. It’s a bit more command line focused. Keep it simple. Update weekly using yay, and see how it goes.
If neither works for you, break out that windows USB and go back to the drawing board, or keep digging. Linux is a less intimidating experience than it used to be, but it still generally requires an active learner who wants to solve problems as they arise and learn more about Linux in the process.
linux_gaming
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.