Hi guys,<br><br>I'm sorry i haven't been able to provide any views on this as Ton asked me to do,<br>i'm currently integrating luxrender at digital graphics on a film project,<br>and doing our v0.6 release at the same time.<br>
<br>I hope to be able to provide some details on the views about the API from the lux/pbrt community in 1-2 weeks,<br>in the mean time, i'm very happy with starting from a quasi renderman like/compatible point of view, yet generalized.<br>
It's pretty easy to hook up any renderer to a quasi renderman inspired API imo. (at least for geometry)<br><br>Regarding all the GPU stuff, i agree with yves, this does not apply to the render api at all at the moment.<br>
<br>Radiance <br><br><div class="gmail_quote">On Thu, Apr 2, 2009 at 3:52 AM, Yves Poissant <span dir="ltr"><<a href="mailto:ypoissant2@videotron.ca">ypoissant2@videotron.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
From: <<a href="mailto:echelon@infomail.upr.edu.cu">echelon@infomail.upr.edu.cu</a>><br>
Sent: Tuesday, March 31, 2009 1:17 PM<br>
<br>
> ....About the CUDA topic in the render API, while GPGPU´s and stream<br>
> computing are a must in every graphics pippeline currenty is not well<br>
> standarized, NVIDIA have CUDA that due to smart movements from that<br>
> company have gained a big user base, but ATI also have its choice with<br>
> Ati Stream basec on Brook+ , and if Intel enters with Larrabee is<br>
> probably that they will make their movement... so that field is<br>
> currently like a swamp, each GPGPU company trying to get the biggest<br>
> piece of the cake<br>
><br>
> The best option seems to be OpenCL, that currently is only paperware....<br>
><br>
> So there´s two options:<br>
> 1- several devs take care of the NVIDIA side (CUDA), the ATI side<br>
> (Stream) and so on<br>
> 2- wait for a hardware independent implementation like OpenCL<br>
<br>
Or 3- Don't wait for any of those but start designing for parallelism.<br>
<br>
I have the feeling there is a rush to choose a GPU programming paradigm<br>
before even considering designing the API. We are already reading<br>
discussions of CUDA, Brook, OpenCL and Larrabee but I have still to read any<br>
discussion about what a Render API should look like, what are the needs and<br>
requirements?<br>
<br>
Discussing any particular GPU programming paradigm is broadly premature and<br>
IMO will always be, because those paradigms will evolve. We are just<br>
beginning to see those paradigms coming out. The hardware industry is just<br>
starting to truely explore the possibilities of parallel and streaming<br>
architectures We are very far from the end of this exploration. Even if we<br>
were to choose the best one for today, there is a huge probability that this<br>
will be outdated in just a few years if not a few months.<br>
<br>
Designing software for parallelism is very different than designing software<br>
for serial processing. One cannot expect to use the full potential of<br>
parallel architecture by just recompiling the source with the new<br>
vectorizing compiler. That is the old way of thinking: That we would get<br>
better performance by just swaping for a faster CPU. No more of that. The<br>
design itself must be approached with parallelism in mind making abstraction<br>
of any particular architecture of paradigm.<br>
<br>
Why don't we just get back to the true discussion? That is :<br>
- What is a render API?<br>
- What would be a good render API for Blender?<br>
- What would be a good render API for Lux and others?<br>
- What do we know about the current interface/exporters/API to external<br>
renderer that we would like to improve?<br>
- What is currently lacking?<br>
- What kind of communication between Blender and the renderer do we need?<br>
- How tight or how loose do we need this communnication to be?<br>
- Can we identify and categorize which king of information can be loosely<br>
coupled and which ones need to be tightly coupled?<br>
- Can the information be decoupled and exchanged in parallel chunks?<br>
- How can this chunking be done?<br>
- What sort of information, structures, interaction, UI must be<br>
echanged/shared from Blender to the renderer and from the renderer to<br>
Blender?<br>
- Do we need the renderer to be able to expose UI widgets in Blender (for<br>
example to describe materials and lights)?<br>
- How is the data and properties persistence handled?<br>
- Do we need Blender to store, save and load, to/from blend files, the<br>
renderer particular properties?<br>
- Do we need Blender to store, save and load, to/from blend files, the<br>
renderer's particular requirements for material and light properties?<br>
- What should be the formalism for that?<br>
<br>
etc. etc. etc.<br>
<br>
All of those questions don't even require that a particular parallelism or<br>
streaming model be selected. If there is one thing that is certain, it is<br>
that we will have to think parallelism for the years to come no matter the<br>
marketing gizmos each company will come up with. The design phase should be<br>
thought with parallelism in mind but making abstraction of which platform<br>
this parallelism will be implemented in.<br>
<br>
Yves<br>
<br>
PS: For those interested in Larrabee, Dr Dobb's just published an very<br>
intersting and insiightfull article about this upcoming CPU/GPU at<br>
<a href="http://www.ddj.com/hpc-high-performance-computing/216402188" target="_blank">http://www.ddj.com/hpc-high-performance-computing/216402188</a><br>
And Intel have released a Larrabee C++ Prototype Library at<br>
<a href="http://software.intel.com/en-us/articles/prototype-primitives-guide/" target="_blank">http://software.intel.com/en-us/articles/prototype-primitives-guide/</a><br>
<br>
While those are interesting reads, I still strongly believe it would be a<br>
big mistake to base a design on any specific architecture.<br>
<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</blockquote></div><br>