ड्रॉएलिमेंट्स गुणवत्ता कार्यक्रम परीक्षण

AOSP में https://android.googlesource.com/platform/external/deqp पर ड्रॉएलिमेंट्स क्वालिटी प्रोग्राम (deqp) GPU परीक्षण सूट शामिल है। यह पृष्ठ विवरण देता है कि नए वातावरण में डीक्यूपी परीक्षण सूट को कैसे तैनात किया जाए।

नवीनतम सबमिट किए गए कोड के साथ काम करने के लिए, deqp-dev शाखा का उपयोग करें। किसी विशिष्ट एंड्रॉइड सीटीएस रिलीज से मेल खाने वाले कोड के लिए, release-code-name -release शाखा का उपयोग करें (उदाहरण के लिए एंड्रॉइड 6.0 के लिए, marshmallow-release शाखा का उपयोग करें)।

स्रोत लेआउट

डीक्यूपी परीक्षण मॉड्यूल और सहायक पुस्तकालयों के लिए स्रोत कोड लेआउट नीचे दी गई तालिका में दिखाया गया है (सूची व्यापक नहीं है लेकिन सबसे महत्वपूर्ण निर्देशिकाओं पर प्रकाश डालती है)।

निर्देशिका	विवरण
android	एंड्रॉइड परीक्षक स्रोत और स्क्रिप्ट बनाते हैं
data	डेटा फ़ाइलों का परीक्षण करें
modules	परीक्षण मॉड्यूल स्रोत
modules/egl	ईजीएल मॉड्यूल
modules/gles2	GLES2 मॉड्यूल
modules/gles3	GLES3 मॉड्यूल
modules/gles31	GLES3.1 मॉड्यूल
modules/gles32	GLES3.2 मॉड्यूल
targets	लक्ष्य-विशिष्ट बिल्ड कॉन्फ़िगरेशन फ़ाइलें
framework	डीक्यूपी परीक्षण मॉड्यूल ढांचा और उपयोगिताएँ
framework/delibs	पोर्टेबिलिटी को आधार बनाएं और लाइब्रेरी बनाएं
framework/platform	प्लेटफ़ॉर्म पोर्ट
framework/qphelper	परीक्षण कार्यक्रम एकीकरण लाइब्रेरी (सी)
framework/common	डीक्यूपी ढांचा (सी++)
framework/opengl, framework/egl	एपीआई-विशिष्ट उपयोगिताएँ
execserver	डिवाइस-साइड ExecServer स्रोत
executor	होस्ट-साइड परीक्षण निष्पादक शेल उपकरण और उपयोगिताएँ
external	बाहरी libs libpng और zlib के लिए स्टब निर्देशिका बनाएं

खुला स्रोत घटक

Deqp libpng और zlib का उपयोग करता है, जिसे स्क्रिप्ट platform/external/deqp/external/fetch_sources.py उपयोग करके या platform/external/[libpng,zlib] से git के माध्यम से प्राप्त किया जा सकता है।

परीक्षण कार्यक्रम बनाएं

परीक्षण रूपरेखा को पोर्टेबिलिटी को ध्यान में रखकर डिज़ाइन किया गया है। एकमात्र अनिवार्य आवश्यकताएं I/O, थ्रेड्स और सॉकेट के लिए पूर्ण C++ समर्थन और मानक सिस्टम लाइब्रेरी हैं।

सीएमके बिल्ड सिस्टम

डीक्यूपी स्रोतों में सीएमके के लिए बिल्ड स्क्रिप्ट हैं, जो परीक्षण कार्यक्रमों को संकलित करने के लिए पसंदीदा उपकरण है।

सीएमके एक ओपन सोर्स बिल्ड सिस्टम है जो कई प्लेटफार्मों और टूलचेन का समर्थन करता है। सीएमके लक्ष्य-स्वतंत्र कॉन्फ़िगरेशन फ़ाइलों से मूल मेकफ़ाइलें या आईडीई प्रोजेक्ट फ़ाइलें उत्पन्न करता है। सीएमके पर अधिक जानकारी के लिए कृपया सीएमके दस्तावेज देखें।

सीएमके आउट-ऑफ-सोर्स-ट्री बिल्ड का समर्थन और अनुशंसा करता है, यानी, आपको हमेशा सोर्स ट्री के बाहर एक अलग बिल्ड निर्देशिका में मेकफ़ाइल या प्रोजेक्ट फ़ाइलें बनानी चाहिए। सीएमके के पास किसी भी प्रकार का "डिस्टक्लीन" लक्ष्य नहीं है, इसलिए सीएमके द्वारा उत्पन्न किसी भी फाइल को हटाना मैन्युअल रूप से किया जाना चाहिए।

-D OPTION_NAME = VALUE सिंटैक्स का उपयोग करके CMake को कॉन्फ़िगरेशन विकल्प दिए गए हैं। Deqp के लिए आमतौर पर उपयोग किए जाने वाले कुछ विकल्प नीचे सूचीबद्ध हैं।

कॉन्फ़िगरेशन विकल्प	विवरण
DEQP_TARGET	लक्ष्य नाम, उदाहरण के लिए: "एंड्रॉइड" Deqp CMake स्क्रिप्ट में फ़ाइल targets/ DEQP_TARGET / DEQP_TARGET .cmake शामिल होगी और वहां से लक्ष्य-विशिष्ट बिल्ड विकल्प ढूंढने की अपेक्षा की जाएगी।
CMAKE_TOOLCHAIN_FILE	सीएमके के लिए टूलचेन फ़ाइल का पथ। क्रॉस संकलन के लिए उपयोग किया जाता है।
CMAKE_BUILD_TYPE	मेकफ़ाइल लक्ष्यों के लिए निर्माण प्रकार। मान्य मान हैं: "डीबग" और "रिलीज़" ध्यान दें कि व्याख्या और डिफ़ॉल्ट प्रकार लक्षित निर्माण प्रणाली पर निर्भर करते हैं। विवरण के लिए सीएमके दस्तावेज़ देखें।

एक लक्ष्य बिल्ड फ़ाइल बनाएँ

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	क्या ओपनवीजी समर्थित है (डिफ़ॉल्ट: बंद)
DEQP_OPENVG_LIBRARIES	ओपनवीजी लाइब्रेरीज़ (यदि समर्थित नहीं है या डायनेमिक लोडिंग का उपयोग किया जाता है तो खाली छोड़ दें)
DEQP_SUPPORT_EGL	क्या ईजीएल समर्थित है (डिफ़ॉल्ट: बंद)
DEQP_EGL_LIBRARIES	ईजीएल लाइब्रेरीज़ (यदि समर्थित नहीं है या डायनेमिक लोडिंग का उपयोग किया जाता है तो खाली छोड़ दें)
DEQP_PLATFORM_LIBRARIES	लिंक करने के लिए अतिरिक्त प्लेटफ़ॉर्म-विशिष्ट लाइब्रेरीज़ की आवश्यकता है
DEQP_PLATFORM_COPY_LIBRARIES	प्रत्येक परीक्षण बाइनरी बिल्ड निर्देशिका में कॉपी की गई लाइब्रेरीज़ की सूची। उन पुस्तकालयों की प्रतिलिपि बनाने के लिए उपयोग किया जा सकता है जो परीक्षण चलाने के लिए आवश्यक हैं लेकिन डिफ़ॉल्ट खोज पथ में नहीं हैं।
TCUTIL_PLATFORM_SRCS	प्लेटफ़ॉर्म पोर्ट स्रोत सूची. डिफ़ॉल्ट स्रोत क्षमताओं और OS के आधार पर निर्धारित किए जाते हैं। नोट: पथ इनसे संबंधित हैं: framework/platform

लक्ष्य बिल्ड फ़ाइल include_directories() और link_directories() CMake फ़ंक्शंस का उपयोग करके अतिरिक्त शामिल या लिंक पथ जोड़ सकती है।

Win32 का निर्माण

विंडोज़ के लिए डीक्यूपी मॉड्यूल बनाने का सबसे आसान तरीका सीएमके बिल्ड सिस्टम का उपयोग करना है। आपको CMake 2.6.12 या नए और Microsoft Visual C/C++ कंपाइलर की आवश्यकता होगी। डीक्यूपी का परीक्षण विजुअल स्टूडियो 2013 के साथ किया गया है।

विजुअल स्टूडियो प्रोजेक्ट फ़ाइलें निम्नलिखित कमांड से तैयार की जा सकती हैं:

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

बिल्ड जनरेटर के रूप में "विज़ुअल स्टूडियो VERSION Win64" का चयन करके 64-बिट बिल्ड बनाया जा सकता है:

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

आप -G "NMake Makefiles" विकल्प के साथ-साथ बिल्ड प्रकार ( -DCMAKE_BUILD_TYPE="Debug" या "Release" ) के साथ भी NMake मेकफ़ाइलें जेनरेट कर सकते हैं।

संदर्भ निर्माण प्रस्तुत करें

रेंडरिंग संदर्भ या तो WGL के साथ या विंडोज़ पर EGL के साथ बनाया जा सकता है।

डब्लूजीएल समर्थन

सभी Win32 बायनेरिज़ WGL के साथ GL संदर्भ निर्माण का समर्थन करते हैं क्योंकि इसके लिए केवल मानक पुस्तकालयों की आवश्यकता होती है। WGL संदर्भ को --deqp-gl-context-type=wgl कमांड लाइन तर्क का उपयोग करके चुना जा सकता है। WGL मोड में, Deqp OpenGL ES संदर्भ बनाने के लिए WGL_EXT_create_context_es_profile एक्सटेंशन का उपयोग करता है। इसका परीक्षण NVIDIA और Intel के नवीनतम ड्राइवरों के साथ काम करने के लिए किया गया है। AMD ड्राइवर आवश्यक एक्सटेंशन का समर्थन नहीं करते हैं.

ईजीएल समर्थन

यदि DEQP_SUPPORT_EGL चालू है तो Deqp विंडोज़ पर EGL के लिए डायनामिक लोडिंग के साथ बनाया गया है। अधिकांश लक्ष्यों में यह डिफ़ॉल्ट है. फिर, यदि होस्ट के पास ईजीएल लाइब्रेरी उपलब्ध है, तो कमांड लाइन पैरामीटर के साथ उनके साथ परीक्षण चलाना संभव है: --deqp-gl-context-type=egl

एंड्रॉइड बिल्ड

एंड्रॉइड बिल्ड मूल परीक्षण कोड के निर्माण के लिए सीएमके बिल्ड स्क्रिप्ट का उपयोग करता है। जावा पार्ट्स, यानी, टेस्ट एक्ज़ीक्यूशन सर्वर और टेस्ट एप्लिकेशन स्टब, मानक एंड्रॉइड बिल्ड टूल का उपयोग करके संकलित किए जाते हैं।

प्रदान की गई बिल्ड स्क्रिप्ट के साथ एंड्रॉइड के लिए डीक्यूपी परीक्षण प्रोग्राम संकलित करने के लिए, आपको इसकी आवश्यकता होगी:

• एंड्रॉइड एनडीके का नवीनतम संस्करण; android/scripts/common.py फ़ाइल आवश्यक संस्करण सूचीबद्ध करती है
• एपीआई 13, एसडीके टूल्स, एसडीके प्लेटफॉर्म-टूल्स और एसडीके बिल्ड-टूल्स पैकेज के साथ एंड्रॉइड स्टैंड-अलोन एसडीके स्थापित किया गया है
• अपाचे एंट 1.9.4 (जावा कोड बिल्ड द्वारा आवश्यक)
• सीएमके 2.8.12 या नया
• पायथन 2.6 या 2.x श्रृंखला में नया; पायथॉन 3.x समर्थित नहीं है
• विंडोज़ के लिए: PATH में या तो NMake या JOM
  • JOM तेजी से निर्माण सक्षम बनाता है
• वैकल्पिक: निंजा मेक लिनक्स पर भी समर्थित है

चींटी और एसडीके बायनेरिज़ कुछ ओवरराइडिंग डिफ़ॉल्ट के साथ 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 को ADB के माध्यम से डिवाइस पर launch.py स्क्रिप्ट के साथ लॉन्च किया जाता है। स्क्रिप्ट को किसी भी निर्देशिका से निष्पादित किया जा सकता है।

लिनक्स निर्माण

सीएमके का उपयोग करके मेकफाइल्स उत्पन्न करके लिनक्स के लिए टेस्ट बायनेरिज़ और कमांड लाइन उपयोगिताओं का निर्माण किया जा सकता है। कई, पूर्व-निर्धारित निर्माण लक्ष्य हैं जो लिनक्स के लिए निर्माण करते समय उपयोगी होते हैं।

लक्ष्य बनाएं	विवरण
default	डिफ़ॉल्ट लक्ष्य जो विभिन्न एपीआई के लिए समर्थन निर्धारित करने के लिए सीएमके प्लेटफ़ॉर्म आत्मनिरीक्षण का उपयोग करता है।
x11_glx	OpenGL (ES) संदर्भ बनाने के लिए GLX का उपयोग करता है।
x11_egl	ओपनजीएल (ईएस) संदर्भ बनाने के लिए ईजीएल का उपयोग करता है।
x11_egl_glx	X11 के साथ GLX और EGL दोनों को सपोर्ट करता है।

बिल्ड प्रकार को परिभाषित करने के लिए हमेशा -DCMAKE_BUILD_TYPE=<Debug|Release> का उपयोग करें। Release एक अच्छा डिफ़ॉल्ट है. इसके बिना, एक डिफ़ॉल्ट, अअनुकूलित रिलीज़ बिल्ड बनाया जाता है।

-DCMAKE_C_FLAGS और -DCMAKE_CXX_FLAGS कमांड लाइन तर्कों का उपयोग कंपाइलर को अतिरिक्त तर्क पारित करने के लिए किया जा सकता है। उदाहरण के लिए 32-बिट या 64-बिट बिल्ड क्रमशः -DCMAKE_C(XX)_FLAGS="-m32" या "-m64" सेट करके किया जा सकता है। यदि निर्दिष्ट नहीं है, तो टूलचेन मूल आर्किटेक्चर, आमतौर पर 64-बिट टूलचेन पर 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 टूलचेन फ़ाइल का उपयोग करके क्रॉस-कंपाइलिंग प्राप्त की जा सकती है। टूलचेन फ़ाइल लाइब्रेरी और हेडर के लिए कस्टम खोज पथ के साथ-साथ उपयोग करने के लिए कंपाइलर को निर्दिष्ट करती है। सामान्य परिदृश्यों के लिए कई टूलचेन फ़ाइलें framework/delibs/cmake निर्देशिका में रिलीज़ पैकेज में शामिल हैं।

मानक CMake चर के अलावा, निम्नलिखित deqp-विशिष्ट चर टूलचेन फ़ाइल द्वारा सेट किए जा सकते हैं। CMake आमतौर पर DE_OS , DE_COMPILER और DE_PTR_SIZE का सही ढंग से पता लगा सकता है लेकिन DE_CPU टूलचेन फ़ाइल द्वारा सेट किया जाना चाहिए।

चर	विवरण
DE_OS	ऑपरेटिंग सिस्टम। समर्थित मान हैं: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER	संकलक प्रकार. समर्थित मान हैं: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU	सीपीयू प्रकार. समर्थित मान हैं: DE_CPU_ARM, DE_CPU_X86 ।
DE_PTR_SIZE	प्लेटफ़ॉर्म पर sizeof(void*) । समर्थित मान हैं: 4 और 8

टूलचेन फ़ाइल को CMAKE_TOOLCHAIN_FILE बिल्ड पैरामीटर का उपयोग करके चुना जा सकता है। उदाहरण के लिए, निम्नलिखित ARM/Linux के लिए CodeSourcery क्रॉस-कंपाइलर का उपयोग करके एक बिल्ड के लिए मेकफ़ाइलें बनाएगा:

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

जीएलईएस और ईजीएल पुस्तकालयों का रनटाइम लिंकिंग

लिंकिंग के दौरान डीक्यूपी को परीक्षण के तहत एपीआई के प्रवेश बिंदुओं की आवश्यकता नहीं है। परीक्षण कोड हमेशा फ़ंक्शन पॉइंटर्स के माध्यम से एपीआई तक पहुंचता है। प्रवेश बिंदुओं को रन टाइम पर गतिशील रूप से लोड किया जा सकता है या प्लेटफ़ॉर्म पोर्ट उन्हें लिंक समय पर प्रदान कर सकता है।

यदि बिल्ड सेटिंग्स में एपीआई के लिए समर्थन चालू है और लिंक लाइब्रेरी प्रदान नहीं की गई है, तो डीक्यूपी रन टाइम पर आवश्यक प्रविष्टि बिंदुओं को लोड करेगा। यदि स्थैतिक लिंकिंग वांछित है, तो DEQP_<API>_LIBRARIES बिल्ड कॉन्फ़िगरेशन वेरिएबल में आवश्यक लिंक लाइब्रेरी प्रदान करें।

परीक्षण ढांचे को पोर्ट करें

डीक्यूपी को पोर्ट करने में तीन चरण शामिल हैं: बेस पोर्टेबिलिटी लाइब्रेरीज़ को अनुकूलित करना, टेस्ट-फ्रेमवर्क प्लेटफ़ॉर्म-एकीकरण इंटरफेस को लागू करना और निष्पादन सेवा को पोर्ट करना।

नीचे दी गई तालिका संभावित पोर्टिंग परिवर्तनों के लिए स्थानों को सूचीबद्ध करती है। उनसे परे कुछ भी विदेशी होने की संभावना है।

जगह	विवरण
framework/delibs/debase framework/delibs/dethread framework/delibs/deutil	ओएस-विशिष्ट कोड का कोई भी आवश्यक कार्यान्वयन।
framework/qphelper/qpCrashHandler.c	वैकल्पिक: आपके ओएस के लिए कार्यान्वयन।
framework/qphelper/qpWatchDog.c	आपके OS के लिए कार्यान्वयन. वर्तमान dethread और मानक सी लाइब्रेरी पर आधारित है।
framework/platform	नए प्लेटफ़ॉर्म पोर्ट और एप्लिकेशन स्टब को टेस्ट फ्रेमवर्क प्लेटफ़ॉर्म पोर्ट में वर्णित अनुसार लागू किया जा सकता है।

बेस पोर्टेबिलिटी लाइब्रेरीज़

बेस पोर्टेबिलिटी लाइब्रेरीज़ पहले से ही विंडोज़, अधिकांश लिनक्स वेरिएंट, मैक ओएस, आईओएस और एंड्रॉइड का समर्थन करती हैं। यदि परीक्षण लक्ष्य उन ऑपरेटिंग सिस्टमों में से एक पर चलता है, तो संभवतः बेस पोर्टेबिलिटी लाइब्रेरीज़ को छूने की कोई आवश्यकता नहीं है।

टेस्ट फ्रेमवर्क प्लेटफ़ॉर्म पोर्ट

डीक्यूपी टेस्ट फ्रेमवर्क प्लेटफ़ॉर्म पोर्ट के लिए दो घटकों की आवश्यकता होती है: एक एप्लिकेशन एंट्री पॉइंट और एक प्लेटफ़ॉर्म इंटरफ़ेस कार्यान्वयन।

एप्लिकेशन एंट्री पॉइंट प्लेटफ़ॉर्म ऑब्जेक्ट बनाने, कमांड लाइन ( tcu::CommandLine ) ऑब्जेक्ट बनाने, टेस्ट लॉग खोलने ( tcu::TestLog ) और टेस्ट एप्लिकेशन को पुनरावृत्त करने ( tcu::App ) के लिए ज़िम्मेदार है। यदि लक्ष्य OS एक मानक main() प्रविष्टि बिंदु का समर्थन करता है, tcuMain.cpp प्रवेश बिंदु कार्यान्वयन के रूप में उपयोग किया जा सकता है।

Deqp प्लेटफ़ॉर्म API को निम्नलिखित फ़ाइलों में विस्तार से वर्णित किया गया है।

फ़ाइल	विवरण
framework/common/tcuPlatform.hpp	सभी प्लेटफ़ॉर्म पोर्ट के लिए बेस क्लास
framework/opengl/gluPlatform.hpp	ओपनजीएल प्लेटफ़ॉर्म इंटरफ़ेस
framework/egl/egluPlatform.hpp	ईजीएल प्लेटफ़ॉर्म इंटरफ़ेस
framework/platform/tcuMain.cpp	मानक अनुप्रयोग प्रवेश बिंदु

सभी प्लेटफ़ॉर्म पोर्ट के लिए बेस क्लास tcu::Platform है। प्लेटफ़ॉर्म पोर्ट वैकल्पिक रूप से GL- और EGL-विशिष्ट इंटरफ़ेस का समर्थन कर सकता है। परीक्षण चलाने के लिए क्या लागू करने की आवश्यकता है, इसके अवलोकन के लिए निम्न तालिका देखें।

मापांक	इंटरफेस
ओपनजीएल (ईएस) परीक्षण मॉड्यूल	जीएल प्लेटफ़ॉर्म इंटरफ़ेस
ईजीएल परीक्षण मॉड्यूल	ईजीएल प्लेटफ़ॉर्म इंटरफ़ेस

प्लेटफ़ॉर्म पोर्ट लागू करने के लिए विस्तृत निर्देश पोर्टिंग लेयर हेडर में हैं।

परीक्षण निष्पादन सेवा

Deqp परीक्षण निष्पादन अवसंरचना या कमांड लाइन निष्पादक का उपयोग करने के लिए, परीक्षण निष्पादन सेवा लक्ष्य पर उपलब्ध होनी चाहिए। सेवा का एक पोर्टेबल C++ कार्यान्वयन execserver निर्देशिका में प्रदान किया गया है। स्टैंड-अलोन बाइनरी को पीसी लक्ष्यों के लिए डीक्यूपी परीक्षण मॉड्यूल निर्माण के एक भाग के रूप में बनाया गया है। आप अन्य लक्ष्यों पर निर्माण सक्षम करने के लिए execserver/CMakeLists.txt को संशोधित कर सकते हैं।

परीक्षण निष्पादन सेवा का C++ संस्करण दो कमांड लाइन पैरामीटर स्वीकार करता है:

• --port=<port> टीसीपी पोर्ट सेट करेगा जिस पर सर्वर सुनता है। डिफ़ॉल्ट 50016 है.
• --single क्लाइंट के डिस्कनेक्ट होने पर सर्वर प्रक्रिया को समाप्त कर देगा। डिफ़ॉल्ट रूप से, सर्वर प्रक्रिया आगे के परीक्षण निष्पादन अनुरोधों को पूरा करने के लिए चालू रहेगी।

परीक्षण चलाएँ

यह पृष्ठ लिनक्स और विंडोज वातावरण में डीक्यूपी परीक्षण चलाने, कमांड लाइन तर्कों का उपयोग करने और एंड्रॉइड एप्लिकेशन पैकेज के साथ काम करने के निर्देश प्रदान करता है।

लिनक्स और विंडोज़ वातावरण

निम्न फ़ाइलों और निर्देशिकाओं को लक्ष्य पर कॉपी करके प्रारंभ करें।

मापांक	निर्देशिका	लक्ष्य
निष्पादन सर्वर	build/execserver/execserver	<dst>/execserver
ईजीएल मॉड्यूल	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>	ओपनजीएल संदर्भ प्रकार। उपलब्ध संदर्भ प्रकार प्लेटफ़ॉर्म पर निर्भर करते हैं। ईजीएल का समर्थन करने वाले प्लेटफ़ॉर्म पर, egl मान का उपयोग ईजीएल संदर्भ का चयन करने के लिए किया जा सकता है।
--deqp-gl-config-id=<id>	प्रदत्त जीएल कॉन्फ़िगरेशन आईडी के लिए परीक्षण चलाएँ। व्याख्या मंच पर निर्भर है. ईजीएल प्लेटफॉर्म पर, यह ईजीएल कॉन्फ़िगरेशन आईडी है।
--deqp-gl-config-name=<name>	नामित GL कॉन्फ़िगरेशन के लिए परीक्षण चलाएँ। व्याख्या मंच पर निर्भर है. ईजीएल के लिए, प्रारूप rgb(a)<bits>d<bits>s<bits> है। उदाहरण के लिए, rgb888s8 का मान पहले कॉन्फ़िगरेशन का चयन करेगा जहां रंग बफर RGB888 है और स्टेंसिल बफर में 8 बिट हैं।
--deqp-gl-context-flags=<flags>	एक प्रसंग बनाता है. robust या debug निर्दिष्ट करें।
--deqp-surface-width=<width> --deqp-surface-height=<height>	किसी दिए गए आकार के साथ एक सतह बनाने का प्रयास करें। इसके लिए समर्थन वैकल्पिक है.
--deqp-surface-type=<type>	मुख्य परीक्षण रेंडरिंग लक्ष्य के रूप में किसी दिए गए सतह प्रकार का उपयोग करें। संभावित प्रकार हैं window , pixmap , pbuffer , और fbo .
--deqp-screen-rotation=<rotation>	इसका समर्थन करने वाले प्लेटफ़ॉर्म के लिए 90 डिग्री की वृद्धि में स्क्रीन ओरिएंटेशन।

टेस्ट केस सूची प्रारूप

टेस्ट केस सूची दो प्रारूपों में दी जा सकती है। पहला विकल्प मानक ASCII फ़ाइल में प्रत्येक परीक्षण का पूरा नाम एक अलग पंक्ति में सूचीबद्ध करना है। जैसे-जैसे परीक्षण सेट बढ़ते हैं, दोहराए जाने वाले उपसर्ग बोझिल हो सकते हैं। उपसर्गों को दोहराने से बचने के लिए, नीचे दिखाए गए ट्राइ (जिसे उपसर्ग वृक्ष के रूप में भी जाना जाता है) सिंटैक्स का उपयोग करें।

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

उदाहरण के लिए:

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

निम्नलिखित दो परीक्षण मामलों में अनुवादित:

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

एंड्रॉयड

एंड्रॉइड एप्लिकेशन पैकेज में परीक्षण निष्पादन सेवा, परीक्षण बायनेरिज़ और डेटा फ़ाइलों सहित सभी आवश्यक घटक शामिल हैं। परीक्षण गतिविधि एक NativeActivity है जो ईजीएल का उपयोग करती है (एंड्रॉइड 3.2 या उच्चतर की आवश्यकता है)।

एप्लिकेशन पैकेज को निम्नलिखित कमांड के साथ इंस्टॉल किया जा सकता है (दिखाया गया नाम एंड्रॉइड सीटीएस पैकेज में एपीके का नाम है; कौन सा नाम बिल्ड पर निर्भर करता है):

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.app.NativeActivity को लक्षित करता है। गतिविधियाँ com.drawelements.deqp पैकेज में पाई जा सकती हैं। कमांड लाइन को इंटेंट में कुंजी "cmdLine" के साथ एक अतिरिक्त स्ट्रिंग के रूप में प्रदान किया जाना चाहिए।

एक परीक्षण लॉग /sdcard/dEQP-log.qpa पर लिखा जाता है। यदि परीक्षण रन सामान्य रूप से प्रारंभ नहीं होता है, तो अतिरिक्त डिबग जानकारी डिवाइस लॉग में उपलब्ध है।

आप am उपयोगिता का उपयोग करके कमांड लाइन से एक गतिविधि लॉन्च कर सकते हैं। उदाहरण के लिए, NativeActivity का समर्थन करने वाले प्लेटफ़ॉर्म पर 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"'

एंड्रॉइड पर डीबग करें

एंड्रॉइड पर जीडीबी डिबगर के तहत परीक्षण चलाने के लिए, पहले निम्नलिखित दो स्क्रिप्ट चलाकर डिबग बिल्ड को संकलित और इंस्टॉल करें:

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

डिवाइस पर डिबग बिल्ड स्थापित होने के बाद, होस्ट पर चल रहे जीडीबी के तहत परीक्षण लॉन्च करने के लिए, निम्न कमांड चलाएँ:

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 का उपयोग करें)। प्रतीक सूची प्राप्त करने के लिए स्क्रिप्ट लक्ष्य डिवाइस से कुछ डिफ़ॉल्ट लाइब्रेरीज़ को भी कॉपी करती है।

ड्राइवर कोड के माध्यम से कदम उठाने के लिए (जैसे कि जब जीडीबी को पूर्ण डिबग जानकारी के साथ बायनेरिज़ के स्थानों को जानने की आवश्यकता होती है), debug.py कमांड लाइन पैरामीटर के माध्यम से अधिक लाइब्रेरी जोड़ें। यह स्क्रिप्ट स्क्रिप्ट फ़ाइल की पंक्ति 132 से शुरू होकर GDB के लिए एक कॉन्फ़िगरेशन फ़ाइल लिखती है। आप बायनेरिज़ आदि के लिए अतिरिक्त पथ प्रदान कर सकते हैं, लेकिन सही कमांड लाइन पैरामीटर प्रदान करना पर्याप्त होना चाहिए।

नोट: विंडोज़ पर, GDB बाइनरी के लिए libpython2.7.dll की आवश्यकता होती है। debug.py लॉन्च करने से पहले, PATH वेरिएबल में <path-to-ndk>/prebuilt/windows/bin जोड़ें।

नोट: नेटिव कोड डिबगिंग स्टॉक एंड्रॉइड 4.3 पर काम नहीं करता है; समाधान के लिए, इस सार्वजनिक बग को देखें। एंड्रॉइड 4.4 और उच्चतर में यह बग नहीं है।

परीक्षणों को स्वचालित करें

Deqp परीक्षण मॉड्यूल को कई तरीकों से स्वचालित परीक्षण प्रणालियों में एकीकृत किया जा सकता है। सर्वोत्तम दृष्टिकोण मौजूदा परीक्षण अवसंरचना और लक्ष्य वातावरण पर निर्भर करता है।

परीक्षण चलाने से प्राथमिक आउटपुट हमेशा परीक्षण लॉग फ़ाइल होती है, अर्थात .qpa पोस्टफ़िक्स वाली फ़ाइल। पूर्ण परीक्षण परिणाम परीक्षण लॉग से पार्स किए जा सकते हैं। कंसोल आउटपुट केवल डिबग जानकारी है और सभी प्लेटफ़ॉर्म पर उपलब्ध नहीं हो सकता है।

टेस्ट बायनेरिज़ को सीधे टेस्ट ऑटोमेशन सिस्टम से लागू किया जा सकता है। परीक्षण बाइनरी को किसी विशिष्ट मामले के लिए, परीक्षण सेट के लिए, या सभी उपलब्ध परीक्षणों के लिए लॉन्च किया जा सकता है। यदि निष्पादन के दौरान कोई घातक त्रुटि होती है (जैसे कि कुछ एपीआई त्रुटियाँ या क्रैश), तो परीक्षण निष्पादन निरस्त हो जाएगा। प्रतिगमन परीक्षण के लिए, सबसे अच्छा तरीका अलग-अलग मामलों या छोटे परीक्षण सेटों के लिए परीक्षण बायनेरिज़ को अलग से लागू करना है, ताकि कठिन विफलता की स्थिति में भी आंशिक परिणाम उपलब्ध हो सकें।

Deqp कमांड लाइन परीक्षण निष्पादन टूल के साथ आता है जिसका उपयोग अधिक मजबूत एकीकरण प्राप्त करने के लिए निष्पादन सेवा के साथ संयोजन में किया जा सकता है। निष्पादक परीक्षण प्रक्रिया समाप्ति का पता लगाता है और अगले उपलब्ध मामले पर परीक्षण निष्पादन फिर से शुरू करेगा। पूर्ण परीक्षण सत्र से एक एकल लॉग फ़ाइल तैयार की जाती है। यह सेटअप हल्के परीक्षण प्रणालियों के लिए आदर्श है जो क्रैश रिकवरी सुविधाएं प्रदान नहीं करते हैं।

कमांड लाइन परीक्षण निष्पादन उपकरण

वर्तमान कमांड लाइन टूल सेट में एक दूरस्थ परीक्षण निष्पादन उपकरण, प्रतिगमन विश्लेषण के लिए एक परीक्षण लॉग तुलना जनरेटर, एक परीक्षण-लॉग-टू-सीएसवी कनवर्टर, एक परीक्षण-लॉग-टू-एक्सएमएल कनवर्टर और एक टेस्टलॉग-टू-जूनिट कनवर्टर शामिल है। .

इन उपकरणों का स्रोत कोड executor निर्देशिका में है, और बायनेरिज़ <builddir>/executor निर्देशिका में बनाए गए हैं।

कमांड लाइन परीक्षण निष्पादक

कमांड लाइन परीक्षण निष्पादक एक डिवाइस पर परीक्षण चलाने और टीसीपी/आईपी पर परिणामी लॉग एकत्र करने के लिए एक पोर्टेबल सी++ उपकरण है। निष्पादक लक्ष्य डिवाइस पर निष्पादन सेवा (निष्पादक) के साथ संचार करता है। साथ में वे परीक्षण प्रक्रिया क्रैश से पुनर्प्राप्ति जैसी कार्यक्षमता प्रदान करते हैं। निम्नलिखित उदाहरण दर्शाते हैं कि कमांड लाइन टेस्ट एक्ज़ीक्यूटर का उपयोग कैसे करें (अधिक जानकारी के लिए --help उपयोग करें):

उदाहरण 1: एंड्रॉइड डिवाइस पर GLES2 कार्यात्मक परीक्षण चलाएँ

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: स्थानीय स्तर पर आंशिक ओपनजीएल ईएस 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

सीएसवी निर्यात लॉग का परीक्षण करें और तुलना करें

Deqp में परीक्षण लॉग (. qpa फ़ाइलें) को CSV फ़ाइलों में परिवर्तित करने के लिए एक उपकरण है। सीएसवी आउटपुट में परीक्षण मामलों और उनके परिणामों की एक सूची होती है। उपकरण दो या दो से अधिक बैच परिणामों की तुलना भी कर सकता है और केवल उन परीक्षण मामलों को सूचीबद्ध कर सकता है जिनके इनपुट बैच परिणामों में अलग-अलग स्थिति कोड हैं। तुलना मिलान वाले मामलों की संख्या भी प्रिंट करेगी।

मानक कमांड लाइन उपयोगिताओं या स्प्रेडशीट संपादक के साथ आगे की प्रक्रिया के लिए सीएसवी प्रारूप में आउटपुट बहुत व्यावहारिक है। निम्नलिखित कमांड लाइन तर्क का उपयोग करके एक अतिरिक्त, मानव-पठनीय, सादा-पाठ प्रारूप का चयन किया जा सकता है: --format=text

उदाहरण 1: सीएसवी प्रारूप में परीक्षण लॉग निर्यात करें

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 निर्यात

testlog-to-xml उपयोगिता का उपयोग करके टेस्ट लॉग फ़ाइलों को वैध XML दस्तावेज़ों में परिवर्तित किया जा सकता है। दो आउटपुट मोड समर्थित हैं:

• अलग दस्तावेज़ मोड, जहां प्रत्येक परीक्षण केस और caselist.xml सारांश दस्तावेज़ एक गंतव्य निर्देशिका में लिखे जाते हैं
• एकल फ़ाइल मोड, जहां .qpa फ़ाइल के सभी परिणाम एकल XML दस्तावेज़ में लिखे जाते हैं।

निर्यातित परीक्षण लॉग फ़ाइलों को XML स्टाइल शीट का उपयोग करके ब्राउज़र में देखा जा सकता है। नमूना स्टाइल शीट दस्तावेज़ ( testlog.xsl और testlog.css ) doc/testlog-stylesheet निर्देशिका में उपलब्ध कराए गए हैं। ब्राउज़र में लॉग फ़ाइलों को प्रस्तुत करने के लिए, दो स्टाइल शीट फ़ाइलों को उसी निर्देशिका में कॉपी करें जहां निर्यात किए गए XML दस्तावेज़ स्थित हैं।

यदि आप Google Chrome का उपयोग कर रहे हैं, तो फ़ाइलों को HTTP के माध्यम से एक्सेस किया जाना चाहिए क्योंकि Chrome सुरक्षा कारणों से स्थानीय फ़ाइल एक्सेस को सीमित करता है। मानक पायथन इंस्टॉलेशन में एक बुनियादी HTTP सर्वर शामिल होता है जिसे python –m SimpleHTTPServer 8000 कमांड के साथ वर्तमान निर्देशिका की सेवा के लिए लॉन्च किया जा सकता है। सर्वर लॉन्च करने के बाद, परीक्षण लॉग देखने के लिए बस क्रोम ब्राउज़र को http://localhost:8000 पर इंगित करें।

JUnit परीक्षण लॉग में रूपांतरण

कई परीक्षण स्वचालन प्रणालियाँ JUnit आउटपुट से परीक्षण रन परिणाम रिपोर्ट उत्पन्न कर सकती हैं। Deqp परीक्षण लॉग फ़ाइलों को टेस्टलॉग-टू-जूनिट टूल का उपयोग करके JUnit आउटपुट स्वरूप में परिवर्तित किया जा सकता है।

उपकरण वर्तमान में केवल परीक्षण मामले के फैसले का अनुवाद करने का समर्थन करता है। चूंकि JUnit केवल "पास" और "असफल" परिणामों का समर्थन करता है, इसलिए deqp के उत्तीर्ण परिणाम को "JUnit पास" में मैप किया जाता है और अन्य परिणामों को विफल माना जाता है। मूल deqp परिणाम कोड JUnit आउटपुट में उपलब्ध है। अन्य डेटा, जैसे लॉग संदेश और परिणाम छवियां, रूपांतरण में संरक्षित नहीं हैं।

विशेष परीक्षण समूहों का प्रयोग करें

कुछ परीक्षण समूहों को विशेष कमांड लाइन विकल्पों की आवश्यकता या समर्थन हो सकता है, या कुछ प्रणालियों पर उपयोग किए जाने पर विशेष देखभाल की आवश्यकता हो सकती है।

मेमोरी आवंटन तनाव परीक्षण

मेमोरी आवंटन तनाव परीक्षण कुछ संसाधनों को बार-बार आवंटित करके मेमोरी से बाहर की स्थिति का अभ्यास करते हैं जब तक कि ड्राइवर आउट-ऑफ-मेमोरी त्रुटि की रिपोर्ट नहीं करता है।

एंड्रॉइड और अधिकांश लिनक्स वेरिएंट जैसे कुछ प्लेटफार्मों पर, निम्नलिखित हो सकता है: ऑपरेटिंग सिस्टम ड्राइवर को संभालने की अनुमति देने के बजाय परीक्षण प्रक्रिया को समाप्त कर सकता है या अन्यथा आउट-ऑफ-मेमोरी त्रुटि प्रदान कर सकता है। ऐसे प्लेटफ़ॉर्म पर, जो परीक्षण आउट-ऑफ-मेमोरी त्रुटियों का कारण बनने के लिए डिज़ाइन किए गए हैं, वे डिफ़ॉल्ट रूप से अक्षम हैं, और --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.*