"Pixar Quality Graphics" is 720 Gflops

For at least 10 years GPU vendors have been talking about "Pixar Quality" graphics. But what does that mean? Well, according to this lecture on The Design of Renderman, the original goals for the REYES architecture were
  • 3000 x 1667 pixels (5 MP)
  • 80M Micropolygons (each 1/4th of a pixel in size, depth complexity of 4)
  • 16 samples per pixel
  • 150K geometric primitives
  • 300 shading flops per micropolygon
  • 6 textures per primitive
  • 100 1MB textures
That's a shading rate of 80M * 300 * 30 Hz = 720 Gflops. (They were probably more concerned about 24 Hz, but for games 30Hz is better.)

In comparison I think the peak shader flops of high-end 2008-era video cards are in the 1 TFlop range. (Xbox 360 Xenos is 240 Gflops, PS3 is a bit less.). Now, GPU vendors typically quote multiply-accumulate flops, because that doubles the number of flops. So it's more realistic to say that 2008-era video cards are in the 500 Gflop range. So we really are entering the era of "Pixar Quality" graphics.

Comments

Ho Ho said…
Riiigth. If we don't consider the efficiency of patching, memory fetches, changing shaders and metric ton of other things that are needed to be done to get image to screen then that really simple calculation holds true.

Unfortunately in real world we can't just calculate performance by simple formulas. I'd say we are about 2-3 orders of magnitude short of true Pixar quality images.

If I remember correctly Reyes spent around 2-4h per frame on average 2p rendering node a few years ago. At that time high-end 2p machines had around 20GFlops of theoretical peak computing power. That meant around 150-300k gflops could have been performed over that time and that was around 8 years ago, today Pixar movies take several times more computing power. I'd say current high-end 2P nodes should have around 100-150gflops of peak throughput but rendering takes just as long if not longer than back then.

Also, that 1Tflop for GPU performance is vastly exaggerated. You'll be lucky to get >20% of it in any real-world scenario. In GPGPU you might get a bit more, in games less.
February 17, 2009 at 1:57 AM
Post a Comment

Popular posts from this blog

GLES Quake - a port of Quake to the Android platform

I've just published the source code to a port of Quake to the Android platform . This is something I did a while ago as a internal test application. It's not very useful as a game, because there hasn't been any attempt to optimize the controls for the mobile phone. It's also awkward to install because the end user has to supply the Quake data files on their own. Still, I thought people might enjoy seeing a full-sized example of how to write a native code video game for the Android platform. So there it is, in all its retro glory. (Porting Quake II or Quake III is left as an exercise for the reader. :-) What's different about this particular port of Quake? Converted the original application into a DLL Android applications are written in Java, but they are allowed to call native languge DLLs, and the native language DLLs are allowed to call a limited selection of OS APIs, which include OpenGL ES and Linux File I/O. I was able to make the game work by using Java for: T...
Read more

A Taipei-Torrent postmortem: Writing a BitTorrent client in Go

This is a BitTorrent client. There are many like it, but this one is mine. -- the BitTorrent Implementer's Creed For fun I've started writing a command-line BitTorrent client in Google's go programming language. The program, Taipei-Torrent , is about 70% done. It can successfully download a torrent, but there are still lots of edge cases to implement. Go routines and channels are a good base for writing multithreaded network code. My design uses goroutines as follows: a single main goroutine contains most of the BitTorrent client logic. each BitTorrent peer is serviced by two goroutines: one to read data from the peer, the other to write data to the peer. a goroutine is used to communicate with the tracker some "time.Tick" goroutines are used to wake the main goroutine up periodically to perform housekeeping duties. All the complicated data structures are owned by the main goroutine. The other goroutines just perform potentially blocking network I/O using channel...
Read more

Writing an Android application in JavaScript and HTML5

Image
Happy Mother's Day everyone! This year I wrote an Android app for my wife for Mother's Day. How geeky is that? The reason I wrote it is that my wife's favorite Android application, Word Mix Lite, recently added annoying banner ads. While the sensible thing to do might have been to switch to another app, or perhaps upgrade to the paid version of Word Mix, I thought it might be interesting to see if I could write my own replacement. And as long as I was writing the app, I though I'd try writing it using JavaScript. Normally Android applications are written in Java, but it's also possible to write them in JavaScript, by using a shell application such as PhoneGap . Why use JavaScript instead of Java? Well, hack value mostly. On the plus side it's a fun to write! Another potential plus is that it is theoretically possible to run the same PhoneGap application on both Android and Apple. The drawback is that PhoneGap is not very popular yet, especially among Android dev...
Read more