Last week during the project sync meeting there was a topic raised about performance regressions. There was interest from other modules/projects to give attention to the tooling and eco-system.
Current focus areas
In Scope
- Improvements to blender performance testing (/tests/performance/benchmark.py) #154961
- Add support for tracy !139922
Out of scope
- User oriented performance tooling.
Participants
- Brecht
- Jeroen
- Jonas
- Mark
- Sean
Tracy
Continuation of !139922
- Platform module/library/building - Jonas
- Integrating into Blender
- Add a BLI wrapper around the API.
- Marker placement
- CPU side; idea is to start with wm.cc main loop and go along the functions. - Sean
- GPU side - Mark
- Guarded malloc
- Plotting of custom data (future?)
Prioritization; what are important or easy tasks with impact)
- Use existing patch as inital patch other work
- BLI wrapper
- Adding marker
- (Platform/Library update could be done separatly)
- Easier to use (
make profiler)
Performance testing
To clarify the goal of the benchmark tool is to indicate that there is a regression. It should not pin-point to where the regression is.
Jeroen will pick up some tasks mentioned in #154961
- Add git commit hash to the export
- Perform multiple runs
- Add actual used device to the output
- Issues related to building
We shortly discussed the idea of putting the results in a data store with a graphana frontend. The idea is to not change how the tool currently works, but to collect daily build results and upload them in the data store. The benchmark tool should always be easy to use locally.
Follow up/next meeting
We agree to follow up via PR’s and pokes on the chat.
Next meeting could be held when we are able to place markers.