Indigo Renderer Forum

No need to buy an nVidia card just for Indigo, we will have OpenCL support :) Of course it remains to be seen which mode is better, OpenCL and CUDA, right now it is too early to tell; but we definitely don't want to leave anyone out!

Benn or ono.. do you know if you could provide us with some benchmarks from gpu acceleration?

pixie wrote:

Zom-B wrote:

Pibuz wrote:..indeed, only "indigo" mat preview doesn't work properly: all the others render just fine..

the indigo_console.exe (used for preview renderings mostly) is here a special cuda build... just as the error message says.

I simply replaced the indigo_console.exe by the last stable build 2.2 exe....
duplicating indigo.exe and renaming to indigo_console.exe should work fine too ;-)

Other solution would be to buy a nvidia card =p

I HAVE an nVidia card!
..maybe I need to install the CUDA software..

But I guessed I couldn't use GPU support 'cos it's not ready yet!

Zom-B wrote:I had a issue in 2.2.12 for my renderslave where the networkclient started in indigo.exe doesn't get killed after closing, but stays in taskmanager crunching 1 core to death.

Now with 2.4.2 this is getting even heavier!

Closing my network client, it stays in taskmanager and grabs for 2 cores to burn them and also eats RAM each second like a pro:

O_o.jpg

Hi Zom-B,
I can't replicate this personally. I've made a few changes to the termination of network connections, so please try again with the upcoming 2.4.4 and let me know if it's still an issue, thanks.

OnoSendai wrote:Hi Zom-B,
I can't replicate this personally. I've made a few changes to the termination of network connections, so please try again with the upcoming 2.4.4 and let me know if it's still an issue, thanks.

Yes, I'll test it when 2.4.4 is out, thanks for taking a look into it!

OnoSendai wrote:I can't replicate this personally. I've made a few changes to the termination of network connections, so please try again with the upcoming 2.4.4 and let me know if it's still an issue, thanks.

Hey Ono, I forgot to mention:

This issue apears only with indigo.exe! The indigo_console.exe is free of this problem.
I also updated all possible drivers and the bios of my machine, and the issue is still always reproducible.
Ram usage raises by 44MB a second btw!


**EDIT**
Ok guys, I also found out that on my main master machine starting the Indigo Renderer Network Slave and closing it it also stays in the task manager, but only burning 1 Core and without eating up RAM!

lycium wrote:No need to buy an nVidia card just for Indigo, we will have OpenCL support :) Of course it remains to be seen which mode is better, OpenCL and CUDA, right now it is too early to tell; but we definitely don't want to leave anyone out!

Hi, I am new here.
I am choosing an unbiased rendering program to learn.The images in Indigo gallery look great.The free learning version is very nice too. The opportunity to be able to accelerate rendering just by adding new GPU to my modest PC looks great!
My only question is that I don’t understand why Indigo needs to have CUDA and not just OpenCL support. VrayRT was on CUDA, and then it was just on CPU and it is ported to OpenCL now.
If I understand it right, OpenCL is an open standard that allows hybrid CPU/GPU or any other heterogeneous stuff renderer ,as opposite to just GPU renderer.
In my humble opinion, there will be accelerators other than GPU out there as well as multicore CPUs with OpenCL support (I’ve read Intel’s article about it). I don’t think that Larrabee and Cell processor were really totally cancelled. Intel and IBM are probably just working on the software side of the problem, and we can have them back any time.
Here is an answer to question about OpenCL support in Intel’s forums on April 23, 2010:
“We are scheduled for a presentation on openCL in the next few weeks. We'll see if it gives any information we can mention.”
http://software.intel.com/en-us/forums/ ... hp?t=72505
Or what do you think about something like this for Cell processor (or Larrabee):
Sieve C++ for OpenCL compiler from Codeplay:
http://www.codeplay.com/en/products/sie ... e-c-opencl
If I understand it correctly the only problem here is current OpenCL limitations.
Sorry if I am out of base here.

Gene.

We're currently focusing on OpenCL support.

lycium wrote:We're currently focusing on OpenCL support.

Cool!

I just want to correct myself. Speaking of OpenCl support, according to this article I’ve just found:
“OpenCL: democracy for GPU computing?”
http://www.behardware.com/articles/744- ... uting.html

“OpenCL…is a common language for any architecture. It hasn’t only been designed for GPUs but is also adapted to CPUs and accelerators such as Cell. Does this mean that you can now develop a code that’s compatible with any architecture? This is where it gets more complicated. In fact, the work group in charge of OpenCL, which includes among others, Apple, AMD, Intel, NVIDIA and Sony, decided to go for a support of all the specificities of each architecture rather than easing porting…”
…and “the more the code is optimized the less the portability”, even for different GPUs.

So, I guess, OpenCl for things like Cell processor or Larrabee must be different version than for GPU, and code written for GPU acceleration wouldn’t work on them anyway, would it?
Sorry if my English is incorrect.

Kernels written for OpenCL should indeed work on all supported platforms.

Also, I don't think we're quite ready to give up on CUDA support, but we're definitely going to try to push OpenCL since it is vendor agnostic.

Well, I am definitely not buying any new hardware any time soon! All this is very confusing.

The CPU will still be very important for achieving good speed, so your investment in a good quad-core (or better!) will definitely be a good one.

lycium wrote:The CPU will still be very important for achieving good speed, so your investment in a good quad-core (or better!) will definitely be a good one.

Even if it's CUDA support?

Our GPU support will be hybrid in any case. It will use the CPU and the GPU. The GPU is going to do the ray intersections and the CPU the material calculations, tonemapping, etc.

It does not hurt to have a fast CPU