Pemrograman grafis tidak hanya sumber kesenangan, tetapi juga frustrasi ketika sesuatu tidak ditampilkan sebagaimana dimaksud, atau tidak ada yang ditampilkan di layar sama sekali. Melihat bahwa sebagian besar yang kami lakukan terkait dengan manipulasi piksel, mungkin sulit untuk mengetahui penyebab kesalahan ketika sesuatu tidak berfungsi sebagaimana mestinya. Debugging jenis kesalahan ini lebih sulit daripada kesalahan debugging pada CPU. Kami tidak memiliki konsol tempat kami dapat menampilkan teks, kami tidak dapat meletakkan breakpoint di shader dan kami tidak bisa hanya mengambil dan memeriksa status program pada GPU.

Dalam tutorial ini, kami akan memperkenalkan Anda kepada beberapa metode dan teknik debugging untuk program OpenGL Anda. Debugging di OpenGL tidak begitu sulit, dan mempelajari beberapa trik pasti akan membuahkan hasil.

glGetError ()

Ketika Anda menggunakan OpenGL secara tidak benar (misalnya, ketika Anda mengatur buffer dan lupa untuk mengikatnya), OpenGL akan melihat dan membuat satu atau beberapa flag kesalahan khusus di belakang layar. Kita dapat melacak kesalahan ini dengan memanggil fungsi glGetError() , yang hanya memeriksa flag kesalahan yang diatur dan mengembalikan nilai kesalahan jika terjadi kesalahan.

 GLenum glGetError(); 

Fungsi ini mengembalikan bendera kesalahan atau tidak ada kesalahan sama sekali. Daftar Nilai Pengembalian:

Di dalam dokumentasi untuk fungsi OpenGL, Anda dapat menemukan kode kesalahan yang dihasilkan oleh fungsi yang salah digunakan. Misalnya, jika Anda melihat dokumentasi untuk fungsi glBindTexture() , Anda dapat menemukan kode kesalahan yang dihasilkan oleh fungsi ini di bagian Kesalahan.
Ketika bendera kesalahan diatur, tidak ada bendera kesalahan lain yang akan dihasilkan. Selain itu, ketika glGetError dipanggil, fungsi menghapus semua flag kesalahan (atau hanya satu pada sistem terdistribusi, lihat di bawah). Ini berarti bahwa jika Anda memanggil glGetError sekali setelah setiap frame dan mendapatkan kesalahan, ini tidak berarti bahwa ini adalah satu-satunya kesalahan dan Anda masih tidak tahu di mana kesalahan ini terjadi.

Perhatikan bahwa ketika OpenGL bekerja secara terdistribusi, seperti yang sering terjadi pada sistem dengan X11, kesalahan lain dapat dihasilkan ketika mereka memiliki kode yang berbeda. Memanggil glGetError kemudian hanya glGetError salah satu flag kode kesalahan alih-alih semua. Karena itu, mereka merekomendasikan untuk memanggil fungsi ini dalam satu lingkaran.

 glBindTexture(GL_TEXTURE_2D, tex); std::cout << glGetError() << std::endl; //  0 ( ) glTexImage2D(GL_TEXTURE_3D, 0, GL_RGB, 512, 512, 0, GL_RGB, GL_UNSIGNED_BYTE, data); std::cout << glGetError() << std::endl; //  1280 ( ) glGenTextures(-5, textures); std::cout << glGetError() << std::endl; //  1281 (  std::cout << glGetError() << std::endl; //  0 ( ) 

Fitur khas glGetError adalah membuatnya relatif mudah untuk menentukan di mana kesalahan dapat terjadi dan memverifikasi bahwa OpenGL digunakan dengan benar. Katakanlah Anda tidak menggambar apa pun, dan Anda tidak tahu apa alasannya: penyangga bingkai tidak disetel dengan benar? Lupa mengatur tekstur? Dengan memanggil glGetError mana-mana, Anda dapat dengan cepat mengetahui di mana kesalahan pertama terjadi.
Secara default, glGetError melaporkan hanya nomor kesalahan, yang tidak mudah dimengerti sampai Anda mengingat nomor kode. Seringkali masuk akal untuk menulis fungsi kecil untuk membantu mencetak string kesalahan bersama dengan lokasi dari mana fungsi dipanggil.

 GLenum glCheckError_(const char *file, int line) { GLenum errorCode; while ((errorCode = glGetError()) != GL_NO_ERROR) { std::string error; switch (errorCode) { case GL_INVALID_ENUM: error = "INVALID_ENUM"; break; case GL_INVALID_VALUE: error = "INVALID_VALUE"; break; case GL_INVALID_OPERATION: error = "INVALID_OPERATION"; break; case GL_STACK_OVERFLOW: error = "STACK_OVERFLOW"; break; case GL_STACK_UNDERFLOW: error = "STACK_UNDERFLOW"; break; case GL_OUT_OF_MEMORY: error = "OUT_OF_MEMORY"; break; case GL_INVALID_FRAMEBUFFER_OPERATION: error = "INVALID_FRAMEBUFFER_OPERATION"; break; } std::cout << error << " | " << file << " (" << line << ")" << std::endl; } return errorCode; } #define glCheckError() glCheckError_(__FILE__, __LINE__) 

Jika Anda memutuskan untuk membuat lebih banyak panggilan ke glCheckError , akan berguna untuk mengetahui di mana kesalahan terjadi.

 glBindBuffer(GL_VERTEX_ARRAY, vbo); glCheckError(); 

Kesimpulan:

Satu hal penting tetap ada: ada bug lama di GLEW: glewInit() selalu mengatur flag GL_INVALID_ENUM . Untuk memperbaikinya, cukup panggil glGetError setelah glewInit untuk menghapus flag:

 glewInit(); glGetError(); 

glGetError tidak banyak membantu, karena informasi yang dikembalikan relatif sederhana, tetapi sering membantu untuk menangkap kesalahan ketik atau menangkap tempat di mana kesalahan terjadi. Ini adalah alat debugging yang sederhana namun efektif.

Output debug

Alat ini kurang dikenal, tetapi lebih bermanfaat daripada glCheckError , ekstensi "debug output" OpenGL, yang dimasukkan dalam Profil Inti OpenGL 4.3. Dengan ekstensi ini, OpenGL akan mengirim pesan kesalahan kepada pengguna dengan detail kesalahan. Ekstensi ini tidak hanya menyediakan lebih banyak informasi, tetapi juga memungkinkan Anda untuk menangkap kesalahan di mana mereka terjadi menggunakan debugger.

Output debug disertakan dalam OpenGL dimulai dengan versi 4.3, yang berarti Anda akan menemukan fungsionalitas ini pada mesin apa pun yang mendukung OpenGL 4.3 dan lebih tinggi. Jika versi ini tidak tersedia, maka Anda dapat memeriksa ekstensi ARB_debug_output dan AMD_debug_output . Ada juga informasi yang tidak diverifikasi bahwa hasil debug tidak didukung pada OS X (penulis asli dan penerjemah belum diuji, harap informasikan penulis asli atau kepada saya dalam pesan pribadi melalui mekanisme koreksi kesalahan, jika Anda menemukan konfirmasi atau bantahan atas fakta ini; UPD: Jeka178RUS memeriksa ini fakta: di luar kotak, output debug tidak berfungsi, ia tidak memeriksa ekstensi).

Untuk mulai menggunakan output debug, kita perlu meminta konteks debug OpenGL selama proses inisialisasi. Proses ini berbeda pada sistem jendela yang berbeda, tetapi di sini kita hanya akan membahas GLFW, tetapi pada akhir artikel di bagian "Bahan Tambahan" Anda dapat menemukan informasi tentang sistem jendela lainnya.

Output debug dalam GLFW

Meminta konteks debugging di GLFW ternyata sangat sederhana: yang perlu Anda lakukan hanyalah memberi GLFW petunjuk bahwa kami menginginkan konteks yang mendukung output debugging. Kita perlu melakukan ini sebelum memanggil glfwCreateWindow :

 glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GL_TRUE); 

Segera setelah kita menginisialisasi GLFW, kita harus memiliki konteks debugging jika kita menggunakan OpenGL 4.3 atau lebih tinggi, kalau tidak kita perlu mencoba keberuntungan kita dan berharap bahwa sistem masih dapat membuat konteks debugging. Jika terjadi kegagalan, kita perlu meminta hasil debug melalui mekanisme ekstensi OpenGL.

Konteks debug OpenGL bisa lebih lambat dari biasanya, jadi Anda harus menghapus atau mengomentari baris ini saat mengerjakan optimasi atau sebelum rilis.

Untuk memeriksa hasil inisialisasi konteks debug, cukup dengan menjalankan kode berikut:

 GLint flags; glGetIntegerv(GL_CONTEXT_FLAGS, &flags); if (flags & GL_CONTEXT_FLAG_DEBUG_BIT) { //  } else { //   } 

Bagaimana cara kerja output debug? Kami meneruskan fungsi panggilan balik ke penangan pesan di OpenGL (mirip dengan panggilan balik di GLFW) dan dalam fungsi ini kami dapat memproses data OpenGL sesuai keinginan, dalam kasus kami mengirim pesan kesalahan yang berguna ke konsol. Prototipe fungsi ini:

 void APIENTRY glDebugOutput(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar *message, void *userParam); 

Perhatikan bahwa pada beberapa sistem operasi jenis parameter terakhir mungkin tidak const void* .
Dengan kumpulan data besar yang kami miliki, kami dapat membuat alat pencetakan kesalahan yang bermanfaat, seperti yang ditunjukkan di bawah ini:

 void APIENTRY glDebugOutput(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar *message, void *userParam) { // ignore non-significant error/warning codes if(id == 131169 || id == 131185 || id == 131218 || id == 131204) return; std::cout << "---------------" << std::endl; std::cout << "Debug message (" << id << "): " << message << std::endl; switch (source) { case GL_DEBUG_SOURCE_API: std::cout << "Source: API"; break; case GL_DEBUG_SOURCE_WINDOW_SYSTEM: std::cout << "Source: Window System"; break; case GL_DEBUG_SOURCE_SHADER_COMPILER: std::cout << "Source: Shader Compiler"; break; case GL_DEBUG_SOURCE_THIRD_PARTY: std::cout << "Source: Third Party"; break; case GL_DEBUG_SOURCE_APPLICATION: std::cout << "Source: Application"; break; case GL_DEBUG_SOURCE_OTHER: std::cout << "Source: Other"; break; } std::cout << std::endl; switch (type) { case GL_DEBUG_TYPE_ERROR: std::cout << "Type: Error"; break; case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR: std::cout << "Type: Deprecated Behaviour"; break; case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR: std::cout << "Type: Undefined Behaviour"; break; case GL_DEBUG_TYPE_PORTABILITY: std::cout << "Type: Portability"; break; case GL_DEBUG_TYPE_PERFORMANCE: std::cout << "Type: Performance"; break; case GL_DEBUG_TYPE_MARKER: std::cout << "Type: Marker"; break; case GL_DEBUG_TYPE_PUSH_GROUP: std::cout << "Type: Push Group"; break; case GL_DEBUG_TYPE_POP_GROUP: std::cout << "Type: Pop Group"; break; case GL_DEBUG_TYPE_OTHER: std::cout << "Type: Other"; break; } std::cout << std::endl; switch (severity) { case GL_DEBUG_SEVERITY_HIGH: std::cout << "Severity: high"; break; case GL_DEBUG_SEVERITY_MEDIUM: std::cout << "Severity: medium"; break; case GL_DEBUG_SEVERITY_LOW: std::cout << "Severity: low"; break; case GL_DEBUG_SEVERITY_NOTIFICATION: std::cout << "Severity: notification"; break; } std::cout << std::endl; std::cout << std::endl; } 

Ketika ekstensi mendeteksi kesalahan OpenGL, ia akan memanggil fungsi ini dan kami dapat mencetak sejumlah besar informasi kesalahan. Perhatikan bahwa kami mengabaikan beberapa kesalahan, karena tidak berguna (misalnya, 131185 pada driver NVidia menunjukkan bahwa buffer telah berhasil dibuat).
Sekarang kita memiliki panggilan balik yang diinginkan, sekarang saatnya untuk menginisialisasi output debug:

 if (flags & GL_CONTEXT_FLAG_DEBUG_BIT) { glEnable(GL_DEBUG_OUTPUT); glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS); glDebugMessageCallback(glDebugOutput, nullptr); glDebugMessageControl(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, nullptr, GL_TRUE); } 

Jadi kami memberi tahu OpenGL bahwa kami ingin mengaktifkan hasil debug. Panggilan ke glEnable(GL_DEBUG_SYNCRHONOUS) memberi tahu OpenGL bahwa kami menginginkan pesan kesalahan ketika baru saja terjadi.

Penyaringan Output Debug

Dengan fungsi glDebugMessageControl Anda dapat memilih jenis kesalahan yang ingin Anda terima. Dalam kasus kami, kami mendapatkan semua jenis kesalahan. Jika kami hanya menginginkan kesalahan OpenGL API, seperti Kesalahan dan tingkat signifikansi Tinggi, kami akan menulis kode berikut:

 glDebugMessageControl(GL_DEBUG_SOURCE_API, GL_DEBUG_TYPE_ERROR, GL_DEBUG_SEVERITY_HIGH, 0, nullptr, GL_TRUE); 

Dengan konfigurasi dan konteks debugging ini, setiap perintah OpenGL yang salah akan mengirim banyak informasi berguna:

Temukan sumber kesalahan melalui tumpukan panggilan

Trik lain dengan output debugging adalah Anda relatif dapat dengan mudah menentukan lokasi kesalahan dalam kode Anda. Dengan mengatur breakpoint di fungsi DebugOutput pada jenis kesalahan yang diinginkan (atau di awal fungsi jika Anda ingin menangkap semua kesalahan), debugger akan menangkap kesalahan dan Anda dapat menavigasi tumpukan panggilan untuk mengetahui di mana kesalahan terjadi:

Ini memerlukan beberapa intervensi manual, tetapi jika Anda tahu kira-kira apa yang Anda cari, sangat berguna untuk dengan cepat menentukan panggilan mana yang menyebabkan kesalahan.

Kesalahan sendiri

Seiring dengan kesalahan membaca, kami dapat mengirimkannya ke sistem keluaran debug menggunakan glDebugMessageInsert :

 glDebugMessageInsert(GL_DEBUG_SOURCE_APPLICATION, GL_DEBUG_TYPE_ERROR, 0, GL_DEBUG_SEVERITY_MEDIUM, -1, "error message here"); 

Ini sangat berguna jika Anda terhubung ke aplikasi lain atau kode OpenGL yang menggunakan konteks debugging. Pengembang lain akan dapat dengan cepat mengetahui kesalahan yang dilaporkan yang terjadi pada kode OpenGL khusus Anda.
Secara umum, output debugging (jika tersedia) sangat berguna untuk menangkap kesalahan dengan cepat dan pasti sepadan dengan usaha yang dihabiskan untuk penyetelan, karena menghemat waktu pengembangan yang signifikan. Anda dapat menemukan salinan kode sumber di sini menggunakan glGetError dan hasil debug. Ada kesalahan, coba perbaiki.

Output debug Shader

Ketika datang ke GLSL, kami tidak memiliki akses ke fungsi-fungsi seperti glGetError atau kemampuan untuk berjalan melalui kode dalam langkah-langkah dalam debugger. Ketika Anda menemukan layar hitam atau layar yang sama sekali tidak benar, bisa sangat sulit untuk memahami apa yang terjadi jika masalahnya ada di shader. Ya, kesalahan kompilasi melaporkan kesalahan sintaks, tetapi menangkap kesalahan semantik adalah lagu itu.
Salah satu metode yang umum digunakan untuk mencari tahu apa yang salah dengan shader adalah mengirim semua variabel yang relevan dalam program shader langsung ke saluran output dari shader fragmen. Dengan mengeluarkan variabel shader langsung ke saluran output dengan warna, kita dapat menemukan informasi menarik dengan memeriksa gambar di output. Sebagai contoh, kita perlu mencari tahu apakah normals sudah benar untuk model. Kita dapat mengirim mereka (diubah atau tidak) dari vertex ke shader fragmen, di mana kita memperoleh sesuatu yang normals seperti ini:
(note lane: mengapa tidak ada penyorotan sintaks untuk GLSL?)

 #version 330 core out vec4 FragColor; in vec3 Normal; [...] void main() { [...] FragColor.rgb = Normal; FragColor.a = 1.0f; } 

Dengan mengeluarkan variabel non-warna ke saluran keluaran dengan warna seperti sekarang, kita dapat dengan cepat memeriksa nilai variabel. Jika, misalnya, hasilnya adalah layar hitam, maka jelas bahwa normals salah ditransfer ke shader, dan ketika mereka ditampilkan, relatif mudah untuk memeriksa kebenarannya:

Dari hasil visual, kita dapat melihat bahwa normalnya benar, karena sisi kanan jas didominasi merah (yang berarti bahwa normalnya secara kasar menunjukkan ke arah sumbu pembilasan x) dan juga sisi depan setelan diwarnai ke arah sumbu z positif (biru).

Pendekatan ini dapat diperluas ke variabel apa pun yang ingin Anda uji. Setiap kali Anda macet dan menganggap bahwa kesalahan ada di shader, cobalah untuk menggambar beberapa variabel atau hasil antara dan cari tahu di bagian mana dari algoritma ada kesalahan.

Kompiler referensi OpenGL GLSL

Setiap driver video memiliki kebiasaan sendiri. Sebagai contoh, driver NVIDIA sedikit melunakkan persyaratan spesifikasi, dan driver AMD lebih baik memenuhi spesifikasi (yang lebih baik, menurut saya). Masalahnya adalah shader yang beroperasi pada satu mesin mungkin tidak menghasilkan uang pada mesin lain karena perbedaan driver.

Untuk beberapa tahun pengalaman, Anda dapat mempelajari semua perbedaan antara GPU yang berbeda, tetapi jika Anda ingin memastikan bahwa shader Anda akan bekerja di mana-mana, maka Anda dapat memverifikasi kode Anda dengan spesifikasi resmi menggunakan kompiler referensi GLSL . Anda dapat mengunduh apa yang disebut validator lang GLSL di sini ( sumber ).

Dengan program ini, Anda dapat menguji shader Anda dengan mengirimkannya sebagai argumen pertama ke program tersebut. Ingat bahwa program menentukan jenis shader berdasarkan ekstensi:

• .vert : vertex shader
• .frag : fragmen shader
• .geom : geometris shader
• .tesc : tessellation yang mengendalikan shader
• .tese : shader komputasi tessellation
• .comp : hitung shader

Menjalankan program itu mudah:

 glslangValidator shader.vert 

Perhatikan bahwa jika tidak ada kesalahan, program tidak akan menghasilkan apa pun. Pada vertex shader yang rusak, output akan terlihat seperti:

Program tidak akan menunjukkan perbedaan antara kompiler GLSL dari AMD, NVidia atau Intel, dan bahkan tidak dapat melaporkan semua bug di shader, tetapi setidaknya memeriksa shader untuk kepatuhan dengan standar.

Output buffer bingkai

Metode lain untuk toolkit Anda adalah menampilkan konten buffer bingkai di bagian tertentu layar. Kemungkinan besar, Anda sering menggunakan framebuffer, dan karena semua keajaiban terjadi di belakang layar, mungkin sulit untuk menentukan apa yang terjadi. Output dari isi frame buffer adalah trik yang berguna untuk memverifikasi hal-hal yang benar.

Perhatikan bahwa isi buffer bingkai, seperti yang dijelaskan di sini, bekerja dengan tekstur, bukan dengan objek di buffer gambar

Menggunakan shader sederhana yang menggambar tekstur tunggal, kita dapat menulis fungsi kecil yang dengan cepat menggambar tekstur apa pun di sudut kanan atas layar:

 // vertex shader #version 330 core layout (location = 0) in vec2 position; layout (location = 1) in vec2 texCoords; out vec2 TexCoords; void main() { gl_Position = vec4(position, 0.0f, 1.0f); TexCoords = texCoords; } 

 //fragment shader #version 330 core out vec4 FragColor; in vec2 TexCoords; uniform sampler2D fboAttachment; void main() { FragColor = texture(fboAttachment, TexCoords); } 

 //main.cpp void DisplayFramebufferTexture(GLuint textureID) { if(!notInitialized) { // initialize shader and vao w/ NDC vertex coordinates at top-right of the screen [...] } glActiveTexture(GL_TEXTURE0); glUseProgram(shaderDisplayFBOOutput); glBindTexture(GL_TEXTURE_2D, textureID); glBindVertexArray(vaoDebugTexturedRect); glDrawArrays(GL_TRIANGLES, 0, 6); glBindVertexArray(0); glUseProgram(0); } int main() { [...] while (!glfwWindowShouldClose(window)) { [...] DisplayFramebufferTexture(fboAttachment0); glfwSwapBuffers(window); } } 

Ini akan memberi Anda jendela kecil di sudut layar untuk men-debug output buffer bingkai. Ini berguna, misalnya, ketika Anda mencoba memeriksa kebenaran normals:

Anda juga dapat memperluas fungsi ini sehingga menghasilkan lebih dari 1 tekstur. Ini adalah cara cepat untuk mendapatkan umpan balik terus menerus dari apa pun di bingkai penyangga.

Program Debugger Eksternal

Ketika semuanya gagal, ada satu trik lagi: menggunakan program pihak ketiga. Mereka dibangun ke dalam driver OpenGL dan dapat mencegat semua panggilan OpenGL untuk memberi Anda banyak data menarik tentang aplikasi Anda. Aplikasi ini dapat membuat profil penggunaan fungsi OpenGL, mencari kemacetan, dan memonitor buffer bingkai, tekstur, dan memori. Saat mengerjakan kode (besar), alat-alat ini bisa menjadi sangat berharga.

Saya telah membuat daftar beberapa alat populer. Cobalah masing-masing dan pilih yang paling cocok untuk Anda.

Renderderoc

RenderDoc adalah alat debugging terpisah ( terbuka penuh) yang bagus. Untuk memulai penangkapan, pilih file yang dapat dieksekusi dan direktori kerja. Aplikasi Anda berfungsi seperti biasa, dan ketika Anda ingin menonton satu frame, Anda mengizinkan RenderDoc untuk menangkap beberapa frame aplikasi Anda. Di antara frame yang diambil, Anda dapat melihat status pipa, semua perintah OpenGL, penyimpanan buffer, dan tekstur yang digunakan.

Codexl

CodeXL - Alat debugging GPU, berfungsi sebagai aplikasi mandiri dan plugin untuk Visual Studio. CodeXL Menyediakan banyak informasi dan bagus untuk membuat profil aplikasi grafis. CodeXL juga berjalan pada kartu grafis dari NVidia dan Intel, tetapi tanpa dukungan debug OpenCL.

Saya tidak banyak menggunakan CodeXL, karena RenderDoc tampak lebih sederhana bagi saya, tetapi saya memasukkan CodeXL dalam daftar ini karena terlihat seperti alat yang cukup andal dan terutama dikembangkan oleh salah satu produsen utama GPU.

NVIDIA Nsight

Nsight adalah alat debugging GPU NUIDIA yang populer. Ini bukan hanya plug-in untuk Visual Studio dan Eclipse, tetapi juga aplikasi terpisah . Plugin Nsight adalah hal yang sangat berguna bagi pengembang grafis karena ia mengumpulkan banyak statistik waktu nyata mengenai penggunaan GPU dan keadaan frame-by-frame GPU.

Saat Anda meluncurkan aplikasi Anda melalui Visual Studio atau Eclipse menggunakan perintah debug atau profil Nsight, itu akan mulai di dalam aplikasi itu sendiri. Suatu hal yang baik di Nsight: merender sistem GUI (GUI, antarmuka pengguna grafis) di atas aplikasi yang sedang berjalan yang dapat Anda gunakan untuk mengumpulkan semua jenis informasi tentang aplikasi Anda secara real time atau analisis frame-by-frame.

Nsight adalah alat yang sangat berguna, yang, menurut saya, melampaui alat-alat di atas, tetapi memiliki satu kelemahan serius: Nsight hanya berfungsi pada kartu grafis NVIDIA. Jika Anda menggunakan kartu grafis NVIDIA dan menggunakan Visual Studio, maka Nsight pasti patut dicoba.

, ( , VOGL APItrace ), , . , , () ( , ).

• ? — Reto Koradi.
• — Vallentin Source.

PS : Kami punya telegram conf untuk koordinasi transfer. Jika Anda memiliki keinginan serius untuk membantu penerjemahan, silakan!