การทดสอบโปรแกรมDrawElements Quality

AOSP มีชุดทดสอบ GPUDrawElements Quality (deqp) ที่ https://android.googlesource.com/platform/external/deqp หน้านี้แสดงรายละเอียดวิธีทำให้ชุดทดสอบ Deqp ใช้งานได้ในสภาพแวดล้อมใหม่

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

เลย์เอาต์ต้นฉบับ

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

ไดเรกทอรี คำอธิบาย
android

แหล่งที่มาของผู้ทดสอบ Android และสคริปต์บิลด์
data

ไฟล์ข้อมูลทดสอบ
modules

แหล่งที่มาของโมดูลทดสอบ
modules/egl

โมดูล 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

เครื่องมือและยูทิลิตี Shell ผู้ดำเนินการทดสอบฝั่งโฮสต์
external

สร้างไดเรกทอรี stub สำหรับ libs ภายนอก libpng และ zlib

คอมโพเนนต์โอเพนซอร์ส

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

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

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

ระบบบิลด์ CMake

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

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

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

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

ตัวเลือกการกำหนดค่า คำอธิบาย
DEQP_TARGET

ชื่อเป้าหมาย เช่น "android"

สคริปต์ Deqp CMake จะมีไฟล์ targets/DEQP_TARGET/DEQP_TARGET.cmake และคาดว่าจะพบ ตัวเลือกบิลด์เฉพาะเป้าหมายจากที่นั่น
CMAKE_TOOLCHAIN_FILE

เส้นทางไปยังไฟล์ Toolchain สำหรับ CMake ใช้สำหรับการคอมไพล์แบบข้ามระบบ
CMAKE_BUILD_TYPE

ประเภทบิลด์สำหรับเป้าหมาย Makefile ค่าที่ถูกต้องคือ "Debug" และ "เผยแพร่"

โปรดทราบว่าการตีความและประเภทเริ่มต้นขึ้นอยู่กับระบบบิลด์เป้าหมาย โปรดดูรายละเอียดในเอกสารประกอบของ 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 โดยใช้ตัวเลือก -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 ไม่สนับสนุน ส่วนขยาย

การรองรับ EGL

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 ติดตั้งแพ็กเกจ Build-tools แล้ว
  • Apache Ant 1.9.4 (จำเป็นสำหรับบิลด์โค้ด Java)
  • CMake 2.8.12 ขึ้นไป
  • Python 2.6 ขึ้นไปในซีรีส์ 2.x ไม่รองรับ Python 3.x
  • สำหรับ Windows: ใช้ NMake หรือ JOM ใน PATH ก็ได้
    • JOM ช่วยให้สร้างบิลด์ได้เร็วขึ้น
  • ไม่บังคับ: 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

สามารถสร้างไบนารีทดสอบและยูทิลิตีบรรทัดคำสั่งสำหรับ Linux ได้โดยการสร้างไฟล์การติดต่อโดยใช้ 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

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

คุณสามารถคอมไพล์ข้ามได้โดยใช้ไฟล์เครื่องมือ CMake Toolchain ระบุคอมไพเลอร์ที่จะใช้ พร้อมด้วยเส้นทางการค้นหาที่กำหนดเองสำหรับ ไลบรารีและส่วนหัว ไฟล์ Toolchain หลายๆ ไฟล์สำหรับสถานการณ์ที่พบบ่อยมีดังนี้ ซึ่งรวมอยู่ในแพ็กเกจรุ่นในไดเรกทอรี 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

ประเภท CPU ค่าที่รองรับคือ DE_CPU_ARM, DE_CPU_X86
DE_PTR_SIZE

sizeof(void*) บนแพลตฟอร์ม ค่าที่รองรับคือ 4 และ 8

คุณเลือกไฟล์ Toolchain ได้โดยใช้พารามิเตอร์บิลด์ CMAKE_TOOLCHAIN_FILE ตัวอย่างเช่น ตัวอย่างต่อไปนี้จะสร้างไฟล์จำนวนมากสำหรับบิลด์โดยใช้ CodeSourcery แบบข้ามคอมไพเลอร์สำหรับ 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 มี 3 ขั้นตอน ได้แก่ การปรับเปลี่ยน Base Portability Library การใช้อินเทอร์เฟซการผสานรวมแพลตฟอร์มที่มีกรอบการทดสอบ และการย้าย ที่ดำเนินการได้

ตารางด้านล่างแสดงสถานที่ตั้งของการเปลี่ยนแปลงที่น่าจะเป็นการย้าย สิ่งอื่นใดนอกเหนือจากนั้น ก็น่าจะแปลกใหม่

ตำแหน่ง คำอธิบาย
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

การใช้งานที่จำเป็นของโค้ดเฉพาะระบบปฏิบัติการ
framework/qphelper/qpCrashHandler.c

ไม่บังคับ: การติดตั้งใช้งานในระบบปฏิบัติการ
framework/qphelper/qpWatchDog.c

การติดตั้งใช้งานสำหรับระบบปฏิบัติการของคุณ ค่าปัจจุบันอิงตาม dethread และไลบรารี C มาตรฐาน
framework/platform

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

ไลบรารีความสามารถในการเคลื่อนย้ายฐาน

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

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

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

จุดแรกเข้าของแอปพลิเคชันมีหน้าที่สร้างออบเจ็กต์แพลตฟอร์ม กำลังสร้างออบเจ็กต์บรรทัดคำสั่ง (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 โปรดดู เพื่อดูภาพรวมของสิ่งที่ต้องดำเนินการเพื่อ ทำการทดสอบ

โมดูล SDK โฆษณา B

โมดูลทดสอบ OpenGL (ES)

อินเทอร์เฟซแพลตฟอร์ม GL

โมดูลการทดสอบ EGL

อินเทอร์เฟซแพลตฟอร์ม EGL

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

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

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

บริการการดำเนินการทดสอบเวอร์ชัน C++ ยอมรับบรรทัดคำสั่ง 2 บรรทัด ได้แก่

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

ทำการทดสอบ

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

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

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

โมดูล ไดเรกทอรี Target
เซิร์ฟเวอร์การเรียกใช้ 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

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

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

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

อาร์กิวเมนต์ คำอธิบาย
--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> Base 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 องศาสำหรับแพลตฟอร์มที่ ก็สนับสนุนได้เลย

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

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

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

เช่น

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

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

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

Android

แพ็กเกจแอปพลิเคชัน 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 หากทำการทดสอบ ไม่เริ่มทำงานตามปกติ อุปกรณ์จะแสดงข้อมูลการแก้ไขข้อบกพร่องเพิ่มเติม log

คุณสามารถเปิดกิจกรรมจากบรรทัดคำสั่งได้โดยใช้ 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 ให้คอมไพล์และติดตั้งก่อน บิลด์การแก้ไขข้อบกพร่องด้วยการเรียกใช้สคริปต์ 2 รายการต่อไปนี้

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 สามารถผสานรวมเข้ากับระบบทดสอบอัตโนมัติได้หลายวิธี วิธีที่ดีที่สุดขึ้นอยู่กับโครงสร้างพื้นฐานและเป้าหมายการทดสอบที่มีอยู่ ของคุณ

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

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

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

เครื่องมือทดสอบบรรทัดคำสั่ง

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

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

ผู้ดำเนินการทดสอบบรรทัดคำสั่ง

การดำเนินการทดสอบบรรทัดคำสั่งเป็นเครื่องมือ C++ แบบพกพาสำหรับเรียกใช้การทดสอบ ในอุปกรณ์และเก็บรวบรวมบันทึกที่ได้จากอุปกรณ์ผ่าน TCP/IP ผู้บริหาร สื่อสารกับบริการดำเนินการ (execserver) ในอุปกรณ์เป้าหมาย รวมทั้งมีฟังก์ชันการทำงานต่างๆ เช่น การกู้คืนจากข้อขัดข้องของกระบวนการทดสอบ ตัวอย่างต่อไปนี้สาธิตวิธีใช้ตัวดำเนินการทดสอบบรรทัดคำสั่ง (ใช้ --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 เอาต์พุตจะมีรายการกรอบการทดสอบและ ผลลัพธ์ เครื่องมือนี้ยังสามารถเปรียบเทียบผลลัพธ์แบบกลุ่มตั้งแต่ 2 รายการขึ้นไปและแสดงเฉพาะ กรอบการทดสอบที่มีรหัสสถานะแตกต่างกันในผลลัพธ์ของกลุ่มอินพุต ก็จะพิมพ์จำนวนเคสที่ตรงกันด้วย

เอาต์พุตในรูปแบบ 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: แสดงรายการความแตกต่างของผลการทดสอบระหว่างบันทึกการทดสอบ 2 รายการ
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

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

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

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

  • โหมดเอกสารแยกต่างหาก โดยจะใช้แต่ละกรอบการทดสอบและข้อมูลสรุป 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" และผลลัพธ์อื่นๆ จะถือว่าล้มเหลว Deqp เดิม รหัสผลลัพธ์จะอยู่ในเอาต์พุต JUnit ข้อมูลอื่นๆ เช่น ข้อความบันทึก และรูปภาพผลลัพธ์ จะไม่ปรากฏใน Conversion

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

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

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

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

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

กลุ่มทดสอบ

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

การทดสอบความเครียดในการแสดงภาพที่ใช้เวลานาน

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

กลุ่มทดสอบ

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