VUDA: การอิมพลีเมนต์ CUDA บน Vulkan

 (github.com/jgbit)
1 คะแนน โดย GN⁺ 2023-07-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • VUDA เป็นไลบรารีแบบ header-only ที่ทำงานบน Vulkan โดยให้ส่วนติดต่อของ CUDA Runtime API สำหรับการเขียนแอปพลิเคชันที่เร่งความเร็วด้วย GPU
  • ฟังก์ชันการทำงานยึดตามสเปกของ CUDA runtime เท่าที่เป็นไปได้ และสำหรับการใช้งานทั่วไปสามารถอ้างอิงเอกสารของ NVIDIA CUDA Runtime API ได้
  • ฟีเจอร์ทั้งหมดเข้าถึงได้ด้วยการ include vuda.hpp และใช้งานผ่านเนมสเปซ vuda:: โดย vuda_runtime.hpp จะทำหน้าที่แรปและรีไดเร็กต์ฟังก์ชันของ CUDA
  • เวิร์กโฟลว์ตัวอย่างใช้การเรียก CUDA Runtime API เช่น cudaSetDevice, cudaMalloc, cudaMemcpy, cudaFree และเมื่อไม่ใช้ NVCC จะรัน Vulkan shader module ด้วย vuda::launchKernel("add.spv", "main", ...)
  • หัวข้อในเอกสารประกอบด้วย Change List, Setup and Compilation, Deviations from CUDA, Implementation Details

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

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

 
GN⁺ 2023-07-03
ความคิดเห็นบน Hacker News

  • มันไม่ใช่การอิมพลีเมนต์ CUDA แต่เป็นการอิมพลีเมนต์ CUDA Runtime API
    API นี้ใช้สำหรับตั้งค่าการ์ด จัดสรร·คัดลอกหน่วยความจำ และรันเคอร์เนล
    ประเด็นสำคัญคือ มันยังใช้เขียนโค้ดเคอร์เนลที่รันจริงบน GPU ไม่ได้

    • ตอนแรกแอบหวังอยู่นิดหน่อยว่านี่อาจหมายถึงสามารถรันโค้ด CUDA บน AMD GPU ได้ แต่พออ่านคำอธิบายแล้วไม่ใช่แบบนั้น
    • ถ้าอย่างนั้นก็สงสัยว่ามันมีประโยชน์ในด้านไหน
    • ถ้าจะอ้างตัวว่าเป็นตัวแทน CUDA ก็ต้องมี การรองรับ PTX และรองรับการพัฒนาด้วยหลายภาษา
      ไม่อย่างนั้นเวิร์กโหลดจำนวนมากก็เริ่มต้นไม่ได้ตั้งแต่แรก
    1. นี่คือการอิมพลีเมนต์ API สไตล์ C แบบดิบ ๆ
      ยังมีตัวห่อ Modern C++ API ที่ให้ความสามารถอย่างการตรวจสอบข้อผิดพลาดอัตโนมัติและการจัดการรีซอร์สแบบ RAII ด้วย: https://github.com/eyalroz/cuda-api-wrappers
      อนึ่ง ผมเป็นคนเขียนเอง
    2. การอิมพลีเมนต์ Runtime API ไม่ใช่ทางเลือกที่เหมาะนัก
      ถ้าต้องการทำเรื่องอย่างการแยกคอนเท็กซ์ หรือการเพิ่ม JIT kernel ที่คอมไพล์ใหม่เข้าเป็นโมดูลแบบไดนามิก การอิมพลีเมนต์ Driver API สำคัญกว่า
    3. โปรเจ็กต์นี้มีไม่ถึง 3000 บรรทัด
      แต่การห่อ CUDA API หลักทั้งหมด ทั้งไดรเวอร์·รันไทม์·NVTX·CUDA-C++ และ PTX JIT compilation ใช้ไปมากกว่า 14,000 บรรทัด

  • สงสัยว่าสิ่งนี้เกี่ยวข้องอย่างไรกับเป้าหมายที่ George Hotz พูดถึง เรื่องการทำให้แมชชีนเลิร์นนิงทำงานได้บนชิป AMD และ ทำลายอำนาจครอบงำของ Nvidia
    ผมไม่ใช่ผู้เชี่ยวชาญ แต่แนวทางนี้ดูทรงพลังและสำคัญ
    เพียงแต่ระบบมันซับซ้อนมากจนสงสัยว่าคนคนเดียวจะทำได้ไหม และดูเหมือนว่าการเริ่มต้นน่าจะต้องมีการสนับสนุนจากบริษัท
    คิดว่า AMD เองอาจสนใจออกค่าแรงวิศวกรเพื่อช่วยปรับปรุงแบบวนซ้ำด้วยก็ได้

    • Hotz พูดถึงไม่ใช่แค่ไลบรารีใน user space แต่รวมถึง ไดรเวอร์ ด้วย

      The software is terrible! There’s kernel panics in the driver. You have to run a newer kernel than the Ubuntu default to make it remotely stable. I’m still not sure if the driver supports putting two cards in one machine, or if there’s some poorly written global state. When I put the second card in and run an OpenCL program, half the time it kernel panics and you have to reboot.
      เขาพูดถึงฝั่ง user space ด้วย แต่ชัดเจนว่าเขามองว่ามีหลายจุดให้แก้ทั้ง สแตกทั้งหมด ทั้งเหนือและใต้ไลบรารีลักษณะนี้

    • เจอ https://www.youtube.com/watch?v=Mr0rWJhv9jU และ https://geohot.github.io/blog/jekyll/update/2023/06/07/a-div... แล้ว
      ตอนนี้รู้สึกสบายใจขึ้นนิดหน่อยกับประสบการณ์ที่เจอตอนใช้ AMD
      มันดูเหมือนไดรเวอร์ GPU มีปัญหาใหญ่จริง ๆ และได้รู้ว่าไม่ได้เป็นอยู่คนเดียว

  • ถ้าใครใช้ AMD GPU บน Windows แล้วอยากฝึกหรือรันโมเดลแมชชีนเลิร์นนิง ก็น่าลองดู torch-directml และ tensorflow-directml

    • ไม่แน่ใจว่า DirectML สมเหตุสมผลกว่าไหมเมื่อเทียบกับที่ AMD พยายามไล่ตามความเข้ากันได้กับ CUDA ผ่าน ROCm/MiOpen/HIP
      CUDA กับ DirectX ดูเป็นสิ่งที่ low-level เกินไปสำหรับจะเป็น API กลางที่เข้ากันได้ข้ามฮาร์ดแวร์ที่ต่างกันมากอย่าง AMD และ Nvidia โดยไม่เสียประสิทธิภาพไปมาก
      cuDNN อยู่ในระดับที่สูงกว่า จึงน่าจะมีช่องให้ทำเคอร์เนลแยกตามฮาร์ดแวร์ของ AMD และ Nvidia พร้อมยังคงความเข้ากันได้โดยไม่เสียประสิทธิภาพ
      แต่สิ่งที่เฟรมเวิร์กอย่าง PyTorch ทำจำนวนมากไม่ได้อาศัยแค่ cuDNN เท่านั้น แต่ยังอิงกับ custom kernel ด้วย
      สำหรับ AMD ทางเลือกที่ดีที่สุดน่าจะเป็น low-level API ที่แข็งแรงเชื่อถือได้ และการรองรับคอมไพเลอร์แมชชีนเลิร์นนิงระดับสูงที่ทำให้ผู้พัฒนาเฟรมเวิร์กอย่าง PyTorch·TensorFlow·JAX สร้างการรองรับบนมันได้ง่าย
      สุดท้ายคนที่ได้ประโยชน์ก็คือผู้พัฒนาเฟรมเวิร์กเหล่านี้ ดังนั้น AMD ต้องร่วมมือกับพวกเขาอย่างใกล้ชิดมาก
      แปลกที่ AMD ดูเหมือนจะวางเรื่องการรองรับแมชชีนเลิร์นนิงไว้เป็นเรื่องรองมาหลายปี
      อาจเพราะมองว่าตลาดแมชชีนเลิร์นนิงฝั่งผู้บริโภคเล็กกว่าเมื่อเทียบกับตลาดกราฟิก·เกม จึงไม่คุ้มจะลงแรง แต่ Nvidia แสดงให้เห็นแล้วว่านี่คือทางไปสู่ดีลศูนย์ข้อมูลที่ทำกำไรได้มากกว่ามาก
    • สงสัยว่าของจริงมันทำงานอย่างไร
      ครั้งล่าสุดที่ผมลองใช้ DirectML การรองรับยังไม่ดีนัก และซอฟต์แวร์ที่รองรับก็น้อย
      ประสิทธิภาพก็ดูไม่ค่อยดีด้วย
      ตอนนี้ผมใช้ Linux ติดตั้งตรง ซึ่งด้วย ROCm ทำให้ใช้เครื่องมือยอดนิยมอย่าง Automatic111 webui และ oobabooga ได้
    • มันใช้งานได้จริงเหรอ?
      ถ้า AMD ออก GPU ราคาสมเหตุสมผลที่ชนะ Nvidia ในงานแมชชีนเลิร์นนิงได้ ผมก็อาจซื้อ GPU ใหม่
      Nvidia GPU ที่พอใช้ได้ราคาสูงเกินไปจนยากจะหาเหตุผลมาซื้อ

  • ดูเหมือนเป็นโปรเจ็กต์ที่ตายแล้ว
    คอมมิตล่าสุดคือ กุมภาพันธ์ 2022

    • แถมคอมมิตนั้นก็แค่เพิ่มมาหนึ่งบรรทัด
      โค้ดส่วนใหญ่มีอายุ 3 ถึง 5 ปีแล้ว

  • ผมไม่เคยเขียนโปรแกรม GPU โดยตรง เลยอยากถามว่านี่เทียบกับ HIP แล้วเป็นอย่างไร?
    มันจะเป็นชั้น abstraction ที่มีประสิทธิภาพบนทั้ง Nvidia และ AMD GPU ได้ไหม?

    • ตาม https://news.ycombinator.com/item?id=34399633 ระบุว่า hipify-clang เป็นเครื่องมือบนพื้นฐาน clang ที่แปลซอร์ส CUDA ไปเป็นซอร์ส HIP
      มันแปลงซอร์ส CUDA ไปเป็น abstract syntax tree แล้วตัวแปลงจะเดินผ่านมันก่อนส่งออกเป็นซอร์ส HIP
      และนี่คือรายการ CUDA API ที่ hipify-clang รองรับ: https://rocm.docs.amd.com/projects/HIPIFY/en/latest/supporte...

  • ไม่ได้คาดหวังอะไรจาก AMD
    เครื่องมือด้านความเข้ากันได้แบบนี้ควรมีมาตั้งนานแล้ว

  • โปรเจ็กต์แนวนี้ออกมาค่อนข้างบ่อย แต่ไม่เคยสร้างแรงส่งได้ และผมก็ยังใช้ Nvidia GPU อยู่
    อันนี้ก็คงไม่ต่างกันมาก

  • ค่อนข้างน่าสนใจ
    ถ้าอย่างนั้นหมายความว่าโปรแกรมที่เร่งความเร็วด้วย CUDA ของผมควรจะไปรันบนอุปกรณ์ AMD และ Intel ได้ด้วยใช่ไหม?