On an iMac (Retina 5K, 27-inch, Late 2015) it crashed when rendering using Cycles. This was due to the fact that it incorrectly detected that the machine supported ray tracing. This uses the device.supportsRaytracing flag to fill in the use_hardware_raytracing flag for the device.
This patch removes a workaround for an issue that is now understood to be undefined behaviour (and fixed by #108176). It also adds two useful debug flags that we would like to be available in Blender 3.6.
Pull Request: https://projects.blender.org/blender/blender/pulls/108322
This patch fixes an undefined behaviour where we were trying to use linked functions with binary archives. This isn't supported yet. At best this will fail silently, but this is not guaranteed in future. To fix this we simply disable binary archives if any linked functions are involved. The impact of this is that the `SHADE_SURFACE_RAYTRACE` and `SHADE_SURFACE_MNEE` kernels will fall back to the file system cache when MetalRT is enabled. The file system cache will occasionally be purged due to factors beyond Blender's control.
Pull Request: https://projects.blender.org/blender/blender/pulls/108176
Only Embree CPU BVH was built in the multi-device case. However, one
Embree GPU BVH is needed per GPU, so we now reuse the same logic as in
the other backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/107992
Hardware Raytracing wasn't properly disabled or enabled in the
subdevices of the multi-device.
This construct:
foreach ( DeviceInfo &info,
(device.multi_devices.size() != 0 ?
device.multi_devices : vector<DeviceInfo>({device}))
)
was a nice trap - it was giving a copy to iterate on.
Pull Request: https://projects.blender.org/blender/blender/pulls/107989
NanoVDB headers have unused code using "double" type, which is not supported on Arc GPUs.
Recent DPC++ changes enforced runtime verifications:
7663dc201d
which prevents execution when such type has been present even if unused.
This is a solution to avoid double to be compiled at all, similar as how it is done for Metal.
Area light sampling use special techniques to reduce noise with small
spread angles; the change in sampled area was not taken into
consideration when computing the pdf in MNEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/107897
After the removal of the Shadow pass this no longer worked. Now it works by
marking the object as a shadow catcher and returning the Shadow Catcher pass.
The result is different than before, since it also takes into account indirect
light now and uses a different method to weight the contribution of lights that
is adaptive to the light strength.
Without this, support for newer NVIDIA cards will not be compiled with pre-compiling the CUDA binaries.
Includes changes needed for the buildbot building pipeline.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/107585
79f1cc601c introduces a ray-offset to improve ray tracing precision near
triangle edges, but motion triangles still read the static vertices,
causing incorrect intersection detection
Pull Request: https://projects.blender.org/blender/blender/pulls/107748
This will make further changes for light linking easier, where we want to
build multiple trees specialized for each light linking set.
It's also easier to understand than the stack used previously.
Pull Request: https://projects.blender.org/blender/blender/pulls/107560
For derived mesh triangulation information, currently the three face
corner indices are stored in the same struct as index of the mesh
polygon the triangle is part of. While those pieces of information are
often used together, they often aren't, and combining them prevents
the indices from being used with generic utilities. It also means that
1/3 more memory has to be written when recalculating the triangulation
after deforming the mesh, and that the entire triangle data has to be
read when only the polygon indices are needed.
This commit splits the polygon index into a separate cache on `Mesh`.
The triangulation data isn't saved to files, so this doesn't affect
.blend files at all.
In a simple test deforming a mesh with geometry nodes, the time used
to recalculate the triangulation reduced from 2.0 ms to 1.6 ms,
increasing overall FPS from 14.6 to 15.
Pull Request: https://projects.blender.org/blender/blender/pulls/106774
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
In some cases the Geometry Nodes Volume Cube generates
a Volume grid that doesn't contain any leaf nodes. This can happen
when only tiles are needed to represent the volume.
This PR changes the `empty_grid` check function to also check if
there are any active tiles in the grid before returning `true`.
Pull Request: https://projects.blender.org/blender/blender/pulls/107551
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
* User simpler API names that accept both PTX and OptiX-IR
* New argument for optixProgramGroupGetStackSize, leave to default
* Remove OptixPipelineLinkOptions::debugLevel that does nothing
Pull Request: https://projects.blender.org/blender/blender/pulls/107450
There were two issues here preventing the proper display of the IES
files in question.
The primary one was that these lights are actually vertical. Their
profiles actually point upwards from 90deg to 180deg but our parser was
trying hard to adjust it to start at 0deg incorrectly.
Lastly, the files in question ended with the parser in the `eof`
state - they are "missing" the final carriage return that other IES
files tend to have but other viewers don't seem to mind. Change the
`eof` check instead for a better one that will indicate if any parsing
errors occurred along the way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107320
MSVC can't optimize it out and even keeps an external call to CRT
function rintf: https://godbolt.org/z/Ex9vjf8vj
It does translate to a real speedup on windows on some scenes, here are the ratios I had on my 13900K:
classroom 101.53%
junkshop 100.71%
monster 100.76%
attic 107.98%
bistro 113.00%
Pull Request: https://projects.blender.org/blender/blender/pulls/107371
Since the version v1.5.0 of sse2neon the functionality for denormals
flushing is implemented in the library. This commit makes it so the
_MM_SET_FLUSH_ZERO_MODE and _MM_SET_DENORMALS_ZERO_MODE are used from
the ss2neon if available.
This solves macro re-definition when a newer sse2neon is used.
The change is implemented in a way that both current and new sse2neon
are supported.
The intersection distance offset in Cycles could have returned
a denormal floating point value for the input values of 0 (and
for the denormal input value).
This could lead to a situation when ray is unable to be advanced
when it hits an edge between two triangles: the intersection will
keep bouncing between two adjacent triangles. This is because the
ray->tmin is compared inclusively, and 0 >= <denormal zero>.
The solution is to return the smallest possible normalized floating
point value from the intersection_t_offset if the input is zero
or a denormal value (which is covered by the same t == 0 check).
This fix is hard to measure on the user level. The old code did
not cause any infinite traversal loop because of the way how the
integration is organized (some kernels offset ray.P, others check
for the number of bounces). It is possible that this fixes some
corner cases of noise: i.e. if some shadow rays falsefully were
considered occluded due to reached maximum number of bounces.
The actual problematic case was discovered during working on a
prototype which had an in-lined intersection loop with the ray
tmin offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/107364
HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a
to shader implementation for older graphics cards. It offers an average 25%
sample rendering rate improvement in Cycles benchmarks, on a W6800 card.
The ray tracing feature functions are accessed through HIP RT SDK, available on
GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and
shipped with the SDK.
This is not yet enabled as there are issues to be resolved, but landing the
code now makes testing and further changes easier.
Known limitations:
* Not working yet with current public AMD drivers.
* Visual artifact in motion blur.
* One of the buffers allocated for traversal has a static size. Allocating it
dynamically would reduce memory usage.
* This is for Windows only currently, no Linux support.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
