Hello!
I’ve had some ideas and I think it would be possible to make gpu-accelerated versions of some of the new volume grid nodes, something others have previously expressed interest in.
I’ve also been working on fluxx, a standalone GPU-accelerated fluid simulation software with OpenVDB import/export capabilities; I’m currently working on v0.3 and will finish it of for Blender 5.0.
However, I have a finite amount of time and wanted to hear what people would find most useful:
GPU accelerated versions of some grid nodes used in fluid simulation
All implementations would be completely vendor agnostic, based on respectively on blender’s internal GPU module and Godot’s Vulkan/Foward renderer.
Thank you for your input!
I don’t know if that is making sense to create GPU accelerated classes of nodes, at different places of node tree, with CPU execution in the connections between them.
The idea of using nodes is to have flexibility in complexity and to bake multiple caches to ease computations.
We don’t really want two Math nodes, one for CPU and one for GPU.
That would probably make more sense to have a GPU accelerated zone, with dedicated warnings about impossible node combinations for GPU.
Maybe just a toggle for zone nodes, with a visual feedback, this zone is what is what is compute by GPU and the rest is done by CPU.
At the end, that would probably make more sense to debug an overloading of GPU.
I don’t know, maybe it is preferable to have a toggle per node tree, and stack multiple geometry node modifiers.
Just try to do something, where it is understandable for user, how to avoid to burn its computer or to crash Blender.
I like the UI idea, but I think the problem here is that many algorithms that work well on the CPU don’t work/work badly on the GPU (and vice versa).
To use the example of VDB volumes:
CPU algorithms using OpenVDB can be parallelized (in fact OpenVDB tools are multithreaded), but not trivially because the data structure is changing during computation. However, this mutability allows them to adjust volume topology as part of the computation.
GPU algorithms using NanoVDB can be trivially paralellized because the datastructure has a static memory layout. However, changing volume topology is not possible.
Trying to hide this difference from the end user is going to result in fustrations, leaving developers with a few options:
Use two different nodes for the two different computations, possibly implementing some transparent way of passing around GPU buffers to avoid unneccesary CPU-GPU data transfer.
Re-write the CPU algorithm using a cross-platform abstraction layer like SYCL. OpenVDB already has CUDA implementations of some tools, but this would still require major work, preferably in the upstream library.
Simply not allow GPU acceleration of the operation, despite a GPU-friendly algorithm being available.
Ideas/suggestions appreciated. Also, do you think it would be worth moving this discussion to the blender developer forums?
What I meant is that if operation wanted by user implies to use a GPU version of basic nodes ( Math, Vector Math, Mix,…), that will not be manageable by user.
Sample nodes for Volume Grids are supposed to be used in combination of other nodes.
That will be complicated to use, if all switch nodes have to be avoided for inputs of those nodes or if inputs have to be systematically baked.
In that case, that will probably be better to create another application that can import Blender mesh data and export simulation result as an OpenVDB data, that user will be able to transform in Blender.
Because it looks like as part of node tree, or as a modifier coming later in the stack, that will be hard for GPU to adapt to potential anterior switches.
You did not explicit volume nodes, you wanted to create as Blender nodes.
But if there is a potential conflict with most of existing GN, that probably does not worth the pain.
Indeed, you probably should create a devtalk thread.
The pool may stay, here.
My gpu is very weak, so I will count it at the level of integrated graphics, but if a simulation was able to run on it, then I supppse it would be very useful. I dont have much hope though, given how much OpenCL and cuda seem to be prevalent on these kind of software.