For large filters, convolving in frequency space is definitely a win (especially if you want to do other manipulations there). But many of the simple filters used in graphics are discrete and have pretty small areas of support in the time domain, typically 3x3 or 5x5. A perfectly reasonable sharpening kernel is:
-1 -1 -1 -1 +9 -1 -1 -1 -1
It's usually quicker to just slide that over the image and convolve directly, sticking to basic integer multiplication and arithmetic. For these kinds of filters, the efficiency gain in Fourier space is normally outweighed by the overhead of converting to that domain and back.
I'll have to look into Kalman filters. I knew when I posted that someone was probably going to call me on the Wiener filters since I knew there were better - they were just the first example that I could think of off the top of my head at 2 AM. I'm not familiar with Kalman though.
That's probably not quite "deconvolution"; it's probably high-pass filtering in Fourier frequency space...
Nah, simple sharpening kernels like PS does are quicker and easier to apply the spatial domain. Frequency space is overkill.
To deconvolve, you have to have a proper kernel to "deconvolve" with, which Photoshop has no knowledge of.
Yes, but there are plenty of techniques out there for estimating a filter, either bootstrapping from nothing or using a little information. Check out Wiener filters for an example of an early approach (Granted there are some pesky requirements: ergotic signal, uncorrelated noise, signal and noise are zero-mean, etc.)
Yeah, but C programming's nerfed. You should put some skill points into getting C++ so you can get into the newer dungeons. The grind to get it up enough can be a pain, but real wiz^H^H^H mage oughta be able to handle it fairly easily.
The site mentioned that this was a simulation as though the speed of light were only 30km/h. That makes the time and distance scale reasonable enough to give you the sense of the relativistic distortion.
Well, I know at that at least one video game composer, Jeremy Soule, has expressed his support for them and even submitted a FFVI remix of his own.
Granted, that's an individual opinion and the video game companies may think a little differently. But it's good to know that there's at least one composer who is aware of and doesn't mind remixes of his work up there.
I noticed that nowhere in TFA did he mention anything about where the money comes from (other than that its cheaper now). I'd have loved to try starting a company after college. But in the real world, I had students lots of expensive loans to pay off, rent on an apartment, various bills. Where would he expect me to have paid that from? How does he expect me to eat? He sort of seems to be overlooking the chicken and the egg problem. Yes, a newly graduated student can live cheaply -- but not for free.
[dash dit / dash dash dash / dash dit dash] dit dit dash dit / dit dit / dit dash dit / dit dit dit / dash dit dash dash dit / dash dash dash / dit dit dit / dash / dit dit dash dash dit dit
Wow... I guess I lost out in the moderator lottery today! My poor attempt at humour may have fallen flat but it was certainly not meant as a troll.
I was kidding, okay? Obviously, PDF is a good choice for a document like that when they want page-level formatting and such, and when the new format described is not ubiquitous or implemented yet. (Parent was meant as a joke about bootstrapping a new format.) PDF is open and is great with the right tools -- Preview and the "Save as PDF" buttons in OS X rock! (Though I've done the same thing for years in Windows, using a generic PS printer driver, the save to file button in the print dialog box and ps2pdf -- OS X just makes it far more convenient.) And between open tools like Ghostscript, pdftk, pdflatex, Scribus and anything else that produces PS or PDF directly, it's possible to do quite a bit. I've also found it wonderful for archiving interesting papers and other documents useful to my research.
Sorry to tell you this, but the review is even mistaken with respect to Povray. Povray is not a C++ program - it's good ol' C. So in fact, none of the programs he benchmarked were C++. The test was exclusively on C code.
As nice as C is, a lot of the improvements in GCC seemed to have been targetted at improving its handling of C++ code. I'd particularly like to know how it fairs with respect to modern C++ style code - massively templated stuff with STL, Boost, traits and policies, smart pointers, lots of small inlined methods, etc. This test tells me nothing about that, and that's where a lot of development is these days.
when you choose to abandon LISP in favour of, say, static type checking, his insistence that all great hackers prefer LISP, and if you don't prefer LISP you aren't a great hacker, begins to grate somewhat.
Yes, that's my biggest problem with his writings. I rather like static type checking personally, and will gladly trade the minor benefit in malleabillity for more error checking at compile time. I can't count the times I've made a trivial typo in Perl, for example, taken hours to find it and then thought to myself, "this would have been caught instantly in ML."
While LISP is a cool language, I really like what I've seen of the strongly static-typed functional languages like the ML family (especially OCaml.) I love the pattern matching features for example. The only thing I miss in them is the macro mechanism from LISP or Scheme and the extreme performance optimizations of modern C++ compilers. I do heavy-duty numerical coding in C++ (graphics/ray tracing), but I'd love to be able to write code in a statically-typed functional language, have macros expand out and optimize or inline the low-level, performance critical parts and have the compiler optimizer work it over till it's as fast as I'd be able to do in C++. (or faster!)
So yes, I consider myself a pretty good code-hacker, but I'd still not pick LISP for my graphics code. LISP is not the right tool for every job.
It's not at all obvious, but you can have a URL link to a specific page of a PDF in Acrobat Reader. Tack something like #page=42 onto the end of a URL to a PDF and Reader will open it to that page. (Of course, for what you describe you'll still have to update the URL when you finish, but it's better than nothing.)
For me, the most moving scene in FFVI was the destruction of Doma. Man, wipe out everyone that Cyan has ever known and loved in one stroke. Talk about nothing left to live for, poor guy.
FFVI is definitely up there as one of my favorites. I really liked all of the SNES FFs. Honestly, I prefer the older tile and sprite games from Square to the newer 3D ones. For one, they left a little more to the imagination. Second, I find the stories feel more self-consistent and like they're about the right length. FFVII and up seemed to just drag on the stories always felt too convoluted. Maybe it's an age thing and I'd like the 3D ones better if I'd started with them.
I actually attended this lecture yesterday and Vinton disclaimed the "father of the internet" moniker, saying that he co-designed the original TCP/IP protocol but that he and Bob Kahn and that that work was largely based on the ARPANET design which was in turn based on packet radio, etc. So yes, the man himself said he was just one of a long list contributors.
He did joke though that his son once asked if he was the "brother of the Internet".
He also commented that one of the properties of the system that he was quite happy with was the ease with which others could contribute at any level of the system, including building new application layer protocols on top of the basic protocols without going and needing to go and get permission from someone. People can just go out and write new protocols and build the apps to use them. (e.g. Bit Torrent) He said he thought that the Internet is largely where it is today because of that openness to the contributions of thousands of people.
The burden of extracting parallelism will shift squarely on the programmer in the coming years. The hardware has been extracting ILP (instruction level parallelism) for you automatically for several years now.
True. And in many ways I see it as a good thing for programmers to understand parallelism. I think of ILP vs. program level parallelism as analogous to optimizing compilers vs. using the correct algorithm. Like the compiler, the processor can certainly help with micro-optimizations. But it's up to the programmer to manage the bigger picture.
Because of thermal limits, we are entering an era where you will either have to scale switching speed (frequency) OR density.
Given the memory/bandwidth bottleneck, choosing density makes a lot of sense to me since in addition to greater parallelism, it also allows for more room for larger on-chip caches to aid performance. Given that the caches tend to switch much less actively and therefore run much cooler than the other parts of a processor, I'd expect enlarging them to give pretty decent return on performance vs. heat dissipation.
Yes, but if you've looked at some of the chip diagrams, dual-core chips can do funky things like share the same on-chip cache and stuff. Plus, eventually you should be able to run dual- dual-cores to have a quad-core machine.
A lot of the systems folks that I've been hearing from and things that I've been reading have suggested that, like it or not, multi-core systems are the way of the future. The argument is that the clock-speed aspect of Moore's law has been slowing down for the past couple of years and that we've seen single processors that are as fast as they'll go with current chip design and fabrication technology. (Barring fundamental breakthroughs, of course.) Hence parallelism and multi-core systems.
I think the point is that it's not really a choice between clock speed and parallelism. You may still have a choice at the moment, but don't expect that to continue. Developers will have to start learning to deal with parallelism if they don't want to fall off the performance curve. I expect we'll start seeing methods, tools, languages and libraries to help developers manage it easily while avoid the common dangers of deadlock and inconsistency. There's some interesting research in the area and we may start seeing some of that find its way into production systems. And of course once developers start adopting parallelism, consumers will in turn begin to see the benefits of it.
In some ways its an obvious message if you look at supercomputers. No one's running serial code on petahertz machines! They're all just systems with large numbers of fairly pedestrian processors with custom fast, low-latency interconnects. As always, this is just the natural trickling down of that to the desktop level.
The bit about graphics cards not being needed was my first thought when I read his post. But what I think he meant was that they need the graphics cards for interactively previewing scenes in the modeller and such. Though I'll agree with you that they're doing enough wacky displacement mapping and such that they really need the renderer output anyway.
Often some combination of Maya on the front-end with lots of custom scripts is used to generate RIB data which is rendered by a RenderMan interface compliant renderer. You won't get PRMan (Pixar's implementation) very cheaply, but there some other good implentations. You may still be able to dig up a copy of the Blue Moon Rendering Tools (BMRT) somewhere. RenderDotC has a resolution limited evaluation version. There's also Aqsis and which is GPL, but I haven't used it so I can't really speak on its quality or how complete it is. Pixie is another GPL renderer which seems pretty cool. All of them can run on Linux.
Part of the reason that RenderMan renderers are so popular is that they let you write custom shader scripts which they interpret to shade and deform the geometry. It's kind of the equivalent of GPU pixel and vertex shaders (which are partly inspired by RenderMan, by the way.)
If you want books, Advanced RenderMan is excellent. (My copy is well worn.) The RenderMan Repository has some examples and some good basic information on RenderMan. They also have a nice collection of PDF's of the course notes from the RenderMan SIGGRAPH courses over the years. Those typically have chapters by folks from the studios describing how they accomplished certain effects. I highly recommend it for getting the flavor of the the thing. Lastly, there's the RenderMan spec itself from Pixar, though I certainly wouldn't recommend it as an introduction to all this.
My suggestion to start trying this stuff out would be too Google for RIB export scripts/plugins for Blender (I know they exists, but I don't use Blender), grab one of the GPL renderers out there and pick up a copy of Advanced RenderMan to start learning the shading language. Good luck!
Sigh... This is why I shouldn't post first thing in the morning.
Yes, yes, I'm well aware that there's more to computers than clock rates. Lately I've been dealing with tuning my code to optimize cache-coherency, memory access paterns, latency-hiding, instruction scheduling, parallelism and all that jazz.
But it's still a fact that you only get so many cycles per second. If you're CPU bound, then raising the clock rate increases your cycle budget commensurately. Even allowing for differences in cycle counts and superscalar/out-of-order execution, clock rate is still a factor. Superscalar execution and multiple pipes and all are nice but they'll thrash on inherently serial code blocks with data dependencies, for example. And most code these days is still written without thought for parallelism. (Yes, I know about parallelizing compilers -- they can only do so much, just like any optimizer.) Given that, clock rate at least is a nice, simple, rough performace metric that is independent of the code itself.
Yes, I've noticed this too. I've just gone back to grad school in CS. It's interesting to me to hear how many of the profs and students love their Macs and how those who'd got Intel based machines wished they'd gotten a Mac. I used to think that raw processor clock rate was everything, but I've seen the Macs run circles around Intel machines with half-again as much clock rate. And this on CPU and numerically intensive tasks. And the folks who are using the Macs are hard-core alpha-geek types too. I've also heard very good things about the dev tools from them.
When it came time to pick a machine for myself for the lab, I ended up going with the Mac -- and I'm someone who's never had a Mac before. Part of my motivation was the "getting stuff done". I don't care if it doesn't play games like my home Wintel box. I need good Unix/X compatibility for when I deal with the big iron. And I don't want to have to futz with dozens of/etc files like in Linux either. I'm there to study, do research and write some code and go home. From this point of view, the Mac wins.
But I'll admit that the design and prettiness of the environment doesn't hurt. If I'm going to be spending hours every day looking at the screen, it might as well look good. (No badly aliased, bitmapped text in Emacs windows, thank you.)
I thought this was old news, having to deal with the theory of scale free systems, power-laws, etc. Most nodes on the internet are leaf nodes or have only a few connections to larger nodes which in turn feed into still larger nodes on up to supernodes which tie everything together. The probability of a node have some number of links is inversely proportional to the number of links raised to a power.
It turns out that this design has a couple of advantages. For one, the network diameter grows only logarithmically with the number of nodes. There's a fairly low bound on the number of hops between any two nodes, and the average is even better.
It's also quite robust in the face of random outages. As the vast majority of the nodes are leafs or small local networks, removing any single node at random tends to have only small local effects. Since there are so few of them, the odds are heavily against a critical node going down.
As nice as it is, the scheme isn't so robust against targetted damage. Destroying just a handful of nodes brings the system to its knees.
Interesting bit of history: According to "Advanced RenderMan", Pixar's RenderMan started out as a project to build a hardware renderer. The algorithms were prototyped in software on general purpose machines which ended up overtaking the hardware project on price/performance and the hardware was abandonned.
Slashdot Mirror
I'll have to look into Kalman filters. I knew when I posted that someone was probably going to call me on the Wiener filters since I knew there were better - they were just the first example that I could think of off the top of my head at 2 AM. I'm not familiar with Kalman though.
Yeah, but C programming's nerfed. You should put some skill points into getting C++ so you can get into the newer dungeons. The grind to get it up enough can be a pain, but real wiz^H^H^H mage oughta be able to handle it fairly easily.
The site mentioned that this was a simulation as though the speed of light were only 30km/h. That makes the time and distance scale reasonable enough to give you the sense of the relativistic distortion.
Well, I know at that at least one video game composer, Jeremy Soule, has expressed his support for them and even submitted a FFVI remix of his own.
Granted, that's an individual opinion and the video game companies may think a little differently. But it's good to know that there's at least one composer who is aware of and doesn't mind remixes of his work up there.
I noticed that nowhere in TFA did he mention anything about where the money comes from (other than that its cheaper now). I'd have loved to try starting a company after college. But in the real world, I had students lots of expensive loans to pay off, rent on an apartment, various bills. Where would he expect me to have paid that from? How does he expect me to eat? He sort of seems to be overlooking the chicken and the egg problem. Yes, a newly graduated student can live cheaply -- but not for free.
[dash dit / dash dash dash / dash
dit dash]
dit dit dash dit / dit dit / dit dash dit / dit dit dit / dash
dit dash dash dit / dash dash dash / dit dit dit / dash / dit dit dash dash dit dit
Silly lameness filter...
Wow... I guess I lost out in the moderator lottery today! My poor attempt at humour may have fallen flat but it was certainly not meant as a troll.
I was kidding, okay? Obviously, PDF is a good choice for a document like that when they want page-level formatting and such, and when the new format described is not ubiquitous or implemented yet. (Parent was meant as a joke about bootstrapping a new format.) PDF is open and is great with the right tools -- Preview and the "Save as PDF" buttons in OS X rock! (Though I've done the same thing for years in Windows, using a generic PS printer driver, the save to file button in the print dialog box and ps2pdf -- OS X just makes it far more convenient.) And between open tools like Ghostscript, pdftk, pdflatex, Scribus and anything else that produces PS or PDF directly, it's possible to do quite a bit. I've also found it wonderful for archiving interesting papers and other documents useful to my research.
Is anyone else amused that the draft is in PDF form?
Sorry to tell you this, but the review is even mistaken with respect to Povray. Povray is not a C++ program - it's good ol' C. So in fact, none of the programs he benchmarked were C++. The test was exclusively on C code.
As nice as C is, a lot of the improvements in GCC seemed to have been targetted at improving its handling of C++ code. I'd particularly like to know how it fairs with respect to modern C++ style code - massively templated stuff with STL, Boost, traits and policies, smart pointers, lots of small inlined methods, etc. This test tells me nothing about that, and that's where a lot of development is these days.
when you choose to abandon LISP in favour of, say, static type checking, his insistence that all great hackers prefer LISP, and if you don't prefer LISP you aren't a great hacker, begins to grate somewhat.
Yes, that's my biggest problem with his writings. I rather like static type checking personally, and will gladly trade the minor benefit in malleabillity for more error checking at compile time. I can't count the times I've made a trivial typo in Perl, for example, taken hours to find it and then thought to myself, "this would have been caught instantly in ML."
While LISP is a cool language, I really like what I've seen of the strongly static-typed functional languages like the ML family (especially OCaml.) I love the pattern matching features for example. The only thing I miss in them is the macro mechanism from LISP or Scheme and the extreme performance optimizations of modern C++ compilers. I do heavy-duty numerical coding in C++ (graphics/ray tracing), but I'd love to be able to write code in a statically-typed functional language, have macros expand out and optimize or inline the low-level, performance critical parts and have the compiler optimizer work it over till it's as fast as I'd be able to do in C++. (or faster!)
So yes, I consider myself a pretty good code-hacker, but I'd still not pick LISP for my graphics code. LISP is not the right tool for every job.
It's not at all obvious, but you can have a URL link to a specific page of a PDF in Acrobat Reader. Tack something like #page=42 onto the end of a URL to a PDF and Reader will open it to that page. (Of course, for what you describe you'll still have to update the URL when you finish, but it's better than nothing.)
More info here.
I'd add:
- The destruction of Mist. (Rydia's village)
- Finding the Big Whale (loved the Big Whale music).
FFIV was my first real RPG as well.
For me, the most moving scene in FFVI was the destruction of Doma. Man, wipe out everyone that Cyan has ever known and loved in one stroke. Talk about nothing left to live for, poor guy.
FFVI is definitely up there as one of my favorites. I really liked all of the SNES FFs. Honestly, I prefer the older tile and sprite games from Square to the newer 3D ones. For one, they left a little more to the imagination. Second, I find the stories feel more self-consistent and like they're about the right length. FFVII and up seemed to just drag on the stories always felt too convoluted. Maybe it's an age thing and I'd like the 3D ones better if I'd started with them.
Note the key phrase "one of" in the story.
I actually attended this lecture yesterday and Vinton disclaimed the "father of the internet" moniker, saying that he co-designed the original TCP/IP protocol but that he and Bob Kahn and that that work was largely based on the ARPANET design which was in turn based on packet radio, etc. So yes, the man himself said he was just one of a long list contributors.
He did joke though that his son once asked if he was the "brother of the Internet".
He also commented that one of the properties of the system that he was quite happy with was the ease with which others could contribute at any level of the system, including building new application layer protocols on top of the basic protocols without going and needing to go and get permission from someone. People can just go out and write new protocols and build the apps to use them. (e.g. Bit Torrent) He said he thought that the Internet is largely where it is today because of that openness to the contributions of thousands of people.
True. And in many ways I see it as a good thing for programmers to understand parallelism. I think of ILP vs. program level parallelism as analogous to optimizing compilers vs. using the correct algorithm. Like the compiler, the processor can certainly help with micro-optimizations. But it's up to the programmer to manage the bigger picture.
Given the memory/bandwidth bottleneck, choosing density makes a lot of sense to me since in addition to greater parallelism, it also allows for more room for larger on-chip caches to aid performance. Given that the caches tend to switch much less actively and therefore run much cooler than the other parts of a processor, I'd expect enlarging them to give pretty decent return on performance vs. heat dissipation.
Yes, but if you've looked at some of the chip diagrams, dual-core chips can do funky things like share the same on-chip cache and stuff. Plus, eventually you should be able to run dual- dual-cores to have a quad-core machine.
A lot of the systems folks that I've been hearing from and things that I've been reading have suggested that, like it or not, multi-core systems are the way of the future. The argument is that the clock-speed aspect of Moore's law has been slowing down for the past couple of years and that we've seen single processors that are as fast as they'll go with current chip design and fabrication technology. (Barring fundamental breakthroughs, of course.) Hence parallelism and multi-core systems.
I think the point is that it's not really a choice between clock speed and parallelism. You may still have a choice at the moment, but don't expect that to continue. Developers will have to start learning to deal with parallelism if they don't want to fall off the performance curve. I expect we'll start seeing methods, tools, languages and libraries to help developers manage it easily while avoid the common dangers of deadlock and inconsistency. There's some interesting research in the area and we may start seeing some of that find its way into production systems. And of course once developers start adopting parallelism, consumers will in turn begin to see the benefits of it.
In some ways its an obvious message if you look at supercomputers. No one's running serial code on petahertz machines! They're all just systems with large numbers of fairly pedestrian processors with custom fast, low-latency interconnects. As always, this is just the natural trickling down of that to the desktop level.
The bit about graphics cards not being needed was my first thought when I read his post. But what I think he meant was that they need the graphics cards for interactively previewing scenes in the modeller and such. Though I'll agree with you that they're doing enough wacky displacement mapping and such that they really need the renderer output anyway.
Often some combination of Maya on the front-end with lots of custom scripts is used to generate RIB data which is rendered by a RenderMan interface compliant renderer. You won't get PRMan (Pixar's implementation) very cheaply, but there some other good implentations. You may still be able to dig up a copy of the Blue Moon Rendering Tools (BMRT) somewhere. RenderDotC has a resolution limited evaluation version. There's also Aqsis and which is GPL, but I haven't used it so I can't really speak on its quality or how complete it is. Pixie is another GPL renderer which seems pretty cool. All of them can run on Linux.
Part of the reason that RenderMan renderers are so popular is that they let you write custom shader scripts which they interpret to shade and deform the geometry. It's kind of the equivalent of GPU pixel and vertex shaders (which are partly inspired by RenderMan, by the way.)
If you want books, Advanced RenderMan is excellent. (My copy is well worn.) The RenderMan Repository has some examples and some good basic information on RenderMan. They also have a nice collection of PDF's of the course notes from the RenderMan SIGGRAPH courses over the years. Those typically have chapters by folks from the studios describing how they accomplished certain effects. I highly recommend it for getting the flavor of the the thing. Lastly, there's the RenderMan spec itself from Pixar, though I certainly wouldn't recommend it as an introduction to all this.
My suggestion to start trying this stuff out would be too Google for RIB export scripts/plugins for Blender (I know they exists, but I don't use Blender), grab one of the GPL renderers out there and pick up a copy of Advanced RenderMan to start learning the shading language. Good luck!
Sigh... This is why I shouldn't post first thing in the morning.
Yes, yes, I'm well aware that there's more to computers than clock rates. Lately I've been dealing with tuning my code to optimize cache-coherency, memory access paterns, latency-hiding, instruction scheduling, parallelism and all that jazz.
But it's still a fact that you only get so many cycles per second. If you're CPU bound, then raising the clock rate increases your cycle budget commensurately. Even allowing for differences in cycle counts and superscalar/out-of-order execution, clock rate is still a factor. Superscalar execution and multiple pipes and all are nice but they'll thrash on inherently serial code blocks with data dependencies, for example. And most code these days is still written without thought for parallelism. (Yes, I know about parallelizing compilers -- they can only do so much, just like any optimizer.) Given that, clock rate at least is a nice, simple, rough performace metric that is independent of the code itself.
Yes, I've noticed this too. I've just gone back to grad school in CS. It's interesting to me to hear how many of the profs and students love their Macs and how those who'd got Intel based machines wished they'd gotten a Mac. I used to think that raw processor clock rate was everything, but I've seen the Macs run circles around Intel machines with half-again as much clock rate. And this on CPU and numerically intensive tasks. And the folks who are using the Macs are hard-core alpha-geek types too. I've also heard very good things about the dev tools from them.
/etc files like in Linux either. I'm there to study, do research and write some code and go home. From this point of view, the Mac wins.
When it came time to pick a machine for myself for the lab, I ended up going with the Mac -- and I'm someone who's never had a Mac before. Part of my motivation was the "getting stuff done". I don't care if it doesn't play games like my home Wintel box. I need good Unix/X compatibility for when I deal with the big iron. And I don't want to have to futz with dozens of
But I'll admit that the design and prettiness of the environment doesn't hurt. If I'm going to be spending hours every day looking at the screen, it might as well look good. (No badly aliased, bitmapped text in Emacs windows, thank you.)
I thought this was old news, having to deal with the theory of scale free systems, power-laws, etc. Most nodes on the internet are leaf nodes or have only a few connections to larger nodes which in turn feed into still larger nodes on up to supernodes which tie everything together. The probability of a node have some number of links is inversely proportional to the number of links raised to a power.
It turns out that this design has a couple of advantages. For one, the network diameter grows only logarithmically with the number of nodes. There's a fairly low bound on the number of hops between any two nodes, and the average is even better.
It's also quite robust in the face of random outages. As the vast majority of the nodes are leafs or small local networks, removing any single node at random tends to have only small local effects. Since there are so few of them, the odds are heavily against a critical node going down.
As nice as it is, the scheme isn't so robust against targetted damage. Destroying just a handful of nodes brings the system to its knees.
Don't forget that there's already Google Linux and Google BSD. Not quite what you're asking for, but a little closer.
And Google Labs has Google Personalized Search where you can flag open source as a topic of interest.
Interesting bit of history: According to "Advanced RenderMan", Pixar's RenderMan started out as a project to build a hardware renderer. The algorithms were prototyped in software on general purpose machines which ended up overtaking the hardware project on price/performance and the hardware was abandonned.