การทดสอบโปรแกรมคุณภาพ DrawElements

AOSP มีชุดการทดสอบ GPU DrawElements Quality Program (deqp) อยู่ที่ https://android.googlesource.com/platform/external/deqp หน้านี้แสดงรายละเอียดวิธีการปรับใช้ชุดทดสอบ deqp กับสภาพแวดล้อมใหม่

หากต้องการทำงานกับโค้ดที่ส่งมาล่าสุด ให้ใช้สาขา deqp-dev สำหรับโค้ดที่ตรงกับ Android CTS รุ่นใดรุ่นหนึ่ง ให้ใช้สาขา release-code-name -release (เช่น สำหรับ Android 6.0 ให้ใช้สาขา marshmallow-release )

เค้าโครงแหล่งที่มา

เค้าโครงซอร์สโค้ดสำหรับโมดูลทดสอบ deqp และไลบรารีที่รองรับแสดงอยู่ในตารางด้านล่าง (รายการไม่ครอบคลุม แต่เน้นไดเรกทอรีที่สำคัญที่สุด)

ไดเรกทอรี	คำอธิบาย
android	แหล่งที่มาของผู้ทดสอบ Android และสคริปต์การสร้าง
data	ทดสอบไฟล์ข้อมูล
modules	แหล่งที่มาของโมดูลทดสอบ
modules/egl	โมดูลอีจีแอล
modules/gles2	โมดูล GLES2
modules/gles3	โมดูล GLES3
modules/gles31	โมดูล GLES3.1
modules/gles32	โมดูล GLES3.2
targets	ไฟล์การกำหนดค่าบิลด์เฉพาะเป้าหมาย
framework	เฟรมเวิร์กโมดูลทดสอบ deqp และยูทิลิตี้
framework/delibs	การพกพาฐานและสร้างไลบรารี
framework/platform	พอร์ตแพลตฟอร์ม
framework/qphelper	ทดสอบไลบรารีการรวมโปรแกรม (C)
framework/common	กรอบงาน Deqp (C++)
framework/opengl, framework/egl	ยูทิลิตี้เฉพาะ API
execserver	แหล่งที่มา ExecServer ฝั่งอุปกรณ์
executor	เครื่องมือและยูทิลิตี้เชลล์ตัวดำเนินการทดสอบฝั่งโฮสต์
external	สร้างไดเร็กทอรี stub สำหรับ libs libpng และ zlib ภายนอก

ส่วนประกอบโอเพ่นซอร์ส

deqp ใช้ libpng และ zlib ซึ่งสามารถดึงข้อมูลได้โดยใช้ script platform/external/deqp/external/fetch_sources.py หรือผ่าน git จาก platform/external/[libpng,zlib]

สร้างโปรแกรมทดสอบ

กรอบการทดสอบได้รับการออกแบบโดยคำนึงถึงความสะดวกในการพกพา ข้อกำหนดบังคับเพียงอย่างเดียวคือการสนับสนุน C++ เต็มรูปแบบและไลบรารีระบบมาตรฐานสำหรับ I/O, เธรด และซ็อกเก็ต

ระบบสร้าง CMake

แหล่งที่มา deqp มีสคริปต์สำหรับ CMake ซึ่งเป็นเครื่องมือที่ต้องการสำหรับการรวบรวมโปรแกรมทดสอบ

CMake เป็นระบบสร้างโอเพ่นซอร์สที่รองรับหลายแพลตฟอร์มและ toolchains CMake สร้างไฟล์ makefiles ดั้งเดิมหรือไฟล์โครงการ IDE จากไฟล์การกำหนดค่าที่ไม่ขึ้นอยู่กับเป้าหมาย สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ CMake โปรดดูเอกสารประกอบของ CMake

CMake รองรับและแนะนำบิลด์นอกซอร์ส กล่าวคือ คุณควรสร้าง makefiles หรือไฟล์โปรเจ็กต์ในไดเร็กทอรีบิลด์แยกต่างหากภายนอกแผนผังซอร์ส CMake ไม่มีเป้าหมาย "distclean" ใดๆ ดังนั้นการลบไฟล์ใดๆ ที่สร้างโดย CMake จะต้องดำเนินการด้วยตนเอง

ตัวเลือกการกำหนดค่าถูกกำหนดให้กับ CMake โดยใช้ไวยากรณ์ -D OPTION_NAME = VALUE ตัวเลือกที่ใช้กันทั่วไปสำหรับ deqp มีดังต่อไปนี้

ตัวเลือกการกำหนดค่า	คำอธิบาย
DEQP_TARGET	ชื่อเป้าหมาย เช่น "android" สคริปต์ deqp CMake จะรวมไฟล์ targets/ DEQP_TARGET / DEQP_TARGET .cmake และคาดว่าจะพบตัวเลือกบิลด์เฉพาะเป้าหมายจากที่นั่น
CMAKE_TOOLCHAIN_FILE	เส้นทางไปยังไฟล์ toolchain สำหรับ CMake ใช้สำหรับการรวบรวมข้าม
CMAKE_BUILD_TYPE	ประเภทบิลด์สำหรับเป้าหมาย makefile ค่าที่ถูกต้องคือ: "Debug" และ "Release" หมายเหตุการตีความและประเภทดีฟอลต์ขึ้นอยู่กับระบบบิลด์เป้าหมาย ดูเอกสารประกอบ CMake สำหรับรายละเอียด

สร้างไฟล์บิลด์เป้าหมาย

ระบบการสร้าง deqp ได้รับการกำหนดค่าสำหรับเป้าหมายใหม่โดยใช้ไฟล์บิลด์เป้าหมาย ไฟล์บิลด์เป้าหมายจะกำหนดคุณสมบัติที่แพลตฟอร์มรองรับ และไลบรารีใดหรือเส้นทางรวมเพิ่มเติมที่จำเป็น ชื่อไฟล์เป้าหมายเป็นไปตามรูปแบบ targets/ NAME / NAME .cmake และเลือกเป้าหมายโดยใช้พารามิเตอร์บิลด์ DEQP_TARGET

พาธของไฟล์ในไฟล์เป้าหมายสัมพันธ์กับไดเร็กทอรี deqp ฐาน ไม่ใช่ไดเร็กทอรี targets/ NAME ตัวแปรมาตรฐานต่อไปนี้สามารถตั้งค่าได้ด้วยไฟล์บิลด์เป้าหมาย

ตัวแปร	คำอธิบาย
DEQP_TARGET_NAME	ชื่อเป้าหมาย (จะรวมอยู่ในบันทึกการทดสอบ)
DEQP_SUPPORT_GLES2	รองรับ GLES2 หรือไม่ (ค่าเริ่มต้น: ปิด)
DEQP_GLES2_LIBRARIES	ไลบรารี GLES2 (เว้นว่างไว้หากไม่รองรับหรือใช้การโหลดแบบไดนามิก)
DEQP_SUPPORT_GLES3	รองรับ GLES3.x หรือไม่ (ค่าเริ่มต้น: ปิด)
DEQP_GLES3_LIBRARIES	ไลบรารี GLES3.x (เว้นว่างไว้หากไม่รองรับหรือใช้การโหลดแบบไดนามิก)
DEQP_SUPPORT_VG	รองรับ OpenVG หรือไม่ (ค่าเริ่มต้น: ปิด)
DEQP_OPENVG_LIBRARIES	ไลบรารี OpenVG (เว้นว่างไว้หากไม่รองรับหรือใช้การโหลดแบบไดนามิก)
DEQP_SUPPORT_EGL	รองรับ EGL หรือไม่ (ค่าเริ่มต้น: ปิด)
DEQP_EGL_LIBRARIES	ไลบรารี EGL (เว้นว่างไว้หากไม่รองรับหรือใช้การโหลดแบบไดนามิก)
DEQP_PLATFORM_LIBRARIES	ต้องมีไลบรารีเฉพาะแพลตฟอร์มเพิ่มเติมสำหรับการเชื่อมโยง
DEQP_PLATFORM_COPY_LIBRARIES	รายชื่อไลบรารีที่ถูกคัดลอกไปยังไดเร็กทอรีบิลด์ไบนารีทดสอบแต่ละรายการ สามารถใช้เพื่อคัดลอกไลบรารีที่จำเป็นสำหรับการรันการทดสอบ แต่ไม่ได้อยู่ในพาธการค้นหาเริ่มต้น
TCUTIL_PLATFORM_SRCS	รายการแหล่งที่มาของพอร์ตแพลตฟอร์ม แหล่งที่มาเริ่มต้นจะพิจารณาจากความสามารถและระบบปฏิบัติการ หมายเหตุ: เส้นทางสัมพันธ์กับ: framework/platform

ไฟล์บิลด์เป้าหมายสามารถเพิ่มการรวมหรือพาธลิงก์เพิ่มเติมได้โดยใช้ฟังก์ชัน include_directories() และ link_directories() CMake

บิลด์ Win32

วิธีที่ง่ายที่สุดในการสร้างโมดูล deqp สำหรับ Windows คือการใช้ระบบการสร้าง CMake คุณจะต้องมี CMake 2.6.12 หรือใหม่กว่าและคอมไพเลอร์ Microsoft Visual C/C++ deqp ได้รับการทดสอบกับ Visual Studio 2013

ไฟล์โครงการ Visual Studio สามารถสร้างได้ด้วยคำสั่งต่อไปนี้:

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

สามารถสร้างบิลด์ 64 บิตได้โดยเลือก "Visual Studio VERSION Win64" เป็นตัวสร้างบิลด์:

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

คุณยังสามารถสร้าง NMake makefiles ด้วยตัวเลือก -G "NMake Makefiles" รวมถึงประเภทบิลด์ ( -DCMAKE_BUILD_TYPE="Debug" หรือ "Release" )

เรนเดอร์การสร้างบริบท

บริบทการเรนเดอร์สามารถสร้างได้ด้วย WGL หรือ EGL บน Windows

การสนับสนุน WGL

ไบนารี Win32 ทั้งหมดรองรับการสร้างบริบท GL ด้วย WGL เนื่องจากต้องการเฉพาะไลบรารีมาตรฐานเท่านั้น สามารถเลือกบริบท WGL ได้โดยใช้อาร์กิวเมนต์บรรทัดคำสั่ง --deqp-gl-context-type=wgl ในโหมด WGL นั้น deqp ใช้ส่วนขยาย WGL_EXT_create_context_es_profile เพื่อสร้างบริบท OpenGL ES สิ่งนี้ได้รับการทดสอบแล้วว่าใช้งานได้กับไดรเวอร์ล่าสุดจาก NVIDIA และ Intel ไดรเวอร์ AMD ไม่รองรับส่วนขยายที่จำเป็น

การสนับสนุนอีจีแอล

deqp สร้างขึ้นด้วยการโหลดแบบไดนามิกสำหรับ EGL บน Windows หาก DEQP_SUPPORT_EGL เปิดอยู่ นี่เป็นค่าเริ่มต้นในเป้าหมายส่วนใหญ่ จากนั้น หากโฮสต์มีไลบรารี EGL อยู่ ก็เป็นไปได้ที่จะรันการทดสอบด้วยพารามิเตอร์บรรทัดคำสั่ง: --deqp-gl-context-type=egl

บิลด์ Android

บิลด์ Android ใช้สคริปต์บิลด์ CMake สำหรับการสร้างโค้ดทดสอบเนทิฟ ส่วน Java เช่น Test Execution Server และ Test Application Stub ได้รับการคอมไพล์โดยใช้เครื่องมือสร้าง Android มาตรฐาน

ในการคอมไพล์โปรแกรมทดสอบ deqp สำหรับ Android ด้วยสคริปต์บิลด์ที่ให้มา คุณจะต้องมี:

• Android NDK เวอร์ชันล่าสุด ไฟล์ android/scripts/common.py แสดงรายการเวอร์ชันที่ต้องการ
• ติดตั้ง SDK แบบสแตนด์อโลน Android ที่มี API 13, เครื่องมือ SDK, เครื่องมือแพลตฟอร์ม SDK และ แพ็คเกจ เครื่องมือสร้าง SDK
• Apache Ant 1.9.4 (จำเป็นสำหรับบิลด์โค้ด Java)
• CMake 2.8.12 หรือใหม่กว่า
• Python 2.6 หรือใหม่กว่าในซีรีย์ 2.x; ไม่รองรับ Python 3.x
• สำหรับ Windows: NMake หรือ JOM ใน PATH
  • JOM ช่วยให้สร้างได้เร็วขึ้น
• ทางเลือก: Ninja make ยังรองรับบน Linux อีกด้วย

ไบนารี Ant และ SDK ตั้งอยู่ตามตัวแปรสภาพแวดล้อม PATH พร้อมด้วยค่าเริ่มต้นที่แทนที่บางอย่าง ตรรกะถูกควบคุมโดย android/scripts/common.py

ไดเร็กทอรี NDK ต้องเป็น ~/android-ndk- VERSION หรือ C:/android/android-ndk- VERSION หรือกำหนดผ่านตัวแปรสภาพแวดล้อม ANDROID_NDK_PATH

ส่วนประกอบ Deqp บนอุปกรณ์ บริการดำเนินการทดสอบ และโปรแกรมทดสอบถูกสร้างขึ้นโดยการเรียกใช้สคริปต์ android/scripts/build.py .apk สุดท้ายถูกสร้างขึ้นใน android/package/bin และสามารถติดตั้งได้โดยสคริปต์ install.py หากใช้ ตัวดำเนินการบรรทัดคำสั่ง ExecService จะถูกเปิดใช้งานด้วยสคริปต์ launch.py ​​บนอุปกรณ์ผ่าน ADB สคริปต์สามารถดำเนินการได้จากไดเร็กทอรีใดก็ได้

โครงสร้างลินุกซ์

ไบนารีทดสอบและยูทิลิตี้บรรทัดคำสั่งสามารถสร้างขึ้นสำหรับ Linux ได้โดยการสร้าง makefiles โดยใช้ CMake มีเป้าหมายบิลด์ที่กำหนดไว้ล่วงหน้าหลายรายการซึ่งมีประโยชน์เมื่อสร้างสำหรับ Linux

สร้างเป้าหมาย	คำอธิบาย
default	เป้าหมายเริ่มต้นที่ใช้วิปัสสนาแพลตฟอร์ม CMake เพื่อพิจารณาการสนับสนุนสำหรับ API ต่างๆ
x11_glx	ใช้ GLX เพื่อสร้างบริบท OpenGL (ES)
x11_egl	ใช้ EGL เพื่อสร้างบริบท OpenGL (ES)
x11_egl_glx	รองรับทั้ง GLX และ EGL พร้อม X11

ใช้ -DCMAKE_BUILD_TYPE=<Debug|Release> เสมอเพื่อกำหนดชนิดบิลด์ Release เป็นค่าเริ่มต้นที่ดี หากไม่มีสิ่งนี้ จะมีการสร้างบิลด์รีลีสที่ไม่ได้รับการปรับให้เหมาะสมเป็นค่าเริ่มต้น

อาร์กิวเมนต์บรรทัดคำสั่ง -DCMAKE_C_FLAGS และ -DCMAKE_CXX_FLAGS สามารถใช้เพื่อส่งผ่านอาร์กิวเมนต์เพิ่มเติมไปยังคอมไพเลอร์ ตัวอย่างเช่น บิลด์ 32 บิตหรือ 64 บิตสามารถทำได้โดยการตั้งค่า -DCMAKE_C(XX)_FLAGS="-m32" หรือ "-m64" ตามลำดับ หากไม่ได้ระบุ สถาปัตยกรรมเนทีฟของ toolchain โดยทั่วไปจะเป็น 64 บิตบน toolchain 64 บิต

อาร์กิวเมนต์ -DCMAKE_LIBRARY_PATH และ -DCMAKE_INCLUDE_PATH สามารถใช้สำหรับ CMake เพื่อให้ CMake ไลบรารีเพิ่มเติมหรือรวมพาธการค้นหา

ตัวอย่างของบรรทัดคำสั่งแบบเต็มที่ใช้ในการสร้างการแก้ไขจุดบกพร่องแบบ 32 บิตกับส่วนหัวของไดรเวอร์และไลบรารีในตำแหน่งที่กำหนดเองมีดังต่อไปนี้:

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

การคอมไพล์ข้าม

การคอมไพล์ข้ามสามารถทำได้โดยใช้ไฟล์ toolchain CMake ไฟล์ toolchain ระบุคอมไพเลอร์ที่จะใช้ พร้อมด้วยพาธการค้นหาที่กำหนดเองสำหรับไลบรารีและส่วนหัว ไฟล์ toolchain หลายไฟล์สำหรับสถานการณ์ทั่วไปจะรวมอยู่ในแพ็กเกจ release ในไดเร็กทอรี framework/delibs/cmake

นอกเหนือจากตัวแปร CMake มาตรฐานแล้ว ตัวแปรเฉพาะ deqp ต่อไปนี้สามารถตั้งค่าได้โดยไฟล์ toolchain โดยทั่วไป CMake จะสามารถตรวจจับ DE_OS , DE_COMPILER และ DE_PTR_SIZE ได้อย่างถูกต้อง แต่ต้องตั้งค่า DE_CPU โดยไฟล์ toolchain

ตัวแปร	คำอธิบาย
DE_OS	ระบบปฏิบัติการ. ค่าที่รองรับคือ: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER	ประเภทคอมไพเลอร์ ค่าที่รองรับคือ: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU	ประเภทซีพียู ค่าที่รองรับคือ: DE_CPU_ARM, DE_CPU_X86
DE_PTR_SIZE	ขนาดของ(โมฆะ*) บนแพลตฟอร์ม ค่าที่รองรับคือ: 4 และ 8

สามารถเลือกไฟล์ toolchain ได้โดยใช้พารามิเตอร์บิลด์ CMAKE_TOOLCHAIN_FILE ตัวอย่างเช่น สิ่งต่อไปนี้จะสร้าง makefiles สำหรับบิลด์โดยใช้ CodeSourcery cross-compiler สำหรับ 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

การเชื่อมโยงรันไทม์ของไลบรารี GLES และ EGL

deqp ไม่ต้องการจุดเริ่มต้นของ API ที่กำลังทดสอบระหว่างการลิงก์ รหัสทดสอบจะเข้าถึง API ผ่านทางตัวชี้ฟังก์ชันเสมอ จุดเข้าใช้งานสามารถโหลดแบบไดนามิก ณ รันไทม์หรือพอร์ตแพลตฟอร์มสามารถจัดเตรียมให้ ณ เวลาลิงก์

หากเปิดใช้งานการรองรับ API ในการตั้งค่าบิวด์และไม่มีไลบรารีลิงก์ deqp จะโหลดจุดเข้าที่จำเป็น ณ รันไทม์ หากต้องการลิงก์แบบคงที่ ให้จัดเตรียมไลบรารีลิงก์ที่จำเป็นในตัวแปรการกำหนดค่าบิวด์ DEQP_<API>_LIBRARIES

พอร์ตกรอบการทดสอบ

การย้าย deqp เกี่ยวข้องกับสามขั้นตอน: การปรับไลบรารีความสามารถในการพกพาพื้นฐาน การใช้อินเทอร์เฟซการรวมแพลตฟอร์มการทดสอบกรอบงาน และการย้ายบริการดำเนินการ

ตารางด้านล่างแสดงตำแหน่งที่อาจมีการเปลี่ยนแปลงในการย้าย อะไรที่นอกเหนือไปจากนั้นก็มีแนวโน้มที่จะแปลกใหม่

ที่ตั้ง	คำอธิบาย
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	การใช้งานโค้ดเฉพาะ OS ที่จำเป็น
framework/qphelper/qpCrashHandler.c	ทางเลือก: การใช้งานสำหรับระบบปฏิบัติการของคุณ
framework/qphelper/qpWatchDog.c	การใช้งานสำหรับระบบปฏิบัติการของคุณ อันปัจจุบันอิงจากไลบรารี dethread และ C มาตรฐาน
framework/platform	พอร์ตแพลตฟอร์มใหม่และ stub ของแอปพลิเคชันสามารถนำมาใช้ตามที่อธิบายไว้ใน พอร์ตแพลตฟอร์มกรอบการทดสอบ

ไลบรารีความสามารถในการพกพาฐาน

ไลบรารีความสามารถในการพกพาพื้นฐานรองรับ Windows, Linux เวอร์ชันส่วนใหญ่, Mac OS, iOS และ Android แล้ว หากเป้าหมายการทดสอบทำงานบนระบบปฏิบัติการใดระบบหนึ่ง มีแนวโน้มว่าไม่จำเป็นต้องแตะไลบรารีความสามารถในการพกพาพื้นฐานเลย

ทดสอบพอร์ตแพลตฟอร์มเฟรมเวิร์ก

พอร์ตแพลตฟอร์มเฟรมเวิร์กการทดสอบ deqp ต้องการสององค์ประกอบ: จุดเข้าแอปพลิเคชันและการใช้งานอินเทอร์เฟซแพลตฟอร์ม

จุดเข้าใช้งานแอปพลิเคชันมีหน้าที่สร้างออบเจ็กต์แพลตฟอร์ม การสร้างออบเจ็กต์บรรทัดคำสั่ง ( tcu::CommandLine ) เปิดบันทึกการทดสอบ ( tcu::TestLog ) และวนซ้ำแอปพลิเคชันทดสอบ ( tcu::App ) หากระบบปฏิบัติการเป้าหมายรองรับจุดเข้า main() มาตรฐาน ก็สามารถใช้ tcuMain.cpp เป็นการใช้งานจุดเริ่มต้นได้

API แพลตฟอร์ม deqp มีการอธิบายโดยละเอียดในไฟล์ต่อไปนี้

ไฟล์	คำอธิบาย
framework/common/tcuPlatform.hpp	คลาสพื้นฐานสำหรับพอร์ตแพลตฟอร์มทั้งหมด
framework/opengl/gluPlatform.hpp	อินเทอร์เฟซแพลตฟอร์ม OpenGL
framework/egl/egluPlatform.hpp	อินเทอร์เฟซแพลตฟอร์ม EGL
framework/platform/tcuMain.cpp	จุดเข้าใช้งานมาตรฐาน

คลาสพื้นฐานสำหรับพอร์ตแพลตฟอร์มทั้งหมดคือ tcu::Platform พอร์ตแพลตฟอร์มสามารถเลือกรองรับอินเทอร์เฟซเฉพาะ GL- และ EGL ได้ ดูตารางต่อไปนี้เพื่อดูภาพรวมของสิ่งที่จำเป็นต้องดำเนินการเพื่อรันการทดสอบ

โมดูล	อินเตอร์เฟซ
โมดูลทดสอบ OpenGL (ES)	อินเทอร์เฟซแพลตฟอร์ม GL
โมดูลทดสอบ EGL	อินเทอร์เฟซแพลตฟอร์ม EGL

คำแนะนำโดยละเอียดสำหรับการนำพอร์ตแพลตฟอร์มไปใช้อยู่ในส่วนหัวของเลเยอร์การย้าย

บริการดำเนินการทดสอบ

หากต้องการใช้โครงสร้างพื้นฐานการดำเนินการทดสอบ deqp หรือตัวดำเนินการบรรทัดคำสั่ง เซอร์วิสการดำเนินการทดสอบจะต้องพร้อมใช้งานบนเป้าหมาย การใช้งานบริการ C++ แบบพกพามีอยู่ในไดเร็กทอรี execserver ไบนารีแบบสแตนด์อโลนถูกสร้างขึ้นโดยเป็นส่วนหนึ่งของการสร้างโมดูลทดสอบ deqp สำหรับเป้าหมายพีซี คุณสามารถแก้ไข execserver/CMakeLists.txt เพื่อเปิดใช้งานบิลด์บนเป้าหมายอื่น

บริการดำเนินการทดสอบเวอร์ชัน C++ ยอมรับพารามิเตอร์บรรทัดคำสั่งสองตัว:

• --port=<port> จะตั้งค่าพอร์ต TCP ที่เซิร์ฟเวอร์รับฟัง ค่าเริ่มต้นคือ 50016
• --single จะยุติกระบวนการเซิร์ฟเวอร์เมื่อไคลเอนต์ยกเลิกการเชื่อมต่อ ตามค่าเริ่มต้น กระบวนการเซิร์ฟเวอร์จะคงอยู่เพื่อรองรับคำขอดำเนินการทดสอบเพิ่มเติม

ดำเนินการทดสอบ

หน้านี้ให้คำแนะนำสำหรับการรันการทดสอบ deqp ในสภาพแวดล้อม Linux และ Windows การใช้อาร์กิวเมนต์บรรทัดคำสั่ง และการทำงานกับแพ็คเกจแอปพลิเคชัน Android

สภาพแวดล้อม Linux และ Windows

เริ่มต้นด้วยการคัดลอกไฟล์และไดเร็กทอรีต่อไปนี้ไปยังเป้าหมาย

โมดูล	ไดเรกทอรี	เป้า
เซิร์ฟเวอร์การดำเนินการ	build/execserver/execserver	<dst>/execserver
โมดูล EGL	build/modules/egl/deqp-egl	<dst>/deqp-egl
โมดูล GLES2	build/modules/gles2/deqp-gles2	<dst>/deqp-gles2
	data/gles2	<dst>/gles2
โมดูล GLES3	build/modules/gles3/deqp-gles3	<dst>/deqp-gles3
	data/gles3	<dst>/gles3
โมดูล GLES3.1	build/modules/gles31/deqp-gles31	<dst>/deqp-gles31
	data/gles31	<dst>/gles31
โมดูล GLES3.2	build/modules/gles32/deqp-gles32	<dst>/deqp-gles32
	data/gles32	<dst>/gles32

คุณสามารถปรับใช้บริการดำเนินการและทดสอบไบนารีได้ทุกที่ในระบบไฟล์เป้าหมาย อย่างไรก็ตาม ไบนารีทดสอบคาดว่าจะพบไดเร็กทอรีข้อมูลในไดเร็กทอรีการทำงานปัจจุบัน เมื่อพร้อมแล้ว ให้เริ่ม Test Execution Service บนอุปกรณ์เป้าหมาย สำหรับรายละเอียดเกี่ยวกับการเริ่มบริการ โปรดดู บริการการดำเนินการทดสอบ

อาร์กิวเมนต์บรรทัดคำสั่ง

ตารางต่อไปนี้แสดงรายการอาร์กิวเมนต์บรรทัดคำสั่งที่ส่งผลต่อการทำงานของโปรแกรมทดสอบทั้งหมด

การโต้แย้ง	คำอธิบาย
--deqp-case=<casename>	เรียกใช้เคสที่ตรงกับรูปแบบที่กำหนด รองรับไวด์การ์ด (*)
--deqp-log-filename=<filename>	เขียนผลการทดสอบลงในไฟล์ที่คุณระบุชื่อ บริการดำเนินการทดสอบจะตั้งชื่อไฟล์เมื่อเริ่มการทดสอบ
--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>	อ่านรายการเคสจาก stdin หรือจากอาร์กิวเมนต์ที่กำหนด บริการดำเนินการทดสอบจะตั้งค่าอาร์กิวเมนต์ตามคำขอดำเนินการที่ได้รับ ดูส่วนถัดไปสำหรับคำอธิบายของรูปแบบรายการกรณีและปัญหา
--deqp-test-iteration-count=<count>	ลบล้างจำนวนการวนซ้ำสำหรับการทดสอบที่รองรับจำนวนการวนซ้ำแบบแปรผัน
--deqp-base-seed=<seed>	ข้อมูลพื้นฐานสำหรับกรณีทดสอบที่ใช้การสุ่ม

อาร์กิวเมนต์เฉพาะของ GLES2 และ GLES3

ตารางต่อไปนี้แสดงรายการอาร์กิวเมนต์เฉพาะของ GLES2 และ GLES3

การโต้แย้ง	คำอธิบาย
--deqp-gl-context-type=<type>	ประเภทบริบท OpenGL ประเภทบริบทที่ใช้ได้จะขึ้นอยู่กับแพลตฟอร์ม บนแพลตฟอร์มที่รองรับ EGL สามารถใช้ค่า egl เพื่อเลือกบริบท EGL ได้
--deqp-gl-config-id=<id>	รันการทดสอบสำหรับรหัสการกำหนดค่า GL ที่ให้มา การตีความขึ้นอยู่กับแพลตฟอร์ม บนแพลตฟอร์ม EGL นี่คือรหัสการกำหนดค่า EGL
--deqp-gl-config-name=<name>	รันการทดสอบสำหรับการกำหนดค่า GL ที่มีชื่อ การตีความขึ้นอยู่กับแพลตฟอร์ม สำหรับ EGL รูปแบบคือ rgb(a)<bits>d<bits>s<bits> ตัวอย่างเช่น ค่า rgb888s8 จะเลือกการกำหนดค่าแรกที่บัฟเฟอร์สีคือ RGB888 และบัฟเฟอร์สเตนซิลมี 8 บิต
--deqp-gl-context-flags=<flags>	สร้างบริบท ระบุ robust หรือ debug
--deqp-surface-width=<width> --deqp-surface-height=<height>	พยายามสร้างพื้นผิวตามขนาดที่กำหนด การสนับสนุนนี้เป็นทางเลือก
--deqp-surface-type=<type>	ใช้ประเภทพื้นผิวที่กำหนดเป็นเป้าหมายการเรนเดอร์การทดสอบหลัก ประเภทที่เป็นไปได้คือ window , pixmap , pbuffer และ fbo
--deqp-screen-rotation=<rotation>	การวางแนวหน้าจอเพิ่มขึ้น 90 องศาสำหรับแพลตฟอร์มที่รองรับ

รูปแบบรายการกรณีทดสอบ

รายการกรณีทดสอบสามารถกำหนดได้สองรูปแบบ ตัวเลือกแรกคือการแสดงรายการชื่อเต็มของการทดสอบแต่ละรายการในบรรทัดแยกกันในไฟล์ ASCII มาตรฐาน เมื่อชุดการทดสอบเติบโตขึ้น คำนำหน้าซ้ำๆ อาจยุ่งยากได้ เพื่อหลีกเลี่ยงการซ้ำคำนำหน้า ให้ใช้ไวยากรณ์ trie (หรือที่เรียกว่า ต้นไม้คำนำหน้า) ที่แสดงด้านล่าง

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

ตัวอย่างเช่น:

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

แปลเป็นกรณีทดสอบสองกรณีต่อไปนี้:

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

หุ่นยนต์

แพ็คเกจแอปพลิเคชัน Android มีส่วนประกอบที่จำเป็นทั้งหมด รวมถึงบริการดำเนินการทดสอบ ไบนารีทดสอบ และไฟล์ข้อมูล กิจกรรมการทดสอบคือ NativeActivity ที่ใช้ EGL (ต้องใช้ Android 3.2 หรือสูงกว่า)

สามารถติดตั้งแพ็คเกจแอปพลิเคชันได้ด้วยคำสั่งต่อไปนี้ (ชื่อที่แสดงคือชื่อของ APK ในแพ็คเกจ Android CTS ชื่อใดขึ้นอยู่กับบิลด์):

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

หากต้องการเปิดบริการดำเนินการทดสอบและตั้งค่าการส่งต่อพอร์ต ให้ใช้สิ่งต่อไปนี้:

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

สามารถเปิดใช้งานการพิมพ์ดีบักได้โดยดำเนินการต่อไปนี้ก่อนเริ่มการทดสอบ:

adb –d shell setprop log.tag.dEQP DEBUG

ดำเนินการทดสอบบน Android โดยไม่ต้องใช้ Android CTS

หากต้องการเริ่มกิจกรรมการดำเนินการทดสอบด้วยตนเอง ให้สร้าง Intent ของ Android ที่กำหนดเป้าหมายไปที่ android.app.NativeActivity กิจกรรมต่างๆ สามารถพบได้ในแพ็คเกจ com.drawelements.deqp ต้องระบุบรรทัดคำสั่งเป็นสตริงพิเศษพร้อมคีย์ "cmdLine" ใน Intent

บันทึกการทดสอบถูกเขียนลงใน /sdcard/dEQP-log.qpa หากการทดสอบไม่เริ่มต้นตามปกติ ข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติมจะอยู่ในบันทึกของอุปกรณ์

คุณสามารถเปิดกิจกรรมจากบรรทัดคำสั่งโดยใช้ยูทิลิตี้ am ตัวอย่างเช่น หากต้องการรันการทดสอบ dEQP-GLES2.info บนแพลตฟอร์มที่รองรับ NativeActivity, ให้ใช้คำสั่งต่อไปนี้

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

ดีบักบน Android

หากต้องการรันการทดสอบภายใต้ดีบักเกอร์ GDB บน ​​Android ขั้นแรกให้คอมไพล์และติดตั้งบิลด์การดีบักโดยการรันสคริปต์สองตัวต่อไปนี้:

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

หลังจากติดตั้งบิลด์การดีบักบนอุปกรณ์แล้ว หากต้องการเรียกใช้การทดสอบภายใต้ GDB ที่ทำงานบนโฮสต์ ให้รันคำสั่งต่อไปนี้:

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

บรรทัดคำสั่ง deqp ขึ้นอยู่กับกรณีทดสอบที่จะดำเนินการและพารามิเตอร์ที่จำเป็นอื่นๆ สคริปต์เพิ่มเบรกพอยต์เริ่มต้นที่จุดเริ่มต้นของการดำเนินการ deqp ( tcu::App::App )

สคริปต์ debug.py ยอมรับอาร์กิวเมนต์บรรทัดคำสั่งหลายรายการสำหรับการดำเนินการ เช่น การตั้งค่าเบรกพอยต์สำหรับการดีบัก พารามิเตอร์การเชื่อมต่อ gdbserver และเส้นทางไปยังไบนารีเพิ่มเติมเพื่อแก้ไขข้อบกพร่อง (ใช้ debug.py --help สำหรับอาร์กิวเมนต์และคำอธิบายทั้งหมด) สคริปต์ยังคัดลอกไลบรารีเริ่มต้นบางส่วนจากอุปกรณ์เป้าหมายเพื่อรับรายการสัญลักษณ์

ในการก้าวผ่านโค้ดไดรเวอร์ (เช่น เมื่อ GDB ต้องการทราบตำแหน่งของไบนารีพร้อมข้อมูลการดีบักแบบเต็ม) ให้เพิ่มไลบรารีเพิ่มเติมผ่านพารามิเตอร์บรรทัดคำสั่ง debug.py สคริปต์นี้เขียนไฟล์คอนฟิกูเรชันสำหรับ GDB โดยเริ่มจากบรรทัดที่ 132 ของไฟล์สคริปต์ คุณสามารถระบุเส้นทางเพิ่มเติมให้กับไบนารี ฯลฯ ได้ แต่การจัดหาพารามิเตอร์บรรทัดคำสั่งที่ถูกต้องก็เพียงพอแล้ว

หมายเหตุ: บน Windows ไบนารี GDB ต้องใช้ libpython2.7.dll ก่อนที่จะเปิดตัว debug.py ให้เพิ่ม <path-to-ndk>/prebuilt/windows/bin ให้กับตัวแปร PATH

หมายเหตุ: การดีบักโค้ดเนทีฟไม่ทำงานบน Android 4.3 ในสต็อก สำหรับวิธีแก้ปัญหา โปรดดูที่ จุดบกพร่องสาธารณะนี้ Android 4.4 และสูงกว่าไม่มีข้อบกพร่องนี้

ทำการทดสอบอัตโนมัติ

โมดูลทดสอบ Deqp สามารถรวมเข้ากับระบบทดสอบอัตโนมัติได้หลายวิธี แนวทางที่ดีที่สุดขึ้นอยู่กับโครงสร้างพื้นฐานการทดสอบและสภาพแวดล้อมเป้าหมายที่มีอยู่

เอาต์พุตหลักจากการทดสอบการทำงานจะเป็นไฟล์บันทึกการทดสอบเสมอ นั่นคือไฟล์ที่มี postfix .qpa ผลการทดสอบทั้งหมดสามารถแยกวิเคราะห์ได้จากบันทึกการทดสอบ เอาต์พุตคอนโซลเป็นเพียงข้อมูลการดีบักเท่านั้น และอาจไม่พร้อมใช้งานบนทุกแพลตฟอร์ม

ไบนารีทดสอบสามารถเรียกใช้ได้โดยตรงจากระบบทดสอบอัตโนมัติ ไบนารีการทดสอบสามารถเปิดใช้งานได้สำหรับกรณีเฉพาะ สำหรับชุดการทดสอบ หรือสำหรับการทดสอบที่มีอยู่ทั้งหมด หากเกิดข้อผิดพลาดร้ายแรงระหว่างการดำเนินการ (เช่น ข้อผิดพลาด API บางอย่างหรือข้อขัดข้อง) การดำเนินการทดสอบจะถูกยกเลิก สำหรับการทดสอบการถดถอย แนวทางที่ดีที่สุดคือการเรียกใช้ไบนารีการทดสอบสำหรับแต่ละกรณีหรือชุดการทดสอบขนาดเล็กแยกกัน เพื่อให้ได้ผลลัพธ์บางส่วนแม้ในกรณีที่เกิดความล้มเหลวอย่างรุนแรง

deqp มาพร้อมกับเครื่องมือดำเนินการทดสอบบรรทัดคำสั่งที่สามารถใช้ร่วมกับบริการดำเนินการเพื่อให้เกิดการบูรณาการที่แข็งแกร่งยิ่งขึ้น ผู้ดำเนินการตรวจพบการยุติกระบวนการทดสอบ และจะดำเนินการทดสอบต่อในกรณีถัดไปที่พร้อมใช้งาน ไฟล์บันทึกเดียวถูกสร้างขึ้นจากเซสชันการทดสอบทั้งหมด การตั้งค่านี้เหมาะสำหรับระบบทดสอบน้ำหนักเบาที่ไม่มีสิ่งอำนวยความสะดวกในการกู้คืนความเสียหาย

เครื่องมือการดำเนินการทดสอบบรรทัดคำสั่ง

ชุดเครื่องมือบรรทัดคำสั่งปัจจุบันประกอบด้วยเครื่องมือการดำเนินการทดสอบระยะไกล ตัวสร้างการเปรียบเทียบบันทึกการทดสอบสำหรับการวิเคราะห์การถดถอย ตัวแปลง test-log-to-CSV ตัวแปลง test-log-to-XML และตัวแปลง testlog-to-JUnit .

ซอร์สโค้ดสำหรับเครื่องมือเหล่านี้อยู่ในไดเร็กทอรี executor และไบนารีถูกสร้างขึ้นในไดเร็กทอรี <builddir>/executor

ตัวดำเนินการทดสอบบรรทัดคำสั่ง

ตัวดำเนินการทดสอบบรรทัดคำสั่งเป็นเครื่องมือ C++ แบบพกพาสำหรับเรียกใช้การทดสอบบนอุปกรณ์และรวบรวมบันทึกผลลัพธ์จากอุปกรณ์ผ่าน TCP/IP ผู้ดำเนินการสื่อสารกับบริการดำเนินการ (execserver) บนอุปกรณ์เป้าหมาย ทั้งสองอย่างนี้ร่วมกันมอบฟังก์ชันการทำงาน เช่น การกู้คืนจากความล้มเหลวของกระบวนการทดสอบ ตัวอย่างต่อไปนี้สาธิตวิธีใช้ Test Executor บรรทัดคำสั่ง (ใช้ --help เพื่อดูรายละเอียดเพิ่มเติม):

ตัวอย่างที่ 1: เรียกใช้การทดสอบการทำงานของ GLES2 บนอุปกรณ์ 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"

ตัวอย่างที่ 2: ดำเนินการทดสอบ OpenGL ES 2 บางส่วนต่อในเครื่อง

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

ทดสอบการส่งออก CSV บันทึกและเปรียบเทียบ

deqp มีเครื่องมือสำหรับแปลงบันทึกการทดสอบ (ไฟล์ . qpa ) เป็นไฟล์ CSV เอาต์พุต CSV ประกอบด้วยรายการกรณีทดสอบและผลลัพธ์ เครื่องมือยังสามารถเปรียบเทียบผลลัพธ์ของแบทช์ตั้งแต่สองรายการขึ้นไป และแสดงรายการเฉพาะกรณีการทดสอบที่มีรหัสสถานะที่แตกต่างกันในผลลัพธ์ของแบทช์อินพุต การเปรียบเทียบจะพิมพ์จำนวนเคสที่ตรงกันด้วย

เอาต์พุตในรูปแบบ CSV มีประโยชน์อย่างมากสำหรับการประมวลผลเพิ่มเติมด้วยยูทิลิตี้บรรทัดคำสั่งมาตรฐานหรือด้วยโปรแกรมแก้ไขสเปรดชีต คุณสามารถเลือกรูปแบบข้อความธรรมดาเพิ่มเติมที่มนุษย์สามารถอ่านได้โดยใช้อาร์กิวเมนต์บรรทัดคำสั่งต่อไปนี้: --format=text

ตัวอย่างที่ 1: ส่งออกบันทึกการทดสอบในรูปแบบ CSV

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

ตัวอย่างที่ 2: แสดงรายการความแตกต่างของผลการทดสอบระหว่างบันทึกการทดสอบสองรายการ

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

หมายเหตุ: อาร์กิวเมนต์ --value=code จะแสดงโค้ดผลลัพธ์การทดสอบ เช่น "ผ่าน" หรือ "ล้มเหลว" อาร์กิวเมนต์ --value=details เลือกคำอธิบายเพิ่มเติมของผลลัพธ์หรือค่าตัวเลขที่สร้างโดยการทดสอบประสิทธิภาพ ความสามารถ หรือความแม่นยำ

ทดสอบการส่งออก XML บันทึก

ไฟล์บันทึกการทดสอบสามารถแปลงเป็นเอกสาร XML ที่ถูกต้องได้โดยใช้ยูทิลิตี testlog-to-xml รองรับโหมดเอาต์พุตสองโหมด:

• โหมดแยกเอกสาร โดยที่แต่ละกรณีการทดสอบและเอกสารสรุป caselist.xml ถูกเขียนไปยังไดเร็กทอรีปลายทาง
• โหมดไฟล์เดี่ยว โดยที่ผลลัพธ์ทั้งหมดในไฟล์ .qpa จะถูกเขียนลงในเอกสาร XML เดียว

ไฟล์บันทึกการทดสอบที่ส่งออกสามารถดูได้ในเบราว์เซอร์โดยใช้สไตล์ชีต XML เอกสารสไตล์ชีตตัวอย่าง ( testlog.xsl และ testlog.css ) มีอยู่ในไดเร็กทอรี doc/testlog-stylesheet หากต้องการแสดงไฟล์บันทึกในเบราว์เซอร์ ให้คัดลอกไฟล์สไตล์ชีตทั้งสองไฟล์ลงในไดเร็กทอรีเดียวกันกับที่มีเอกสาร XML ที่เอ็กซ์พอร์ตอยู่

หากคุณใช้ Google Chrome ไฟล์จะต้องเข้าถึงได้ผ่าน HTTP เนื่องจาก Chrome จำกัดการเข้าถึงไฟล์ในเครื่องด้วยเหตุผลด้านความปลอดภัย การติดตั้ง Python มาตรฐานประกอบด้วยเซิร์ฟเวอร์ HTTP พื้นฐานที่สามารถเปิดใช้งานเพื่อรองรับไดเร็กทอรีปัจจุบันด้วยคำสั่ง python –m SimpleHTTPServer 8000 หลังจากเปิดตัวเซิร์ฟเวอร์ เพียงชี้เบราว์เซอร์ Chrome ไปที่ http://localhost:8000 เพื่อดูบันทึกการทดสอบ

การแปลงเป็นบันทึกการทดสอบ JUnit

ระบบทดสอบอัตโนมัติจำนวนมากสามารถสร้างรายงานผลการทดสอบจากเอาต์พุต JUnit ไฟล์บันทึกการทดสอบ deqp สามารถแปลงเป็นรูปแบบเอาต์พุต JUnit ได้โดยใช้เครื่องมือ testlog-to-junit

ปัจจุบันเครื่องมือนี้รองรับการแปลคำตัดสินกรณีทดสอบเท่านั้น เนื่องจาก JUnit รองรับเฉพาะผลลัพธ์ "ผ่าน" และ "ล้มเหลว" ผลลัพธ์ที่ส่งผ่านของ deqp จะถูกแมปกับ "JUnit pass" และผลลัพธ์อื่น ๆ จะถือว่าล้มเหลว โค้ดผลลัพธ์ deqp ดั้งเดิมมีอยู่ในเอาต์พุต JUnit ข้อมูลอื่นๆ เช่น ข้อความบันทึกและรูปภาพผลลัพธ์ จะไม่ถูกเก็บไว้ในการแปลง

ใช้กลุ่มทดสอบพิเศษ

กลุ่มการทดสอบบางกลุ่มอาจต้องการหรือสนับสนุนตัวเลือกบรรทัดคำสั่งพิเศษ หรือต้องการการดูแลเป็นพิเศษเมื่อใช้กับบางระบบ

การทดสอบความเครียดในการจัดสรรหน่วยความจำ

การทดสอบความเครียดในการจัดสรรหน่วยความจำจะใช้สภาวะหน่วยความจำไม่เพียงพอโดยการจัดสรรทรัพยากรบางอย่างซ้ำๆ จนกว่าไดรเวอร์จะรายงานข้อผิดพลาดเกี่ยวกับหน่วยความจำไม่เพียงพอ

ในบางแพลตฟอร์ม เช่น Android และ Linux ส่วนใหญ่ สิ่งต่อไปนี้สามารถเกิดขึ้นได้: ระบบปฏิบัติการอาจหยุดกระบวนการทดสอบแทนที่จะปล่อยให้ไดรเวอร์จัดการหรือทำให้เกิดข้อผิดพลาดหน่วยความจำไม่เพียงพอ บนแพลตฟอร์มดังกล่าว การทดสอบที่ออกแบบมาเพื่อทำให้เกิดข้อผิดพลาดหน่วยความจำไม่เพียงพอจะถูกปิดใช้งานตามค่าเริ่มต้น และต้องเปิดใช้งานโดยใช้อาร์กิวเมนต์บรรทัดคำสั่ง --deqp-test-oom=enable ขอแนะนำให้คุณรันการทดสอบดังกล่าวด้วยตนเองเพื่อตรวจสอบว่าระบบทำงานอย่างถูกต้องภายใต้แรงกดดันด้านทรัพยากรหรือไม่ อย่างไรก็ตาม ในสถานการณ์เช่นนี้ ความผิดพลาดของกระบวนการทดสอบควรถูกตีความว่าเป็นการผ่าน

กลุ่มทดสอบ

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

การทดสอบความเครียดในการเรนเดอร์ในระยะยาว

การทดสอบความเครียดในการเรนเดอร์ได้รับการออกแบบมาเพื่อเปิดเผยปัญหาด้านความทนทานภายใต้โหลดการเรนเดอร์อย่างต่อเนื่อง ตามค่าเริ่มต้น การทดสอบจะดำเนินการวนซ้ำเพียงไม่กี่ครั้ง แต่สามารถกำหนดค่าให้รันได้อย่างไม่มีกำหนดโดยระบุอาร์กิวเมนต์บรรทัดคำสั่ง --deqp-test-iteration-count=-1 หน่วยงานเฝ้าระวังการทดสอบควรปิดการใช้งาน ( --deqp-watchdog=disable ) เมื่อทำการทดสอบเหล่านี้เป็นระยะเวลานาน

กลุ่มทดสอบ

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