mirror of
https://github.com/encounter/dawn-cmake.git
synced 2025-05-14 19:31:25 +00:00
fb5a492787
The current presubmit has the filter inverted so it would only attempt to match the filtered files. The file name also has to be converted to `LocalPath` otherwise it's attempting to compare a python object to a string and always fails to match. Bug: dawn:1339 Change-Id: Ie7712dee60f6b9df2cb78c9feab11769f7ea1f02 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/87080 Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Dan Sinclair <dsinclair@chromium.org> Auto-Submit: Dan Sinclair <dsinclair@chromium.org>
70 lines
3.8 KiB
Markdown
70 lines
3.8 KiB
Markdown
# Testing Dawn
|
|
|
|
(TODO)
|
|
|
|
## Dawn Perf Tests
|
|
|
|
For benchmarking with `dawn_perf_tests`, it's best to build inside a Chromium checkout using the following GN args:
|
|
```
|
|
is_official_build = true # Enables highest optimization level, using LTO on some platforms
|
|
use_dawn = true # Required to build Dawn
|
|
use_cfi_icall=false # Required because Dawn dynamically loads function pointers, and we don't sanitize them yet.
|
|
```
|
|
|
|
A Chromium checkout is required for the highest optimization flags. It is possible to build and run `dawn_perf_tests` from a standalone Dawn checkout as well, only using GN arg `is_debug=false`. For more information on building, please see [building.md](./building.md).
|
|
|
|
### Terminology
|
|
|
|
- Iteration: The unit of work being measured. It could be a frame, a draw call, a data upload, a computation, etc. `dawn_perf_tests` metrics are reported as time per iteration.
|
|
- Step: A group of Iterations run together. The number of `iterationsPerStep` is provided to the constructor of `DawnPerfTestBase`.
|
|
- Trial: A group of Steps run consecutively. `kNumTrials` are run for each test. A Step in a Trial is run repetitively for approximately `kCalibrationRunTimeSeconds`. Metrics are accumlated per-trial and reported as the total time divided by `numSteps * iterationsPerStep`. `maxStepsInFlight` is passed to the `DawnPerfTestsBase` constructor to limit the number of Steps pipelined.
|
|
|
|
(See [`//src/dawn/tests/perf_tests/DawnPerfTest.h`](https://cs.chromium.org/chromium/src/third_party/dawn/src/dawn/tests/perf_tests/DawnPerfTest.h) for the values of the constants).
|
|
|
|
### Metrics
|
|
|
|
`dawn_perf_tests` measures the following metrics:
|
|
- `wall_time`: The time per iteration, including time waiting for the GPU between Steps in a Trial.
|
|
- `cpu_time`: The time per iteration, not including time waiting for the GPU between Steps in a Trial.
|
|
- `validation_time`: The time for CommandBuffer / RenderBundle validation.
|
|
- `recording_time`: The time to convert Dawn commands to native commands.
|
|
|
|
Metrics are reported according to the format specified at
|
|
[[chromium]//build/recipes/performance_log_processor.py](https://cs.chromium.org/chromium/build/recipes/performance_log_processor.py)
|
|
|
|
### Dumping Trace Files
|
|
|
|
The test harness supports a `--trace-file=path/to/trace.json` argument where Dawn trace events can be dumped. The traces can be viewed in Chrome's `about://tracing` viewer.
|
|
|
|
### Test Runner
|
|
|
|
[`//scripts/perf_test_runner.py`](https://cs.chromium.org/chromium/src/third_party/dawn/scripts/perf_test_runner.py) may be run to continuously run a test and report mean times and variances.
|
|
|
|
Currently the script looks in the `out/Release` build directory and measures the `wall_time` metric (hardcoded into the script). These should eventually become arguments.
|
|
|
|
Example usage:
|
|
|
|
```
|
|
scripts/perf_test_runner.py DrawCallPerf.Run/Vulkan__e_skip_validation
|
|
```
|
|
|
|
### Tests
|
|
|
|
**BufferUploadPerf**
|
|
|
|
Tests repetitively uploading data to the GPU using either `WriteBuffer` or `CreateBuffer` with `mappedAtCreation = true`.
|
|
|
|
**DrawCallPerf**
|
|
|
|
DrawCallPerf tests drawing a simple triangle with many ways of encoding commands,
|
|
binding, and uploading data to the GPU. The rationale for this is the following:
|
|
- Static/Multiple/Dynamic vertex buffers: Tests switching buffer bindings. This has
|
|
a state tracking cost as well as a GPU driver cost.
|
|
- Static/Multiple/Dynamic bind groups: Same rationale as vertex buffers
|
|
- Static/Dynamic pipelines: In addition to a change to GPU state, changing the pipeline
|
|
layout incurs additional state tracking costs in Dawn.
|
|
- With/Without render bundles: All of the above can have lower validation costs if
|
|
precomputed in a render bundle.
|
|
- Static/Dynamic data: Updating data for each draw is a common use case. It also tests
|
|
the efficiency of resource transitions.
|