Indigo Renderer 4.0.44 Beta Release

General News and accouncements regarding the Indigo render engine
User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Indigo Renderer 4.0.44 Beta Release

Post by OnoSendai » Wed Aug 31, 2016 4:04 am

This is a Beta release.
If you spot any bugs or problems, please make a post about them in this thread.
Thanks!

Indigo for Windows 32-bit:
IndigoRenderer_4.0.44_Setup.exe

Indigo for Windows 64-bit:
IndigoRenderer_x64_4.0.44_Setup.exe

Indigo for Linux 64-bit:
IndigoRenderer_x64_v4.0.44.tar.gz

Indigo for Mac OS X (10.7 - ):
IndigoRenderer4.0.44.dmg


Indigo RT for Windows 32-bit:
IndigoRT_4.0.44_Setup.exe

Indigo RT for Windows 64-bit:
IndigoRT_x64_4.0.44_Setup.exe

Indigo RT for Linux 64-bit:
IndigoRT_x64_v4.0.44.tar.gz

Indigo RT for Mac OS X (10.7 - ):
IndigoRT4.0.44.dmg

Changelog:
4.0.44
* Improved dark theme. Added new dark icons for dark theme.
* Improved default/grey theme a bit on Mac.
* Added initial implementation of render queue override settings.
* Added UI for them in render queue settings panel.
* OpenGL preview is only initialised when visible.
* Greatly increased the speed of the scene node list on scenes with lots of nodes.
* Sped up scene parsing somewhat.
* Moved reset layout menu item from Tools to Window menu.
* Fixed rendering issues with negative RGB values.
* Improved some XML parsing error messages in a few places.
* GPU PT: Fixed invisible-to-camera support, was creating artifacts.
* Added log display widget to network manager, improved error messages.
* Fixed issue where setting the halt time on multiple render queue items would update the halt spp for all of them, and vice-versa.
* Made it that you can edit the output path for multiple render queue items at once.
You can use '%frame', which will be replaced with the frame index.
* Added back some output to render log when image saving is initiated.
* Not clearing render log in UI when new scene is loaded. Makes it a bit easier to see what's going on in queue renderings.
Attachments
overrides2.PNG

STUDIO AARON
Posts: 24
Joined: Wed Aug 13, 2014 12:39 pm
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by STUDIO AARON » Wed Aug 31, 2016 7:57 am

Nice,

The queue overrides will definitely be useful.
And I like the changes to the dark theme, as well.

Having the same bug with the rx 480 using opencl, renders seem to run fine but, indigo continuously uses more ram when running. Hitting the pause button stops the ram increase but upon pressing play, indigo continues to use more system memory.
AMD might release a future driver that takes care of the issue,
and I am going to file an error report over there but I'm not sure what to point them at..

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by OnoSendai » Wed Aug 31, 2016 8:01 am

STUDIO AARON wrote: Having the same bug with the rx 480 using opencl, renders seem to run fine but, indigo continuously uses more ram when running. Hitting the pause button stops the ram increase but upon pressing play, indigo continues to use more system memory.
AMD might release a future driver that takes care of the issue,
and I am going to file an error report over there but I'm not sure what to point them at..
Does this occur on all scenes, or just a few?

STUDIO AARON
Posts: 24
Joined: Wed Aug 13, 2014 12:39 pm
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by STUDIO AARON » Wed Aug 31, 2016 10:23 am

It happens on all scenes.


I found another bug with network rendering from the gui(win64), the slaves do not seem to be connecting.
Nothing happens after "Master Discovery Listener started." in the log.
Everything works great with indigo_console.exe

TonyD
Posts: 49
Joined: Sat Aug 20, 2016 2:24 pm

Re: Indigo Renderer 4.0.44 Beta Release

Post by TonyD » Wed Aug 31, 2016 11:47 am

Hello!
Great, I tried out the Override settings and it worked, a very nifty tool indeed :D

In my case I ran a sequence and checked both boxes for OpenCL, and I was wondering what the one on the left and right meant. Do you have to check each box, do they each represent/do something different?

One idea would be to have EV Adjust and ISO overrides in that menu also (maybe sliders, or a checkbox to match current scene...). That would be really useful if you could tweak, in Indigo, the Tonemapping lighting for the whole .igq sequence.

Thanks!
-Tony D.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by OnoSendai » Wed Aug 31, 2016 11:57 am

TonyD wrote:Hello!

In my case I ran a sequence and checked both boxes for OpenCL, and I was wondering what the one on the left and right meant. Do you have to check each box, do they each represent/do something different?
The checkbox on the right enables/disabled GPU acceleration.
The checkbox on the left overrides the usual settings. So the override only has an effect if the checkbox on the left is checked.

User avatar
Originalplan®
Posts: 757
Joined: Sat Sep 26, 2015 8:58 pm
3D Software: Cinema 4D
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by Originalplan® » Thu Sep 01, 2016 8:35 pm

I'm not online for a day a we have a new UI going :D

Nice work on the new dark mode!! Icons are good too.
All in all using OpenCL to render on both GPU's Indigo feels much more responsive!
(You can now easy zoom in and out from the current render)
Love this release.


TonyD
Posts: 49
Joined: Sat Aug 20, 2016 2:24 pm

Re: Indigo Renderer 4.0.44 Beta Release

Post by TonyD » Fri Sep 02, 2016 7:23 am

Hello!

Figured I'd take time to write further on experiences with the render engine.
This is not a complaint or fix-request, and I recognize build is in progress.
Just identifying where opportunities for further optimization exist.

A) Here is a current list of issues I found on some scenes that occur OpenCL but, don't occur non-OpenCL:

1) "CL_INVALID_BINARY" error - same scene will load fine on non-OpenCL but crash with the error on OpenCL
2) Blocky Pixelation on a character hair and/or eyelashes - will render fine non-OpenCL, but show on OpenCL
3) Missing Non-mesh Emitter Lights - an application-specific non-mesh light source will render fine against other reflective objects when non-OpenCL, but it will not be visible, as if 'off', when rendered on OpenCL

Perhaps the underlying application may not be communicating optimally to Indigo, on the other had, the fact that the render will in fact work when non-OpenCL makes it appear these are OpenCL build issues.

B) OpenCL Speed of building and closing out Kernels:

I had noted earlier that the current build in my experience had a diminishing, and even negative, return when using more than 4 GPUs with actual rendering speed, and had found linear render speed was achievable up to the point of 4 GPU. However this was with 4 Titan Z connected to my mobo at PCI 1x.

Experimenting further, I set up a 2nd Titan X on my mobo directly at 16x PCI 3.0 connection to see how it would compare vs 1Titan X for rendering a series of animation frames (500 samples). What I found was that the render speed was almost doubled linearly. Yet what happens then is the kernel build time and close out time is greater as well, and winds up offsetting the speed gain. It also takes Indigo a few seconds to rev up to the GPUs to full render speed, and with thios all, sometimes the 2-Titan X per-frame render times were even greater by a good 10 seconds from start to finish. Those seconds difference vs 1 card makes a big difference over thousands of frames to the point where it's almost optimal to render on 1 card. I know a bunch of variables are at work here, however in general, an improvement in Kernel build time would be as, if not more valuable, than an optimized linear render improvement.

Like, if a single .igs would open and close out with a 2-3 second snap, no matter how many GPU, that would be incredible to work with, and would really make the ability to have multi-gpu that much more. In saying so I do understand, that for a single 5,000 sample render, for example, it doesn't pay to have a quicker load-in and close out time, rather here pure render speed matters most. But in having a bias for animation at lower sample counts, the kernel time will be a big consideration.

PS - I am a multi-GPU enthusiast so OpenCL is very promising here!

Thanks for the hard work, looks and feels awesome...you guys rock!
-Tony D.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Indigo Renderer 4.0.44 Beta Release

Post by OnoSendai » Sat Sep 03, 2016 2:00 am

Thanks for the excellent feedback TonyD.

Regarding the CL_INVALID_BINARY error, can you send us a packed indigo scene (PIGS file) that produces the error?

Regarding kernel building, there is a slightly different approach we can take that will hopefully build multiple kernels at the same time.

User avatar
bubs
2nd Place Winner
Posts: 620
Joined: Fri Jul 22, 2011 8:46 pm
Location: UK

Re: Indigo Renderer 4.0.44 Beta Release

Post by bubs » Sat Sep 03, 2016 5:15 am

Thanks to the joys of a new computer I have finally managed to have a bit of a play with Indigo 4.
It seems to me that the 'Update Image' button doesn't actually update the image when using GPU rendering... you have to wait for the 'next update' countdown to complete. My issue with this is that I set a short render time of 3mins to try out animation frames, the image updated at 90secs but the next countdown was then in a further 3mins or something. Because my scene render time finished before this my image never updated from how it was at 90sec, so was the last 90secs of rendering lost?

Apologies if this is old news...

User avatar
Oscar J
1st Place Winner
Posts: 2204
Joined: Sat Mar 31, 2012 3:47 am
Location: Gothenburg, Sweden
3D Software: Blender

Re: Indigo Renderer 4.0.44 Beta Release

Post by Oscar J » Sat Sep 03, 2016 6:19 am

bubs wrote:Thanks to the joys of a new computer I have finally managed to have a bit of a play with Indigo 4.
It seems to me that the 'Update Image' button doesn't actually update the image when using GPU rendering... you have to wait for the 'next update' countdown to complete. My issue with this is that I set a short render time of 3mins to try out animation frames, the image updated at 90secs but the next countdown was then in a further 3mins or something. Because my scene render time finished before this my image never updated from how it was at 90sec, so was the last 90secs of rendering lost?

Apologies if this is old news...
Congrats on the new machine, what GPU? :)

This is how the GPU rendering works. Thing is, it renders in tiles internally, and instead of displaying unfinished passes, Indigo only updates after completing each pass. Hopefully the devs will make the cycles shorter. :) In the meantime, try using a fixed halt spp that Indigo updates on.

User avatar
bubs
2nd Place Winner
Posts: 620
Joined: Fri Jul 22, 2011 8:46 pm
Location: UK

Re: Indigo Renderer 4.0.44 Beta Release

Post by bubs » Sat Sep 03, 2016 7:05 am

Ah right! Good to know, me and my complete the lack of technical knowledge! My new machine has a gtx 1070... the difference from my crappy old i5 with no gpu worth talking of is mind blowing! I'm seeing increases of x20 speed in some cases!

User avatar
Oscar J
1st Place Winner
Posts: 2204
Joined: Sat Mar 31, 2012 3:47 am
Location: Gothenburg, Sweden
3D Software: Blender

Re: Indigo Renderer 4.0.44 Beta Release

Post by Oscar J » Sat Sep 03, 2016 7:06 am

bubs wrote:My new machine has a gtx 1070...
Give me... :D

Asticles
Posts: 9
Joined: Sat Sep 03, 2016 9:34 pm

Re: Indigo Renderer 4.0.44 Beta Release

Post by Asticles » Sat Sep 03, 2016 10:33 pm

Hi all,

I've make an account because I'm considering to buy indigort to work with blender and amd cards but I've seen some issues:

Indigo:

I'm testing indigo with my two RX480, and seems that having the opengl window opened crashes the program when rendering with opencl, but also crashes when exiting indigo after render with the cards.
I've sent a dump.

I'm testing the memory leakage because some days ago I had the same problem. I've updated drivers but the leak seems to continue(on gpu mem). Also, it does not seem to work with my two cards (indigorender).

IndigoRT:

It does not have the opengl problem, nor the leakage (on gpu mem), but maybe is too small that I cannot see it on gpuz.

When I hit pause the GPU load still is at 100%, hitting close button makes the program not to respond and hangs the computer.

Regards

Post Reply
31 posts

Who is online

Users browsing this forum: Yandex [Bot] and 29 guests