Simplify logic for freeing a NULL pointer. While no null-pointer
de-reference was performed, this wasn't as so obvious as the pointer
was passed to MEM_lockfree_allocN_len before checking for NULL.
NOTE: T99744 claimed the a NULL pointer free was a vulnerability,
while I can't see evidence for this - exiting early makes it clearer
the memory isn't accessed.
*Details*
- Add MEMHEAD_LEN macro, avoids redundant NULL check.
- Use "UNLIKELY(..)" hint's for error cases
(freeing NULL pointer and checking if `leak_detector_has_run`).
Backend initialization needs to be delayed until after the OpenGL context
is created. This worked fine in foreground mode because the OpenGL context
already exists for the window at the point GPU_backend_init_once was called,
but not for background mode.
Create the backend just in time in GPU_context_create as before, and
automatically free it when the last context id discarded. But check if any
GPU backend is supported before creating the OpenGL context.
Ref D15463, D15465
For transparency, volume and light intersection rays, adjust these distances
rather than the ray start position. This way we increment the start distance
by the smallest possible float increment to avoid self intersections, and be
sure it works as the distance compared to be will be exactly the same as
before, due to the ray start position and direction remaining the same.
Fix T98764, T96537, hair ray tracing precision issues.
Differential Revision: https://developer.blender.org/D15455
This causes an assert with libepoxy, but was wrong already regardless.
Refactor logic to work as follows:
* GPU_exit() deletes backend resources
* Destroy UI GPU resources with the context active
* Call GPU_backend_exit() after deleting the context
Ref D15291
Differential Revision: https://developer.blender.org/D15465
An increased number of vertices is not a stopper for the surface
deform modifier anymore. It might still be useful to expose the
message in the UI, but printing error message to the console on
every modifier evaluation makes real errors to become almost
invisible.
Differential Revision: https://developer.blender.org/D15468
When rendering with headless builds, show an error instead of crashing.
Previously GPU_backend_init was called indirectly from
DRW_opengl_context_create, a new function is now called from the window
manager (GPU_backend_init_once), so it's possible to check if the GPU
has a back-end.
This also disables the `bgl` Python module when building WITH_HEADLESS.
Reviewed By: fclem
Ref D15463
This includes:
- new modifier names
It mostly uses `N_` because the strings are actually translated elsewhere.
The goal is simply to export them to .po files.
Most of the new translations were reported in T43295#1105335.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15418
The outliner would tagg all existing local IDs (for remap from linked
reference data to newly created overrides) when creating a new override.
This would become critical issue in case there is several existing
copies of the same override hierarchy (leading to several hierarchies
using the same override).
Further more, BKE override creation code would not systematically
properly remapp linked usages to new overrides one whithin the affected
override hierarchy, leading to potential undesired remaining usages of
linked data.
This was added for Metal, but also gives good results with CUDA and OptiX.
Also enable it for future Apple GPUs instead of only M1 and M2, since this has
been shown to help across multiple GPUs so the better bet seems to enable
rather than disable it.
Also moves some of the logic outside of the Metal device code, and always
enables the code in the kernel since other devices don't do dynamic compile.
Time per sample with OptiX + RTX A6000:
new old
barbershop_interior 0.0730s 0.0727s
bmw27 0.0047s 0.0053s
classroom 0.0428s 0.0464s
fishy_cat 0.0102s 0.0108s
junkshop 0.0366s 0.0395s
koro 0.0567s 0.0578s
monster 0.0206s 0.0223s
pabellon 0.0158s 0.0174s
sponza 0.0088s 0.0100s
spring 0.1267s 0.1280s
victor 0.0524s 0.0531s
wdas_cloud 0.0817s 0.0816s
Ref D15331, T87836
The Metal backend now compiles and caches a second set of kernels which are
optimized for scene contents, enabled for Apple Silicon.
The implementation supports doing this both for intersection and shading
kernels. However this is currently only enabled for intersection kernels that
are quick to compile, and already give a good speedup. Enabling this for
shading kernels would be faster still, however this also causes a long wait
times and would need a good user interface to control this.
M1 Max samples per minute (macOS 13.0):
PSO_GENERIC PSO_SPECIALIZED_INTERSECT PSO_SPECIALIZED_SHADE
barbershop_interior 83.4 89.5 93.7
bmw27 1486.1 1671.0 1825.8
classroom 175.2 196.8 206.3
fishy_cat 674.2 704.3 719.3
junkshop 205.4 212.0 257.7
koro 310.1 336.1 342.8
monster 376.7 418.6 424.1
pabellon 273.5 325.4 339.8
sponza 830.6 929.6 1142.4
victor 86.7 96.4 96.3
wdas_cloud 111.8 112.7 183.1
Code contributed by Jason Fielder, Morteza Mostajabodaveh and Michael Jones
Differential Revision: https://developer.blender.org/D14645
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
* Snap border to pixels just outside the drawn border, to more easily select
specific pixels by drawing a border inside them.
* Support cropped border renders.
Fix unreported: Resize with Constrain To Bounds will now limit one shared scale
value for both U and V instead of calculating separate scale values for each.
To fix T98061, the individual origins (transdata->center) is now used when
that mode is active.
See also: 0e9367fc29
Differential Revision: https://developer.blender.org/D15420
Was a bit oif a struggle since those functions take a first string which
is not our label, but should work fine now.
Reported/detected as part of D15418.
The goal of this change is to fix an increasing bottleneck of the event
queue handling when there is an operator bound to a key press event and
is taking longer to finish than a key-repeat speed on the system.
Practical example of when it happens is the marker tracking operator in
a single-frame track mode. Quite often artists will hold down Alt-arrow
to track a segment of footage which seems trivial to track. The issue
arises when the Alt-arrow is released: prior to this change it is was
possible that more frames will be tracked. It also seems that redraws
are less smooth.
It is a bit hard to make easily shareable computer-independent test
case. Instead, a synthetic case can be reproduced by adding a 50 ms
sleep in the `text_move_exec()`. In such synthetic case open a long
text in the text editor and hold left/right arrow button to navigate
the cursor. The observed behavior is that seemingly redraws happen
less and less often and cursor travels longer and longer distances
between redraws. The cursor will also keep moving after the buttons
has been released.
The proposed solution is to ignore sequential key-press events from
being added to the event queue. This seems to be the least intrusive
and the most safe approach:
- If the operator is fast enough there will be no multiple press events
in the queue in both prior and after of this change.
- If the operator is slow enough, clicking the button multiple times
(i.e. clicking arrow button 3 times in a heavy shot will change the
scene frame by exactly 3 frames because no events are ignored in
this case).
- Only do it for key press events, keeping mouse and tabled behavior
unchanged which is crucial for the paint mode.
Note that this is a bit different from the key repeat tracking and
filtering which is already implemented for keymaps as here we only want
to avoid the event queue build-up and do want to ignore all repeat
events. In other words: we do want to handle as many key presses as the
operator performance allows it without clogging anything.
A possible extension to this change could be a key press counter, so
that instead of ignoring the event we merge it into the last event in
the queue, incrementing some counter. This way if some operator really
needs to know exact number of key repeats it can still access it.
Differential Revision: https://developer.blender.org/D15444
For bit counts that were exact multiple of block size, the macro was
computing one block too much.
Reviewed By: Campbell Barton, Bastien Montagne
Differential Revision: https://developer.blender.org/D15454
In preparation for a larger change (D14162), some BLI_bitmap
functionality that could be submitted separately:
- Ability to declare a fixed size bitmap by-value, without extra
memory allocation: BLI_BITMAP_DECLARE
- Function to find the index of lowest unset bit:
BLI_bitmap_find_first_unset
- Test coverage of the above.
Reviewed By: Campbell Barton, Bastien Montagne
Differential Revision: https://developer.blender.org/D15454
Use const pointers to ImageSaveOptions and ImageFormatData for API
parameters where appropriate.
Differential Revision: https://developer.blender.org/D15400
It was smart enough to check if the buffer had the right
size but neglected to cast to a 64 bit value so it
overflowed.
Differential Revision: https://developer.blender.org/D15457
Reviewed By: brecht
We would first invoke the dragging, and then set the drag data (like the
ID or the dragged modifier), so the `wmDropBox.on_drag_start()` handler
wouldn't be able to access this. This broke dragging some IDs from the
Outliner, noticed in D15333.
It's now possible to first create/request drag data, extend it, and then
invoke the actual dragging. The normal function to start dragging
returns `void` now instead of `wmDrag *`, so the drag data can't easily
be modified after starting anymore.
* Don't nest "Show Recent Locations" and "Show System Locations" under a
"Defaults" heading. They are not just a default setting but completely
hide panels from the UI.
* Use own "Show Locations" heading instead, and remove redundant words
from labels.
* Move the options to the top of the panel, they are more general since
they can't be toggled in a File Browser session, and thus have bigger
impact.
We may want to remove these options in a future major release, I don't
think they are useful.
Agreed on with Pablo Vazquez.
When the solve is successful, the light sample needs to be updated since the
effective shading point is now on the last refractive interface. Spread was
not taken into account, creating false caustics.
Differential Revision: https://developer.blender.org/D15449
With choices Default, Lower Memory and Faster Render. For convenience, and
to help communicate what the various settings do.
Differential Revision: https://developer.blender.org/D15446
