* Git (for checking out sources)
* Python 3.x (for the build related scripts, some other scripts still use Python 2.7.x)
- * CMake 2.8 (3.6 for Android NDK r17+ builds) or newer
+ * CMake 3.0 (3.6 for Android NDK r17+ builds) or newer
### Win32
Release build can be done by using -DCMAKE_BUILD_TYPE=Release
+If building for 32-bit x86 with GCC, you probably also want to add `-msse2
+-mfpmath=sse` to ensure that you get correct IEEE floating-point behavior.
+
### Linux 64-bit Debug
cmake <path to vulkancts> -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64
Current mustpass is checked into repository and can be found at:
- external/vulkancts/mustpass/1.1.4/vk-default.txt
+ external/vulkancts/mustpass/master/vk-default.txt
Vulkan CTS mustpass can be re-generated by running:
python <vulkancts>/external/vulkancts/scripts/build_mustpass.py
-Pre-compiling SPIR-V binaries
------------------------------
-
-For distribution, and platforms that don't support GLSL to SPIR-V compilation,
-SPIR-V binaries can be pre-built with following command:
-
- python external/vulkancts/scripts/build_spirv_binaries.py
-
-By default the script builds SPIR-V binaries for Vulkan 1.1.
-Binaries for other Vulkan versions can be requested by supplying
-an extra command line option:
-
- python external/vulkancts/scripts/build_spirv_binaries.py --target-vulkan-version <Vulkan version>
-
-Binaries will be written to `external/vulkancts/data/vulkan/prebuilt/`.
-
-Test modules (or in case of Android, the APK) must be re-built after building
-SPIR-V programs in order for the binaries to be available.
-
-
Running CTS
-----------
Following command line options MUST be used when running CTS:
- --deqp-caselist-file=<vulkancts>/external/vulkancts/mustpass/1.1.4/vk-default.txt
+ --deqp-caselist-file=<vulkancts>/external/vulkancts/mustpass/master/vk-default.txt
--deqp-log-images=disable
--deqp-log-shader-sources=disable
--deqp-shadercache=disable
+CTS execution may be split into N fractions ( for the purpose of running it in parallel ) using
+
+ --deqp-fraction=I,N
+
+where I denotes index of current CTS execution ( I=[0..N-1], N=[1..8] )
+
+When collecting results for a Conformance Submission Package the number of fractions must not exceed 8,
+and a list of mandatory information tests for each fraction must be supplied:
+
+ --deqp-fraction-mandatory-caselist-file=<vulkancts>external/vulkancts/mustpass/master/vk-fraction-mandatory-tests.txt
+
No other command line options are allowed.
### Win32
cd <builddir>/external/vulkancts/modules/vulkan
- Debug/deqp-vk.exe --deqp-caselist-file=...
+ Debug\deqp-vk.exe --deqp-caselist-file=...
Test log will be written into TestResults.qpa
### Android
- adb push <vulkancts>/external/vulkancts/mustpass/1.1.4/vk-default.txt /sdcard/vk-default.txt
+ adb push <vulkancts>/external/vulkancts/mustpass/master/vk-default.txt /sdcard/vk-default.txt
adb shell
In device shell:
The conformance submission package must contain the following:
-1. Full test logs (`TestResults.qpa`) from CTS runs against all driver builds
+1. Full test logs (`TestResults.qpa`) from CTS runs against all driver builds and all fractions
2. Result of `git status` and `git log` from CTS source directory
3. Any patches used on top of release tag
4. Conformance statement
-Test logs (1) should be named `<submission pkg dir>/TestResults-<driver build type>.qpa`,
-for example `TestResults-armeabi-v7a.qpa`. On platforms where multiple different driver
+Test logs (1) should be named `<submission pkg dir>/TestResults-<driver build type>-<fraction id>-of-<total fractions>.qpa`,
+for example `TestResults-armeabi-v7a-1-of-8.qpa`. On platforms where multiple different driver
builds (for example 64-bit and 32-bit) are present, CTS logs must be provided
-for each driver build as part of the submission package.
+for each driver build as part of the submission package. If CTS run was split into multiple
+fractions then result files for all fractions must be provided, each file must
+contain results of the mandatory information tests.
+
+Fractions may be run on different physical devices but each device must represent
+the same Conformant Product.
Test logs generated on a system which exposes more than one physical device
in a device group can be used for products that expose one or more physical
If the submission package covers multiple products, you can list them by appending
additional `PRODUCT:` lines to the conformance statement. For example:
- CONFORM_VERSION: vulkan-cts-1.1.4.0
+ CONFORM_VERSION: vulkan-cts-1.1.6.0
PRODUCT: Product A
PRODUCT: Product B
...
script. The script takes two arguments: path to extracted submission package
and path to current mustpass list. For example:
- python external/vulkancts/scripts/verify_submission.py VK_11_Khronos_1/ external/vulkancts/mustpass/1.1.4/vk-default.txt
+ python external/vulkancts/scripts/verify_submission.py VK_11_Khronos_1/ external/vulkancts/mustpass/master/vk-default.txt
Please note that the script reports a warning even for a correctly generated git-log.txt
If your git-log.txt contains only head commit of the release tag then
The list of the optimization recipes can be found and customized in the
`optimizeCompiledBinary()` function in `vkPrograms.cpp`.
-As of this writing, there are 8 recipes to choose from:
+As of this writing, there are 2 recipes to choose from:
0. Disabled (default)
- 1. The example recipe from spir-v opt 1.0 whitepaper
- 2. RegisterPerformancePasses from commandline optimizer tool october 2017
- 3. RegisterSizePasses from commandline optimizer tool october 2017
- 4. RegisterLegalizationPasses from commandline optimizer tool April 2018
- 5. RegisterPerformancePasses from commandline optimizer tool April 2018
- 6. RegisterPerformancePasses from commandline optimizer tool April 2018 with CreateCommonUniformElimPass
- 7. RegisterSizePasses from commandline optimizer tool April 2018
- 8. RegisterSizePasses from commandline optimizer tool April 2018 with CreateCommonUniformElimPass
-
-The `Register...Passes()` calls change in the SPIR-V optimizer tool from
-time to time. Since different sets of passes may result in different
-shaders, having several fixed sets is useful for issue discovery.
+ 1. Optimize for performance
+ 2. Optimize for size
+
+The performance and size optimization recipes are defined by the spir-v
+optimizer, and will change from time to time as the optimizer matures.
--deqp-optimize-spirv=enable
projects / platform / upstream / VK-GL-CTS.git / blobdiff