Live data from Hacker News

Pixar's Render Farm

twitter.com

51–60 of 323 posts

Re: Pixar's Render Farm

#51

Can anyone comment on why Pixar uses standard CPU for processing instead of custom hardware or GPU? I'm wondering why they haven't invested in FPGA or completely custom silicon that speeds up common operations by an order of magnitude. Is each show that different that no common operations are targets for hardware optimization?

Probably because CPU times fall within acceptable windows. That would be my guess. You can go faster with FPGA or silicon, but it also has a very high cost, on the order of 10 to 100 as expensive. You can get a lot of hardware for that.

Re: Pixar's Render Farm

#53
I would love to know about some curious questions, for example:

If there's a generally static scene with just characters walking through it, does the render take advantage of rendering the static parts for the whole scene once, and then overlay and recompute the small differences caused by the moving things in each individual sub frame?

Or, alternatively what "class" of optimizations does something like that fall into?

Is rendering of video games more similar to rendering for movies, or for VFX?

What are some of physics "cheats" that look good enough but massively reduce compute intensity?

What are some interesting scaling laws about compute intensity / time versus parameters that the film director may have to choose between? "Director X, you can have but that means to fit in the budget, we can't do "

Can anyone point to a nice introduction to some of the basic compute-relevant techniques that rendering uses? Thanks!

Re: Pixar's Render Farm

#54

Can anyone comment on why Pixar uses standard CPU for processing instead of custom hardware or GPU? I'm wondering why they haven't invested in FPGA or completely custom silicon that speeds up common operations by an order of magnitude. Is each show that different that no common operations are targets for hardware optimization?

Because the expense is not really worth it - even GPU rendering (while around 3/4 x faster than CPU rendering) is memory constrained compared to CPU rendering, and as soon as you try and go out-of-core on the GPU, you're back at CPU speeds, so there's usually no point doing GPU rendering for entire scenes (which can take > 48 GB of RAM for all geometry, accel structures, textures, etc) given the often large memory requirements.

High end VFX/CG usually tessellates geometry down to micropolygon, so you roughly have 1 quad (or two triangles) per pixel in terms of geometry density, so you can often have > 150,000,000 polys in a scene, along with per vertex primvars to control shading, and many textures (which can be paged fairly well with shade on hit).

Using ray tracing pretty much means having all that in memory at once (paging sucks in general of geo and accel structures, it's been tried in the past) so that intersection / traversal is fast.

Doing lookdev on individual assets (i.e. turntables) is one place where GPU rendering can be used as the memory requirements are much smaller, but only if the look you get is identical to the one you get using CPU rendering, which isn't always the case (some of the algorithms are hard to get working correctly on GPUs, i.e. volumetrics).

Renderman (the renderer Pixar use, and create in Seattle) isn't really GPU ready yet (they're attempting to release XPU this year I think).

Re: Pixar's Render Farm

#56

I would love to know about some curious questions, for example: If there's a generally static scene with just characters walking through it, does the render take advantage of rendering the static parts for the whole scene once , and then overlay and recompute the small differences caused by the moving things in each individual sub frame? Or, alternatively what "class" of optimizations does something like that fall in…

Illumination is global so each frame needs to be rendered separately AFAIK.

Re: Pixar's Render Farm

#57

Earlier quoted context omitted.

Thank you. All I saw was a post with zero context, followed by a reply, followed by another reply using a different reply delineator (a horizontal break instead of a vertical line??), followed by nothing. It just ends. It's hard to believe this is real and intended.

It's amazing to me that people find twitter difficult to read... I mean it's not perfect but it's not an ovaltine decoder ring, either. Just ... Scroll ... Down ... Click where it says "read more" or "show more replies" You're human; THE most adaptable creature known. Adapt! I'm not saying that twitter UX is perfect, or even good. I AM saying that it is usable.

I think building a more usable alternative (or in this case using an existing one) is a better idea than adapting to Twitter's horrendous "UX".

Re: Pixar's Render Farm

#58

Can anyone comment on why Pixar uses standard CPU for processing instead of custom hardware or GPU? I'm wondering why they haven't invested in FPGA or completely custom silicon that speeds up common operations by an order of magnitude. Is each show that different that no common operations are targets for hardware optimization?

In addition to what others have said, I remember reading somewhere that CPUs give more reliably accurate results, and that that's part of why they're still preferred for pre-rendered content

Re: Pixar's Render Farm

#59
post #47

For those that can't stand Twitter's UI: https://threadreaderapp.com/thread/1345146328058269696.html

It's very painful to follow a conversation on Twitter. I'm not sure why they think the way they've done things makes sense.

It was never supposed to support conversation in the first place.

People were supposed to shoot short, simple, single messages and other people maybe react to this with their own short, single messages.

Re: Pixar's Render Farm

#60
post #3

My understanding (I am not an authority) is that for a long time, it has taken Pixar roughly an equal amount of time to render one frame of film. Something on the order of 24 hours. I don’t know what the real units are though (core-hours? machine-hours? simple wall clock?) I am not surprised that they “make the film fit the box”, because managing compute expenditures is such a big deal! (Edit: When I say "simple wall…

Wait, what? 24 hours per frame?! At the standard 24fps it takes you 24 days per film second which works out to 473 years for the average 2 hour long film which can't be right.

Again, I'm not sure whether this is core-hours, machine-hours, or wall clock. And to be clear, when I say "wall clock", what I'm talking about is latency between when someone clicks "render" and when they see the final result.

My experience running massive pipelines is that there's a limited amount of parallelization you can do. It's not like you can just slice the frame into rectangles and farm them out.

Post reply on HN