Additional requirement is to have OpenImageDenoiser, and the devices
should not support OIDN denoiser.
Reproduced here in the studio with a system on Linux with either double
Quadro GP100 cards, and Limnux with Quadro 6000 + Quadro 6000 ADA.
The reason for the crash is that the find_best_device() might return
nullptr, and it was never checked.
Pull Request: https://projects.blender.org/blender/blender/pulls/122823
Currently, during baking each pixel stores a seed input that comes from the
Blender side. This is only needed for vertex color baking, however -
for regular image baking, we can just as well hash the pixel coordinates.
Therefore, we can save some memory (4 byte per pixel) by splitting the seed
info out into a separate pass and only storing it when needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122806
Previously, Cycles would render up to 4SPP during viewport navigation when
using reduced resolution, even when the overall number of samples was set
lower.
This causes problems with the blue-noise pattern, so ensure that the
number of samples is always clamped to the configured maximum.
This is a proper fix for the issue worked around in 11d311e300.
Previously, an incorrect condition adjustment of the device info
was done for a preferred device. Now, this change reverts that
condition, and the adjustment is done correctly and unconditionally.
This patch implements blue-noise dithered sampling as described by Nathan Vegdahl (https://psychopath.io/post/2022_07_24_owen_scrambling_based_dithered_blue_noise_sampling), which in turn is based on "Screen-Space Blue-Noise Diffusion of Monte Carlo Sampling Error via Hierarchical Ordering of Pixels"(https://repository.kaust.edu.sa/items/1269ae24-2596-400b-a839-e54486033a93).
The basic idea is simple: Instead of generating independent sequences for each pixel by scrambling them, we use a single sequence for the entire image, with each pixel getting one chunk of the samples. The ordering across pixels is determined by hierarchical scrambling of the pixel's position along a space-filling curve, which ends up being pretty much the same operation as already used for the underlying sequence.
This results in a more high-frequency noise distribution, which appears smoother despite not being less noisy overall.
The main limitation at the moment is that the improvement is only clear if the full sample amount is used per pixel, so interactive preview rendering and adaptive sampling will not receive the benefit. One exception to this is that when using the new "Automatic" setting, the first sample in interactive rendering will also be blue-noise-distributed.
The sampling mode option is now exposed in the UI, with the three options being Blue Noise (the new mode), Classic (the previous Tabulated Sobol method) and the new default, Automatic (blue noise, with the additional property of ensuring the first sample is also blue-noise-distributed in interactive rendering). When debug mode is enabled, additional options appear, such as Sobol-Burley.
Note that the scrambling distance option is not compatible with the blue-noise pattern.
Pull Request: https://projects.blender.org/blender/blender/pulls/118479
On a M3 MacBook Pro, this change increases the benchmark score by 8% (with classroom seeing a path-tracing speedup of 15%).
The integrator state is currently store using struct-of-arrays, with one array per field. Such fine grained separation can result in poor GPU cache utilisation in cases where multiple fields of the same parent struct are accessed together. This PR changes the layout of the `ray`, `isect`, `subsurface`, and `shadow_ray` structs so that the data is interleaved (per parent struct) instead of separate. To try and keep this change localised, I encapsulated the layout change by extending the integrator state access macros, however maybe we want to do this more explicitly? (e.g. by updating every bit of code that accesses these parts of the state). Feedback welcome.
Pull Request: https://projects.blender.org/blender/blender/pulls/122015
This is an oversight of #122543, for which benchmarking was done in
the headless mode.
The solution is to tweak policy a little bit, and keep refresh intervals
low for the first 10 seconds of render, after which increase updates to
every 15 seconds. Doing so allows:
- Have quick cancel of complex files when the error is noticed during
the first few samples.
- Have more predictable cancel time after long render.
- Mitigate the performance regression.
This does not fully solve the regression, but it makes it much more
manageable. There are some compromises to be done from the performance
for the UI renders. The interactivity is also not as fantastic, but it
could be solved later by introducing some "Instant Cancel" operations
which would be able to also stop render in the middle of a sample.
Performance measured with the Spring file (path tracing time in seconds):
Samples: 300 1024 2048
Base (prior to #122543): 29.1 85.4 174.1
This patch: 37.0 95.7 180.2
This is measured on M2 Ultra GPU render.
The penalty is close to a constant time (the time within which a more
interactive cancel is possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122658
A regression since #118841.
It is possible that the selected preference device is not found, in which
case a default-initialized DeviceInfo would have added to the list. This
device is set to CPU, but with differnet other fields (such as description)
compared to the actual CPU device.
Pull Request: https://projects.blender.org/blender/blender/pulls/122701
This fixes#69535 and #98930.
We use a equi-solid-angle sampling algorithm for rectangular area lights,
but it is not particularly robust for small area lights (either small
in general and/or small because it's being viewed from grazing angles).
The actual sampling part is fine since it just gets clamped into the
valid area anyways, and the difference isn't notable for small lights.
However, we also need to compute the solid angle to get the sampling PDF,
and that computation is quite sensitive to numerical issues for small
values.
Therefore, this commit adds a fallback path for small values, which instead
uses the classic equi-area sampling PDF term times the area-to-solid-angle
Jacobian term. This approximation assumes that all points on the light have
the same distance and angle to the sampling point, which is of course not
strictly the case, but it's close enough for small area lights and better
than failing altogether.
Pull Request: https://projects.blender.org/blender/blender/pulls/122323
Reformulates some terms in the equi-solid-angle rectangle sampling code to
handle small area lamps better, and allows for some rounding error in the
check whether the sampled position is inside the area light.
Pull Request: https://projects.blender.org/blender/blender/pulls/122323
In the original paper, the falloff inside `bcone.theta_e` is assumed to
be `pi/2`, which is too large for spot light and resulted in an
overestimation near the cone boundary.
To address this issue, attenuate the energy of a spot light using the
minimal possible angle formed by the light axis and the shading point
when traversing the light tree.
Ref: #122362
Pull Request: https://projects.blender.org/blender/blender/pulls/122667
Previously, GPU denoisers were ignoring settings about render
configuration and were using any available GPU. With these changes,
GPU denoisers will use the device selected in Blender Cycles
settings.
This allows any GPU denoiser to be used with CPU rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/118841
In some of the complex scenes it could a very long time for Cycles
to respond to cancel request. This is because Cycles only cancels
render at a consistent state of render buffer: when all scheduled
samples are rendered.
This was caused by the render scheduler over-scheduling the number
of samples in an attempt to improve occupancy of the GPU.
This fix makes it so the scheduler only compensates for the low
occupancy if rendering can happen within a desired update time.
There is no visible difference in the benchmark scenes with this
change.
Pull Request: https://projects.blender.org/blender/blender/pulls/122543
Happens when opening a file saved file with preview paused.
This fix covers the typical use-case when the property is modified
from the space it comes from.
Pull Request: https://projects.blender.org/blender/blender/pulls/122502
ZES_ENABLE_SYSMAN is supposed to be set for free_memory queries to be
available.
These queries are then optionally used since
759bb6c768, for the host memory fallback
feature.
Setting SYCL_ENABLE_PCI was leading ZES_ENABLE_SYSMAN to be set by DPCPP
2022-12 but it's not used by newer versions of DPCPP.
We however temporarily disable SYSMAN by default on Linux as builds with
JEMALLOC enabled currently lead to driver runtime issues. These can be
worked around by using LD_PRELOAD=libigsc.so.
Vulkan layers should not be controlled from application, but
should be enabled via `vkconfig`. There are configurations
in the layers that are mutual exclusive and hard to maintain from
within an application.
An example is that currently we are not able to use renderdoc efficient,
because there is an validation error triggered from within renderdoc.
This PR removes all vulkan layer configuration from Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/122473
Since the previous fix to properly support volumes and transparent objects
it became very easy to make it so the intersection loop takes all 1024
iterations to find intersections.
This change makes it so the number of intersection is limited by the max
number of volume/transparent bounces.
This should minimize possible performance impact of the previous fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/122448
We can't do the optimization to shorten the ray when we might still need
to go through transparent surfaces or volumes to reach the light.
This issue was not light tree specific, however in the test file it was
more noticable because the light tree poorly handles some areas. This in
in turn causes MIS weights for forward path tracing to become higher,
which is where the error was.
Pull Request: https://projects.blender.org/blender/blender/pulls/122404
This enables scenes with all textures not fitting in GPU
memory to finally render. For scenes that are fitting,
no functional change or performance change is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122385
One of the properties of Perlin noise is that it always evaluates to 0.0
when not normalized (or 0.5 when normalized) when the input consists of
only whole integers in all vector components.
Blender's Perlin noise implementation uses single precision floats with
a machine epsilon of 1.19e-07 meaning that for numbers that are greater
than 1/(1.19e-07) = 8.40e6 there mantissa doesn't have any bits left to
store a rational part of the number, effectively meaning that any number
greater than 8.40e6 is a whole integer as far as Blender is concerned.
Therefore when evaluating Perlin noise for any coordinates greater than
that it always results in 0.0 (or 0.5 when normalized).
This fix works as follows: If the original input number is larger than
1.0e6 it is offset by 0.5 after it underwent modulo, which always outputs
numbers in a [0.0, 1.0e5) range leaving the mantissa room for a rational
part. This way the quantization error still persists however the outputs
are random again instead of a constant 0.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/122112
When VK_EXT_maintenance4 extension is used at device creation its
extension should also be part of the device extension list.
This wasn't the case and would trigger UB in the validation layers.
Pull Request: https://projects.blender.org/blender/blender/pulls/122208
