[Bf-committers] Render API follow-up

[Yves Poissant]

From: Terrence Vergauwen
Sent: Friday, March 20, 2009 5:58 AM

> We have already done quite a bit of proactive research
> since a few years into CUDA and equiv technologies,
> and unfortunately it's not an architecture capable of
> running a practical raytracer.

More and more people are finding techniques to coax CUDA into doing 
raytracing including implementing BIH or Kd-Trees acceleration structures on 
CUDA. I believe it is important to keep following those efforts and learn 
the techniques.

That said, I agree that today version of CUDA have too many constraints to 
implement a true practical (read production) raytracer. Beside, choosing 
CUDA seems risky to me since this is a proprietary API. I would favor OpenCL 
which is much more general as it is not targetted only to GPU but also to 
multicore CPUs. But although nVidia, AMD and Intel have all announced that 
they would provide OpenCL support and drivers for their next generation 
GPUs, OpenCL is currently only at the stage of paperware for now.

Beside, using technologies such as CUDA or OpenCL is really truely 
meaningfull on the rendering side of the API. To me, though, the suggestion 
to use CUDA in the discussion about the API is better translated into a 
suggestion to think the next API in term of  multi-core environment, 
distributed rendering, cloud computing. I'm not sure how this would affect 
the API but it is good to keep the multi-threading on the backburner while 
designing the API. There are many things a renderer must do to render a 
scene. A lot of that can be processed in parrallel even at the data 
gathering and preparation stage. So an API designed to serve different 
aspect of data gathering, data preparation and rendering simultaneously and 
in parallel should be thought of during the API design.

Yves