Indigo News
Announcing IndigoMax
Announcing IndigoMax
In case you missed the announcement on our 3ds Max forum, we have a brand new 3ds Max exporter in development: IndigoMax!
Through a partnership with Jakub Jeziorski, a fully native plugin for 3ds Max using the Indigo SDK is being developed to take integration with Indigo to the next level. Early releases are available from our forum here: http://www.indigorenderer.com/forum/viewtopic.php?f=9&t=11368
Welcome on board, Jakub!
A simple and fun render with the new exporter has been made by ENSLAVER (click to enlarge):
Indigo News
Recent progress in the CUDA ecosystem
Recent progress in the CUDA ecosystem
Less than a week after my previous post about how "only OpenCL can expose massively parallel compute capabilities in a vendor-neutral way", NVIDIA open-sourced their CUDA compiler! Obviously they are intently watching this blog, and had to react to my nay-saying.
Jokes aside, this is a big move for CUDA as it allows anyone with the ability to create LLVM ASTs from their scripting language to use the PTX backend. Indigo already features a dynamically-compiled scripting language, Winter, and this technology could be extended to output optimised code for NVIDIA GPUs directly. Of course, this isn't necessarily an approach we'll use, however it illustrates the potential of having a powerful optimising compiler for many platforms behind your domain-specific language.
It will be exciting to see how this develops, as more back- and front-ends are added to the burgeoning LLVM framework.
Indigo News
Recent progress in the OpenCL ecosystem
Recent progress in the OpenCL ecosystem
Recently AMD announced an increased focus on its Accelerated Parallel Processing SDK, promising more frequent updates tied to display driver releases on all platforms; AMD Product Manager for Compute Solutions Mark Ireton wrote on their developer blog, "[...] we will also be upgrading our OpenCL solution on a more frequent basis through the regular monthly Catalyst driver updates."
NVIDIA, for their part, are continually improving their OpenCL implementation with each driver update, approaching the performance of its native CUDA language. Much as I love the lean and mean CUDA 4 API, only OpenCL can expose massively parallel compute capabilities in a vendor-neutral way (and it's nice to be able to JIT from source), so in the long term I expect OpenCL to become the de facto standard for parallel computation.
AMD and Intel already have an OpenCL SDK which supports their CPUs, and this is important since they already include (or soon will) considerable GPU-like parallel compute resources. The tight integration of these heterogeneous compute resources is quite unlike the present norm, in which discrete cards with dedicated memory are connected to the CPU by a long PCI Express trip, and this will be an interesting scenario to optimise for in the future. Intel's Many Integrated Core (MIC) architecture is another one to watch in the future: with a widened x86 architecture (easy to program) and their manufacturing process leadership, we could see a compelling compute platform.
When we started developing for GPUs, we'd have to manually write out debug info to be returned to the host; unsuccessful runs were often met with a hard reset or blue screen. This is in stark contrast to the fantastic development tools we have now, including the ability to print out debug info from kernels, and do live debugging in Visual Studio - and it almost never hangs the machine. Two thumbs up!
It's clear that a great OpenCL implementation is important for these companies, and we are very pleased with the progress that is being made.
Indigo News
Imaging pipeline improvements in Indigo 3.0.14
Imaging pipeline improvements in Indigo 3.0.14
The imaging pipeline collectively refers to the sequence of processing steps which result in the final displayed image. This consists of tone mapping, white point correction, light layer processing and the image resizing from the super-sampled source data.
Previously this would require a number of auxiliary buffers, which could use quite a lot of memory since they needed to be at the same resolution as the final and super-sampled images. However, since Indigo version 3.0.14, we've implemented a new imaging pipeline which avoids the need for these extra buffers, and is also a little faster.
When rendering high resolution images, especially ones with high super-sampling, this can save gigabytes of memory! Here are some numbers reported in our Indigo 3.0.14 announcement:
Scene by dcm (3508x2480 resolution, super-sampling factor 4):
Indigo 3.0.12: 12,1 GB used
Indigo 3.0.14: 8,7 GB used - 3.4 gigabytes saved!
Scene by Zom-B (3543x1993 resolution, super-sampling factor 3):
Indigo 3.0.12: 3.8 GB used
Indigo 3.0.14: 2.2 GB used - 1.6 gigabytes saved!
These improvements are only enabled when not using Aperture Diffraction, however work to improve the memory usage and performance of AD is ongoing!
Indigo News
Architectural interiors by dcm / Michal Timko
Architectural interiors by dcm / Michal Timko
Architectural visualisation specialist Michal Timko, also known as dcm on the forum, is known for his stylish and realistic interior shots. Here are some of his latest works with Indigo Renderer, enjoy!
Indigo News
Announcing GPU acceleration for Indigo Renderer
Announcing GPU acceleration for Indigo Renderer
Graphics processing units (GPUs) have come a long way since their inception, when they were used to accelerate basic rasterisation features in high-end CAD workstations. Through standards such as 3Dfx's Glide, and later Direct3D and OpenGL, the market for inexpensive consumer GPUs has bloomed into the success story it is today.