Insider view on how AMD lost the GPU oppty | Hacker News Reader

Insider view on how AMD lost the GPU oppty

twitter.com

17 pointsjakeirving27 comments

https://threadreaderapp.com/thread/1285234687267356672.html

Also (2020)

He has a very binary sense of better/"SUPERIOR". I don't dispute the qualitative direction of the claim, but was there a quantitative estimate of how much benefit "true" dual core or an APU would bring vs. the alternative? Nobody is going to care too much about chip internals, only the observable performance.

I can actually explain in far less than one Tweet:

CUDA

CUDA was released to consumers in 2006. AMD had plenty of time to counteract that with their own well before the AI boom, especially since back then they now had both CPUs and GPUs under the same roof meaning they actually had an advantage on paper over Nvidia at the time.

It was even their initiative back then called Fusion, and because of that I though AMD would end up overtaking both Intel who could only do CPUs and Nvidia who could only do GPUs. Instead their APUs turned out to be just mediocre CPUs and GPUs at beast without ani killer apps/features, and so lost both markets and had to struggle to regain at least the CPU sector but mostly because Intel was complacent and incompetent on the architecture and manufacturing sides.

Also what does "oppty" from the title mean?

AMD had plenty of OpenCL investments as well as C++Amp, which IMO is much cleaner than CUDA. The idea of a Microsoft-led revolution in GPU-compute isn't bad, especially coinciding with C++11 Lambda functions and whatnot.

That obviously didn't work out, but you can't say that AMD didn't do anything for those years. Especially as AMD was falling into bankruptcy at the time, it was clear that AMD needed to rely upon others to take on the risk of new APIs.

I'm still curious how Microsoft screwed the pooch here. Windows8 was seen as a failure, but I think I can safely say that C++AMP / ConcRT / etc. etc. were well designed APIs. AMD lost some momentum here, and had to do a CUDA-based API for ROCm moving forward a few years later.

I'm not sure why AMD has bet on Windows. The SFX industry has always been using Linux, and various Unixes before that. All the big clusters also run Linux. If they wanted to steal market share from Nvidia, then why also convince people to switch to Windows? Maybe their target customer was someone who has a workstation with one or two GPUs?

The Linux bets were OpenCL 2.0 and later Vulkan.

Remember that NVidia basically stalled out on OpenCL 1.2, purposefully to encourage CUDA adoption. AMD actually moved forward, though their OpenCL2.0 wasn't that good either... it at least existed.

--------

AMD's APUs culminated in XBox One / PS4 APIs, which actually have a substantial market share in the console market.

---------

Vulkan on Linux is working out pretty well today. I don't think anyone would have picked that as the strongest API 10 years ago. Remember that in 2010s, "Vulkan" was known as "AMD Mantle" (https://en.wikipedia.org/wiki/Mantle_(API)).

Even as AMD was going bankrupt in the early 2010s, they had plenty of software investments. Some of these investments (Mantle/Vulkan) even worked out.

IIRC Mantle was co-developed by DICE, I think DICE may have even had the initial idea and done the prototyping.

Here's a video where John Carmack, Tim Sweeney, and Johan Andersson (from Dice) talks about AMD Mantle in 2013: https://youtu.be/MH2hjhcfWic?t=4975 Carmack is sceptical, Sweeney likes it but doesn't want yet another API.

And here's another video where Andersson talks about the motivation behind Mantle: https://www.youtube.com/watch?v=KApdf4P2Iak

Except neither AMD, nor Intel, or Google, ever delivered anything with OpenCL that could match CUDA tooling, libraries, or choice of programming languages.

Additionally their drivers were never great.

The tweet thread makes it clear: AMD has consistently based future strategy on the past which is why they were so ill-prepared for every major non-PC trend this century in CPUs until Ryzen. (which was basically catching up + much better value than Intel) This also translates to their GPUs where they seem to have absolutely no consumer GPU vision beyond 'we want some of what nVidia's getting.' Their current strategy seems to be weaker hardware + weak compute drivers + a little cheaper than nVidia = success.

I wonder if the lack of a "consumer GPU vision" is sort of a forced conclusion.

With ~15% of the market, it's going to be very difficult to pull the market in a direction you want, so you're forced to say "I can offer you what nVidia does, but cheaper"

AMD pulls the market with near 100% of consoles.

PC vs console is weird. They are different markets but you'd think the x86 based PS5 would have more pull these days.

The PC gaming market doesn't seem to track that well with the console market, though. I was always surprised by this-- you'd think that all the optimization skills and tricks they learned to get the most out of console APUs would result in a lot of ports being optimized by default for Radeon cards.

I suspect the problem the PC gaming market is very halo-product steered: Intel's product credibility is still buttressed by whatever 700-watt-from-the-wall 16900WTFBBQ they can showcase for benchmarks, and Radeons winning at various price/performance tiers means nothing when they don't have a 4090 killer.

I was also surprised how effectively ray-tracing was sold to the market, considering plenty of games still don't use it, and those that do take a big performance hit for it. The RTX2xxx cards were sort of turkeys, but I suspect it now provides an excellent FOMO/FUD scenario for newer cards-- that 7900XT might not ray-trace as well as a 4080.

Ryzen wasn't "catching up". Ryzen was literally inventing the future. It was stubbornly insisting on shipping on chiplets on a fabric at a time where intel and nvidia were both insistent on monolithic as the right choice.

The GPUs aren't playing catch up either, They're the shared memory APU systems. widely celebrated as novel on the current Apple silicon and shipping in configuration since the playstation 4.

The windows stuff is fallout from graphics coming from games dev and that industry being mostly windows based. Not really a conscious bet on windows being a good idea for compute, just what the first set of graphics customers happened to be using years ago.

C++AMP was more a POC than anything else.

The work on ConcRT and WinRT is on the genesis of C++ Co-routines, initially proposed by Microsoft to WG21.

Anything else, Microsoft has always been more interested in doing compute via DirectX, aka DirectCompute.

I will leave the WinRT/UWP rant for another day.

> C++AMP was more a POC than anything else.

Everything starts somewhere. I'd say C++Amp was better than OpenCL 2.0 ever got (since OpenCL2.0 is basically nonexistant), and if you were fine being on Windows-only, it was better than OpenCL1.2.

Developer tooling was loads better on C++Amp than OpenCL ever got honestly, mostly because C++Amp leveraged DirectCompute.

> Anything else, Microsoft has always been more interested in doing compute via DirectX, aka DirectCompute.

Well yeah, but DirectCompute is in its own little language / world (much like OpenCL). Its HLSL, not C++ directly.

What makes CUDA easier to use was that C++ integration. So C++Amp, which took true C++ Lambda functions and automagically compiled them into DirectCompute really made it easier to perform all these computations.

I get that Microsoft is still investing into DirectCompute today, but Microsoft is missing out on some fundamental features of CUDA (ie: one source C++).

-----------

Well, C++AMP has been dead for a decade now, so not much use reminiscing now. But it could have been great IMO with more investment and confidence. Bring C++Amp to DirectX12 so that 64-bit was usable, then start building Thrust-like (CPU-side helper libraries that utilize GPUs) or CUB-like libraries (GPU-side helper libraries).

> I will leave the WinRT/UWP rant for another day.

Don't worry, I think everyone in the industry is universally frustrated at this!

I'm just trying to remind people where AMD was during this period.

What makes CUDA easier to use isn't only C++ integration, rather since CUDA 3.0, NVidia has embraced a polyglot environment, with C, C++ and Fortran at the center stage, followed by anything that could target PTX.

Khronos took ages to understand this, until they finally came up with SPIR.

I was on an OpenCL conference (IOWCL), where the panel could not understand why people on the audience would care about Fortran or why C99 wasn't good enough.

Even now with Vulkan, NVidia with Slang, and Microsoft with HLSL, are doing Khronos work, because no one is sponsoring GLSL further development.

HLSL is following MSL footsteps and becoming more C++ like, even if not exactly the same.

Then again, up to AMD and Intel to improve SYCL story, which Intel is much further on.

I can agree with that. The pseudo-assembly language of PIX serving as the long term basis for tooling on NVidia likely helped a lot.

I know little changes to AMDs architecture required minor changes to the machine code. I think the Assembly could recompile but long term binary compatibility is something of an NVidia superpower (even if it's imperfect, it's far better than competitors attempts)

> SPIR

I hear it's kinda sorta worth using... Maybe soon?

Strangely, the most SPIR stuff seems to be from Intel and their OneAPI push? Id have expected a bigger role from AMD.

I'm wondering why it took so long for SPIR to become a serious engineering attempt. Well, better late than never.

AMDs investment in OpenCL and RoCM before the FOMO of the last years was only for the checkbox they never showed real intend. Especially on consumer hardware...

Oppty = Opportunity

What does the original author do with the extra time gained in a day from removing 5 letters out of a word?

Yeah seems like it makes for poor a11y without any real gain…

Also what does "oppty" from the title mean?

The lazy man's version of opportunity

This is from 2020, a LOT has happened since.

Reply on news.ycombinator.com