Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-04-26Geometry Nodes: refactor array devirtualizationJacques Lucke
Goals: * Better high level control over where devirtualization occurs. There is always a trade-off between performance and compile-time/binary-size. * Simplify using array devirtualization. * Better performance for cases where devirtualization wasn't used before. Many geometry nodes accept fields as inputs. Internally, that means that the execution functions have to accept so called "virtual arrays" as inputs. Those can be e.g. actual arrays, just single values, or lazily computed arrays. Due to these different possible virtual arrays implementations, access to individual elements is slower than it would be if everything was just a normal array (access does through a virtual function call). For more complex execution functions, this overhead does not matter, but for small functions (like a simple addition) it very much does. The virtual function call also prevents the compiler from doing some optimizations (e.g. loop unrolling and inserting simd instructions). The solution is to "devirtualize" the virtual arrays for small functions where the overhead is measurable. Essentially, the function is generated many times with different array types as input. Then there is a run-time dispatch that calls the best implementation. We have been doing devirtualization in e.g. math nodes for a long time already. This patch just generalizes the concept and makes it easier to control. It also makes it easier to investigate the different trade-offs when it comes to devirtualization. Nodes that we've optimized using devirtualization before didn't get a speedup. However, a couple of nodes are using devirtualization now, that didn't before. Those got a 2-4x speedup in common cases. * Map Range * Random Value * Switch * Combine XYZ Differential Revision: https://developer.blender.org/D14628
2022-02-11File headers: SPDX License migrationCampbell Barton
Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2020-08-07Code Style: use "#pragma once" in source directoryJacques Lucke
This replaces header include guards with `#pragma once`. A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`), because they are used in other places. This patch has been generated by P1561 followed by `make format`. Differential Revision: https://developer.blender.org/D8466
2020-07-12Functions: minor improvementsJacques Lucke
2020-07-03Cleanup: use nested namespacesJacques Lucke
2020-07-03Cleanup: use trailing underscore for non-public data membersJacques Lucke
2020-06-22Functions: Various improvements to the spans and generic data structuresJacques Lucke
Most of this code is covered by unit tests.
2020-06-16Functions: Multi FunctionJacques Lucke
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