Pengujian Program Kualitas drawElements

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

AOSP menyertakan rangkaian pengujian GPU drawElements Quality Program (deqp) di https://android.googlesource.com/platform/external/deqp. Halaman ini menjelaskan cara men-deploy rangkaian pengujian deqp ke lingkungan baru.

Untuk menggunakan kode terbaru yang dikirimkan, gunakan cabang deqp-dev. Untuk kode yang cocok dengan rilis Android CTS tertentu, gunakan cabang release-code-name-release (misalnya, untuk Android 6.0, gunakan cabang marshmallow-release).

Tata letak sumber

Tata letak kode sumber untuk modul pengujian deqp dan library pendukung ditampilkan dalam tabel di bawah (listingan tidak komprehensif, tetapi menyoroti direktori yang paling penting).

Komponen open source

deqp menggunakan libpng dan zlib, yang dapat diambil menggunakan skrip platform/external/deqp/external/fetch_sources.py atau melalui git dari platform/external/[libpng,zlib].

Membuat program pengujian

Framework pengujian telah dirancang dengan mempertimbangkan portabilitas. Satu-satunya persyaratan wajib adalah dukungan C++ penuh dan library sistem standar untuk I/O, thread, dan soket.

Sistem build CMake

Sumber deqp memiliki skrip build untuk CMake, yang merupakan alat pilihan untuk mengompilasi program pengujian.

CMake adalah sistem build open source yang mendukung beberapa platform dan toolchain. CMake menghasilkan file project IDE atau makefile native dari file konfigurasi yang tidak bergantung pada target. Untuk informasi selengkapnya tentang CMake, lihat dokumentasi CMake.

CMake mendukung dan merekomendasikan build di luar hierarki sumber, yaitu, Anda harus selalu membuat file makefile atau project di direktori build terpisah di luar hierarki sumber. CMake tidak memiliki jenis target "distclean", sehingga penghapusan file apa pun yang dihasilkan oleh CMake harus dilakukan secara manual.

Opsi konfigurasi diberikan ke CMake menggunakan sintaksis -DOPTION_NAME=VALUE. Beberapa opsi yang umum digunakan untuk deqp tercantum di bawah.

Membuat file build target

Sistem build deqp dikonfigurasi untuk target baru menggunakan file build target. File build target menentukan fitur yang didukung platform dan library atau jalur penyertaan tambahan yang diperlukan. Nama file target mengikuti format targets/NAME/NAME.cmake dan target dipilih menggunakan parameter build DEQP_TARGET.

Jalur file dalam file target bersifat relatif terhadap direktori deqp dasar, bukan direktori targets/NAME. Variabel standar berikut dapat ditetapkan oleh file build target.

File build target dapat menambahkan jalur link atau include tambahan menggunakan fungsi CMake include_directories() dan link_directories().

Build Win32

Cara termudah untuk mem-build modul deqp untuk Windows adalah dengan menggunakan sistem build CMake. Anda memerlukan CMake 2.6.12 atau yang lebih baru dan compiler Microsoft Visual C/C++. deqp telah diuji dengan Visual Studio 2013.

File project Visual Studio dapat dibuat dengan perintah berikut:

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

Build 64-bit dapat dibuat dengan memilih "Visual Studio VERSION Win64" sebagai generator build:

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

Anda juga dapat membuat file make NMake dengan opsi -G "NMake Makefiles" serta jenis build (-DCMAKE_BUILD_TYPE="Debug" atau "Release").

Membuat konteks render

Konteks rendering dapat dibuat dengan WGL atau dengan EGL di Windows.

Dukungan WGL

Semua biner Win32 mendukung pembuatan konteks GL dengan WGL karena hanya memerlukan library standar. Konteks WGL dapat dipilih menggunakan argumen command line --deqp-gl-context-type=wgl. Dalam mode WGL, deqp menggunakan ekstensi WGL_EXT_create_context_es_profile untuk membuat konteks OpenGL ES. Hal ini telah diuji agar berfungsi dengan driver terbaru dari NVIDIA dan Intel. Driver AMD tidak mendukung ekstensi yang diperlukan.

Dukungan EGL

deqp dibuat dengan pemuatan dinamis untuk EGL di Windows jika DEQP_SUPPORT_EGL AKTIF. Ini adalah setelan default di sebagian besar target. Kemudian, jika host memiliki library EGL yang tersedia, Anda dapat menjalankan pengujian dengan library tersebut menggunakan parameter command line: --deqp-gl-context-type=egl

Build Android

Build Android menggunakan skrip build CMake untuk mem-build kode pengujian native. Bagian Java, yaitu Server Eksekusi Pengujian dan Stub Aplikasi Pengujian, dikompilasi menggunakan alat build Android standar.

Untuk mengompilasi program pengujian deqp untuk Android dengan skrip build yang disediakan, Anda memerlukan:

• Versi terbaru Android NDK; file android/scripts/common.py mencantumkan versi yang diperlukan
• SDK mandiri Android dengan API 13, SDK Tools, SDK Platform-tools, dan SDK Build-tools paket terinstal
• Apache Ant 1.9.4 (diperlukan oleh build kode Java)
• CMake 2.8.12 atau yang lebih baru
• Python 2.6 atau yang lebih baru dalam seri 2.x; Python 3.x tidak didukung
• Untuk Windows: NMake atau JOM di PATH
  • JOM memungkinkan build yang lebih cepat
• Opsional: Ninja make juga didukung di Linux

Biner Ant dan SDK terletak berdasarkan variabel lingkungan PATH dengan default penggantian tertentu. Logika dikontrol oleh android/scripts/common.py.

Direktori NDK harus berupa ~/android-ndk-VERSION atau C:/android/android-ndk-VERSION atau ditentukan melalui variabel lingkungan ANDROID_NDK_PATH.

Komponen di perangkat Deqp, layanan eksekusi pengujian, dan program pengujian di-build dengan menjalankan skrip android/scripts/build.py. .apk akhir dibuat di android/package/bin dan dapat diinstal oleh skrip install.py. Jika eksekutor command line digunakan, ExecService akan diluncurkan dengan skrip launch.py di perangkat melalui ADB. Skrip dapat dieksekusi dari direktori mana pun.

Build Linux

Biner pengujian dan utilitas command line dapat di-build untuk Linux dengan membuat file make menggunakan CMake. Ada beberapa target build standar yang berguna saat mem-build untuk Linux.

Selalu gunakan -DCMAKE_BUILD_TYPE=<Debug|Release> untuk menentukan jenis build. Release adalah default yang baik. Tanpanya, build rilis default yang tidak dioptimalkan akan dibuat.

Argumen command line -DCMAKE_C_FLAGS dan -DCMAKE_CXX_FLAGS dapat digunakan untuk meneruskan argumen tambahan ke compiler. Misalnya, build 32-bit atau 64-bit dapat dilakukan dengan menyetel -DCMAKE_C(XX)_FLAGS="-m32" atau "-m64". Jika tidak ditentukan, arsitektur native toolchain, biasanya 64-bit pada toolchain 64-bit, akan digunakan.

Argumen -DCMAKE_LIBRARY_PATH dan -DCMAKE_INCLUDE_PATH dapat digunakan untuk CMake agar memberikan library tambahan atau menyertakan jalur penelusuran.

Contoh command line lengkap yang digunakan untuk melakukan build debug 32-bit terhadap header dan library driver di lokasi kustom adalah sebagai berikut:

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

Mengompilasi silang

Kompilasi silang dapat dilakukan dengan menggunakan file toolchain CMake. File toolchain menentukan compiler yang akan digunakan, beserta jalur penelusuran kustom untuk library dan header. Beberapa file toolchain untuk skenario umum disertakan dalam paket rilis di direktori framework/delibs/cmake.

Selain variabel CMake standar, variabel khusus deqp berikut dapat ditetapkan oleh file toolchain. CMake biasanya dapat mendeteksi DE_OS, DE_COMPILER, dan DE_PTR_SIZE dengan benar, tetapi DE_CPU harus ditetapkan oleh file toolchain.

File toolchain dapat dipilih menggunakan parameter build CMAKE_TOOLCHAIN_FILE. Misalnya, perintah berikut akan membuat file make untuk build menggunakan cross-compiler CodeSourcery untuk 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

Penautan runtime library GLES dan EGL

deqp tidak memerlukan titik entri API yang sedang diuji selama penautan. Kode pengujian selalu mengakses API melalui pointer fungsi. Titik entri kemudian dapat dimuat secara dinamis pada waktu proses atau port platform dapat menyediakannya pada waktu penautan.

Jika dukungan untuk API diaktifkan di setelan build dan library link tidak disediakan, deqp akan memuat titik entri yang diperlukan pada waktu proses. Jika penautan statis diinginkan, berikan library link yang diperlukan dalam variabel konfigurasi build DEQP_<API>_LIBRARIES.

Mentransfer framework pengujian

Mentransfer deqp melibatkan tiga langkah: menyesuaikan library portabilitas dasar, menerapkan antarmuka integrasi platform framework pengujian, dan mentransfer layanan eksekusi.

Tabel di bawah mencantumkan lokasi untuk kemungkinan perubahan transfer. Apa pun di luar hal tersebut kemungkinan bersifat eksotis.

Library portabilitas dasar

Library portabilitas dasar sudah mendukung Windows, sebagian besar varian Linux, Mac OS, iOS, dan Android. Jika target pengujian berjalan di salah satu sistem operasi tersebut, kemungkinan besar Anda tidak perlu menyentuh library portabilitas dasar sama sekali.

Menguji port platform framework

Port platform framework pengujian deqp memerlukan dua komponen: Titik entri aplikasi dan implementasi antarmuka platform.

Titik entri aplikasi bertanggung jawab untuk membuat objek platform, membuat objek command line (tcu::CommandLine), membuka log pengujian (tcu::TestLog), dan melakukan iterasi aplikasi pengujian (tcu::App). Jika OS target mendukung titik entri main() standar, tcuMain.cpp dapat digunakan sebagai implementasi titik entri.

API platform deqp dijelaskan secara mendetail dalam file berikut.

Class dasar untuk semua port platform adalah tcu::Platform. Port platform dapat secara opsional mendukung antarmuka khusus GL dan EGL. Lihat tabel berikut untuk mengetahui ringkasan hal yang perlu diterapkan untuk menjalankan pengujian.

Petunjuk mendetail untuk menerapkan port platform ada di header lapisan transfer.

Layanan eksekusi pengujian

Untuk menggunakan infrastruktur eksekusi pengujian deqp atau eksekutor command line, layanan eksekusi pengujian harus tersedia di target. Implementasi C++ portabel dari layanan disediakan di direktori execserver. Biner mandiri dibuat sebagai bagian dari build modul pengujian deqp untuk target PC. Anda dapat mengubah execserver/CMakeLists.txt untuk mengaktifkan build pada target lain.

Layanan eksekusi pengujian versi C++ menerima dua parameter command line:

• --port=<port> akan menetapkan port TCP yang diproses server. Defaultnya adalah 50016.
• --single akan menghentikan proses server saat klien terputus. Secara default, proses server akan tetap aktif untuk melayani permintaan eksekusi pengujian lebih lanjut.

Menjalankan pengujian

Halaman ini memberikan petunjuk untuk menjalankan pengujian deqp di lingkungan Linux dan Windows, menggunakan argumen command line, dan menggunakan paket aplikasi Android.

Lingkungan Linux dan Windows

Mulai dengan menyalin file dan direktori berikut ke target.

Anda dapat men-deploy layanan eksekusi dan menguji biner di mana saja dalam sistem file target; namun, biner pengujian diharapkan menemukan direktori data di direktori kerja saat ini. Jika sudah siap, mulai Layanan Eksekusi Pengujian di perangkat target. Untuk mengetahui detail tentang cara memulai layanan, lihat Layanan eksekusi pengujian.

Argumen command line

Tabel berikut mencantumkan argumen command line yang memengaruhi eksekusi semua program pengujian.

Argumen khusus GLES2 dan GLES3

Format daftar kasus pengujian

Daftar kasus pengujian dapat diberikan dalam dua format. Opsi pertama adalah mencantumkan nama lengkap setiap pengujian di baris terpisah dalam file ASCII standar. Seiring dengan peningkatan set pengujian, awalan berulang dapat menjadi rumit. Untuk menghindari pengulangan awalan, gunakan sintaksis trie (juga dikenal sebagai hierarki awalan) yang ditunjukkan di bawah.

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

Contoh:

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

Diterjemahkan menjadi dua kasus pengujian berikut:

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

Android

Paket aplikasi Android berisi semua komponen yang diperlukan, termasuk layanan eksekusi pengujian, biner pengujian, dan file data. Aktivitas pengujian adalah NativeActivity yang menggunakan EGL (memerlukan Android 3.2 atau yang lebih tinggi).

Paket aplikasi dapat diinstal dengan perintah berikut (nama yang ditampilkan adalah nama APK dalam paket Android CTS; nama yang bergantung pada build):

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

Untuk meluncurkan layanan eksekusi pengujian dan menyiapkan penerusan port, gunakan hal berikut:

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

Pencetakan debug dapat diaktifkan dengan menjalankan hal berikut sebelum memulai pengujian:

adb –d shell setprop log.tag.dEQP DEBUG

Menjalankan pengujian di Android tanpa Android CTS

Untuk memulai aktivitas eksekusi pengujian secara manual, buat intent Android yang menargetkan android.app.NativeActivity. Aktivitas dapat ditemukan dalam paket com.drawelements.deqp. Command line harus disediakan sebagai string tambahan dengan kunci "cmdLine" dalam Intent.

Log pengujian ditulis ke /sdcard/dEQP-log.qpa. Jika pengujian yang dijalankan tidak dimulai secara normal, informasi debug tambahan tersedia di log perangkat.

Anda dapat meluncurkan aktivitas dari command line menggunakan utilitas am. Misalnya, untuk menjalankan pengujian dEQP-GLES2.info di platform yang mendukung NativeActivity,, gunakan perintah berikut.

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

Melakukan proses debug di Android

Untuk menjalankan pengujian di bawah debugger GDB di Android, kompilasi dan instal build debug terlebih dahulu dengan menjalankan dua skrip berikut:

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

Setelah build debug diinstal di perangkat, untuk meluncurkan pengujian di GDB yang berjalan di host, jalankan perintah berikut:

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

Command line deqp bergantung pada kasus pengujian yang akan dijalankan dan parameter lain yang diperlukan. Skrip menambahkan titik henti sementara default di awal eksekusi deqp (tcu::App::App).

Skrip debug.py menerima beberapa argumen command line untuk tindakan seperti menetapkan titik henti sementara untuk proses debug, parameter koneksi gdbserver, dan jalur ke biner tambahan untuk di-debug (gunakan debug.py --help untuk semua argumen dan penjelasan). Skrip ini juga menyalin beberapa library default dari perangkat target untuk mendapatkan listingan simbol.

Untuk menelusuri kode driver (seperti saat GDB perlu mengetahui lokasi biner dengan informasi debug lengkap), tambahkan lebih banyak library melalui parameter command line debug.py. Skrip ini menulis file konfigurasi untuk GDB mulai dari baris 132 file skrip. Anda dapat memberikan jalur tambahan ke biner, dll., tetapi memberikan parameter command line yang benar sudah cukup.

Catatan: Di Windows, biner GDB memerlukan libpython2.7.dll. Sebelum meluncurkan debug.py, tambahkan <path-to-ndk>/prebuilt/windows/bin ke variabel PATH.

Catatan: Proses debug kode native tidak berfungsi di Android 4.3 bawaan; untuk solusinya, lihat bug publik ini. Android 4.4 dan yang lebih tinggi tidak berisi bug ini.

Mengotomatiskan pengujian

Modul pengujian deqp dapat diintegrasikan ke sistem pengujian otomatis dengan beberapa cara. Pendekatan terbaik bergantung pada infrastruktur pengujian dan lingkungan target yang ada.

Output utama dari pengujian yang dijalankan selalu berupa file log pengujian, yaitu file dengan akhiran .qpa. Hasil pengujian lengkap dapat diuraikan dari log pengujian. Output konsol hanya informasi debug dan mungkin tidak tersedia di semua platform.

Biner pengujian dapat dipanggil langsung dari sistem otomatisasi pengujian. Biner pengujian dapat diluncurkan untuk kasus tertentu, untuk set pengujian, atau untuk semua pengujian yang tersedia. Jika error fatal terjadi selama eksekusi (seperti error API tertentu atau error), eksekusi pengujian akan dibatalkan. Untuk pengujian regresi, pendekatan terbaik adalah memanggil biner pengujian untuk setiap kasus atau set pengujian kecil secara terpisah, agar hasil parsial tersedia bahkan jika terjadi kegagalan berat.

deqp dilengkapi dengan alat eksekusi pengujian command line yang dapat digunakan bersama dengan layanan eksekusi untuk mencapai integrasi yang lebih andal. Eksekutor mendeteksi penghentian proses pengujian dan akan melanjutkan eksekusi pengujian pada kasus berikutnya yang tersedia. Satu file log dihasilkan dari sesi pengujian penuh. Penyiapan ini ideal untuk sistem pengujian ringan yang tidak menyediakan fasilitas pemulihan error.

Alat eksekusi pengujian command line

Kumpulan alat command line saat ini mencakup alat eksekusi pengujian jarak jauh, generator perbandingan log pengujian untuk analisis regresi, pengonversi log pengujian ke CSV, pengonversi log pengujian ke XML, dan pengonversi log pengujian ke JUnit.

Kode sumber untuk alat ini berada di direktori executor, dan biner di-build ke dalam direktori <builddir>/executor.

Eksekutor pengujian command line

Eksekutor pengujian command line adalah alat C++ portabel untuk meluncurkan pengujian yang dijalankan di perangkat dan mengumpulkan log yang dihasilkan darinya melalui TCP/IP. Executor berkomunikasi dengan layanan eksekusi (execserver) di perangkat target. Keduanya bersama-sama menyediakan fungsi seperti pemulihan dari error proses pengujian. Contoh berikut menunjukkan cara menggunakan Test Executor command line (gunakan --help untuk mengetahui detail selengkapnya):

Contoh 1: Menjalankan pengujian fungsional GLES2 di perangkat 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"

Contoh 2: Melanjutkan pengujian OpenGL ES 2 parsial yang dijalankan secara lokal

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

Pengujian ekspor dan perbandingan CSV log

deqp memiliki alat untuk mengonversi log pengujian (file .qpa) menjadi file CSV. Output CSV berisi daftar kasus pengujian dan hasilnya. Alat ini juga dapat membandingkan dua atau beberapa hasil batch dan hanya mencantumkan kasus pengujian yang memiliki kode status berbeda dalam hasil batch input. Perbandingan juga akan mencetak jumlah kasus yang cocok.

Output dalam format CSV sangat praktis untuk pemrosesan lebih lanjut dengan utilitas command line standar atau dengan editor spreadsheet. Format teks biasa tambahan yang dapat dibaca manusia dapat dipilih menggunakan argumen command line berikut: --format=text

Contoh 1: Mengekspor log pengujian dalam format CSV

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

Contoh 2: Mencantumkan perbedaan hasil pengujian antara dua log pengujian

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

Catatan: Argumen --value=code menghasilkan kode hasil pengujian, seperti "Lulus" atau "Gagal". Argumen --value=details memilih penjelasan lebih lanjut tentang hasil atau nilai numerik yang dihasilkan oleh pengujian performa, kemampuan, atau akurasi.

Menguji ekspor XML log

File log pengujian dapat dikonversi menjadi dokumen XML yang valid menggunakan utilitas testlog-to-xml. Dua mode output didukung:

• Mode dokumen terpisah, dengan setiap kasus pengujian dan dokumen ringkasan caselist.xml ditulis ke direktori tujuan
• Mode file tunggal, dengan semua hasil dalam file .qpa ditulis ke satu dokumen XML.

File log pengujian yang diekspor dapat dilihat di browser menggunakan sheet gaya XML. Contoh dokumen lembar gaya (testlog.xsl dan testlog.css) disediakan di direktori doc/testlog-stylesheet. Untuk merender file log di browser, salin dua file sheet gaya ke direktori yang sama dengan lokasi dokumen XML yang diekspor.

Jika Anda menggunakan Google Chrome, file harus diakses melalui HTTP karena Chrome membatasi akses file lokal karena alasan keamanan. Penginstalan Python standar menyertakan server HTTP dasar yang dapat diluncurkan untuk menayangkan direktori saat ini dengan perintah python –m SimpleHTTPServer 8000. Setelah meluncurkan server, cukup arahkan browser Chrome ke http://localhost:8000 untuk melihat log pengujian.

Konversi ke log pengujian JUnit

Banyak sistem otomatisasi pengujian yang dapat menghasilkan laporan hasil pengujian dari output JUnit. File log pengujian deqp dapat dikonversi ke format output JUnit menggunakan alat testlog-to-junit.

Alat ini saat ini hanya mendukung terjemahan verdict kasus pengujian. Karena JUnit hanya mendukung hasil "lulus" dan "gagal", hasil lulus deqp dipetakan ke "lulus JUnit" dan hasil lainnya dianggap gagal. Kode hasil deqp asli tersedia di output JUnit. Data lain, seperti pesan log dan gambar hasil, tidak dipertahankan dalam konversi.

Menggunakan grup pengujian khusus

Beberapa grup pengujian mungkin memerlukan atau mendukung opsi command line khusus, atau memerlukan perhatian khusus saat digunakan pada sistem tertentu.

Pengujian stres alokasi memori

Stress testing alokasi memori menjalankan kondisi kehabisan memori dengan berulang kali mengalihkan resource tertentu hingga driver melaporkan error kehabisan memori.

Pada platform tertentu, seperti Android dan sebagian besar varian Linux, hal berikut dapat terjadi: Sistem operasi dapat menghentikan proses pengujian, bukan mengizinkan driver menangani atau memberikan error kehabisan memori. Pada platform tersebut, pengujian yang dirancang untuk menyebabkan error kehabisan memori dinonaktifkan secara default, dan harus diaktifkan menggunakan argumen command line --deqp-test-oom=enable. Sebaiknya jalankan pengujian tersebut secara manual untuk memeriksa apakah sistem berperilaku dengan benar di bawah tekanan resource. Namun, dalam situasi tersebut, error proses pengujian harus ditafsirkan sebagai lulus.

Grup pengujian

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

Pengujian stres rendering yang berjalan lama

Pengujian stres rendering dirancang untuk mengungkapkan masalah keandalan dalam beban rendering yang berkelanjutan. Secara default, pengujian hanya akan menjalankan beberapa iterasi, tetapi pengujian dapat dikonfigurasi untuk berjalan tanpa batas waktu dengan memberikan argumen command line --deqp-test-iteration-count=-1. Test watchdog harus dinonaktifkan (--deqp-watchdog=disable) saat menjalankan pengujian ini dalam jangka waktu yang lama.

Grup pengujian

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