Yet Another Fix Coming for Older AMD GPUs on Linux – Thanks to Valve Developer | Hacker News Reader

Yet Another Fix Coming for Older AMD GPUs on Linux – Thanks to Valve Developer

phoronix.com

52 pointsBender14 comments

I don’t think I ever could have predicted any time earlier than the past few years that Valve would be the one to cook Microsoft’s goose. I know this story isn’t about Windows, but this is a bit like finding cougar paw prints outside your cabin in the morning. The trouble hasn’t found you yet but it’s there, and it’s getting close.

Valve fixing Linux issues feels like pawprints.

Same feeling here. What Valve has done honestly leaves me in awe. The Steam Deck is the best device I’ve ever owned, and probably the only one I unreservedly love.

Not really. Microsoft doesn't support GPUs on Windows, the vendor does.

This is a story about a 10 year old GPU that would not be supported on today's AMD drivers either and the AMDGPU driver was never designed for pre-Polaris hardware, which it is.

The bug also does not exhibit itself on normal compliant x86 machines, only Macintels.

Valve is 1% the size of AMD.

Just think about that for a second.

Slightly unrelated but the gaming performance improvement of the Linux 6.19 release over it's release candidates was huge. I want to say thanks to now having a canonical open source driver that just compounds and accumulates improvements over time.

Which is why I never buy ATI cards ever again.

Good, they were bought out in 2006 and no longer exist.

I assume you mean AMD, and I also assume you didn't actually read the article.

The AMDGPU driver was never designed for cards before Polaris (GCN 1.4). The specific card in question, a R9 M380, was released in early 2015, and in 3 months, will be 10 years old.

The bug listed only exhibits itself on Macs, which requires a custom firmware to cope with the oddities in how Macintels boot and function, and pre-Polaris cards especially on a Mac are not well tested on AMDGPU. The bug does not happen on real x86 machines.

At no point can AMD be blamed for any of this, but Apple most certainly can (refusal to ship a compliant UEFI firmware, and instead shipping the nightmare that Macintels used during their existence).

For what it's worth, Apple's UEFI firmware is likely not compliant because they began using EFI before it was standardized. You can blame them for not updating it later, but I can understand why they didn't; it was working.

They were using OpenFirmware, the standard that EFI is built on, but their first x86 CPU was a Core 1 iirc, which had shipped with a UEFI on real PCs.

Are you sure their early EFI contained anything from OpenFirmware, except for conceptual inspiration, maybe?

Intel wanted to rip OpenFirmware off and wanted to EEE it without paying lip service to Sun et al.

It isn't an accident that both, for example, use Forth.

That's why I've asked? Where is the FORTH in EFI, or any UEFI, for that matter?

Look up "UEFI shell" for your vendor. Sometimes this is an unlisted F key, sometimes its as simple as selecting it as which OS you want to boot, sometimes it will happen automatically if no boot device is discovered, sometimes you must supply it as a bootx64.efi from the vendor (or from Tianocore).

Just because UEFI is a standard doesn't mean all the vendors don't smoke crack.

That's only a shell/repl, implementing a DSL for boot-related stuff. It isn't implemented in FORTH, it does not execute or understand FORTH, or use it for anything. It's not there.

It just occupies a similar role in a similar place, of what some FORTHs on some systems once did. Mainly OpenBoot on SUNs and some PPC Apples, while having nothing from their internals.

Having the ability to type some commands in your firmware/BIOS/UEFI, like it has been the case on Sparcs by SUN, PPC Macintosh by Apple, or the OLPC doesn't make it a FORTH.

https://en.wikipedia.org/wiki/Open_Firmware

Reply on news.ycombinator.com