Comment by dragontamer
22 days ago
> 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.