| commit | 1d359bc71aab0954d73b3d9d8ecb8885c65f13c7 | [log] [tgz] |
|---|---|---|
| author | Alex Walters <alex.walters@imgtec.com> | Wed Apr 22 18:03:12 2020 +0100 |
| committer | Alexander Galazin <Alexander.Galazin@arm.com> | Wed May 13 02:32:03 2020 -0400 |
| tree | 6772e69e2ee98bbfa79711f87707e7cade622bed | |
| parent | b8794cdcd09546f9eb09b922c083da03b6841693 [diff] |
Non-strict line interpolation and rasterization Firstly non-strict line rasterization (parallelogram decomposed to triangles) is changed to use the TriangleInterpolator do determine interpolated colours. Line endpoint attributes are duplicated to the end vertices of parallelogram lines, which means that interpolation is not along the normal of the line, but would be parallel to the major axis. For the interpolation to be calculated correctly by the TriangleInterpolator, the triangle geometry needed to be produced with the correct w values from the line endpoints, previously the triangle was generated pre-projected with 1.0 for the W-coordinates. The perspective interpolation previously was calculated separately using the original line parameters passed to MultisampleLineInterpolator. The second part of the change is to allow for a non-strict line 'GLES' centric relaxation - GLES specified 1px non-antialiased lines would use the 'diamond-exit' rule to produce bresenham lines. Vulkan only specified parallelograms, but not all GLES implementations are able to disable the 1px bresenham behaviour. All changes are in verifyMultisameplLineGroupInterpolation and verifyMultisameplLineGroupInterpolationInternal. Strict lines are not affected. This fixes Imaginations 1.2.2.x failures in: dEQP-VK.rasterization.flatshading*line* dEQP-VK.rasterization.interpolation*line* Affects: dEQP-VK.rasterization*line* dEQP-GLES2.functional.rasterization*line* dEQP-GLES3.functional.rasterization*line* Components: Framework VK-GL-CTS Issue: 2274 Change-Id: I0cfd496969512bdbf9d0156ea8f43e737c44512f
This repository contains a GPU testing suite called dEQP (drawElements Quality Program). dEQP contains tests for several graphics APIs, including OpenGL ES, EGL, and Vulkan.
Up-to-date documentation for the dEQP is available at Android Open Source Project site.
The .qpa logs generated by the conformance tests may contain embedded png images of the results. These can be viewed with the Cherry tool.
This repository includes Khronos Vulkan CTS under external/vulkancts directory. For more information see Vulkan CTS README.
This repository includes Khronos OpenGL / OpenGL ES CTS under external/openglcts directory. For more information see OpenGL / OpenGL ES CTS README.
ANGLE can be built for Android by following the instructions here.
The resulting ANGLE shared object libraries can be linked against and embedded into dEQP.apk with the --angle-path option. This will cause dEQP.apk to use the ANGLE libraries for OpenGL ES calls, rather than the native drivers.
An ABI must be specified and the directory structure containing the ANGLE shared objects must match it so the build system can find the correct *.so files.
Assuming ANGLE shared objects are generated into ~/chromium/src/out/Release/ and dEQP.apk will be generated with --abis arm64-v8a, issue the following commands:
cd ~/chromium/src/out/Release/ mkdir arm64-v8a && cd arm64-v8a cp ../lib*_angle.so .
The --angle-path ~/chromium/src/out/Release/ option can then be used to link against and embed the ANGLE shared object files. The full command would be:
python scripts/android/build_apk.py --sdk <path to Android SDK> --ndk <path to Android NDK> --abis arm64-v8a --angle-path ~/chromium/src/out/Release/