[Bf-committers] GPU computing

Charles Wardlaw cwardlaw at marchentertainment.com
Tue Nov 24 16:19:34 CET 2009


>
> Animation is a big part of blender, and faster subsurf/armature
> systems would be very, very helpful.  To be honest it'd be far more
> helpful then faster physics or rendering systems, and you'd have a
> much better shot at success.
>

I would love to see GPGPU-enabled armature calculations... Although, since
many of the best rigs require custom python scripts I wonder if Python
wouldn't be a bottleneck there.

On the renderer: you wouldn't have to rewrite everything.  Not every part of
the rendering process benefits from multiprocessing anyways, just like not
every part benefits from the various data structures.  But there've been a
number of nice papers on using GPGPU processing to accelerate the parts of
rendering that tend to be the most heavy -- ray collisions, subdivision (as
you said above), ambient occlusion, or even the generation of point clouds
for other purposes (AO, GI, FG).  If Blender could generate point clouds
quickly and that data could be accessed and exported, a lot of studios would
be very interested.

There's also the idea of accelerating nodes in the compositing or texture
graphs.  And now that sculpt is multithreaded, I wonder how hard it would be
to get some of the processing offloaded to OpenCL cores.

Then again, hardware-accelerated subdivision is a serious boon.  At work
we're using Mach Studio, which is a GPU-based real-time rendering system.
 It subdivides on the fly, on the card, and even with a few million polys in
a scene you have completely interactive turnarounds.  Less so with
full-scene AO, but it's still usable.  The last version released something
akin to the DX11 Tessellator functionality on DX10 cards, and watching it
generate a million polygons from a bump map and a plane is something to
behold.

~ C


More information about the Bf-committers mailing list