E&E engine update & Vulkan-only (shared resource-less) Linux client

NoxOverFlow · 2021-07-03T18:50:28.925Z

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.

nta · 2021-07-03T18:58:12.065Z

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.

NoxOverFlow · 2021-07-03T19:09:00.070Z

Very explicative, thanks for the reply.

NoxOverFlow · 2021-07-15T19:06:49.781Z

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.

nta · 2021-07-15T19:23:39.240Z

impending release

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.

NoxOverFlow · 2021-07-15T19:51:19.222Z

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.

nta · 2021-07-15T21:02:32.541Z

NoxOverFlow:

Isn’t Wine compulsory due to game libraries relying on Windows functions?

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…

Pained_Psyche · 2021-09-09T17:14:58.166Z

I’m really glad I found this thread, it gives at least a glimmer of hope that FiveM client will someday be possible to run on Linux regardless of whether wine or dxvk devs ever sort out their gaping API hole.

nta:

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.

I feel like getting rid of these dependencies and MSVC-specific code would be a great improvement anyway and should be a high priority.

nta:

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.

What do you mean by “if at all”? Is it actually possible that this next gen release is going to be console-exclusive? That would only simplify things, you could safely assume that what you got now to work with is final and no “throwing away” is going to be necessary.

I’m guessing that as soon as Rockstar announces whether or not the PC release happens or not, decisions will be made and there’s going to be a big FiveM announcement?

In the event that the release will happen on PC and with it the game actually gets a Vulkan renderer, have you considered taking advantage of it and just using VK_KHR_external_memory_fd on Windows too?

nta:

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.

If the main obstacle is the team being strapped for time… Is there any chance for this Android porting effort to be packed into a git branch and published on FiveM’s github to serve as an outline so that the development of Linux client could potentially be started/continued ‘the linux way’ - in the bazaar style?

nta · 2021-09-10T06:39:11.339Z

Pained_Psyche:

and should be a high priority.

No it shouldn’t, it’s a lot of painful effort with no noticeable beneficial outcome at all, and only potential regression risks.

Pained_Psyche:

or not

implying R* ever announces something not happening.

Pained_Psyche:

advantage of it

Pained_Psyche:

on Windows

lol, Vulkan is a piece of shit on any platform, especially on Windows

Pained_Psyche:

Is there any chance for this Android porting effort to be packed into a git branch and published on FiveM’s github to serve as an outline so that the development of Linux client could potentially be started/continued ‘the linux way’ - in the bazaar style?

No. You’re being way too naive as to your assumptions anyone will even implement this, on top of legal concerns with any distribution of the current implementation.

If people were skilled enough someone’d have added shared resources to DXVK or so already so you bunch can have fun, but so far it’s just dreamers, no doers.

nta · 2021-09-10T06:39:14.648Z

Closing this as it became yet another topic for Linux dreamers to randomly bump.