Support for nVidia K20 cards

I have been working this morning with one of our testers (Marco Podrini) who owns a K20 card, making sure that Arion supports K20s properly, and trying some different strategies to maximize performance in this new architecture (sm_35) released by nVidia.

For those of you feeling curious as to how well a K20 performs compared to other high end GeForce cards of previous Fermi/Kepler generations, here’s an example ran with Arion v2.4.0, with the devices infotag on. The render’s exposure has been deliberately lowered so the numbers are easily readable.

As you can see, the K20 outputs 261 passes in the same time that one of the 580 cards outputs 163. That is, the K20 is about 50% faster than each of the 580s, and nearly 60% faster than each of the 680s. On a side note, the 580s are about 10% faster than the 680s.

We have run many tests in many different scenes and this one is representative of the average. In some scenes the K20 was performing better (even approaching a 2x speed gain, compared to the 580s).

Note that GPU technology adapts better (or worse) to different mathematical problems depending on their nature. Arion is a path/ray tracer, and these results should probably be representative of the speed gain that you could expect from a K20 in ray-tracing applications in general. In other scientific fields, and also in theoretical performance comparisons, the numbers may vary.

Object-based Region-Render

The next version of Arion features a very innovative and extremely useful feature that allows you to constrain the render to a certain object. It has in common with classic Render Region that it wastes little or no computational resources for the pixels that are left out of the selection, but instead of working on a fixed user-defined area, it auto-detects what pixels must be rendered.

This feature can be a total killer in those situations where you need to do multiple variations of the same render.

Below you can see an example where this feature has been used to re-render one of the furniture elements in a kitchen image. The scene/project belongs to Studio Podrini.

This may look familiar to many of you, as this is the kind of thing that our old product SWAP was designed to do.

These renders were made compositing the following elements:

1- The base image, which uses a neutral material for the piece of furniture that changes.
2- An ObjID channel, where everything is black, but the object mask, set to full white.
3- Multiple Object-based Region-Render layers, with different materials.

Each Object-based RR layer renders very quickly (about 20 times faster than the full image in this particular example). These layers look like this one here:

Note how clean the AA is in the final composite, despite everything was rendered at 1:1 without any downsampling or special editing.

This feature works with animations as well, which can be really handy for certain compositing operations. For example, you could composite a change in a character in an animation without re-rendering everything all over again.

Arion v2.4.0

Since a few days ago, we are working on the release of the next version of Arion and MAX LIVE.

We are keeping some really -big- announcements up our sleeves that we will announce here in the upcoming days, as we approach the release date.

We have reviewed everything that will be featured in the next version of Arion/LIVE and have decided to rename v2.0.4 to v2.4.0, since all the features and improvements that we have packed into this next version account for a big portion of the roadmap that we plotted months ago for v2.x.

The most important v2.4.0 features that we have announced so far are:

– Better than 2x speed/noise improvement.
– An entirely new Metropolis Light Transport (MLT) sampler.
– Support for RGB8/16 and raw HDR output.
– Ability to export all the render channels in a multi-layered OpenEXR (.exr) file.
– Support for CUDA 5.

+ Some stuff you will hear about soon. }:)

Noise comparison (v2.0.4 vs. v2.0.3)

As mentioned in a previous post, Arion has experienced a serious performance increase in the past weeks.

With the better noise convergence ratio in v2.0.4 (announced here) and the 2x raw performance boost (more samples are shot per second) we announced the last week, your images will render significantly cleaner in less time. Our tests evidence that the combined speed gain is actually higher than 2x.

Noise comparison between v2.0.3 and v2.0.4:

Scene and render courtesy of Studio Podrini

NOTE: Do not pay attention to the fps/pass counters in the above images. As mentioned in a previous post, the meaning of those counters has changed in v2.0.4 so the actual numbers cannot be compared. Just pay attention to the difference in noise, and the fact that both images were rendered in the same machine, for 90 seconds each.

EDIT: Some people have pointed out that the second image is a bit brighter than the one to the left. The tonemapping was slightly pumped up in the second render. Arion’s output has not changed a single bit regardless of the speed and noise improvements. Also, note that these massive speed improvements have nothing to do with the MLT sampler that we announced weeks ago (that is a separate and entirely new feature to help in complicated light situations).