Blender Git Commits

Fix incorrect volume stack for shadow rays

Cycles X: more complete support for volumes

Brings back volume rendering support to what it was before on the GPU. That
means scattering, emissions and heterogeneous volumes with stepping. However
no decoupled or equiangular sampling yet.

Rather than separate homogeneous and heterogeneous code paths, there is only
heterogeneous now. This ensure shader evaluation is only compiled once. Some
optimizations may be possible for the homogeneous case, but that can be looked
at later.

Includes multiple commits, these are split in P2216. We can discuss how
best to review this next week.

Differential Revision: https://developer.blender.org/D11709

Fix various issues in shadow handling of volumes

Properly compute volume shading for all segments before, between and after
surface hits.

Fix Cycles X interop on non-OpenGL device

Graphics interop for non-display GPU got broken with the CUDA streams
addition.

Now we create interop object via the queue, so its possible to use
proper CUDA stream for mapping/unmapping.

Not sure why adding extra context synchronization did not resolve the
issue, but this change seems to make sense anyway.

Here its only reproducible with non-display GPU (for which it was
needed to tweak `should_use_graphics_interop()`). But some time ago
there reports about missing image in the viewport, so could be related.

Differential Revision: https://developer.blender.org/D11705

Refactor: Move Cycles X CUDA interop class to own file

No functional changes.
Isolates logic, makes it easier to adopt for coming changes.

Fix Cycles X backing on GPU

A mistake was made in the init_from_bake kernel which was wrongly
scheduling next kernel: it was considering that flow comes from
the intersect_closest kernel. This made active kernel counters go
wrong: sum was adding up to 0, but the intersect_closest kernel
had negative value.

Merge branch 'master' into cycles-x

Enable built-in OptiX curves by default

Starting with OptiX 7.3 curves now behave as expected with Cycles and render the same as the
custom intersection implementation, so enable by default.

Fix Cycles X compaction fails with memory issues on Titan V

This card seems to report more threads available than half of the
maximum available states, which breaks offset logic in the path
compaction.

Fix possible "run-away" error state in Cycles X

If the path tracing kernel encountered an error, it could cause wrong
code paths to trigger in the GPU implementation of the display update.

For example, an error state in the path trace should not mate the display
update to attempt to roll-back from interop update to naive one.

Fix display half-float allocation in Cycles X

The comment and check was stating that allocation will happen for the
final resolution, while the actual allocation was using the currently
effective resolution.

Should fix random memory access issues for the viewport render.

Merge branch 'master' into cycles-x

Merge branch 'master' into cycles-x

Cycles X: Initial support for the constant time rendering

Allows to limit render time, so that rendering will either happen
until all samples are finished, or the given time limit is reached.

Currently is only implemented for background and headless renders,
as those seems to benefit the most. In the viewport would still
like to investigate idea of keeping rendering until desired noise
floor is reached before adding extra settings there.

The usecases for the non-interactive (background, headless) renders
includes:

- Rendering a shot previews for movies.
- Ensuring some "bogus" frames do not stall the render farm.
- Allows to implement benchmark which will work reliable for both
very powerful and weak hardware configurations (as an example,
top-end GPUs and mobile GPUs) without requiring to wait forever
on a non-powerful hardware.

One of the tricky parts which is not solved in this version yet is
support of constant time rendering with multiple big tiles. However,
support of big tiles will be an addition on top of the existing code
as some sort of time limit would need to be enforced for every tile
(in other words, support of constant time render for multiple tiles
will be implemented on a higher level).

Differential Revision: https://developer.blender.org/D11526

Cycles X: Re-arrange sampling panel

More explicit separate viewport from render settings. Makes it easier
and more clear to add settings which are only for preview or only for
the final render.

| Before | After |
| {F10177700} | {F10177701} |

Among other thngs removed unused CYCLES_RENDER_PT_sampling_total.
Think better would be to call draw_samples_info for both viewport
and render samples.

Differential Revision: https://developer.blender.org/D11633

Fix Cycles X shadow catcher artifacts

Were caused by matte object appearing in the division process.

This change makes it so the matte object is removed from the
combined pass before division, which solves artifacts caused
by anti-aliasing (the matte "bleeds" into the shadow catcher
and produces artifacts around the rim).

Additionally made certain parts more explicit and better
documented.

Test file: {F10177353}

| Before | After |
| {F10177355} | {F10177358} |

Differential Revision: https://developer.blender.org/D11632

Fix build with older OptiX SDK

Cycles X: Implement OptiX denoising of shadow catcher passes

Pretty much follows similar change in the OIDN.

The information about whether denoiser should use fake albedo for a
specific pass is stored in its PassInfo.

It is probably possible to improve performance of the filter_convert_to_rgb
kernel (avoid per-pixel fake albedo check, avoid scaling normal for every
denoising input pass, ...). Not sure it will bring measurable performance
so leaving it for the future development and investigation.

Differential Revision: https://developer.blender.org/D11614

Cycles X: Use pass accessor in the OptiX denoiser

No functional changes, just converging pass accessor to a commonly
used utility.

There is still custom kernel used, which ensures that pixel values
are within expected range.

Cycles X: Use RenderBuffer in the denoise task API

No functional changes, but gives possibility to use PassAccessor to get
pixels of the input noisy pass.