The way AMD handled this issue seems to be unacceptable. We all go through the cyle of product future features, deprecating the older features and maintaining the compatibility. Its our best interest not to break the compatibility without having telemetry of how its being used.
If this is about shitty workarounds that AMD had to add to their drivers to fix bad programming from an EA studio, well, too bad for AMD (Btw, I'm aware that all driver developers seem to have to add shitty workarounds for AAA games).
This is all about expectation management. The moment you implement a workaround for a buggy game you set expectations. Now it's AMD's problem, not EA's. If the game claims to run with DX9, and your driver claims to support DX9, and you implemented a shitty workaround to make the game work with your driver back in 2007, you better be prepared to support this workaround for as long as you claim to support DX9 with your drivers. If your drivers once worked with a game and then a new driver breaks that, it's most definitely your problem and not EA's.
As I understand it, the entire industry is like this. The reason you're constantly seeing drivers with performance updates and rendering fixes for particular games is that they've put something in the driver to work around a mistake in the original game code.
nVidia have a big developer support program, to the extent of sending their own devs to work on big titles, which makes this easier for them than AMD.
Wow. That is kind of bad. I love to play older games regularly, and had high hopes, because amd provides more and more linux support. But this is kind of a dealbreaker for me. Just wait what happens if reddit and the news get wind of this. i mean it will not be EA kind of bad, but it will surely be bad.
only if the reply is and will be the official position.
I've been waiting for ATI to start having good drivers since 2003. What's weird is that even after being bought by AMD they still haven't turned around. That is to say, if I were you, I wouldn't hold my breath. You'd be more likely to see the open-source drivers for AMD hardware catch up in performance to nVidia's.
Still though, I assume the issue is larger than "some game from over 10 years ago is not working" and is more like "an entire API is not working"? If so, this also has serious consequences for higher-impact applications as, for example, in a professional setting like CAD. It would reflect badly on AMD if they "intentionally" break things, or at least intentionally not fix them.
No, most DirectX 9 games still work (otherwise the driver would have NEVER passed QA). They probably removed a workaround for a buggy way some game developers were using the API.
Well, shit, but that's how they used it. Even if it was never intended as a feature developers used it like one.
Here's a tip: Fix bugs when you find them, not after decades and developers won't expect you to keep them around.
I don't think they fixed a bug or something. A new developer probably just stumbled upon some undocumented code he didn't know what it was used for, so he removed it. My tip: They should improve their CI.
This is a tough one for AMD, because while the number of gamers directly affected is low (~1500 daily players on Steam), it hurts the brand badly - people will think other games might lose support also. That kind of FUD is gold for a competitor.
How is this a tough one? What I mean by that is that any marketing & comms person worth their salt would have prevented this employee from ever making this statement in the first place.
The statement is bad but the underlying choice not to fix it probably won't change. If they do fix this it's likely because of the PR backlash rather than because fixing compatibility with a very old API is important.
And these aren't even obscure, fly-by-night titles. Command an Conquer 3 and Red Alert 3 were AAA titles, no matter how tarnished and moribund the franchise is today.
They aren't particularly old titles, either... maybe this is just me, but most of my gaming time is on DX9 games older and more obscure than that. I'm not in the market for a new GPU now, but this wouldn't encourage me to switch from Nvidia.
"This title is from 2007, so we are unlikely to devote any valuable engineering resources to this issue, which is most likely caused by outdated API modules"
Doesn't make sense #1: Reason to not fix because it is from 2007, what about counter strike?
Doesn't make sense #2: Fixing the issue implies devoting "valuable" engineering resource, does it mean they don't have enough engineers or such issue is extremely difficult?
Doesn't make sense #3: "outdated API modules" was that likely from an educated guess and what does it mean even.
It sounds really foolish for a reply of this calibre to a community of supporters. I love AMD for what they're doing technically but I hope someone can at least promise to fix it soon before this hits the larger community.
This is about politics and nothing else. I hope, and believe, AMD will fix this.
The main issue is probably due to a bug in the old driver. After a while, bugs become a feature, and it's not uncommon to implement bugs to retain backwards compatibility. This is where the politics enter the scene. Some engineers believe that all bugs must be squashed, while others have a more pragmatic approach. IMO, any behavior that is a problematic deviation from the old drivers, should be changed. Otherwise there is no backwards compatibility, only a best effort approach, which is unacceptable for something as crucial as a graphics card driver.
There are specific version profiles like "opengl 3.3 core profile" but a lot of older apps aren't versioned in any fashion, they just request specific extensions. Behavior for specific extensions has varied (old drivers had major bugs, and apps had workarounds for them). If you're on mobile you can assume with near-100% reliability that your GLES driver has a bunch of bugs and you'll need to ship workarounds for them. Chrome (Blink) and Firefox (Gecko) both have huge blacklists for specific GPUs/drivers along with sets of workarounds for issues, many of them specific to individual mobile GPU chipsets or drivers. I shipped a game targeting GL 3.3 core a couple years ago and we hit multiple driver-specific bugs, despite 3.3 being pretty old.
Now imagine you're a driver developer: All this software out there assumes your driver is broken. What happens when you fix it? Well, hopefully the app's workarounds don't actually cause it to break or produce incorrect results. What if the workarounds make it really slow? You want it to run fast on your hardware so people won't buy your competitor's hardware. So now you have workarounds for their workarounds...
OpenGL shaders have (iirc) always been versioned, so that's good at least. The introduction of profile versions also helps but at present even those tend to have major bugs depending on OS and driver, so workarounds still end up in games and applications.
Direct3D was historically much more explicit about versioning and feature sets but there's a lot of variability through things like caps flags (hardware can advertise different levels of functionality) and the app explicitly requesting specific features like a given texture format. Shaders in Direct3D are versioned, but it's quite possible that a driver is only built to handle shaders generated by a given shader compiler, so a new compiler targeting the same shader version will still break the driver. Some shaders probably were generated by old broken compilers, and the driver probably has workarounds for those.
Also, modern graphics drivers typically have a bunch of hacks they quietly apply to big-name game titles and applications to make them run faster or suppress crashes. This goes as far as driver developers actually rewriting the shaders that a game uses, in order to improve performance on their hardware. An infamous old example of this is 'quack3'. https://techreport.com/review/3089/how-ati-drivers-optimize-...
On the bright side, a lot of this madness is gone in Vulkan and Direct3D 12. But very little software is going to end up using those APIs because they're much, much harder to use correctly.
Sadly AMD seems to be in a rush to drop stuff from their Windows driver.
I had the unfortunate experience of watching them drop support for the GPU part of my APU while it was still one of their headline APUs.
This because they had based it on a previous gen discrete GPU, and they didn't want to support that GPU range any more with future drivers.
It is experiences like these that makes me understand were RMS came from, and it pains me when so many even within the FOSS world poo poo his message and seem all too willing to break things left and right just because it is "old and crufty" code.
Isn’t the entire reason you buy AMD/ATI cards so you have issues like this and have to use the just so version of their driver to get the feature you want to work? (Forget having all the features the card is supposed to have all working at the same time)
The only reason I’ve ever bought an ATI card in the last 15 years is because it hashed faster than NVIDIA.
Ironically I still had to play the driver game to prevent the system from crashing. I figured they couldn’t possibly fuck up hashing but I was wrong.
> Doesn't make sense #3: "outdated API modules" was that likely from an educated guess and what does it mean even.
I hope it doesn't mean they lost the source code. Just as bad: did they properly use VCS back in the day? You'd be surprised, I still hear of companies that don't use VCS to this day.
Yes, AMD doesnt have engineers. They rather throw money into garbage fire like Seamicro acquisition resulting in total loss of ~$300mil than actually invest in developers.
- This is why AMD drivers require 15-25% more single thread CPU power to reach fps parity with Nvidia, basically if you want AMD GPU you need to go Intel CPU).
-This is why their educational outreach is a joke, all GPU computing uni courses are teaching Cuda with Nvidias provided support (materials and hardware).
-This is why there still is no viable answer to Cuda. Forget about AMD and Tensorflow.
AMD, the CPU, is great and Ryzen nowadays preferable to Intel (due their hostile behavior - cheap plastic pads inside the CPU is a no-go Intel!).
AMD, the GPU (former ATI), is labeled "sold out" everywhere 'thanks' to crypto-miners. And ATI GPUs where always known to be fast but consume more power than faster NVidia GPUs. NVidia driver got worse recently with all the spyware that sends home data. But AMD/ATI drivers were always known to be worse than Nvidis drivers - if you want to play 1980-2017 PC games than you can only choose Win7 with Ryzen CPU and NVidia GPU.
Beside PC, AMD is going strong on consoles with APU (CPU+GPU on one chip) in X1 and PS4.
"Other problems with the latest driver included glitching, flickering, screen going blank for several seconds, radeon settings manager crashing, relive failing to load, severe drops in fps..."
There must be something else wrong with this user's setup, otherwise there would be more comments about that. From what I've read the Adrenalin driver update was received positive by most users.
Sadly trying to track down the root cause may require a full rebuild of the system, something that may not be a option (never mind that things likely worked on a previous driver version)...
My son and I built a gaming rig for Xmas. Ryzen 1600 and RX580. It’s constantly black screening and crashing. A real piece of shit. Should have stuck with Nvidia and Intel.
My biggest problem with this isn't that some DX9 games (including AAA titles like Red Alert 3 and Witcher 1) don't work on newer hardware; I can understand some old titles having trouble running on new hardware.
What stings me is that they did work in the pre-adrenaline drivers: this was a regression in functionality across the board on current hardware.
I really wish OpenRA 2 were further along! OpenRA is great already(though the AI does a nice job of kicking my ass a bit), but I've given up on trying to make regular Red Alert 2 work over multiplayer.
50 comments
[ 3.5 ms ] story [ 116 ms ] threadThis is all about expectation management. The moment you implement a workaround for a buggy game you set expectations. Now it's AMD's problem, not EA's. If the game claims to run with DX9, and your driver claims to support DX9, and you implemented a shitty workaround to make the game work with your driver back in 2007, you better be prepared to support this workaround for as long as you claim to support DX9 with your drivers. If your drivers once worked with a game and then a new driver breaks that, it's most definitely your problem and not EA's.
nVidia have a big developer support program, to the extent of sending their own devs to work on big titles, which makes this easier for them than AMD.
They/we want backwards compatibly and that does indeed include workarounds for shitty game engines.
only if the reply is and will be the official position.
Nice.
Still though, I assume the issue is larger than "some game from over 10 years ago is not working" and is more like "an entire API is not working"? If so, this also has serious consequences for higher-impact applications as, for example, in a professional setting like CAD. It would reflect badly on AMD if they "intentionally" break things, or at least intentionally not fix them.
AMD is playing with the fire here.
https://news.ycombinator.com/newsguidelines.html
They aren't particularly old titles, either... maybe this is just me, but most of my gaming time is on DX9 games older and more obscure than that. I'm not in the market for a new GPU now, but this wouldn't encourage me to switch from Nvidia.
"This title is from 2007, so we are unlikely to devote any valuable engineering resources to this issue, which is most likely caused by outdated API modules"
Doesn't make sense #1: Reason to not fix because it is from 2007, what about counter strike?
Doesn't make sense #2: Fixing the issue implies devoting "valuable" engineering resource, does it mean they don't have enough engineers or such issue is extremely difficult?
Doesn't make sense #3: "outdated API modules" was that likely from an educated guess and what does it mean even.
It sounds really foolish for a reply of this calibre to a community of supporters. I love AMD for what they're doing technically but I hope someone can at least promise to fix it soon before this hits the larger community.
The main issue is probably due to a bug in the old driver. After a while, bugs become a feature, and it's not uncommon to implement bugs to retain backwards compatibility. This is where the politics enter the scene. Some engineers believe that all bugs must be squashed, while others have a more pragmatic approach. IMO, any behavior that is a problematic deviation from the old drivers, should be changed. Otherwise there is no backwards compatibility, only a best effort approach, which is unacceptable for something as crucial as a graphics card driver.
Now imagine you're a driver developer: All this software out there assumes your driver is broken. What happens when you fix it? Well, hopefully the app's workarounds don't actually cause it to break or produce incorrect results. What if the workarounds make it really slow? You want it to run fast on your hardware so people won't buy your competitor's hardware. So now you have workarounds for their workarounds...
OpenGL shaders have (iirc) always been versioned, so that's good at least. The introduction of profile versions also helps but at present even those tend to have major bugs depending on OS and driver, so workarounds still end up in games and applications.
Direct3D was historically much more explicit about versioning and feature sets but there's a lot of variability through things like caps flags (hardware can advertise different levels of functionality) and the app explicitly requesting specific features like a given texture format. Shaders in Direct3D are versioned, but it's quite possible that a driver is only built to handle shaders generated by a given shader compiler, so a new compiler targeting the same shader version will still break the driver. Some shaders probably were generated by old broken compilers, and the driver probably has workarounds for those.
Also, modern graphics drivers typically have a bunch of hacks they quietly apply to big-name game titles and applications to make them run faster or suppress crashes. This goes as far as driver developers actually rewriting the shaders that a game uses, in order to improve performance on their hardware. An infamous old example of this is 'quack3'. https://techreport.com/review/3089/how-ati-drivers-optimize-...
On the bright side, a lot of this madness is gone in Vulkan and Direct3D 12. But very little software is going to end up using those APIs because they're much, much harder to use correctly.
I had the unfortunate experience of watching them drop support for the GPU part of my APU while it was still one of their headline APUs.
This because they had based it on a previous gen discrete GPU, and they didn't want to support that GPU range any more with future drivers.
It is experiences like these that makes me understand were RMS came from, and it pains me when so many even within the FOSS world poo poo his message and seem all too willing to break things left and right just because it is "old and crufty" code.
The only reason I’ve ever bought an ATI card in the last 15 years is because it hashed faster than NVIDIA.
Ironically I still had to play the driver game to prevent the system from crashing. I figured they couldn’t possibly fuck up hashing but I was wrong.
fixed
I hope it doesn't mean they lost the source code. Just as bad: did they properly use VCS back in the day? You'd be surprised, I still hear of companies that don't use VCS to this day.
Either way - hard to figure out what's the move and agenda is about from a single paragraph from a forum post.
- This is why AMD drivers require 15-25% more single thread CPU power to reach fps parity with Nvidia, basically if you want AMD GPU you need to go Intel CPU).
-This is why their educational outreach is a joke, all GPU computing uni courses are teaching Cuda with Nvidias provided support (materials and hardware).
-This is why there still is no viable answer to Cuda. Forget about AMD and Tensorflow.
AMD, the GPU (former ATI), is labeled "sold out" everywhere 'thanks' to crypto-miners. And ATI GPUs where always known to be fast but consume more power than faster NVidia GPUs. NVidia driver got worse recently with all the spyware that sends home data. But AMD/ATI drivers were always known to be worse than Nvidis drivers - if you want to play 1980-2017 PC games than you can only choose Win7 with Ryzen CPU and NVidia GPU.
Beside PC, AMD is going strong on consoles with APU (CPU+GPU on one chip) in X1 and PS4.
edit: What I meant was that the user could try that to see if it isn't some software incompatibility.
What stings me is that they did work in the pre-adrenaline drivers: this was a regression in functionality across the board on current hardware.
there is nothing more to add to this thread so it’s locked.
What a way to save your face.