Tests du programme de qualité drawElements

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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

Pour utiliser le dernier code envoyé, utilisez la branche deqp-dev. Pour le code correspondant à 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 des modules de test deqp et des bibliothèques associées est présenté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 à partir de 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 compatibilité complète avec C++ et les bibliothèques système standards pour l'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 de projet makefiles ou IDE natifs à partir de fichiers de configuration indépendants de la cible. Pour en savoir plus sur CMake, consultez la documentation CMake.

CMake prend en charge et recommande les compilations hors de l'arborescence source. Autrement dit, vous devez toujours créer des fichiers de compilation ou de projet dans un répertoire de compilation distinct en dehors de l'arborescence source. CMake ne dispose d'aucune cible "distclean". Par conséquent, la suppression des fichiers générés par CMake doit être effectuée manuellement.

Les options de configuration sont transmises à 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 de cible. Un fichier de compilation cible définit les fonctionnalités compatibles avec la plate-forme et les bibliothèques ou 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 dans les fichiers cibles sont relatifs au répertoire deqp de base, 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 d'association 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 d'une version ultérieure, ainsi que du compilateur Microsoft Visual C/C++. Le deqp a été testé avec Visual Studio 2013.

Vous pouvez générer des fichiers de projet Visual Studio à l'aide de la commande suivante:

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

Vous pouvez créer un build 64 bits en sélectionnant "Visual Studio VERSION Win64" comme générateur de build:

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

Vous pouvez également générer des fichiers de compilation 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

Vous pouvez créer un contexte de rendu avec WGL ou EGL sous 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, le deqp utilise l'extension WGL_EXT_create_context_es_profile pour créer des contextes OpenGL ES. Cette fonctionnalité a été testée avec les derniers pilotes de NVIDIA et d'Intel. Les pilotes AMD ne sont pas compatibles avec l'extension requise.

Prise en charge d'EGL

Le deqp est compilé avec le chargement dynamique pour EGL sous Windows si DEQP_SUPPORT_EGL est activé. Il s'agit de la valeur par défaut dans 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 bouchon d'application de test, sont compilées à l'aide des outils de compilation Android standards.

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

• Dernière version du NDK Android ; le fichier android/scripts/common.py indique la version requise.
• SDK Android autonome avec API 13, SDK Tools, SDK Platform-tools et SDK Build-tools packages installés
• Apache Ant 1.9.4 (requis pour 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 de compiler plus rapidement
• Facultatif: Ninja make est également compatible avec Linux

Les binaires Ant et SDK sont situés en fonction de la variable d'environnement PATH avec certaines valeurs par défaut. La logique est contrôlée par android/scripts/common.py.

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

Les composants Deqp sur l'appareil, le service d'exécution des tests et les programmes de test sont créés en exécutant le script android/scripts/build.py. L'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.

Build Linux

Les binaires de test et les utilitaires de ligne de commande peuvent être compilés pour Linux en générant des fichiers de compilation à 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 elle, un build de publication non optimisé est créé par défaut.

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 -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64", respectivement. Si elle n'est pas spécifiée, l'architecture native de la chaîne d'outils, généralement 64 bits sur la chaîne d'outils 64 bits, est utilisée.

Les arguments -DCMAKE_LIBRARY_PATH et -DCMAKE_INCLUDE_PATH peuvent être utilisés pour indiquer à CMake une bibliothèque ou des chemins de recherche supplémentaires.

Voici un exemple de ligne de commande complète utilisée pour créer un build de débogage 32 bits à partir des en-têtes et des 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 des scénarios courants sont inclus dans le package de publication 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 chaîne d'outils peut être sélectionné à l'aide du paramètre de compilation CMAKE_TOOLCHAIN_FILE. Par exemple, la commande suivante crée des fichiers de compilation pour une compilation à l'aide du compilateur multiplate-forme 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 d'exécution des bibliothèques GLES et EGL

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

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

Porter le framework de test

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

Le tableau ci-dessous indique les emplacements des modifications de portage probables. Tout ce qui dépasse ces valeurs est susceptible d'être exotique.

Bibliothèques de portabilité de base

Les bibliothèques de portabilité de base sont déjà compatibles avec Windows, la plupart des variantes de Linux, Mac OS, iOS et Android. Si la cible de test s'exécute sur l'un de ces systèmes d'exploitation, il est fort probable que vous n'ayez pas besoin de toucher aux 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 chargé de créer l'objet de plate-forme, de créer un objet de ligne de commande (tcu::CommandLine), d'ouvrir un journal de test (tcu::TestLog) et d'itérer l'application de test (tcu::App). Si l'OS cible prend en charge 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 de tous les ports de plate-forme est tcu::Platform. Le port de la plate-forme peut éventuellement prendre en charge des interfaces spécifiques à GL et EGL. Consultez le tableau suivant pour obtenir un aperçu de ce qui doit être implémenté pour exécuter les tests.

Vous trouverez des instructions détaillées sur l'implémentation des ports de plate-forme dans les en-têtes de la couche de portabilité.

Service d'exécution de test

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 portable du service en C++ 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 un build 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 met fin au processus du serveur lorsque le client se déconnecte. Par défaut, le processus du serveur reste actif pour répondre aux autres requêtes d'exécution de test.

Exécuter les tests

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

environnements Linux et Windows ;

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

Vous pouvez déployer le service d'exécution et les binaires de test n'importe où dans le système de fichiers cible. Toutefois, les binaires de test s'attendent à trouver des 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 en savoir plus sur le démarrage du service, consultez la section 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 test augmentent, les préfixes répétitifs peuvent devenir encombrants. Pour éviter de répéter les préfixes, utilisez la syntaxe d'un trie (également appelé arbre de préfixes) indiquée 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é à l'aide de la commande suivante (le nom affiché 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, procédez comme suit:

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

Pour activer les sorties 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 qui cible 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 le build 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 le build de débogage installé sur l'appareil, exécutez la commande suivante pour lancer les tests sous GDB exécuté 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 des autres paramètres requis. Le script ajoute un point d'arrêt par défaut au début de l'exécution deqp (tcu::App::App).

Le script debug.py accepte plusieurs arguments de ligne de commande pour des actions telles que le paramétrage de points d'arrêt pour le débogage, les paramètres de connexion gdbserver et les chemins d'accès à des 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 suivre le code du pilote (par exemple, lorsque le GDB doit connaître l'emplacement des binaires avec des informations de débogage complètes), ajoutez d'autres bibliothèques via les paramètres de ligne de commande debug.py. Ce script écrit un fichier de configuration pour le GDB à partir de la ligne 132 du fichier de script. Vous pouvez fournir des chemins d'accès supplémentaires aux binaires, etc., mais fournir les paramètres de ligne de commande appropriés devrait suffire.

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 d'origine. Pour connaître les 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.

La sortie principale d'une exécution de test est toujours le fichier journal de test, c'est-à-dire le fichier avec un suffixe .qpa. Les résultats complets du test peuvent être analysés à partir du journal de test. La sortie de la console ne contient que des informations de débogage et n'est pas nécessairement 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 (telles que 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 de défaillance grave.

Le deqp est fourni avec des outils d'exécution de test par 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 de plantage.

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

L'ensemble d'outils de ligne de commande actuel comprend un outil d'exécution de test à distance, un générateur de comparaison de 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 test de ligne de commande

L'exécuteur de test de ligne de commande est un outil C++ portable permettant de lancer une exécution de test sur un appareil et de collecter les journaux qui en résultent 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 un plantage du processus de test. Les exemples suivants montrent comment utiliser l'exécuteur de test de 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: Poursuite d'une exécution de test OpenGL ES 2 partielle 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

Tester l'exportation et la comparaison des journaux au format CSV

Le deqp dispose d'un outil permettant de convertir les journaux de test (fichiers .qpa) en fichiers CSV. La sortie au format CSV contient une liste de scénarios de test et leurs résultats. L'outil peut également comparer deux résultats de lot ou plus et n'afficher que les cas de test dont les codes d'état sont différents dans les résultats du lot d'entrée. La comparaison imprime également le nombre de cas correspondants.

La sortie au format CSV est très pratique pour un traitement ultérieur avec des utilitaires de ligne de commande standards ou avec un éditeur de feuilles de calcul. Vous pouvez sélectionner un format de texte brut supplémentaire lisible par l'humain à 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 deux journaux de test

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

Remarque:L'argument --value=code affiche le code de résultat du test, par exemple "Pass" (Passer) ou "Fail" (Échec). L'argument --value=details sélectionne l'explication supplémentaire du résultat ou de la valeur numérique produite par un test de performances, de capacités ou de précision.

Exportation des 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 acceptés:

• Mode de documents distincts, où chaque scénario 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 affichés dans un navigateur à l'aide d'une feuille de style XML. Des exemples de documents de feuille 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 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 à l'aide de la commande python –m SimpleHTTPServer 8000. Après avoir lancé le serveur, pointez simplement le navigateur Chrome vers 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 exécutions de test à partir de la sortie JUnit. Les fichiers de journal de test deqp peuvent être convertis au format de sortie JUnit à l'aide de l'outil testlog-to-junit.

Pour le moment, l'outil ne permet de traduire que l'évaluation du cas de test. Comme JUnit n'est compatible qu'avec les résultats "pass" et "fail", un résultat "pass" de la deqp est mappé sur "JUnit pass" 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 de 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 des options de ligne de commande spéciales ou être compatibles avec elles, ou encore nécessiter des précautions particulières lorsqu'ils sont utilisés sur certains systèmes.

Tests de stress d'allocation de mémoire

Les tests de stress d'allocation de mémoire simulent des conditions de mémoire insuffisante en allouant de manière répétée 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 de Linux, le système d'exploitation peut arrêter le processus de test au lieu d'autoriser un pilote à gérer ou à fournir une erreur de mémoire insuffisante. Sur ces plates-formes, les tests conçus pour provoquer des erreurs de manque de mémoire 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 sous pression de ressources. Toutefois, dans ce cas, un plantage du processus de test doit être interprété comme un succès.

Groupes de test

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

Tests de stress de rendu de longue durée

Les tests de stress de rendu sont conçus pour révéler les problèmes de robustesse en cas de 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 chien de garde de test doit être désactivé (--deqp-watchdog=disable) lorsque vous exécutez ces tests pendant une longue période.

Groupes de test

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