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 จะรวมไฟล์ |
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 ไม่รองรับส่วนขยายที่จำเป็น
การสนับสนุนอีจีแอล
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_COMPILER | ประเภทคอมไพเลอร์ ค่าที่รองรับคือ: |
DE_CPU | ประเภทซีพียู ค่าที่รองรับคือ: |
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 | การใช้งานโค้ดเฉพาะ OS ที่จำเป็น |
framework/qphelper/qpCrashHandler.c | ทางเลือก: การใช้งานสำหรับระบบปฏิบัติการของคุณ |
framework/qphelper/qpWatchDog.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 | อ่านรายการเคสจาก 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 องศาสำหรับแพลตฟอร์มที่รองรับ |
รูปแบบรายการกรณีทดสอบ
รายการกรณีทดสอบสามารถกำหนดได้สองรูปแบบ ตัวเลือกแรกคือการแสดงรายการชื่อเต็มของการทดสอบแต่ละรายการในบรรทัดแยกกันในไฟล์ 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.*
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2024-03-18 UTC