vkd3d/gitlab
Giovanni Mascellani ede1ff6951 demos: Do not trigger -Wmissing-prototypes for wmain().
For some reason wmain() is not exempted from -Wmissing-prototypes
in the same way as main() is. So we just declare a prototype for it.
2023-10-02 22:25:14 +02:00
..
build-crosstest ci: Store config.log as a build artifact. 2023-10-02 22:25:14 +02:00
build-linux ci: Store config.log as a build artifact. 2023-10-02 22:25:14 +02:00
build-mac ci: Store config.log as a build artifact. 2023-10-02 22:25:14 +02:00
build-mingw demos: Do not trigger -Wmissing-prototypes for wmain(). 2023-10-02 22:25:14 +02:00
build.yml ci: Build vkd3d with MinGW too. 2023-09-27 22:34:18 +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
patch_moltenvk_icd.sh ci: Run the tests on macOS. 2023-09-14 20:28:47 +02:00
README ci: Run the tests on macOS. 2023-09-14 20:28:47 +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); and on macOS, on Intel, using MoltenVK as Vulkan driver. 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.

A runner on an Intel macOS system tagged with `mac' must also be
available to run the macOS tests. Unfortunately a system like Docker
is not available in this case to provide an isolated standard
environment for running the tests. All the software required to
compile and run the tests will therefore have to be installed directly
on the host system. Complete instructions to setup the macOS are
currently not available.