71–80 of 117 posts
How lame, it would have been much nicer to just keep OpenCL functioning well and supported.
Earlier quoted context omitted.
> 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 limitatio…
Why would anyone want pointers on the GPU?
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.
Earlier quoted context omitted.
> 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 limitatio…
Why would anyone want pointers on the GPU?
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.
Earlier quoted context omitted.
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 _doe…
Indeed, and a reason why Khronos only adopted SPIR-V and is now slowly embracing C++. They took a hard beating from proprietary APIs that have long moved away from "C is the best" approach, and now they are playing catch-up with the rest of the world cozy in their mature C++ tooling for the GPGPU.
However, MS failed to capitalise on it and bailed out (too early). Has been limping along dead since years, finally acknowledged as deprecated in VS2022.
It's good that AMD is providing support for some of their customers since OpenCL is being removed in 3.0. I hope that this is just the start of far greater investment into their software ecosystem. It was understandable that AMD invested less in drivers and support software when they were almost bankrupt but that excuse is drying up. There are rumors that future AMD GPU architectures will be quite good and it would b…
They should really get together with Intel on an open standard, now that Intel is doing real GPUs. They both have a shared interest in people not being stuck on proprietary Nvidia interfaces.
Earlier quoted context omitted.
Apple is contributing Metal support so there’s another chance.
Only because the move to their own customised ARM based unified memory architecture means that if they don’t want to completely hemorrhage the remaining loyal customers in the pro market paying for their hardware they have to support at least basic hardware acceleration in these apps. So don’t expect support on anything but the latest hardware. Like their new Metal based Machine learning library junk. Oh whats that y…
Note that it’s temporary (as of today) because of bugs in Intel’s Metal graphics drivers. AMD GPUs are supported on TensorFlow/MLCompute.
This is not M1 only, just Intel GPUs are excluded.
Earlier quoted context omitted.
Why would anyone want pointers on the GPU?
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-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 woul…
Earlier quoted context omitted.
Indeed, and a reason why Khronos only adopted SPIR-V and is now slowly embracing C++. They took a hard beating from proprietary APIs that have long moved away from "C is the best" approach, and now they are playing catch-up with the rest of the world cozy in their mature C++ tooling for the GPGPU.
Note that Microsoft had C++ AMP on that front, https://docs.microsoft.com/en-us/cpp/parallel/amp/cpp-amp-ov... . That worked on DirectX devices as a whole. However, MS failed to capitalise on it and bailed out (too early). Has been limping along dead since years, finally acknowledged as deprecated in VS2022.
Earlier quoted context omitted.
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-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 woul…
Except in this case the question makes sense, you don't have malloc on the GPU (it only allocates from a fixed array), and without dynamic memory allocation you could just use indices to an array any time you would use a pointer on the CPU. This also makes sense if you transfer your datastructure between GPU and CPU, since you don't need to translate pointers.
What does Brecht Van Lommel know about writing 3D graphics code and GPU kernels, anyway?
https://www.blenderdiplom.com/en/interviews/400-interview-br...
https://devtalk.blender.org/t/2021-08-31-blender-rendering-m...
So the hip, forward-thinking HP technical support person was right after all, decades ago! Makes me wonder why they're not still in business. Such nice hardware! Too bad about the software.
When amd can compete with Nvidia in this space they'll both be the same price. Just buy nvidia.
If AMD will succeeds, at the very least there will be a long period where they will undercut prices in order to gain market share.