First of all, I’m fairly new to Blender and modeling in general, so please don’t be too harsh on me if I’m not understanding this topic too well :o However if I’m to make very detailed or demanding models/animations, I’d like to shorten the speed. I was contemplating making a render farm some time in the future, but this talk of GPU renders being many times faster than cpu renders makes it sound like GPU’s may provide a much cheaper solution for huge improvements in render speed, which would make a render farm a waste of money, space, and time.
I know this has been discussed many times in the past, but I’ve looked into it and it sounds like most people were pessimistic on the topic of GPU renderers because either 1. Currently available stuff like Gelato didn’t provide significant performance boosts, 2. It involves a lot of work and the Blender program contributers have a busy schedule, 3. it sacrifices accuracy for the sake of speed, or 4. GPU renderers were intended for real time rendering but aren’t well suited for pre-rendering models or animations.
But I don’t think these arguments are very valid. For one thing, it seems that gpu and hybrid gpu/cpu renderers have been created with great success, Octane Render being a fine example. It seems to produce great image quality but claims something like 10-50 times the render speed (For the cost of a couple of really good video cards, as opposed to 10-50 more computers!)
There’s a similar Maya plug in called Furry Ball. Both of these applications were created with Nvidia’s CUDA SDK, which makes me think that it’s entirely possible to create a Blender plug-in that uses CUDA-enabled video cards to multiply the render speeds.
I realize this is a lot of work, and there are probably a lot of issues with starting development on a GPU render plug in, and I’m not quite a programmer yet so I don’t understand what’s necessary for such a task. I’m really just looking for insight so I don’t go and waste tons of money and effort into making a render farm when I could’ve just picked up a GTX 480 for less and gotten better, easier results.
GPU rendering is an interesting topic, but it’s not the holy grail for rendering. (maybe not yet)
Main problem is the memory (VRAM). You have to store the whole scene incl. textures in your graphics card. With smaller scenes it’s ok and fast, but you will have problems with bigger, complex scenes.
The bandwidth betw. RAM and VRAM is a bottleneck, too.
Not all rendering algorithms are possible to calculate with a GPU. Pathtracing seems relative easy to calculate with GPUs, but other rendering algorithms are problematic.
depends on what you want to render… cartoons may look cool with gpu lighting but arent needed. Lots of reflections and caustics look great in ray traced renders(gpu). It is more complex than that. But you just need to choose what will work best for the job you are trying to do.
Reality for me is that I have time to let things work over night if need be. Even running slg(gpu based luxrender)
Rendering small samples (low res and stills) saves me more time than anything
Hmm… Seems like there may be more obstacles than I thought. That brute force path tracing is disheartening. But if the image is so noisy, how come all the sample images on octane’s website were so perfect? @ibkanat
I wasn’t thinking of rendering anything in particular, just trying to cut down on render time. I didn’t think there was so great a difference between c/gpu in certain areas.
You can render it twice and postpro the 2 images to remove the fireflies and grain.
There are also statistical algorithms to remove the fireflies during rendering like metropolis light transport (MLT) which octane does not have yet as far as I know.
You can avoid to have lots of glass between scene and camera.
You can supersample it.
You can use a high pass noise filter of image manipulation programs.
As for the numbers, brute theoretical FLOP power, a GTX480 calculates 200 times faster than a Ci7-920.
There’s been some work on adding OpenCL acceleration to other process-intensive blender tasks. Visit the bf-committers log and look by topic for those discussions around “OpenCL” in August and September. Interesting stuff. Perhaps it will visit the render engine at some future point once the basis is established… ?