nir/scheduler: Add an option to specify what stages share memory for I/O

[mesa.git] / .gitlab-ci / tracie / README.md

diff --git a/.gitlab-ci/tracie/README.md b/.gitlab-ci/tracie/README.md
index 8dc32d043c9733dc714a141ed914a508341a33fe..014bafc92e560034b08c5103a1ceedef3c8111b8 100644 (file)
--- a/.gitlab-ci/tracie/README.md
+++ b/.gitlab-ci/tracie/README.md
@@ -5,13 +5,14 @@ Home of the Mesa trace testing effort.
 
 ### Traces definition file
 
-The trace definition file contains information about the git repo/commit to get
-the traces from, and a list of the traces to run along with their expected image
-checksums on each device. An example:
+The trace definition file contains information about the GitLab
+project and git commit to get the traces from, and a list of the
+traces to run along with their expected image checksums on each
+device. An example:
 
 ```yaml
 traces-db:
-  repo: https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db
+  gitlab-project-url: https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db
   commit: master
 
 traces:
@@ -27,8 +28,8 @@ traces:
         checksum: ff827f7eb069afd87cc305a422cba939
 ```
 
-The traces-db entry can be absent, in which case it is assumed that the
-current directory is the traces-db directory.
+The `traces-db` entry can be absent, in which case it is assumed that
+the traces can be found in the `CWD/traces-db` directory.
 
 Traces that don't have an expectation for the current device are skipped
 during trace replay.
@@ -39,11 +40,12 @@ with the [image_checksum.py](.gitlab-ci/tracie/image_checksum.py) script.
 Alternatively, an arbitrary checksum can be used, and during replay (see below)
 the scripts will report the mismatch and expected checksum.
 
-### Trace-db repos
+### Trace-db GitLab projects
 
-The trace-db repos are assumed to be git repositories using LFS for their trace
-files. This is so that trace files can be potentially checked out and replayed
-individually, thus reducing storage requirements during CI runs.
+The trace-db GitLab projects are assumed to have git repositories
+using LFS for their trace files. This is so that trace files can be
+potentially checked out and replayed individually, thus reducing
+storage requirements during CI runs.
 
 ### Enabling trace testing on a new device
 
@@ -97,22 +99,17 @@ publisher.
 Mesa traces CI uses a set of scripts to replay traces and check the output
 against reference checksums.
 
-The high level script [tracie.sh](.gitlab-ci/tracie/tracie.sh) accepts
-a traces definition file and the type of traces
-(apitrace/renderdoc/gfxreconstruct) to run:
+The high level script [tracie.py](.gitlab-ci/tracie/tracie.py) accepts
+a traces definition file and the name of the device to be tested:
 
-    tracie.sh .gitlab-ci/traces.yml renderdoc
+    tracie.py --file .gitlab-ci/traces.yml --device-name gl-vmware-llvmpipe
 
-tracie.sh copies produced artifacts to the `$CI_PROJECT_DIR/result`
+tracie.py copies the produced artifacts to the `$CI_PROJECT_DIR/result`
 directory. By default, created images from traces are only stored in case of a
 checksum mismatch. The `TRACIE_STORE_IMAGES` CI/environment variable can be set
 to `1` to force storing images, e.g., to get a complete set of reference
 images.
 
-The `tracie.sh` script requires that the environment variable `DEVICE_NAME` is
-properly set for the target machine, and matches the `device` field of the
-relevant trace expectations in the used `traces.yml` file.
-
 At a lower level the
 [dump_trace_images.py](.gitlab-ci/tracie/dump_trace_images.py) script is
 called, which replays a trace, dumping a set of images in the process. By