Indigo Renderer Forum

Now we are happy congratulating with Glare for the Indigo 4.0 beta release I was searching for other places where to disperse the good news.

I was instead captured reading the announcement made from the market leader in GPU rendering, Otoy

https://home.otoy.com/octanerender-3-an ... ap-update/

From the slide 32-33 of the presentation and this forum thread

https://render.otoy.com/forum/viewtopic.php?f=9&t=53089

appear Otoy does create a cross platform release of CUDA, that will work since the next 3.1 release (2017) on CPU, FPGA, AMD GPU.

Reading the slides and forum posts, and the push for the new render as a service and cloud render, appear to me:

- Otoy and Nvidia are trying to preserve CUDA dominance, enabling transparent working of CUDA code on non-Nvidia hardware
- The first declared goal it's NOT non-Nvidia GPU (aka AMD) but CPU and other hardware. In fact non-Nvidia GPU is nominated at the end of every statement, or not nominated at all
- Enabling the remote usage of a GPU (no GPU PC) they did push current Apple users to adopt eGPU solutions trough TB port...possibly using Nvidia hw, or just rely on cloud services.
- forum direct questions about OpenCL support are not answered, or answered in such a way where is not clear the future direction
- with all this smoke about OpenCL support (first officially announced 1 year ago, and only now discovered to be something different) Otoy is in fact putting pressure on who does wait one year on his Apple or AMD hw, to discover he might need to upgrade to something different.
- If this statement was made 1 year ago someone might decided to switch to another renderer (aka Indigo) that officially state his future support for OpenCL, and did maintain his statements

This got me some questions

1) this is wrong reasoning? I did read something in the wrong way?
2) AFIAK CUDA it's not only a driver implementation but also proprietary hw on Nvidia GPU. So this kind of open source CUDA will be possibly an emulation, not a native translation? Meaning performances on non-Nvidia GPU will be lower?
3) The Winter framework used in Indigo 4.0 it's something similar to the Otoy new layer, decoupling or substituting in some part OpenCL?
4) Considering OpenCL appear to be not taking off in a short time (i.e. no Apple baking, with crippled OpenCL drivers, maybe pushing for his own GPU hw in the future), this will enable Glare to have the same flexibly as Otoy in term of future platform adoption?
5) Winter does add some overhead over OpenCL or does in fact speed the whole thing?

Apologize for the long post, my work (apart messing with rendering sw for unpaid work) is business design, and I'm respecting so much this outliers community of talented specialists.

Hey davide445 interesting thread.
I can't answer all of your questions...but i can offer my opinion.

1) No you are on the right track.

2) It depends maybe Cuda can work natively but it's a trumendous work to get it done. And in the end im sure it will be more like an emulation. (lot's of technical stuff here from smarter people than me)

3) Not sure ask ONO

4) Apple is pushing for its own GPU chips but its likely still years away. Not using the latest OpenCL drivers has its reason too. (system stability etc). OpenCL has taken off but its mainly used for scientific paralell compute simulations.

this will enable Glare to have the same flexibly as Otoy in term of future platform adoption?

I think so yes.

5) Ask ONO

IMO You have to always keep in mind that maybe Otoy is the business leader in GPU rendering (for now).
But their success is heavily grounded in CUDA and people having CUDA capable NVIDIA cards.
Another way to put it they losing money if you don't have an Nvidia card.
As for the cloud rendering stuff i'm really not a fan of that modell...maybe larger company's will use it instead of a render farm. But for individuals i don't think its the future.

I for myself vote Indigo...on OSX there simply IS no better.

After a bit more digging things are starting to clarify about all the market movements around CUDA/OpenCL. With all info nicely summed up in this article

http://www.anandtech.com/show/9792/amd- ... r-amd-gpus

- AMD prepared a CUDA-->C++ translator (named HIP), and from C++ you can compile to any architecture
- AMD is also extending HSA to add C++ as dev language for GPU coding, in some way departing from OpenCL
- Kronos group in latest OpenCL 2.1 specification allow the usage of a subset of C++, but considering only the upcoming AMD Polaris GPU are supporting it this is a limiting factor.

So in fact we can look at Otoy/Glare Tech activities in the bigger picture: a path to overcome both OpenCL/CUDA limitations and allow cross platform coding of their specific products (in the case of Glare I understood the target will be always OpenCL).

davide445 wrote:(in the case of Glare I understood the target will be always OpenCL).

Ask Ono !

Like CTZn said. Ask ONO
Im not sure what to tell you.
But what im sure of is that Indigo is going in the right direction both technically & quality wise.
And it will be so in the future ( i hope ).

OnoSendai wrote:Winter can output OpenCL code. We don't support CUDA because we don't need to - OpenCL runs on Nvidia GPUs.

I remembered well: already asked to Ono (about the fact Indigo - Winter tool in fact - target platform will be OpenCL or also CUDA), that was his response.

Hi,

I just want to clarify a little bit on the "what is CUDA" side. First of all it mainly an extension to C (later C++) that allows to start data parallel functions on (an asynchronous) compute device and manage it's memory hierarchy.

To do this, Nvidia provides tools (the CUDA toolkit) to split the code into CPU/GPU parts, compile the CPU part with Visual C++ (Windows) or gcc (Linux), compile the GPU part with its own compiler into some intermediate format (some form of assembly for a virtuals massive parallel machine) and then compile it to the native instruction sets of the various Nvidia GPUs.

It's quite easy to abstact the basic CUDA stuff away and run the same C/C++ code on Nvidia GPUs via CUDA and on x86_64 CPUs (for example using OpenMP or TBB to do the data parallel part on multicore or even use some auto-parallelisation with SIMD).

So I don't think that Otoy did something revolutionary to get Octane running on CPU. Even open source projects like Cycles got it done years before.

Surely it gets more complicated with code that uses some fancy GPU features that don't map 1:1 on CPU. Stuff like texture units, shared memory, warp votes, some atomics, synch barriers, etc.

Or if you heavily used (often closed source) CUDA support libs.

Also the devil is always in the details and numerical accuracy and performance behaviour can be quite different on CPU/GPU.

It is easier if you evolve the renderer at the same time on CPU and GPU instead of porting it later in one or the other direction.

GlossyCaustics: interesting post, thanks for clarifying.

And welcome to the forum

GlossyCaustics are you a GPU rendering dev? (I almost don't need to ask based on your username, same with why don't you like photon mapping.) Your answers are right on the money

Also welcome to the forums

GlossyCaustics wrote:
....

It's quite easy to abstact the basic CUDA stuff away and run the same C/C++ code on Nvidia GPUs via CUDA and on x86_64 CPUs (for example using OpenMP or TBB to do the data parallel part on multicore or even use some auto-parallelisation with SIMD).

So I don't think that Otoy did something revolutionary to get Octane running on CPU. Even open source projects like Cycles got it done years before.
......

Was interesting to me the opportunity to make work the CUDA code on a different GPU brand, being AMD the obvious target but also Intel since in a couple of generations can be pretty interesting in term of performances.
Do you think Otoy or AMD projects will make it possible with the same performances as in Nvidia hw?

One fundamental difference between AMD and NVIDIA GPUs is the number of threads executed together, it's 32 for NVIDIA and 64 for AMD.

When developing exclusively for one thread group size, as you would do with CUDA, you end up making optimisations and code decisions based on this parameter over time. If you have never tried setting this "magic number" from 32 to 64 or vice versa, and built tons of code on top of this assumption, it very likely won't work without some major refactoring and fixes, probably taking some performance with it.

This is why it's difficult to make apples to apples comparisons with CUDA and OpenCL renderers: CUDA renderers would lose a bit of their speed trying to suddenly work on other GPUs, and OpenCL renderers without GPU-specific optimisations are fighting a more fair fight

Clear explanation. We can say CUDA is abstract enough to not depend from a specific hw (just to make an example I suppose on the contrary PhysX is hw dependent and cannot ported without using an hw emulation).
What is ticking my brain is the fact in all the Otoy communication the first declared target is CPU and outlier hardware (I suppose Xeon Phi or FPGA). Odd choice considering the primary goal of a GPU renderer is...fast rendering.
At least Indigo effort was clear in one direction: OpenCL open all kind of possibilities, as far the vendor does support it in their drivers.