Increase the shader node limit
As Blender is used more and more professionally shortcomings of decisions made in the past become more and more apparent. One of these is the current shader node limit. With the advent of geometry nodes there has been a strive to be able to do as many things procedurally as possible, for which considering the reusablity and consequent time save it is no surprise that it is also particularly popular in professional enviroments. In these enviroments node trees of astonishing complexity are often necessary to create the effects the artists wants to achieve, which however is currently impossible im Blender. The problem is the shader node limit, which is set seemingly arbitrarily low.
This is especially apparent in Cycles. For example I have node trees which render at thousands of samples per minute (on a GTX 1080), however still hit the node limit if I add just a single math node.
After informing myself on the problem it appears that the problem lies in the fact that Blender encounters a SVM (Shader Virtual Machine) stack error and shows nothing but black. So to fix this problem we need to prevent this from happening.
If I am not mistaken stack refers to the part of RAM, so everything we need to do is just increase the stack allocated for the SVM (Support Vector Machine), which given the fact that even modern low-end PC’s usually have a few gigabytes of RAM shouldn’t be a problem.
5 Comments
SVM stands for shader virtual machine and the stack error is hardcoded at the moment. This should be made more flexible, but just increasing this would impact gpu performance. Note stack does not refer to cpu stack, but the internal stack used in svm. It is easy to increase it for experimenting. This experimenting could make clear the limitations and perhaps show better solutions
This would be fantastic to be improved, and I find it particularly very necessary.
I am developing procedural effects and in order to simplify things for the user I have to make use of many nodes inside nodegroups. I'm currently not being able to develop more effects or add more realism to it because I'm tied to this constraint. The moment I start to stack too many of them, the blackout appears.
The current possible way I found to avoid this issue is to enable the CPU and use OSL, but you lose the power of GPU rendering for it.
It would be fantastic to have an increased limit without it being an experimental option, but at least a toggle to enable it would help a lot.
It would let more complex creations emerge as creative freedom wouldn't be constrained by this technical issue.
Changing this value, requires recompiling cycles and all kernels for Cuda, Optix, Metal, HIP, requiring the SDK's to be available and wait times of 30 minutes when changing this.
This cannot be done as a simple toggle or even experimental option without doing major changes to Cycles, we might not want in a release yet. I was suggesting to experiment by compiling Blender and change the stack size manually.
GPU support for OSL is part for Blender 3.5. See wiki.blender.org/wiki/Reference/Release_Notes/3.5/Cycles
Ok, I thought that this "easy" manual tweaking could be done and implemented natively in the next Blender version.
I've seen that OSL now can be used with GPU but, as I understand, it is limited (I know that it is in the early stage). The AO and Bevel node (which at least I use in my creations) are not able to be used. I suppose that this will be solved in the future, but also I get some errors that when using OSL + CPU don't appear to be. The error says "Requested OSL group data size (15248) is greater than the maximum supported with OptiX (2048)" The number of the group data size varies according to the combination of sliders that I use in my node group.
So, to sum up:
I have to say that I can't go way deeper than this or that I may have referred to some technical details wrong because, at least for now, this is way too technical for me.
I hope you understand that I really appreciate the effort that you guys are doing with Blender and that I'm trying to point out a current constraint I believe could be great to be improved!
This is becoming more of an issue with geometry node improvements. The amount of attributes you ideally want to pass through to the material easily breaks the limit, even combining the attributes into RGB channels.
It's currently very limiting, the viewport can be running perfect in real-time and arbitrarily you're material goes black or pink because of the limit.