tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/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.

363 lines
13 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-15 16:20:26 +02: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
*/
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 <mutex>
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
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
ParamsBuilder(const Signature &signature, const IndexMask &mask)
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
: signature_(&signature), mask_(mask), min_array_size_(mask.min_array_size())
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 signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
actual_params_.reserve(signature.params.size());
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
Functions: add utility methods to parameter builder
2021-08-20 11:43:54 +02:00
template<typename T> void add_readonly_single_input_value(T value, StringRef expected_name = "")
{
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
this->assert_current_param_type(ParamType::ForSingleInput(CPPType::get<T>()), expected_name);
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
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single{},
CPPType::get<T>(),
min_array_size_,
&value);
Functions: add utility methods to parameter builder
2021-08-20 11:43:54 +02:00
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
template<typename T> void add_readonly_single_input(const T *value, 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
{
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
this->assert_current_param_type(ParamType::ForSingleInput(CPPType::get<T>()), expected_name);
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
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single_ref{},
CPPType::get<T>(),
min_array_size_,
value);
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
}
void add_readonly_single_input(const GSpan span, StringRef expected_name = "")
{
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
this->assert_current_param_type(ParamType::ForSingleInput(span.type()), expected_name);
Functions: speedup preparing multi-function parameters My benchmark which spend most time preparing function parameters takes `250 ms` now, from `510 ms` before. This is mainly achieved by doing less unnecessary work and by giving the compiler more inlined code to optimize. * Reserve correct vector sizes and use unchecked `append` function. * Construct `GVArray` parameters directly in the vector, instead of moving/copying them in the vector afterwards. * Inline some constructors, because that allows the compiler understand what is happening, resulting in less code. This probably has negilible impact on the user experience currently, because there are other bottlenecks. Differential Revision: https://developer.blender.org/D15009
2022-05-31 20:41:01 +02:00
BLI_assert(span.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GVArray>, varray_tag::span{}, span);
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 adding a single input to a multi-function This is used by the upcoming new geometry nodes evaluator.
2021-05-13 13:23:53 +02:00
void add_readonly_single_input(GPointer value, StringRef expected_name = "")
{
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
this->assert_current_param_type(ParamType::ForSingleInput(*value.type()), expected_name);
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
actual_params_.append_unchecked_as(std::in_place_type<GVArray>,
varray_tag::single_ref{},
*value.type(),
min_array_size_,
value.get());
Functions: simplify adding a single input to a multi-function This is used by the upcoming new geometry nodes evaluator.
2021-05-13 13:23:53 +02:00
}
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
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
{
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
this->assert_current_param_type(ParamType::ForSingleInput(varray.type()), expected_name);
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
BLI_assert(varray.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GVArray>, std::move(varray));
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
void add_readonly_vector_input(const GVectorArray &vector_array, StringRef expected_name = "")
{
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
this->add_readonly_vector_input(
this->resource_scope().construct<GVVectorArray_For_GVectorArray>(vector_array),
expected_name);
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: add utility methods to parameter builder
2021-08-20 11:43:54 +02:00
void add_readonly_vector_input(const GSpan single_vector, StringRef expected_name = "")
{
this->add_readonly_vector_input(
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
this->resource_scope().construct<GVVectorArray_For_SingleGSpan>(single_vector,
min_array_size_),
Functions: add utility methods to parameter builder
2021-08-20 11:43:54 +02:00
expected_name);
}
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
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
{
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
this->assert_current_param_type(ParamType::ForVectorInput(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<const GVVectorArray *>, &ref);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
template<typename T> void add_uninitialized_single_output(T *value, StringRef expected_name = "")
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->add_uninitialized_single_output(GMutableSpan(CPPType::get<T>(), value, 1),
expected_name);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
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
{
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
this->assert_current_param_type(ParamType::ForSingleOutput(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, ref);
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
void add_ignored_single_output(StringRef expected_name = "")
{
this->assert_current_param_name(expected_name);
const int param_index = this->current_param_index();
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 ParamType &param_type = signature_->params[param_index].type;
BLI_assert(param_type.category() == ParamCategory::SingleOutput);
Cleanup: quiet dangling-reference warnings with GCC13
2023-05-10 04:06:27 +02:00
const DataType data_type = param_type.data_type();
const CPPType &type = data_type.single_type();
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
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);
}
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
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void add_vector_output(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
{
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
this->assert_current_param_type(ParamType::ForVectorOutput(vector_array.type()),
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(vector_array.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GVectorArray *>, &vector_array);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +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
{
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
this->assert_current_param_type(ParamType::ForMutableSingle(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GMutableSpan>, ref);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +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
{
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
this->assert_current_param_type(ParamType::ForMutableVector(vector_array.type()),
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(vector_array.size() >= 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
actual_params_.append_unchecked_as(std::in_place_type<GVectorArray *>, &vector_array);
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: 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
int next_param_index() const
{
return actual_params_.size();
}
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
GMutableSpan computed_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
{
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
BLI_assert(ELEM(signature_->params[param_index].type.category(),
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
ParamCategory::SingleOutput,
ParamCategory::SingleMutable));
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return std::get<GMutableSpan>(actual_params_[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
}
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
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
{
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
BLI_assert(ELEM(signature_->params[param_index].type.category(),
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
ParamCategory::VectorOutput,
ParamCategory::VectorMutable));
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return *std::get<GVectorArray *>(actual_params_[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
}
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
void assert_current_param_type(ParamType param_type, 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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
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
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
int param_index = this->current_param_index();
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
if (expected_name != "") {
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
StringRef actual_name = signature_->params[param_index].name;
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
BLI_assert(actual_name == expected_name);
}
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
ParamType expected_type = signature_->params[param_index].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
BLI_assert(expected_type == param_type);
#endif
}
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
void assert_current_param_name(StringRef expected_name)
{
UNUSED_VARS_NDEBUG(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
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
if (expected_name.is_empty()) {
return;
}
const int param_index = this->current_param_index();
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
StringRef actual_name = signature_->params[param_index].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
BLI_assert(actual_name == expected_name);
#endif
}
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
int current_param_index() const
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
return actual_params_.size();
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: 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
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 &resource_scope()
{
if (!scope_) {
scope_ = std::make_unique<ResourceScope>();
}
return *scope_;
}
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
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
template<typename T> VArray<T> 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
{
Geometry Nodes: refactor virtual array system Goals of this refactor: * Simplify creating virtual arrays. * Simplify passing virtual arrays around. * Simplify converting between typed and generic virtual arrays. * Reduce memory allocations. As a quick reminder, a virtual arrays is a data structure that behaves like an array (i.e. it can be accessed using an index). However, it may not actually be stored as array internally. The two most important implementations of virtual arrays are those that correspond to an actual plain array and those that have the same value for every index. However, many more implementations exist for various reasons (interfacing with legacy attributes, unified iterator over all points in multiple splines, ...). With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and `GVMutableArray`) can be used like "normal values". They typically live on the stack. Before, they were usually inside a `std::unique_ptr`. This makes passing them around much easier. Creation of new virtual arrays is also much simpler now due to some constructors. Memory allocations are reduced by making use of small object optimization inside the core types. Previously, `VArray` was a class with virtual methods that had to be overridden to change the behavior of a the virtual array. Now,`VArray` has a fixed size and has no virtual methods. Instead it contains a `VArrayImpl` that is similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly, unless a new virtual array implementation is added. To support the small object optimization for many `VArrayImpl` classes, a new `blender::Any` type is added. It is similar to `std::any` with two additional features. It has an adjustable inline buffer size and alignment. The inline buffer size of `std::any` can't be relied on and is usually too small for our use case here. Furthermore, `blender::Any` can store additional user-defined type information without increasing the stack size. Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
const GVArray &varray = this->readonly_single_input(param_index, name);
return varray.typed<T>();
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
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: 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
this->assert_correct_param(param_index, name, ParamCategory::SingleInput);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return std::get<GVArray>(builder_->actual_params_[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
}
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.
*/
bool single_output_is_required(int param_index, StringRef name = "")
{
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
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return !std::get<GMutableSpan>(builder_->actual_params_[param_index]).is_empty();
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>
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
MutableSpan<T> 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
{
return this->uninitialized_single_output(param_index, name).typed<T>();
}
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
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
{
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
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
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
BLI_assert(
!bool(builder_->signature_->params[param_index].flag & ParamFlag::SupportsUnusedOutput));
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
GMutableSpan span = std::get<GMutableSpan>(builder_->actual_params_[param_index]);
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
BLI_assert(span.size() >= builder_->min_array_size_);
return span;
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>
MutableSpan<T> uninitialized_single_output_if_required(int param_index, StringRef name = "")
{
return this->uninitialized_single_output_if_required(param_index, name).typed<T>();
}
GMutableSpan uninitialized_single_output_if_required(int param_index, StringRef name = "")
{
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
this->assert_correct_param(param_index, name, ParamCategory::SingleOutput);
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
BLI_assert(
bool(builder_->signature_->params[param_index].flag & ParamFlag::SupportsUnusedOutput));
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return std::get<GMutableSpan>(builder_->actual_params_[param_index]);
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>
const VVectorArray<T> &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
const GVVectorArray &vector_array = this->readonly_vector_input(param_index, name);
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
return builder_->resource_scope().construct<VVectorArray_For_GVVectorArray<T>>(vector_array);
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
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: 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
this->assert_correct_param(param_index, name, ParamCategory::VectorInput);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return *std::get<const GVVectorArray *>(builder_->actual_params_[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
}
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>
GVectorArray_TypedMutableRef<T> 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
{
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
return {this->vector_output(param_index, 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
}
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
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
{
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
this->assert_correct_param(param_index, name, ParamCategory::VectorOutput);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return *std::get<GVectorArray *>(builder_->actual_params_[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
}
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
template<typename T> MutableSpan<T> 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
{
return this->single_mutable(param_index, name).typed<T>();
}
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
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: 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
this->assert_correct_param(param_index, name, ParamCategory::SingleMutable);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return std::get<GMutableSpan>(builder_->actual_params_[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
}
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>
GVectorArray_TypedMutableRef<T> vector_mutable(int param_index, StringRef name = "")
Functions: Various improvements to the spans and generic data structures Most of this code is covered by unit tests.
2020-06-22 15:48:08 +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
return {this->vector_mutable(param_index, name)};
Functions: Various improvements to the spans and generic data structures Most of this code is covered by unit tests.
2020-06-22 15:48:08 +02:00
}
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
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
{
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
this->assert_correct_param(param_index, name, ParamCategory::VectorMutable);
Cleanup: use std::get instead of std::get_if `std::get` could not be used due to restrictions on macos. However, the minimum requirement has been lifted in {rB597aecc01644f0063fa4545dabadc5f73387e3d3}.
2023-01-14 14:16:51 +01:00
return *std::get<GVectorArray *>(builder_->actual_params_[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
}
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
void assert_correct_param(int param_index, StringRef name, ParamType param_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
{
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
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
BLI_assert(builder_->signature_->params[param_index].type == param_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
if (name.size() > 0) {
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
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
}
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
void assert_correct_param(int param_index, StringRef name, ParamCategory category)
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
{
UNUSED_VARS_NDEBUG(param_index, name, category);
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
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
BLI_assert(builder_->signature_->params[param_index].type.category() == category);
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
if (name.size() > 0) {
Functions: simplify multi-function signature type * `depends_on_context` was not used for a long time already. * `param_data_indices` is not used since rB42b88c008861b6. * The remaining data is moved to a single `Vector` to avoid having to do two allocations when the size signature becomes larger than fits into the inline buffer.
2023-01-07 16:51:26 +01:00
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
}
};
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