Sometime throughout development some checks got lost during refactor.
This change makes it so that if OIDN is not supported on the current
CPU Cycles will report an error and stop rendering. This behavior is
similar to when an OptiX denoiser is requested and there is no OptiX
compatible device available.
The easiest way to verify this change is to force return false from
the `openimagedenoise_supported()`.
Fixes Cycles part of the T94127.
Differential Revision: https://developer.blender.org/D13944
The root of the issue is caused by Cycles ignoring OpenGL limitation on
the maximum resolution of textures: Cycles was allocating texture of the
final render resolution. It was exceeding limitation on certain GPUs and
driver.
The idea is simple: use multiple textures for the display, each of which
will fit into OpenGL limitations.
There is some code which allows the display driver to know when to start
the new tile. Also added some code to allow force graphics interop to be
re-created. The latter one ended up not used in the final version of the
patch, but it might be helpful for other drivers implementation.
The tile size is limited to 8K now as it is the safest size for textures
on many GPUs and OpenGL drivers.
This is an updated fix with a workaround for freezing with the NVIDIA
driver on Linux.
Differential Revision: https://developer.blender.org/D13385
Sample offset was not accounted for in the adaptive sampling code and caused
issues, like immediately applied adaptive filtering, with non-zero values.
Differential Revision: https://developer.blender.org/D13510
Adds hysteresis to the resolution divider algorithm to avoid having the resolution bounce around when on the boundary of two resolutions.
Reviewed By: brecht, leesonw
Differential Revision: https://developer.blender.org/D12385
This reverts commit 5e37f70307.
It is leading to freezing of the entire desktop for a few seconds when stopping
3D viewport rendering on my Linux / NVIDIA system.
The root of the issue is caused by Cycles ignoring OpenGL limitation on
the maximum resolution of textures: Cycles was allocating texture of the
final render resolution. It was exceeding limitation on certain GPUs and
driver.
The idea is simple: use multiple textures for the display, each of which
will fit into OpenGL limitations.
There is some code which allows the display driver to know when to start
the new tile. Also added some code to allow force graphics interop to be
re-created. The latter one ended up not used in the final version of the
patch, but it might be helpful for other drivers implementation.
The tile size is limited to 8K now as it is the safest size for textures
on many GPUs and OpenGL drivers.
Differential Revision: https://developer.blender.org/D13385
This patch adds new arg-type parameters to `DeviceQueue::enqueue` and its overrides. This is in preparation for the Metal backend which needs this information for correct argument encoding.
Ref T92212
Reviewed By: brecht
Maniphest Tasks: T92212
Differential Revision: https://developer.blender.org/D13357
Noticed when was looking into T93155. Steps to reproduce:
- Open the .blend file from the report
- Hit F12 to start rendering
- After some tiles were rendered hit Esc
The issue is caused by "sticky" cancel reported via Progress. This means
that once user hit Esc all further requests for cancel state will return
truth, which was preventing OIDN denoiser from completing the denoising
task.
Now only allow stopping the denoiser when interactive rendering requests
a very fast stopping.
Aiming the fix for 3.0 branch.
Differential Revision: https://developer.blender.org/D13352
With the current code in master, scrambling distance is enabled on non-hardware accelerated ray tracing devices see a measurable performance decrease when compared scrambling distance on vs off. From testing, this performance decrease comes from the large tile sizes scheduled in `tile.cpp`.
This patch attempts to address the performance decrease by using different algorithms to calculate the tile size for devices with hardware accelerated ray traversal and devices without. Large tile sizes for hardware accelerated devices and small tile sizes for others.
Most of this code is based on proposals from @brecht and @leesonw
Reviewed By: brecht, leesonw
Differential Revision: https://developer.blender.org/D13042
The calculation based on preserving device occupancy was conflicting
with the fact that time limit needs to render less samples at the last
round of render work.
For example, rendering BMW27 for 30sec on i9-11900k was actually
rendering for almost a minute. Now the render time limit is respected
much more close.
Differential Revision: https://developer.blender.org/D13269
Adds a method to profiler that can be used to check if it is active.
This is used to determine if stop_profiling and start_profiling
should be called.
| patch | Juans Scene UI 256 samples | Juans Scene bg 256 samples | junkshop UI | junkshop bg |
| No patch | 6:16.59 | 4:05.37 | 2:08.48 | 1:59.7 |
| D13187 | 4:12.15 | 3:57.36 | 2:07.25 | 1:58.16 |
| D13185 | 4.11.18 |3:54.74 | 2:07.44 | 1:58.03 |
| D13190 | 4:12.39 | 3:55.42 | 2:07.62 | 1:58.68 |
UI - means rendered from within Blender
bg - means rendered from the command line using ##blender -b scene.blend -f 1##
Reviewed By: sergey, brecht
Maniphest Tasks: T92601
Differential Revision: https://developer.blender.org/D13190
Adds a method to profiler that can be used to check if it is active.
This is used to determine if stop_profiling and start_profiling
should be called.
| patch | Juans Scene UI 256 samples | Juans Scene bg 256 samples | junkshop UI | junkshop bg |
| No patch | 6:16.59 | 4:05.37 | 2:08.48 | 1:59.7 |
| D13187 | 4:12.15 | 3:57.36 | 2:07.25 | 1:58.16 |
| D13185 | 4.11.18 |3:54.74 | 2:07.44 | 1:58.03 |
| D13190 | 4:12.39 | 3:55.42 | 2:07.62 | 1:58.68 |
UI - means rendered from within Blender
bg - means rendered from the command line using ##blender -b scene.blend -f 1##
Reviewed By: sergey, brecht
Maniphest Tasks: T92601
Differential Revision: https://developer.blender.org/D13190
The issue was caused by splitting happening twice.
Fixed by checking for split flag which is assigned to the both states
during split.
The tricky part was to write catcher data at the moment of split: the
transparency and shadow catcher sample count is to be accumulated at
that point. Now it is happening in the `intersect_closest` kernel.
The downside is that render buffer is to be passed to the kernel, but
the benefit is that extra split bounce check is not needed now.
Had to move the passes write to shadow catcher header, since include
of `film/passes.h` causes all the fun of requirement to have BSDF
data structures available.
Differential Revision: https://developer.blender.org/D13177
This patch exposes the sampling offset option to Blender. It is located in the "Sampling > Advanced" panel.
For example, this can be useful to parallelize rendering and distribute different chunks of samples for each computer to render.
---
I also had to add this option to `RenderWork` and `RenderScheduler` classes so that the sample count in the status string can be calculated correctly.
Reviewed By: leesonw
Differential Revision: https://developer.blender.org/D13086
When reading pixels for virtual passes like diffuse, that sum diffuse direct
and indirect passes, we do not need them to exist with an offset in the render
buffer.
Instead of printing debug flags listing various CPU and GPU settings that
may or may not be used, print when we are using them. This include CPU
kernel types, OptiX debugging and CUDA and HIP adaptive compilation. BVH
type was already printed.
Adds scrambling distance to the PMJ sampler. This is based
on the work by Mathieu Menuet in D12318 who created the original
implementation for the Sobol sampler.
Reviewed By: brecht
Maniphest Tasks: T92181
Differential Revision: https://developer.blender.org/D12854
Cycles:Distance Scrambling for Cycles Sobol Sampler
This option implements micro jittering an is based on the INRIA
research paper [[ https://hal.inria.fr/hal-01325702/document | on micro jittering ]]
and work by Lukas Stockner for implementing the scrambling distance.
It works by controlling the correlation between pixels by either using
a user supplied value or an adaptive algorithm to limit the maximum
deviation of the sample values between pixels.
This is a follow up of https://developer.blender.org/D12316
The PMJ version can be found here: https://developer.blender.org/D12511
Reviewed By: leesonw
Differential Revision: https://developer.blender.org/D12318
Remove prefix of filenames that is the same as the folder name. This used
to help when #includes were using individual files, but now they are always
relative to the cycles root directory and so the prefixes are redundant.
For patches and branches, git merge and rebase should be able to detect the
renames and move over code to the right file.
* Split render/ into scene/ and session/. The scene/ folder now contains the
scene and its nodes. The session/ folder contains the render session and
associated data structures like drivers and render buffers.
* Move top level kernel headers into new folders kernel/camera/, kernel/film/,
kernel/light/, kernel/sample/, kernel/util/
* Move integrator related kernel headers into kernel/integrator/
* Move OSL shaders from kernel/shaders/ to kernel/osl/shaders/
For patches and branches, git merge and rebase should be able to detect the
renames and move over code to the right file.
Add a Fast GI Method, either Replace for the existing behavior, or Add
to add ambient occlusion like the old world settings.
This replaces the old Ambient Occlusion settings in the world properties.
Panning in camera view makes the border to be modified, which was causing
the Cycles display to believe the rendered result is unusable.
The solution is to draw the render result at the display parameters it was
updated for. This allows to avoid flickering during panning, zooming, and
camera FOV changes. The suboptimal aspect of this is that it has some jelly
effect, although it is on the same level as jelly effect of object outline
so it is not terrible.
Differential Revision: https://developer.blender.org/D12970
Similar to main path compaction that happens before adding work tiles, this
compacts shadow paths before launching kernels that may add shadow paths.
Only do it when more than 50% of space is wasted.
It's not a clear win in all scenes, some are up to 1.5% slower. Likely caused
by different order of scheduling kernels having an unpredictable performance
impact. Still feels like compaction is just the right thing to avoid cases
where a few shadow paths can hold up a lot of main paths.
Differential Revision: https://developer.blender.org/D12944
Easy now thanks to the main and shadow path decoupling. Doesn't help
in an benchmark scene except Spring, where it reduces render time by
maybe 2-3%.
Ref T87836
