Commit Graph

8 Commits

Author SHA1 Message Date
Bastien Montagne
4afb48acad Cleanup: Move internal guardedalloc headers to C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/124106
2024-07-03 16:04:18 +02:00
Campbell Barton
20b0805213 Cleanup: use const pointers where possible 2024-04-16 12:27:47 +10:00
Campbell Barton
e955c94ed3 License Headers: Set copyright to "Blender Authors", add AUTHORS
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.

While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.

Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.

Some directories in `./intern/` have also been excluded:

- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.

An "AUTHORS" file has been added, using the chromium projects authors
file as a template.

Design task: #110784

Ref !110783.
2023-08-16 00:20:26 +10:00
Campbell Barton
65f99397ec License headers: use SPDX-FileCopyrightText in all sources 2023-06-15 13:35:34 +10:00
Jacques Lucke
ae7163007d Allocator: improve protection against false sharing
On Apple Silicon, the cache line size is 128 bytes.
2023-01-06 13:04:49 +01:00
Campbell Barton
14fc02f91d Cleanup: spelling in comments 2023-01-06 14:00:36 +11:00
Jacques Lucke
862d08bb97 Fix: use-after-free when threadlocal is destructed after static variable
This issue was introduced in rB78f28b55d39288926634d0cc.

The fix is to use a `std::shared_ptr` to ensure that the `Global` will live
long enough until all `Local` objects are destructed.
2023-01-05 14:38:34 +01:00
Jacques Lucke
78f28b55d3 Allocator: improve multi-threaded allocation performance
Both, the guarded and lockfree allocator, are keeping track of current
and peak memory usage. Even the lockfree allocator used to use a
global atomic variable for the memory usage. When multiple threads
use the allocator at the same time, this variable is highly contended.
This can result in significant slowdowns as presented in D16862.

While specific cases could always be optimized by reducing the number
of allocations, having this synchronization point in functions used by
almost every part of Blender is not great.

The solution is use thread-local memory counters which are only added
together when the memory usage is actually requested. For more details
see in-code comments and D16862.

Differential Revision: https://developer.blender.org/D16862
2023-01-04 14:55:46 +01:00