Drag and dropping bitmap images (as in drag and dropping directly from
another software such as a web browser, not from an image file in
Finder) inside the Blender window on macOS would segfault due to the
dropped image being [autorelease]d even though its data was meant to
outlive the function scope.
Fixed by removing the superflous autorelease and adding a comment note.
The only caller of this function (GHOST_SystemCocoa::handleDraggingEvent)
already properly [release]s the image in question.
Note that currently, non-file/bitmap image drag and drop is not
implemented on the WM side, and as such this feature/GHOST event does
not do anything practical.
Pull Request: https://projects.blender.org/blender/blender/pulls/135076
Remove GP legacy obtype and unused functions
Few hidden bugs are fixed with that:
- Outliner drag-drop for GP material/effect elements now works
- Correct stats are shown in status bar.
Pull Request: https://projects.blender.org/blender/blender/pulls/133957
This is an intermediate steps towards making lights actual geometry.
Light is now a subclass of Geometry, which simplifies some code.
The geometry is not added to the BVH yet, which would be the next
step and improve light intersection performance with many lights.
This makes object attributes work on lights.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/134846
The attribute handling code in the kernel is currently highly duplicated since
it needs to handle five different data types and we couldn't use templates
back then.
We can now, so might as well make use of it and get rid of ~1000 lines.
There are also some small fixes for the GPU OSL code:
- Wrong derivative for .w component when converting float2/float3->float4
- Different conversion for float2->float (CPU averages, GPU used to take .x)
- Removed useless code for converting to float2, not used by OSL
Pull Request: https://projects.blender.org/blender/blender/pulls/134694
This change brings the following improvements on the user level
- Support of GPUs with gfx12 architecture
- New HIP-RT library which in addition to the gfx12 support brings
various bug-fixes.
The known limitation of gfx12 is that OpenImageDenoiser does not yet
support this GPU architecture. This means that while Cycles will use the
full advantage of the gfx12 (including hardware accelerated ray-tracing),
denoising will only be possible on CPU, or secondary gfx11 or below GPU.
This is something that requires a change in OIDN and it is to late to do
it for Blender 4.4, but it is something to look forward for Blender 4.5.
The gfx12 changes for the pre-compiled kernels is rather trivial,
so it comes together (in the same PR) as the bigger HIP-RT change.
On the development side this change brings the following improvements:
- One step compile and link (much simpler CMake rules)
- Embedding BVH binaries in hiprt dll (which makes it easier to package
and load, without relying on special path configuration)
Co-authored-by: Sahar Kashi <sahar.kashi@amd.com>
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/133129
Followup to 48e26c3afe, and discussions in !134771 about keeping
'C-style' and 'C++ template type-safe style' implementations of our
guardedalloc separated. And it makes `MEM_freeN<T>` code simpler.
Also skip type-checking in `MEM_freeN<T>` only with MSVC, as clang-cl on
windows-arm64 does work fine with DNA structs using
`DNA_DEFINE_CXX_METHODS`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134861
The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
There is a bug in Embree that makes BVH updates crash. Disabling multithreaded
BVH updates after the initial BVH build appears to work around it, at the cost
of some performance.
This will not affect performance of the initial BVH build, transforming objects
or editing a single mesh. It will only affect performance when multiple smaller
meshes are edited together, as those can no longer have their BVH updated in
parallel or benefit from parallellization over many primitives.
Pull Request: https://projects.blender.org/blender/blender/pulls/134747
Plotting happens from the given root node into a graphviz file.
Supports plotting from both scene level LightTreeNode and the kernel
level KernelLightTreeNode.
An external graphviz command is to be used to convert generated file
to an image.
Pull Request: https://projects.blender.org/blender/blender/pulls/134738
The original report stumbled upon this issue with a more tricky
configuration when light linking is combined with light tress.
However, the actual contributing factor was a mesh with emission
shader which is not assigned to any triangles. This triggered a
bug in the BoundBox::transformed() which converted non-valid bounds
to bounds by performing per-corner growing.
Additionally fix incorrect handling of shared nodes which only
worked for leaf nodes. This was due to the fact how the measure
was accumulated: it is possible that add() is called with an empty
measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/134699
194e233d86 caused a discussion in the chat about the initialization
behavior of `MEM_new()`, and agreement was to not rely on
zero-initialization ever. Noted this in the API comment now.
Some people found the existing comment useful but it still left some
questions. Tried to clarify that now.
This is a crucial memory management function, it's important to have
behavior documented well, even if a full explanation is out-of-scope.
Also added another link in case people want to check more details.
Pull Request: https://projects.blender.org/blender/blender/pulls/134577
This patch modifies the logic behind handling NDOF device events on
macOS so that it can benefit from the `Blender` profile available in
3DConnexion driver v10.8.7 and later.
A new device command was introduced: `kConnexionCmdAppEvent`, which is
sent by the driver upong getting an apprioriate NDOF device button
input. This allow the driver to consumes all NDOF device input and then
send appropriate app events based on its configuration instead of
forwarding raw data to the application directly.
When using 3DConnexion driver versions prior to v10.8.7, the behavior
is unchanged. This approach allows for supporting all of the SpaceMouse
Enterprise buttons, long presses included (solving issue #119206 on macOS)
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/126694
The issue here is that the individual components of TypeDesc are 8-bit each,
but the code was applying a 4-bit mask. It just so happens that the only
case where this matters is TypeDesc::MATRIX44, since its value is 16.
In Cycles lights can be given a light falloff node to control their
light falloff.
This worked by multiplying the light's strength by different
combinations of the ray length, which would be FLT_MAX for
distant lights. This resulting in almost every configuration of the
light falloff node overflowing when used on distant lights, which is
undesirable.
This commit fixes this issue by ignoring most of the functions of the
light falloff node when used on a distant light.
And in the process fixes a small discrepancy between SVM and OSL when
using the light falloff node on distant lights.
Pull Request: https://projects.blender.org/blender/blender/pulls/134539
free_memory queries were disabled due to runtime driver issues on Linux
when using jemalloc.
compute-runtime introduced a fix for these issues with
8527779778
which is part of versions 31740 and higher, and matches the currently
required min-driver version, so we can restore this feature.
Pull Request: https://projects.blender.org/blender/blender/pulls/134542
This commit fixes a issue where ray depth for emissive objects
(E.g. Lights) was incorrect when using the ray depth output of the
light path node in Cycles OSL.
Pull Request: https://projects.blender.org/blender/blender/pulls/134496
* Do oneAPI copy optimization as part of host memory alloc and free, so
it is properly released before host memory is freed.
* Synchronize after loading texture info, like CUDA and HIP.
https://projects.blender.org/blender/blender/pulls/134412
This may be used for device to do host memory allocation in a way that
is more efficient for copy the host memory to the device.
Also rename and group device memory allocation functions for clarity.
Pull Request: https://projects.blender.org/blender/blender/pulls/134412
The issue was caused by c0ba800f64.
Simple solution for now: check the data size and free the memory to
allow the device memory to be re-allocated. Seems the safest for the
upcoming release.
Ideally we'd need to avoid having these manual tricks with the device
memory pointers.
Pull Request: https://projects.blender.org/blender/blender/pulls/134516
The current usage of software-based texture operations in
the oneAPI implementation puts additional register pressure on
the GPU compiler during register allocation. And it also creates
code that requires maintenance. This commit is intended to address
this situation by utilizing a recently productized SYCL bindless
texture API to enable HW-based texture operations using
Intel GPUs' hardware sampler.
This currently translates to 1-11% rendering speedups (scene-specific)
on my Arc A770 and Arc B580. At the moment, there are small
performance regressions with NanoVDB texture operations on Arc B580
and small performance regressions in shade surface MNEE and Raytrace
kernels on Arc A770, but they look recoverable and will be handled
in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/133457
There is now a non-experimental API for this_work_item functionality, so
let's use it for better code quality and also to avoid the deprecation
warning during compilation.
No functional or performance changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/133472
The issue also happens on macOS 15.3.
This is a Metal driver bug, a fix is coming in macOS 15.4. Until then
disable refitting the viewport. There is no perceptible benefit from
refitting, so while it might be less that ideal it allows to side step
the problem and still benefit from the HWRT.
Pull Request: https://projects.blender.org/blender/blender/pulls/134399
