vkd3d/gitlab
2023-09-04 20:26:05 +02:00
..
build-linux ci: Execute the tests. 2023-08-31 22:07:21 +02:00
build.yml ci: Run the tests on a 32 bit Linux system. 2023-09-04 20:26:05 +02:00
image.docker ci: Execute CI also an a runner with an AMD GPU. 2023-08-31 22:07:16 +02:00
image.yml ci: Introduce a CI pipeline for GitLab. 2023-08-29 22:07:56 +02:00
README ci: Run the tests on a 32 bit Linux system. 2023-09-04 20:26:05 +02:00

=====================
vkd3d testing scripts
=====================

These scripts are used by the GitLab CI feature to automatically run
the vkd3d tests on each merge request.

The CI target build-image, in the file image.yml, builds a Docker
image based on Debian bookworm with all the packages required for
testing, and uploads it to the GitLab container registry. The Docker
script is in the file image.docker.

The file build.yml contains the actual testing targets. Currently
vkd3d is tested on Linux, on x86-64 and i386, each architecture with
two different Vulkan drivers (both from Mesa): llvmpipe (a software
implementation) and RADV (a hardware implementation backed by an AMD
GPU). The testing logs are available as CI artifacts.

Some custom runner configuration is required in order to run the tests
on an AMD GPU. Specifically, a runner tagged with `amd-gpu' must be
available with the following features:

 * of course a sufficiently recent AMD GPU must be available to the
   host;

 * the host kernel must have the appropriate driver and firmware
   installed;

 * the runner must forward the DRI nodes to the guest; this can be
   configured by adding the line

     devices = ["/dev/dri"]

   to the relevant [runners.docker] section in the config.toml file;

 * the DRI render nodes must be readable and writable by GID 800,
   either because they belong to that group (e.g. because the group
   `render', which typically owns those files, has GID 800) or via a
   FS ACL; such stipulation is needed because in Debian group `render'
   is created dynamically, therefore has no predictable GID: the use
   of a fixed GID enables the guest system to be set up so that the
   user running the tests can access the render nodes.