(upbeat music)
- Hello, my name is Frederic Servant.
I'm a Software Development Manager for Arnold at Autodesk,
and I'm here to discuss the collaboration we've had
with Intel to optimize Arnold on CPU.
So, here's the outline of this presentation.
I'll start with a brief introduction of what Arnold is
and what it does.
And then, we'll discuss the optimizations
and the implementation of the Intel® Open Image Denoise
in Arnold.
So, what is Arnold?
Arnold is a production renderer
that's been designed to handle complexity
in production scenarios.
So, that's why it scales well for large scenes.
It's able to address a variety
of complex rendering challenges,
such as effects, carter,
and also Arnold ships with Comprehensive C++
and Python API.
We have both CPU
and GPU rendering available
with similar results also to note
that Arnold ships with Maya and 3ds Max out of the box,
but it's also integrated in 3rd party DCCs
such as Houdini, Cinema 4D, or Katana.
So, Arnold is used in feature films for VFX,
but also episodic content.
It’s used in game cinematics,
feature animation, music videos,
and extensively used in commercials.
Recently, because of the acquisition of Arnold
at Autodesk,
it's been used more and more
in product visualization as well.
Because of its pioneering role
in making path tracing commonplace in the industry,
Arnold was awarded an Academy Sci-Tech Award in 2017.
And now, I'll hand it over to Thiago
to discuss the technical details
of the optimization work with Intel.
And just so you know,
Thiago is the second on the left in this photo.
Over to you, Thiago.
- Thanks, Fred.
I'm Thiago Ize, Principal Software Engineer at Autodesk,
where I work on the Arnold core.
The first Intel optimization collaboration
I'd like to present is for cell noise.
Here's some examples of the different kinds
of cell noise patterns Arnold can generate.
These cell noise patterns are often applied
in a straightforward way to, for instance,
produce bumpy materials.
But they can also be used in clever ways,
such as to simulate the caustics
at the bottom of a pool.
Here, the cell noise is used to procedurally drive
the displacement.
And because cell noise can vary over time,
it can be used to produce abstract and fanciful animations.
Cell noise is a widely used and powerful shader.
Unfortunately, it is also an expensive shader
and can dramatically slow down renders.
This was brought to our attention when Cinesite
reported to us an Arnold log
for particularly slow 20-hour per frame render.
Remember, a film is usually 24 frames per second.
So, even a short shot can contain hundreds of frames,
making these 20-hour renders important candidates
for optimization.
Because Arnold has it built-in and always running profiler,
log files will contain detailed information
about where the time was spent.
Here's an excerpt of that log
showing what the Arnold profiler determined
to be the most expensive components.
In this case,
we see that it bunch of cell noise shaders
were, in total, consuming half the render time.
The actual ray tracing component,
which is already highly optimized,
is just 20% of the total time.
So, optimizing that is unlikely to significantly help.
Even if dedicated ray tracing hardware existed
that was infinitely fast,
we still wouldn't be able
to save more than four out of the 20 hours.
The best option here is to make cell noise faster.
Working with Intel to identify the cell noise bottlenecks
and optimize that code using various techniques,
we were able to make cell noise
up to two and a half times faster.
In our previous example from Cinesite,
this likely would have saved that shot six hours
of render time per frame.
The next topic of our collaboration with Intel
is how they helped us optimize our Toon shader.
Toon shading allows Arnold
to do non-photorealistic rendering.
For instance, it can automatically draw the feature lines
of an object and generate stylized highlights,
which are similar in style to hand-drawn animations.
It can also add hatching.
Toon has many artistic uses,
but a driving motivator was to support
our Japanese customers’ anime style renders.
The Toon shader's popular,
but unfortunately, it was particularly slow
and didn't scale well to many cores.
Intel was able to help identify and optimize
this important shader.
I'll let Eric from Intel explain how and what they did.
- Thanks, Thiago.
Hi, I'm Eric Niemeyer.
I'm a Software Performance Engineer
and also the technical lead
of the Autodesk Enabling Team at Intel.
Let's take a look at how we helped Arnold
optimize the Toon shader.
Optimization is often an iterative process
that we at Intel are fond of comparing to peeling an onion.
We find that optimizing one area
often reveals underlying performance issues
that also need optimization.
Then this cycle repeats until we reach our end goal
for user experience.
This occurred when working with the Arnold team
in the last year to improve the performance
of their Toon shader.
The Intel team identified that the FilterPixel function
as a hotspot using the Intel® VTune™ Profiler
running the Nova workload.
Analysis of the FilterPixel function
showed that high CPI and bad speculation
was impacting performance.
Looking deeper,
we discovered that this function was doing a comparison
with a square root operation,
when this operation was actually not needed.
We changed the code to just compare
the square of the lengths
versus the square root of the lengths,
removing an expensive instruction from the loop.
This change alone gave us a 2% improvement
at the workload level.
Next, we unrolled the inner FOR loop
and replaced it with SIMD instructions
to process four offsets at a time,
instead of one.
This change gave us an additional 9 to 10%
at the workload level.
Then, to eliminate that pesky IF statement
that was causing the bad speculation
in the inner FOR loop,
we use branchless vectorization using left-packing.
This technique gained us another 20% at the workload level.
This layered approach yielded a cumulative 2X improvement
in CPU time, spent in the FilterPixel function.
With these optimizations completed,
we focused our attention on the SampleStore::reset function,
which should become the new dominant hotspot
after the previous optimizations.
In the SampleStore::reset function,
we observed that each bucket worker
had its own sample store buffer that was allocated
and de-allocated repeatedly during rendering.
Closer inspection revealed that this was unnecessary.
The buffer could actually be reused
among the bucket workers belonging to the same thread.
This led us to change the behavior
to share the sample store buffer at the thread level
versus the bucket level
to avoid unnecessary allocations and de-allocations.
This single change improve performance 3.4X
on a 112 thread, two socket workstation
on the Nova workload.
This change also eliminated a performance in version
at thread counts greater than 56 threads
that was due to the overhead
of the unneeded memory operations.
The Arnold team later modified this change
to push the de-allocation to the end of the render,
further improving the performance up to 4X.
The final result was greatly improved user experience
through the increased utilization efficiency
of the available CPU resources.
Let's take a look and what this means to an end user.
In this video, on the left,
you see the after optimization performance,
and on the right, the before optimization performance.
You can see the user experience on the left
is far superior to that on the right.
In the end,
the total gain from these changes
was up to 4X at the workload level
and leveraged an iterative approach
using the Intel® VTune™ Profiler
to reveal larger and larger opportunities
for performance gains.
I'd like to take a moment to recognize the entire team
that contributed to this effort,
specifically, Sanket Save and Joe Olivas
for their excellent work.
Also, many thanks to Thiago and the entire Arnold team
for supporting our ongoing collaboration.
Back to you, Thiago.
- Thanks, Eric.
Path tracers like Arnold require tracing many rays
in order to get noise-free images.
Rather than render for many additional hours
until a converged image is achieved,
users prefer to stop the render earlier
while it's still slightly noisy,
instead denoise the image.
Until recently, Arnold had 2 denoisers.
Noice was a CPU-based denoiser,
targeted at final frame renders.
It has features needed for animation,
such as temporal stability
so that we don't get flickering across frames.
And individual AOVs can be denoised
and then recombined to produce the proper final frame.
These features come at a heavy computational cost
that prevent noise from being used
to denoise interactive renders.
OptiX 6’s denoiser, on the other hand,
requires an NVIDIA GPU
and while it doesn't have Noice’s features
for final frame rendering,
it is AI powered and much faster
allowing it to be used for interactive renders.
Intel’s denoiser, like Noice,
will run on CPUs.
So, all users can benefit from it,
even those using GPUs to render.
Like OptiX, it is AI powered and much faster than Noice.
This made it an attractive option for adding to Arnold.
So, how did Intel integrate their denoiser into Arnold?
Well, thankfully, Arnold already has an Imager Framework
used for post-process imaging effects,
which happens to map perfectly
to the Intel denoiser workflow.
This made it easy and quick for Intel
to add their denoiser to Arnold.
This kitchen scene is rendered without,
and then with the Intel denoiser.
Both took 90 seconds to render.
The denoising stage took less than a second,
making the denoising essentially free.
Denoising allows us to very quickly
get a good idea of what the image should look like.
For this scene, tracing just one sample per pixel
gives noticeably noisy results.
Denoising gives workably smooth results,
though, not yet as good as a converged render
with over 4,000 more samples.
As we trace more samples per pixel,
we see that the denoised version more quickly converges
to the final result.
Depending on the accuracy needed,
some users might already be content
with the 11-second denoise render,
and even more might be happy by the 43-second mark.
By this point,
the denoised images almost fully converged
and for many use cases is good enough,
while the original image still has noticeable noise.
At this point,
I cannot see any difference between the denoised image
and the fully converged image.
But the un-denoised image,
even after almost an hour,
it still has a little bit of noise left.
Because we can denoise so quickly,
we can even use it for interactive rendering.
These are real-time recordings of interactive renders.
Now, I'd like to hand this over to Roy.
- Thanks, Thiago.
I'm Roy Hill, Senior Technical Marketing Engineer
in the OEM Workstation Platform Group at Intel.
And I'm really excited to see what these guys have done.
I want to thank Erik and Fredric,
and Thiago for the work that they've done with their teams
to optimize Arnold for CPU.
One of the exciting things about optimizing for CPU
is as Thiago pointed out,
everybody has a CPU.
So, everybody benefits from these optimizations.
And you're not limited by VRAM,
so, your models and scenes can scale with system memory.
Intel has a long history of these types of collaborations,
and we have a long history of collaboration with Autodesk,
and the team that does presented to you today.
The platforms that we have to offer from Intel are amazing
and we work with our OEM partners,
including Dell, HP, and Lenovo
to deliver entry and mobile, mainstream, and expert.
All of these platforms from the mobile and entry,
which is optimized for frequency to the mainstream,
which is, is a mix of frequency
and scalability to the expert
which is all about scaling from 8 cores
to 56 cores gives you a tremendous amount of choice
when you're looking for a workstation platform.
The fact that all of this optimization has been done on CPU
is just really great.
And I'm looking forward to the next time
that we work with this team and deliver more benefit
that helps create a professional state in the zone.
Thank you.
(upbeat music)