griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
2db026ef67bc66f951dc45ccba37544c200e94de
test/source/blender/functions/FN_multi_function_params.hh

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

464 lines
17 KiB
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 */
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
#pragma once
/** \file
* \ingroup fn
*
Cleanup: remove MF prefix from some classes in multi-function namespace This was missing in rBeedcf1876a6651c38d8f4daa2e65d1fb81f77c5d.
2023-01-14 15:42:52 +01:00
* This file provides an Params and ParamsBuilder structure.
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02: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
* `ParamsBuilder` is used by a function caller to be prepare all parameters that are passed into
Cleanup: remove MF prefix from some classes in multi-function namespace This was missing in rBeedcf1876a6651c38d8f4daa2e65d1fb81f77c5d.
2023-01-14 15:42:52 +01:00
* the function. `Params` is then used inside the called function to access the parameters.
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
*/
Functions: simplify multi-function parameters The use of `std::variant` allows combining the four vectors into one which more closely matches the intend and avoids a workaround used before. Note that this uses `std::get_if` instead of `std::get` because `std::get` is only available since macOS 10.14.
2023-01-06 11:50:56 +01:00
#include <variant>
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
BLI: move generic data structures to blenlib This is a follow up to rB2252bc6a5527cd7360d1ccfe7a2d1bc640a8dfa6.
2022-03-19 08:26:29 +01:00
#include "BLI_generic_pointer.hh"
#include "BLI_generic_vector_array.hh"
#include "BLI_generic_virtual_vector_array.hh"
BLI: rename resource collector to resource scope Differential Revision: https://developer.blender.org/D10857
2021-04-01 15:55:08 +02:00
#include "BLI_resource_scope.hh"
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
#include "FN_multi_function_signature.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 {
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02: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
class ParamsBuilder {
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
private:
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
std::unique_ptr<ResourceScope> scope_;
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
const Signature *signature_;
BLI: refactor IndexMask for better performance and memory usage Goals of this refactor: * Reduce memory consumption of `IndexMask`. The old `IndexMask` uses an `int64_t` for each index which is more than necessary in pretty much all practical cases currently. Using `int32_t` might still become limiting in the future in case we use this to index e.g. byte buffers larger than a few gigabytes. We also don't want to template `IndexMask`, because that would cause a split in the "ecosystem", or everything would have to be implemented twice or templated. * Allow for more multi-threading. The old `IndexMask` contains a single array. This is generally good but has the problem that it is hard to fill from multiple-threads when the final size is not known from the beginning. This is commonly the case when e.g. converting an array of bool to an index mask. Currently, this kind of code only runs on a single thread. * Allow for efficient set operations like join, intersect and difference. It should be possible to multi-thread those operations. * It should be possible to iterate over an `IndexMask` very efficiently. The most important part of that is to avoid all memory access when iterating over continuous ranges. For some core nodes (e.g. math nodes), we generate optimized code for the cases of irregular index masks and simple index ranges. To achieve these goals, a few compromises had to made: * Slicing of the mask (at specific indices) and random element access is `O(log #indices)` now, but with a low constant factor. It should be possible to split a mask into n approximately equally sized parts in `O(n)` though, making the time per split `O(1)`. * Using range-based for loops does not work well when iterating over a nested data structure like the new `IndexMask`. Therefor, `foreach_*` functions with callbacks have to be used. To avoid extra code complexity at the call site, the `foreach_*` methods support multi-threading out of the box. The new data structure splits an `IndexMask` into an arbitrary number of ordered `IndexMaskSegment`. Each segment can contain at most `2^14 = 16384` indices. The indices within a segment are stored as `int16_t`. Each segment has an additional `int64_t` offset which allows storing arbitrary `int64_t` indices. This approach has the main benefits that segments can be processed/constructed individually on multiple threads without a serial bottleneck. Also it reduces the memory requirements significantly. For more details see comments in `BLI_index_mask.hh`. I did a few tests to verify that the data structure generally improves performance and does not cause regressions: * Our field evaluation benchmarks take about as much as before. This is to be expected because we already made sure that e.g. add node evaluation is vectorized. The important thing here is to check that changes to the way we iterate over the indices still allows for auto-vectorization. * Memory usage by a mask is about 1/4 of what it was before in the average case. That's mainly caused by the switch from `int64_t` to `int16_t` for indices. In the worst case, the memory requirements can be larger when there are many indices that are very far away. However, when they are far away from each other, that indicates that there aren't many indices in total. In common cases, memory usage can be way lower than 1/4 of before, because sub-ranges use static memory. * For some more specific numbers I benchmarked `IndexMask::from_bools` in `index_mask_from_selection` on 10.000.000 elements at various probabilities for `true` at every index: ``` Probability Old New 0 4.6 ms 0.8 ms 0.001 5.1 ms 1.3 ms 0.2 8.4 ms 1.8 ms 0.5 15.3 ms 3.0 ms 0.8 20.1 ms 3.0 ms 0.999 25.1 ms 1.7 ms 1 13.5 ms 1.1 ms ``` Pull Request: https://projects.blender.org/blender/blender/pulls/104629
2023-05-24 18:11:41 +02:00
const IndexMask &mask_;
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int64_t min_array_size_;
Functions: simplify multi-function parameters The use of `std::variant` allows combining the four vectors into one which more closely matches the intend and avoids a workaround used before. Note that this uses `std::get_if` instead of `std::get` because `std::get` is only available since macOS 10.14.
2023-01-06 11:50:56 +01:00
Vector<std::variant<GVArray, GMutableSpan, const GVVectorArray *, GVectorArray *>>
actual_params_;
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: remove MF prefix from some classes in multi-function namespace This was missing in rBeedcf1876a6651c38d8f4daa2e65d1fb81f77c5d.
2023-01-14 15:42:52 +01:00
friend class Params;
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
ParamsBuilder(const Signature &signature, const IndexMask &mask);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Functions: support optional outputs in multi-function Sometimes not all outputs of a multi-function are required by the caller. In those cases it would be a waste of compute resources to calculate the unused values anyway. Now, the caller of a multi-function can specify when a specific output is not used. The called function can check if an output is unused and may ignore it. Multi-functions can still computed unused outputs as before if they don't want to check if a specific output is unused. The multi-function procedure system has been updated to support ignored outputs in call instructions. An ignored output just has no variable assigned to it. The field system has been updated to generate a multi-function procedure where unused outputs are ignored.
2021-09-14 14:52:44 +02:00
public:
/**
* The indices referenced by the #mask has to live longer than the params builder. This is
* because the it might have to destruct elements for all masked indices in the end.
*/
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
ParamsBuilder(const class MultiFunction &fn, const IndexMask *mask);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
template<typename T> void add_readonly_single_input_value(T value, StringRef expected_name = "");
template<typename T>
void add_readonly_single_input(const T *value, StringRef expected_name = "");
void add_readonly_single_input(const GSpan span, StringRef expected_name = "");
void add_readonly_single_input(GPointer value, StringRef expected_name = "");
void add_readonly_single_input(GVArray varray, StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void add_readonly_vector_input(const GVectorArray &vector_array, StringRef expected_name = "");
void add_readonly_vector_input(const GSpan single_vector, StringRef expected_name = "");
void add_readonly_vector_input(const GVVectorArray &ref, StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
template<typename T>
void add_uninitialized_single_output(T *value, StringRef expected_name = "");
void add_uninitialized_single_output(GMutableSpan ref, StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void add_ignored_single_output(StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void add_vector_output(GVectorArray &vector_array, StringRef expected_name = "");
Geometry Nodes: refactor storage for socket values This refactors `SocketValueVariant` with the following goals in mind: * Support type erasure so that not all users of `SocketValueVariant` have to know about all the types sockets can have. * Move towards supporting "rainbow sockets" which are sockets whoose type is only known at run-time. * Reduce complexity when dealing with socket values in general. Previously, one had to use `SocketValueVariantCPPType` a lot to manage uninitialized memory. This is better abstracted away now. One related change that I had to do that I didn't see coming at first was that I had to refactor `set_default_remaining_outputs` because now the default value of a `SocketValueVariant` would not contain any value. Previously, it was initialized the zero-value of the template parameter. Similarly, I had to change how implicit conversions are created, because comparing the `CPPType` of linked sockets was not enough anymore to determine if a conversion is necessary. We could potentially use `SocketValueVariant` for the remaining socket types in the future as well. Not entirely sure if that helps yet. `SocketValueVariant` can easily be adapted to make that work though. That would also justify the name "SocketValueVariant" better. Pull Request: https://projects.blender.org/blender/blender/pulls/116231
2023-12-17 14:00:07 +01:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void add_single_mutable(GMutableSpan ref, StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void add_vector_mutable(GVectorArray &vector_array, StringRef expected_name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
int next_param_index() const;
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
GMutableSpan computed_array(int param_index);
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
GVectorArray &computed_vector_array(int param_index);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
private:
void assert_current_param_type(ParamType param_type, StringRef expected_name = "");
void assert_current_param_name(StringRef expected_name);
Functions: support optional outputs in multi-function Sometimes not all outputs of a multi-function are required by the caller. In those cases it would be a waste of compute resources to calculate the unused values anyway. Now, the caller of a multi-function can specify when a specific output is not used. The called function can check if an output is unused and may ignore it. Multi-functions can still computed unused outputs as before if they don't want to check if a specific output is unused. The multi-function procedure system has been updated to support ignored outputs in call instructions. An ignored output just has no variable assigned to it. The field system has been updated to generate a multi-function procedure where unused outputs are ignored.
2021-09-14 14:52:44 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
int current_param_index() const;
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
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
ResourceScope &resource_scope();
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
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 add_unused_output_for_unsupporting_function(const CPPType &type);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
};
Cleanup: remove MF prefix from some classes in multi-function namespace This was missing in rBeedcf1876a6651c38d8f4daa2e65d1fb81f77c5d.
2023-01-14 15:42:52 +01:00
class Params {
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
private:
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
ParamsBuilder *builder_;
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
public:
Clang-Format: Allow empty functions to be single-line For example ``` OIIOOutputDriver::~OIIOOutputDriver() { } ``` becomes ``` OIIOOutputDriver::~OIIOOutputDriver() {} ``` Saves quite some vertical space, which is especially handy for constructors. Pull Request: https://projects.blender.org/blender/blender/pulls/105594
2023-03-29 16:50:54 +02:00
Params(ParamsBuilder &builder) : builder_(&builder) {}
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
template<typename T> VArray<T> readonly_single_input(int param_index, StringRef name = "");
const GVArray &readonly_single_input(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Functions: support optional outputs in multi-function Sometimes not all outputs of a multi-function are required by the caller. In those cases it would be a waste of compute resources to calculate the unused values anyway. Now, the caller of a multi-function can specify when a specific output is not used. The called function can check if an output is unused and may ignore it. Multi-functions can still computed unused outputs as before if they don't want to check if a specific output is unused. The multi-function procedure system has been updated to support ignored outputs in call instructions. An ignored output just has no variable assigned to it. The field system has been updated to generate a multi-function procedure where unused outputs are ignored.
2021-09-14 14:52:44 +02:00
/**
* \return True when the caller provided a buffer for this output parameter. This allows the
* called multi-function to skip some computation. It is still valid to call
* #uninitialized_single_output when this returns false. In this case a new temporary buffer is
* allocated.
*/
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
bool single_output_is_required(int param_index, StringRef name = "");
Functions: support optional outputs in multi-function Sometimes not all outputs of a multi-function are required by the caller. In those cases it would be a waste of compute resources to calculate the unused values anyway. Now, the caller of a multi-function can specify when a specific output is not used. The called function can check if an output is unused and may ignore it. Multi-functions can still computed unused outputs as before if they don't want to check if a specific output is unused. The multi-function procedure system has been updated to support ignored outputs in call instructions. An ignored output just has no variable assigned to it. The field system has been updated to generate a multi-function procedure where unused outputs are ignored.
2021-09-14 14:52:44 +02:00
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
template<typename T>
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
MutableSpan<T> uninitialized_single_output(int param_index, StringRef name = "");
GMutableSpan uninitialized_single_output(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Geometry Nodes: support Noise Texture node This makes the Noise Texture node available in geometry nodes. It should behave the same as in shader node, with the exception that it does not have an implicit position input yet. That will be added separately. Differential Revision: https://developer.blender.org/D12467
2021-09-20 13:12:25 +02:00
/**
* Same as #uninitialized_single_output, but returns an empty span when the output is not
* required.
*/
template<typename T>
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
MutableSpan<T> uninitialized_single_output_if_required(int param_index, StringRef name = "");
GMutableSpan uninitialized_single_output_if_required(int param_index, StringRef name = "");
Geometry Nodes: support Noise Texture node This makes the Noise Texture node available in geometry nodes. It should behave the same as in shader node, with the exception that it does not have an implicit position input yet. That will be added separately. Differential Revision: https://developer.blender.org/D12467
2021-09-20 13:12:25 +02:00
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
template<typename T>
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
const VVectorArray<T> &readonly_vector_input(int param_index, StringRef name = "");
const GVVectorArray &readonly_vector_input(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
template<typename T>
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
GVectorArray_TypedMutableRef<T> vector_output(int param_index, StringRef name = "");
GVectorArray &vector_output(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
template<typename T> MutableSpan<T> single_mutable(int param_index, StringRef name = "");
GMutableSpan single_mutable(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
template<typename T>
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
GVectorArray_TypedMutableRef<T> vector_mutable(int param_index, StringRef name = "");
GVectorArray &vector_mutable(int param_index, StringRef name = "");
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
private:
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
void assert_correct_param(int param_index, StringRef name, ParamType param_type);
void assert_correct_param(int param_index, StringRef name, ParamCategory category);
};
/* -------------------------------------------------------------------- */
/** \name #Paramsbuilder Inline Methods
* \{ */
inline ParamsBuilder::ParamsBuilder(const Signature &signature, const IndexMask &mask)
: signature_(&signature), mask_(mask), min_array_size_(mask.min_array_size())
{
actual_params_.reserve(signature.params.size());
}
template<typename T>
inline void ParamsBuilder::add_readonly_single_input_value(T value, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleInput(CPPType::get<T>()), expected_name);
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single{},
CPPType::get<T>(),
min_array_size_,
&value);
}
template<typename T>
inline void ParamsBuilder::add_readonly_single_input(const T *value, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleInput(CPPType::get<T>()), expected_name);
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single_ref{},
CPPType::get<T>(),
min_array_size_,
value);
}
inline void ParamsBuilder::add_readonly_single_input(const GSpan span, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleInput(span.type()), expected_name);
BLI_assert(span.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GVArray>, varray_tag::span{}, span);
}
inline void ParamsBuilder::add_readonly_single_input(GPointer value, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleInput(*value.type()), expected_name);
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single_ref{},
*value.type(),
min_array_size_,
value.get());
}
inline void ParamsBuilder::add_readonly_single_input(GVArray varray, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleInput(varray.type()), expected_name);
BLI_assert(varray.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GVArray>, std::move(varray));
}
inline void ParamsBuilder::add_readonly_vector_input(const GVectorArray &vector_array,
StringRef expected_name)
{
this->add_readonly_vector_input(
this->resource_scope().construct<GVVectorArray_For_GVectorArray>(vector_array),
expected_name);
}
inline void ParamsBuilder::add_readonly_vector_input(const GSpan single_vector,
StringRef expected_name)
{
this->add_readonly_vector_input(this->resource_scope().construct<GVVectorArray_For_SingleGSpan>(
single_vector, min_array_size_),
expected_name);
}
inline void ParamsBuilder::add_readonly_vector_input(const GVVectorArray &ref,
StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForVectorInput(ref.type()), expected_name);
BLI_assert(ref.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<const GVVectorArray *>, &ref);
}
template<typename T>
inline void ParamsBuilder::add_uninitialized_single_output(T *value, StringRef expected_name)
{
this->add_uninitialized_single_output(GMutableSpan(CPPType::get<T>(), value, 1), expected_name);
}
inline void ParamsBuilder::add_uninitialized_single_output(GMutableSpan ref,
StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForSingleOutput(ref.type()), expected_name);
BLI_assert(ref.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, ref);
}
inline void ParamsBuilder::add_ignored_single_output(StringRef expected_name)
{
this->assert_current_param_name(expected_name);
const int param_index = this->current_param_index();
const ParamType &param_type = signature_->params[param_index].type;
BLI_assert(param_type.category() == ParamCategory::SingleOutput);
const DataType data_type = param_type.data_type();
const CPPType &type = data_type.single_type();
if (bool(signature_->params[param_index].flag & ParamFlag::SupportsUnusedOutput)) {
/* An empty span indicates that this is ignored. */
const GMutableSpan dummy_span{type};
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, dummy_span);
}
else {
this->add_unused_output_for_unsupporting_function(type);
}
}
inline void ParamsBuilder::add_vector_output(GVectorArray &vector_array, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForVectorOutput(vector_array.type()), expected_name);
BLI_assert(vector_array.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GVectorArray *>, &vector_array);
}
inline void ParamsBuilder::add_single_mutable(GMutableSpan ref, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForMutableSingle(ref.type()), expected_name);
BLI_assert(ref.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, ref);
}
inline void ParamsBuilder::add_vector_mutable(GVectorArray &vector_array, StringRef expected_name)
{
this->assert_current_param_type(ParamType::ForMutableVector(vector_array.type()), expected_name);
BLI_assert(vector_array.size() >= min_array_size_);
actual_params_.append_unchecked_as(std::in_place_type<GVectorArray *>, &vector_array);
}
inline int ParamsBuilder::next_param_index() const
{
return actual_params_.size();
}
inline GMutableSpan ParamsBuilder::computed_array(int param_index)
{
BLI_assert(ELEM(signature_->params[param_index].type.category(),
ParamCategory::SingleOutput,
ParamCategory::SingleMutable));
return std::get<GMutableSpan>(actual_params_[param_index]);
}
inline GVectorArray &ParamsBuilder::computed_vector_array(int param_index)
{
BLI_assert(ELEM(signature_->params[param_index].type.category(),
ParamCategory::VectorOutput,
ParamCategory::VectorMutable));
return *std::get<GVectorArray *>(actual_params_[param_index]);
}
inline void ParamsBuilder::assert_current_param_type(ParamType param_type, StringRef expected_name)
{
UNUSED_VARS_NDEBUG(param_type, expected_name);
Build: replace Blender specific DEBUG by standard NDEBUG NDEBUG is part of the C standard and disables asserts. Only this will now be used to decide if asserts are enabled. DEBUG was a Blender specific define, that has now been removed. _DEBUG is a Visual Studio define for builds in Debug configuration. Blender defines this for all platforms. This is still used in a few places in the draw code, and in external libraries Bullet and Mantaflow. Pull Request: https://projects.blender.org/blender/blender/pulls/115774
2023-12-04 15:13:06 +01:00
#ifndef NDEBUG
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
int param_index = this->current_param_index();
if (expected_name != "") {
StringRef actual_name = signature_->params[param_index].name;
BLI_assert(actual_name == expected_name);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
}
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
ParamType expected_type = signature_->params[param_index].type;
BLI_assert(expected_type == param_type);
#endif
}
inline void ParamsBuilder::assert_current_param_name(StringRef expected_name)
{
UNUSED_VARS_NDEBUG(expected_name);
#ifndef NDEBUG
if (expected_name.is_empty()) {
return;
}
const int param_index = this->current_param_index();
StringRef actual_name = signature_->params[param_index].name;
BLI_assert(actual_name == expected_name);
#endif
}
inline int ParamsBuilder::current_param_index() const
{
return actual_params_.size();
}
inline ResourceScope &ParamsBuilder::resource_scope()
{
if (!scope_) {
scope_ = std::make_unique<ResourceScope>();
}
return *scope_;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name #Params Inline Methods
* \{ */
template<typename T>
inline VArray<T> Params::readonly_single_input(int param_index, StringRef name)
{
const GVArray &varray = this->readonly_single_input(param_index, name);
return varray.typed<T>();
}
inline const GVArray &Params::readonly_single_input(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::SingleInput);
return std::get<GVArray>(builder_->actual_params_[param_index]);
}
inline bool Params::single_output_is_required(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
return !std::get<GMutableSpan>(builder_->actual_params_[param_index]).is_empty();
}
template<typename T>
inline MutableSpan<T> Params::uninitialized_single_output(int param_index, StringRef name)
{
return this->uninitialized_single_output(param_index, name).typed<T>();
}
inline GMutableSpan Params::uninitialized_single_output(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
BLI_assert(
!bool(builder_->signature_->params[param_index].flag & ParamFlag::SupportsUnusedOutput));
GMutableSpan span = std::get<GMutableSpan>(builder_->actual_params_[param_index]);
BLI_assert(span.size() >= builder_->min_array_size_);
return span;
}
template<typename T>
inline MutableSpan<T> Params::uninitialized_single_output_if_required(int param_index,
StringRef name)
{
return this->uninitialized_single_output_if_required(param_index, name).typed<T>();
}
inline GMutableSpan Params::uninitialized_single_output_if_required(int param_index,
StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
BLI_assert(
bool(builder_->signature_->params[param_index].flag & ParamFlag::SupportsUnusedOutput));
return std::get<GMutableSpan>(builder_->actual_params_[param_index]);
}
template<typename T>
inline const VVectorArray<T> &Params::readonly_vector_input(int param_index, StringRef name)
{
const GVVectorArray &vector_array = this->readonly_vector_input(param_index, name);
return builder_->resource_scope().construct<VVectorArray_For_GVVectorArray<T>>(vector_array);
}
inline const GVVectorArray &Params::readonly_vector_input(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::VectorInput);
return *std::get<const GVVectorArray *>(builder_->actual_params_[param_index]);
}
template<typename T>
inline GVectorArray_TypedMutableRef<T> Params::vector_output(int param_index, StringRef name)
{
return {this->vector_output(param_index, name)};
}
inline GVectorArray &Params::vector_output(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::VectorOutput);
return *std::get<GVectorArray *>(builder_->actual_params_[param_index]);
}
template<typename T> inline MutableSpan<T> Params::single_mutable(int param_index, StringRef name)
{
return this->single_mutable(param_index, name).typed<T>();
}
inline GMutableSpan Params::single_mutable(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::SingleMutable);
return std::get<GMutableSpan>(builder_->actual_params_[param_index]);
}
template<typename T>
inline GVectorArray_TypedMutableRef<T> Params::vector_mutable(int param_index, StringRef name)
{
return {this->vector_mutable(param_index, name)};
}
inline GVectorArray &Params::vector_mutable(int param_index, StringRef name)
{
this->assert_correct_param(param_index, name, ParamCategory::VectorMutable);
return *std::get<GVectorArray *>(builder_->actual_params_[param_index]);
}
inline void Params::assert_correct_param(int param_index, StringRef name, ParamType param_type)
{
UNUSED_VARS_NDEBUG(param_index, name, param_type);
Build: replace Blender specific DEBUG by standard NDEBUG NDEBUG is part of the C standard and disables asserts. Only this will now be used to decide if asserts are enabled. DEBUG was a Blender specific define, that has now been removed. _DEBUG is a Visual Studio define for builds in Debug configuration. Blender defines this for all platforms. This is still used in a few places in the draw code, and in external libraries Bullet and Mantaflow. Pull Request: https://projects.blender.org/blender/blender/pulls/115774
2023-12-04 15:13:06 +01:00
#ifndef NDEBUG
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
BLI_assert(builder_->signature_->params[param_index].type == param_type);
if (name.size() > 0) {
BLI_assert(builder_->signature_->params[param_index].name == name);
}
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
#endif
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
}
inline void Params::assert_correct_param(int param_index, StringRef name, ParamCategory category)
{
UNUSED_VARS_NDEBUG(param_index, name, category);
#ifndef NDEBUG
BLI_assert(builder_->signature_->params[param_index].type.category() == category);
if (name.size() > 0) {
BLI_assert(builder_->signature_->params[param_index].name == name);
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
}
Cleanup: move inline method definitions out of class This makes it easier to scan the API.
2024-08-29 13:43:22 +02:00
#endif
}
/** \} */
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02: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