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.
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.
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.
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.
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.
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.
Valve is 1% the size of AMD.
Just think about that for a second.
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.