Hacker News new | past | comments | ask | show | jobs | submit login

Successful open systems tend to have standards that "just happened", not prescriptive standards. Like x86 PCs or Linux or most programming languages.

Cuda seems to be clearly winning over OpenCL in the real world so other vendors should just adopt it. AMD already has a CUDA compiler IIRC.




The point where you suggested that x86 PCs are "open systems" (listing it next to "Linux" of all things!) I realized that you don't get it. We are where we are with Intel ripping off the consumers and companies alike exactly because nobody realized that x86 is everything but open.

A similar mistake is about to happen, but luckily on the software side where losses can be cut quick and mistakes can be reversed easier -- though many will suffer when they have to reimplement their precious library from ground up because they did (or could) not take into account the fact that CUDA is as proprietary as it gets.

AMD has no CUDA compiler BTW. And CUDA is not a programming language FYI. ;)


I'm pretty sure I referred to open systems and CUDA in their commonly understood meanings. Here are some links that may help to clarify the concepts:

http://www.pcmag.com/encyclopedia/term/48478/open-system

http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...

Aside: I have no position on whether is CUDA's Fortran and C++ dialects constitute their own languages, nor did I refer to CUDA as a programming language.


> http://www.pcmag.com/encyclopedia/term/48478/open-system

Sadly, that's a very problematic, borderline BS definition.

"A system that allows third parties to make products that plug into or interoperate with it. For example, the PC is an open system."

Intel allows some third parties to interoperate with their system (ref Intel vs NVIDIA etc.) and they pick and choose to their liking, kill some and promote others exactly because they control the open-ness of their systems.

> http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia...

HIP is still not a CUDA compiler. http://gpuopen.com/compute-product/hip-convert-cuda-to-porta...

> nor did I refer to CUDA as a programming language.

You did refer to "CUDA compiler". My comment was admittedly a nitpick as well as a serious point too. CUDA can be seen as a C++ language + extensions -- something you can compile --, but it's also more than that (stuff that you can't compile), e.g.: API, programming tools, etc. all strongly adapted for NVIDIA hardware.


That article doesn't say AMD wanted to support CUDA, they wanted to give tools to migrate to HCC ("AMD's CUDA").


That would be one way, but what's commendable is that they went further and HIP is actually also a common thin API on top of CUDA and their own platform. They could've just stopped at converting code, but they did not -- and that's something that might save them and give people enough incentive to support their products. You can keep your NVIDIA path that'll be compiled with the nvcc backend and target both platforms with the nearly the same code, especially on host (and often also device side).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: