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

Nvidia adds native Python support to CUDA

thenewstack.io

Post reply on HN
Print view View original

171–180 of 196 posts

Re: Nvidia adds native Python support to CUDA

#171

Post by jms55 »

pjmlp wrote: post #108
bigyabai wrote: post #105

Earlier quoted context omitted.

Well, Apple has done nothing to replace the common standard they abandoned. They failed to develop their proprietary alternatives into a competitive position and now can't even use their own TSMC dies (imported at great expense) for training: https://www.eteknix.com/apple-set-to-invest-1-billion-in-nvi... However you want to paint the picture today, you can't say the industry didn't try to resist CUDA. The stakeholde…

Yes they did, it is called Metal Compute, and everyone using Apple devices has to use it. Vulkan you say? It is only relevant on GNU/Linux and Android, because Google is pushing it, and still most folks still keep using OpenGL ES, no one else cares about it, and already turned into the same spaghetti mess as OpenGL, to the point that there was a roadmap talk at Vulkanised 2025 on how to sort things out. NVidia and AM…

> NVidia and AMD keep designing their cards with Microsoft for DirectX first, and Vulkan, eventually.

Not really. For instance NVIDIA released day 1 Vulkan extensions for their new raytracing and neural net tech (VK_NV_cluster_acceleration_structure, VK_NV_partitioned_tlas, VK_NV_cooperative_vector), as well as equivalent NVAPI extensions for DirectX12. Equal support, although DirectX12 is technically worse as you need to use NVAPI and rely on a prerelease version of DXC, as unlike Vulkan and SPIR-V, DirectX12 has no mechanism for vendor-specific extensions (for good or bad).

Meanwhile the APIs, both at a surface level and how the driver implements them under the hood, are basically identical. So identical in fact, that NVIDIA has the nvrhi project which provides a thin wrapper over Vulkan/DirectX12 so that you can run on multiple platforms via one API.

Re: Nvidia adds native Python support to CUDA

#172

Post by pjmlp »

jms55 wrote: post #171
pjmlp wrote: post #108

Earlier quoted context omitted.

Yes they did, it is called Metal Compute, and everyone using Apple devices has to use it. Vulkan you say? It is only relevant on GNU/Linux and Android, because Google is pushing it, and still most folks still keep using OpenGL ES, no one else cares about it, and already turned into the same spaghetti mess as OpenGL, to the point that there was a roadmap talk at Vulkanised 2025 on how to sort things out. NVidia and AM…

> NVidia and AMD keep designing their cards with Microsoft for DirectX first, and Vulkan, eventually. Not really. For instance NVIDIA released day 1 Vulkan extensions for their new raytracing and neural net tech (VK_NV_cluster_acceleration_structure, VK_NV_partitioned_tlas, VK_NV_cooperative_vector), as well as equivalent NVAPI extensions for DirectX12. Equal support, although DirectX12 is technically worse as you ne…

An exception that doesn't change the rule, where are the Vulkan extensions for DirectX neural shaders, and RTX kit?

As a more recent example, not feeling like enumerating all of them since DirectX 8 shader model introduction, and collaboration with NVidia where Cg became HLSL foundation.

Exactly, proprietary APIs don't have extension spaghetti like Khronos APIs, that always end up out of control, hence Vulkan 2025 roadmap plans.

Khronos got lucky that Google and Samsung decided to embrace Vulkan as the API to be on Android, Valve for their Steam Deck, and IoT displays, basically.

Everywhere else it is middleware engines that support all major 3D APIs, with WebGPU becoming also middleware outside of the browser due to the ways of Vulkan.

Re: Nvidia adds native Python support to CUDA

#173

Post by pjmlp »

_0ffh wrote: post #148
KeplerBoy wrote: post #143

Earlier quoted context omitted.

sorry, could you link to the project? Seems there are quite a few languages called slang.

I guess he might mean this one https://shader-slang.org/ though at first glance at least it looks more graphics than GPGPU oriented. Edit: Hmm, this part of the same project looks general purpose-y and apparently integrates with PyTorch https://slangpy.shader-slang.org/en/latest/

Yes that is the one, and all shader languages also support compute as well, not only graphics.

Re: Nvidia adds native Python support to CUDA

#174

Post by jms55 »

pjmlp wrote: post #172
jms55 wrote: post #171

Earlier quoted context omitted.

> NVidia and AMD keep designing their cards with Microsoft for DirectX first, and Vulkan, eventually. Not really. For instance NVIDIA released day 1 Vulkan extensions for their new raytracing and neural net tech (VK_NV_cluster_acceleration_structure, VK_NV_partitioned_tlas, VK_NV_cooperative_vector), as well as equivalent NVAPI extensions for DirectX12. Equal support, although DirectX12 is technically worse as you ne…

An exception that doesn't change the rule, where are the Vulkan extensions for DirectX neural shaders, and RTX kit? As a more recent example, not feeling like enumerating all of them since DirectX 8 shader model introduction, and collaboration with NVidia where Cg became HLSL foundation. Exactly, proprietary APIs don't have extension spaghetti like Khronos APIs, that always end up out of control, hence Vulkan 2025 ro…

> An exception that doesn't change the rule, where are the Vulkan extensions for DirectX neural shaders, and RTX kit?

DirectX "neural shaders" is literately the VK_NV_cooperative_vector extension I mentioned previously, which is actually easier to use in Vulkan at the moment since you don't need a custom prelease version of DXC. Same for all the RTX kit stuff, e.g. https://github.com/NVIDIA-RTX/RTXGI has both VK and DX12 support.

Re: Nvidia adds native Python support to CUDA

#175

Post by system2 »

wiseowise wrote: post #137
system2 wrote: post #120

Earlier quoted context omitted.

I heard the same thing about Ruby, Go, TypeScript, and Rust. (Even JS at one point when NodeJS was super popular a few years ago). There will be new shiny things, but of course, my choice is Python too.

Python - new (34 years old), shiny thing.

I meant the other new shiny stuff.

Re: Nvidia adds native Python support to CUDA

#176

Post by system2 »

airstrike wrote: post #124
system2 wrote: post #118

Earlier quoted context omitted.

With the help of GPT, I think the bad habit part is non-existent anymore. Learning it from GPT really helps people nowadays. Ask ChatGPT 4.0 some questions, and you will be shocked by how well it describes the code. Just don't ask to fix indentations because it will do it line by line for hours. But it finds mistakes quickly and points you in the right direction. And of course, it comes up with random non-existent mo…

The bad habits I was thinking about were more in the line of not understanding how memory is being used (even something as simple as stack vs. heap allocation), not having a type system that forces you to think about the types of data structure you have in your system, and overall just being forced to design before coding

I ask for help from ChatGPT before I go all in, and it creates these old-fashioned ASCII graphics to show how the flow will be. I think newcomers will not have the bad habits we have/had.

Re: Nvidia adds native Python support to CUDA

#177

Post by pjmlp »

ryao wrote: post #125
pjmlp wrote: post #97

Earlier quoted context omitted.

First of all they extend C, and with CUDA 3.0, initial support was added for C++, afterwards they bought PGI and added Fortran into the mix. Alongside for the ride, they fostered an ecosystem from compiled language backends targeting CUDA. Additionally modern CUDA supports standard C++ as well, with frameworks that hide the original extensions. Most critics don't really get the CUDA ecosystem.

They replaced C with C++. For example, try passing a function pointer as a void pointer argument without a cast. C says this should work. C++ says it should not. There are plenty of other differences that make it C++ and not C, if you know to look for them. The fact that C++ symbol names are used for one, which means you need to specify extern “C” if you want to reference them from the CUDA driver API. Then there is…

They replaced most of the documentation with C++ examples, given the benefits the language has over C, that was already obvious to me in 1993.

As for the language extensions required by CUDA C, it is kind of interesting that clang and GCC extensions are praised and people keep referring to them as C, while everyone else's extensions are never C or C++ under the same measure.

With OpenAAC directives, an HPC industry standard, you can make use of plain old C11 with traditional #pragmas,

https://developer.nvidia.com/openacc

Re: Nvidia adds native Python support to CUDA

#178

Post by pjmlp »

jms55 wrote: post #174
pjmlp wrote: post #172

Earlier quoted context omitted.

An exception that doesn't change the rule, where are the Vulkan extensions for DirectX neural shaders, and RTX kit? As a more recent example, not feeling like enumerating all of them since DirectX 8 shader model introduction, and collaboration with NVidia where Cg became HLSL foundation. Exactly, proprietary APIs don't have extension spaghetti like Khronos APIs, that always end up out of control, hence Vulkan 2025 ro…

> An exception that doesn't change the rule, where are the Vulkan extensions for DirectX neural shaders, and RTX kit? DirectX "neural shaders" is literately the VK_NV_cooperative_vector extension I mentioned previously, which is actually easier to use in Vulkan at the moment since you don't need a custom prelease version of DXC. Same for all the RTX kit stuff, e.g. https://github.com/NVIDIA-RTX/RTXGI has both VK and…

And how does that prove that NVidia has not designed that together with Microsoft first in DirectX prototype?

Additionally, naturally Intel and AMD will come up with their extensions, if ever, followed by a Khronos common one. Not counting mobile units into this extension frenzy.

So then we will have the pleasure to chose between four extensions for a feature, depending on the card's vendor, with possible incompatible semantics, as it has happened so many times.

Re: Nvidia adds native Python support to CUDA

#179

Post by pjmlp »

ryao wrote: post #127
swyx wrote: post #67

Earlier quoted context omitted.

why is that impt to you? just trying to understand the problem you couldnt solve without a C-like

I want to write C code, not C++ code. Even if I try to write C style C++, it is more verbose and less readable, because of various C++isms. For example, having to specify extern “C” to get sane ABI names for the Nvidia CUDA driver API: https://docs.nvidia.com/cuda/cuda-driver-api/index.html Not to mention that C++ does not support neat features like variable sized arrays on the stack.

A neat feature that is so neat Google paid to get it irradicated from Linux kernel, and became optional after C11.

Re: Nvidia adds native Python support to CUDA

#180

Post by _0ffh »

pjmlp wrote: post #173
_0ffh wrote: post #148

Earlier quoted context omitted.

I guess he might mean this one https://shader-slang.org/ though at first glance at least it looks more graphics than GPGPU oriented. Edit: Hmm, this part of the same project looks general purpose-y and apparently integrates with PyTorch https://slangpy.shader-slang.org/en/latest/

Yes that is the one, and all shader languages also support compute as well, not only graphics.

Thanks yes. Though I did not mean the bare possibility, but intended use case, which may lead to different design choices.
Post reply on HN