> Now we just need the GPU manufactures to give Linus the same driver support Windows gets.
We're already there: AMD has first class upstream Linux support!
I played steam games for ten hours on 6.11-rc3 last week with zero problems, on a very old userland (Debian bullseye). The amdgpu driver was built-in, not a module.
Now ask yourself the same question but only for iGPU/dGPU compute API support from AMD on Linux and I do not think that you or anyone will come to the same conclusion on Linux!
And really Valve/Linux Community is more responsible for AMD's Opensource Radeon drivers and Gaming performance on Linux than AMD is!
Even Intel has better Blender 3D iGPU/dGPU Accelerated Cycles rendering support for Intel's ARC/Earlier iGPUs and dGPU hardware(Via OneAPI/Level-0) and iGPU/dGPU compute API support on Linux. And so really one must first consider what Linux Opensource applications need proper iGPU/dGPU compute API support so they do not have to use the slow and power hungry CPU rendering/whatever fallback instead.
And Blender 3D used to support OpenCL as the iGPU/dGPU compute API for AMD and Intel Graphics but even back then AMD's OpenCL component was not easy to get installed and working on Linux. And Linux/MESA had the old clover OpenCL implementation in the MESA drivers but that was not kept updated for OpenCL feature set support! And even with the newer Rusticl OpenCL Implementation in MESA that's just been created is that Rusticl/OpenCL implementation been fully enabled in any Ubuntu versions or Ubuntu derivatives currently?
Look at support for AMD's ROCm/HIP in Linux and for Consumer/Client iGPUs and dGPUs and that's rather limited and Polaris dGPUs have long since been dropped form the ROCm/HIP support matrix and Vega iGPU/dGPUs are on borrowed time for ROCm/HIP support.
So be careful there giving too much credit to AMD's iGPU/dGPU efforts on Linux as there's more to that story. And Look at Blender 3D where that works with Nvidia's CUDA and Works with Apple's Metal and iGPU compute API support there and dGPUs as well.
And I'm on Linux Mint and never going back to Windows but all my older AMD iGPU/dGPU hardware has never been properly supported for Blender 3D's iGPU/dGPU accelerated Cycles rendering. Intel's got better iGPU/dGPU compute API support on Linux but for ARM Based Processors Apple's the only choice there for proper Blender 3D iGPU support and no mention of Blender 3D iGPU accelerated Cycles rendering support for Qualcomm's Adreno X1 iGPUs on the Snapdragon X Elite SOC based laptops or Mini Desktop PC(Coming soon for consumers).
Sure, as long as you don’t mind hdmi 2.1 being busted because AMD blindly assumed that hdmi would open-source it for them.
Imagine spending the money for a premium laptop and the hdmi port being just permanently busted because it has an AMD apu inside, lol.
Even worse… AMD has settled on rdna 3.5 as their forever architecture for APUs (like Vega before it) so this isn’t going away anytime soon even if it’s fixed in rdna4. Same problem with av1 encoding - the bugs are present in rdna3.5 and won’t be fixed until rdna4 at earliest, and AMD won’t put rdna4 in APUs because it’s got raytracing, so these bugs are just gonna stick around forever. It’ll be probably 3 years until they launch APUs with rdna4.5 or rdna5 or whatever the next forever architecture is.
So anyone who wants plex transcoding is best advised to stay away as well. And that’s the problem - with Radeon you’ve always had to start listing off all the people who shouldn’t buy the product, and if you don’t use any of those things it’s great. (well, decent… except for x y and z…)
> Sure, as long as you don’t mind hdmi 2.1 being busted because AMD blindly assumed that hdmi would open-source it for them
That's not AMD's fault and there's nothing AMD can do here outside of releasing a proprietary driver. Which they used to do. It sucked and caused a lot of confusion and problems.
> That's not AMD's fault and there's nothing AMD can do here outside of releasing a proprietary driver.
Actually,
(1) it’s their product so yes, it is their fault, and blindly assuming HDMI would be willing to open-source their product for AMD (after release!) was an incredibly stupid decision from the get-go. You get legal approvals beforehand like any other company does. You certainly don’t release a whole second generation (or further cards in the same generation) without it fixing it, and you don’t continue advertising it on products that don’t support it.
(2) literally everyone else has figured it out, including intel, who has an open driver. They do it by implementing a LPCON onboard, which is perfectly fine and gets the job done. AMD is the only one with broken HDMI support under Linux.
(3) AMD already has a proprietary driver, amdgpu-pro, so this clearly isn’t a problem or burden. In fact it was and is their primary focus of development, per their communication with geohotz.
I will never understand why the AMD fan base engages in this kind of apologism for clearly broken features etc. like oh gosh poor lil AMD had no idea that hdmi was unwilling to open-source their shit, despite every single other vendor realizing this and implementing workarounds. It’s not their fault, they had no choice but to ship a broken feature, advertising it on the box, and spend 5 years leading people on that it was going to happen!
Like they are literally still shipping broken products today! Not just standalone cards, but laptops etc where it will never ever be fixable.
That’s shitty anti-consumer behavior and you’re enabling it.
At the end of the day it's AMD's product, the buck stops with them. Nobody is making them continue falsely advertising the product, and in fact it really is their job to make sure it works properly before release, not begging HDMI to open-source their product after the fact. Imagine if literally any other company had gone ahead and released the product before they knew they were legally allowed to release the product - "oops" would not cut it.
> And really Valve/Linux Community is more responsible for AMD's Opensource Radeon drivers and Gaming performance on Linux than AMD is!
Which is an extremely questionable business decision, probably driven by statistics like desktop market share.
But the resources need for driver development are negligible and Linux does run on most computers worldwide, so the behavior of many hardware manufacturers is quite puzzling from a business and technology standpoint.
Unfortunately when they pulled official servers they also yanked the game off of most storefronts, and now what few community servers still exist suffer from a complete lack of new blood. Sure, you can still play it, but I'll still miss its heyday.
Some game developers do test under Proton. Saying that because I'm in the discord server(s) for a few, and they mention stuff they're working on/support/etc over time.
Likewise, some do write GNU/Linux games, yet that wasn't in a number relevant enough to keep the original SteamOS going as businesses, until translation of Windows APIs was added.
Sure, I didn't want to belittle your experience at all. It's great that vendors think about Linux as first class citizens on desktop , too.
My understanding though, is that most of "steam games" are still windows binaries + wine + patches (proton, etc). It's well hidden behind a nice GUI, but the tech couldn't exist without the legacy of pure old wine.
Hahaha not belittling at all, I'm just old enough that "running X with Wine" means "spending hours upon hours pulling your hair out until X barely works" to me. Getting it for free feels like cheating :)
Well, if this is steam, isn't it proton, which is wine underneath?
I'm not discounting your experiences at all, btw. My 11 year old has been using Ubuntu as his main gaming rig, and the NVidia drivers work incredibly well and Steam games just work. It's still mind boggling to me that it works so well.
And, I no longer have to troubleshoot removing Windows virii from his computer.
Bought an AMD GPU as my most recent graphics card for this reason. I was able to play just about all my Windows games without issue, except for multiplayer games that rely on anticheat that does not run on Linux.
When Win10 goes out of support I'll probably be using Linux as my daily driver for the foreseeable future, so I'm glad Valve put in the work.
Can confirm. Playing Elden Ring on OpenSUSE Tumbleweed. Just installed the Steam flatpak, enabled proton, installed the game, works just as well if not better than my Windows install. Nothing extra to install gpu driver wise this is practically vanilla OpenSUSE install with Steam really the only extra thing, playing online with multiplayer summons, etc.
There's also the fun approach which Valve had for 10 years in CSGO until CS2 release. They just didn't run anticheat on Linux clients meaning an opensource cheat was absolutely undetected for years.
Yes, the Nvidia proprietary driver has a kernel module that must be installed separately from the kernel. Most distros that focus on desktop usage and/or gaming handle this for you in a relatively simple way, but even with that, if you use a cutting-edge kernel you'll often end up with an unbootable system due to the kernel updating before the nvidia kernel module does. If you need nvidia on Linux, either use the (much worse, but rapidly improving) open source drivers or a distro that uses consistently supported kernels like Ubuntu, Mint, or Pop!_OS
I was trying to make it clear it was built as part of the kernel source, not as an external module.
There are some subtle arguable advantages, for example on x86 static kernel text sits on 2MB hugepages while module text sits on 4K pages from vmalloc.
The kernel on my gaming machine is actually built without loadable module support at all. It's a static binary with only the exact necessary set of drivers turned on.
They have an optional open-source kernel module. It's still pretty far away from being upstreamed and their userspace driver is still fully closed source
We're already there: AMD has first class upstream Linux support!
I played steam games for ten hours on 6.11-rc3 last week with zero problems, on a very old userland (Debian bullseye). The amdgpu driver was built-in, not a module.