Blender Git Commits

Cycles: Ensure there is always a single-device

Previously enabling denoising will create a multi-device with a single
sub-device. This broke assumptions in PathTracer about the fact that we
only support single device at this point.

Fixes bad render buffers pointer passed to CUDA kernels when denoising
is enabled.

Cycles: Fix denoiser not working after recent changes

The change which introduced check of denoising parameters made it
so denoiser in PathTrace was never created: constructor was checking
denosiing parameters with self.

For now use a special function from constructor which ensures
initialization is fully done correctly.

In the coming future the synchronization and locks will be redone,
so while this is a bit annoying change it is only to unlock current
development.

Cycles: Fix threading issue between scene update and buffers reset

It was possible that scene was updated to use denoising passes prior to
delayed reset which was re-allocating render buffers. Was unlikely, but
still possible: this is because update_scene() was only guarded by the
scene mutex, and buffers reset was not using scene mutex.

Repro was "simple": erratically toggle "Use viewport denoising" while
viewport was rendering.

This change makes it so buffers and scene are always in the consistent
state. It also moves some logic outside of the run() functions, making
it possible to re-use it for both run_cpu() and run_gpu().

Currently the change is limited to run_cpu(), so that it is easier to
verify logic before using it in all codepaths.

Cycles: Remove device->task_wait from Session::run_cpu()

Should be no functional changes.

The reason for this is because rendering tasks are handled by the
PathTrace class and the session is not directly interacting with
the device.

Cycles: Fix parameters modification blocking UI

If any Cycles property which triggers re-synchronization is modified
during viewport rendering the interface could have been blocked until
the current sample is finished.

This was caused by the following factors:

- run_cpu acquires a buffer lock for rendering
- set_denoising also acquires lock, avoiding denoising to be triggered
while settings are modified.

This was not noticeable during run_cpu() rendering with old integrator
because the render buffer was not locked during entire duration of
sample rendering (despite the claim in the comment in the code). So what
was happening instead is that the render buffer was only locked during
scheduling on the path tracing tasks. Waiting for the tasks to be
complete was done outside of the buffers lock.

This was avoiding interface lock, but could have caused other threading
issues (those issues are outside of the scope of this change).

On the run_gpu() rendering it was possible to have interface locked for
no reason if sample takes noticeable amount of time.

This change makes it so there is no render buffer locked acquired
during synchronization unless denoiser settings did actually change.
This is still sub-optimal, but makes interaction more pleasant.

Cycles: Initial support of noisy image pass

Is rather quick implementation, which should be enough to have
proper progressive render+denoise in viewport.

Not super happy with the code duplication, and the transparency
I am not sure how to support. But maybe this is acceptable for
the development purposes.

Cycles: Comment out a lot of logic in TileManager

The actual tricky tiling logic is done in the PathTraceWork and the
TileManager is mainly tracking state of the current resolution and
sample. In the future it can also be used to keep track of big tiles
but the logic will be way more simple.

Fix debug asserts and checks in work schedulers

The work size can be the same as the maximum number of path states, as
they are both sizes (not indices in 0-based arrays).

Cycles: add back light intersection for multiple importance sampling

* Intersect closest kernel now intersects with point, spot and area lights
in addition to scene geometry. This could later be optimized by adding
lights to the BVH.
* If such a light is hit, the new shade_light kernel will be executed
which will evaluate the light shader and write to the render buffer,
then continue with intersect_closest.
* The shade_background kernel handles intersection and shader evaluation
for distant lights.

Cycles: Support denoiser in the new integrator

Implemented as own classes which provide higher level API for rendering
pipeline. Currently placed in the integrator folder, which feels a bit
strange, but is easy to move these files around.

The idea is the following:

- Have every implementation to implement Denoiser interface, which
goes away from previous implementation on a device level. This allows
to more naturally consider Device a way to invoke kernels, without
business logic.

- Currently Denoiser operates on an entire RenderBuffer. In the future
this would need to be changed to operate on a list of render buffers
to support denoising of renders done on multi-device. Seems to be
"just" a straightforward extension of the currently implemented
simple API.

Currently Session is requesting denoising as a dedicated call of
PathTrace. This is something I am not really sure about: in a way this
feels wrong and Session can/should have direct access to denoiser. But
on another hand, having denoising done in the PathTracer allows to have
a more centralized and comprehensive logic around decision of how many
samples to render before update, when to start denoising and things
like this.

From actual implementation is only OpenImageDenoise with color buffer
is implemented. The rest would need a support from kernel.

Cycles: Rename Denoiser to DenoiserPipeline

The goal is to have clarity on entity names.

The proposed/desired convention:

- Device: low-level "glue" logic, which takes care of running
functions on a particular device. Algorithm implementation
does not belong to device.

- Denoiser: breaks down specific denoising algorithm into a
function calls which happens on a device. It does not belong
to the device because denoising can happen regardless of where
noisy image came from: could be file, could be single render
buffer, could be multiple render buffers rendered by multiple
devices.

- DenoiserPipeline: takes care of performing all steps needed to
denoise a sequence of frames.

In an ideal world DenoiserPipeline will implement a frame accessor
of some sort, and use Denoiser to perform actual denoising on a
configured device/denoising algorithm.

This change only modifies the class name, making room for implementing
an actual denoising algorithms as dedicated entities. Further cleanup
in naming and structure is needed. It will be revisited once the
cross-frame denoising will be worked on as an official core
functionality.

Cycles: move integrator specific logic out of device queue

The CUDA integrator queue was mostly CUDA independent and highly coupled to
PathTraceWorkTiled. Seems better to move the tiled integrator logic into a
single class, and keep the queue implementations simple to implement for each
device type.

The particular motivation for this change was scheduling of most queued
kernels, which was getting even more complicated.

Cycles: add path regeneration for new GPU integrator

Fix broken CUDA render after accidentally removed load_kernels

Cycles: change queue work tile handling

* Use single method to both pass work tiles and launch init kernel
* Support passing multiple tiles
* Schedule multiple tiles on the GPU if there is enough space

Cycles: deduplicate DeviceKernel enums

Cycles: greedily execute GPU integrator kernel with most queued items

Fix Cycles GPU viewport border rendering

Cycles: keep track of effectively used part of GPU path state array

To avoid launching unnecessary work.

Cycles: Remove unused sample argument

It is taken care of in the path tracer, which should be very well aware
of how many samples were rendered into the render buffer.