Total War: WARHAMMER Linux Requirements Announced - AMD & NVIDIA GPUs

[faldzip]

Not sure if it's "very wrong" or just time for another evolutionary jump. Traditionally all of the big jumps in HW support and functionality were in out-of-tree closed-source drivers while upstream drivers moved relatively slowly, but in the last couple of years that has turned around... so a couple of months upstream-to-distro plus every-six-month release cycle plus a few months from fast-moving to enterprise/LTS is too slow for desktop users.

That seems like great news, question is whether distros+HWvendors can respond (I don't think sticking this on Feral is the right answer, despite shoot-the-messenger being a popular game in many otherwise-civilised countries). Neither vendor-only nor distro-only is going to work, we need something that >1 vendor and >1 distro buy into.

Can you finally opensource the OpenGL+Vulkan+OpenCL and merge it to mesa or something like this? It is really anoying that for some games it is better (or even necessary) to have mesa, for some others it is better to have AMDGPU-PRO, for OpenCL you need to use AMDGPU-PRO and so on. Oh to add more to that - for Mesa it is better to use rolling release like Arch while for AMDGPU-PRO you need to use Ubuntu LTS release which is exact opposite. I that know Nvidia has only binary blob (and nouveau but you use it only for displaying desktop on more than 2 displays :P) but on the other hand - it is the only one driver which just works (mostly). So much more convenient.

[bug77]

Must be an ubuntu fanboy. Any rolling distro supports them.

You make it sound like Ubuntu is some kind of oddity in a world of rolling releases. Last I checked, it was rolling releases that you could count on your fingers (of one hand, if you don't count development repos as distributions), not the other way around.

[faldzip]

Can't edit the comment, but want to clarify that I really appreciate the work done around the AMD's linux drivers and I have 3 desktop PCs and all of them have AMD GPUs but as a guy that do not have much free time I would really like to spend it much more "productive" then on solving problems, switching/compiling drivers and so on. So the situation is much better regarding drivers (on Windows too) then it was but still long way to go.

[Adarion]

Good to see free driver stack support. For now this recent stack is not too widespread, but sooner or later it'll come even to Debian stable.

I wonder if this port will also allow DLC contents to be used.

[smitty3268]

Can you finally opensource the OpenGL+Vulkan+OpenCL and merge it to mesa or something like this? It is really anoying that for some games it is better (or even necessary) to have mesa, for some others it is better to have AMDGPU-PRO, for OpenCL you need to use AMDGPU-PRO and so on. Oh to add more to that - for Mesa it is better to use rolling release like Arch while for AMDGPU-PRO you need to use Ubuntu LTS release which is exact opposite. I that know Nvidia has only binary blob (and nouveau but you use it only for displaying desktop on more than 2 displays :P) but on the other hand - it is the only one driver which just works (mostly). So much more convenient.

Which games still require the PRO drivers? The Mesa stack should be in good enough shape now with LLVM 3.9 and Mesa 13.0 that everything will run with decent enough performance.

Mankind Divided has slow loading issues, I suppose, but the PRO driver isn't supported on that game either and you can hack some config files to make it run in Mesa.

[GreatEmerald]

openSUSE is my main distro (Tumbleweed on main PC, Leap on production laptop), and it's also my go-to suggestion for new people who want to do something more complex on it than office/web stuff (else Mageia is suggested).

Now, Tumbleweed is usually real nice, but it doesn't play well with proprietary drivers. I'd never recommend someone new to this to run it with proprietary drivers; it works but is a real pain, and you need to know what you're doing.

Let's begin with the installer. It was unable to create an encrypted partition layout where /home uses the rest of the maximum space available. With the result that you have to resize home after installation or mess with your partition layout manually (which I usually don't want).

That... is not basic usage. Encrypted partitions are not for new users, and if you want one, you should really be fine with making your own partition layout.

That said, the partitioner is getting remade from scratch as we speak.

After I solved that, I noticed that no network manager was available. Also I found the handling of repositories very counterintuitive even though it might can be done via YAST.

That certainly shouldn't happen. NetworkManager is default. You must have disabled it somehow.

Handling repositories is more intuitive than any other system I've seen so far. It really just depends on what you're used to...

Btw, YAST looks alien in every DE. Why didn't Suse ported YAST to Qt when they rewrote it.

They did. It's Qt 5. (It actually was Qt4 before.) It's just using a custom theme. If you don't like it:

sudo zypper remove yast2-qt-branding-openSUSE

[duby229]

Then please don't post bullshit like this while taking a wild shot in the dark. OpenSUSE has GUIs for most things (see YaST), a rather lively AUR-equivalent (the Opensuse Build Service) with one-click guided installation of stuff and overall is great for newbies.

Here the issue is that Steam is the usual garbage and does not like rolling release distros so it has to be hacked. tomtomme user had posted his hacks somewhere in this forum but tumbleweed is a moving target.

I'm on OpenSUSE Leap 42.2 (the stable version) and Steam runs fine, of course in here Mesa is like 11.something so it's probably not good for gaming.

This mesa issues are getting ridiculous. There is something VERY wrong in linux if the best distro for gaming with open drivers is Gentoo/Arch. VERY wrong.


/just saying

No, your just a dumbass that clearly doesn't understand the whole concept of release distribution. It takes time for supported releases to propagate and then there are so many distro's that propagation varies dramatically between them. As such it makes perfect sense that Arch and Genteoo are most often the best gaming distributions. Duh. Obvious.

[duby229]

What I think is very wrong is how people think AMD can somehow manifest time itself... Idiot.

[starshipeleven]

So why don't you enable

X11:XOrg (maybe Kernel:stable, too)

then?

It offer all you need for latest AMD 'experience'.
Ask pontostroy if you like, too...;-)))

I'm with (and more) S.u.S.E (the 'old' starting term) for over 23 years, now.

Good to know, thanks (migrated relatively recently from Linux Mint Debian).

I'm probably not going to do that on my main rigs (running OpenSUSE Leap) as they aren't really for serious gaming, but might try this out on the current gaming rig (still running Windows because reasons), that is much more expendable.

[starshipeleven]

Not sure if it's "very wrong" or just time for another evolutionary jump.

Well, both are one and the same.

Currently you can only choose between stable but relatively stale frozen-release distros (Debian/RHEL are VERY stale) and rolling distros where you need to be a bit more hardcore than average to keep the %&£%"£ Steam working at all and iron out any other issue that crops up every now and then.

Neither vendor-only nor distro-only is going to work, we need something that >1 vendor and >1 distro buy into.

The traditional way would be to make a "OSS gaming distro" (probably an Ubuntu respin as usual), but it has the same limitations as SteamOS.

I think the evolutionary jump are the new gen of package managers (flatpack/snap) that should be able to package and run programs with different versions of libraries.

Then you basically ship a whole "gaming distro" over any other distro. In the sense that you ship Steam and other games and stuff + mesa + whatever else and the games will live in their own little world, any instability or issue will stay confined there and not break the rest of the system.

running up-to-date kernels on any distro isn't usually causing breakage so that can be left to the current third party repos.

Theoretically also Docker/containers would allow this, but the fact none pulled something like this off on a decent scale doesn't bode well.