Comment by fireteller | Hacker News Reader

Comment by fireteller | Hacker News Reader

Parent Full thread

(I can't see any of the 11 comments so forgive me if post is redundant in some way)

Visual Effects production often needs lots of computing resources for rendering. This is a task that can be heavily parallelized. Usually this is done on a frame/per core basis, with memory being the limiting factor. Now I've started using EC2 recently which made me realize a different approach to rendering tasks.

Normally a facility has a fixed number of CPUs available to run jobs. So for example 100 cpus. Let's say the average number of frames to render is usually around 200. So if each frame takes an hour to render and your's is the only job on the queue then it will take 2 hours to see the complete shot. And it's much worse in the real world with many artists working on many shots. Whereas using a resource like EC2 you can always render your entire shot in 1 hour regardless of the number of frames. You're only limited by the time it takes 1 frame to render, and the cost is the same if you use 1 cpu or 200.

In other words one can trade depth for breadth. Now this may seem obvious to anyone familiar with EC2, but for me it means that tools like Tesla which where once in high demand for this type of work are now much less valuable. I would expect that it's price/performance is much better then EC2, but where is the cutoff? How many hours do you have to run that Tesla to come out ahead? And if you're running 1 Tesla for that many hours, might it not be worth a premium to get your answer sooner by running more massively parallel (but for less wall clock time) on an EC2 like service?

I suspect these types of tools becoming only relevant to real time applications (due to reduced latency vs. EC2), and or nonstop computing (assuming there's a big price/performance win).

Pretty soon someone will rent you GPUs by the hour, at which point you'd have the advantages of elasticity and price/performance.

That actually sounds like a neat business.

It's easy to imagine EC2 expanding beyond 1U servers and databases to GPGPUs, FGPAs or quantum cores. There's a lot of potential for a gpu cloud - from quick rendering (xtraNormal/nVidia Gelato) to scientific computing (Larrabee?).

Why stop at one frame per core? Once you have easily scalable renderfarms, you could switch the the somewhat slower (though currently less heavily optimized) raytracing approach, and run almost as many cores per frame as you like. That way the only thing limiting your render time is your budget (not that that hasn't always been true, but your set up makes it sound like there is a "rock bottom" limit that you reach before the end of your budget at one hour per frame).

Most modern high-end offline rasterizers aren't forward renderers, or deferred renders, _or_ ray tracing. No, they are typically radiosity renderers: http://en.wikipedia.org/wiki/Radiosity

Put simply is that ray-tracing is a per-screen pixel ray which is quite good at glossy surfaces with predictable lighting and plastic appearance. Radiosity, on the other hand, simulates actual light photons/waves. It is slower and more computational intensive, but it produces far more realistic results. In particular, it is good at lighting/shadowing, and is more directly applicable to rendering non-plastic surfaces, including sub-surface scattering (like flesh or hair).

All that said, REAL modern renderers, are wacky hybrid of every technique :-P

You're right, I forgot about the radiosity - but couldn't that still be split up to multiple cores per frame? i.e. simulate one "bundle" of photons per core, and then presuming that you're not too badly i/o bound, you should be able to do some sort of map/reduce. Each would generate a separate scene of light, and you would add them all together to make the final frame.

Yes, it can made data parallel, but not nearly as easily as ray-tracing. Ray tracing is easily parallelized by dividing the screen into sub renders. Each box renders a different NxM segment of the final image. This approach doesn't work for radiosity because each patch is dependant on the computations of other patches.

The primary trick used to parallelize radiosity is to partition the scene spatially. Treat the virtual polygons which separate the rooms as light absorbers. When the room is finished with all of the available light, send the light absorber across the bus as light emitters to the other processes rendering the other rooms. Iterate back and forth until the light absorbers absorb under a threshold of light.

Reply on news.ycombinator.com