Age | Commit message (Collapse) | Author |
|
The recent revert of Apple silicon inlining changes to avoid long compile times
worked on macOS 12, but in macOS 13 Beta it results in render errors. This may
be a compiler bug and perhaps get fixed in time, but try to be on the safe side
and ensure Blender 3.3.0 works regardless.
This brings part of the inlining back, which brings improved performance but
also longer compiler times again. Compile time is around 2min now, where the
previous full inlining was about 5-7min.
Patch by Michael Jones.
Differential Revision: https://developer.blender.org/D15897
|
|
Differential Revision: https://developer.blender.org/D15889
|
|
The fix from cefd6140f322 was for light intersection, but light sampling also
needs it.
Differential Revision: https://developer.blender.org/D15879
|
|
This was fixed in 8159e0a but accidentally reverted as part of 18b703d
|
|
sycl/L0 runtime reports compute-runtime version since Intel graphics
driver 101.3268 on Windows, when querying driver version from sycl.
Prior to this driver, it was 0. Now we can bump minimum requirement to
this one and filter-out devices returning 0.
Maniphest Tasks: T100648
|
|
|
|
|
|
The calculation was revised to address two issues:
* Discontinuities occurring when detail was a non-integer greater than 2.
* Levels of detail in the interval [0,1) repeating the levels of detail in
the interval [1,2).
This fixes Cycles, Eevee and geometry nodes.
Differential Revision: https://developer.blender.org/D15785
|
|
|
|
Fix typo in blender_release.cmake, and ensure that "make release" still works
when ocloc is not available. While a fatal error is useful for debugging, the
current convention is to disable features, especially in cases like this where
there is no simple way to make the feature work.
Differential Revision: https://developer.blender.org/D15774
|
|
Differential Revision: https://developer.blender.org/D15299
|
|
|
|
To avoid conflicts with BLI headers and simplify code.
|
|
|
|
This gave a 1.1x speedup, however also leads to very long compile times
that make it seems like Blender has stopped working.
This can be brought back in the future behind an option that users can
explicitly enabled.
Fix T100102
Ref D14923, D14763, T92212
|
|
|
|
The auto refresh option should be ignored in this case.
|
|
Checking for the existence of and using __GLIBC_PREREQ can't be done in the
same conditional.
Contributed by listout.
Differential Revision: https://developer.blender.org/D15690
|
|
|
|
I'm still not sure how the `0xFF` value came about, but it's not a
valid virtual key code.
Therefore it should not be used in `MapVirtualKey`.
|
|
|
|
This patch causes the render buffers to be copied to the denoiser
device only once before denoising and output/display is then fed
from that single buffer on the denoiser device. That way usually all
but one copy (from all the render devices to the denoiser device)
can be eliminated, provided that the denoiser device is also the
display device (in which case interop is used to update the display).
As such this patch also adds some logic that tries to ensure the
chosen denoiser device is the same as the display device.
Differential Revision: https://developer.blender.org/D15657
|
|
Detect cases where a ray-intersection would miss the current triangle, which if
the intersection is strictly watertight, implies that a neighboring triangle would
incorrectly be hit instead.
When that is detected, apply a ray-offset. The idea being that we only want to
introduce potential error from ray offsets if we really need to.
This work for BVH2 and Embree, as we are able to match the ray-interesction
bit-for-bit, though doing so for Embree requires ugly hacks. Tiny differences
like fused-multiply-add or dot product intrinstics in matrix inversion and ray
intersection needed to be matched exactly, so this is fragile.
Unfortunately we're not able to do the same for OptiX or MetalRT, since those
implementations are unknown (and possibly impossible to match as hardware
instructions). Still artifacts are much reduced, though not eliminated.
Ref T97259
Differential Revision: https://developer.blender.org/D15559
|
|
Helps improve ray-tracing precision. This is a bit complicated as it requires
different implementation depending on the CPU architecture.
|
|
The performance of this will be slightly more important for upcoming changes.
Also removed an unused function and changed includes so these system.h can
be included in more places.
|
|
Caused by 38af5b050100.
Adjust barycentric coordinates used for intersection result in the
ray-to-rectangle intersection check.
Differential Revision: https://developer.blender.org/D15592
|
|
|
|
|
|
zebin format is critical for the compatibility of AoT graphics binaries
across driver versions. It was previously disabled on Linux due to
runtime issues that are now fixed in
https://github.com/intel/compute-runtime/releases/tag/22.31.23852.
The minimum supported driver version isn't bumped to this one yet as
current codebase with current IGC compiler does actually run fine on
earlier drivers and is not running into these issues anymore.
|
|
Copy the improved hair curves sync implementation from D14942. That patch is
not ready as a whole but this part was verified to match the old hair particles
can be used already.
|
|
|
|
This was by design, but maybe not so useful in practice. It's always possible to
set alpha to 1 in compositing if needed.
|
|
Emrbee
It should consistently use the Cycles pirmitive ID for self intersection detection,
not the one from the OptiX or Embree acceleration structure.
Differential Revision: https://developer.blender.org/D15632
|
|
No denoising is supported in this case, it only works on images.
|
|
After recent changes to change barycentric coordinate convention.
|
|
Assume that all faces using the smae material form a closed mesh, so that
joining meshes gives the same result as separate meshes.
It does mean that using different materials on different sides of one
closed mesh do not work, but the meaning of that is poorly defined anyway
if there is a volume interior.
|
|
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
Intel® Arc™ GPUs
Recently, performance with oneAPI have regressed due some recent
changes in Blender itself. This commit's changes is resolving this
and also improve compilation time for oneAPI backend first
execution (or Blender compilation time in case of AoT).
Regression have appeared after 5152c7c152e and not related to the
changes itself, but increase of kernels complexity introduced with
it. Changes in this commit is marking some Blender functions as
noinlined for oneAPI backend, which helps GPU compiler to deal with
this complexity without any negative side-effects on performance.
|
|
Checking arm64 assembly support before CUDA/Metal would cause NVCC to
generate inline arm64 assembly.
Differential Revision: https://developer.blender.org/D15569
|
|
Simplifies intersection code a little and slightly improves precision regarding
self intersection.
The parametric texture coordinate in shader nodes is still the same as before
for compatibility.
|
|
|
|
Runtime switching between Embree and BVH2 got lost.
|
|
The number of Execution Units and resident "threads" (simd width * threads
per EUs) are now exposed and used to select the number of states using
a simplified heuristic.
|
|
|
|
float8 is a reserved type in Metal, but is not implemented. So rename to
float8_t for now.
Also move back intersection handlers to kernel.metal, they can't be in the
class that encapsulates the other Metal kernel functions.
|
|
The issue was introduced by rBad5e3d30a2d2 which made possible to use
unbounded elevation angle.
In order to not touch the shading code, we just remap the value to the
expected range the shading code expects. This means that elevation angles
above +/-PI/2 effectively flip the sun rotation angle.
|
|
This was tested in some places to check if code was being compiled for the
CPU, however this is only defined in the kernel. Checking __KERNEL_GPU__
always works.
|
|
This patch adds required math functions for float8 to make it possible
using float8 instead of float3 for color data.
Differential Revision: https://developer.blender.org/D15525
|
|
Having the OptiX/MetalRT/Embree/MetalRT implementations all in one file with
many #ifdefs became too confusing. Instead split it up per device, and also
move it together with device specific hit/filter/intersect functions and
associated data types.
|
|
No need anymore to have a difference between CPU/GPU, all distances
remain in world space.
|