As I ponder, “how can we get real GPU-based acceleration?” I keep thinking about the new nodes-based systems for both rendering and materials. And in that I see the germ of a real idea. Maybe it’s already been done, maybe it’s already being done, so I thought I’d start by bringing it up here…
What I (think I…) really want is a set of materials-nodes and render-nodes which use GPU-based hardware acceleration. (Presumably these nodes would employ OpenGL, to give themselves a natural layer of hardware-abstraction…)
I would also like a “Python node” (does one already exist??) which would allow me to create my own stuff.
It goes without saying that… the resulting node-structures are not intended to run at “real-time speeds.” Their only purpose is to run a damn-sight faster than CPU-only … to whatever extent a particular user’s hardware is actually able to do so.
It will, therefore, “take some doing” for an intrepid Blender-head to properly employ these facilities, but to the extent that he or she is able to do so the render-speed improvements could be dramatic. Or not. Anyhow, the entire onus would rest upon the Blender-head to “make of it what you will.” And I don’t think it would take too long for Blender-heads to do very dramatic things with it.
These node-types donot promise to “replicate the software renders.” Instead, they offer a specific, well-defined, hardware-accelerated building block, which does not promise “real time speed.”
I currently don’t actively work on it, but Ianwill has taken the task of finalising this for a next release. When I did this more actively, I know that Cessen did some cool shaders, and brecht even tried a monaco tracer (48 lines of code?) with the pyNodes.
I imagine that to use available GPUs, such as the nVidia, you have to write a GPU-specific driver for each OpenGL call, so that when Blender calls the OpenGL function, that function in turn uses the GPU-driver library available on that machine to perform the function (partially or totally).
Then, every six months or so, you have to rewrite the whole thing again to accommodate bug fixes and upgrades to the GPU library. Every year you get to learn the new GPU library for the new GPU cards that come out. For nVidia, I think the 8800 series is the latest.
I don’t know all that much about GPU programming, but would it be possible to ‘fake’ GPU programming by using generic openGL functions that are normally intended for realtime rendering? Hmm maybe that’s what the OP is saying, but just in case… would it?
I have experimented with GPU based compositing nodes. My conclusion is that due to the latency between GPU and CPU, it only becomes really useful once nearly all nodes run on the GPU, otherwise the speed gain for all the parts added together is not that significant. For material nodes this type of hybrid is not feasible at all.
And while in principle you can program things in OpenGL/GLSL and have it platform independent, once you start to use it as a generic programming tool, you find out that the parts you have to use aren’t really that compatible. Not to mention that you have to do ugly hacks to work around limitations, while in the future there might be a proper, clean interface, and then you will have to rewrite all the code.
I know that GameEngine does this; I’m limping along now.
I fully well understand that OpenGL-based (GPU accelerated) render-nodes (and Python render-nodes) would be of “limited usefulness” and that the results would be at least somewhat GPU-specific and therefore not a substitute for CPU-based methods. In making this request, I fully accept and fully understand that, and all of its implications.
It will still be of enormous practical benefit to me to be able to specify that certain operations are to be performed by the GPU, and it will be worth the time that I will have to invest in setting-up these nodes to get the results that I want. It is also acceptable to me if the finished rendering pipeline includes one or more CPU-based steps.
My work is for video, not artwork and not for movies. It does not require photorealism. It does not require the greater level of output-quality that a CPU-based or ray-tracing render could provide. It does not require the frame-rates that the game engine requires. It does not have to be an optimal use of the GPU. I’d be happy to churn out one or two completed frames per second, with the reasonable ability to improve that as I saw fit.
My business requirement is that I am able to generate animation sequences, targeted for video-kiosk work, with a sharply-reduced rendering time compared to existing CPU-only methods. I believe that if this requirement were satisfied using render nodes of various types, this would represent an excellent compromise with the CPU-render folks … and I also suspect that, once this ball gets rolling, it will quickly become a major feature of the product.
I think there is just a lot of modern OpenGL programming that needs to happen, according to the OpenGL rep at BlenderCon 07. He showed what you speak of, in real-time, inside Blender, by not coding some old style where you locked the thread and then released it. See the conference proceedings. He also mentioned that the recode would remove a huge chunk of code. I remember some comment like Ton saying “Holy smoke! Why didnt we know about this?” and it was because of a major upgrade to the driver and standard that happened a few years ago.
It will only be of practical benefit if it is actually technically possible, and if it actually would bring you speed improvements. I don’t know much about GPU programming, but I know a bit about Blender’s node shaders, and to me, both points seems extremely doubtful. For a shader node tree that is executed many times per pixel, the repeated copying from CPU to GPU and back would probably kill it. Brecht has actually tried it for comp - this would seem to be the only efficient way to integrate it, being able to store the entire image in graphics memory and letting the GPU work on it there, and even that wasn’t worthwhile in his opinion. I’d listen to him
GPU image processing will only become worthwhile on one of two conditions
Ideally: all the processing pipeline can be done on the GPU (bear in mind that not all type of operations are easily done but all point to point, neighborhood and color remapping operations are easily done).
Alternatively: a sizable sequence of the pipeline (even better if its the start or end of it) can be done on the GPU, enough to offset the penalty of memory transfer.
Until that’s done (and it would require a non trivial amount of work), just buy more CPU and parallelize the work.
There are plenty of gentlepeople out there … “in the GameBlender world” … who quite happily take for granted that their hardware (which BTW is just the same as yours…) is able to churn out enough “frames per second” that they can fight against it (if they choose) with their swords and magick.
Truly… what I ask of Blender is no less … and the circumstances in which I ask it are, “also, no less.”
What I simply desire, no more and no less, is a choice. In this very strange environment that gives us so much computing power both from “the CPU” and from “the GPU,” let me choose. And let me make of my choice whatever I will.
Blender no longer has this “either/or choice.” (Hallelujah!)
The “node-based render pipeline,” that we now all have, does give us all that “choice.” And, it lets us make our own decisions. No longer do we have to make a choice between “the GPU” and “the CPU.” Now, realistically, we can combine the two. Therefore… let us make of this new power whatever we will.
run a damn-sight faster than CPU-only 