With the upcoming next-gen Expanded & Enhanced game edition and the various rumors surrounding the aforementioned about RAGE being updated to the contemporary RDR3 version (which thankfully is already supported by RedM), I was left wondering if we will ever get our chance at seeing an official Vulkan-only Linux client build of the platform.
Maybe. There’s still a few issues which remain for cross-platform builds:
- Shared surface handle support. This is a no-go for DXVK on Wine due to NT handle dependencies, but any native loader may have this be a bit simpler, assuming Chromium gl_image_* APIs are more workable to use other platforms’ file descriptor sharing and GPU drivers play along on these platforms.
- Anticheat obfuscation. There’s a lot of dependencies on x86/AMD64 single-architecture WinNT in here, this would need adapting for Linux bionic/glibc systems, but also for ARM64 WinNT.
- Platform runtime: ideally we’d make the entire codebase cross-platform as to not rely on the hot mess that is Wine, but this would entail making every single component that currently may assume some Windows/MSVC-isms portable, including some dependencies on high-level Windows components. The game itself is the least concerning here as RAGE doesn’t use many high-level Windows APIs to any extent that makes them non-trivial to reimplement using e.g. the .NET PAL.
This is probably the least likely thing to happen short-term as the next-next-gen release (2022? if at all) will have many more important portability concerns at first, especially if the MSVC compiler gets upgraded as we’ll have to port thousands of patterns to a new compiler then.
There’s not much that prevents this from happening even for the current game version (DXVK-Native when rebased to newer DXVK runs the game fairly decently under the Rotor PAL as shown with the Android porting effort, and should be a lot more trivial to add
VK_KHR_external_memory_fd mapping to), except for the fact that there’s not really enough time to work on everything including this at once, and the likelihood to need to throw away a lot of stuff depending on how GTA V on PC gets migrated to future platform releases.
Very explicative, thanks for the reply.
Excuse me for the necro.
With the impending release of Valve’s Steam Deck (which runs on a fork of Arch) boosting this feature on the priority list would be amazing. Windows can be installed on the device - as confirmed by Valve - but it would definitely be tedious if not frightening for the average user.
Over half a year in the future, or more depending on production capacity. Hell, we don’t even know how the third-party app situation will be at all on the default distro if outside the ‘happy’ Steam flow.
Ideally Linux would have workable GPU-PV support by then even if by means of Mesa D3D10UMD being somehow viable over VirtIO, but that’s not very… likely.
Time flies so fast half a year is impending for me lmao, sorry for this foul misconception.
FiveM works great on KVM + QEMU with GPU passthrough, VirtIO drivers and everything set up correctly. Having to populate a working Windows 10 image would have been a complete hassle if I wasn’t an Oculus user and being forced to do it.
DXVK/Proton is ok, it runs GTA V absolutely fine out of the box.
Isn’t Wine compulsory due to game libraries relying on Windows functions?
(Even in the presence of an official Vulkan implementation)
You could also look into this next-generation piece of software aiming to nixe x64 CI pipelines, Cosmopolitan Libc. I can’t properly visualize how convenient it would be for usage in this application, just tossing some ideas around. But I’m seeing the issue with the anticheat not being libc compatible here.
Nope, the work on mobile porting actually showed that game code actually depends on so few APIs it took around 3 days to reimplement all of the important ones.
I’d write a longer post about some of the tech involved in these plans but my browser seems buggy right now and the composer is getting progressively more blurry so that’s a nope for now…