Test del Programma di qualità drawElements

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

AOSP include la suite di test della GPU drawElements Quality Program (deqp) all'indirizzo https://android.googlesource.com/platform/external/deqp. Questa pagina descrive in dettaglio come eseguire il deployment della suite di test deqp in un nuovo ambiente.

Per utilizzare il codice inviato più recente, utilizza il ramo deqp-dev. Per il codice corrispondente a una versione specifica del CTS di Android, utilizza il ramo release-code-name-release (ad es. per Android 6.0, utilizza il ramo marshmallow-release).

Layout dell'origine

Il layout del codice sorgente per i moduli di test deqp e le librerie di supporto è riportato nella tabella seguente (l'elenco non è esaustivo, ma mette in evidenza le directory più importanti).

Componenti open source

deqp utilizza libpng e zlib, che possono essere recuperati utilizzando lo script platform/external/deqp/external/fetch_sources.py o tramite git da platform/external/[libpng,zlib].

Creare programmi di test

Il framework di test è stato progettato per la portabilità. Gli unici requisiti obbligatori sono il supporto completo di C++ e le librerie di sistema standard per I/O, thread e socket.

Sistema di compilazione CMake

Le sorgenti deqp hanno script di compilazione per CMake, lo strumento preferito per compilare i programmi di test.

CMake è un sistema di compilazione open source che supporta più piattaforme e toolchain. CMake genera file makefile o progetti IDE nativi da file di configurazione indipendenti dal target. Per ulteriori informazioni su CMake, consulta la documentazione di CMake.

CMake supporta e consiglia le build al di fuori dell'albero di origine, ovvero devi sempre creare file makefile o di progetto in una directory di compilazione separata al di fuori dell'albero di origine. CMake non ha alcun tipo di target "distclean", quindi la rimozione di eventuali file generati da CMake deve essere eseguita manualmente.

Le opzioni di configurazione vengono fornite a CMake utilizzando la sintassi -DOPTION_NAME=VALUE. Di seguito sono elencate alcune opzioni di deqp di uso comune.

Creare un file di compilazione di destinazione

Il sistema di compilazione deqp è configurato per i nuovi target utilizzando i file di compilazione target. Un file di compilazione target definisce le funzionalità supportate dalla piattaforma e le librerie o i percorsi di inclusione aggiuntivi richiesti. I nomi dei file di destinazione rispettano il targets/NAME/NAME.cmake formato e il target viene selezionato utilizzando il parametro di compilazione DEQP_TARGET.

I percorsi dei file nei file di destinazione sono relativi alla directory di base deqp, non alla directory targets/NAME. Le seguenti variabili standard possono essere impostate dal file di compilazione target.

Il file di compilazione di destinazione può aggiungere percorsi di inclusione o collegamento aggiuntivi utilizzando le funzioni CMake include_directories() e link_directories().

Build Win32

Il modo più semplice per compilare i moduli deqp per Windows è utilizzare il sistema di compilazione CMake. Avrai bisogno di CMake 2.6.12 o versioni successive e del compilatore Microsoft Visual C/C++. Il deqp è stato testato con Visual Studio 2013.

I file di progetto di Visual Studio possono essere generati con il seguente comando:

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

Puoi creare una build a 64 bit selezionando "Visual Studio VERSION Win64" come generatore di build:

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

Puoi anche generare file make NMake con l'opzione -G "NMake Makefiles" e il tipo di compilazione (-DCMAKE_BUILD_TYPE="Debug" o "Release").

Creazione del contesto di rendering

Il contesto di rendering può essere creato con WGL o con EGL su Windows.

Supporto WGL

Tutti i file binari Win32 supportano la creazione di contesti GL con WGL in quanto richiedono solo librerie standard. Il contesto WGL può essere selezionato utilizzando l'argomento --deqp-gl-context-type=wgl della riga di comando. In modalità WGL, deqp utilizza l'estensione WGL_EXT_create_context_es_profile per creare contesti OpenGL ES. È stato verificato che funziona con gli ultimi driver di NVIDIA e Intel. I driver AMD non supportano l'estensione richiesta.

Supporto EGL

Il deqp viene compilato con il caricamento dinamico per EGL su Windows se DEQP_SUPPORT_EGL è attivo. Questo è il valore predefinito nella maggior parte dei target. Se l'host dispone di librerie EGL, è possibile eseguire test con esse utilizzando il parametro della riga di comando: --deqp-gl-context-type=egl

Build Android

La compilazione Android utilizza gli script di compilazione CMake per compilare il codice di test nativo. Le parti Java, ovvero il server di esecuzione dei test e lo stub dell'applicazione di test, vengono compilate utilizzando gli strumenti di compilazione Android standard.

Per compilare i programmi di test deqp per Android con gli script di compilazione forniti, devi disporre di:

• La versione più recente di Android NDK; il file android/scripts/common.py elenca la versione richiesta
• SDK Android autonomo con API 13, SDK Tools, SDK Platform-tools e SDK packages di Build-tools installati
• Apache Ant 1.9.4 (richiesto dalla compilazione del codice Java)
• CMake 2.8.12 o versioni successive
• Python 2.6 o versioni successive della serie 2.x; Python 3.x non è supportato
• Per Windows: NMake o JOM in PATH
  • JOM consente build più rapide
• (Facoltativo) Ninja make è supportato anche su Linux

I file binari di Ant e dell'SDK si trovano in base alla variabile di ambiente PATH con alcuni valori predefiniti che hanno la precedenza. La logica è controllata da android/scripts/common.py.

La directory NDK deve essere ~/android-ndk-VERSION o C:/android/android-ndk-VERSION o essere definita tramite la variabile di ambiente ANDROID_NDK_PATH.

I componenti on-device di Deqp, il servizio di esecuzione dei test e i programmi di test vengono compilati mediante l'esecuzione dello script android/scripts/build.py. L'APK finale viene creato in android/package/bin e può essere installato dallo script install.py. Se viene utilizzato l'eseguitore della riga di comando, ExecService viene avviato con lo script launch.py sul dispositivo tramite ADB. Gli script possono essere eseguiti da qualsiasi directory.

Build Linux

I file binari di test e le utilità a riga di comando possono essere compilati per Linux generando file make utilizzando CMake. Esistono più target di compilazione predefiniti che sono utili per la compilazione per Linux.

Utilizza sempre -DCMAKE_BUILD_TYPE=<Debug|Release> per definire il tipo di build. Release è un buon valore predefinito. In caso contrario, viene creata una release build predefinita non ottimizzata.

Gli argomenti della riga di comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS possono essere utilizzati per trasmettere argomenti aggiuntivi al compilatore. Ad esempio, la compilazione a 32 o 64 bit può essere eseguita impostando rispettivamente -DCMAKE_C(XX)_FLAGS="-m32" o "-m64". Se non specificato, viene utilizzata l'architettura nativa della toolchain, in genere a 64 bit sulla toolchain a 64 bit.

Gli argomenti -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH possono essere utilizzati per fornire a CMake una libreria aggiuntiva o includere percorsi di ricerca.

Di seguito è riportato un esempio di riga di comando completa utilizzata per eseguire una compilazione di debug a 32 bit rispetto alle intestazioni e alle librerie del driver in una posizione personalizzata:

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-compilazione

La compilazione incrociata può essere eseguita utilizzando un file toolchain CMake. Il file toolchain specifica il compilatore da utilizzare, insieme ai percorsi di ricerca personalizzati per biblioteche e intestazioni. Diversi file della toolchain per scenari comuni sono inclusi nel pacchetto di release nella directory framework/delibs/cmake.

Oltre alle variabili CMake standard, le seguenti variabili specifiche di deqp possono essere impostate dal file toolchain. In genere CMake è in grado di rilevare correttamente DE_OS, DE_COMPILER e DE_PTR_SIZE, ma DE_CPU deve essere impostato dal file toolchain.

Il file della toolchain può essere selezionato utilizzando il parametro di compilazione CMAKE_TOOLCHAIN_FILE. Ad esempio, il seguente comando crea i file make per una build che utilizza il compilatore incrociato CodeSourcery per 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

Collegamento in fase di runtime delle librerie GLES ed EGL

Il deqp non ha bisogno dei punti di contatto dell'API in test durante il collegamento. Il codice di test accede sempre alle API tramite puntatori di funzione. I punti di contatto possono quindi essere caricati dinamicamente in fase di esecuzione o la porta della piattaforma può fornirli in fase di collegamento.

Se il supporto di un'API è attivato nelle impostazioni di compilazione e non vengono fornite le librerie di collegamento, deqp caricherà i punti di contatto necessari in fase di esecuzione. Se è auspicato il collegamento statico, fornisci le librerie di collegamento necessarie nella variabile di configurazione del build DEQP_<API>_LIBRARIES.

Esegui il porting del framework di test

La portabilità di deqp prevede tre passaggi: adattamento delle librerie di portabilità di base, implementazione di interfacce di integrazione della piattaforma del framework di test e portabilità del servizio di esecuzione.

La tabella seguente elenca le posizioni delle probabili modifiche di porting. Qualsiasi altro valore è probabilmente esotico.

Librerie di portabilità di base

Le librerie di portabilità di base supportano già Windows, la maggior parte delle varianti di Linux, Mac OS, iOS e Android. Se la destinazione del test viene eseguita su uno di questi sistemi operativi, molto probabilmente non è necessario modificare le librerie di portabilità di base.

Porta della piattaforma del framework di test

La porta della piattaforma del framework di test deqp richiede due componenti: un punto di accesso all'applicazione e un'implementazione dell'interfaccia della piattaforma.

L'entry point dell'applicazione è responsabile della creazione dell'oggetto piattaforma, della creazione di un oggetto a riga di comando (tcu::CommandLine), dell'apertura di un log di test (tcu::TestLog) e dell'iterazione dell'applicazione di test (tcu::App). Se l'OS di destinazione supporta un entry point main() standard, tcuMain.cpp può essere utilizzato come implementazione dell'entry point.

L'API della piattaforma deqp è descritta in dettaglio nei seguenti file.

La classe di base per tutte le porte della piattaforma è tcu::Platform. La porta della piattaforma può supportare facoltativamente interfacce specifiche per GL ed EGL. Consulta la tabella seguente per una panoramica di ciò che deve essere implementato per eseguire i test.

Le istruzioni dettagliate per l'implementazione delle porte della piattaforma sono riportate nelle intestazioni del livello di porting.

Servizio di esecuzione dei test

Per utilizzare l'infrastruttura di esecuzione dei test deqp o l'eseguitore a riga di comando, il servizio di esecuzione dei test deve essere disponibile sulla destinazione. Nella directory execserver è fornita un'implementazione del servizio in C++ portatile. Il codice binario autonomo viene compilato nell'ambito della compilazione del modulo di test deqp per i target PC. Puoi modificare execserver/CMakeLists.txt per attivare una compilazione su altri target.

La versione C++ del servizio di esecuzione dei test accetta due parametri della riga di comando:

• --port=<port> imposterà la porta TCP su cui il server è in ascolto. Il valore predefinito è 50016.
• --single termina il processo del server quando il client si disconnette. Per impostazione predefinita, il processo del server rimarrà attivo per soddisfare ulteriori richieste di esecuzione dei test.

Esegui i test

Questa pagina fornisce istruzioni per eseguire test deqp in ambienti Linux e Windows, utilizzare gli argomenti della riga di comando e lavorare con il pacchetto di applicazioni Android.

Ambienti Linux e Windows

Inizia copiando i seguenti file e directory nella destinazione.

Puoi eseguire il deployment del servizio di esecuzione e dei binari di test in qualsiasi punto del file system di destinazione. Tuttavia, i binari di test si aspettano di trovare le directory di dati nella directory di lavoro corrente. Quando è tutto pronto, avvia il servizio di esecuzione dei test sul dispositivo di destinazione. Per informazioni dettagliate sull'avvio del servizio, consulta Test del servizio di esecuzione.

Argomenti della riga di comando

La tabella seguente elenca gli argomenti della riga di comando che influiscono sull'esecuzione di tutti i programmi di test.

Argomenti specifici per GLES2 e GLES3

Formato dell'elenco degli scenari di test

L'elenco degli scenari di test può essere fornito in due formati. La prima opzione consiste nell'elencare il nome completo di ciascun test su una riga separata in un file ASCII standard. Man mano che gli insiemi di test aumentano, i prefissi ripetitivi possono essere complicati. Per evitare di ripetere i prefissi, utilizza una sintassi di trie (nota anche come albero di prefisso) mostrata di seguito.

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

Ad esempio:

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

Si traduce nei seguenti due casi di test:

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

Android

Il pacchetto dell'applicazione Android contiene tutti i componenti richiesti, tra cui il servizio di esecuzione dei test, i file binari di test e i file di dati. L'attività di test è un NativeActivity che utilizza EGL (richiede Android 3.2 o versioni successive).

Il pacchetto dell'applicazione può essere installato con il seguente comando (il nome visualizzato è il nome dell'APK nel pacchetto Android CTS; il nome dipende dalla build):

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

Per avviare il servizio di esecuzione del test e configurare il reindirizzamento delle porte, utilizza quanto segue:

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

Le stampe di debug possono essere attivate eseguendo quanto segue prima di iniziare i test:

adb –d shell setprop log.tag.dEQP DEBUG

Eseguire test su Android senza Android CTS

Per avviare manualmente l'attività di esecuzione del test, crea un'intent Android che abbia come target android.app.NativeActivity. Le attività sono disponibili nel pacchetto com.drawelements.deqp. La riga di comando deve essere fornita come stringa aggiuntiva con la chiave "cmdLine" nell'intent.

Un log di test viene scritto in /sdcard/dEQP-log.qpa. Se l'esecuzione del test non si avvia normalmente, sono disponibili ulteriori informazioni di debug nel log del dispositivo.

Puoi avviare un'attività dalla riga di comando utilizzando l'utilità am. Ad esempio, per eseguire i test dEQP-GLES2.info su una piattaforma supportata da NativeActivity,, utilizza i seguenti comandi.

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

Eseguire il debug su Android

Per eseguire i test sotto il debugger GDB su Android, compila e installa innanzitutto la build di debug eseguendo i seguenti due script:

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

Dopo aver installato la build di debug sul dispositivo, per avviare i test in GDB in esecuzione sull'host, esegui il seguente comando:

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

La riga di comando deqp dipende dai casi di test da eseguire e da altri parametri obbligatori. Lo script aggiunge un punto di interruzione predefinito all'inizio dell'esecuzione di deqp (tcu::App::App).

Lo script debug.py accetta più argomenti della riga di comando per azioni come l'impostazione di breakpoint per il debug, i parametri di connessione di gdbserver e i percorsi di altri binari da eseguire in debug (utilizza debug.py --help per tutti gli argomenti e le spiegazioni). Lo script copia anche alcune librerie predefinite dal dispositivo di destinazione per ottenere le schede dei simboli.

Per eseguire la procedura passo passo del codice del driver (ad esempio quando GDB deve conoscere le posizioni degli oggetti binari con informazioni di debug complete), aggiungi altre librerie tramite i parametri della riga di comando debug.py. Questo script scrive un file di configurazione per il GDB a partire dalla riga 132 del file dello script. Puoi fornire percorsi aggiuntivi ai file binari e così via, ma dovrebbe essere sufficiente fornire i parametri della riga di comando corretti.

Nota:su Windows, il file binario GDB richiedelibpython2.7.dll. Prima di avviare debug.py, aggiungi<path-to-ndk>/prebuilt/windows/bin alla variabile PATH.

Nota: il debug del codice nativo non funziona su Android 4.3 stock. Per le soluzioni alternative, consulta questo bug pubblico. Android 4.4 e versioni successive non contengono questo bug.

Automatizzare i test

I moduli di test Deqp possono essere integrati nei sistemi di test automatici in diversi modi. L'approccio migliore dipende dall'infrastruttura di test esistente e dall'ambiente di destinazione.

L'output principale di un'esecuzione di test è sempre il file di log del test, ovvero il file con un suffisso .qpa. I risultati completi del test possono essere analizzati dal log del test. L'output della console riguarda solo le informazioni di debug e potrebbe non essere disponibile su tutte le piattaforme.

I file binari di test possono essere richiamati direttamente da un sistema di automazione dei test. Il codice binario del test può essere avviato per un caso specifico, per un set di test o per tutti i test disponibili. Se si verifica un errore irreversibile durante l'esecuzione (ad esempio determinati errori relativi all'API o un arresto anomalo), l'esecuzione del test verrà interrotta. Per i test di regressione, l'approccio migliore è richiamare i binari di test per singoli casi o piccoli set di test separatamente, in modo da avere risultati parziali disponibili anche in caso di errore grave.

deqp è dotato di strumenti di esecuzione dei test a riga di comando che possono essere utilizzati in combinazione con il servizio di esecuzione per ottenere un'integrazione più solida. L'executor rileva il termine del processo di test e riprende l'esecuzione del test sul prossimo caso disponibile. Viene generato un unico file di log dalla sessione di test completa. Questa configurazione è ideale per sistemi di test leggeri che non forniscono funzionalità di recupero in caso di arresto anomalo.

Strumenti di esecuzione dei test a riga di comando

L'attuale set di strumenti a riga di comando include uno strumento di esecuzione dei test da remoto, un generatore di confronti dei log di test per l'analisi di regressione, un convertitore di log di test in CSV, un convertitore di log di test in XML e un convertitore di log di test in JUnit.

Il codice sorgente di questi strumenti si trova nella directory executor e i file binari sono integrati nella directory executor.<builddir>/executor

Esecutore di test a riga di comando

L'eseguitore di test a riga di comando è uno strumento C++ portatile per avviare un test su un dispositivo e raccogliere i log risultanti tramite TCP/IP. L'Executor comunicate con il servizio di esecuzione (execserver) sul dispositivo di destinazione. Insieme, forniscono funzionalità come il recupero dai crash del processo di test. I seguenti esempi mostrano come utilizzare l'Eseguitore di test a riga di comando (utilizza --help per maggiori dettagli):

Esempio 1: esegui test funzionali GLES2 su un dispositivo 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"

Esempio 2: continuare un test OpenGL ES 2 parziale eseguito localmente

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

Esporta e confronta i log di test in formato CSV

deqp dispone di uno strumento per convertire i log di test (file .qpa) in file CSV. L'output CSV contiene un elenco di casi di test e relativi risultati. Lo strumento può anche confrontare due o più risultati batch e elencare solo i casi di test con codici di stato diversi nei risultati batch di input. Il confronto stamperà anche il numero di casi corrispondenti.

L'output in formato CSV è molto pratico per l'ulteriore elaborazione con utilità a riga di comando standard o con un editor di fogli di lavoro. È possibile selezionare un formato di testo normale aggiuntivo di facile lettura utilizzando il seguente argomento della riga di comando: --format=text

Esempio 1: esporta il log di test in formato CSV

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

Esempio 2: elenca le differenze tra i risultati dei test di due log di test

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

Nota: l'argomento --value=code restituisce il codice del risultato del test, ad esempio "Pass" o "Fail". L'argomento --value=details seleziona la spiegazione aggiuntiva del risultato o del valore numerico prodotto da un test di prestazioni, funzionalità o accuratezza.

Testare l'esportazione dei log in XML

I file di log di test possono essere convertiti in documenti XML validi utilizzando l'utilità testlog-to-xml. Sono supportate due modalità di uscita:

• Modalità Documenti separati, in cui ogni test case e il caselist.xmldocumento di riepilogo vengono scritti in una directory di destinazione
• Modalità file singolo, in cui tutti i risultati nel file .qpa vengono scritti in un unico documento XML.

I file di log di test esportati possono essere visualizzati in un browser utilizzando un foglio di stile XML. I documenti di esempio delle stylesheet (testlog.xsl e testlog.css) sono forniti nella directory doc/testlog-stylesheet. Per eseguire il rendering dei file di log in un browser, copia i due file di stylesheet nella stessa directory in cui si trovano i documenti XML esportati.

Se utilizzi Google Chrome, per accedere ai file è necessario utilizzare HTTP, poiché Chrome limita l'accesso ai file locali per motivi di sicurezza. L'installazione standard di Python include un server HTTP di base che può essere avviato per servire la directory corrente con il comando python –m SimpleHTTPServer 8000. Dopo aver avviato il server, basta indirizzare il browser Chrome a http://localhost:8000 per visualizzare il log del test.

Conversione in un log di test JUnit

Molti sistemi di automazione dei test possono generare report sui risultati dell'esecuzione del test dall'output di JUnit. I file di log dei test deqp possono essere convertiti nel formato di output JUnit utilizzando lo strumento testlog-to-junit.

Al momento lo strumento supporta la traduzione solo del verdetto del caso di test. Poiché JUnit supporta solo i risultati "pass" e "fail", un risultato positivo del deqp viene mappato a "JUnit pass" e gli altri risultati sono considerati errori. Il codice del risultato deqp originale è disponibile nell'output di JUnit. Altri dati, come i messaggi di log e le immagini dei risultati, non vengono conservati durante la conversione.

Utilizzare gruppi di test speciali

Alcuni gruppi di test potrebbero richiedere o supportare opzioni della riga di comando speciali oppure richiedere un'attenzione particolare se utilizzati su determinati sistemi.

Stress test di allocazione della memoria

I test di stress di allocazione della memoria simulano condizioni di esaurimento della memoria allocando ripetutamente determinate risorse finché il driver non segnala un errore di esaurimento della memoria.

Su alcune piattaforme, come Android e la maggior parte delle varianti di Linux, può verificarsi quanto segue: il sistema operativo potrebbe interrompere il processo di test anziché consentire a un driver di gestire o altrimenti fornire un errore di esaurimento della memoria. Su queste piattaforme, i test progettati per causare errori di esaurimento della memoria sono disattivati per impostazione predefinita e devono essere attivati utilizzando l'argomento della riga di comando --deqp-test-oom=enable. Ti consigliamo di eseguire questi test manualmente per verificare se il sistema si comporta correttamente in caso di pressione sulle risorse. Tuttavia, in una situazione simile, un arresto anomalo del processo di test deve essere interpretato come un passaggio.

Gruppi di test

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

Test di stress di rendering di lunga durata

Gli stress test di rendering sono progettati per rilevare problemi di robustezza sotto un carico di rendering prolungato. Per impostazione predefinita, i test eseguiranno solo alcune iterazioni, ma possono essere configurati per essere eseguiti a tempo indeterminato specificando l'argomento della riga di comando --deqp-test-iteration-count=-1. Il watchdog del test deve essere disattivato (--deqp-watchdog=disable) quando esegui questi test per un lungo periodo di tempo.

Gruppi di test

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