ดีบักเกอร์สำหรับ AMD GPU

 (thegeeko.me)
3 คะแนน โดย GN⁺ 2025-12-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อธิบายกระบวนการสร้าง ดีบักเกอร์ที่สามารถหยุดการทำงานของ GPU และตรวจสอบสถานะได้ บน AMD GPU โดยเริ่มจากการที่ยังไม่มีเครื่องมือประเภทนี้
  • สื่อสารกับ GPU โดยตรงผ่าน อินเทอร์เฟซ DRM และ libdrm พร้อมจัดลำดับขั้นตอนการสร้างคอนเท็กซ์ การจัดสรรบัฟเฟอร์ และการส่งคำสั่ง
  • ใช้ รีจิสเตอร์ TBA/TMA และ trap handler เพื่อหยุดการทำงานของ GPU และสร้างโครงสร้างสำหรับอ่านและกู้คืนสถานะผ่านการซิงโครไนซ์กับ CPU
  • ขยายสภาพแวดล้อมการดีบักเชดเดอร์จริงผ่าน การคอมไพล์โค้ด SPIR-V และการผสานรวมกับ RADV ทำให้สามารถรองรับฟีเจอร์ breakpoint·stepping·watchpoint ได้
  • แนวทางนี้ที่ควบคุมโครงสร้างภายในของ GPU ได้โดยตรง พิสูจน์ถึง ความเป็นไปได้ในการสร้างดีบักเกอร์แบบสมบูรณ์สำหรับ AMD GPU และยังมีโอกาสพัฒนาต่อไปสู่การผสานรวมกับ Vulkan

ความจำเป็นและแนวทางของการดีบัก GPU

  • เริ่มต้นจากการที่ ยังไม่มีเครื่องมือที่สามารถหยุดการทำงานของ GPU ชั่วคราวและตรวจสอบสถานะได้ เหมือนกับ CPU
    • โมเดลการประมวลผลแบบขนาน ของ GPU ทำให้การดีบักซับซ้อนกว่ามาก
  • แม้จะมี rocgdb ในสภาพแวดล้อม AMD ROCm แต่รองรับเพียง ขอบเขตที่จำกัดอยู่ใน ROCm
  • อ้างอิงบล็อกซีรีส์ของ Marcell Kiss แล้วทดลอง สร้างดีบักเกอร์ที่สื่อสารกับ GPU โดยตรง

การสื่อสารกับ GPU โดยตรง

  • เรียนรู้วิธีสื่อสารกับ GPU โดยตรงด้วยการติดตามการทำงานของ ไดรเวอร์ RADV
  • เปิด /dev/dri/cardX เพื่อเชื่อมต่อกับ KMD (kernel mode driver) แล้วเรียก amdgpu_device_initialize
  • ใช้ libdrm สำหรับ การสร้างคอนเท็กซ์ (amdgpu_cs_ctx_create) และ การจัดสรรบัฟเฟอร์
    • สร้างบัฟเฟอร์สองชุดคือ code buffer และ command buffer
  • แมปบัฟเฟอร์เข้ากับ พื้นที่แอดเดรสเสมือนของ GPU/CPU
    • แทนที่จะใช้ amdgpu_bo_va_op ได้จัดการการแมปด้วยการเรียก IOCTL โดยตรง
  • ใช้ clang และ objdump เพื่อ คอมไพล์โค้ดแอสเซมบลีของเชดเดอร์และดึงไบนารีออกมา
  • จัดรูปคำสั่ง GPU ในรูปแบบ PM4 Packet เพื่อ ส่งคำสั่งรันเชดเดอร์

GPU trap และการใช้ Debugfs

  • ตั้งค่า trap handler โดยใช้ รีจิสเตอร์ TBA/TMA ของ RDNA3 ISA
    • TBA: แอดเดรสของ trap handler
    • TMA: แอดเดรสหน่วยความจำชั่วคราวสำหรับ trap handler
  • เนื่องจากไม่สามารถเข้าถึงจาก user space ได้โดยตรง จึงใช้ อินเทอร์เฟซ debugfs
    • เข้าถึงรีจิสเตอร์ผ่านไฟล์ /sys/kernel/debug/dri/{PCI address}/regs2
    • เขียนค่ารีจิสเตอร์ด้วย amdgpu_debugfs_regs2_write
  • ตั้งค่า TBA/TMA แยกตาม VMID เพื่อ เปิดใช้งาน trap handler
    • แต่ละ VMID ใช้แยกคอนเท็กซ์ของโปรเซสบน GPU

การพัฒนา trap handler

  • trap handler คือ โปรแกรมเชดเดอร์สิทธิพิเศษที่ทำงานเมื่อ GPU พบข้อยกเว้น
  • ใช้รีจิสเตอร์ TTMP เพื่อเก็บ สถานะของ GPU (STATUS, EXEC, VCC ฯลฯ)
  • ใช้คำสั่ง global_store_addtid_b32 เพื่อ บันทึกค่ารีจิสเตอร์ของแต่ละเธรดลงหน่วยความจำ
  • เมื่อ GPU เขียนข้อมูลแล้ว CPU จะตรวจจับและใช้รีจิสเตอร์ SQ_CMD เพื่อ หยุด GPU ชั่วคราว
    • หลังจากนั้น CPU จะวิเคราะห์ข้อมูล แล้วใช้ SQ_CMD อีกครั้งเพื่อ ให้ GPU ทำงานต่อ
  • เมื่อ trap handler ส่งคืนการทำงาน จะมีการ กู้คืน program counter และสถานะรีจิสเตอร์

การรันโค้ด SPIR-V และการผสานรวมกับ RADV

  • รองรับ การคอมไพล์โค้ด SPIR-V แทนการเขียนแอสเซมบลีด้วยมือ
    • ใช้คอมไพเลอร์ ACO ของ RADV เพื่อแปลง SPIR-V เป็นไบนารีของ GPU
    • ใช้ตัวแปรแวดล้อม RADV_FORCE_FAMILY เพื่อสร้างอุปกรณ์เสมือน
  • ใช้โหมด null_winsys ของ RADV เพื่อ คอมไพล์อย่างเดียวโดยไม่เข้าถึงฮาร์ดแวร์จริง
  • ดึง โค้ดเชดเดอร์ การตั้งค่ารีซอร์ส และข้อมูลดีบัก จากผลลัพธ์การคอมไพล์

การขยายความสามารถของดีบักเกอร์

  • Stepping: ใช้บิต RSRC1.DEBUG_MODE, RSRC3.TRAP_ON_START เพื่อ ควบคุมการรันทีละคำสั่ง
  • Breakpoints: จัดการ trap โดย คำนวณตำแหน่ง program counter จากแอดเดรสของ code buffer
  • Source Mapping: แมปบรรทัดซอร์สโค้ดด้วย ข้อมูลดีบัก จากคอมไพเลอร์ ACO
  • Watchpoints: สามารถสร้าง ฟังก์ชันเฝ้าดูแอดเดรส ได้ผ่านการป้องกันหน้าหน่วยความจำของ GPU หรือรีจิสเตอร์ SQ_WATCH
  • การติดตามชื่อตัวแปร·ชนิดข้อมูล: ยังต้อง ปรับปรุงการส่งต่อข้อมูลดีบัก ในขั้นตอนเพิ่มประสิทธิภาพ NIR ของ Mesa
  • การผสานรวมกับ Vulkan: บนพื้นฐานของ RADV สามารถต่อยอดไปสู่การดีบักระดับเฟรม และใช้ข้อมูลบัฟเฟอร์·เท็กซ์เจอร์·ค่าคงที่ได้

โบนัส: โค้ด page walking ใน user mode

  • มีตัวอย่าง โค้ดสำรวจ page table สำหรับ GPU RDNA3(gfx11)
    • รวมถึงนิยามโครงสร้าง PDE/PTE และฟังก์ชันถอดรหัส
    • มีการพัฒนากระบวนการแปลงจาก virtual address ไปเป็น physical address
  • สามารถอ่านรีจิสเตอร์ page table แยกตาม VMID เพื่อ วิเคราะห์โครงสร้างการแมปหน่วยความจำของ GPU ได้

บทสรุป

  • พิสูจน์ ความเป็นไปได้ของการสร้างดีบักเกอร์แบบสมบูรณ์ สำหรับ AMD GPU ผ่านการเข้าถึงระดับเคอร์เนลและฮาร์ดแวร์
  • สร้าง ลูปการสื่อสารสองทางระหว่าง CPU และ GPU เพื่อให้สามารถหยุดการทำงาน วิเคราะห์สถานะ และรันต่อได้
  • ในอนาคตมีโอกาสพัฒนาไปสู่ สภาพแวดล้อมการดีบัก GPU ที่เป็นมิตรกับนักพัฒนา ผ่านการผสานรวมกับ RADV และ Vulkan

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-10
ความคิดเห็นบน Hacker News

  • แม้จะไม่ใช่ AMD แต่ Metal มีดีบักเกอร์และชุดเครื่องมือพัฒนาที่ยอดเยี่ยมจริง ๆ
    เพราะแบบนั้นเวลาทำงานด้าน GPU ฉันจึงมักใช้ Metal ก่อนเสมอ แล้วค่อยพอร์ตไปยังระบบอื่นภายหลัง
    ลองดู เอกสาร Metal Debugger ได้
    แม้จะไม่ใช่นักพัฒนาเกมระดับ AAA แต่สำหรับงานของฉันมันเกือบสมบูรณ์แบบ
    โดยเฉพาะฟีเจอร์ที่สามารถพิมพ์สตริงล็อกแบบฟอร์แมตจาก shader แล้วแสดงปะปนกับแอปล็อกได้ ถือว่าน่าทึ่งมาก
    ฉันกำลังพัฒนาแอปที่ใช้ GPU โดยใช้ทั้ง Metal และ OpenGL แต่ฝั่ง OpenGL หายากมากที่จะเจอเครื่องมือระดับเดียวกับ Metal

    • ฉันได้เจอ shader ครั้งแรกตอนพอร์ตโค้ดกราฟิก OpenGL ไปยัง PS5 และ Xbox
      ทั้งสองแพลตฟอร์มมี ดีบักเกอร์เฉพาะทาง ให้ และคุณภาพก็ค่อนข้างดี
      สุดท้ายก็ได้รู้ว่าเวลาที่เห็นแค่หน้าจอดำ เครื่องมือคือทุกอย่าง
      เลยสงสัยว่าถ้าใช้ DirectX แทน OpenGL จะได้เครื่องมือที่ดีกว่าบน Windows หรือไม่
    • Metal debugger ทำมาดีมาก แต่ก็มักจะ ค้าง หรือทำให้ Xcode ปิดตัวแบบบังคับอยู่บ่อย ๆ
      โดยเฉพาะตอนจัดการกับ compute shader การ profiling มักใช้ไม่ได้ดีนัก
      มันเป็นเครื่องมือที่ออกแบบมาโดยเน้นกราฟิก ดังนั้นสำหรับงาน AI หรือบัฟเฟอร์ขนาดใหญ่ก็ดูเหมือนจะยังมีข้อจำกัด
    • Metal debugger ของ Xcode ยอดเยี่ยมมาก และตัว Metal API เองก็เข้าใจง่าย
      มันเข้ามือกว่าการใช้ OpenGL มาก
      ฝั่ง OpenGL เคยลอง RenderDoc หรือยัง? สำหรับ Vulkan/OpenGL มันคือเครื่องมือที่ใกล้เคียงที่สุด
    • เห็นด้วยได้ยากกับความเห็นที่ว่าควรซื้อ Mac มาเพื่อเรียนรู้ GPU
      การซื้อคอมราคาแพงมาเพื่อดีบัก API ที่ใช้ได้เฉพาะกับ Metal เป็นเรื่องไม่มีประสิทธิภาพ
      ถ้าอยากเรียนกราฟิกโปรแกรมมิงอย่างจริงจัง ฉันคิดว่าควรไปเรียน DX12 หรือ Vulkan บน Windows หรือ Linux จะดีกว่า
      ใช้เครื่องมืออย่าง RenderDoc ก็เพียงพอแล้ว
      Metal เป็น API ที่ดี แต่ข้อจำกัดใหญ่ที่สุดคือใช้นอกแพลตฟอร์ม Apple ไม่ได้
    • Metal นั้นเจ๋งก็จริง แต่ฉันคิดว่าปัญหาคือ vendor lock-in
      ในสภาพแวดล้อมเซิร์ฟเวอร์หรือเกม ส่วนใหญ่ใช้ GPU ของ AMD หรือ Nvidia ดังนั้นการพัฒนาโดยยึด Metal เป็นศูนย์กลางจึงไม่ค่อยใช้งานได้จริง

  • CUDA ของ NVIDIA มี GDB ที่เป็น 1st-party ชื่อ cuda-gdb
    อย่างที่เห็นใน เอกสารทางการ มันเข้ากันได้ดีกับโมเดลเธรดของ CUDA
    แต่สามารถสั่ง single-step ได้แค่ในระดับ warp เท่านั้น

  • บนการ์ด NVIDIA สามารถใช้ NSight ได้ และยังมี RenderDoc ที่ทำงานได้กับ GPU หลากหลายรุ่นด้วย

    • RenderDoc ใกล้เคียงกับดีบักเกอร์ระดับสูง และยังมีประโยชน์กับ การวิเคราะห์ประสิทธิภาพ ด้วย
      เวลาขาดภาพแสดงผลระดับสูงอย่าง QML หรือ QSG_VISUALIZE=overdraw การตามดูฉากในระดับ API call ก็น่าสนใจดี
    • nsys และ nvtx ก็เป็นเครื่องมือที่ยอดเยี่ยมเช่นกัน
      หลายคนไม่รู้ว่ามันใช้งานได้แม้ไม่มี GPU

  • สำหรับคำถามว่ามีเครื่องมือทางการของ AMD ไหม GDB รองรับ การดีบัก AMD GPU
    นอกจากนี้ยังมีเครื่องมืออย่าง UMR ของ AMD และ
    Radeon GPU Detective,
    Radeon Developer Tool Suite

    • ถ้าดูจากบล็อกโพสต์ จะมีการพูดถึงดีบักเกอร์สำหรับ AMD ROCm ที่ชื่อ rocgdb ด้วย

  • ขอแชร์ เครื่องมือตรวจสอบ ที่ทำขึ้นเองสำหรับ AMD GPU
    เป็นโปรเจ็กต์ชื่อ picomon ซึ่งสร้างขึ้นมาเพื่อแก้ปัญหาที่ nvtop เข้มงวดเกินไปจนแครชบ่อย

  • แต่ละแพลตฟอร์มอย่าง Metal, CUDA, Pix, PS/Switch ต่างก็มีเครื่องมือเฉพาะทางของตัวเอง
    ด้วยเหตุนี้นักวิจัยจึงยังมีแนวโน้มจะ ชอบ CUDA อยู่
    Nsight Systems ก็เป็นหนึ่งในนั้น

  • อยากรู้ว่ามีใครใช้ GPU 7900 XTX กับงาน local inference หรือ diffusion บ้างไหม
    ฉันลง Linux ไว้แล้วแต่ส่วนใหญ่ปล่อยว่างอยู่ เลยอยากเอามาใช้ประโยชน์

    • ฉันใช้มันบน Gentoo มาหลายปีแล้ว
      เมื่อก่อนเคยมีปัญหาเกี่ยวกับ Python แต่ช่วงหลังเสถียรขึ้นมากจนทำ img2video ได้แล้ว
      ถ้าวัดจาก VRAM 24GB ฉันยังคิดว่ามันเป็น การ์ดที่คุ้มค่าที่สุด
      ช่วงหลัง ROCm ถูกปรับปรุงครั้งใหญ่เพื่อ ปรับ UX ให้ดีขึ้น ดังนั้นแนะนำให้ลองดู TheRock
    • ฉันเคยโฮสต์ LLM แบบโลคัลบน Windows ผ่าน ollama ด้วย 7900XT และมันทำงานได้ดี
      โมเดล devstral:24b ก็รันได้ค่อนข้างเร็ว
    • ตอนซื้อมาใหม่ ๆ ช่วงเปิดตัว เคยมี kernel OOM error ที่เกี่ยวกับ ROCm
      ใน ComfyUI ส่วนใหญ่ใช้งานได้ดี แต่กับงานแปลก ๆ บางอย่างจะไม่เสถียร
      ล่าสุดได้ยินมาว่าตอนนี้นิ่งขึ้นแล้ว
    • ฉันเคยทำงานคล้าย ๆ กันด้วย 6800XT แม้ระบบนิเวศจะเน้น CUDA เป็นหลักเลยค่อนข้างจุกจิก แต่ก็ทำได้
    • ฉันทดสอบทั้งโมเดลสร้างภาพและสร้างข้อความ แล้วแค่เปลี่ยนไลบรารี torch ปกติเป็น ROCm เวอร์ชัน ของ AMD ทุกอย่างก็ทำงานได้ไม่มีปัญหา