Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CUDA Ontology

jamesakl.com

Post reply on HN
Print view View original

41–44 of 44 posts

Re: CUDA Ontology

#42

Post by einpoklum »

nickysielicki wrote: post #37
einpoklum wrote: post #29

> CUDA Runtime: The runtime library (libcudart) that applications link against. That library is actually a rather poor idea. If you're writing a CUDA application, I strongly recommend avoiding the "runtime API". It provides partial access to the actual CUDA driver and its API, which is 'simpler' in the sense that you don't explicitly create "contexts", but: * It hides or limits a lot of the functionality. * Its actua…

If you do this, you forego both backwards and forwards compatibility. You must follow the driver release cadence exactly, and rebuild all of your code for every driver you want to support when a new release happens, or you risk subtle breakage. NVIDIA guarantees nothing in terms of breakage for you. Probably the worst part of this: for the most part, in practice, it will work just fine. Until it doesn’t. You will hav…

Disagree, because:

* The Runtime API is also a black box - it's just differently shaped.

* CUDA runtime APIs are also incompatible with CUDA drivers which are significantly older. Although TBH I have not checked that compatibility range recently.

* C++ is a compiled language. So, yes, in some cases, you need to recompile. But - less than your might think. Specifically, the driver API headers use macros to direct your API function names to versioned names. For example:

    #define cuStreamGetCaptureInfo              __CUDA_API_PTSZ(cuStreamGetCaptureInfo_v3)

  and this versioned function will typically be available also when the signature changes to v4 (in this example, it seems two versions backwards are available in CUDA 13.0).
* ... meaning also that you don't have to "follow the driver release cadence exactly". But even if you want to follow it - there's a change every couple of years: a major CUDA version is released, and instead of functionality getting added, the API changes. And as for actual under-the-hoold behavior while observing the same API - that can change whether you're using the driver or the runtime API.

* Finally, if you want something more stable, more portable, that doesn't change frequently - OpenCL can also be considered rather than CUDA.

Re: CUDA Ontology

#43

Post by zvr »

xpe wrote: post #32
zvr wrote: post #7

Great explanation! It should probably also add that everything CUDA is owned by NVIDIA, and "CUDA" itself is a registered trademark. The official way to refer to it is that the first time you spell it out as "NVIDIA® CUDA®" and then subsequently refer to just CUDA.

I am not a layer (IANAL), but here is what Gemini 3 Pro says: "You generally do not need to use the trademark symbol for CUDA in a blog post, unless you have a specific commercial relationship with NVIDIA." Now direct from actual sources... From [1] > Intended users of this Brand Guideline are members of the NVIDIA Partner Network (NPN), including original equipment manufacturers (OEMs), solution advisors, cloud part…

Ah, my point (which I failed to make, obviously) was not regarding the post.

It was more like "the whole CUDA stuff is by a single company".

Post reply on HN