Even before ATI was acquired by AMD they had driver support problems.

When I was working for a Unix commercial graphics software company, the CTO told me how bad the information he received under ATI’s NDA was: different revisions of the same chipset had contradictory register settings, so the driver had to identify the revision before writing a value to the write-only configuration registers. The same chipset might need a 0 or a 1; writing the wrong values could crash the driver.

FWIW Back in 2015 OpenCL 2.0 performance was quite good on then-current AMD GPUs (IMO), but the problem was that 1. You had to implement everything yourself, from scratch, since AMD's GPU BLAS was barely compilable, and 2. They abandoned OpenCL that year, and switched to HIP (or whatever their copy of CUDA was called) which didn't even compile (in practice) for quite some time, and 3. Even with HIP, you were on your own when it comes for any BLAS and other standard library implementations because AMD provided nothing of the sorts for a long time.

All in all, it's not that the drivers performance was poor per se, but AMD did nothing about providing a software ecosystem, which amount to its hardware wasn't realistically usable unless your pockets were so big that you can do AMD's job and fund the re-development of the whole ecosystem from scratch.

In other words, it made MUCH better ROI to just use Nvidia, pay a little bit more for the hardware, and save millions on software :)

Has this changed, If I want to go hands on with development using pytorch or whatever is used now, would you recommend an AMD card?

Genuine question, I have not followed this topic closely for years :)

Does PyTorch not work on AMD cards? I remain very nervous about returning to the AMD ecosystem. On paper AMD has been a compelling choice for GPGPU work for years, up until it turns out the hardware can't actually do what it claims. But the PyTorch problem seemed to be largely solved years. The issues weren't on the application layer, it was crippling firmware bugs that they didn't seem interested in getting a handle on. PyTorch ran fine until the computer kernel paniced or whatever, but that isn't a PyTorch problem.

The problem is "just". "Just" getting pytorch to work and to work well is a huge undertaking.

These days it's for sure the dev environment that is lacking, hardware is okay (potentially great?!), software abysmal. To run a local llm in a stable manner implies using Vulkan.. any attempt at ROCm is totally hamstrung by haphazard support of hardware alongside with an online presence poisoned by people primarily discussing work-arounds rather than work when it comes to AMD as a platform. Argh.

You can't have good performance without good DevX. There's a reason why we get a new python dsl for nvidia GPUs every week.

And yet hardware companies with good software are the exception, not the norm. Is it just the cultural mismatch between hardware and software development life cycles and planning philosophies, or is there more to it?