[Bf-funboard] GPU accelerated rendering

Konrad Haenel public at konrad-haenel.de
Wed Oct 20 04:20:06 CEST 2004


Robert Wenzlaff wrote:

>On Tuesday 19 October 2004 06:49, Bart wrote:
>  
>
>>Here is another interesting thing about GPU rendering:
>>
>>Nvidia Gelato
>>http://film.nvidia.com/page/gelato.html
>>
>>Bart wrote:
>>    
>>
>>>Hey this would be amazing!!!
>>>
>>>car wrote:
>>>      
>>>
>>>>Oh wow that is some nice stuff for the render times  ... One can only
>>>>hope that others here will try and do that with the GPU...
>>>>        
>>>>
>
>The problems I see with GPU assisted rendering, is the fact that no standard 
>has shaken out of the industry yet.    If you are a pro-house using custom 
>tools, you can specify "All computers for this movie will have BrandX ModelY 
>graphics cards" (Note who nVidia is targeting with the Gelato link...  
>"Gelato offers all the features that film and television customers demand 
>today, and is both flexible and extensible allowing for easy integration into 
>your existing production pipeline"...) .   
>
>For GPU assisted disply/editing we have such a standard, OpenGL (and even that 
>causes us fits sometimes).    For a general purpose app that must strive to 
>support all decent GPU's, there are basically two paths to go by:
>
>1) Wait for a standard to settle out.  It could be a while, each GPU 
>manufacturer wants to lock customers into their cards.  There's little 
>advantage to standardizing (for them) as long as they have a chance to reach 
>the top. (Note how Gelato ships with an API, not an input/output format.  
>I'll bet that when/if ATI ships a similar product, their API will be 
>incompatible with nVidia's.  Whose API do we hardcode in?)
>
>2) Make a standard interface to Blender's rendering engine that can take 
>"plug-in libraries" that convert what they can to a specific GPU API and 
>returns the render data in the form Blender expects.   This means that anyone 
>wanting GPU assisted rendering for CardX would need to write, or find someone 
>to write the infterface for their card.  If a standard does shake out, then 
>that plug-in lib will be the "official" one.  A lot of this work is already 
>being done to support external renderers.  
>
>I'll bet a renderman compliant interface to the GPU will be something that 
>most manufacturers will ship, or will become available through 3rd party 
>efforts (Gelato has one, and it's even free and Open Source!), so it may take 
>care of itself once the Blenderman project is up and running.  Instead of 
>dividing the developer community on GPU specific tasks, let's leverage GPU 
>assisted rendering to the advantage of an existing, general use, project.   
>On-the-fly RIB import/export gives us Gelato _and so much more_.... 
>
>The point is, yes, it's a cool idea.  Running blindly to chase every cool idea 
>via the quickest/dirtiest method is not a cool idea.  There's a lot of cool 
>ideas out there that have ended up as dead-ends. (Hey, let's start a 
>Blender.org project that will let us save our output to Betamax!) 
>  
>
My knowledge of OpenGL is a little too limited to know an answer to this 
question:

Is it possible to save definite frames of OpenGL-output to files?

If it is, and I would be surprised if it isn't, I think all of the above 
doesn't apply. In case we can use a highly standartized API it won't 
matter what brand of GPU is used to render the output. That's what APIs 
are for, isn't it?

Anyway, even if certain manufacturer-specific criteria have to be met it 
basically comes down to ATI and nVIDIA. It's safe to assume that there 
won't be any more major players in the 3D-card field in the forseeable 
future. No kidding, if someone can assure me that he will deliver a 
GPU-renderer with the features I proposed in my original mail within the 
next 3 months I'll buy and send him a Radeon 9600 XT just to make it happen.

And a third point: like in any open-source project the paradigm applies 
here as well: "publish soon, publish often". Once a GPU-renderer is 
available in a usable fashion it will be a project creating lots of 
interest, even if it isn't the best possible solution. I highly doubt 
that this is something that might lead to a "dead end", the comparison 
to the Betamax-project is way out of place here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-funboard/attachments/20041020/e5f00f1f/attachment-0001.html


More information about the Bf-funboard mailing list