Android:
+Following command will build CTS into android/package/bin/dEQP-debug.apk.
+
$ python android/scripts/build.py
+
+The package can be installed by either running:
+
$ python android/scripts/install.py
+By default the CTS package will contain libdeqp.so built for armeabi-v7a, arm64-v8a,
+and x86 ABIs, but that can be changed in android/scripts/common.py script.
+
+To pick which ABI to use at install time, following commands must be used
+instead:
+
+ $ adb install --abi <ABI name> android/package/bin/dEQP-debug.apk /data/local/tmp/dEQP-debug.apk
+
Building Mustpass
-----------------
-Vulkan CTS mustpass can be built by running:
+Current mustpass is checked into repository and can be found at:
+
+ external/vulkancts/mustpass/1.0.0/vk-default.txt
+
+Vulkan CTS mustpass can be re-generated by running:
$ python <vulkancts>/external/vulkancts/build_mustpass.py
+Pre-compiling SPIR-V binaries
+-----------------------------
+
+For distribution, and platforms that don't support GLSL to SPIR-V compilation,
+SPIR-V binaries must be pre-built with following command:
+
+ $ python external/vulkancts/build_spirv_binaries.py
+
+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
-----------
--deqp-caselist-file=<vulkancts>/external/vulkancts/mustpass/1.0.0/vk-default.txt
--deqp-log-images=disable
+ --deqp-log-shader-sources=disable
In addition on multi-device systems the device for which conformance is claimed
can be selected with:
In device shell:
- $ am start -n com.drawelements.deqp/android.app.NativeActivity -es cmdLine "deqp --deqp-caselist-file=/sdcard/vk-default.txt --deqp-log-images=disable --deqp-log-filename=/sdcard/TestResults.qpa"
+ $ 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"
Process can be followed by running:
Test log will be written into /sdcard/TestResults.qpa
-Pre-compiling SPIR-V binaries
------------------------------
+Conformance Submission Package Requirements
+-------------------------------------------
-For distribution, and platforms that don't support GLSL to SPIR-V compilation,
-SPIR-V binaries must be pre-built with following command:
+The conformance submission package must contain the following:
- $ python external/vulkancts/build_spirv_binaries.py
+1) Full test logs (TestResults.qpa) from CTS runs against all driver builds
+2) Result of "git status" and "git log" from CTS source directory
+3) Any patches used on top of release tag
+4) Conformance statement
-Binaries will be written to external/vulkancts/data/vulkan/prebuilt/.
+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
+builds (for example 64-bit and 32-bit) are present, CTS logs must be provided
+for each driver build.
-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.
+The CTS build must always be done from clean git repository that doesn't have any
+uncommitted changes. Thus it is necessary to run and capture output of "git
+status" and "git log" (2) in the source directory:
+
+ git status > <submission pkg dir>/git-status.txt
+ git log <release tag>..HEAD > <submission pkg dir>/git-log.txt
+
+Any changes made to CTS must be committed to the local repository, and provided
+as part of the submission package (3). This can be done by running:
+
+ git format-patch -o <submission pkg dir> <release tag>..HEAD
+
+In general, bugfixes and changes to platform-specific code (mostly under
+framework/platform) are allowed. The commit message for each change must
+include a clear description of the change and why it is necessary. Non-porting
+related changes must be accompanied by a waiver (see below).
+
+Note: When cherry-picking patches on top of release tag, please use "git cherry-pick -x"
+to include original commit hash in the commit message.
+
+Conformance statement (4) must be included in a file called STATEMENT-<adopter>
+and must contain following:
+
+ CONFORM_VERSION: <git tag of CTS release>
+ PRODUCT: <string-value>
+ CPU: <string-value>
+ OS: <string-value>
+
+Note that product/cpu/os information is also captured in dEQP-VK.info.* tests
+if vk::Platform::describePlatform() is implemented.
+
+The actual submission package consists of the above set of files which must
+be bundled into a gzipped tar file named VK10_<adopter><_info>.tgz. <adopter>
+is the name of the Adopting member company, or some recognizable abbreviation.
+The <_info> field is optional. It may be used to uniquely identify a submission
+by OS, platform, date, or other criteria when making multiple submissions.
+
+One way to create a suiteable gzipped tar file is to execute the command:
+
+$ tar -cvzf <filename.tgz> -C <submission pkg dir> .
+
+where <submission pkg dir> is the directory containing the files from (1)-(4)
+from above. A submission package must contain all of the files listed above,
+and only those files.
+
+
+Waivers
+-------
+
+The process for requesting a waiver is to report the issue by filing a bug
+report in the Gitlab VulkanCTS project (TODO Github?). When creating the
+submission package, include references to the waiver in the commit message of
+the relevant change. Including as much information as possible in your bug
+report (including a unified diff or a merge request of suggested file changes)
+will ensure the issue can be progressed as rapidly as possible. Issues must
+be labeled "Waiver" (TODO!) and identify the version of the CTS and affected
+tests.
+
+Conformance Criteria
+--------------------
+
+Conformance run is considered passing if all tests finish with allowed result
+codes. The test results are contained in the TestResults.qpa log. Each
+test case section contains XML tag Result, for example:
+
+ <Result StatusCode="Pass">Not validated</Result>
+
+The result code is the value of the StatusCode attribute. Following status
+codes are allowed:
+
+ Pass, NotSupported, QualityWarning, CompatibilityWarning
+
+TODO: Create script for verifying logs.
Vulkan platform port
projects / platform / upstream / VK-GL-CTS.git / blobdiff