Comment by dragontamer
19 days ago
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.
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.
IIRC Mantle was co-developed by DICE, I think DICE may have even had the initial idea and done the prototyping.
1 reply →
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"
2 replies →
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.
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...
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.
1 reply →