6 ms·

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose. It isn't about that. Vulk

by my123 5y ago

> Looks like this more about adapt existing CUDA code to work with AMD. So it makes sense as the least resistance approach I suppose. It isn't about that. Vulkan isn't flexible enough to allow it to happen. Give true pointers support in Vulkan for example first. GLSL/HLSL is much worse than modern C++ as a programming language too. As described by Brecht Van Lommel (Blender and Cycles developer): Vulkan has limitations in how you can write kernels, in practice you can’t currently use pointers for example. But also, GPU vendors will recommend certain platforms for writing production renderers, provide support around that, and various renderers will use it. Choosing a different platform means you will hit more bugs and limitations, have slower or no access to certain features, are not likely to see library support like OSL, etc. Our strategy for Cycles X is to rely on the GPU vendors to support us and provide APIs that meet our requirements. We want to support as many GPUs as possible, but not at any cost.

raphlinus 5y ago
This doesn't sound right to me. Vulkan 1.2 has support for pointers through an extension[1], and that's getting more widely available (certainly a lot more cards than can run ROCm). There's also support coming down the pike for buffer device address[2], which basically lets you use pointers to refer to resources when submitting work to the GPU instead of having to create bindings. If an open source project of this scope came to me for advice, I would absolutely 100% recommend they base their stuff on Vulkan. It's getting very good quite quickly; there's basically nothing holding you back any more if you're willing to use the latest extensions. There is a tendency in open source to move more slowly though, and I understand that. I agree with you that GLSL/HLSL is a bad programming language, but you can still get your work done in it. I'm personally excited about rust-gpu, but that is not ready yet. [1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_variable_pointers.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... [2]: https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/vulkan-buffer-device-address https://community.arm.com/arm-community-blogs/b/graphics-gam...
- boulos 5y ago
  You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
  - raphlinus 5y ago
    So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town. I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possible to develop good tools that run on top of it. That's happening to a large extent in the machine learning space with IREE, much less so here though. I should also say, I'm not disagreeing with the strategy Blender has chosen, specifically getting vendors to support tuned ports to their hardware. I'm just saying that these specific criticisms of Vulkan (like lacking pointers) aren't really valid.
    - pjmlp 5y ago
      If I have learned anything from Khronos APIs is that if Internet was a Khronos standard instead of IETF, we would only have IP as standard, while everyone else had to come up with TCP, UDP, HTTP,... as extensions. Language support and tooling are never better than the alternatives.
      - my123 5y ago
        Blender decided to support just the platforms which have a C++ target device language. This encompasses CUDA, Metal[1] (one of the reasons why it’s much more usable than Vulkan), ROCm HIP, and oneAPI[2]. [1] Metal’s Shading Language is C++14 with a handful of limitations, the biggest one is no lambdas [2] Vulkan uses a restricted SPIR-V dialect without pointers notably. OpenCL and oneAPI use a separate one which _does_ support them. However, AMD[3] and NVIDIA do not implement SPIR-V in their OpenCL drivers. [3] it’s a trainwreck, they supported the original SPIR but then https://community.amd.com/t5/opencl/spir-support-in-new-drivers-lost/td-p/170165 https://community.amd.com/t5/opencl/spir-support-in-new-driv... happened. It never came back since then. Migrating back down to GLSL/HLSL from that makes absolutely no sense. The options above, using C++ as a device language, allow much more code sharing with a CPU backend. Portability is also a good story, the adaptation is mostly in the glue layer, if your GPU vendor is _not_ AMD and has a proper software stack.
floatboth 5y ago
Why would anyone want pointers on the GPU?
- my123 5y ago
  Among other things: C++ on the GPU, with lots of common code between the two worlds. It’s one of the core reasons why CUDA took off. You could adapt your code instead of a full rewrite, even mixing code within the same file. Types are checked at compile time too.
  - shmerl 5y ago
    I'd take Rust over C++ for the GPU.
    - my123 5y ago
      I don’t see why you’d want that, but if you want to do it you can. nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...)
      - shmerl 5y ago
        I'd ask why wouldn't you want that? I think this is more promising: https://github.com/EmbarkStudios/rust-gpu https://github.com/EmbarkStudios/rust-gpu
        floatboth 5y ago
        …and this one is targeting SPIR-V for Vulkan, not some nvptx-stuff :)
- DonHopkins 5y ago
  That reminds me of the line from the HP technical support person from the "X-Windows Disaster" chapter of the "Unix-Haters" handbook: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#7197 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

by my123 5y ago

raphlinus 5y ago

This doesn't sound right to me. Vulkan 1.2 has support for pointers through an extension[1], and that's getting more widely available (certainly a lot more cards than can run ROCm). There's also support coming down the pike for buffer device address[2], which basically lets you use pointers to refer to resources when submitting work to the GPU instead of having to create bindings. If an open source project of this scope came to me for advice, I would absolutely 100% recommend they base their stuff on Vulkan. It's getting very good quite quickly; there's basically nothing holding you back any more if you're willing to use the latest extensions. There is a tendency in open source to move more slowly though, and I understand that. I agree with you that GLSL/HLSL is a bad programming language, but you can still get your work done in it. I'm personally excited about rust-gpu, but that is not ready yet. [1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_variable_pointers.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions... [2]: https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/vulkan-buffer-device-address https://community.arm.com/arm-community-blogs/b/graphics-gam...

boulos 5y ago
You'd recommend Vulkan Compute over "CUDA" though for a path tracer? (I don't assume Cycles has any hybrid rendering in it, so there isn't much value in the traditional pipeline)
- raphlinus 5y ago
  So it depends a lot on the goals. CUDA is a very good developer experience, and Vulkan compute shaders is (at the moment) a very bad one. But if the goal is to ship real compute on a wide variety of devices, Vulkan is pretty close to the only game in town. I also expect the language support and tooling to get a lot better. The fact that it's based on SPIR-V means it doesn't lock you into any one language, it's possible to develop good tools that run on top of it. That's happening to a large extent in the machine learning space with IREE, much less so here though. I should also say, I'm not disagreeing with the strategy Blender has chosen, specifically getting vendors to support tuned ports to their hardware. I'm just saying that these specific criticisms of Vulkan (like lacking pointers) aren't really valid.
  - pjmlp 5y ago
    If I have learned anything from Khronos APIs is that if Internet was a Khronos standard instead of IETF, we would only have IP as standard, while everyone else had to come up with TCP, UDP, HTTP,... as extensions. Language support and tooling are never better than the alternatives.
    - my123 5y ago
      Blender decided to support just the platforms which have a C++ target device language. This encompasses CUDA, Metal[1] (one of the reasons why it’s much more usable than Vulkan), ROCm HIP, and oneAPI[2]. [1] Metal’s Shading Language is C++14 with a handful of limitations, the biggest one is no lambdas [2] Vulkan uses a restricted SPIR-V dialect without pointers notably. OpenCL and oneAPI use a separate one which _does_ support them. However, AMD[3] and NVIDIA do not implement SPIR-V in their OpenCL drivers. [3] it’s a trainwreck, they supported the original SPIR but then https://community.amd.com/t5/opencl/spir-support-in-new-drivers-lost/td-p/170165 https://community.amd.com/t5/opencl/spir-support-in-new-driv... happened. It never came back since then. Migrating back down to GLSL/HLSL from that makes absolutely no sense. The options above, using C++ as a device language, allow much more code sharing with a CPU backend. Portability is also a good story, the adaptation is mostly in the glue layer, if your GPU vendor is _not_ AMD and has a proper software stack.

floatboth 5y ago

Why would anyone want pointers on the GPU?

my123 5y ago
Among other things: C++ on the GPU, with lots of common code between the two worlds. It’s one of the core reasons why CUDA took off. You could adapt your code instead of a full rewrite, even mixing code within the same file. Types are checked at compile time too.
- shmerl 5y ago
  I'd take Rust over C++ for the GPU.
  - my123 5y ago
    I don’t see why you’d want that, but if you want to do it you can. nvptx64-nvidia-cuda is a Tier 2 Rust target. (see https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...)
    - shmerl 5y ago
      I'd ask why wouldn't you want that? I think this is more promising: https://github.com/EmbarkStudios/rust-gpu https://github.com/EmbarkStudios/rust-gpu
      - floatboth 5y ago
        …and this one is targeting SPIR-V for Vulkan, not some nvptx-stuff :)
DonHopkins 5y ago
That reminds me of the line from the HP technical support person from the "X-Windows Disaster" chapter of the "Unix-Haters" handbook: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#7197 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.