> If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers.
Absolutely false. First, GPU code is inherently unportable in terms of performance. Switch to another vendor's GPU, or to another microarchitecture, and you may need to rewrite your entire kernel.
But even other than that: NVIDIA promotes its own proprietary and mostly-closed-source ecosystem, named CUDA, and has actively hampered the adoption and development of OpenCL, which was supposed to be the open standard. Not that OpenCL was not "betrayed" by others, but still.
> They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards
There is no GPU support in the C++ standard. If you mean something like `std::par` as an execution strategy for standard library algorithm, that's rather limited in scope and not really GPU-specific.
> While NVIDIA implemented this YEARS ago
Again not quite sure what you mean. Are you talking about how you can't write GPU kernels in C++17? Or about `std::par` implementations for the standard libraries?
> You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs.
This doesn't make sense, and it's also not true. On a GPU, you would not use a lot of the standard library to get things done; that would either be exceedingly slow or just not work. Also, some language features (like exceptions) don't work on GPUs, and for good reason; hence anything in the standard library which relies on exceptions for error handling also doesn't work as-is - which is perfectly ok.
> You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes.
This is the only part of what you've written which is mostly-true (and I haven't fully verified even this since I don't do Python work).