drawElements গুণমান প্রোগ্রাম পরীক্ষা

AOSP-তে https://android.googlesource.com/platform/external/deqp -এ অবস্থিত drawElements Quality Program (deqp) GPU টেস্টিং স্যুটটি অন্তর্ভুক্ত রয়েছে। এই পৃষ্ঠায় একটি নতুন পরিবেশে deqp টেস্ট স্যুটটি কীভাবে স্থাপন করতে হয় তার বিস্তারিত বর্ণনা দেওয়া হয়েছে।

সর্বশেষ জমা দেওয়া কোড নিয়ে কাজ করার জন্য, deqp-dev ব্রাঞ্চটি ব্যবহার করুন। কোনো নির্দিষ্ট অ্যান্ড্রয়েড CTS রিলিজের সাথে মেলে এমন কোডের জন্য, release-code-name -release ব্রাঞ্চটি ব্যবহার করুন (উদাহরণস্বরূপ, অ্যান্ড্রয়েড ৬.০-এর জন্য marshmallow-release ব্রাঞ্চটি ব্যবহার করুন)।

উৎস বিন্যাস

deqp টেস্ট মডিউল এবং সহায়ক লাইব্রেরিগুলোর সোর্স কোডের বিন্যাস নিচের সারণিতে দেখানো হলো (তালিকাটি সম্পূর্ণ নয়, তবে এতে সবচেয়ে গুরুত্বপূর্ণ ডিরেক্টরিগুলো তুলে ধরা হয়েছে)।

ওপেন সোর্স উপাদান

deqp libpng এবং zlib ব্যবহার করে, যা platform/external/deqp/external/fetch_sources.py স্ক্রিপ্ট ব্যবহার করে অথবা git-এর মাধ্যমে platform/external/[libpng,zlib] থেকে সংগ্রহ করা যায়।

পরীক্ষার প্রোগ্রাম তৈরি করুন

টেস্ট ফ্রেমওয়ার্কটি পোর্টেবিলিটি মাথায় রেখে ডিজাইন করা হয়েছে। এর জন্য একমাত্র আবশ্যিক শর্তগুলো হলো সম্পূর্ণ C++ সাপোর্ট এবং I/O, থ্রেড ও সকেটের জন্য স্ট্যান্ডার্ড সিস্টেম লাইব্রেরি।

CMake বিল্ড সিস্টেম

deqp সোর্সগুলোতে CMake-এর জন্য বিল্ড স্ক্রিপ্ট রয়েছে, যা টেস্ট প্রোগ্রামগুলো কম্পাইল করার জন্য পছন্দের টুল।

CMake একটি ওপেন সোর্স বিল্ড সিস্টেম যা একাধিক প্ল্যাটফর্ম এবং টুলচেইন সমর্থন করে। CMake টার্গেট-নিরপেক্ষ কনফিগারেশন ফাইল থেকে নেটিভ মেকফাইল বা IDE প্রোজেক্ট ফাইল তৈরি করে। CMake সম্পর্কে আরও তথ্যের জন্য, অনুগ্রহ করে CMake ডকুমেন্টেশন দেখুন।

CMake সোর্স ট্রি-এর বাইরে বিল্ড সমর্থন করে এবং এরই সুপারিশ করে, অর্থাৎ, আপনার সবসময় সোর্স ট্রি-এর বাইরে একটি আলাদা বিল্ড ডিরেক্টরিতে মেকফাইল বা প্রোজেক্ট ফাইল তৈরি করা উচিত। CMake-এর কোনো ধরনের 'distclean' টার্গেট নেই, তাই CMake দ্বারা তৈরি যেকোনো ফাইল মুছে ফেলার কাজটি ম্যানুয়ালি করতে হবে।

-D OPTION_NAME = VALUE সিনট্যাক্স ব্যবহার করে CMake-কে কনফিগারেশন অপশন দেওয়া হয়। deqp-এর জন্য সচরাচর ব্যবহৃত কিছু অপশন নিচে দেওয়া হলো।

একটি টার্গেট বিল্ড ফাইল তৈরি করুন

টার্গেট বিল্ড ফাইল ব্যবহার করে ডিইকিউপি (deqp) বিল্ড সিস্টেম নতুন টার্গেটগুলোর জন্য কনফিগার করা হয়। একটি টার্গেট বিল্ড ফাইল নির্ধারণ করে যে প্ল্যাটফর্মটি কোন কোন ফিচার সমর্থন করে এবং কোন কোন লাইব্রেরি বা অতিরিক্ত ইনক্লুড পাথ প্রয়োজন। টার্গেট ফাইলের নামগুলো targets/ NAME / NAME .cmake ফরম্যাট অনুসরণ করে এবং DEQP_TARGET বিল্ড প্যারামিটার ব্যবহার করে টার্গেটটি নির্বাচন করা হয়।

টার্গেট ফাইলগুলির ফাইল পাথগুলি বেস deqp ডিরেক্টরির সাপেক্ষে হয়, targets/ NAME ডিরেক্টরির সাপেক্ষে নয়। নিম্নলিখিত স্ট্যান্ডার্ড ভেরিয়েবলগুলি টার্গেট বিল্ড ফাইল দ্বারা সেট করা যেতে পারে।

টার্গেট বিল্ড ফাইলে include_directories() এবং link_directories() CMake ফাংশন ব্যবহার করে অতিরিক্ত include বা link path যোগ করা যায়।

উইন৩২ বিল্ড

উইন্ডোজের জন্য deqp মডিউল তৈরি করার সবচেয়ে সহজ উপায় হলো CMake বিল্ড সিস্টেম ব্যবহার করা। এর জন্য আপনার CMake 2.6.12 বা তার নতুন সংস্করণ এবং Microsoft Visual C/C++ কম্পাইলার প্রয়োজন হবে। deqp-টি Visual Studio 2013-এর সাথে পরীক্ষা করা হয়েছে।

নিম্নলিখিত কমান্ডের মাধ্যমে ভিজ্যুয়াল স্টুডিও প্রজেক্ট ফাইল তৈরি করা যায়:

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

বিল্ড জেনারেটর হিসেবে 'Visual Studio VERSION Win64' নির্বাচন করে একটি ৬৪-বিট বিল্ড তৈরি করা যায়:

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

আপনি -G "NMake Makefiles" অপশন এবং বিল্ড টাইপ ( -DCMAKE_BUILD_TYPE="Debug" অথবা "Release" ) ব্যবহার করেও NMake মেকফাইল তৈরি করতে পারেন।

রেন্ডার কনটেক্সট তৈরি

উইন্ডোজে WGL অথবা EGL ব্যবহার করে রেন্ডারিং কনটেক্সট তৈরি করা যায়।

WGL সমর্থন

সমস্ত Win32 বাইনারি WGL ব্যবহার করে GL কনটেক্সট তৈরি করা সমর্থন করে, কারণ এর জন্য শুধুমাত্র স্ট্যান্ডার্ড লাইব্রেরি প্রয়োজন হয়। --deqp-gl-context-type=wgl কমান্ড লাইন আর্গুমেন্ট ব্যবহার করে WGL কনটেক্সট নির্বাচন করা যায়। WGL মোডে, deqp ওপেনজিএল ইএস কনটেক্সট তৈরি করার জন্য WGL_EXT_create_context_es_profile এক্সটেনশনটি ব্যবহার করে। এটি NVIDIA এবং Intel-এর সর্বশেষ ড্রাইভারের সাথে কাজ করে বলে পরীক্ষিত। AMD ড্রাইভার প্রয়োজনীয় এক্সটেনশনটি সমর্থন করে না।

EGL সমর্থন

DEQP_SUPPORT_EGL চালু থাকলে, উইন্ডোজে EGL-এর জন্য ডাইনামিক লোডিং সহ deqp বিল্ড করা হয়। বেশিরভাগ টার্গেটে এটিই ডিফল্ট। এরপর, যদি হোস্টে EGL লাইব্রেরিগুলো উপলব্ধ থাকে, তবে কমান্ড লাইন প্যারামিটার --deqp-gl-context-type=egl ব্যবহার করে সেগুলোর সাহায্যে টেস্ট চালানো সম্ভব।

অ্যান্ড্রয়েড বিল্ড

অ্যান্ড্রয়েড বিল্ড নেটিভ টেস্ট কোড তৈরির জন্য CMake বিল্ড স্ক্রিপ্ট ব্যবহার করে। জাভার অংশগুলো, অর্থাৎ টেস্ট এক্সিকিউশন সার্ভার এবং টেস্ট অ্যাপ্লিকেশন স্টাব, স্ট্যান্ডার্ড অ্যান্ড্রয়েড বিল্ড টুল ব্যবহার করে কম্পাইল করা হয়।

প্রদত্ত বিল্ড স্ক্রিপ্ট ব্যবহার করে অ্যান্ড্রয়েডের জন্য deqp টেস্ট প্রোগ্রাম কম্পাইল করতে আপনার প্রয়োজন হবে:

• অ্যান্ড্রয়েড এনডিকে- এর সর্বশেষ সংস্করণ; android/scripts/common.py ফাইলে প্রয়োজনীয় সংস্করণটি তালিকাভুক্ত করা আছে।
• এপিআই ১৩, এসডিকে টুলস, এসডিকে প্ল্যাটফর্ম-টুলস এবং এসডিকে বিল্ড-টুলস প্যাকেজ সহ অ্যান্ড্রয়েড স্ট্যান্ড-অ্যালোন এসডিকে ইনস্টল করা আছে।
• অ্যাপাচি অ্যান্ট ১.৯.৪ (জাভা কোড বিল্ডের জন্য আবশ্যক)
• CMake 2.8.12 বা নতুন সংস্করণ
• পাইথন ২.৬ বা তার ২.x সিরিজের নতুন সংস্করণ; পাইথন ৩.x সমর্থিত নয়।
• উইন্ডোজের জন্য: PATH এ হয় NMake অথবা JOM যোগ করুন।
  • JOM দ্রুততর বিল্ড সক্ষম করে
• ঐচ্ছিক: নিনজা মেক লিনাক্সেও সমর্থিত।

PATH এনভায়রনমেন্ট ভেরিয়েবলের উপর ভিত্তি করে Ant এবং SDK বাইনারিগুলোর অবস্থান নির্ণয় করা হয়, যেখানে কিছু নির্দিষ্ট ডিফল্ট মান প্রযোজ্য থাকে। এই কার্যপ্রণালীটি android/scripts/common.py দ্বারা নিয়ন্ত্রিত হয়।

NDK ডিরেক্টরিটি অবশ্যই ~/android-ndk- VERSION অথবা C:/android/android-ndk- VERSION হতে হবে, অথবা ANDROID_NDK_PATH এনভায়রনমেন্ট ভেরিয়েবলের মাধ্যমে নির্ধারিত হতে হবে।

android/scripts/build.py স্ক্রিপ্টটি এক্সিকিউট করার মাধ্যমে Deqp অন-ডিভাইস কম্পোনেন্ট, টেস্ট এক্সিকিউশন সার্ভিস এবং টেস্ট প্রোগ্রামগুলো বিল্ড করা হয়। চূড়ান্ত অ্যান্ড্রয়েড প্যাকেজ কিট (APK) android/package/bin এ তৈরি হয় এবং install.py স্ক্রিপ্টের মাধ্যমে এটি ইনস্টল করা যায়। যদি কমান্ড লাইন এক্সিকিউটর ব্যবহার করা হয়, তাহলে ডিভাইসে ADB-এর মাধ্যমে launch.py ​​স্ক্রিপ্ট দিয়ে ExecService চালু করা হয়। স্ক্রিপ্টগুলো যেকোনো ডিরেক্টরি থেকে এক্সিকিউট করা যায়।

লিনাক্স বিল্ড

CMake ব্যবহার করে মেকফাইল তৈরির মাধ্যমে লিনাক্সের জন্য টেস্ট বাইনারি এবং কমান্ড লাইন ইউটিলিটি বিল্ড করা যায়। একাধিক পূর্বনির্ধারিত বিল্ড টার্গেট রয়েছে, যা লিনাক্সের জন্য বিল্ড করার সময় বেশ উপযোগী।

বিল্ড টাইপ নির্ধারণ করতে সর্বদা -DCMAKE_BUILD_TYPE=<Debug|Release> ব্যবহার করুন। Release একটি ভালো ডিফল্ট। এটি ছাড়া, একটি ডিফল্ট, অপটিমাইজ না করা রিলিজ বিল্ড তৈরি হয়।

কম্পাইলারে অতিরিক্ত আর্গুমেন্ট পাঠানোর জন্য -DCMAKE_C_FLAGS এবং -DCMAKE_CXX_FLAGS কমান্ড লাইন আর্গুমেন্টগুলো ব্যবহার করা যায়। উদাহরণস্বরূপ, যথাক্রমে -DCMAKE_C(XX)_FLAGS="-m32" বা "-m64" সেট করে ৩২-বিট বা ৬৪-বিট বিল্ড করা যায়। যদি নির্দিষ্ট করে না দেওয়া হয়, তাহলে টুলচেইনের নেটিভ আর্কিটেকচার, যা সাধারণত ৬৪-বিট টুলচেইনে ৬৪-বিট হয়ে থাকে, সেটিই ব্যবহৃত হয়।

CMake-কে অতিরিক্ত লাইব্রেরি বা ইনক্লুড সার্চ পাথ দেওয়ার জন্য -DCMAKE_LIBRARY_PATH এবং -DCMAKE_INCLUDE_PATH আর্গুমেন্টগুলো ব্যবহার করা যায়।

একটি কাস্টম অবস্থানে থাকা ড্রাইভার হেডার এবং লাইব্রেরিগুলোর ওপর ভিত্তি করে ৩২-বিট ডিবাগ বিল্ড করার জন্য ব্যবহৃত একটি সম্পূর্ণ কমান্ড লাইনের উদাহরণ নিচে দেওয়া হলো:

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 অবশ্যই টুলচেইন ফাইলের মাধ্যমে সেট করতে হবে।

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

GLES এবং EGL লাইব্রেরির রানটাইম লিঙ্কিং

লিঙ্কিংয়ের সময় ডিইকিউপি-র পরীক্ষাধীন এপিআই-এর এন্ট্রি পয়েন্টের প্রয়োজন হয় না। টেস্ট কোড সর্বদা ফাংশন পয়েন্টারের মাধ্যমে এপিআইগুলো অ্যাক্সেস করে। এরপর রান টাইমে এন্ট্রি পয়েন্টগুলো ডায়নামিকভাবে লোড করা যেতে পারে অথবা প্ল্যাটফর্ম পোর্ট লিঙ্ক টাইমে সেগুলো সরবরাহ করতে পারে।

যদি বিল্ড সেটিংসে কোনো API-এর জন্য সাপোর্ট চালু করা থাকে এবং লিঙ্ক লাইব্রেরি সরবরাহ করা না হয়, তাহলে deqp রান টাইমে প্রয়োজনীয় এন্ট্রি পয়েন্টগুলো লোড করবে। যদি স্ট্যাটিক লিঙ্কিং প্রয়োজন হয়, তাহলে DEQP_<API>_LIBRARIES বিল্ড কনফিগারেশন ভেরিয়েবলে প্রয়োজনীয় লিঙ্ক লাইব্রেরিগুলো সরবরাহ করুন।

টেস্ট ফ্রেমওয়ার্কটি পোর্ট করুন

deqp পোর্ট করার তিনটি ধাপ রয়েছে: বেস পোর্টেবিলিটি লাইব্রেরিগুলোকে অভিযোজিত করা, টেস্ট-ফ্রেমওয়ার্ক প্ল্যাটফর্ম-ইন্টিগ্রেশন ইন্টারফেসগুলো বাস্তবায়ন করা এবং এক্সিকিউশন সার্ভিস পোর্ট করা।

নিচের সারণিতে সম্ভাব্য পোর্টিং পরিবর্তনের স্থানগুলোর তালিকা দেওয়া হয়েছে। এর বাইরের যেকোনো কিছুই সম্ভবত অস্বাভাবিক হবে।

বেস পোর্টেবিলিটি লাইব্রেরি

বেস পোর্টেবিলিটি লাইব্রেরিগুলো ইতিমধ্যেই উইন্ডোজ, বেশিরভাগ লিনাক্স সংস্করণ, ম্যাক ওএস, আইওএস এবং অ্যান্ড্রয়েড সমর্থন করে। যদি টেস্ট টার্গেটটি এই অপারেটিং সিস্টেমগুলোর কোনো একটিতে চলে, তাহলে সম্ভবত বেস পোর্টেবিলিটি লাইব্রেরিগুলোতে কোনো পরিবর্তন করার প্রয়োজন হবে না।

টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্ট

deqp টেস্ট ফ্রেমওয়ার্ক প্ল্যাটফর্ম পোর্টের জন্য দুটি উপাদানের প্রয়োজন হয়: একটি অ্যাপ্লিকেশন এন্ট্রি পয়েন্ট এবং একটি প্ল্যাটফর্ম ইন্টারফেস ইমপ্লিমেন্টেশন।

অ্যাপ্লিকেশন এন্ট্রি পয়েন্ট প্ল্যাটফর্ম অবজেক্ট তৈরি করা, একটি কমান্ড লাইন ( tcu::CommandLine ) অবজেক্ট তৈরি করা, একটি টেস্ট লগ ( tcu::TestLog ) খোলা এবং টেস্ট অ্যাপ্লিকেশন ( tcu::App ) চালানো—এই কাজগুলোর জন্য দায়ী। যদি টার্গেট অপারেটিং সিস্টেম একটি স্ট্যান্ডার্ড main() এন্ট্রি পয়েন্ট সমর্থন করে, তাহলে এন্ট্রি পয়েন্ট ইমপ্লিমেন্টেশন হিসেবে tcuMain.cpp ব্যবহার করা যেতে পারে।

deqp প্ল্যাটফর্ম API-টি নিম্নলিখিত ফাইলগুলিতে বিশদভাবে বর্ণনা করা হয়েছে।

সমস্ত প্ল্যাটফর্ম পোর্টের বেস ক্লাস হলো tcu::Platform । প্ল্যাটফর্ম পোর্টটি ঐচ্ছিকভাবে GL- এবং EGL-নির্দিষ্ট ইন্টারফেস সমর্থন করতে পারে। টেস্টগুলো চালানোর জন্য কী কী ইমপ্লিমেন্ট করতে হবে তার একটি সার্বিক ধারণা পেতে নিচের সারণিটি দেখুন।

প্ল্যাটফর্ম পোর্ট বাস্তবায়নের বিস্তারিত নির্দেশাবলী পোর্টিং লেয়ার হেডারগুলোতে রয়েছে।

পরীক্ষা সম্পাদন পরিষেবা

deqp টেস্ট এক্সিকিউশন ইনফ্রাস্ট্রাকচার বা কমান্ড লাইন এক্সিকিউটর ব্যবহার করার জন্য, টার্গেটে টেস্ট এক্সিকিউশন সার্ভিসটি অবশ্যই উপলব্ধ থাকতে হবে। সার্ভিসটির একটি পোর্টেবল C++ ইমপ্লিমেন্টেশন execserver ডিরেক্টরিতে দেওয়া আছে। পিসি টার্গেটের জন্য deqp টেস্ট মডিউল বিল্ডের অংশ হিসেবে স্ট্যান্ড-অ্যালোন বাইনারিটি তৈরি করা হয়। অন্যান্য টার্গেটে বিল্ড চালু করার জন্য আপনি execserver/CMakeLists.txt ফাইলটি পরিবর্তন করতে পারেন।

টেস্ট এক্সিকিউশন সার্ভিসের C++ সংস্করণটি দুটি কমান্ড লাইন প্যারামিটার গ্রহণ করে:

• --port=<port> সার্ভার যে TCP পোর্টে শুনবে তা নির্ধারণ করবে। ডিফল্ট পোর্ট হলো 50016।
• ক্লায়েন্ট সংযোগ বিচ্ছিন্ন করলে --single বিকল্পটি সার্ভার প্রসেসটি বন্ধ করে দেবে। ডিফল্টরূপে, পরবর্তী টেস্ট এক্সিকিউশন অনুরোধগুলি সম্পাদন করার জন্য সার্ভার প্রসেসটি চালু থাকবে।

পরীক্ষাগুলো চালান

এই পৃষ্ঠায় লিনাক্স এবং উইন্ডোজ পরিবেশে deqp টেস্ট চালানো, কমান্ড লাইন আর্গুমেন্ট ব্যবহার করা এবং অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্যাকেজ নিয়ে কাজ করার নির্দেশাবলী দেওয়া হয়েছে।

লিনাক্স এবং উইন্ডোজ পরিবেশ

প্রথমে নিম্নলিখিত ফাইল এবং ডিরেক্টরিগুলো টার্গেটে কপি করুন।

আপনি টার্গেট ফাইল সিস্টেমের যেকোনো স্থানে এক্সিকিউশন সার্ভিস এবং টেস্ট বাইনারিগুলো স্থাপন করতে পারেন; তবে, টেস্ট বাইনারিগুলো বর্তমান ওয়ার্কিং ডিরেক্টরিতে ডেটা ডিরেক্টরিগুলো খুঁজে পাওয়ার প্রত্যাশা করে। প্রস্তুত হলে, টার্গেট ডিভাইসে টেস্ট এক্সিকিউশন সার্ভিসটি চালু করুন। সার্ভিসটি চালু করার বিস্তারিত তথ্যের জন্য, টেস্ট এক্সিকিউশন সার্ভিস দেখুন।

কমান্ড লাইন আর্গুমেন্ট

নিম্নলিখিত সারণিতে সেইসব কমান্ড লাইন আর্গুমেন্ট তালিকাভুক্ত করা হয়েছে, যেগুলো সকল টেস্ট প্রোগ্রামের নির্বাহকে প্রভাবিত করে।

GLES2 এবং GLES3-নির্দিষ্ট আর্গুমেন্ট

নিম্নলিখিত সারণিতে GLES2- এবং GLES3-এর জন্য নির্দিষ্ট আর্গুমেন্টগুলো তালিকাভুক্ত করা হয়েছে।

টেস্ট কেস তালিকা বিন্যাস

টেস্ট কেস তালিকা দুটি ফরম্যাটে দেওয়া যেতে পারে। প্রথম বিকল্পটি হলো একটি স্ট্যান্ডার্ড 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 যা EGL ব্যবহার করে (এর জন্য অ্যান্ড্রয়েড ৩.২ বা তার উচ্চতর সংস্করণ প্রয়োজন)।

নিম্নলিখিত কমান্ডের মাধ্যমে অ্যাপ্লিকেশন প্যাকেজটি ইনস্টল করা যেতে পারে (প্রদর্শিত নামটি হলো অ্যান্ড্রয়েড CTS প্যাকেজের APK-এর নাম; এই নামটি বিল্ডের উপর নির্ভর করে):

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.app.NativeActivity টার্গেট করে একটি অ্যান্ড্রয়েড ইন্টেন্ট তৈরি করুন। অ্যাক্টিভিটিগুলো com.drawelements.deqp প্যাকেজে পাওয়া যাবে। ইন্টেন্টের মধ্যে "cmdLine" কী-সহ একটি অতিরিক্ত স্ট্রিং হিসেবে কমান্ড লাইনটি অবশ্যই সরবরাহ করতে হবে।

একটি টেস্ট লগ /sdcard/dEQP-log.qpa তে লেখা হয়। যদি টেস্ট রান স্বাভাবিকভাবে শুরু না হয়, তবে ডিভাইস লগে অতিরিক্ত ডিবাগ তথ্য পাওয়া যায়।

আপনি am ইউটিলিটি ব্যবহার করে কমান্ড লাইন থেকে একটি অ্যাক্টিভিটি চালু করতে পারেন। উদাহরণস্বরূপ, NativeActivity, সমর্থনকারী কোনো প্ল্যাটফর্মে dEQP-GLES2.info টেস্টগুলো চালানোর জন্য, নিম্নলিখিত কমান্ডগুলো ব্যবহার করুন।

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"'

অ্যান্ড্রয়েডে ডিবাগ করুন

অ্যান্ড্রয়েডে GNU ডিবাগার (GDB)-এর অধীনে টেস্টগুলো চালানোর জন্য, প্রথমে নিচের দুটি স্ক্রিপ্ট চালিয়ে ডিবাগ বিল্ডটি কম্পাইল ও ইনস্টল করুন:

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-এর জন্য একটি কনফিগারেশন ফাইল লিখে দেয়। আপনি বাইনারিগুলোর জন্য অতিরিক্ত পাথ দিতে পারেন, কিন্তু সঠিক কমান্ড লাইন প্যারামিটার সরবরাহ করাই যথেষ্ট হওয়া উচিত।

দ্রষ্টব্য: উইন্ডোজে, GDB বাইনারিটির জন্য libpython2.7.dll প্রয়োজন। debug.py চালু করার আগে, PATH ভেরিয়েবলে <path-to-ndk>/prebuilt/windows/bin যোগ করুন।

দ্রষ্টব্য: স্টক অ্যান্ড্রয়েড ৪.৩-এ নেটিভ কোড ডিবাগিং কাজ করে না; এর বিকল্প সমাধানের জন্য এই পাবলিক বাগটি দেখুন। অ্যান্ড্রয়েড ৪.৪ এবং এর পরবর্তী সংস্করণগুলোতে এই বাগটি নেই।

পরীক্ষাগুলো স্বয়ংক্রিয় করুন

Deqp টেস্ট মডিউলগুলোকে স্বয়ংক্রিয় টেস্ট সিস্টেমের সাথে বিভিন্ন উপায়ে সংযুক্ত করা যায়। সর্বোত্তম পন্থাটি বিদ্যমান টেস্ট পরিকাঠামো এবং লক্ষ্য পরিবেশের উপর নির্ভর করে।

একটি টেস্ট রানের প্রাথমিক আউটপুট সর্বদা টেস্ট লগ ফাইল, অর্থাৎ, .qpa পোস্টফিক্সযুক্ত ফাইলটি। টেস্ট লগ থেকে সম্পূর্ণ পরীক্ষার ফলাফল পার্স করা যেতে পারে। কনসোল আউটপুট শুধুমাত্র ডিবাগ তথ্য এবং এটি সব প্ল্যাটফর্মে উপলব্ধ নাও হতে পারে।

টেস্ট বাইনারিগুলো সরাসরি একটি টেস্ট অটোমেশন সিস্টেম থেকে চালু করা যায়। টেস্ট বাইনারিটি একটি নির্দিষ্ট কেসের জন্য, একটি টেস্ট সেটের জন্য, অথবা উপলব্ধ সমস্ত টেস্টের জন্য চালু করা যেতে পারে। এক্সিকিউশনের সময় যদি কোনো মারাত্মক ত্রুটি ঘটে (যেমন নির্দিষ্ট API ত্রুটি বা ক্র্যাশ), তাহলে টেস্ট এক্সিকিউশনটি বাতিল হয়ে যাবে। রিগ্রেশন টেস্টিংয়ের জন্য, সবচেয়ে ভালো পদ্ধতি হলো স্বতন্ত্র কেস বা ছোট টেস্ট সেটের জন্য টেস্ট বাইনারিগুলো আলাদাভাবে চালু করা, যাতে হার্ড ফেইলিউরের ক্ষেত্রেও আংশিক ফলাফল পাওয়া যায়।

deqp-এর সাথে কমান্ড লাইন টেস্ট এক্সিকিউশন টুলস রয়েছে, যা আরও শক্তিশালী ইন্টিগ্রেশন অর্জনের জন্য এক্সিকিউশন সার্ভিসের সাথে একত্রে ব্যবহার করা যেতে পারে। এক্সিকিউটর টেস্ট প্রসেসের সমাপ্তি শনাক্ত করে এবং পরবর্তী উপলব্ধ কেস থেকে টেস্ট এক্সিকিউশন পুনরায় শুরু করে। সম্পূর্ণ টেস্ট সেশন থেকে একটিমাত্র লগ ফাইল তৈরি হয়। এই সেটআপটি সেইসব লাইটওয়েট টেস্ট সিস্টেমের জন্য আদর্শ, যেগুলোতে ক্র্যাশ রিকভারি সুবিধা নেই।

কমান্ড লাইন পরীক্ষা সম্পাদনের সরঞ্জাম

বর্তমান কমান্ড লাইন টুল সেটে একটি রিমোট টেস্ট এক্সিকিউশন টুল, রিগ্রেশন অ্যানালাইসিসের জন্য একটি টেস্ট লগ কম্প্যারিসন জেনারেটর, একটি টেস্ট-লগ-টু-CSV কনভার্টার, একটি টেস্ট-লগ-টু-XML কনভার্টার এবং একটি টেস্টলগ-টু-JUnit কনভার্টার অন্তর্ভুক্ত রয়েছে।

এই টুলগুলির সোর্স কোড executor ডিরেক্টরিতে থাকে এবং বাইনারিগুলি <builddir>/executor ডিরেক্টরিতে বিল্ড করা হয়।

কমান্ড লাইন টেস্ট এক্সিকিউটর

কমান্ড লাইন টেস্ট এক্সিকিউটর হলো একটি পোর্টেবল C++ টুল, যা কোনো ডিভাইসে একটি টেস্ট রান চালু করতে এবং TCP/IP-এর মাধ্যমে এর থেকে প্রাপ্ত লগগুলো সংগ্রহ করতে ব্যবহৃত হয়। এক্সিকিউটরটি টার্গেট ডিভাইসের এক্সিকিউশন সার্ভিসের (execserver) সাথে যোগাযোগ করে। এরা একত্রে টেস্ট প্রসেস ক্র্যাশ থেকে পুনরুদ্ধারের মতো কার্যকারিতা প্রদান করে। নিম্নলিখিত উদাহরণগুলোতে দেখানো হয়েছে কীভাবে কমান্ড লাইন টেস্ট এক্সিকিউটর ব্যবহার করতে হয় (আরও বিস্তারিত জানতে --help ব্যবহার করুন):

উদাহরণ ১: একটি অ্যান্ড্রয়েড ডিভাইসে 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"

উদাহরণ ২: স্থানীয়ভাবে একটি আংশিক 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

উদাহরণ ১: টেস্ট লগ CSV ফরম্যাটে এক্সপোর্ট করুন

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

উদাহরণ ২: দুটি টেস্ট লগের মধ্যে পরীক্ষার ফলাফলের পার্থক্যগুলো তালিকাভুক্ত করুন।

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

দ্রষ্টব্য: --value=code আর্গুমেন্টটি পরীক্ষার ফলাফলের কোড আউটপুট করে, যেমন "Pass" বা "Fail"। --value=details আর্গুমেন্টটি পারফরম্যান্স, ক্যাপাবিলিটি বা অ্যাকুরেসি পরীক্ষার মাধ্যমে প্রাপ্ত ফলাফলের বিস্তারিত ব্যাখ্যা অথবা সাংখ্যিক মান নির্বাচন করে।

টেস্ট লগ XML এক্সপোর্ট

testlog-to-xml ইউটিলিটি ব্যবহার করে টেস্ট লগ ফাইলগুলোকে বৈধ XML ডকুমেন্টে রূপান্তর করা যায়। দুটি আউটপুট মোড সমর্থিত:

• পৃথক ডকুমেন্ট মোড, যেখানে প্রতিটি টেস্ট কেস এবং caselist.xml সামারি ডকুমেন্ট একটি ডেস্টিনেশন ডিরেক্টরিতে লেখা হয়।
• একক ফাইল মোড, যেখানে .qpa ফাইলের সমস্ত ফলাফল একটি একক XML ডকুমেন্টে লেখা হয়।

এক্সপোর্ট করা টেস্ট লগ ফাইলগুলো একটি XML স্টাইল শীট ব্যবহার করে ব্রাউজারে দেখা যায়। নমুনা স্টাইল শীট ডকুমেন্টগুলো ( testlog.xsl এবং testlog.css ) doc/testlog-stylesheet ডিরেক্টরিতে দেওয়া আছে। ব্রাউজারে লগ ফাইলগুলো রেন্ডার করার জন্য, এক্সপোর্ট করা XML ডকুমেন্টগুলো যে ডিরেক্টরিতে রয়েছে, সেই একই ডিরেক্টরিতে স্টাইল শীট ফাইল দুটি কপি করুন।

আপনি যদি গুগল ক্রোম ব্যবহার করেন, তবে ফাইলগুলো অবশ্যই HTTP-এর মাধ্যমে অ্যাক্সেস করতে হবে, কারণ নিরাপত্তাজনিত কারণে ক্রোম লোকাল ফাইল অ্যাক্সেস সীমিত করে। স্ট্যান্ডার্ড পাইথন ইনস্টলেশনে একটি বেসিক HTTP সার্ভার অন্তর্ভুক্ত থাকে, যা python –m SimpleHTTPServer 8000 কমান্ডের মাধ্যমে বর্তমান ডিরেক্টরি পরিবেশন করার জন্য চালু করা যেতে পারে। সার্ভারটি চালু করার পর, টেস্ট লগটি দেখার জন্য শুধু ক্রোম ব্রাউজারটিকে http://localhost:8000 এ নির্দেশ করুন।

JUnit টেস্ট লগে রূপান্তর

অনেক টেস্ট অটোমেশন সিস্টেম JUnit আউটপুট থেকে টেস্ট রানের ফলাফল রিপোর্ট তৈরি করতে পারে। deqp টেস্ট লগ ফাইলগুলোকে testlog-to-junit টুল ব্যবহার করে 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.*