This allows exclusions to be set in the `tests` filter for the
benchmarks using the exclamation mark. Exclusions apply *after*
inclusions ie:
tests = ['*', '!victor', '!koro']
would select all available tests then specifically exclude victor
and koro, while:
tests = ['!victor']
would just exclude victor, since nothing is marked for inclusion
no tests will be run.
tests = ['!victor','bmw27,'victor']
would exclude victor, but include bmw27 and victor but as victor was
marked for exclusion only bmw27 will be ran.
Requested by bart in #146019
Pull Request: https://projects.blender.org/blender/blender/pulls/147588
Stored undo step data for position changes in sculpt mode are now
automatically compressed. Compression is run in background threads,
reducing memory consumption during sculpting sessions while adding
little performance overhead.
For testing and benchmarks, memory usage is now available through
`bpy.app.undo_memory_info()`. Undo memory usage is now tracked by the
existing automated benchmark tests. Some changes to the web benchmark
visualization present the data a bit better.
ZSTD compression is run asynchronously in a backround task pool.
Compression is only blocking if the data is requested immediately for
undo/redo.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/141310
Improve handling of runtime defined python RNA properties. Mainly:
* Add `get_transform` and `set_transform` new callbacks.
These allow to edit the value, while still using the default
(IDProperty-based) storage system.
* Read-only properties should now be defined using a new `options` flag,
`READ_ONLY`.
* `get`/`set` should only be used when storing data outside of the
default system now.
* Having a `get` without a `set` defined forces property to be
read-only (same behavior as before).
* Having a `set` without a `get` is now an error.
* Just like with existing `get/set` callbacks, `get_/set_transform`
callbacks must always generate values matching the constraints defined
by their `bpy.props` property definition (same type, within required
range, same dimensions/sizes for the `Vector` properties, etc.).
* To simplify handling of non-statically sized strings, the relevant
RNA API has been modified, to use `std::string` instead of
(allocated) char arrays.
Relevant unittests and benchmarking have been added or updated as part
of this project.
Note: From initial benchmarking, 'transform' versions of get/set are
several times faster than 'real' get/set.
Implements #141042.
Pull Request: https://projects.blender.org/blender/blender/pulls/141303
This PR adds code for setting the Quality of Service (QoS) level of the
process on Windows. This can, e.g., make sure that on hybrid systems
P-cores are utilized even when the app window is out of focus.
In the following cases, it is adjusted from the default behavior:
- In wm_jobs.cc the QoS level is raised while a priority job is running.
- The command line option `--qos [high|eco|default]` can be used to
change the QoS level of the process.
- By default, the QoS level is raised for the EEVEE performance tests,
as they check viewport rendering performance and would otherwise be
reliant on never going out of focus to not get a downgraded QoS level.
By default, they are created with an out of focus window at the time
of landing this PR. This PR makes sure that they actually measure the
animation replay performance attainable during real-world use.
Pull Request: https://projects.blender.org/blender/blender/pulls/144224
Make registered py-defined property tests more flexible, by allowing to
pass the property type as an argument.
And add basic such tests for Bool and String types.
This PR overwrites the FPS limit in the EEVEE performance tests to 1000 FPS.
Background: I have been using the performance tests with, e.g., the Temple scene from the Blender demo files. However, it has configured an animation playback frame rate of 25 FPS. I think for the performance tests it would be more meaningful to render at an unlimited frame rate. Otherwise, one can just see that Temple renders at 25 FPS on pretty much any GPU and it is not possible to measure performance improvements or regressions.
Pull Request: https://projects.blender.org/blender/blender/pulls/142984
Extend the existing benchmark framework to support the compositor.
Files are added separately.
Example output:
```
$ ./benchmark.py run comp
4.5 main
ghosts 1.2055s 1.0243s
ghosts 1.4936s 1.0454s
ghosts 0.4414s 0.4330s
file:///Users/habib/blender-git/benchmark/comp/results.html
```
Pull Request: https://projects.blender.org/blender/blender/pulls/136600
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
