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

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

หากต้องการใช้โค้ดที่ส่งล่าสุด ให้ใช้กิ่ง deqp-dev สำหรับโค้ดที่ตรงกับการเผยแพร่ CTS ของ Android ที่เฉพาะเจาะจง ให้ใช้กิ่ง release-code-name-release (เช่น สำหรับ Android 6.0 ให้ใช้กิ่ง 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

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

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

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

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

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

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

ระบบบิลด์ CMake

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

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

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

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

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

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

สคริปต์ CMake ของ deqp จะมีไฟล์ 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 ไม่รองรับส่วนขยายที่จำเป็น

การรองรับ EGL

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

บิลด์ Android

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

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

  • Android NDK เวอร์ชันล่าสุด โดยไฟล์ android/scripts/common.py จะแสดงเวอร์ชันที่จำเป็น
  • ติดตั้ง แพ็กเกจ Android SDK แบบสแตนด์อโลนที่มี API 13, SDK Tools, SDK Platform-tools และ 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 ยังรองรับ Ninja Make ด้วย

ระบบจะค้นหาไบนารีของ 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 ได้โดยการสร้างไฟล์ Make โดยใช้ 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 มีเส้นทางการค้นหาไลบรารีหรือเส้นทางการค้นหาเพิ่มเติม

ตัวอย่างบรรทัดคำสั่งแบบเต็มที่ใช้ในการสร้างการดีบักแบบ 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 หลายไฟล์สำหรับสถานการณ์ทั่วไปจะรวมอยู่ในแพ็กเกจรีลีสในไดเรกทอรี framework/delibs/cmake

นอกเหนือจากตัวแปร CMake มาตรฐานแล้ว ไฟล์ Toolchain ยังตั้งค่าตัวแปรต่อไปนี้ที่เฉพาะเจาะจงสำหรับ deqp ได้ โดยปกติแล้ว 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พารามิเตอร์บิลด์ ตัวอย่างเช่น คำสั่งต่อไปนี้จะสร้างไฟล์ Make สำหรับบิลด์โดยใช้ครอสคอมไพเลอร์ 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 ขั้นตอน ได้แก่ การปรับไลบรารีความสามารถในการพกพาพื้นฐาน การติดตั้งใช้งานอินเทอร์เฟซการผสานรวมแพลตฟอร์มของเฟรมเวิร์กการทดสอบ และการพอร์ต บริการการดำเนินการ

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

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

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

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

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

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

ไลบรารีการโอนพื้นฐาน

ไลบรารีการย้ายข้อมูลพื้นฐานรองรับ 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

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

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

อาร์กิวเมนต์เฉพาะ 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 ขึ้นไป)

คุณติดตั้งแพ็กเกจแอปพลิเคชันได้ด้วยคำสั่งต่อไปนี้ (name shown คือชื่อของ APK ในแพ็กเกจ CTS ของ Android ซึ่งชื่อจะขึ้นอยู่กับ บิลด์)

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

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

โปรแกรมเรียกใช้การทดสอบบรรทัดคำสั่ง

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

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

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

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

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

ในบางแพลตฟอร์ม เช่น 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.*