←back to thread

Pixar's Render Farm

(twitter.com)
382 points brundolf | 1 comments | 02 Jan 21 19:56 UTC | HN request time: 0.26s | source
Show context
thomashabets2 ◴[02 Jan 21 20:38 UTC] No.25616274[source]▶
I'm surprised they hit only 80-90% CPU utilization. Sure, I don't know their bottlenecks, but I understood this to be way more parallelizable than that.

I ray trace quake demos for fun at a much much lower scale[0], and have professionally organized much bigger installs (I feel confident in saying even though I don't know Pixar's exact scale).

But I don't know state of the art rendering. I'm sure Pixar knows their workload much better than I do. I would be interested in hearing why, though.

[0] Youtube butchers the quality in compression, but https://youtu.be/0xR1ZoGhfhc . Live system at https://qpov.retrofitta.se/, code at https://github.com/ThomasHabets/qpov.

Edit: I see people are following the links. What a day to overflow Go's 64bit counter for time durations on the stats page. https://qpov.retrofitta.se/stats

I'll fix it later.

replies(5): >>25616362 #>>25616369 #>>25616380 #>>25616401 #>>25617648 #
1. mike_d ◴[02 Jan 21 20:51 UTC] No.25616401[source]▶
Rendering may be highly parallelizable, but the custom bird flock simulation they wrote may be memory constrained. This is why having a solid systems team who can do care and feeding of a job scheduler is worth more than expanding a cluster.