Nvidia Releases Hardware-Accelerated Film Renderer 251
snowtigger writes "The day we'll be doing movie rendering in hardware has come: Nvidia today released Gelato, a hardware rendering solution for movie production with some advanced rendering features: displacement, motion blur, raytracing, flexible shading and lighting, a C++ interface for plugins and integration, plus lots of other goodies used in television and movie production. It will be nice to see how this will compete against the software rendering solutions used today. And it runs under Linux too, so we might be seeing more Linux rendering clusters in the future =)" Gelato is proprietary (and pricey), which makes me wonder: is there any Free software capable of exploiting the general computing power of modern video cards?
This would be more useful (Score:-1, Insightful)
the problem is in the Bus (Score:5, Insightful)
Teh horror !!! (Score:5, Insightful)
A company that wants to be payed for their work, weird !
You will see more, allot more, of this for the Linux platform in the near future.
Software may be released with source code, but no way that it will be released under GPL, most ISV's can't make a living releasing their work under GPL.
And please the "but you can provid consulting services" argument is not valid, it dont work that way in the real world.
Re:3D graphics cards aren't relevant (Score:3, Insightful)
'pricey' (Score:5, Insightful)
I bet the type of people that buy this are like big time architects that have a few machines set up to do renders for clients, and want to perhaps do some additional effects for promo/confidence value, that likely already have people running that type of hardware.
Then again all those Quadro users could be CAD people and they've got no audience. =)
Re:the problem is in the Bus (Score:5, Insightful)
The purpose might mostly be to show people why they need to run out
and get PCI Express hardware; it completely addresses the assymetry
issue.
I'm guessing the main reason Gelato is spec'd to work on their
current AGP kit is to encourage the appearance of really impressive
benchmarks showing how much better performance is with PCI Express.
They have a good idea, and they're rolling it out at a good time,
I think.
Some folks were trying to do stuff like this with PS2 game consoles,
but I guess now they'll have more accessible toys to play with.
I think it'll start happening a lot more (Score:4, Insightful)
Free software is a product of a lifecycle (Score:4, Insightful)
"Moore's Law" is simply the application of this general law to hardware. But it applies also to software.
Free software is an expression of this cycle: at the point where the individual price paid by a group of developers to collaborate on a project falls below some amount (which is some function of a commercial license cost), they will naturally tend to produce a free version.
This is my theory, anyhow.
We can use this theory to predict where and how free software will be developed: there must be a market (i.e. enough developers who need it to also make it) and the technology required to build it must be itself very cheap (what I'd call 'zero-price').
History is full of examples of this: every large scale free software domain is backed by technologies and tools that themselves have fallen into the zero-price domain.
Thus we can ask: what technology is needed to build products like Gelato, and how close is this coming to the zero-price domain?
Incidentally, a corollary of this theory is that _all_ software domains will eventually fall into the zero-price domain.
And a second corollary is that this process can be mapped and predicted to some extent.
Re:Teh horror !!! (Score:2, Insightful)
That just saved me the trouble of clicking the link and checking it out
ps: I recently visited a project trying to "harness the power of GPU's". I think that project was something like seti/folding/ud/... but tried to have all the calculations be made by the GPU of your 3d card.
If someone knows what I'm talking about: please post it, I can't find it anymore
Not an issue, esp. for non-RT rendering (Score:5, Insightful)
For 3D rendering, especially non-realtime cinematic rendering, you have large source datasets - LOTS of geometry, huge textures, complex shaders - but a relatively small result. You also generally take long enough to render (seconds or even minutes, rather than fractions of a second) that the readback speed is not so much an issue.
Upload to the card is plenty fast enough (theoretical 2 GB/s, but achieved bandwidth is usually a lot less) to feed it the source data, if you're doing something intensive like global illumination (which will take a lot more time to render than the upload time). Readback speed (around 150 MB/s) is indeed a lot slower, but when your result is only e.g. 2048x1536x64 (FP16 OpenEXR format, 24 MB per image), you can typically read that back in 1/6 of a second. Not to say PCIe won't help, of course, in both cases.
Readback is more of an issue if you can't do a required processing stage on the GPU, and you have to retrieve the partially-complete image from the GPU, work on it, then send it back for more GPU processing etc, but with fairly generalised 32 bit float processing, you can usually get away with just using a different algorithm, even if it's less efficient, and keep it on the card.
Another issue might be running out of onboard RAM, but in most cases you can just dump source data instead & upload it again later.
Little value... (Score:3, Insightful)
Renderman is proven technology and has been so since the early '90s. Renderman is well known, its results are predictable and it is a fast renderer. Also, current production pipelines are optimised for Renderman.
UNIX and Linux are quite good when it comes to distributed environments (can anyone say Render Farm?) and handle large file sizes well (Think a 2k by 2k image file, large RIB files).
And last but not least, renderman is available with a source code license.
Hardware accelerated film rendering is in essence nothing but processor operations, some memory to hold objects and some I/O stuff to get the source files and output the film images. Please explain to me why a dedicated rendering device from NVidia would be any better than your average UNIX or Linux machine? Correct, there aren't any advantages, only disadvantages. (More expensive, proprietary hardware, unproven etc.)
Re:Teh horror !!! (Score:1, Insightful)
math coprocssor (Score:3, Insightful)
Does this mean that I could eventually use my GeForce to do things like matrix inversion for me?
Re:the problem is in the Bus (Score:2, Insightful)
Only the second generation PCI Express cards from nVidia will be native solutions and will use the bridge the other way arround (to usa a PCI Express chip inside an AGP system).
Linus gave Linux away, Nvidia benefitted. (Score:3, Insightful)
So why should Nvidia benefit from Linux, without some reciprical giving ? Hardware programming specs would be enough of a gift.
Re:Fab for machinima (Score:3, Insightful)
The opening quote of the article poster is ignorant. Movie rendering has been done in hardware forever. He seems to be mixing up doing rendering in hardware with rendering on the fly in a video card.
What we have here is a slight mix of the two, but by no means anything new on the market. Its only letting you use your quadro if you already have one for movie rendering acceleration. I certainly would not buy one for this purpose. I imagine its still incredibly more profitable to use a CPU than GPU. Also, note that render farms computers rarely have video cards. The video part would be wasted.
But for in-game recording by home users and non-studio $$$ having artist, this will likely be a welcome addition. (Especially for those who can turn a GeForce into a Quadro) Though I have to wonder, doesen't the Quadro cost quite a bit of money!?
Still think its nice technology. I wonder if PCI-Express is allowing them to get this data off the GPU and back into the hands of the CPU?
Re:I think it'll start happening a lot more (Score:4, Insightful)
How do you know ISV's are getting annoyed? Do you go to lunch with ISV's every other day?
No, but working for a medium-sized ISV who deals with Microsoft (we buy bulk embedded XP licenses for use in custom gaming machines), I can tell you a few things about how Microsoft deals with customers. They have actually tried to offer us better deals if we discontinued our Linux solutions and marginalized our dealings with our Russian partners who produce hardware and software for use with Mandrake Linux 9.x in gaming solutions. (Sounds impossible? Think again). I can only imagine how much more underhanded Microsoft are when dealing with bigger ISVs.
Not only are you crudely generalizing, I think your point is actually not sound at all. You think Adobe cares about Microsoft dominating?
I'm sure Netscape and Sun didn't care either, until Microsoft took them out of the market. You are really insulting the intelligence of the Adobe executives if you think that they haven't considered this possibility or what they could do to avoid something similar happening.
Re:I like this... (Score:3, Insightful)
Physics APIs- Direct KinetiX and Open/mgh (Score:2, Insightful)
Sounds like an old (Lucasfilm?) Siggraph paper. (Score:3, Insightful)
That sounds like an old Siggraph presentation I saw a decade or two ago when I used to go to Siggraph. Lucasfilm, I think. (The fine sample picture in the article showed a motion-blured image of a set of pool balls in motion.)
When rendering an image using raytracing, there are several effects that are achieved by similar over-rendering processes. I.e. you ray-trace several times varying a paramter:
- Depth-of-field (use different points on the iris of the "camera", blurring things at different distances from the "focal plane".)
- Diffuse shadows (use different points on the diffuse light source(s) when computing the illumination of a point.)
- Motion blur (use different positions for the objects and "camera", evenly {or randomly} distributed along their paths during the "exposure" - ideally pick the positions of the whole set of objects by picking several intermediate times, rather than picking the postion of each object separately, to avoid artifacts of improper position combinations.)
- Anti-aliased edges. (Pick different points in the pixel when computing whether you hit or missed the object or which color patch of its texture you hit.)
As I recall there were about five effects that worked similarly, but I don't recall the other(s?) just now.
To do any one of them requires rendering the frame N times {for some N} with the parameter varied, then averaging the frames. (Eight times might be typical.) Naively, to do them all would require N**5 renderings - 32,768 raytracings of the frame to do all five.
The insight was to realize that the effects could be computed SIMULTANEOUSLY. Pseudorandomly pick one of the N from each effect's set for each frame and only render N frames, rather than N**5. Eight is a LOT smaller than 32K. B-)
Sounds like Nvidia ported this hack to the firmware for their accellerator.
Re:3D graphics cards aren't relevant (Score:3, Insightful)
Besides, you don't need killer bus bandwidth with this because you're not trying to pump out 100fps using a couple of hundred megs of geometry and textures on a card with only a hundred or so megs of memory. (That means you have to send loads of data over the bus 100 times each second.)
The power here is in the parallelisation and incredible performance delivered by highly-specialised processors. Graphics cards have phenomenal memory bandwidth - nVidia's latest has something like 32GB/sec (big B!) - compare that to say a Dual 2GHz PowerMac G5, which has 6.4GB/sec of memory bandwidth. New graphics chips are heading towards the usage of memory paging (3D Labs P10 already does this I believe) So with this and high-end cards with 256 or 512MB of RAM you won't need much bus bandwidth because you'll just page in little bits of geometry and textures as each processor needs it, rather than having to upload huge textures everytime an entire one gets trashed to make room for another one.
So once again, the key thing to remember is that you're not trying to push 100fps. Most of the time spent rendering a frame will be in the GPU shader units, not uploading data to the graphics chip.