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

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

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

উৎস বিন্যাস

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

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

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

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

পরীক্ষার কাঠামোটি পোর্টেবিলিটির কথা মাথায় রেখে ডিজাইন করা হয়েছে। একমাত্র বাধ্যতামূলক প্রয়োজনীয়তা হল পূর্ণ C++ সমর্থন এবং I/O, থ্রেড এবং সকেটের জন্য স্ট্যান্ডার্ড সিস্টেম লাইব্রেরি।

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

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 ফাংশন ব্যবহার করে অতিরিক্ত অন্তর্ভুক্ত বা লিঙ্ক পাথ যোগ করতে পারে।

Win32 বিল্ড

উইন্ডোজের জন্য 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" কে বিল্ড জেনারেটর হিসেবে নির্বাচন করে একটি 64-বিট বিল্ড তৈরি করা যেতে পারে:

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

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

প্রসঙ্গ তৈরি রেন্ডার করুন

রেন্ডারিং কনটেক্সট WGL দিয়ে অথবা Windows এ EGL দিয়ে তৈরি করা যেতে পারে।

WGL সাপোর্ট

সমস্ত Win32 বাইনারি WGL দিয়ে GL কনটেক্সট তৈরি সমর্থন করে কারণ এর জন্য শুধুমাত্র স্ট্যান্ডার্ড লাইব্রেরি প্রয়োজন। --deqp-gl-context-type=wgl কমান্ড লাইন আর্গুমেন্ট ব্যবহার করে WGL কনটেক্সট নির্বাচন করা যেতে পারে। WGL মোডে, deqp OpenGL ES কনটেক্সট তৈরি করতে 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 ফাইলটি প্রয়োজনীয় সংস্করণটি তালিকাভুক্ত করে
• API 13, SDK টুলস, SDK প্ল্যাটফর্ম-টুল এবং SDK বিল্ড-টুল প্যাকেজ ইনস্টল সহ Android স্ট্যান্ড-অ্যালোন SDK
• অ্যাপাচি অ্যান্ট ১.৯.৪ (জাভা কোড বিল্ড দ্বারা প্রয়োজনীয়)
• সিমেক ২.৮.১২ বা তার পরবর্তী সংস্করণ
• 2.x সিরিজের Python 2.6 বা তার পরবর্তী সংস্করণ; Python 3.x সমর্থিত নয়
• উইন্ডোজের জন্য: PATH তে হয় NMake অথবা JOM
  • JOM দ্রুত বিল্ড সক্ষম করে
• ঐচ্ছিক: নিনজা মেক লিনাক্সেও সমর্থিত

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 স্ক্রিপ্ট দ্বারা ইনস্টল করা যেতে পারে। যদি কমান্ড লাইন এক্সিকিউটর ব্যবহার করা হয়, তাহলে ADB-এর মাধ্যমে ডিভাইসে launch.py ​​স্ক্রিপ্টের মাধ্যমে ExecService চালু করা হয়। স্ক্রিপ্টগুলি যেকোনো ডিরেক্টরি থেকে কার্যকর করা যেতে পারে।

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

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

বিল্ড টাইপ নির্ধারণ করতে সর্বদা -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-কে অতিরিক্ত লাইব্রেরি দিতে বা অনুসন্ধানের পথ অন্তর্ভুক্ত করতে ব্যবহার করা যেতে পারে।

একটি কাস্টম অবস্থানে ড্রাইভার হেডার এবং লাইব্রেরির বিরুদ্ধে 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 অবশ্যই টুলচেইন ফাইল দ্বারা সেট করা উচিত।

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 লাইব্রেরির রানটাইম লিঙ্কিং

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

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

পরীক্ষার কাঠামোটি পোর্ট করুন

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

নিম্নলিখিত ফাইল এবং ডিরেক্টরিগুলি লক্ষ্যবস্তুতে অনুলিপি করে শুরু করুন।

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

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

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

GLES2 এবং GLES3-নির্দিষ্ট যুক্তি

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

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

পরীক্ষার কেস তালিকা দুটি ফর্ম্যাটে দেওয়া যেতে পারে। প্রথম বিকল্পটি হল প্রতিটি পরীক্ষার পুরো নাম একটি স্ট্যান্ডার্ড 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

অ্যান্ড্রয়েড

অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্যাকেজটিতে পরীক্ষা সম্পাদন পরিষেবা, পরীক্ষা বাইনারি এবং ডেটা ফাইল সহ সমস্ত প্রয়োজনীয় উপাদান রয়েছে। পরীক্ষা কার্যকলাপটি একটি NativeActivity যা EGL ব্যবহার করে (Android 3.2 বা উচ্চতর সংস্করণ প্রয়োজন)।

অ্যাপ্লিকেশন প্যাকেজটি নিম্নলিখিত কমান্ড দিয়ে ইনস্টল করা যেতে পারে (দেখানো নামটি অ্যান্ড্রয়েড সিটিএস প্যাকেজে 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 কে লক্ষ্য করে একটি Android ইন্টেন্ট তৈরি করুন। অ্যাক্টিভিটিগুলি com.drawelements.deqp প্যাকেজে পাওয়া যাবে। কমান্ড লাইনটি Intent-এ "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"'

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

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

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

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

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

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

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

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

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

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

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

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

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

কমান্ড লাইন টেস্ট এক্সিকিউটর হল একটি পোর্টেবল C++ টুল যা একটি ডিভাইসে টেস্ট রান চালু করে এবং TCP/IP এর মাধ্যমে এর ফলে লগ সংগ্রহ করে। এক্সিকিউটর টার্গেট ডিভাইসে এক্সিকিউশন সার্ভিস (এক্সিকিউটর) এর সাথে যোগাযোগ করে। একসাথে তারা টেস্ট প্রসেস ক্র্যাশ থেকে পুনরুদ্ধারের মতো কার্যকারিতা প্রদান করে। নিম্নলিখিত উদাহরণগুলি টেস্ট এক্সিকিউটর কমান্ড লাইন কীভাবে ব্যবহার করতে হয় তা প্রদর্শন করে (আরও বিস্তারিত জানার জন্য --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 পরীক্ষার ফলাফল কোড আউটপুট করে, যেমন "পাস" বা "ফেল"। আর্গুমেন্ট --value=details একটি কর্মক্ষমতা, ক্ষমতা, বা নির্ভুলতা পরীক্ষার দ্বারা উত্পাদিত ফলাফল বা সংখ্যাসূচক মানের আরও ব্যাখ্যা নির্বাচন করে।

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

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

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

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

যদি আপনি গুগল ক্রোম ব্যবহার করেন, তাহলে ফাইলগুলিকে HTTP এর মাধ্যমে অ্যাক্সেস করতে হবে কারণ নিরাপত্তার কারণে Chrome স্থানীয় ফাইল অ্যাক্সেস সীমিত করে। স্ট্যান্ডার্ড পাইথন ইনস্টলেশনে একটি মৌলিক HTTP সার্ভার রয়েছে যা python –m SimpleHTTPServer 8000 কমান্ডের সাহায্যে বর্তমান ডিরেক্টরিটি পরিবেশন করার জন্য চালু করা যেতে পারে। সার্ভার চালু করার পরে, পরীক্ষার লগ দেখতে Chrome ব্রাউজারটিকে 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.*