Tests du programme de qualité drawElements

AOSP inclut la suite de tests GPU drawElements Quality Program (deqp) à l'adresse https://android.googlesource.com/platform/external/deqp. Cette page explique comment déployer la suite de tests deqp dans un nouvel environnement.

Pour travailler avec le dernier code envoyé, utilisez la branche deqp-dev. Pour le code qui correspond à une version spécifique d'Android CTS, utilisez la branche release-code-name-release (par exemple, pour Android 6.0, utilisez la branche marshmallow-release).

Mise en page de la source

La mise en page du code source pour les modules de test deqp et les bibliothèques associées est indiquée dans le tableau ci-dessous (la liste n'est pas exhaustive, mais met en évidence les répertoires les plus importants).

Composants Open Source

Le deqp utilise libpng et zlib, qui peuvent être récupérés à l'aide du script platform/external/deqp/external/fetch_sources.py ou via git depuis platform/external/[libpng,zlib].

Créer des programmes de test

Le framework de test a été conçu pour être portable. Les seules exigences obligatoires sont la prise en charge complète de C++ et des bibliothèques système standards pour les E/S, les threads et les sockets.

Système de compilation CMake

Les sources deqp disposent de scripts de compilation pour CMake, qui est l'outil privilégié pour compiler les programmes de test.

CMake est un système de compilation Open Source compatible avec plusieurs plates-formes et chaînes d'outils. CMake génère des fichiers makefile natifs ou des fichiers de projet IDE à partir de fichiers de configuration indépendants de la cible. Pour en savoir plus sur CMake, veuillez consulter la documentation CMake.

CMake prend en charge et recommande les compilations hors arborescence source. Autrement dit, vous devez toujours créer des fichiers makefile ou de projet dans un répertoire de compilation distinct en dehors de l'arborescence source. CMake ne dispose d'aucune cible "distclean". Vous devez donc supprimer manuellement tous les fichiers générés par CMake.

Les options de configuration sont fournies à CMake à l'aide de la syntaxe -DOPTION_NAME=VALUE. Vous trouverez ci-dessous quelques options couramment utilisées pour deqp.

Créer un fichier de compilation cible

Le système de compilation deqp est configuré pour les nouvelles cibles à l'aide de fichiers de compilation cibles. Un fichier de compilation cible définit les fonctionnalités prises en charge par la plate-forme, ainsi que les bibliothèques ou les chemins d'inclusion supplémentaires requis. Les noms de fichiers cibles suivent le format targets/NAME/NAME.cmake et la cible est sélectionnée à l'aide du paramètre de compilation DEQP_TARGET.

Les chemins d'accès aux fichiers cibles sont relatifs au répertoire de base deqp, et non au répertoire targets/NAME. Les variables standards suivantes peuvent être définies par le fichier de compilation cible.

Le fichier de compilation cible peut ajouter des chemins d'inclusion ou de lien supplémentaires à l'aide des fonctions CMake include_directories() et link_directories().

Build Win32

Le moyen le plus simple de créer des modules deqp pour Windows consiste à utiliser le système de compilation CMake. Vous aurez besoin de CMake 2.6.12 ou version ultérieure, ainsi que du compilateur Microsoft Visual C/C++. Le deqp a été testé avec Visual Studio 2013.

Les fichiers de projet Visual Studio peuvent être générés avec la commande suivante :

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

Pour créer une version 64 bits, sélectionnez "Visual Studio VERSION Win64" comme générateur de compilation :

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

Vous pouvez également générer des fichiers make NMake avec l'option -G "NMake Makefiles" ainsi que le type de compilation (-DCMAKE_BUILD_TYPE="Debug" ou "Release").

Création du contexte de rendu

Le contexte de rendu peut être créé avec WGL ou EGL sur Windows.

Compatibilité avec WGL

Tous les binaires Win32 sont compatibles avec la création de contexte GL avec WGL, car ils ne nécessitent que des bibliothèques standards. Le contexte WGL peut être sélectionné à l'aide de l'argument de ligne de commande --deqp-gl-context-type=wgl. En mode WGL, deqp utilise l'extension WGL_EXT_create_context_es_profile pour créer des contextes OpenGL ES. La compatibilité avec les derniers pilotes NVIDIA et Intel a été testée. Les pilotes AMD ne sont pas compatibles avec l'extension requise.

Prise en charge d'EGL

deqp est conçu avec un chargement dynamique pour EGL sur Windows si DEQP_SUPPORT_EGL est activé. Il s'agit de la valeur par défaut pour la plupart des cibles. Ensuite, si l'hôte dispose de bibliothèques EGL, il est possible d'exécuter des tests avec elles à l'aide du paramètre de ligne de commande : --deqp-gl-context-type=egl

Build Android

La compilation Android utilise des scripts de compilation CMake pour compiler le code de test natif. Les parties Java, à savoir le serveur d'exécution des tests et le stub de l'application de test, sont compilées à l'aide des outils de compilation Android standards.

Pour compiler les programmes de test deqp pour Android avec les scripts de compilation fournis, vous aurez besoin des éléments suivants :

• La dernière version du NDK Android. Le fichier android/scripts/common.py indique la version requise.
• SDK Android autonome avec les packages SDK Tools, SDK Platform-tools et SDK Build-tools installés (API 13)
• Apache Ant 1.9.4 (requis par la compilation du code Java)
• CMake 2.8.12 ou version ultérieure
• Python 2.6 ou version ultérieure de la série 2.x (Python 3.x n'est pas compatible)
• Pour Windows : NMake ou JOM dans PATH
  • JOM permet des compilations plus rapides
• Facultatif : Ninja make est également compatible avec Linux.

Les binaires Ant et du SDK sont localisés en fonction de la variable d'environnement PATH avec certains paramètres par défaut prioritaires. La logique est contrôlée par android/scripts/common.py.

Le répertoire NDK doit être ~/android-ndk-VERSION ou C:/android/android-ndk-VERSION, ou être défini via la variable d'environnement ANDROID_NDK_PATH.

Les composants sur l'appareil Deqp, le service d'exécution des tests et les programmes de test sont créés en exécutant le script android/scripts/build.py. Le fichier .apk final est créé dans android/package/bin et peut être installé par le script install.py. Si l'exécuteur de ligne de commande est utilisé, ExecService est lancé avec le script launch.py sur l'appareil via ADB. Les scripts peuvent être exécutés à partir de n'importe quel répertoire.

Compilation Linux

Les binaires de test et les utilitaires de ligne de commande peuvent être créés pour Linux en générant des fichiers make à l'aide de CMake. Plusieurs cibles de compilation prédéfinies sont utiles lors de la compilation pour Linux.

Utilisez toujours -DCMAKE_BUILD_TYPE=<Debug|Release> pour définir le type de compilation. Release est une bonne valeur par défaut. Sans cela, une version de publication par défaut et non optimisée est créée.

Les arguments de ligne de commande -DCMAKE_C_FLAGS et -DCMAKE_CXX_FLAGS peuvent être utilisés pour transmettre des arguments supplémentaires au compilateur. Par exemple, la compilation 32 bits ou 64 bits peut être effectuée en définissant respectivement -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64". Si aucune valeur n'est spécifiée, l'architecture native de la chaîne d'outils est utilisée (généralement 64 bits sur la chaîne d'outils 64 bits).

Les arguments -DCMAKE_LIBRARY_PATH et -DCMAKE_INCLUDE_PATH peuvent être utilisés pour que CMake fournisse des chemins de recherche supplémentaires pour les bibliothèques ou les inclusions.

Voici un exemple de ligne de commande complète utilisée pour effectuer une compilation de débogage 32 bits par rapport aux en-têtes et aux bibliothèques de pilotes dans un emplacement personnalisé :

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

Compilation croisée

La compilation croisée peut être effectuée à l'aide d'un fichier de chaîne d'outils CMake. Le fichier de chaîne d'outils spécifie le compilateur à utiliser, ainsi que les chemins de recherche personnalisés pour les bibliothèques et les en-têtes. Plusieurs fichiers de chaîne d'outils pour les scénarios courants sont inclus dans le package de version, dans le répertoire framework/delibs/cmake.

En plus des variables CMake standards, les variables spécifiques à deqp suivantes peuvent être définies par le fichier de chaîne d'outils. CMake peut généralement détecter correctement DE_OS, DE_COMPILER et DE_PTR_SIZE, mais DE_CPU doit être défini par le fichier de chaîne d'outils.

Le fichier de la chaîne d'outils peut être sélectionné à l'aide du paramètre de compilation CMAKE_TOOLCHAIN_FILE. Par exemple, la commande suivante créerait des fichiers make pour une compilation utilisant le compilateur croisé CodeSourcery pour ARM/Linux :

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

Association au moment de l'exécution des bibliothèques GLES et EGL

Le deqp n'a pas besoin de points d'entrée de l'API testée lors de la liaison. Le code de test accède toujours aux API via des pointeurs de fonction. Les points d'entrée peuvent ensuite être chargés dynamiquement au moment de l'exécution, ou le port de la plate-forme peut les fournir au moment de la liaison.

Si la prise en charge d'une API est activée dans les paramètres de compilation et que les bibliothèques de liens ne sont pas fournies, deqp chargera les points d'entrée nécessaires au moment de l'exécution. Si vous souhaitez utiliser l'association statique, fournissez les bibliothèques de liens nécessaires dans la variable de configuration de compilation DEQP_<API>_LIBRARIES.

Transférer le framework de test

Le portage de deqp implique trois étapes : l'adaptation des bibliothèques de portabilité de base, l'implémentation des interfaces d'intégration de plate-forme du framework de test et le portage du service d'exécution.

Le tableau ci-dessous liste les emplacements où des modifications de portage sont susceptibles d'être nécessaires. Tout ce qui va au-delà est probablement exotique.

Bibliothèques de portabilité de base

Les bibliothèques de portabilité de base sont déjà compatibles avec Windows, la plupart des variantes Linux, Mac OS, iOS et Android. Si la cible de test s'exécute sur l'un de ces systèmes d'exploitation, il n'est probablement pas nécessaire de toucher les bibliothèques de portabilité de base.

Port de la plate-forme du framework de test

Le port de plate-forme du framework de test deqp nécessite deux composants : un point d'entrée d'application et une implémentation d'interface de plate-forme.

Le point d'entrée de l'application est responsable de la création de l'objet de plate-forme, de la création d'un objet de ligne de commande (tcu::CommandLine), de l'ouverture d'un journal de test (tcu::TestLog) et de l'itération de l'application de test (tcu::App). Si l'OS cible est compatible avec un point d'entrée main() standard, tcuMain.cpp peut être utilisé comme implémentation du point d'entrée.

L'API de la plate-forme deqp est décrite en détail dans les fichiers suivants.

La classe de base pour tous les ports de plate-forme est tcu::Platform. Le port de plate-forme peut éventuellement prendre en charge les interfaces spécifiques à GL et EGL. Pour savoir ce qui doit être implémenté pour exécuter les tests, consultez le tableau ci-dessous.

Des instructions détaillées pour implémenter les ports de plate-forme sont disponibles dans les en-têtes de la couche de portage.

Service d'exécution des tests

Pour utiliser l'infrastructure d'exécution des tests deqp ou l'exécuteur de ligne de commande, le service d'exécution des tests doit être disponible sur la cible. Une implémentation C++ portable du service est fournie dans le répertoire execserver. Le binaire autonome est créé dans le cadre de la compilation du module de test deqp pour les cibles PC. Vous pouvez modifier execserver/CMakeLists.txt pour activer une compilation sur d'autres cibles.

La version C++ du service d'exécution des tests accepte deux paramètres de ligne de commande :

• --port=<port> définit le port TCP sur lequel le serveur écoute. La valeur par défaut est 50016.
• --single mettra fin au processus du serveur lorsque le client se déconnectera. Par défaut, le processus du serveur reste actif pour répondre à d'autres demandes d'exécution de tests.

Exécuter les tests

Cette page explique comment exécuter des tests deqp dans des environnements Linux et Windows, à l'aide d'arguments de ligne de commande, et comment utiliser le package d'application Android.

Environnements Linux et Windows

Commencez par copier les fichiers et répertoires suivants vers la cible.

Vous pouvez déployer le service d'exécution et tester les binaires n'importe où dans le système de fichiers cible. Toutefois, les binaires de test s'attendent à trouver les répertoires de données dans le répertoire de travail actuel. Lorsque vous êtes prêt, démarrez le service d'exécution des tests sur l'appareil cible. Pour savoir comment démarrer le service, consultez Service d'exécution des tests.

Arguments de ligne de commande

Le tableau suivant répertorie les arguments de ligne de commande qui affectent l'exécution de tous les programmes de test.

Arguments spécifiques à GLES2 et GLES3

Format de la liste des scénarios de test

La liste des scénarios de test peut être fournie dans deux formats. La première option consiste à lister le nom complet de chaque test sur une ligne distincte dans un fichier ASCII standard. À mesure que les ensembles de tests augmentent, les préfixes répétitifs peuvent devenir encombrants. Pour éviter de répéter les préfixes, utilisez une syntaxe de trie (également appelée arbre de préfixes) comme indiqué ci-dessous.

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

Exemple :

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

Cela se traduit par les deux scénarios de test suivants :

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

Android

Le package d'application Android contient tous les composants requis, y compris le service d'exécution des tests, les binaires de test et les fichiers de données. L'activité de test est un NativeActivity qui utilise EGL (nécessite Android 3.2 ou version ultérieure).

Le package d'application peut être installé avec la commande suivante (le nom indiqué est celui de l'APK dans le package Android CTS, qui dépend de la compilation) :

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

Pour lancer le service d'exécution des tests et configurer le transfert de port, utilisez la commande suivante :

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

Pour activer les impressions de débogage, exécutez la commande suivante avant de commencer les tests :

adb –d shell setprop log.tag.dEQP DEBUG

Exécuter des tests sur Android sans Android CTS

Pour démarrer manuellement l'activité d'exécution des tests, créez un intent Android ciblant android.app.NativeActivity. Les activités se trouvent dans le package com.drawelements.deqp. La ligne de commande doit être fournie en tant que chaîne supplémentaire avec la clé "cmdLine" dans l'Intent.

Un journal de test est écrit dans /sdcard/dEQP-log.qpa. Si l'exécution du test ne démarre pas normalement, des informations de débogage supplémentaires sont disponibles dans le journal de l'appareil.

Vous pouvez lancer une activité à partir de la ligne de commande à l'aide de l'utilitaire am. Par exemple, pour exécuter des tests dEQP-GLES2.info sur une plate-forme compatible avec NativeActivity,, utilisez les commandes suivantes.

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"'

Déboguer sur Android

Pour exécuter les tests sous le débogueur GDB sur Android, commencez par compiler et installer la version de débogage en exécutant les deux scripts suivants :

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

Une fois la version de débogage installée sur l'appareil, exécutez la commande suivante pour lancer les tests sous GDB s'exécutant sur l'hôte :

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

La ligne de commande deqp dépend des cas de test à exécuter et d'autres paramètres requis. Le script ajoute un point d'arrêt par défaut au début de l'exécution de deqp (tcu::App::App).

Le script debug.py accepte plusieurs arguments de ligne de commande pour des actions telles que la définition de points d'arrêt pour le débogage, les paramètres de connexion gdbserver et les chemins d'accès aux binaires supplémentaires à déboguer (utilisez debug.py --help pour tous les arguments et explications). Le script copie également certaines bibliothèques par défaut de l'appareil cible pour obtenir des listes de symboles.

Pour parcourir le code du pilote (par exemple, lorsque le GDB a besoin de connaître l'emplacement des binaires avec des informations de débogage complètes), ajoutez d'autres bibliothèques à l'aide des paramètres de ligne de commande debug.py. Ce script écrit un fichier de configuration pour GDB à partir de la ligne 132 du fichier de script. Vous pouvez fournir des chemins d'accès supplémentaires aux binaires, etc., mais il devrait suffire de fournir les paramètres de ligne de commande corrects.

Remarque : Sous Windows, le binaire GDB nécessite libpython2.7.dll. Avant de lancer debug.py, ajoutez <path-to-ndk>/prebuilt/windows/bin à la variable PATH.

Remarque : Le débogage du code natif ne fonctionne pas sur Android 4.3 standard. Pour trouver des solutions de contournement, consultez ce bug public. Android 4.4 et versions ultérieures ne contiennent pas ce bug.

Automatiser les tests

Les modules de test Deqp peuvent être intégrés aux systèmes de test automatisés de plusieurs manières. La meilleure approche dépend de l'infrastructure de test existante et de l'environnement cible.

Le résultat principal d'une série de tests est toujours le fichier journal de test, c'est-à-dire le fichier avec un suffixe .qpa. Les résultats complets des tests peuvent être analysés à partir du journal de test. La sortie de la console ne contient que des informations de débogage et peut ne pas être disponible sur toutes les plates-formes.

Les binaires de test peuvent être appelés directement à partir d'un système d'automatisation des tests. Le binaire de test peut être lancé pour un cas spécifique, pour un ensemble de tests ou pour tous les tests disponibles. Si une erreur fatale se produit lors de l'exécution (comme certaines erreurs d'API ou un plantage), l'exécution du test est interrompue. Pour les tests de régression, la meilleure approche consiste à appeler les binaires de test pour des cas individuels ou de petits ensembles de tests séparément, afin de disposer de résultats partiels même en cas d'échec grave.

deqp est fourni avec des outils d'exécution de tests en ligne de commande qui peuvent être utilisés en combinaison avec le service d'exécution pour obtenir une intégration plus robuste. L'exécuteur détecte l'arrêt du processus de test et reprend l'exécution du test sur le prochain cas disponible. Un seul fichier journal est généré à partir de la session de test complète. Cette configuration est idéale pour les systèmes de test légers qui ne fournissent pas de fonctionnalités de récupération en cas d'erreur.

Outils d'exécution de tests en ligne de commande

L'ensemble d'outils de ligne de commande actuel inclut un outil d'exécution de tests à distance, un générateur de comparaison des journaux de test pour l'analyse de régression, un convertisseur de journaux de test au format CSV, un convertisseur de journaux de test au format XML et un convertisseur de journaux de test au format JUnit.

Le code source de ces outils se trouve dans le répertoire executor, et les binaires sont intégrés au répertoire <builddir>/executor.

Exécuteur de tests en ligne de commande

L'exécuteur de test en ligne de commande est un outil C++ portable permettant de lancer une série de tests sur un appareil et de collecter les journaux résultants via TCP/IP. L'exécuteur communique avec le service d'exécution (execserver) sur l'appareil cible. Ensemble, ils offrent des fonctionnalités telles que la récupération après des plantages du processus de test. Les exemples suivants montrent comment utiliser l'exécuteur de tests en ligne de commande (utilisez --help pour en savoir plus) :

Exemple 1 : Exécuter des tests fonctionnels GLES2 sur un appareil Android

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"

Exemple 2 : Poursuivre une exécution partielle de test OpenGL ES 2 en local

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

Exporter et comparer les journaux de test au format CSV

deqp dispose d'un outil permettant de convertir les journaux de test (fichiers .qpa) en fichiers CSV. Le fichier CSV généré contient une liste de cas de test et leurs résultats. L'outil peut également comparer deux résultats de lot ou plus et ne lister que les cas de test qui ont des codes d'état différents dans les résultats de lot d'entrée. La comparaison affichera également le nombre de cas correspondants.

Le résultat au format CSV est très pratique pour un traitement ultérieur avec des utilitaires de ligne de commande standards ou avec un tableur. Un format texte brut lisible par l'homme peut être sélectionné à l'aide de l'argument de ligne de commande suivant : --format=text

Exemple 1 : Exporter le journal de test au format CSV

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

Exemple 2 : Lister les différences entre les résultats de test de deux journaux de test

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

Remarque : L'argument --value=code génère le code du résultat du test, tel que "Réussite" ou "Échec". L'argument --value=details sélectionne l'explication supplémentaire du résultat ou de la valeur numérique générée par un test de performances, de capacités ou de précision.

Exporter les journaux de test au format XML

Les fichiers journaux de test peuvent être convertis en documents XML valides à l'aide de l'utilitaire testlog-to-xml. Deux modes de sortie sont disponibles :

• Mode "Documents séparés", dans lequel chaque cas de test et le document récapitulatif caselist.xml sont écrits dans un répertoire de destination
• Mode fichier unique, dans lequel tous les résultats du fichier .qpa sont écrits dans un seul document XML.

Les fichiers journaux de test exportés peuvent être consultés dans un navigateur à l'aide d'une feuille de style XML. Des exemples de feuilles de style (testlog.xsl et testlog.css) sont fournis dans le répertoire doc/testlog-stylesheet. Pour afficher les fichiers journaux dans un navigateur, copiez les deux fichiers de feuille de style dans le même répertoire que celui où se trouvent les documents XML exportés.

Si vous utilisez Google Chrome, vous devez accéder aux fichiers via HTTP, car Chrome limite l'accès aux fichiers locaux pour des raisons de sécurité. L'installation standard de Python inclut un serveur HTTP de base qui peut être lancé pour diffuser le répertoire actuel avec la commande python –m SimpleHTTPServer 8000. Après avoir lancé le serveur, il vous suffit de pointer le navigateur Chrome sur http://localhost:8000 pour afficher le journal de test.

Conversion en journal de test JUnit

De nombreux systèmes d'automatisation des tests peuvent générer des rapports sur les résultats des tests à partir de la sortie JUnit. Les fichiers journaux de test deqp peuvent être convertis au format de sortie JUnit à l'aide de l'outil testlog-to-junit.

L'outil ne permet actuellement de traduire que le verdict du cas de test. JUnit ne prenant en charge que les résultats "réussite" et "échec", un résultat de réussite de deqp est mappé sur "JUnit pass" (JUnit réussi), et les autres résultats sont considérés comme des échecs. Le code de résultat deqp d'origine est disponible dans la sortie JUnit. Les autres données, telles que les messages du journal et les images de résultats, ne sont pas conservées lors de la conversion.

Utiliser des groupes de test spéciaux

Certains groupes de test peuvent nécessiter ou accepter des options de ligne de commande spéciales, ou nécessiter une attention particulière lorsqu'ils sont utilisés sur certains systèmes.

Tests de contrainte d'allocation de mémoire

Les tests de résistance à l'allocation de mémoire exercent des conditions de mémoire insuffisante en allouant à plusieurs reprises certaines ressources jusqu'à ce que le pilote signale une erreur de mémoire insuffisante.

Sur certaines plates-formes, telles qu'Android et la plupart des variantes Linux, les éléments suivants peuvent se produire : le système d'exploitation peut arrêter le processus de test au lieu de permettre à un pilote de gérer ou de fournir une erreur de mémoire insuffisante. Sur ces plates-formes, les tests conçus pour provoquer des erreurs de mémoire insuffisante sont désactivés par défaut et doivent être activés à l'aide de l'argument de ligne de commande --deqp-test-oom=enable. Nous vous recommandons d'exécuter ces tests manuellement pour vérifier si le système se comporte correctement en cas de pression sur les ressources. Toutefois, dans une telle situation, un plantage du processus de test doit être interprété comme une réussite.

Groupes de test

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

Tests de contrainte de rendu de longue durée

Les tests de contrainte de rendu sont conçus pour révéler les problèmes de robustesse sous une charge de rendu soutenue. Par défaut, les tests n'exécutent que quelques itérations, mais ils peuvent être configurés pour s'exécuter indéfiniment en fournissant l'argument de ligne de commande --deqp-test-iteration-count=-1. Le watchdog de test doit être désactivé (--deqp-watchdog=disable) lorsque ces tests sont exécutés pendant une longue période.

Groupes de test

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