Debugger GPU AMD

 (thegeeko.me)
3 poin oleh GN⁺ 2025-12-10 | 1 komentar | Bagikan ke WhatsApp
  • Berangkat dari ketiadaan debugger yang dapat menghentikan eksekusi GPU dan memeriksa statusnya, artikel ini menjelaskan proses implementasinya secara langsung pada GPU AMD
  • Berkomunikasi langsung dengan GPU melalui antarmuka DRM dan libdrm, lalu menyusun proses pembuatan konteks, alokasi buffer, dan pengiriman perintah secara bertahap
  • Membangun struktur untuk menghentikan eksekusi GPU dengan memanfaatkan register TBA/TMA dan trap handler, lalu membaca dan memulihkan status melalui sinkronisasi dengan CPU
  • Memperluas lingkungan debugging shader nyata melalui kompilasi kode SPIR-V dan integrasi RADV, sehingga fitur breakpoint, stepping, dan watchpoint dapat diimplementasikan
  • Pendekatan yang mengendalikan langsung struktur internal GPU ini membuktikan kemungkinan implementasi debugger lengkap untuk GPU AMD, dan masih memiliki ruang untuk berkembang ke integrasi Vulkan

Kebutuhan dan pendekatan untuk debugging GPU

  • Berangkat dari ketiadaan alat untuk menghentikan sementara eksekusi GPU dan memeriksa statusnya seperti pada CPU
    • Model eksekusi paralel pada GPU membuat debugging jauh lebih kompleks
  • rocgdb di lingkungan AMD ROCm memang ada, tetapi hanya mendukung cakupan yang terbatas pada ROCm
  • Dengan merujuk pada seri blog Marcell Kiss, penulis mencoba mengimplementasikan debugger yang berkomunikasi langsung dengan GPU

Berkomunikasi langsung dengan GPU

  • Mempelajari cara berkomunikasi langsung dengan GPU dengan menelusuri cara kerja driver RADV
  • Membuka /dev/dri/cardX untuk terhubung ke KMD (kernel mode driver), lalu memanggil amdgpu_device_initialize
  • Melalui libdrm, melakukan pembuatan konteks (amdgpu_cs_ctx_create) dan alokasi buffer
    • Membuat dua buffer: buffer kode dan buffer perintah
  • Memetakan buffer ke ruang alamat virtual GPU/CPU
    • Alih-alih amdgpu_bo_va_op, pemetaan dilakukan dengan memanggil IOCTL secara langsung
    Iklan
  • Menggunakan clang dan objdump untuk mengompilasi kode assembly shader dan mengekstrak binarinya
  • Menyusun perintah GPU dalam format PM4 Packet untuk mengirim perintah eksekusi shader

Trap GPU dan pemanfaatan Debugfs

  • Menyetel trap handler menggunakan register TBA/TMA pada ISA RDNA3
    • TBA: alamat trap handler
    • TMA: alamat memori sementara untuk trap handler
  • Karena tidak bisa diakses langsung dari user space, digunakan antarmuka debugfs
    • Mengakses register melalui file /sys/kernel/debug/dri/{PCI address}/regs2
    • Penulisan register dilakukan dengan amdgpu_debugfs_regs2_write
  • Mengaktifkan trap handler dengan mengatur TBA/TMA per VMID
    • Tiap VMID membedakan konteks proses GPU
    Iklan

Implementasi trap handler

  • Trap handler adalah program shader istimewa yang dijalankan saat GPU menemui pengecualian
  • Menggunakan register TTMP untuk menyimpan status GPU (STATUS, EXEC, VCC, dll.)
  • Menyimpan nilai register tiap thread ke memori dengan instruksi global_store_addtid_b32
  • Saat GPU selesai menulis data, CPU mendeteksinya lalu menghentikan sementara GPU dengan register SQ_CMD
    • Setelah CPU menganalisis data, eksekusi GPU dilanjutkan kembali melalui SQ_CMD
  • Saat kembali, trap handler memulihkan program counter dan status register

Eksekusi kode SPIR-V dan integrasi RADV

  • Mendukung kompilasi kode SPIR-V alih-alih assembly manual
    • Menggunakan kompiler ACO milik RADV untuk mengubah SPIR-V menjadi biner GPU
    • Membuat perangkat virtual dengan variabel lingkungan RADV_FORCE_FAMILY
  • Dalam mode null_winsys RADV, hanya kompilasi yang dilakukan tanpa akses ke perangkat keras nyata
  • Mengekstrak kode shader, pengaturan resource, dan informasi debug dari hasil kompilasi
Iklan

Perluasan fitur debugger

  • Stepping: mengendalikan eksekusi per instruksi dengan bit RSRC1.DEBUG_MODE dan RSRC3.TRAP_ON_START
  • Breakpoints: menangani trap setelah menghitung posisi program counter berdasarkan alamat buffer kode
  • Source Mapping: memetakan baris kode sumber dengan informasi debug dari kompiler ACO
  • Watchpoints: fitur pemantauan alamat dapat diimplementasikan dengan proteksi halaman GPU atau register SQ_WATCH
  • Pelacakan nama dan tipe variabel: perlu peningkatan pada penyampaian informasi debug di tahap optimisasi NIR milik Mesa
  • Integrasi Vulkan: memungkinkan debugging per frame berbasis RADV serta pemanfaatan informasi buffer, tekstur, dan konstanta

Bonus: kode page walking mode pengguna

  • Menyediakan contoh kode penelusuran page table untuk GPU RDNA3 (gfx11)
    • Termasuk definisi struct PDE/PTE dan fungsi decoding
    • Mengimplementasikan proses konversi dari alamat virtual ke alamat fisik
  • Dengan membaca register page table per VMID, dimungkinkan untuk menganalisis struktur pemetaan memori GPU

Kesimpulan

  • Membuktikan kemungkinan implementasi debugger lengkap melalui akses tingkat kernel dan perangkat keras pada GPU AMD
  • Mewujudkan penghentian eksekusi, analisis status, dan pelanjutan kembali dengan membangun loop komunikasi dua arah antara CPU dan GPU
  • Ke depan, ada peluang berkembang menjadi lingkungan debugging GPU yang ramah pengembang melalui integrasi RADV dan Vulkan

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-10
Komentar Hacker News

  • Bukan AMD, tetapi Metal menyediakan debugger dan rangkaian alat pengembangan yang benar-benar luar biasa
    Karena itu saya selalu memilih memakai Metal terlebih dahulu saat mengerjakan GPU, lalu mem-porting-nya ke sistem lain setelahnya
    Ada baiknya melihat dokumentasi Metal Debugger
    Saya bukan pengembang game AAA, tetapi untuk kebutuhan saya ini nyaris sempurna
    Yang paling mengejutkan adalah fitur untuk mencetak string log terformat dari shader, lalu menampilkannya tercampur bersama log aplikasi
    Saya sedang mengembangkan aplikasi berbasis GPU yang menggunakan Metal dan OpenGL sekaligus, dan di sisi OpenGL sulit menemukan alat setara Metal

    • Saya pertama kali mengenal shader saat mem-porting kode grafis OpenGL ke PS5 dan Xbox
      Kedua platform menyediakan debugger khusus, dan kualitasnya cukup bagus
      Pada akhirnya saya sadar bahwa saat yang terlihat hanya layar hitam, tool-lah segalanya
      Saya penasaran apakah memakai DirectX alih-alih OpenGL akan memberi tooling yang lebih baik di Windows
    • Debugger Metal memang dibuat dengan sangat baik, tetapi sering freeze atau membuat Xcode crash
      Terutama saat menangani compute shader, profiling sering kali tidak berjalan dengan baik
      Karena alat ini dirancang dengan fokus grafis, tampaknya masih ada batasan untuk AI atau pekerjaan dengan buffer berukuran besar
    • Debugger Metal di Xcode sangat bagus, dan API Metal sendiri juga intuitif
      Jauh lebih cocok daripada OpenGL
      Di sisi OpenGL, pernah mencoba RenderDoc? Untuk Vulkan/OpenGL, itu alat yang paling mirip
    • Sulit setuju dengan pendapat bahwa orang harus membeli Mac untuk belajar GPU
      Membeli komputer mahal untuk men-debug API khusus Metal itu tidak efisien
      Kalau ingin serius belajar pemrograman grafis, menurut saya lebih baik belajar DX12 atau Vulkan di Windows atau Linux
      Dengan alat seperti RenderDoc, itu sangat memungkinkan
      Metal adalah API yang bagus, tetapi keterbatasan terbesarnya adalah tidak bisa dipakai di luar platform Apple
    • Metal memang keren, tetapi menurut saya masalahnya adalah vendor lock-in
      Di lingkungan server atau game, kebanyakan memakai GPU AMD atau Nvidia, jadi pengembangan yang berpusat pada Metal tidak praktis

  • CUDA dari NVIDIA punya GDB first-party bernama cuda-gdb
    Seperti yang bisa dilihat di dokumentasi resmi, alat ini cocok dengan model thread CUDA
    Namun single-step execution hanya bisa dilakukan per warp

  • Di kartu NVIDIA bisa memakai NSight, dan ada juga RenderDoc yang berjalan di berbagai GPU

    • RenderDoc lebih dekat ke debugger tingkat tinggi, dan juga berguna untuk analisis performa
      Saat visualisasi tingkat tinggi seperti QML atau QSG_VISUALIZE=overdraw tidak memadai, menarik untuk melacak scene sampai ke tingkat pemanggilan API
    • nsys dan nvtx juga alat yang sangat bagus
      Banyak orang tidak tahu bahwa keduanya bisa dipakai bahkan tanpa GPU

  • Menjawab pertanyaan apakah ada alat resmi untuk AMD, GDB mendukung debugging AMD GPU
    Ada juga alat seperti UMR dari AMD,
    Radeon GPU Detective,
    dan Radeon Developer Tool Suite

    • Jika melihat posting blog tersebut, disebutkan debugger untuk AMD ROCm bernama rocgdb

  • Saya membagikan alat pemantauan yang saya buat sendiri untuk AMD GPU
    Proyeknya bernama picomon, dibuat untuk mengatasi masalah nvtop yang terlalu ketat sehingga sering crash

  • Ada alat khusus untuk tiap platform seperti Metal, CUDA, Pix, dan PS/Switch
    Karena alasan ini, para peneliti masih cenderung lebih menyukai CUDA
    Nsight Systems adalah salah satunya

  • Saya penasaran apakah ada yang memakai GPU 7900 XTX untuk inferensi lokal atau diffusion
    Saya sudah memasang Linux, tetapi sebagian besar waktu GPU ini menganggur, jadi saya ingin memanfaatkannya

    • Saya sudah memakainya di Gentoo selama beberapa tahun
      Dulu sempat ada masalah terkait Python, tetapi belakangan sudah stabil dan bahkan img2video juga bisa
      Dengan VRAM 24GB, menurut saya ini masih kartu dengan value terbaik untuk harganya
      ROCm baru-baru ini dirombak besar-besaran untuk peningkatan UX, jadi saya sarankan melihat TheRock
    • Di Windows saya pernah mencoba self-hosting LLM secara lokal lewat ollama dengan 7900XT, dan hasilnya berjalan baik
      Model devstral:24b juga berjalan cukup cepat
    • Saat membelinya di awal perilisan, sempat ada kernel OOM error terkait ROCm
      Di ComfyUI sebagian besar berjalan baik, tetapi untuk pekerjaan yang tidak biasa sistemnya kurang stabil
      Saya dengar belakangan ini sudah lebih stabil
    • Saya juga pernah melakukan pekerjaan serupa dengan 6800XT; memang sedikit merepotkan karena ekosistemnya berpusat pada CUDA, tetapi tetap bisa dilakukan
    • Saya menguji model generasi gambar dan teks, lalu setelah mengganti library torch bawaan dengan versi ROCm dari AMD, semuanya berjalan tanpa masalah