griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
2db026ef67bc66f951dc45ccba37544c200e94de
test2/source/blender/functions/intern/multi_function_params.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
731 B
C++
Raw Normal View History

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
/* SPDX-FileCopyrightText: 2023 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
Geometry Nodes: refactor multi-threading in field evaluation Previously, there was a fixed grain size for all multi-functions. That was not sufficient because some functions could benefit a lot from smaller grain sizes. This refactors adds a new `MultiFunction::call_auto` method which has the same effect as just calling `MultiFunction::call` but additionally figures out how to execute the specific multi-function efficiently. It determines a good grain size and decides whether the mask indices should be shifted or not. Most multi-function evaluations benefit from this, but medium sized work loads (1000 - 50000 elements) benefit from it the most. Especially when expensive multi-functions (e.g. noise) is involved. This is because for smaller work loads, threading is rarely used and for larger work loads threading worked fine before already. With this patch, multi-functions can specify execution hints, that allow the caller to execute it most efficiently. These execution hints still have to be added to more functions. Some performance measurements of a field evaluation involving noise and math nodes, ordered by the number of elements being evaluated: ``` 1,000,000: 133 ms -> 120 ms 100,000: 30 ms -> 18 ms 10,000: 20 ms -> 2.7 ms 1,000: 4 ms -> 0.5 ms 100: 0.5 ms -> 0.4 ms ```
2021-11-26 11:05:47 +01:00
#include "FN_multi_function_params.hh"
Functions: introduce multi-function namespace This moves all multi-function related code in the `functions` module into a new `multi_function` namespace. This is similar to how there is a `lazy_function` namespace. The main benefit of this is that many types names that were prefixed with `MF` (for "multi function") can be simplified. There is also a common shorthand for the `multi_function` namespace: `mf`. This is also similar to lazy-functions where the shortened namespace is called `lf`.
2023-01-07 17:32:28 +01:00
namespace blender::fn::multi_function {
Geometry Nodes: refactor multi-threading in field evaluation Previously, there was a fixed grain size for all multi-functions. That was not sufficient because some functions could benefit a lot from smaller grain sizes. This refactors adds a new `MultiFunction::call_auto` method which has the same effect as just calling `MultiFunction::call` but additionally figures out how to execute the specific multi-function efficiently. It determines a good grain size and decides whether the mask indices should be shifted or not. Most multi-function evaluations benefit from this, but medium sized work loads (1000 - 50000 elements) benefit from it the most. Especially when expensive multi-functions (e.g. noise) is involved. This is because for smaller work loads, threading is rarely used and for larger work loads threading worked fine before already. With this patch, multi-functions can specify execution hints, that allow the caller to execute it most efficiently. These execution hints still have to be added to more functions. Some performance measurements of a field evaluation involving noise and math nodes, ordered by the number of elements being evaluated: ``` 1,000,000: 133 ms -> 120 ms 100,000: 30 ms -> 18 ms 10,000: 20 ms -> 2.7 ms 1,000: 4 ms -> 0.5 ms 100: 0.5 ms -> 0.4 ms ```
2021-11-26 11:05:47 +01:00
Functions: improve handling of unused multi-function outputs Previously, `ParamsBuilder` lazily allocated an array for an output when it was unused, but the called multi-function wanted to access it. Now, whether the multi-function supports an output to be unused is part of the signature. This way, the allocation can happen earlier when the parameters are build. The benefit is that this makes all methods of `MFParams` thread-safe again, removing the need for a mutex.
2023-01-14 15:35:44 +01:00
void ParamsBuilder::add_unused_output_for_unsupporting_function(const CPPType &type)
Geometry Nodes: refactor multi-threading in field evaluation Previously, there was a fixed grain size for all multi-functions. That was not sufficient because some functions could benefit a lot from smaller grain sizes. This refactors adds a new `MultiFunction::call_auto` method which has the same effect as just calling `MultiFunction::call` but additionally figures out how to execute the specific multi-function efficiently. It determines a good grain size and decides whether the mask indices should be shifted or not. Most multi-function evaluations benefit from this, but medium sized work loads (1000 - 50000 elements) benefit from it the most. Especially when expensive multi-functions (e.g. noise) is involved. This is because for smaller work loads, threading is rarely used and for larger work loads threading worked fine before already. With this patch, multi-functions can specify execution hints, that allow the caller to execute it most efficiently. These execution hints still have to be added to more functions. Some performance measurements of a field evaluation involving noise and math nodes, ordered by the number of elements being evaluated: ``` 1,000,000: 133 ms -> 120 ms 100,000: 30 ms -> 18 ms 10,000: 20 ms -> 2.7 ms 1,000: 4 ms -> 0.5 ms 100: 0.5 ms -> 0.4 ms ```
2021-11-26 11:05:47 +01:00
{
Functions: only allocate resource scope when it is actually used In most cases it is currently not used, so always having it there causes unnecessary overhead. In my test file that causes a 2 % performance improvement.
2023-01-14 15:56:43 +01:00
ResourceScope &scope = this->resource_scope();
Cleanup: simplify allocating buffers for a CPPType This reduces verbosity when using `LinearAllocator` or `ResourceScope` to allocate values for a `CPPType`. Now, this is simplified and one also does not have to manually add a destructor call anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/137685
2025-04-17 22:01:07 +02:00
void *buffer = scope.allocator().allocate_array(type, min_array_size_);
Functions: improve handling of unused multi-function outputs Previously, `ParamsBuilder` lazily allocated an array for an output when it was unused, but the called multi-function wanted to access it. Now, whether the multi-function supports an output to be unused is part of the signature. This way, the allocation can happen earlier when the parameters are build. The benefit is that this makes all methods of `MFParams` thread-safe again, removing the need for a mutex.
2023-01-14 15:35:44 +01:00
const GMutableSpan span{type, buffer, min_array_size_};
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, span);
Refactor: BLI: Make some CPPType properties public instead of using methods This makes accessing these properties more convenient. Since we only ever have const references to `CPPType`, there isn't really a benefit to using methods to avoid mutation. Pull Request: https://projects.blender.org/blender/blender/pulls/137482
2025-04-14 17:48:17 +02:00
if (!type.is_trivially_destructible) {
Functions: only allocate resource scope when it is actually used In most cases it is currently not used, so always having it there causes unnecessary overhead. In my test file that causes a 2 % performance improvement.
2023-01-14 15:56:43 +01:00
scope.add_destruct_call(
Functions: improve handling of unused multi-function outputs Previously, `ParamsBuilder` lazily allocated an array for an output when it was unused, but the called multi-function wanted to access it. Now, whether the multi-function supports an output to be unused is part of the signature. This way, the allocation can happen earlier when the parameters are build. The benefit is that this makes all methods of `MFParams` thread-safe again, removing the need for a mutex.
2023-01-14 15:35:44 +01:00
[&type, buffer, mask = mask_]() { type.destruct_indices(buffer, mask); });
Geometry Nodes: refactor multi-threading in field evaluation Previously, there was a fixed grain size for all multi-functions. That was not sufficient because some functions could benefit a lot from smaller grain sizes. This refactors adds a new `MultiFunction::call_auto` method which has the same effect as just calling `MultiFunction::call` but additionally figures out how to execute the specific multi-function efficiently. It determines a good grain size and decides whether the mask indices should be shifted or not. Most multi-function evaluations benefit from this, but medium sized work loads (1000 - 50000 elements) benefit from it the most. Especially when expensive multi-functions (e.g. noise) is involved. This is because for smaller work loads, threading is rarely used and for larger work loads threading worked fine before already. With this patch, multi-functions can specify execution hints, that allow the caller to execute it most efficiently. These execution hints still have to be added to more functions. Some performance measurements of a field evaluation involving noise and math nodes, ordered by the number of elements being evaluated: ``` 1,000,000: 133 ms -> 120 ms 100,000: 30 ms -> 18 ms 10,000: 20 ms -> 2.7 ms 1,000: 4 ms -> 0.5 ms 100: 0.5 ms -> 0.4 ms ```
2021-11-26 11:05:47 +01:00
}
}
Functions: introduce multi-function namespace This moves all multi-function related code in the `functions` module into a new `multi_function` namespace. This is similar to how there is a `lazy_function` namespace. The main benefit of this is that many types names that were prefixed with `MF` (for "multi function") can be simplified. There is also a common shorthand for the `multi_function` namespace: `mf`. This is also similar to lazy-functions where the shortened namespace is called `lf`.
2023-01-07 17:32:28 +01:00
} // namespace blender::fn::multi_function
Reference in New Issue Copy Permalink