Quoting: slaapliedjeI don't run the latest drivers, like ever. I grab what the distro gives me. https://packages.debian.org/sid/nvidia-driver [External Link] Or I can even pull from experimental https://packages.debian.org/experimental/nvidia-driver [External Link] which currently has 455.38. Tiny bit behind, but still supports the RTX 3xxx cards. So yeah, much easier than AMD.

It's not about running the latest driver now. This discussion is about having the drivers "easily available" on release date of the hardware. So, maybe you should check if 455.23.04 were available on September. Either way, someone already told you that for your distro you can already download the required kernel, mesa version and firmware and run a RX 6800 (if you can get one).

Quoting: slaapliedjeAlso did discovery that nvidia now has an official means of installing for RHEL/Cent and Fedora, so you don't even need rpmfusion anymore (well unless you want 32bit support, doesn't seem like they care about that, as they're more focused on the drivers being used for server side stuff, as you know that's how they make their Linux money.)

Just like AMD with their releases...

Quoting: slaapliedjeI can only hazard a guess that the AMDGPU pro drivers are harder to package, or under a non debian friendly license.

Well, AMD package release are deb and rpm files (with some deb package that may work out of the box in Debian). And repackaging is quite simple: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=amdgpu-pro-installer [External Link]

I don't know, I really fail to see where you find a difficulty with AMD drivers :/

View this comment - View article - View full comments

Quoting: slaapliedjeSo I really WANT to support AMD as I believe that the hardware should all have open source drivers. I just want it to be easier to do so without compromising convenience and stability by adding third party repos or compiling custom libraries.

But how is easier Nvidia? AMD is offering exactly the same options on release as Nvidia does right now (on you want to tell me that, for example, you can get Nvidia 455.45.01 on day one from an official repo on any distro?). If you want to get the latest driver, almost on every distro you will have to do some extra step.

View this comment - View article - View full comments

Quoting: AnzaNot really. nVidia bundles the API libraries with the driver, so I don't think Mesa really plays big role at all. I remember that there used to be bit trouble with that as driver would overwrite Mesa libraries. I don't know if these days things are less hassle as distro packaging has gotten better or drivers integrate with the system bit nicer way.

AMDGPU-PRO does the same as well (you get proprietary and open source stack). The difference is related on how rigid are the correlations between kernel modules versions and libraries are. My point is that there isn't much difference in the driver installation for the latest hardware between one and another.

View this comment - View article - View full comments

Quoting: slaapliedjeYes, I know what all of that is. I've been using Linux for 20+ years at this point. I also vividly remember the hassle I had of trying to get the one AMD system I ever owned to work. Either the fglrx wouldn't compile with newer kernels, or the open source driver had shit performance. I was hoping this situation had improved, but it doesn't seem that way.

1) official repos don't have it (debian sid)
2) I try to avoid third party repositories because they tend to break shit
3) AMDGPU-PRO linux package is not available for any Debian system.
4) Compiling myself is what I try to avoid.

So yeah, there are pros and cons to how AMD does it and how nvidia does it. Most distributions seem to favor the nvidia method, otherwise they'd take the AMDGPU Pro drivers and put them in the repos.

Most distros doesn't favor Nvidia method, they just add their drivers because is the only way to make that hardware work (the "easiness" of Nvidia drivers is 100% thanks to the work the community does). And if you buy the latest Nvidia hardware, you are forced to use a third party repository, just like with AMD if you get their latest GPU. In the end, both delivers the same but AMD gives more options and more freedom.

View this comment - View article - View full comments

Quoting: slaapliedjeNo, it's more about getting a current mesa build. DKMS is easy. Though from my understanding is it shouldn't be needed with the AMD as it's in the kernel instead of needing a separate thing (though for the non-kernel driver you mention, sure the dkms would work).

I'm not sure what you mean here. Hopefully this will clarify your picture:

AMGPU: It's the AMD driver module that lives inside the kernel. You can update it by getting the latest stable/unstable kernel in your distro or by installing it as DKMS (the latter is what I mean by "installing it from AMDGPU-PRO").

Mesa: these are userspace libraries/drivers that implements graphics APIs (OpenGL, Vulkan, etc.). You can get a version by several ways:

• From your distro official repositories


• Third party repositories


• AMDGPU-PRO linux drivers package


• By compiling them by yourself (this step includes dealing with dependencies!)

So, getting the latest Mesa build is fairly trivial now days and the same can be said in order to get the latest kernel (at least in the majority of distros). IMO, any user that wants to setup his system for the latest Nvidia GPU will probably have to deal with both issues as well (with the difference that he may have to avoid some Linux kernel versions).

View this comment - View article - View full comments

Quoting: slaapliedjeWith AMD being kernel based and needing latest Mesa, hardly anyone really packages those unless you want to make your system less stable and are into the whole ppa things. or you start compiling things from source, which I'm not exactly keen on doing for just the graphics card to work. You almost need to be running a rolling release like Arch to be able to just pop the card in and have it go.

I told you this before: you can install AMDGPU dkms using AMDGPU-PRO package release. You don't need a rolling release, having the driver in the kernel has nothing to do with the "problem" you mention. And if your point is that having a dkms driver makes your system less stable... well, that's exactly what happens with Nvidia.

View this comment - View article - View full comments

Good to see that we can have Linux benchs on release date! and really good to see that Mesa 20.2 already supports them :D

View this comment - View article - View full comments

So, now even applications that wants to simply display power consumption will require some kind of privilege and the application by itself will have to be strengthened in order to avoid any possible backdoor. A big F...

View this comment - View article - View full comments

Quoting: ShmerlI think I explained it above, but let's clarify further:

Native:

application → abstraction → system API → …. → hardware

Non native:

application → abstraction → foreign system API → translation → system API …. → hardware

I suggest you to read my second paragraph... but at this point I think that you don't care about what others understands for native applications.

View this comment - View article - View full comments

Quoting: ShmerlSDL is an abstraction that sits above windowing subsystem.

Higher level abstractions don't make things non native, but if you need translate one lower level abstraction to another one because the first isn't supproted, that makes things non native.

I.e. DirectX is native on Windows. It's not native on Linux, so you need to plug all DirectX logic into Vulkan one if you aren't rewriting your code to use Vulkan one directly but used DirectX directly.

Let's say you wrote your code using gfx-rs that can target both Vulkan and DirectX. Then you don't need to replug anything. You are already using an abstraction that can work with both. I hope that explains the difference which I meant.

Basically, abstractions can be helpful. Translating things is a shortcut when you don't want to rewrite them (even if in higher abstractions). Translations add performance cost. Abstractions don't need to, in theory.

SDL is an abstraction but a wrapper in the end, so you always ends up doing a translation to a lower level api at some point.

Maybe what you should do is to differentiate your idea of "native" (which refers to an engine internal architecture) from the concept of native application (i.e. an application with one OS as target).

View this comment - View article - View full comments