Diese Seite wurde von der Cloud Translation API übersetzt.

Prüfung des drawElements-Qualitätsprogramms

AOSP umfasst die GPU-Testsuite des drawElements Quality Program (deqp) unter https://android.googlesource.com/platform/external/deqp . Auf dieser Seite erfahren Sie, wie Sie die Deqp-Testsuite in einer neuen Umgebung bereitstellen.

Um mit dem zuletzt übermittelten Code zu arbeiten, verwenden Sie den Zweig deqp-dev . Für Code, der einer bestimmten Android CTS-Version entspricht, verwenden Sie den Zweig release-code-name -release (verwenden Sie beispielsweise für Android 6.0 den Zweig marshmallow-release “).

Quelllayout

Das Quellcode-Layout für die DEQP-Testmodule und unterstützenden Bibliotheken ist in der folgenden Tabelle dargestellt (die Auflistung erhebt keinen Anspruch auf Vollständigkeit, hebt jedoch die wichtigsten Verzeichnisse hervor).

Verzeichnis	Beschreibung
`android`	Android-Testquellen und Build-Skripte
`data`	Testdatendateien
`modules`	Testmodulquellen
`modules/egl`	EGL-Modul
`modules/gles2`	GLES2-Modul
`modules/gles3`	GLES3-Modul
`modules/gles31`	GLES3.1-Modul
`modules/gles32`	GLES3.2-Modul
`targets`	Zielspezifische Build-Konfigurationsdateien
`framework`	DEQP-Testmodul-Framework und Dienstprogramme
`framework/delibs`	Basisportabilität und Build-Bibliotheken
`framework/platform`	Plattformports
`framework/qphelper`	Testprogramm-Integrationsbibliothek (C)
`framework/common`	Deqp-Framework (C++)
`framework/opengl, framework/egl`	API-spezifische Dienstprogramme
`execserver`	Geräteseitige ExecServer-Quelle
`executor`	Hostseitiges Test-Executor-Shell-Tool und Dienstprogramme
`external`	Erstellen Sie ein Stub-Verzeichnis für die externen Bibliotheken libpng und zlib

Open-Source-Komponenten

Das Deqp verwendet libpng und zlib , die mit dem Skript platform/external/deqp/external/fetch_sources.py oder über git von platform/external/[libpng,zlib] abgerufen werden können.

Erstellen Sie Testprogramme

Das Test-Framework wurde im Hinblick auf Portabilität entwickelt. Die einzigen zwingenden Anforderungen sind vollständige C++-Unterstützung und Standardsystembibliotheken für I/O, Threads und Sockets.

CMake-Build-System

Die DEQP-Quellen verfügen über Build-Skripte für CMake, das bevorzugte Tool zum Kompilieren der Testprogramme.

CMake ist ein Open-Source-Build-System, das mehrere Plattformen und Toolchains unterstützt. CMake generiert native Makefiles oder IDE-Projektdateien aus zielunabhängigen Konfigurationsdateien. Weitere Informationen zu CMake finden Sie in der CMake- Dokumentation.

CMake unterstützt und empfiehlt Builds außerhalb des Quellbaums, dh Sie sollten Makefiles oder Projektdateien immer in einem separaten Build-Verzeichnis außerhalb des Quellbaums erstellen. CMake verfügt über kein „distclean“-Ziel, daher muss das Entfernen aller von CMake generierten Dateien manuell erfolgen.

Konfigurationsoptionen werden CMake mithilfe der Syntax -D OPTION_NAME = VALUE übergeben. Einige häufig verwendete Optionen für deqp sind unten aufgeführt.

Konfigurationsoption Beschreibung

Konfigurationsoption	Beschreibung
`DEQP_TARGET`	Zielname, zum Beispiel: „android“ Die deqp-CMake-Skripte enthalten die Datei `targets/ DEQP_TARGET / DEQP_TARGET .cmake` und erwarten, dass sie von dort aus zielspezifische Build-Optionen finden.
`CMAKE_TOOLCHAIN_FILE`	Pfad zur Toolchain-Datei für CMake. Wird für die Cross-Kompilierung verwendet.
`CMAKE_BUILD_TYPE`	Build-Typ für Makefile-Ziele. Gültige Werte sind: „Debug“ und „Release“ Beachten Sie, dass die Interpretation und der Standardtyp vom Ziel-Build-System abhängen. Weitere Informationen finden Sie in der CMake-Dokumentation.

DEQP_TARGET

Zielname, zum Beispiel: „android“

Die deqp-CMake-Skripte enthalten die Datei targets/ DEQP_TARGET / DEQP_TARGET .cmake und erwarten, dass sie von dort aus zielspezifische Build-Optionen finden.

CMAKE_TOOLCHAIN_FILE

Pfad zur Toolchain-Datei für CMake. Wird für die Cross-Kompilierung verwendet.

CMAKE_BUILD_TYPE

Build-Typ für Makefile-Ziele. Gültige Werte sind: „Debug“ und „Release“

Beachten Sie, dass die Interpretation und der Standardtyp vom Ziel-Build-System abhängen. Weitere Informationen finden Sie in der CMake-Dokumentation.

Erstellen Sie eine Ziel-Build-Datei

Das DEQP-Build-System wird mithilfe von Ziel-Build-Dateien für neue Ziele konfiguriert. Eine Ziel-Build-Datei definiert, welche Funktionen die Plattform unterstützt und welche Bibliotheken oder zusätzlichen Include-Pfade erforderlich sind. Zieldateinamen folgen dem Format targets/ NAME / NAME .cmake und das Ziel wird mithilfe des Build-Parameters DEQP_TARGET ausgewählt.

Dateipfade in Zieldateien beziehen sich auf das Basisverzeichnis deqp , nicht auf das Verzeichnis targets/ NAME . Die folgenden Standardvariablen können je nach Ziel-Build-Datei festgelegt werden.

Variable	Beschreibung
`DEQP_TARGET_NAME`	Zielname (wird in Testprotokolle aufgenommen)
`DEQP_SUPPORT_GLES2`	Ob GLES2 unterstützt wird (Standard: AUS)
`DEQP_GLES2_LIBRARIES`	GLES2-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird)
`DEQP_SUPPORT_GLES3`	Ob GLES3.x unterstützt wird (Standard: AUS)
`DEQP_GLES3_LIBRARIES`	GLES3.x-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird)
`DEQP_SUPPORT_VG`	Ob OpenVG unterstützt wird (Standard: AUS)
`DEQP_OPENVG_LIBRARIES`	OpenVG-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird)
`DEQP_SUPPORT_EGL`	Ob EGL unterstützt wird (Standard: AUS)
`DEQP_EGL_LIBRARIES`	EGL-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird)
`DEQP_PLATFORM_LIBRARIES`	Für die Verlinkung sind zusätzlich plattformspezifische Bibliotheken erforderlich
`DEQP_PLATFORM_COPY_LIBRARIES`	Liste der Bibliotheken, die in jedes Testbinär-Build-Verzeichnis kopiert werden. Kann zum Kopieren von Bibliotheken verwendet werden, die zum Ausführen von Tests benötigt werden, sich aber nicht im Standardsuchpfad befinden.
`TCUTIL_PLATFORM_SRCS`	Liste der Plattformportquellen. Standardquellen werden basierend auf den Funktionen und dem Betriebssystem bestimmt. Hinweis: Pfade sind relativ zu: `framework/platform`

Die Ziel-Build-Datei kann mithilfe der CMake-Funktionen include_directories() und link_directories() zusätzliche Include- oder Linkpfade hinzufügen.

Win32-Build

Der einfachste Weg, Deqp-Module für Windows zu erstellen, ist die Verwendung des CMake-Build-Systems. Sie benötigen CMake 2.6.12 oder neuer und den Microsoft Visual C/C++-Compiler. Das Deqp wurde mit Visual Studio 2013 getestet.

Visual Studio-Projektdateien können mit dem folgenden Befehl generiert werden:

cmake path\to\src\deqp -G "Visual Studio 12"

Ein 64-Bit-Build kann erstellt werden, indem als Build-Generator „Visual Studio VERSION Win64“ ausgewählt wird:

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

Sie können NMake-Makefiles auch mit der Option -G "NMake Makefiles" sowie dem Build-Typ ( -DCMAKE_BUILD_TYPE="Debug" oder "Release" ) generieren.

Erstellung von Renderkontexten

Der Rendering-Kontext kann entweder mit WGL oder mit EGL unter Windows erstellt werden.

WGL-Unterstützung

Alle Win32-Binärdateien unterstützen die GL-Kontexterstellung mit WGL, da hierfür nur Standardbibliotheken erforderlich sind. Der WGL-Kontext kann mit dem Befehlszeilenargument --deqp-gl-context-type=wgl ausgewählt werden. Im WGL-Modus verwendet der Deqp die Erweiterung WGL_EXT_create_context_es_profile , um OpenGL ES-Kontexte zu erstellen. Es wurde getestet, dass es mit den neuesten Treibern von NVIDIA und Intel funktioniert. AMD-Treiber unterstützen die erforderliche Erweiterung nicht.

EGL-Unterstützung

Der DEQP wird mit dynamischem Laden für EGL unter Windows erstellt, wenn DEQP_SUPPORT_EGL aktiviert ist. Dies ist bei den meisten Zielen die Standardeinstellung. Wenn der Host dann über EGL-Bibliotheken verfügt, ist es möglich, mit ihnen Tests mit dem Befehlszeilenparameter --deqp-gl-context-type=egl auszuführen

Android-Build

Der Android-Build verwendet CMake-Build-Skripte zum Erstellen des nativen Testcodes. Java-Teile, also der Test Execution Server und der Test Application Stub, werden mit den Standard-Android-Build-Tools kompiliert.

Um Deqp-Testprogramme für Android mit den bereitgestellten Build-Skripten zu kompilieren, benötigen Sie:

Die neueste Version des Android NDK ; Die Datei android/scripts/common.py listet die erforderliche Version auf
Eigenständiges Android-SDK mit installierten API 13-, SDK-Tools-, SDK-Plattform-Tools- und SDK-Build-Tools- Paketen
Apache Ant 1.9.4 (erforderlich für den Java-Code-Build)
CMake 2.8.12 oder neuer
Python 2.6 oder neuer in der 2.x-Serie; Python 3.x wird nicht unterstützt
Für Windows: Entweder NMake oder JOM in PATH
- JOM ermöglicht schnellere Builds
Optional: Ninja make wird auch unter Linux unterstützt

Ant- und SDK-Binärdateien werden basierend auf der Umgebungsvariablen PATH mit bestimmten vorrangigen Standardwerten gefunden. Die Logik wird von android/scripts/common.py gesteuert.

Das NDK-Verzeichnis muss entweder ~/android-ndk- VERSION oder C:/android/android-ndk- VERSION sein oder über die Umgebungsvariable ANDROID_NDK_PATH definiert werden.

Deqp-Komponenten auf dem Gerät, der Testausführungsdienst und Testprogramme werden durch Ausführen des Skripts android/scripts/build.py erstellt. Die endgültige APK-Datei wird in android/package/bin erstellt und kann mit dem install.py Skript installiert werden. Wenn der Befehlszeilen-Executor verwendet wird, wird der ExecService mit dem Skript launch.py auf dem Gerät über ADB gestartet. Die Skripte können von jedem Verzeichnis aus ausgeführt werden.

Linux-Build

Testbinärdateien und Befehlszeilen-Dienstprogramme können für Linux erstellt werden, indem Makefiles mit CMake generiert werden. Es gibt mehrere vordefinierte Build-Ziele, die beim Erstellen für Linux nützlich sind.

Ziel aufbauen	Beschreibung
`default`	Standardziel, das die Introspektion der CMake-Plattform verwendet, um die Unterstützung für verschiedene APIs zu ermitteln.
`x11_glx`	Verwendet GLX zum Erstellen von OpenGL (ES)-Kontexten.
`x11_egl`	Verwendet EGL zum Erstellen von OpenGL (ES)-Kontexten.
`x11_egl_glx`	Unterstützt sowohl GLX als auch EGL mit X11.

Verwenden Sie immer -DCMAKE_BUILD_TYPE=<Debug|Release> um den Build-Typ zu definieren. Release ist eine gute Standardeinstellung. Ohne sie wird ein standardmäßiger, nicht optimierter Release-Build erstellt.

Die Befehlszeilenargumente -DCMAKE_C_FLAGS und -DCMAKE_CXX_FLAGS können verwendet werden, um zusätzliche Argumente an den Compiler zu übergeben. Beispielsweise kann der 32-Bit- oder 64-Bit-Build durch Setzen -DCMAKE_C(XX)_FLAGS="-m32" bzw. "-m64" erfolgen. Wenn nicht angegeben, wird die native Architektur der Toolchain verwendet, normalerweise 64-Bit in der 64-Bit-Toolchain.

Die Argumente -DCMAKE_LIBRARY_PATH und -DCMAKE_INCLUDE_PATH können für CMake verwendet werden, um CMake zusätzliche Bibliothek bereitzustellen oder Suchpfade einzuschließen.

Ein Beispiel für eine vollständige Befehlszeile, die zum Ausführen eines 32-Bit-Debug-Builds für Treiberheader und -bibliotheken an einem benutzerdefinierten Speicherort verwendet wird, ist das Folgende:

cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32"
-DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib"
-DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"
make -j4

Cross-Kompilierung

Cross-Compiling kann durch die Verwendung einer CMake-Toolchain-Datei erreicht werden. Die Toolchain-Datei gibt den zu verwendenden Compiler sowie benutzerdefinierte Suchpfade für Bibliotheken und Header an. Mehrere Toolchain-Dateien für gängige Szenarien sind im Release-Paket im Verzeichnis framework/delibs/cmake enthalten.

Zusätzlich zu den standardmäßigen CMake-Variablen können die folgenden deqp-spezifischen Variablen durch die Toolchain-Datei festgelegt werden. CMake kann DE_OS , DE_COMPILER und DE_PTR_SIZE normalerweise korrekt erkennen, DE_CPU muss jedoch durch die Toolchain-Datei festgelegt werden.

Variable	Beschreibung
`DE_OS`	Betriebssystem. Unterstützte Werte sind: `DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS`
`DE_COMPILER`	Compilertyp. Unterstützte Werte sind: `DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG`
`DE_CPU`	CPU-Typ. Unterstützte Werte sind: `DE_CPU_ARM, DE_CPU_X86` .
`DE_PTR_SIZE`	sizeof(void*) auf der Plattform. Unterstützte Werte sind: 4 und 8

Die Toolchain-Datei kann über den Build-Parameter CMAKE_TOOLCHAIN_FILE ausgewählt werden. Folgendes würde beispielsweise Makefiles für einen Build mit dem CodeSourcery-Cross-Compiler für ARM/Linux erstellen:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

Laufzeitverknüpfung von GLES- und EGL-Bibliotheken

Der DEQP benötigt während der Verknüpfung keine Einstiegspunkte der zu testenden API. Der Testcode greift immer über Funktionszeiger auf die APIs zu. Einstiegspunkte können dann zur Laufzeit dynamisch geladen werden oder der Plattform-Port kann sie zur Linkzeit bereitstellen.

Wenn die Unterstützung für eine API in den Build-Einstellungen aktiviert ist und keine Linkbibliotheken bereitgestellt werden, lädt der Deqp die erforderlichen Einstiegspunkte zur Laufzeit. Wenn die statische Verknüpfung gewünscht ist, stellen Sie die erforderlichen Linkbibliotheken in der Build-Konfigurationsvariablen DEQP_<API>_LIBRARIES bereit.

Portieren Sie das Testframework

Die Portierung des DeQP umfasst drei Schritte: Anpassung der Basisportabilitätsbibliotheken, Implementierung von Test-Framework-Plattform-Integrationsschnittstellen und Portierung des Ausführungsdienstes.

In der folgenden Tabelle sind die Standorte für wahrscheinliche Portierungsänderungen aufgeführt. Alles, was darüber hinausgeht, dürfte exotisch sein.

Standort	Beschreibung
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	Alle erforderlichen Implementierungen von betriebssystemspezifischem Code.
`framework/qphelper/qpCrashHandler.c`	Optional: Implementierung für Ihr Betriebssystem.
`framework/qphelper/qpWatchDog.c`	Implementierung für Ihr Betriebssystem. Die aktuelle Version basiert auf `dethread` und der Standard-C-Bibliothek.
`framework/platform`	Ein neuer Plattform-Port und ein neuer Anwendungs-Stub können wie unter Test-Framework-Plattform-Port beschrieben implementiert werden.

Basisportabilitätsbibliotheken

Die Basisportabilitätsbibliotheken unterstützen bereits Windows, die meisten Linux-Varianten, Mac OS, iOS und Android. Wenn das Testziel auf einem dieser Betriebssysteme läuft, besteht höchstwahrscheinlich überhaupt keine Notwendigkeit, die Basisportabilitätsbibliotheken zu berühren.

Test-Framework-Plattform-Port

Der Plattformport des DEQP-Testframeworks erfordert zwei Komponenten: einen Anwendungseinstiegspunkt und eine Plattformschnittstellenimplementierung.

Der Anwendungseinstiegspunkt ist für die Erstellung des Plattformobjekts, die Erstellung eines Befehlszeilenobjekts ( tcu::CommandLine ), das Öffnen eines Testprotokolls ( tcu::TestLog ) und die Iteration der Testanwendung ( tcu::App ) verantwortlich. Wenn das Zielbetriebssystem einen standardmäßigen main() Einstiegspunkt unterstützt, kann tcuMain.cpp als Einstiegspunktimplementierung verwendet werden.

Die Deqp-Plattform-API wird in den folgenden Dateien ausführlich beschrieben.

Datei	Beschreibung
`framework/common/tcuPlatform.hpp`	Basisklasse für alle Plattformports
`framework/opengl/gluPlatform.hpp`	OpenGL-Plattformschnittstelle
`framework/egl/egluPlatform.hpp`	EGL-Plattformschnittstelle
`framework/platform/tcuMain.cpp`	Standard-Einstiegspunkt für Anwendungen

Die Basisklasse für alle Plattformports ist tcu::Platform . Der Plattformport kann optional GL- und EGL-spezifische Schnittstellen unterstützen. In der folgenden Tabelle finden Sie einen Überblick darüber, was zum Ausführen der Tests implementiert werden muss.

Modul	Schnittstelle
OpenGL (ES)-Testmodule	GL-Plattformschnittstelle
EGL-Testmodul	EGL-Plattformschnittstelle

Detaillierte Anweisungen zur Implementierung von Plattformports finden Sie in den Headern der Portierungsschicht.

Testdurchführungsservice

Um die Testausführungsinfrastruktur von deqp oder den Befehlszeilen-Executor verwenden zu können, muss der Testausführungsdienst auf dem Ziel verfügbar sein. Eine portable C++-Implementierung des Dienstes wird im Verzeichnis execserver bereitgestellt. Die eigenständige Binärdatei wird als Teil des Deqp-Testmodul-Builds für PC-Ziele erstellt. Sie können execserver/CMakeLists.txt ändern, um einen Build auf anderen Zielen zu ermöglichen.

Die C++-Version des Testausführungsdienstes akzeptiert zwei Befehlszeilenparameter:

--port=<port> legt den TCP-Port fest, auf dem der Server lauscht. Der Standardwert ist 50016.
--single beendet den Serverprozess, wenn der Client die Verbindung trennt. Standardmäßig bleibt der Serverprozess aktiv, um weitere Testausführungsanforderungen zu bearbeiten.

Führen Sie die Tests durch

Auf dieser Seite finden Sie Anweisungen zum Ausführen von Deqp-Tests in Linux- und Windows-Umgebungen, zum Verwenden von Befehlszeilenargumenten und zum Arbeiten mit dem Android-Anwendungspaket.

Linux- und Windows-Umgebungen

Kopieren Sie zunächst die folgenden Dateien und Verzeichnisse auf das Ziel.

Modul	Verzeichnis	Ziel
Ausführungsserver	`build/execserver/execserver`	`<dst>/execserver`
EGL-Modul	`build/modules/egl/deqp-egl`	`<dst>/deqp-egl`
GLES2-Modul	`build/modules/gles2/deqp-gles2`	`<dst>/deqp-gles2`
GLES2-Modul	`data/gles2`	`<dst>/gles2`
GLES3-Modul	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
GLES3-Modul	`data/gles3`	`<dst>/gles3`
GLES3.1-Modul	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
GLES3.1-Modul	`data/gles31`	`<dst>/gles31`
GLES3.2-Modul	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
GLES3.2-Modul	`data/gles32`	`<dst>/gles32`

Sie können den Ausführungsdienst bereitstellen und Binärdateien überall im Zieldateisystem testen. Testbinärdateien erwarten jedoch, dass Datenverzeichnisse im aktuellen Arbeitsverzeichnis gefunden werden. Wenn Sie bereit sind, starten Sie den Testausführungsdienst auf dem Zielgerät. Einzelheiten zum Starten des Dienstes finden Sie unter Testausführungsdienst .

Kommandozeilenargumente

In der folgenden Tabelle sind Befehlszeilenargumente aufgeführt, die sich auf die Ausführung aller Testprogramme auswirken.

Streit	Beschreibung
`--deqp-case=<casename>`	Führen Sie Fälle aus, die einem bestimmten Muster entsprechen. Platzhalter (*) wird unterstützt.
`--deqp-log-filename=<filename>`	Schreiben Sie die Testergebnisse in die Datei, deren Namen Sie angeben. Der Testausführungsdienst legt den Dateinamen fest, wenn ein Test gestartet wird.
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	Fallliste aus stdin oder einem bestimmten Argument lesen. Der Testausführungsdienst legt das Argument entsprechend der empfangenen Ausführungsanforderung fest. Eine Beschreibung des Falllistenformats finden Sie im nächsten Abschnitt.
`--deqp-test-iteration-count=<count>`	Überschreiben Sie die Iterationsanzahl für Tests, die eine variable Anzahl von Iterationen unterstützen.
`--deqp-base-seed=<seed>`	Basis-Seed für die Testfälle, die Randomisierung verwenden.

GLES2- und GLES3-spezifische Argumente

In der folgenden Tabelle sind die GLES2- und GLES3-spezifischen Argumente aufgeführt.

Streit	Beschreibung
`--deqp-gl-context-type=<type>`	OpenGL-Kontexttyp. Die verfügbaren Kontexttypen hängen von der Plattform ab. Auf Plattformen, die EGL unterstützen, kann der Wert `egl` zur Auswahl des EGL-Kontexts verwendet werden.
`--deqp-gl-config-id=<id>`	Führen Sie Tests für die bereitgestellte GL-Konfigurations-ID durch. Die Interpretation ist plattformabhängig. Auf der EGL-Plattform ist dies die EGL-Konfigurations-ID.
`--deqp-gl-config-name=<name>`	Führen Sie Tests für eine benannte GL-Konfiguration durch. Die Interpretation ist plattformabhängig. Für EGL lautet das Format `rgb(a)<bits>d<bits>s<bits>` . Beispielsweise wählt der Wert `rgb888s8` die erste Konfiguration aus, bei der der Farbpuffer RGB888 ist und der Schablonenpuffer 8 Bit hat.
`--deqp-gl-context-flags=<flags>`	Erstellt einen Kontext. Geben Sie `robust` oder `debug` an.
`--deqp-surface-width=<width> --deqp-surface-height=<height>`	Versuchen Sie, eine Oberfläche mit einer bestimmten Größe zu erstellen. Die Unterstützung hierfür ist optional.
`--deqp-surface-type=<type>`	Verwenden Sie einen bestimmten Oberflächentyp als Haupttest-Rendering-Ziel. Mögliche Typen sind `window` , `pixmap` , `pbuffer` und `fbo` .
`--deqp-screen-rotation=<rotation>`	Bildschirmausrichtung in 90-Grad-Schritten für Plattformen, die dies unterstützen.

Testfalllistenformat

Die Testfallliste kann in zwei Formaten angegeben werden. Die erste Möglichkeit besteht darin, den vollständigen Namen jedes Tests in einer separaten Zeile in einer Standard-ASCII-Datei aufzulisten. Wenn die Testsätze wachsen, können sich wiederholende Präfixe umständlich sein. Um eine Wiederholung der Präfixe zu vermeiden, verwenden Sie die unten gezeigte Trie-Syntax (auch als Präfixbaum bezeichnet).

{nodeName{firstChild{…},…lastChild{…}}}

Zum Beispiel:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

Übersetzt in die folgenden zwei Testfälle:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

Das Android-Anwendungspaket enthält alle erforderlichen Komponenten, einschließlich des Testausführungsdienstes, Testbinärdateien und Datendateien. Die Testaktivität ist eine NativeActivity , die EGL verwendet (erfordert Android 3.2 oder höher).

Das Anwendungspaket kann mit dem folgenden Befehl installiert werden (der angezeigte Name ist der Name des APK im Android CTS-Paket; der Name hängt vom Build ab):

adb –d install –r com.drawelements.deqp.apk

Um den Testausführungsdienst zu starten und die Portweiterleitung einzurichten, verwenden Sie Folgendes:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

Debug-Drucke können aktiviert werden, indem vor Beginn der Tests Folgendes ausgeführt wird:

adb –d shell setprop log.tag.dEQP DEBUG

Führen Sie Tests auf Android ohne Android CTS durch

Um die Testausführungsaktivität manuell zu starten, erstellen Sie eine Android-Absicht, die auf android.app.NativeActivity abzielt. Die Aktivitäten finden Sie im Paket com.drawelements.deqp . Die Befehlszeile muss als zusätzlicher String mit dem Schlüssel "cmdLine" im Intent bereitgestellt werden.

Ein Testprotokoll wird in /sdcard/dEQP-log.qpa geschrieben. Sollte der Testlauf nicht normal starten, stehen im Geräteprotokoll zusätzliche Debug-Informationen zur Verfügung.

Sie können eine Aktivität über die Befehlszeile mit dem Dienstprogramm am starten. Um beispielsweise dEQP-GLES2.info Tests auf einer Plattform auszuführen, die NativeActivity, verwenden Sie die folgenden Befehle.

adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'

Debuggen Sie auf Android

Um die Tests unter dem GDB-Debugger auf Android auszuführen, kompilieren und installieren Sie zunächst den Debug-Build, indem Sie die folgenden zwei Skripte ausführen:

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

Nachdem der Debug-Build auf dem Gerät installiert wurde, führen Sie den folgenden Befehl aus, um die Tests unter GDB zu starten, die auf dem Host ausgeführt werden:

python android/scripts/debug.py \
--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"

Die deqp-Befehlszeile hängt von den auszuführenden Testfällen und anderen erforderlichen Parametern ab. Das Skript fügt zu Beginn der Deqp-Ausführung einen Standardhaltepunkt hinzu ( tcu::App::App ).

Das debug.py Skript akzeptiert mehrere Befehlszeilenargumente für Aktionen wie das Festlegen von Haltepunkten für das Debuggen, gdbserver-Verbindungsparameter und Pfade zu zusätzlichen zu debuggenden Binärdateien (verwenden Sie debug.py --help für alle Argumente und Erklärungen). Das Skript kopiert außerdem einige Standardbibliotheken vom Zielgerät, um Symbollisten abzurufen.

Um den Treibercode schrittweise durchzugehen (z. B. wenn die GDB die Speicherorte der Binärdateien mit vollständigen Debug-Informationen kennen muss), fügen Sie über die Befehlszeilenparameter debug.py weitere Bibliotheken hinzu. Dieses Skript schreibt ab Zeile 132 der Skriptdatei eine Konfigurationsdatei für die GDB. Sie können zusätzliche Pfade zu Binärdateien usw. angeben, aber die Angabe korrekter Befehlszeilenparameter sollte ausreichen.

Hinweis: Unter Windows erfordert die GDB-Binärdatei libpython2.7.dll . Fügen Sie vor dem Starten debug.py <path-to-ndk>/prebuilt/windows/bin zur PATH-Variablen hinzu.

Hinweis: Das Debuggen von nativem Code funktioniert nicht auf Standard-Android 4.3; Informationen zu Problemumgehungen finden Sie in diesem öffentlichen Fehler . Android 4.4 und höher enthalten diesen Fehler nicht.

Automatisieren Sie die Tests

Deqp-Testmodule können auf verschiedene Weise in automatisierte Testsysteme integriert werden. Der beste Ansatz hängt von der vorhandenen Testinfrastruktur und Zielumgebung ab.

Die primäre Ausgabe eines Testlaufs ist immer die Testprotokolldatei, also die Datei mit einem .qpa Postfix. Vollständige Testergebnisse können aus dem Testprotokoll analysiert werden. Die Konsolenausgabe dient lediglich der Fehlerbehebung und ist möglicherweise nicht auf allen Plattformen verfügbar.

Testbinärdateien können direkt von einem Testautomatisierungssystem aufgerufen werden. Die Testbinärdatei kann für einen bestimmten Fall, für einen Testsatz oder für alle verfügbaren Tests gestartet werden. Wenn während der Ausführung ein schwerwiegender Fehler auftritt (z. B. bestimmte API-Fehler oder ein Absturz), wird die Testausführung abgebrochen. Für Regressionstests besteht der beste Ansatz darin, die Testbinärdateien für einzelne Fälle oder kleine Testmengen separat aufzurufen, um auch bei hartem Scheitern Teilergebnisse zur Verfügung zu haben.

Das deqp verfügt über Befehlszeilen-Testausführungstools, die in Kombination mit dem Ausführungsdienst verwendet werden können, um eine robustere Integration zu erreichen. Der Ausführende erkennt die Beendigung des Testprozesses und setzt die Testausführung beim nächsten verfügbaren Fall fort. Von der gesamten Testsitzung wird eine einzelne Protokolldatei erstellt. Dieses Setup ist ideal für leichte Testsysteme, die keine Wiederherstellungsfunktionen nach einem Absturz bieten.

Tools zur Ausführung von Befehlszeilentests

Das aktuelle Befehlszeilen-Toolset umfasst ein Remote-Testausführungstool, einen Testprotokoll-Vergleichsgenerator für die Regressionsanalyse, einen Testprotokoll-zu-CSV-Konverter, einen Testprotokoll-zu-XML-Konverter und einen Testprotokoll-zu-JUnit-Konverter .

Der Quellcode für diese Tools befindet sich im executor Verzeichnis und die Binärdateien sind im Verzeichnis <builddir>/executor integriert.

Befehlszeilentest-Ausführer

Der Befehlszeilen-Test-Executor ist ein portables C++-Tool zum Starten eines Testlaufs auf einem Gerät und zum Sammeln der daraus resultierenden Protokolle über TCP/IP. Der Executor kommuniziert mit dem Ausführungsdienst (Execserver) auf dem Zielgerät. Zusammen bieten sie Funktionen wie die Wiederherstellung nach Testprozessabstürzen. Die folgenden Beispiele veranschaulichen die Verwendung des Befehlszeilen-Test-Executors (verwenden Sie --help für weitere Details):

Beispiel 1: Führen Sie GLES2-Funktionstests auf einem Android-Gerät aus

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

Beispiel 2: Setzen Sie einen teilweisen OpenGL ES 2-Testlauf lokal fort

executor --start-server=execserver/execserver --port=50016
--binaryname=deqp-gles2 --workdir=modules/opengl
--caselistdir=caselists
--testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa
--out=BatchResult.qpa

Testprotokoll CSV-Export und Vergleich

Das deqp verfügt über ein Tool zum Konvertieren von Testprotokollen ( qpa Dateien) in CSV-Dateien. Die CSV-Ausgabe enthält eine Liste von Testfällen und deren Ergebnissen. Das Tool kann auch zwei oder mehr Batch-Ergebnisse vergleichen und nur die Testfälle auflisten, die in den Eingabe-Batch-Ergebnissen unterschiedliche Statuscodes haben. Beim Vergleich wird auch die Anzahl der übereinstimmenden Fälle gedruckt.

Die Ausgabe im CSV-Format ist sehr praktisch für die Weiterverarbeitung mit Standard-Befehlszeilenprogrammen oder mit einem Tabellenkalkulationseditor. Ein zusätzliches, für Menschen lesbares Klartextformat kann mit dem folgenden Befehlszeilenargument ausgewählt werden: --format=text

Beispiel 1: Testprotokoll im CSV-Format exportieren

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

Beispiel 2: Unterschiede der Testergebnisse zwischen zwei Testprotokollen auflisten

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Hinweis: Das Argument --value=code gibt den Testergebniscode aus, z. B. „Bestanden“ oder „Nicht bestanden“. Das Argument --value=details wählt die weitere Erklärung des Ergebnisses oder numerischen Werts aus, der durch einen Leistungs-, Fähigkeits- oder Genauigkeitstest erzeugt wird.

Testprotokoll-XML-Export

Testprotokolldateien können mit dem Dienstprogramm testlog-to-xml in gültige XML-Dokumente konvertiert werden. Es werden zwei Ausgabemodi unterstützt:

Separater Dokumentenmodus, bei dem jeder Testfall und das zusammenfassende Dokument caselist.xml in ein Zielverzeichnis geschrieben werden
Einzeldateimodus, bei dem alle Ergebnisse in der .qpa Datei in ein einzelnes XML-Dokument geschrieben werden.

Exportierte Testprotokolldateien können mithilfe eines XML-Stylesheets in einem Browser angezeigt werden. Beispiel-Stylesheet-Dokumente ( testlog.xsl und testlog.css ) werden im Verzeichnis doc/testlog-stylesheet bereitgestellt. Um die Protokolldateien in einem Browser darzustellen, kopieren Sie die beiden Stylesheet-Dateien in dasselbe Verzeichnis, in dem sich die exportierten XML-Dokumente befinden.

Wenn Sie Google Chrome verwenden, muss auf die Dateien über HTTP zugegriffen werden, da Chrome aus Sicherheitsgründen den Zugriff auf lokale Dateien einschränkt. Die Standard-Python-Installation umfasst einen einfachen HTTP-Server, der gestartet werden kann, um das aktuelle Verzeichnis mit dem Befehl python –m SimpleHTTPServer 8000 bereitzustellen. Richten Sie nach dem Starten des Servers einfach den Chrome-Browser auf http://localhost:8000 , um das Testprotokoll anzuzeigen.

Konvertierung in ein JUnit-Testprotokoll

Viele Testautomatisierungssysteme können Testlauf-Ergebnisberichte aus der JUnit-Ausgabe generieren. Die Deqp-Testprotokolldateien können mit dem Tool testlog-to-junit in das JUnit-Ausgabeformat konvertiert werden.

Das Tool unterstützt derzeit nur die Übersetzung des Testfallurteils. Da JUnit nur „bestanden“- und „nicht bestanden“-Ergebnisse unterstützt, wird ein bestandenes Ergebnis des Deqp auf „JUnit-bestanden“ abgebildet und andere Ergebnisse werden als Fehlschläge betrachtet. Der ursprüngliche Deqp-Ergebniscode ist in der JUnit-Ausgabe verfügbar. Andere Daten wie Protokollmeldungen und Ergebnisbilder bleiben bei der Konvertierung nicht erhalten.

Nutzen Sie spezielle Testgruppen

Einige Testgruppen benötigen oder unterstützen möglicherweise spezielle Befehlszeilenoptionen oder erfordern bei der Verwendung auf bestimmten Systemen besondere Sorgfalt.

Stresstests zur Speicherzuordnung

Bei Belastungstests für die Speicherzuordnung werden Bedingungen wegen unzureichendem Arbeitsspeicher überprüft, indem bestimmte Ressourcen wiederholt zugewiesen werden, bis der Treiber einen Fehler wegen unzureichendem Arbeitsspeicher meldet.

Auf bestimmten Plattformen wie Android und den meisten Linux-Varianten kann Folgendes auftreten: Das Betriebssystem bricht möglicherweise den Testprozess ab, anstatt einem Treiber die Behandlung oder anderweitige Bereitstellung eines Fehlers wegen unzureichendem Arbeitsspeicher zu ermöglichen. Auf solchen Plattformen sind Tests, die Fehler wegen unzureichendem Arbeitsspeicher verursachen sollen, standardmäßig deaktiviert und müssen mit dem Befehlszeilenargument --deqp-test-oom=enable aktiviert werden. Es wird empfohlen, solche Tests manuell durchzuführen, um zu überprüfen, ob sich das System unter Ressourcendruck korrekt verhält. In einer solchen Situation sollte ein Absturz des Testprozesses jedoch als bestanden gewertet werden.

Testgruppen

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Lang andauernde Rendering-Stresstests

Rendering-Stresstests sollen Robustheitsprobleme bei anhaltender Rendering-Belastung aufdecken. Standardmäßig führen die Tests nur wenige Iterationen aus. Sie können jedoch so konfiguriert werden, dass sie unbegrenzt ausgeführt werden, indem Sie das Befehlszeilenargument --deqp-test-iteration-count=-1 angeben. Der Test-Watchdog sollte deaktiviert sein ( --deqp-watchdog=disable ), wenn diese Tests über einen längeren Zeitraum ausgeführt werden.

Testgruppen

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*