Buildbot infrastructure relies on the fact that it can enable and
disable `WITH_CYCLES_<COMPUTE>_BINARIES` without affecting speed of
incremental builds. This allows buildbot to skip GPU kernels when
doing CI regression tests which do not need GPU kernels, as well as
it allows to move GPU kernels compilation to a separate step where
all the resources are available to the GPU kernel builders.
For the oneAPI compute enabling and disabling AoT kernels has much
higher implications due to the kernels being a part of the device
implementation from the build target perspective.
This change makes it so different target names are used for JIT and
AoT configurations, which allows CMake to more fully benefit from
"caching" the compiled result.
The end goal of this change is to make it so sequential build of the
same code base on the buildbot happens super fast,
Blender binary still needs to be re-linked when the AOT of oneAPI
option is toggled, but that's already the case in the buildbot due
to the WITH_BUILDINFO.
Differential Revision: https://developer.blender.org/D16312
sycl::info::device::ext_intel_* descriptors are deprecated,
replaced with sycl::ext::intel::info::device:: that are available from
6.0+, for which we now check version in CMake.
- Clarify how data_offer is used for both the clipboard & drag-and-drop.
- Acquire the clipboards mutex lock before freeing.
- Log a warning when creating a pipe fails.
- Add doxy-sections.
- Improve reporting when reading a file descriptor into a buffer fails,
also check for failure to allocate memory.
- Store buffers with size in a simple struct.
- Use shared utility functions for simple buffer operations.
In T93382, the problem was that the Blender-side rendering code was
still generating the subsurface passes because the old render pass
flags were set, even though Cycles doesn't generate them anymore.
After a closer look, it turns out that the entire hardcoded pass
creation code can be removed. We already have an Engine API function
to query the list of render passes from the engine, so we might as
well just call that and create the returned passes.
Turns out that Eevee already did this anyways. On the Cycles side, it
allows to deduplicate a lot of `BlenderSync::sync_render_passes`.
Before, passes were defined in engine.py and in sync.cpp. Now, all
passes that engine.py returns are created automatically, so sync.cpp
only needs to handle a few special cases.
I'm not really concerned about affecting external renderer addons,
since they already needed to handle the old "builtin passes" in
their Engine API implementation anyways to make them show up in the
compositor. So, unless they missed that for like 10 releases, they
should not notice any difference.
Differential Revision: https://developer.blender.org/D16295
The external cancel callback destroyed the data source but didn't
clear the pointer. While this didn't cause problems,
avoid keeping references freed pointers.
Known Issues:
- Command buffer failures when using binary archives (binary archives is disabled for Intel GPUs as a workaround)
- Wrong texture sampler being applied (to be addressed in the future)
Ref T92212
Reviewed By: brecht
Maniphest Tasks: T92212
Differential Revision: https://developer.blender.org/D16253
Previously, a first build using ninja would throw "ninja: error:
'intern/cycles/kernel/cycles_kernel_oneapi.lib', needed by
'bin/blender.exe', missing and no known rule to make it".
MSVC Tools version doesn't match MSVC Redist version on some systems and
it's not populated when using Ninja outside of Visual Studio shell,
trying another way.
Add command line argument to switch gpu backend. Add `--gpu-backend` option to
override the gpu backend selected by Blender.
Values for this option that will be available in releases for now are:
* opengl: Force blender to select OpenGL backend.
During development and depending on compile options additional values can exist:
* metal: Force Blender to select Metal backend.
When this option isn't provided the internal logic for GPU backend selection will be used.
Note that this is at the time of writing the same as always selecting the opengl backend.
Reviewed By: fclem, brecht, MichaelPW
Differential Revision: https://developer.blender.org/D16297
Smooth & discrete scrolling may both be set, instead of always
prioritizing discrete, use discrete scrolling when the source is a
mouse wheel, otherwise prioritize smooth scrolling.
These events are interpreted as MOUSEPAN by Blender.
Tested with a Wacom Intuos5. This isn't full touch support
which is needed to support gestures such as Swipe, Rotate .. etc.
Previously this was only available as a build options, making it
difficult to get user feedback when NDOF events didn't work as expected.
Now logging can be enabled with:
blender --log "ghost.ndof.*" --log-level 2 --log-show-basename
DDS files coming through OIIO needed a similar treatment as TGA in
T99565; just for DDS OIIO just never set the "unassociated alpha"
attribute. Fixes T101850.
Reviewed By: Brecht Van Lommel
Differential Revision: https://developer.blender.org/D16270
- Use `_` suffix for private members.
- Use `wl_` prefix for Wayland native types to help distinguish
them from local types.
- Replace single character names `d` & `w` with `display` `window`.
- Rename `selection` to `clipboard`. Using the primary selection as a
clipboard is a separate and as yet unsupported feature.
These functions are almost identical, the main difference being
BLI_join_dirfile didn't trim existing slashes when joining paths
however this isn't an important difference that warrants a separate
function.
Using varargs had the disadvantages, replace with a macro which has
some advantages.
- Arguments are type checked.
- Less verbose.
- Unintended NULL arguments would silently terminate joining paths.
- Passing in a NULL argument warns with GCC.
This was a floating point precision issue - or, to be more precise,
an issue with how Cycles split floats into the integer and fractional
parts for Perlin noise.
For coordinates below -2^24, the integer could be wrong, leading to
the fractional part being outside of 0-1 range, which breaks all sorts
of other things. 2^24 sounds like a lot, but due to how the detail
octaves work, it's not that hard to reach when combined with a large
scale.
Since this code is originally based on OSL, I checked if they changed
it in the meantime, and sure enough, there's a fix for it:
https://github.com/OpenImageIO/oiio/commit/5c9dc68391e9
So, this basically just ports over that change to Cycles.
The original code mentions being faster, but as pointed out in the
linked commit, the performance impact is actually irrelevant.
I also checked in a simple scene with eight Noise textures at
detail 15 (with >90% of render time being spent on the noise), and
the render time went from 13.06sec to 13.05sec. So, yeah, no issue.
