[Bf-funboard] GPU accelerated rendering
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:
>>>Hey this would be amazing!!!
>>>>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
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...
More information about the Bf-funboard