These tests check performances of ID python wrapper creation (these are
cached), regular RNA struct wrapper creation, acess to IDProperties,
(un)registering of py-defined PropertyGroup, and access to py-defined
properties (without and without custom get/set).
The goal of these tests is mainly to follow performances impact of
on-going refactors and improvements in the BPY/RNA area.
The EEVEE performance tests call scene.frame_set at the end of the warmup stage, which recursively
calls frame_change_handler. Eventually, this leads to a RecursionError. This PR adds a guard for
checking if frame_set is currently active and returns early for this recursive call of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/143203
The EEVEE performance tests wait for shader compilation to finish before
beginning to record performance. However, shader compilation can also
happen after the first frame. This PR adds a check to the warmup phase
to see if shader compilation is still happening. This happens, e.g., for
the Mr. Elephant demo scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/143690
This commit adds a minimum number of frames tested in the EEVEE
performance tests (`tests/performance/tests/eevee.py`). This way,
test results are more reliable for .blend files with a low number of
animation frames.
Pull Request: https://projects.blender.org/blender/blender/pulls/141290
**Problem Description**
Blender's current mesh data layout often lacks spatial coherence,
causing performance bottlenecks during BVH construction for sculpting
and painting operations. Each time a BVH is built, the system must
recompute spatial partitioning and vertex groupings from scratch,
leading to redundant calculations and suboptimal memory access patterns.
**Proposed Solution**
This patch implements pre-computed spatial organization of mesh data
through a new `mesh_apply_spatial_organization()` function that:
- Reorders vertices and faces based on spatial locality using recursive
spatial partitioning.
- Stores pre-computed MeshGroup hierarchies in MeshRuntime for reuse.
- Enables the BVH system to bypass expensive spatial computation when
pre-organized data is available.
This approach separates the expensive spatial computation from more
frequent BVH rebuilds, providing sustained performance improvements
across multiple sculpting operations.
**Limitations**
- Requires manual invocation (occurs automatically only during remesh
operations).
- Additional memory overhead for storing MeshGroup metadata.
- One-time computational cost during initial organization.
- Spatial group references are not yet stored in files.
**User Interface**
The feature is accessible via a new "Reorder Mesh Spatially" operator in
the Mesh Data Properties panel under the Geometry Data section. Users
can invoke it manually when needed, or it will be applied automatically
during quadriflow and voxel remesh operations. The operator provides
feedback confirming successful spatial reordering.
Pull Request: https://projects.blender.org/blender/blender/pulls/139536
Add performance test for subdividing a multiresolution mesh from level
2 to 3. This test ends with a total fine vertex count of approximately
10m, similar to the stroke and BVH tests for multires.
Pull Request: https://projects.blender.org/blender/blender/pulls/141168
When a benchmark test was failing, there was very little info available
to investigate it. Now report the stdout/stderr generated by the failing
command.
Prior to this commit, the sculpt scene and object was only initialized
once, at the very beginning of the test. This has the downside of slowly
changing the performance characteristics as more and more strokes are
performed, as the number of vertices within a given stroke may
eventually approach 1. To ensure a consistent measurement each time,
rebuild the scene between each brush stroke.
Pull Request: https://projects.blender.org/blender/blender/pulls/139960
This commit lowers the size of the mesh from approximately 2 million
verts to 250 thousand verts. This brings the graph more in line with the
mesh and multires usecase, and is more helpful in measuring and
detecting real performance issues.
While the upper end of dyntopo can certainly be massively improved,
strokes that take in the seconds to complete are already unusable from a
user perspective,
Using the same sized grids as the brush tests, this commit uses the
`sculpt.optimize` operator to approximate the cost of rebuilding the BVH
for a given base mesh grid, multires grid, and dyntopo grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/137690
This commit makes a number of changes to the sculpt performance tests,
aimed at measuring more consistent data and making it easier to extend
the test cases.
* Repeats tests a minimum of 5 times up to 100 times, with a timeout
of 5 seconds for a given test case to run, averaging the duration of
the brush strokes to stabilize the value
* Sets the brush from the script instead of having it defined in each
file, preventing the need to duplicate benchmark files.
* Uses the newly defined `override_location` property to allow defining
the stroke in screen-space and repeating strokes multiple times
without regenerating the base mesh
* Adds tests for the smooth brush, as basic neighbor calculations
* Adds tests for dyntopo sculpting
* Renames the base mesh tests to have a "mesh_" prefix as the data is
inherently discontinuous here.
Related benchmark PR: blender/blender-benchmarks#2
Part of #133926
Pull Request: https://projects.blender.org/blender/blender/pulls/133841
This commit gives users of the Cycles performance benchmark tool the
option to run performance benchmarks with OSL enabled for CPUs
and OptiX devices.
This can be done by adding `-OSL` to the device name:
`CPU-OSL`
`OPTIX-OSL_0`
Pull Request: https://projects.blender.org/blender/blender/pulls/136506
Similar to the regression tests it is possible to append -RT suffix
to the compute type to enable hardware ray-tracing.
For example HIP_0 will run benchmark on first HIP device without
hardware ray-tracing, HIP-RT_0 will run benchmark on the same device
but will enable hardware ray-tracing.
The downside of this change is that it will make it so METAL device
will no longer use HW-RT on M3 and aboce, and explicit METAL-RT is
to be used. This is because benchmark was relying on the Auto
configuration which has different behavior depending on the device
generation.
Pull Request: https://projects.blender.org/blender/blender/pulls/136308
Unfortunately, the tests as they are right now will likely not work with
4.2 and previous versions, as the brush asset changes will need to be
accounted for.
Pull Request: https://projects.blender.org/blender/blender/pulls/132827
This commit modifies the `performance/api/sculpt.py` test to add a new
set of tests that run with the multires modifier present. New tests
have `multires_` prepended to the brush name to group them separately
from the existing mesh tests.
Part of #130772
Pull Request: https://projects.blender.org/blender/blender/pulls/132822
As an initial step to creating automated regression tests for sculpt brushes,
make our existing performance test script into an automated performance
test. The test uses the brush active in each file and runs the brush stroke
operator on a large generated grid. The time is just for the brush evaluation,
it doesn't include building the PBVH, drawing, etc.
I'm not sure about the consequences of conditionally disabling
`view3d_operator_needs_opengl`, but it was needed to make the test
work in background mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/123148
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
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.
Tests should never depend on the users startup.blend which can have
settings that interfere with tests.
Failure to load the user startup.blend for e.g. prevented
bl_alembic_io_test from passing.
There should be no functional changes for the typical usecase,
but it allows to have more tricky setups like pointing to a
BAT script to override some configuration.
The issue is that BAT scripts do not support new lines in the
command line arguments. That's where single-line python expression
helps.
For example, it is possible to point benchmark script to a blender.bat
which contains
blender.exe --python-expr "import bpy; bpy.context.preferences.addons['cycles'].preferences.use_oneapirt = False" %*
to have side-by-side numbers of oneAPI with and without HW RT.
Without this change the %* is which did not work: the BAT
script did not "see" part of the command line past the new line.
Pull Request: https://projects.blender.org/blender/blender/pulls/109006
The scene contains some interesting names, which requires to be
written as utf-8. And on Windows file descriptor is not guaranteed
to be using utf-8. Or, will error out if the invalid utf-8 sequence
is written.
This change makes it so running benchmarks on windows it fully successful.
Pull Request: https://projects.blender.org/blender/blender/pulls/108982
Windows does not really have an idea of shebangs, and it needs to
go via a file extension to see that the script is to be executed
by Python.
This change simplifies execution from `python3 benchmark ...`
to `benchmark.py ...`.
Pull Request: https://projects.blender.org/blender/blender/pulls/108971
Ideally, we would also get variance information out of the test, but that
seems a bit more complex to implement. For now just run the test a couple
of times and average the timings.
The test now runs between 5 and 100 times, depending on how long it
to run the test once.
