The moral is that PSP FUD has nothing to do with AMD's lack of success in AI.

Are they "incredibly proprietary" compared to the competition? Clearly they aren't. Nvidia offers blobs in both consumer and professional markets. Even going to the extent of gimping performance hardware through drivers on more than one occasion.

That said, I think AMD isn't really competing with Nvidia. Sure, their R&D budget is smallish but it feels like they're somewhat fine with the current status quo.

> Nvidia offers blobs in both consumer and professional markets

So does AMD.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

And while they have an open version of the userland, it's also missing features compared to the proprietary one, etc.

Besides, in the end it truly hardly matters whether the firmware is loaded at runtime or lives in updateable flash. It's still not "your PC" in the Stallman sense either way, it's been tivoized regardless of whether firmware is injected at runtime or during assembly.

Firmware is also the only way to get proper HDMI support... which is why AMD still does not support HDMI 2.1 on linux. HDMI Forum will not license the spec openly and implementations must contain blobs or omit those features.

https://gitlab.freedesktop.org/drm/amd/-/issues/1417

Hey, I am not white knighting for AMD here. For all we know, they could only have been pursuing open standards because they've been forced to, as the underdog.

Can we really assign blame to them specifically for not fighting the hdmi forum on our behalf?

> I'm honestly not sure what the moral of this story is.

That people will go with what is easier and works?

That open source and open standards don't win by default? That it takes a lot of persistence and effort.

>own OS with its own trusted code solution

AMD is working on moving to things like the open source form of AGESA. They plan to start deploying openSIL by 2026.

The moral of the story is that Nvidia invested a lot more in low level software developers for their GPU solutions and AMD did not, and it shows.

"Open source" by itself is not a magic dust you can sprinkle on your projfcts that will make your software work well.

I personally don't have any insider information but just wanted to add what your saying fits with the meta on the gaming community side where commentators are frustrated that nVidia has so much hubris that they think they can just sell essentially last generation level technology without the step up (I think it was 3xxx vs 4xxx or something like that where you'd expect the 4060Ti to be at least as good as 3070Ti) and just trying to make up for it in "software".

It probably takes a lot of confidence in your software developers to make this kind of decisions.

A company that goes open source might get the icing for free, but they still have to bake the cake themselves.

AMD's focus was always on pure compute power at a good price. And they always beat NVidia at that game. AMD cards always had the highest hash rate per dollar in crypto mining. AMD has 100% of the console market and the fastest iGPUs by 2x over Intel.

NVidia decided to use gimmicks to sell their cards including texture compression, lighting tricks, improved antique video encoders, motion smoothing, bad proprietary variable refresh rate, ray tracing, cuda and now machine learning features.

Nvidia is fortunate that machine learning has taken off. That is masking AMD winning market share from weak overpriced NVidia 3D products!

Calling features which are integral to all modern games and most of which also got adopted by other vendors 'gimmicks' is kind of ridiculous.

You're mashing together a lot under "gimmicks" there.

Texture compression: Useful for games, ongoing work, although I wish they would make cards with appropriate amounts of VRAM

Lighting tricks: Not sure what this is referencing

Improved antique video encoders: NVENC started out with only h.264, but now it supports h.265 and AV1, which aren't antique at all. Niche, but widely used in the streaming industry.

Motion smoothing: The hardware optical flow accelerators in newer cards are important for DLSS, which is a bit gimmicky but works mostly as advertised.

Bad proprietary vrr: No argument here, gsync sucked.

Ray tracing: All 3d games are going to be ray traced sooner or later. Getting a head start on it is a good move, and it's a big head start. The 4090 is ~100% faster than the 7900xtx.

CUDA: No one can seriously call CUDA a gimmick.

Machine learning features: Tensor cores are great.

CUDA is a gimmick though.

CUDA isn't a "technology", its a shader language that has been supplanted by better industry-wide standards.... the same standards whose shader languages are compiled by the same Nvidia shader compiler.

CUDA is a moat whose muddy waters has long since ran dry, and you're drinking koolaid if you think its still relevant for greenfield projects.

> and you're drinking koolaid if you think its still relevant for greenfield projects.

So I want to start a new GPU compute project today. Obviously this will primarily be deployed to AWS/Azure/etc, which means only high-end GPUs available are Nvidia. What do you recommend developing this application with?

The way I see it, you would have to be drinking koolaid to use anything besides CUDA.

Why do you think I can't use standard APIs on Nvidia? I literally just said same compiler does both; Nvidia sits on the Khronos committee! They co-wrote the API that everyone uses, that their compiler also speaks!

Vulkan Compute is not an alternative to CUDA. There's a reason PyTorch doesn't provide Vulkan in their official binaries. It's in the source, though--build it yourself, try running any recent ML project, and see what happens.

Thats a weird strawman; compute in Vulkan is a replacement compute in OpenGL and legacy D3D, and as a twin sibling to compute in D3D12.

OpenCL is the actual intended replacement for all the pre-standard APIs, and has achieved its goals. If you want SPIR-V IR, OpenCL allows this and all the major vendor impls support it.

CUDA has no equivalent for SPIR-V, and never will. Nvidia's own internal IR is not, and never will be, documented nor stable across driver versions. This is a massive downside for ML middlewares, as they have no way of directly emitting optimal code that cannot easily be represented in the HLSL-flavored syntax in CUDA.

>a shader language that has been supplanted by better industry-wide standards....

Are you talking about Vulkan? If so, I'm not sure 'supplanted' is the right word.

OpenCL.

There exists no AMD alternative to CUDA. How is this a “gimmick”?

> CUDA isn't a "technology", its a shader language that has been supplanted by better industry-wide standards

As someone who uses industry-wide standards in a related field...

The proprietary implementation often has the benefit of several more years of iteration with real products than the open standards. 'Supplanted' can only really be evaluated in terms of popularity, not newness or features, because features on paper aren't features in practice until they pay for their migration cost.

That's a wild perspective. I don't know how you can really come to that conclusion either. One attempt at getting Blender to render something using an AMD vs Nvidia card will paint a very very clear picture.

and yet amd lately has been quietly just been slightly less than nvidia but worse product. amd sucks thats just it. their market share is crumbling and nvidias is getting stronger because people are like fuck it, at that price might as well jsut buy the better one that Just works TM

You're entitled to your opinion (which I agree with in broad strokes) but with respect, the op article is specifically about ML. Calling cuda a "gimmick" is silly and completely underestimating the datacenter/ML cluster market share (it dwarfs consumer GPU), and fact of the matter is AMD's CUDA equivalent segfaults. So if "being actually usable to the biggest market" is a gimmick, so be it.

> AMD has 100% of the console market

thats not true, since the switch is based on an nvidia platform. since it's still 1/3 of the market, it's not as bad as it used to be.

Isn't this sort of how specialized hardware kind of works?

At some point, hardware (necessarily?) evolves to become optimized to do one thing, and then you have to just treat the driver as an API to the hardware.

Even "simple" things like keyboards and mice are now small computers that run their own code, moreso more complex devices like sound cards and hard drives.

And since graphics card performance seems to be the bottleneck in a lot of computing, it has become super specialized and you just hand off a high-level chunk of data and it does magic in parallel with fast memory and spits it out the hdmi cable.

For the keyboard/mouse now being small computers that's been true since the 1970s. Almost all keyboards for a period of about 30 years had an 8048 or 8051 CPU. It's how they serialized the keystrokes. From the model M keyboard through to everything up till the USB era.

In the 70s it would be more common to have an MSI part that ran matrix scanning and spit out parallel bus ASCII. UCs were still spendy.

What OS do you mean? The closest thing I can think of is the embedded CPU that gets called CP in the ISA docs, which mostly schedules work onto the compute units. That has firmware which is probably annoying to disassemble, but it's hard to imagine it doing anything particularly interesting.