Well, my impression when I looked into OpenCl a few years ago was that it was certainly real and used for things but it was absolutely nothing like a Cuda replacement. Basically it's constructs are low level and processor specific - workable for graphic engines but not for general purpose gpu programming.
This is explains the rise of ROCm and DPC++ as systems having equivalent higher level constructs to Cuda.
SYCL is the second attempt at it, because only after got punched, seeing researchers rather adopt CUDA with its polyglot PTX, supporting C++, Fortran, and even subsets of Java, Haskell, .NET, did they come up with SPIR, and OpenCL C++ in OpenCL 2.0.
However almost no one cared, meaning AMD and Intel never shiped anything worth using, so OpenCL 3.0 is OpenCL 1.0 rebranded, and out of it, the C++ efforts were placed into SYSCL intead.
Which Intel picked up for their own DPC++ efforts, an additional tooling layer on top of SYSCL, meanwhile the only company selling usable SYCL developer experience is a former compiler vendor, that used to work with Sony in high performance compilers for the Playstation (Codeplay), as they pivoted away from console development.
Eventually Intel acquired Codeplay, and they are now the main supporters of One API tools, and the whole UXL efforts.
In the middle of all this, AMD decided to go with their own efforts.
It isn't only up to NVidia, when their competition can't get their story straight for decades.
If anything the situation is that Nvidia is far-sighted, developing hardware and software for general purpose GPU computing and the other chip manufacturers still think like traditional (non-CPU) chip manufacturers - they just want to sell a best-chip for a single purpose. This explain why they throw random things against the wall to see if they stick rather than choosing a general purpose and committing to it indefinitely.
This is explains the rise of ROCm and DPC++ as systems having equivalent higher level constructs to Cuda.