This change puts all the block size macros in the same common header, so
they can be included in host side code without needing to also include
the kernels that are defined in the device headers that contained these
values.
This change also removes a magic number used to enqueue a kernel, which
happened to agree with the GPU_PARALLEL_SORT_BLOCK_SIZE macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/143646
The performance of the sorted_paths_array kernel on B570 is problematic.
Relying on local sorting+partitioning instead gives a 25% overall rendering
speedup and no regression in shade_surface when rendering Agent 327 Barbershop scene.
On Arc A770, it still gives a 2% speedup when rendering Barbershop.
Pull Request: https://projects.blender.org/blender/blender/pulls/140308
This reverts commit 5abf42012d in the
blender-v4.5-release branch to work around HIP compiler issues. It will
remain in the main branch.
Ref blender/blender#139836
Unlike OpenGL and Metal, this handle is not shared, but rather Cycles
has to take ownership of it. This required a fair amount of refactoring
to ensure the handle is closed, ownership is properly transferred, and
the handle is recreated once when the pixel buffer is modified.
In detail:
- Direct accesses of state attributes are replaced with the INTEGRATOR_STATE and INTEGRATOR_STATE_WRITE macros.
- Unified the checks for the __PATH_GUIDING define to use # if defined (__PATH_GUIDING__).
- Even if __PATH_GUIDING__ is defined, we now check if the feature is enabled using if ((kernel_data.kernel_features & KERNEL_FEATURE_PATH_GUIDING)) {. This is important for later GPU ports.
- The kernel usage of the guiding field, surface, and volume sampling distributions is wrapped behind macros for each specific device (atm only CPU). This will make it easier for a GPU port later.
* Add GraphicsInteropDevice to check if interop is possible with device
* Rename GraphcisInterop to GraphicsInteropBuffer
* Include display device type and memory size in GraphicsInteropBuffer
* Unnest graphics interop class to make forward declarations possible
Pull Request: https://projects.blender.org/blender/blender/pulls/137363
According to the OptiX denoising guide lines, renders should be in the
0..10000 range. As a result, clamping was applied to renders
prior to GPU denoising.
However this lead to a issue where denoising of bright images would
behave differently between CPU OIDN and GPU OIDN as this same clamping
was also applied to the GPU OIDN denoiser.
According to Attila Áfra, a developer working on OIDN, this clamping
isn't neccesary for OIDN. So this commit removes the clamping from
OIDN.
Pull Request: https://projects.blender.org/blender/blender/pulls/137879
The crash was caused by an overflow in the opgl_path_segment_storage
array. It happened because shadow catcher paths would write to the
segments but not clear them. This made it so the next render loop
iteration for the main path starts with non-empty segments in the
guiding data.
Disable training when megakernel is called for the shadow catcher
state.
To ensure this issue is not forgotten when the guiding is ported to
GPU add asserts in the `guiding.h`. While it is a no-op for default
GPU kernels sometimes we do compile debug kernels. But also it acts
as a plain-text reminder to the future-us in working on the code.
There is now also an assert before the main path megakernel to help
catching such cases in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/137291
Cycles has a sample offset feature allowing users to render X samples
in a single frame on one device, then the remaining Y samples later or
on a different device and combine them back together at the end.
However in most situations the result from using this method was
different, and usually lower quality than rendering all the samples in
one go.
This was because Cycles tunes it's random number sequence for the
number of samples being rendered. And the random number sequence was
being tuned for the wrong number of samples in the case that a user
was using the sample offset.
This commit fixes this issue by adding a "sample subset" feature.
The user specifies the total sample count being rendered across all
devices in the existing `Max Samples` parameter, then specifies per
device which subset of samples will be rendered (E.g. Render samples
0-1024 out of a 0-2048 range).
This commit also contains some additional clean up work
inside Cycles related to the area being changed.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/132961
Update the OptiX denoiser model type to the newer and more frequently
updated `OPTIX_DENOISER_MODEL_KIND_AOV` denoiser.
The output of the new denoiser type is typically higher quality.
And the old denoiser is no longer being updated.
Original change was proposed by Patrick Mours from NVIDIA.
Pull Request: https://projects.blender.org/blender/blender/pulls/132542
Check was misc-const-correctness, combined with readability-isolate-declaration
as suggested by the docs.
Temporarily clang-format "QualifierAlignment: Left" was used to get consistency
with the prevailing order of keywords.
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
* Use .empty() and .data()
* Use nullptr instead of 0
* No else after return
* Simple class member initialization
* Add override for virtual methods
* Include C++ instead of C headers
* Remove some unused includes
* Use default constructors
* Always use braces
* Consistent names in definition and declaration
* Change typedef to using
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
Currently the number of shadow paths is multiplied by the ratio of
0.5f which would half the number of paths. However, the index can
never be smaller than the number of paths so the shadow paths will
always be compacted.
Pull Request: https://projects.blender.org/blender/blender/pulls/125048
Looks like some recent changes in the driver broke an assumption
the OptiX denoiser code in Cycles made about being able to set it up
with a different input size than later used to invoke it, which caused
broken output on older GPU architectures. This commit fixes that by
ensuring the input image size passed to `optixDenoiserSetup` matches
that passed to `optixDenoiserInvoke`, even when no tiling is used
(which is the common case).
Pull Request: https://projects.blender.org/blender/blender/pulls/129398
Avoid printing the word `size` twice when printing information about
the scheduled tile size to terminal when Blender is launched with
with `--debug-cycles --verbose 3` or higher.
Pull Request: https://projects.blender.org/blender/blender/pulls/127885
Fix the unnecessary recreation of the denoiser that occurs if
Cycles had fallen back to an alternative denoiser in a previous
interation. (E.g. Fallback from OptiX to OIDN)
This issue occured because Cycles didn't understand that when it
previously setup the denoising device, that it had fallen back to
something else. So it thinks the denoising settings have been changes
and tries to recreate the denoiser.
The solution is to first compute the settings change due to
the fallback, then check to see if it's different from the current
denoiser, then recreate the denoiser device if neccesary.
Pull Request: https://projects.blender.org/blender/blender/pulls/125453
The issue was caused by an attempt to write buffer pass which is
actually supposed to be calculated as compositing (either summing
direct/indirect lights, optionally diving by albedo).
The fact that the crash was only observed on Metal is a lucky
con-incident: it just happened to be so that writing at offset
-1 to the render buffer did not trigger obvious issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/126057
Fixes an issue where Blender would crash if the OptiX denoiser was
selected, but an unsupported GPU device (E.g. Intel GPU) was
selected in preferences.
This crash would occur because Cycles uses the device in preferences
to setup the denoiser, and there was no check stopping an unsupported
GPU from being used to try and setup and run the denoiser.
Pull Request: https://projects.blender.org/blender/blender/pulls/124001
Ever since the introduction of GPU OIDN denoising on CPU devices,
using the path_tracing_device info to pick the automatic denoiser has
typically led to incorrect results.
This commit fixes this issue by using the denoising device info to pick
the denoiser.
Pull Request: https://projects.blender.org/blender/blender/pulls/123593
Cycles automatic denoiser picker assumed that OIDN could not be
run on the GPU while the CPU was the render device. So if the user was
using their CPU for rendering, the automatic denoiser picker would
"fallback" to a different denoiser (OptiX or CPU OIDN). This was true
in Blender 4.1, but changed in 4.2. The UI assumed that OIDN could run
on the GPU if there was a compatible OIDN GPU device.
This lead to a issue on systems using the CPU for rendering
while having a NVIDIA GPU installed in the system. The
UI suggested that OIDN would be used, and would switch between
CPU and GPU depending on user preferences. But the automatic
denoiser picker in Cycle's backend said OIDN could not run on
the GPU in this situation and would always "fallback" to the
OptiX denoiser running on the NVIDIA GPU.
This created a mismatch between the UI and what Cycles was
acutally doing. This issue did not effect other GPU vendors because
their "fallback" was the OIDN denoiser.
This commit fixes this issue by aligning the Cycles automatic
denoiser picker in the backend with the UI. Using OIDN if a GPU
is supported, falling back to OptiX if it's not supported,
falling back to OIDN CPU if OptiX isn't supported,
then falling back to no denoiser if that's not supported.
Pull Request: https://projects.blender.org/blender/blender/pulls/123530
Since #118841 there are more cases where Cycles would check for the
graphics interop support. This could lead to a crash when graphics
interop functions are called without having active graphics context.
This change makes it so there is no graphics interop calls when doing
headless render. In order to achieve this the device creation is now
aware of the headless mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/122844
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
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.
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
