4 This document describes how to build and run Vulkan Conformance Test suite.
6 Vulkan CTS is built on dEQP framework. dEQP documentation is available
7 at http://source.android.com/devices/graphics/testing.html
15 * Git (for checking out sources)
16 * Python 2.7.x (all recent versions in 2.x should work, 3.x is not supported)
21 * Visual Studio 2013 or newer (glslang uses several C++11 features)
25 * Standard toolchain (make, gcc/clang)
30 * Android SDK with: SDK Tools, SDK Platform-tools, SDK Build-tools, and API 22
32 * Windows: either NMake or JOM in PATH
38 To build dEQP, you need first to download sources for zlib, libpng, glslang,
41 To download sources, run:
43 python external/fetch_sources.py
45 You may need to re-run `fetch_sources.py` to update to the latest glslang and
46 spirv-tools revisions occasionally.
48 NOTE: glslang integration is not yet available on Android due to a toolchain
49 bug, so pre-compiled SPIR-V binaries must be used. See instructions below.
51 With CMake out-of-source builds are always recommended. Create a build directory
52 of your choosing, and in that directory generate Makefiles or IDE project
58 cmake <path to vulkancts> -G"Visual Studio 12"
59 start dEQP-Core-default.sln
63 cmake <path to vulkancts> -G"Visual Studio 12 Win64"
64 start dEQP-Core-default.sln
66 ### Linux 32-bit Debug
68 cmake <path to vulkancts> -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32
71 Release build can be done by using -DCMAKE_BUILD_TYPE=Release
73 ### Linux 64-bit Debug
75 cmake <path to vulkancts> -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64
80 Following command will build CTS into android/package/bin/dEQP-debug.apk.
82 python android/scripts/build.py
84 The package can be installed by either running:
86 python android/scripts/install.py
88 By default the CTS package will contain libdeqp.so built for armeabi-v7a, arm64-v8a,
89 and x86 ABIs, but that can be changed in android/scripts/common.py script.
91 To pick which ABI to use at install time, following commands must be used
94 adb install --abi <ABI name> android/package/bin/dEQP-debug.apk /data/local/tmp/dEQP-debug.apk
100 Current mustpass is checked into repository and can be found at:
102 external/vulkancts/mustpass/1.0.0/vk-default.txt
104 Vulkan CTS mustpass can be re-generated by running:
106 python <vulkancts>/external/vulkancts/build_mustpass.py
109 Pre-compiling SPIR-V binaries
110 -----------------------------
112 For distribution, and platforms that don't support GLSL to SPIR-V compilation,
113 SPIR-V binaries must be pre-built with following command:
115 python external/vulkancts/build_spirv_binaries.py
117 Binaries will be written to `external/vulkancts/data/vulkan/prebuilt/`.
119 Test modules (or in case of Android, the APK) must be re-built after building
120 SPIR-V programs in order for the binaries to be available.
126 Following command line options MUST be used when running CTS:
128 --deqp-caselist-file=<vulkancts>/external/vulkancts/mustpass/1.0.0/vk-default.txt
129 --deqp-log-images=disable
130 --deqp-log-shader-sources=disable
132 In addition on multi-device systems the device for which conformance is claimed
133 can be selected with:
135 --deqp-vk-device-id=<value>
137 No other command line options are allowed.
141 cd <builddir>/external/vulkancts/modules/vulkan
142 Debug/deqp-vk.exe --deqp-caselist-file=...
144 Test log will be written into TestResults.qpa
148 cd <builddir>/external/vulkancts/modules/vulkan
149 ./deqp-vk --deqp-vk-caselist-file=...
153 adb push <vulkancts>/external/vulkancts/mustpass/1.0.0/vk-default.txt /sdcard/vk-default.txt
158 am start -n com.drawelements.deqp/android.app.NativeActivity -e cmdLine "deqp --deqp-caselist-file=/sdcard/vk-default.txt --deqp-log-images=disable --deqp-log-shader-sources=disable --deqp-log-filename=/sdcard/TestResults.qpa"
160 Test progress will be written to device log and can be displayed with:
164 Test log will be written into `/sdcard/TestResults.qpa`.
167 Conformance Submission Package Requirements
168 -------------------------------------------
170 The conformance submission package must contain the following:
172 1. Full test logs (`TestResults.qpa`) from CTS runs against all driver builds
173 2. Result of `git status` and `git log` from CTS source directory
174 3. Any patches used on top of release tag
175 4. Conformance statement
177 Test logs (1) should be named `<submission pkg dir>/TestResults-<driver build type>.qpa`,
178 for example `TestResults-armeabi-v7a.qpa`. On platforms where multiple different driver
179 builds (for example 64-bit and 32-bit) are present, CTS logs must be provided
180 for each driver build as part of the submission package.
182 The CTS build must always be done from clean git repository that doesn't have any
183 uncommitted changes. Thus it is necessary to run and capture output of `git
184 status` and `git log` (2) in the source directory:
186 git status > <submission pkg dir>/git-status.txt
187 git log <release tag>..HEAD > <submission pkg dir>/git-log.txt
189 Any changes made to CTS must be committed to the local repository, and provided
190 as part of the submission package (3). This can be done by running:
192 git format-patch -o <submission pkg dir> <release tag>..HEAD
194 In general, bugfixes and changes to platform-specific code (mostly under
195 `framework/platform`) are allowed. The commit message for each change must
196 include a clear description of the change and why it is necessary. Non-porting
197 related changes must be accompanied by a waiver (see below).
199 NOTE: When cherry-picking patches on top of release tag, please use `git cherry-pick -x`
200 to include original commit hash in the commit message.
202 Conformance statement (4) must be included in a file called `STATEMENT-<adopter>`
203 and must contain following:
205 CONFORM_VERSION: <git tag of CTS release>
206 PRODUCT: <string-value>
210 Note that product/cpu/os information is also captured in `dEQP-VK.info.*` tests
211 if `vk::Platform::describePlatform()` is implemented.
213 If the submission package covers multiple products, you can list them by appending
214 additional `PRODUCT:` lines to the conformance statement. For example:
216 CONFORM_VERSION: vulkan-cts-1.0.0-internal
221 The actual submission package consists of the above set of files which must
222 be bundled into a gzipped tar file named `VK10_<adopter><_info>.tgz`. `<adopter>`
223 is the name of the Adopting member company, or some recognizable abbreviation.
224 The `<_info>` field is optional. It may be used to uniquely identify a submission
225 by OS, platform, date, or other criteria when making multiple submissions.
227 One way to create a suiteable gzipped tar file is to execute the command:
229 tar -cvzf <filename.tgz> -C <submission pkg dir> .
231 where `<submission pkg dir>` is the directory containing the files from (1)-(4)
232 from above. A submission package must contain all of the files listed above,
233 and only those files.
235 As an example submission package could contain:
240 0001-Remove-Waived-Filtering-Tests.patch
241 0002-Fix-Pipeline-Parameters.patch
242 TestResults-armeabi-v7a.qpa
243 TestResults-arm64-v8a.qpa
249 The process for requesting a waiver is to report the issue by filing a bug
250 report in the Gitlab VulkanCTS project (TODO Github?). When creating the
251 submission package, include references to the waiver in the commit message of
252 the relevant change. Including as much information as possible in your bug
253 report (including a unified diff or a merge request of suggested file changes)
254 will ensure the issue can be progressed as rapidly as possible. Issues must
255 be labeled "Waiver" (TODO!) and identify the version of the CTS and affected
261 Conformance run is considered passing if all tests finish with allowed result
262 codes. Test results are contained in the TestResults.qpa log. Each
263 test case section contains XML tag Result, for example:
265 <Result StatusCode="Pass">Not validated</Result>
267 The result code is the value of the StatusCode attribute. Following status
275 Submission package can be verified using `external/vulkancts/verify_submission.py`
276 script. The script takes two arguments: path to extracted submission package
277 and path to current mustpass list. For example:
279 python external/vulkancts/verify_submission.py VK_10_Khronos_1/ external/vulkancts/mustpass/1.0.0/vk-default.txt
285 Vulkan support from Platform implementation requires providing
286 `getVulkanPlatform()` method in `tcu::Platform` class implementation.
288 See `framework/common/tcuPlatform.hpp` and examples in
289 `framework/platform/win32/tcuWin32Platform.cpp` and
290 `framework/platform/android/tcuAndroidPlatform.cpp`.
296 For testing and development purposes it might be useful to be able to run
297 tests on dummy Vulkan implementation. One such implementation is provided in
298 vkNullDriver.cpp. To use that, implement `vk::Platform::createLibrary()` with
299 `vk::createNullDriver()`.
305 Vulkan test module can be used with Cherry (GUI for test execution and
306 analysis). Cherry is available at
307 https://android.googlesource.com/platform/external/cherry. Please follow
308 instructions in README to get started.
310 To enable support for Vulkan tests, dEQP-VK module must be added to list of
313 In `cherry/testrunner.go`, add following line to `testPackageDescriptors` list
314 (line 645 in `NewTestRunner` function):
316 {"dEQP-VK", "deqp-vk", "../external/vulkancts/modules/vulkan", dataDir + "dEQP-VK-cases.xml"},
318 Before first launch, and every time test hierarchy has been modified, test
319 case list must be refreshed by running:
321 python scripts/build_caselists.py path/to/cherry/data
323 Cherry must be restarted for the case list update to take effect.