This change makes it so only kernels of the same vendor are compiled in
parallel. For example for the release builds it will be:
1. All CUDA kernels
2. All OptiX kernels
3. All HIP kernels
4. All OneAPI kernels
This potentially leads to a lower CPU utilization, but it makes it much
easier to manage memory usage and tweak per-vendor concurrency.
The goal of this change is to solve occasional out-of-memory during the
GPU kernels compilation step on the CI/CD farm.
This change also includes tweaks to the prallel jobs for HIP-RT and
oneAPI. The tweak is based on measuring apparent memory usage peak on
Linux when doing single-thread compilation, and giving some safe margin
from the available memory on the buildbot.
Pull Request: https://projects.blender.org/blender/blender/pulls/129945
All the OSL matrix functions had been implemented using the
`Transform` utility of Cycles, but that's built around a 4x3 matrix,
when the OSL matrix functions are working with 4x4 matrices.
This resulted in them not producing results consistent with the
CPU implementation.
This fixes that by making use of the `ProjectionTransform` utility
of Cycles instead, because it's built around a 4x4 matrix. Since
matrix inversion is required, I had to make a few more utility
functions available on the GPU (except Metal, due to use of
references/pointers without specification) that were previously
CPU-only.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110102
The `osl_wavelength_color_vf` intrinsic was missing an implementation for
OptiX, causing a link error when attempting to load OSL shaders using the
wavelength node.
Pull Request: https://projects.blender.org/blender/blender/pulls/129372
In volume segment, the minimal angle formed by the emitter bounding cone
axis and the vector pointing from the cluster centroid to any point on
the ray is computed via `dot(bcone.axis, point_to_centroid)`, see Fig.8.
in paper.
For distant light this angle is 0, but due to numerical issues this is
not always true. Therefore explicitly assign `-bcone.axis` to
`point_to_centroid` in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/129489
This PR fixes a latent issue arising from invalid use of `accept_any_intersection(true)` when performing SSS ray-stepping with MetalRT. The comment incorrectly states that "we can optimize and accept the first hit", but to guarantee correct behaviour in future we need to request the closest hit.
Draine phase function sampling internally use Henyey-Greenstein and
Rayleigh sampling for degenerated cases, but the sampling pattern was
different between Draine and Rayleigh. The commit effectively replace
`rand` with `1 - rand` in Rayleigh sampling.
Pull Request: https://projects.blender.org/blender/blender/pulls/129261
When `g == 0`, the Draine phase function from
https://doi.org/10.1051/0004-6361/202142437 simplifies to
\[\Phi(\theta)=\frac{3}{4\pi(3+\alpha)}(1+\alpha\cos^2\theta).\]
Similar as Rayleigh sampling in https://doi.org/10.1364/JOSAA.28.002436,
The solution to the CDF of the marginal density function is
\[\cos^3\theta+a\cos\theta+b=0,\]
with
\[a=\frac{3}{\alpha},\quad b=\frac{3+\alpha}{\alpha}(2\xi_1-1),\]
which has only one real root since \(\alpha > 0\),
resulting in the sample technique
\[\cos\theta=u-\frac{1}{\alpha u}.\]
Pull Request: https://projects.blender.org/blender/blender/pulls/129259
Fix the failing rendering of volumes on Windows with HIP SDK 6.1
by reducing the optimization level.
There should be no functional or performance difference for the average
user as the Blender foundation currently does not use HIP SDK 6.1
on Windows. This change is primarily to fix issues for community members
building Blender locally.
Pull Request: https://projects.blender.org/blender/blender/pulls/128836
Gitea would complain the apostrophe in one of the code comments in
tree.h was an ambiguous Unicode character. So fix it by swapping it
for a more common apostrophe type.
The ray offsetting triangle tests are not numerically identical to
those found in custom BVH implementations.
There was a TODO to fix this, but there was no explaination for why
it should be done. This fixes that.
This packs the SVM stack, current node offset and closure weight into one struct, and just passes that to each SVM node implementation.
This way we don't have to pass the offset back and forth all over the place, and adding additional state (e.g. for layering in the future) becomes easier.
Pull Request: https://projects.blender.org/blender/blender/pulls/110443
- Deduplicate Fisheye projection code
- Replace spherical/cartesian conversions with shared helpers
- Replace transforms from/to local coordinate systems with shared helpers
The main type of repeated transform that's not covered here is `to/from_coords`, but with separate values for xy and z (e.g. BSDFs that already computed `dot(wi, N)` earlier, so they only need `dot(wi, X)` and `dot(wi, Y)` later). Could also be replaced, but it would feel weirdly specific for a helper function.
Pull Request: https://projects.blender.org/blender/blender/pulls/125999
Previously, when compiling on Rocky Linux 8 with fno-honor-nans, compile
time was more than 5x longer than expected, and there was an unresolved
symbol to __sqrtf_finite in GPU binaries.
Once defining sqrtf in compat.h, both issues are effectively gone, this
was certainly due to problematic interactions with build system's math
library headers.
So we can remove current workaround of defining fhonor-nans, and now
have the same set of flags on both Windows and Linux.
Fixes a issue where the Principled BSDF would render incorrectly if
`__SUBSURFACE__` is off. Which is common when using adaptive kernel
compilation (a unsupported Cycles feature).
Pull Request: https://projects.blender.org/blender/blender/pulls/128003
Previously, Cycles only supported the Henyey-Greenstein phase function for volume scattering.
While HG is flexible and works for a wide range of effects, sometimes a more physically accurate
phase function may be needed for realism.
Therefore, this adds three new phase functions to the code:
Rayleigh: For particles with a size below the wavelength of light, mostly athmospheric scattering.
Fournier-Forand: For realistic underwater scattering.
Draine: Fairly specific on its own (mostly for interstellar dust), but useful for the next entry.
Mie: Approximates Mie scattering in water droplets using a mix of Draine and HG phase functions.
These phase functions can be combined using Mix nodes as usual.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/123532
This enables most of the GPU compiler's optimizations while -ffast-math
isn't set at DPC++ level.
It brings an overall 1% speedup and currently doesn't change the unit
tests pass rate.
This change switches Cycles to an opensource HIP-RT library which
implements hardware ray-tracing. This library is now used on
both Windows and Linux. While there should be no noticeable changes
on Windows, on Linux this adds support for hardware ray-tracing on
AMD GPUs.
The majority of the change is typical platform code to add new
library to the dependency builder, and a change in the way how
ahead-of-time (AoT) kernels are compiled. There are changes in
Cycles itself, but they are rather straightforward: some APIs
changed in the opensource version of the library.
There are a couple of extra files which are needed for this to
work: hiprt02003_6.1_amd.hipfb and oro_compiled_kernels.hipfb.
There are some assumptions in the HIP-RT library about how they
are available. Currently they follow the same rule as AoT
kernels for oneAPI:
- On Windows they are next to blender.exe
- On Linux they are in the lib/ folder
Performance comparison on Ubuntu 22.04.5:
```
GPU: AMD Radeon PRO W7800
Driver: amdgpu-install_6.1.60103-1_all.deb
main hip-rt
attic 0.1414s 0.0932s
barbershop_interior 0.1563s 0.1258s
bistro 0.2134s 0.1597s
bmw27 0.0119s 0.0099s
classroom 0.1006s 0.0803s
fishy_cat 0.0248s 0.0178s
junkshop 0.0916s 0.0713s
koro 0.0589s 0.0720s
monster 0.0435s 0.0385s
pabellon 0.0543s 0.0391s
sponza 0.0223s 0.0180s
spring 0.1026s 1.5145s
victor 0.1901s 0.1239s
wdas_cloud 0.1153s 0.1125s
```
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121050
Temporarily disable point cloud rendering in HIPRT to fix a performance
regression triggered by increased register preasure until
a better solution can be developed.
Pull Request: https://projects.blender.org/blender/blender/pulls/127738
VDB files would fail to render in HIP-RT because NanoVDB wasn't
enabled when compiling HIP-RT kernels, resulting in NanoVDB textures
not being sampled and a blank result being returned instead.
The fix is to enable NanoVDB when compiling HIP-RT kernels.
Ref: #125086
Pull Request: https://projects.blender.org/blender/blender/pulls/127384
The same random number was used for sampling color channel at each step,
which leads to bias. Fixed by rescaling the random number.
Another possibility would be to scramble `rng_offset` and use a new
random number each time, similar as in subsurface scattering, but
rescaling random number should be faster than computing a new one, and
is favorable here since the precision here is not very important
Pull Request: https://projects.blender.org/blender/blender/pulls/127454
The device code was disabled for primitives with deformation blur
and the intersection function always returned false, hence no
rendered primitive.
Other than that, there were a few bugs on both device and host codes
(e.g., the order of current and previous times and the primitive name.)
Pull Request: https://projects.blender.org/blender/blender/pulls/127163
Fixes a few issues with point clouds with HIPRT.
1. Crashing when building the BLAS due to an incorrect sized array.
2. A typo leading to all point cloud intersections being skipped.
3. A typo leading to some motion blurred point clouds rendering
as if they were stationary, or not rendering at all.
Pointclouds, with deformable motion blur, with BVH time steps set to >0
still do not render. Curves seem to have the same issue.
Ref #125086
Pull Request: https://projects.blender.org/blender/blender/pulls/125834
`atan2(0, 0)` is undefined on many platforms. To ensure consistent
result across platforms, we return `0` in this case.
Note only the behavior of the shader node `Artan2` is changed here.
During shading, we might still produce `atan2(0, 0)` internally and
cause different results across platforms, but that usually happens with
single samples and is not obvious, plus checking this condition all the
time is costly. If later we find out it's indeed necessary to change all
the invocation of `atan2(0, 0)`, we could change the wrapper functions
in `metal/compat.h` and `mtl_shader_defines.msl`.
Pull Request: https://projects.blender.org/blender/blender/pulls/126951
The kernel zeroing memory since we've added host memory fallback didn't
expect large inputs, so with these scenes, it was running into
"Provided range is out of integer limits. Pass
`-fno-sycl-id-queries-fit-in-int' to disable range check" error.
This kernel was used instead of memset to avoid some issues with the
free_memory queries not always being updated.
As we can't reproduce these with recent drivers, we now use memset,
which fixes rendering with BVH2.
Use a bounding sphere instead of the corners of a bounding box to
compute the subtended angle of a light tree node.
Using the corners of the bounding box was an underestimate in some
scenes, causing some light tree nodes being incorrectly skipped.
Using the subtended angle of a bounding sphere is an overestimate, but
it covers the entire node and would not skip any valid contribution,
and no other reliable algorithm to compute the minimal enclosing angle
is known to us.
We expect some increase in noise due to overestimation, but this has
not been observed yet, in our benchmark scenes only a difference in
noise is visible.
Thanks to Weizhen for the suggestion to use the bounding sphere.
Pull Request: https://projects.blender.org/blender/blender/pulls/126625
Add Metallic BSDF Node to the shader editor.
This node can primarily be used to create more realistic looking
metallic materials than the existing Glossy BSDF node.
This commit does not add any new closures to Cycles, it simply exposes
existing closures that were previous hard to access on their own.
- Exposes the F82 fresnel type that is currently used by the
metallic component of the Principled BSDF. Results should match
between the Metallic BSDF and Principled BSDF when using the same
settings.
- Exposes the Physical Conductor fresnel type that was previously
limited to custom OSL scripts. The Conductor fresnel type accepts
IOR and Extinction coefficients to define the appearance of the
material based off real life measurements.
EEVEE only supports the F82 fresnel type with internal code to convert
the the physical conductor inputs in to a colour format for F82,
which can lead to noticeable rendering differences with
some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114958
when tracing shadow ray through a volume and no hit is registered, we
consider the whole ray segment inside the volume.
However, no hit registered could also happen when the volume is
invisible to shadow ray. We should explicitly check this case and skip
rendering the volume segment instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/126139
This patch improves the isotropic Gabor noise UI controls such that
variations happen in both directions of the base orientation, as opposed
to being biased in the positive direction only.
Thanks to Charlie Jolly for suggesting this improvement.
