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 จะมีไฟล์
|
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 |
รายการแหล่งที่มาของพอร์ตแพลตฟอร์ม แหล่งที่มาเริ่มต้นจะพิจารณาตามความสามารถและระบบปฏิบัติการ หมายเหตุ: เส้นทางจะสัมพันธ์กับ |
ไฟล์บิลด์เป้าหมายสามารถเพิ่มเส้นทางรวมหรือลิงก์เพิ่มเติมได้โดยใช้ฟังก์ชัน 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_COMPILER |
ประเภทคอมไพเลอร์ ค่าที่รองรับมีดังนี้ |
DE_CPU |
ประเภท CPU ค่าที่รองรับมีดังนี้ |
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/qphelper/qpCrashHandler.c |
ไม่บังคับ: การติดตั้งใช้งานสำหรับระบบปฏิบัติการ |
framework/qphelper/qpWatchDog.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 |
อ่านรายการเคสจาก 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-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.*