Quoting: CybolicBased purely on anecdotal observation, I suspect it's because there's been many HOWTO guides for NVIDIA drivers written by "mainstream" news sites and its often mentioned in Youtube videos, whereas I have yet to see anyone mention how to set things up with AMD.

It's probable, but that doesn't justify the common idea that Nvidia gives better support for driver installation. IMO, there is a big bias going on regarding AMD drivers.

View this comment - View article - View full comments

Quoting: 3zekielI think what you fail to see is that Nvidia drivers are integrated, as latest version, in most distros. Most of the time with akmods or equivalent, which means you never have to deal with DKMS and reboot issues you talk about.
For AMD, when the kernel is okay (so, not when new card, new/latest Vulkan support etc), same for Mesa, which is locked to 3 month release cycle. As such, for nvidia, when a new release come out I just have to time "sudo dnf update"/ or "update"tickbox in sw and I am done. It's official repo, not third party. It requires literally 0 knowledge.

Just like with AMD if you use your distro official repo, you get official support for certain versions of their packages (which version? well, that depends of your distro). Lets be honest here: it is not Nvidia how give this easiness, is your distro maintainers that do such thing. So, Nvidia release a driver that is installed using DKMS or akmods... which is probably the same that AMDGPU-PRO provides (And I say "probably" because I never used rpm packages of AMDGPU-PRO, but I would guess that they use akmods).

Quoting: 3zekielWith AMD, you need to go the road of git kernel/ git Mesa with third party or self tinker. And upgrading kernel outside of distro cycle can/will cause issues at one point or another... As such, Nvidia way is usually more safe.

You only have to do that if you need the latest bits of AMDGPU and the same thing can happen in your distro if you use Nvidia. In order to get the latest version of your driver you will probably have to switch to an unstable/third party repository, completely removing the "safety" you mention as it is possible that your distro upgrades to a kernel that doesn't work with your Nvidia driver.

Quoting: 3zekielAs you said, AMD provides also a dkms, but dkms is just bad, it fails at each new kernel release and is an absolute horror. Whereas, while it's true that Nvidia provides dkms on their website, it is thankfully not what is provided by distros - and surprise, never had issues with akmods, defo had with dkms. Also, for AMD is rarely just kernel/dkms, is also mesa git etc, which exposes you to even more issues.

Not sure what you mean here. What the distros provides is what Nvidia releases with changes in order to make it work with the distro kernel (if necessary). In the other hand, using dkms/akmods is completely optional on AMD but you can do exactly the same if you want (any distro can adapt the released AMD packages to their distro and use it if they want). The difference is that is far easier to simply update your kernel instead of dealing with a dynamic module. As you say, it's a absolute horror that will probably fail with each new kernel release... which is a common problem on Nvidia.

As I said before: you should only use the dynamic module for AMD GPUs if you can't upgrade your kernel.

BTW, if in your opinion dmks is just bad, then Nvidia is also just bad as this is the way their driver is installed on Debian based distros.

Quoting: 3zekielThey version that you will want to use completely depends
For nvidia, at most, you just pull the rpm for Nvidia driver, and change the wget url if you need absolutely immediately, or you just wait tomorrow when it will be released in distro.

And the same can be said for each release of the kernels. How easier you can upgrade to the latest bits of your GPU driver is completely dependent of your distro maintainers, so giving the credit of this to Nvidia is just lame. My point here is that AMD provides the exact same options as Nvidia plus the flexibility of avoiding the DKMS modules all together and use the builtin driver of the latest kernel if the user wants (which is in fact the best solution).

I find hard to believe that getting the latest kernel or Mesa version for your distro is way more difficult than getting the latest Nvidia drivers.

Quoting: 3zekielAs for the creatives/ML guys, Nvidia is defo the simplest road, by far and large. Support is once again basically out of the box, and you get CUDA which is often a hard requirements + the tensor cores of course. With AMD, you once again go the tinker road, and forget CUDA.

Once again, this "simplest road" is related to the work that the maintainers do on the distro. If you compare what Nvidia provides and what AMD provides with their proprietary drivers you will find that both gives the exact same stuff.

View this comment - View article - View full comments

Quoting: PJHonestly - I don't even know what you're talking about. I know just one thing - with Nvidia regular desktop user has OpenGL / Vulkan / CUDA / OpenCL working well out of the box (and sadly no Wayland). With Amd I don't - I need to install AMDGPUPRO.

What I mentioned is the steps you have to do in order to get "good OpenCL" running in your system. Depending on your distro, you may or may not get the packages from the repo. But still, is quite simple to install using AMD packages.

Quoting: PJWhen I'm talking about mesa opengl is not good for creatives I mean it regularly fails in professional creative apps (Maya, Modo, Substance, Resolve etc). Often those apps don't work at all (with Modo I've been able to report mesa related issues and Modo was tweaked to work with it). Also when I've used amd mesa drivers it was the only time I've encountered hard lockups on Linux.

As I don't use those type applications, I cannot give an answer regarding of which could be the problem there. But, once again, for OpenCL the AMDGPU-PRO drivers work perfectly fine.

Quoting: PJI agree it shouldn't. But if you're creative it is. If you read my post you'll notice that I've specifically pointed out if you're a regular desktop user and a gamer mesa can be enough.
But if you're getting our of that comfort zone more than often it isn't.
I've managed a workstation with AMDGPU-PRO and I'm just reporting my findings. More than often after a kernel update I had to fix my box by reinstalling the driver. I get it that there may be a way to set it up better, so those won't break that easily / will get rebuilt. But that requires knowledge and setup that a creative / regular user shouldn't have to have. It's really not a way to expand linux user base.

It requires the same knowledge as with Nvidia. Both proprietary drivers ships their kernel modules using DKMS (with AMD not requiring a blob binary) so the risk to getting a broken system after a kernel update is exactly the same on both, with the difference that even if your DKMS build/installation process fails on a kernel update on your AMD system you will probably still be getting a working system if the builtin kernel drivers are new good enough for your GPU.

Either way, in both cases the best thing to do is to use a LTS kernel version as long as you can.

Quoting: PJI mean repos for distros like Ubuntu , OpenSUSE etc... And I don't care whether they're maintained by Nvidia or other organization. I'm just saying that from an average Joe perspective those are easier to handle. You enable the repo and you stop worrying about the driver - and again that it my experience, haven't had any major Nvidia driver related isssues for years.

AFAIK, those repos are maintained by the community, just like the community also have special repositories for the latest stable or bleeding edge versions of Mesa. If the average Joe knows how to install the latest Nvidia driver on a distro, he should also be able to keep to date the AMD counter part as it will require exactly the same steps.

I really fail to understand why so many Nvidia users says that AMD driver support is inferior when they are actually providing the type of solution as Nvidia and more.

View this comment - View article - View full comments

Quoting: PJNot really, but to I should had been more clear what I mean. If you're creative you probably need good opencl and stable opengl that works well in professional content creation apps (no matter 3d, video production etc). Sadly this means Mesa won't be enough.

Bare in mind that you can use ORCA or PAL along side Mesa OpenGL/Vulkan. Also, not sure what do you mean when you say that Mesa OpenGL is not stable.

Quoting: PJThus when you're on AMD you need to install AMDGPU PRO. And my experience is that as you don't have a repo for amdgpu pro for most distros provided by AMD after each kernel update you end with a blank black screen and you neeed to reinstall the driver.

That shouldn't be the case. AMDGPU-PRO is normally used in workstation, so a kernel version update is not very common and if the kernel mayor version is updated, the dynamic module will not be required anymore (a.k.a. everything will work out of the box).

Quoting: PJWith Nvidia it is just way simpler - you get the rebuilt driver after a kernel update (or at least should - which worked for me in the last 3 or 4 years) as Nvidia offers repos for the most popular distros.

Which are the "Nvidia officially supported" drivers repos you refer?

View this comment - View article - View full comments

Quoting: 3zekielRay tracing is coming, and it is to be expected that it will be ubiquitous real fast now. And you can check on gamer nexus bench for RT on 3060TI: https://www.youtube.com/watch?v=t9H2PfYDFok [External Link] which will tell you why you should go nvidia from that point (for gaming at least)... And the more modern the game/RT implem, the worst it is. RT is coming to Linux too when you see all the moves around vulkan ray tracing etc. I don't know if dlss will come to linux/dxvk etc too, I certainly hope so (and I suspect from leaks dlss 3.0 is near and will bring dlss to most games...), and then this will be a massive burial.
As such, unless you plan to change card in 1 year, you should not look at raster performance, but at more interesting RT, and nvidia utterly dominates here, a 400€ card is better than the 700€ card for AMD. Also, AMD MSRP is a total lie, and even when they are in stock, I don't expect to see any card at less than 100€ more than msrp or not before a very long time, making it not much of a sweet deal in the end. At least nvidia has founder editions to control the price.

RT won't be the standard until you have RT capable hardware in all your GPU tiers. Either way, we are on Linux and to the date you can only play two games on Linux with RT (AFAIK). And the DLSS situation is just worst (and lets keep away future "improvements" predictions). From a Linux gaming experience, you should definitely take a look on the raster performance as this are the only benchs you can get on our platform. In the end, DLSS and RT are gimmick features for Linux.

Quoting: 3zekielAlso, whether we like it or not (I don't but well), CUDA is here to stay too... And CUDA is Nvidia. Now, the experience is certainly better than opencl overall, so I'm not gonna blame anyone for staying on CUDA/Nvidia either. Just it is a pain in the ass to setup sometimes... That is smthg I'd love for Nvidia to open source more the framework so we can use/install it more easily.

As you implies, CUDA is just important for a minority of the gaming market, just like VR capabilities are.

View this comment - View article - View full comments

Quoting: scaine

Ubuntu Unity was among the best DE's in existence

This is blasphemy. I should call the Spanish inquisition.

Not to mention that:

Quoting: scaine

Window buttons should be on the right side of the window decoration

wasn't the default location of the buttons in Unity. You hate what you love!

View this comment - View article - View full comments

Quoting: Alm888But what really irks me is that one can bash a Winelib-port (totally a full-fledged ELF executable) and go as far as accusing WINE to be an emulation, while at the same time praising a DXVK-wrapped port.

Apparently, WINE has a bad reputation here and even mentioning WINE is considered an insult (despite official support from the devs), while DXVK is perceived to be a god-sent for Linux games. So, even comparing usage of DXVK to WINE-wrapping is considered blasphemous by some.

If (when) the game is released with official Linux support, IMO it should not matter what technique was used as long as the quality is reasonably high.

And I completely agree with the last part you mention. But still, I also think that creating an specific build environment to get the game into our platform (i.e. working with native dependencies and a compiler for our platform) gives an extra value to their work as this means that game developers get away from their Windows building cage they usually live in.

BTW, I don't think that Wine is blasphemous, I just appreciate more one work than the other.

View this comment - View article - View full comments

Quoting: omer666If using a DirectX to Vulkan translation layer means the port isn't native, I'm afraid we don't have many native Linux ports, as far as AAA games are concerned.

The main problem I see with using DXVK is that people know what it is, what it's used for and thus they complain about it. If they had used another layer altogether, nobody would have known what it was and everyone would be having a nice day and all.

I think people are very exigent on what means "a real port" and sometimes forgot that the delivery of a software product on a platform it isn't just about code but also about QA and support. More than 50% of the time invested in a port is probably dedicated to testing... and that's also something we pay when buying a product.

View this comment - View article - View full comments

Quoting: Alm888Ultimately, it is underlying API dependencies and technologies used in the code that makes something a "Windows binary", is it not?

And what, if the same code using Windows® API was duct-taped with the Direct3D to Vulkan translation layer and repackaged into (arbitrary more true and holy) ELF format, that makes this code suddenly stop being Windows-oriented?

The fact that it uses your native system loader makes the difference. Not to mention that on link time they had to use native linux libraries.

We already had this discussion many times. Your concept of "native" is more related to the software architecture, while our concept is more related on how a binary is loaded and run by the OS. So, like it or not, you may want to differentiate your concept from the other as both are corrects if applied in the right context.

View this comment - View article - View full comments

Quoting: HoriJust wondering... is the Mac version going to be an ARM version?

They can support x86 and ARM if they want: https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon [External Link]

But I'm not 100% sure if this would make any sense outside of making an specific Big Sur release or if it is even possible that M1 is able to move this game (If I recall correctly, 3D Graphics aren't M1 strength).

View this comment - View article - View full comments