gitlab-ci: Add jobs to be able to test Vulkan

Also, adds an example job for radv.

Signed-off-by: Andres Gomez <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Alexandros Frantzis <[email protected]>

1 files changed, 38 insertions, 10 deletions

diff --git a/.gitlab-ci/tracie/README.md b/.gitlab-ci/tracie/README.md
index 8ea51c6d598..e7fccfaf481 100644
--- a/.gitlab-ci/tracie/README.md
+++ b/.gitlab-ci/tracie/README.md
@@ -50,15 +50,29 @@ individually, thus reducing storage requirements during CI runs.
 To enable trace testing on a new device:
 
 1. Create a new job in .gitlab-ci.yml. The job will need to be tagged
-   to run on runners with the appropriate hardware. Use the `.traces-test`
-   template job as a base, and make sure you set a unique value for the
-   `DEVICE_NAME` variable:
+   to run on runners with the appropriate hardware.
+
+   1. If you mean to test GL traces, use the `.traces-test-gl`
+      template jobs as a base, and make sure you set a unique value for the
+     `DEVICE_NAME` variable:
 
    ```yaml
-   my-hardware-traces:
+   my-hardware-gl-traces:
      extends: .traces-test-gl
      variables:
-       DEVICE_NAME: "myhardware"
+       DEVICE_NAME: "gl-myhardware"
+   ```
+
+   2. If you mean to test Vulkan traces, use the `.traces-test-vk`
+      template jobs as a base, set the `VK_DRIVER` variable, and make
+      sure you set a unique value for the `DEVICE_NAME` variable:
+
+   ```yaml
+   my-hardware-vk-traces:
+     extends: .traces-test-vk
+     variables:
+       VK_DRIVER: "radeon"
+       DEVICE_NAME: "vk-myhardware"
    ```
 
 2. Update the .gitlab-ci/traces.yml file with expectations for the new device.
@@ -68,8 +82,9 @@ To enable trace testing on a new device:
 
 ### Trace files
 
-Tracie supports both renderdoc (.rdc) and apitrace (.trace) files. Trace files
-need to have the correct extension so that tracie can detect them properly.
+Tracie supports renderdoc (.rdc), apitrace (.trace) and gfxreconstruct
+(.gfxr) files. Trace files need to have the correct extension so that
+tracie can detect them properly.
 
 The trace files that are contained in public traces-db repositories must be
 legally redistributable. This is typically true for FOSS games and
@@ -83,7 +98,8 @@ 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) to run:
+a traces definition file and the type of traces
+(apitrace/renderdoc/gfxreconstruct) to run:
 
     tracie.sh .gitlab-ci/traces.yml renderdoc
 
@@ -116,11 +132,23 @@ Examples:
 ### Running the replay scripts locally
 
 It's often useful, especially during development, to be able to run the scripts
-locally. The scripts require a recent version of apitrace being in the path,
-and also the renderdoc python module being available.
+locally.
+
+Depending on the target 3D API, the scripts require a recent version
+of apitrace being in the path, and also the renderdoc python module
+being available, for GL traces.
 
 To ensure python3 can find the renderdoc python module you need to set
 `PYTHONPATH` to point to the location of `renderdoc.so` (binary python modules)
 and `LD_LIBRARY_PATH` to point to the location of `librenderdoc.so`. In the
 renderdoc build tree, both of these are in `renderdoc/<builddir>/lib`. Note
 that renderdoc doesn't install the `renderdoc.so` python module.
+
+In the case of Vulkan traces, the scripts need a recent version of
+gfxrecon-replay being in the path, and also the
+`VK_LAYER_LUNARG_screenshot` Vulkan layer from LunarG's VulkanTools.
+
+To ensure that this layer can be found when running the trace you need
+to set `VK_LAYER_PATH` to point to the location of
+`VkLayer_screenshot.json` and `LD_LIBRARY_PATH` to point to the
+location of `libVkLayer_screenshot.so`.