พัฒนาคอมไพเลอร์ DirectX Shader ที่ดีกว่า Microsoft

 (devlog.hexops.com)
3 คะแนน โดย GN⁺ 2024-02-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สร้างคอมไพเลอร์ DirectX Shader ให้ดีกว่า Microsoft

  • เรื่องราวเกี่ยวกับความซับซ้อนของคอมไพเลอร์ DirectX Shader ของ Microsoft และความพยายามในการมอบประสบการณ์ที่ดีกว่าให้กับนักพัฒนาเกม
  • กำลังพัฒนา API กราฟิกเชิงทดลองชื่อ sysgpu ซึ่งเป็นผู้สืบทอดของ WebGPU สำหรับเอนจิน Mach โดยใช้ Zig และมีแผนรองรับแบ็กเอนด์ Metal, Vulkan, Direct3D และ OpenGL
  • จำเป็นต้องคอมไพล์โปรแกรมเชดเดอร์ที่ใช้งานได้บน Direct3D 12

ประวัติย่อของ DirectX

  • กราฟิก API ของ DirectX ใช้ HLSL เป็นภาษาเชดดิง
  • ในอดีตก่อน Direct3D 11 ใช้คอมไพเลอร์ชื่อ FXC ซึ่งขึ้นชื่อว่าช้าและสร้างโค้ดที่ปรับแต่งได้ไม่ดีนัก

FXC ไม่ได้ถูกใช้อีกต่อไป และ DXC มาพร้อมกับ Direct3D 12

  • เมื่อ Direct3D 12 และ Shader Model 6.0 (SM6) เปิดตัว Microsoft ได้เลิกใช้ FXC และเปิดตัวคอมไพเลอร์ใหม่ชื่อ DXC
  • DXC เป็นฟอร์กอย่างเป็นทางการของ LLVM/Clang v3.7 โดย Microsoft และมีการระบุการเปลี่ยนแปลงไว้อย่างชัดเจนผ่านคอมเมนต์

สิ่งที่ไดรเวอร์ DirectX กินเป็นอาหารเช้า: DXBC หรือ DXIL

  • แม้ HLSL จะเป็นภาษาหลักสำหรับการเขียนโปรแกรมบน Direct3D แต่ในความเป็นจริง GPU มีสถาปัตยกรรมการประมวลผลและข้อกำหนดที่หลากหลาย
  • Microsoft จัดเตรียมฟรอนต์เอนด์ API ที่เป็นมิตรกับนักพัฒนา และผู้ผลิตฮาร์ดแวร์อิสระจะเขียนไดรเวอร์เพื่อแปลงไปเป็นสิ่งที่ใกล้เคียงกับ ISA ของฮาร์ดแวร์จริงมากที่สุด
  • หลังการมาของ DirectX 12 และ Shader Model 6.0 ก็มีการใช้ฟอร์แมตใหม่ชื่อ DXIL แทน DXBC

DXIL

  • DXIL คือฟอร์แมตทางการที่ผู้ผลิตไดรเวอร์ DirectX 12 ใช้อยู่ในปัจจุบัน
  • นักพัฒนาเกมใช้คอมไพเลอร์ DXC เพื่อสร้างไบต์โค้ด DXIL แล้วส่งต่อให้ไดรเวอร์กราฟิกแปลงเป็นแมชชีนโค้ดจริงสำหรับรันบนฮาร์ดแวร์ GPU

การปรับแก้ Microsoft LLVM fork

  • Microsoft ตระหนักว่าการให้ผู้ผลิตไดรเวอร์อิสระต้องใช้ฟอร์แมต LLVM bitcode แบบเฉพาะนั้นไม่ใช่เรื่องที่เหมาะนัก และยอมรับว่าการดูแลรักษา LLVM fork ก็ไม่ใช่เรื่องสนุก
  • Microsoft จึงเริ่มงานเพื่อรวมการรองรับการคอมไพล์ HLSL เข้าไปใน LLVM/Clang โดยตรง

ความท้าทายสำหรับนักพัฒนาเกม, WebGPU และอื่น ๆ

  • ชั้น abstraction ด้านกราฟิกจำเป็นต้องมีภาษาเชดดิงแบบรวมศูนย์ และปัจจุบันการติดตั้งใช้งาน WebGPU ส่วนใหญ่ใช้แนวทางคอมไพล์ HLSL ไปเป็น DXBC หรือ DXIL

ทางอ้อมแบบง่าย ๆ: SPIR-V

  • Vulkan/SPIR-V ก็ใช้แนวทางคล้ายกัน และการที่ SPIR-V จะถูกปรับแต่งดีแค่ไหนนั้นขึ้นอยู่กับผู้ผลิต GPU

จะใช้ dxcompiler.dll หรือไม่?

  • รันไทม์ของ WebGPU ต้องตัดสินใจว่าจะใช้คอมไพเลอร์ HLSL รุ่นใหม่ DXC หรือจะใช้คอมไพเลอร์ FXC ที่ถูกเลิกใช้อย่างเป็นทางการแล้วและมีประสิทธิภาพกับคุณภาพโค้ดที่แย่กว่า

ทำไมถึงลิงก์แบบสแตติกไม่ได้?

  • LLVM fork ของ Microsoft ไม่รองรับการลิงก์แบบสแตติก และสาเหตุคือความซับซ้อนของระบบบิลด์

แนะนำ dxil.dll - บล็อบเซ็นโค้ดแบบปิดสำหรับ DirectX Shader

  • dxil.dll ไม่ได้ถูกบิลด์จากซอร์ส และพึ่งพา code blob แบบปิดเฉพาะแพลตฟอร์มที่เป็นส่วนพึ่งพาในรีโพซิทอรี 'โอเพนซอร์ส' ของ Microsoft

ปัญหาการรองรับแพลตฟอร์ม

  • Microsoft แจกจ่าย dxil.dll เฉพาะสำหรับ Windows (x86/arm) และ Linux (x86) เท่านั้น โดยไม่มีไบนารีสำหรับ macOS หรือ Linux aarch64

สรุป

  • ไม่สามารถบิลด์ DXC เป็นไลบรารีแบบสแตติกได้ และการกู้คืนฟังก์ชันของ LLVM กลับมาเพราะติดปัญหา code blob แบบปิดนั้นจะเป็นงานขนาดใหญ่
  • ไม่สามารถทำการคอมไพล์เชดเดอร์แบบออฟไลน์สำหรับเกมข้ามแพลตฟอร์มบน CI pipeline ของ macOS หรือ arm Linux ได้

ปรับปรุงระบบบิลด์

  • สำรวจวิธีเปลี่ยนระบบบิลด์ CMake ไปเป็น build.zig เพื่อให้บิลด์เป็นไลบรารีสแตติกเดี่ยวได้

แก้ปัญหาการพึ่งพาไลบรารีแบบไดนามิก

  • ฟอร์กโค้ดเบสของ DXC และแก้โค้ด C++ เพื่อลบการพึ่งพาไลบรารีแบบไดนามิกออก

แก้ปัญหาการเซ็นโค้ดแบบปิด

  • ค้นพบวิธีคอมไพล์ HLSL shader ได้โดยไม่ต้องพึ่งพา dxil.dll

ผลลัพธ์

  • จัดเตรียมไลบรารี dxcompiler และ CLI dxc ในรูปแบบไบนารีสแตติกที่ไม่ต้องพึ่งพา dxil.dll แบบปิด
  • บิลด์ไบนารีสำหรับ macOS, Linux และ Windows ใน CI pipeline

ข้อควรระวัง

  • ไบนารีบางส่วนยังไม่ได้บิลด์หรือทดสอบ และมีแผนจะใช้ Zig เองเป็นภาษาเชดดิงแทน HLSL

บันทึกส่วนตัว

  • หลังจากมีงานสายเทคนิคประจำเต็มเวลาในชื่อ Stephen ก็ได้ทำงานออนไลน์เพื่อสร้างเอนจิน Mach
  • มีรากฐานมาจาก FOSS และเชื่อว่าผู้พัฒนาควรเป็นเจ้าของเครื่องมือของตนและได้รับพลังจากมัน
  • ความฝันคือสร้าง Mach เพื่อทุกคน และหาเลี้ยงชีพด้วยการขายเกมคุณภาพสูง

ขอบคุณที่อ่าน

  • ลองเข้าไปดูที่ machengine.org
  • โปรดพิจารณาสนับสนุนการพัฒนาเพื่อให้ทำงานต่อได้มากขึ้น
  • เข้าร่วมเซิร์ฟเวอร์ Mach Discord
  • สนับสนุนบน GitHub
  • machengine.org

ความเห็นของ GN⁺

  • ประเด็นสำคัญที่สุดของบทความนี้คือความพยายามของชุมชนนักพัฒนาในการก้าวข้ามความซับซ้อนและข้อจำกัดของคอมไพเลอร์ DirectX Shader DXC ของ Microsoft
  • นักพัฒนา Mach engine ใช้ Zig เพื่อปรับปรุงระบบบิลด์ของ DXC และนำเสนอแนวทางใหม่ในการคอมไพล์ HLSL shader โดยไม่ต้องพึ่งพา dxil.dll แบบปิด ซึ่งเป็นการมีส่วนสำคัญต่อการพัฒนาเกมข้ามแพลตฟอร์ม
  • บทความนี้เน้นย้ำถึงความสำคัญของซอฟต์แวร์โอเพนซอร์ส และแนวคิดที่ว่านักพัฒนาควรเป็นเจ้าของและควบคุมเครื่องมือของตนเองได้ พร้อมแสดงให้เห็นคุณค่าของความร่วมมือและนวัตกรรมในชุมชนเทคโนโลยี

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

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

 
GN⁺ 2024-02-11
ความเห็นจาก Hacker News

  • ภาพรวมที่ยอดเยี่ยมเกี่ยวกับความซับซ้อนของการคอมไพล์เชดเดอร์สำหรับ 3D API

    • มีการนำเสนอภาพรวมของปัญหาที่ซับซ้อนในการคอมไพล์เชดเดอร์ข้าม 3D API
    • แม้จะเน้นที่ D3D และ Microsoft แต่สถานการณ์ใน 3D API อื่น ๆ ก็ไม่ได้ดีไปกว่ากันมากนัก
    • ตัวอย่างเช่น ไม่สามารถ cross-compile เชดเดอร์ Metal บนโฮสต์ Linux ได้ และทำได้เฉพาะบน macOS และล่าสุดคือบน Windows
    • หากทีม Mach ทำให้ "การใช้ Zig เป็นคอมไพเลอร์เชดเดอร์ข้าม 3D API" สำเร็จ และทำให้มันทำงานได้ลื่นไหลเหมือน "การใช้ Zig เป็น toolchain สำหรับ cross-compile" ได้ นี่จะเป็นเหตุการณ์ที่ยิ่งใหญ่ที่สุดในวงการคอมพิวเตอร์กราฟิกส์นับตั้งแต่ปี 1995

  • ปัญหาที่เกี่ยวข้องกับ Godot

    • การรองรับ Direct3D 12 ในปัจจุบันยังพึ่งพาไลบรารีแบบ proprietary dxil.dll ของ DirectX Shader Compiler ที่ถูกแจกจ่ายมาพร้อมกับ Godot
    • การแจกจ่ายซอฟต์แวร์แบบ proprietary ขัดกับพันธกิจของโครงการ Godot

  • การถกเถียงเรื่องการแจกจ่าย .dll เพิ่มเติม

    • การแจกจ่าย .dll เพิ่มเติมไม่ใช่เรื่องจำเป็นเป็นพิเศษ เช่นเดียวกับ proprietary middleware (Bink, SpeedTree, PhysX ฯลฯ) ที่วิดีโอเกมจำนวนมากใช้อยู่แล้ว
    • game launcher ส่วนใหญ่ (Steam, GOG, Epic ฯลฯ) ก็ต้องการ .DLL ของตัวเองเช่นกัน
    • เกมจำนวนมากใช้ D3D11On12 และเกมที่วางจำหน่ายแล้วจำนวนมากก็มี dxil.dll รวมอยู่ในไฟล์ติดตั้ง
    • งาน reverse engineering และ reimplement การลงลายเซ็นโค้ดนั้นน่าทึ่งมาก โดยเฉพาะเพราะผลลัพธ์ของ dxil.dll เหมือนกันทุกบิต
    • อย่างไรก็ตาม คนที่ชอบวิธีที่ง่ายกว่าก็อาจเลือกเพียงแค่แจกจ่าย DLL ไปเลย

  • คำถามเกี่ยวกับลายเซ็นของ DXIL.dll

    • ลายเซ็นที่ DXIL.dll ทำขึ้นนั้นเป็นเพียง MD5 ที่ถูกดัดแปลงหรือไม่?

  • การเปลี่ยนแปลงของ DXC ต่อชั้น code generation และโครงสร้างพื้นฐานของ LLVM

    • LLVM fork ของ DXC ได้ลบหรือทำให้ชั้น code generation และโครงสร้างพื้นฐานของ LLVM เสียหาย
    • การแก้ปัญหานี้และกู้คืนความสามารถของ LLVM ที่เสียหายจะเป็นงานใหญ่ระดับมหาศาล
    • เนื่องจากข้อจำกัดด้านทรัพยากร จึงไม่มีแผนจะแก้ปัญหานี้ในคอมไพเลอร์ DXC ตัวใหม่
    • ในอนาคตอาจรองรับการสร้าง DXBC จาก Clang ได้ แต่เนื่องจากงานนั้นมุ่งเน้นที่การรองรับการสร้าง DXIL และ SPIR-V ก่อน จึงคงจะยังไม่เริ่มในอีกหลายปี
    • มีการแสดงความขอบคุณต่อฝั่ง Microsoft ที่ตั้งความคาดหวังไว้อย่างชัดเจน

  • คำแนะนำเกี่ยวกับระบบนิเวศของ Mach

    • แนะนำให้ลองศึกษาดู mach-sysgpu โดยเฉพาะ ซึ่งเป็นการ reimplement WebGPU แบบสมบูรณ์ และเขียนขึ้นเป็นหลักโดย Ali Chraghi วัย 17 ปี

  • การพูดคุยเกี่ยวกับ SDL_gpu และ SDL3

    • ทีม SDL กำลังพัฒนาภาษาเชดเดอร์ใหม่ชื่อ SDL_gpu ซึ่งจะเปิดตัวใน SDL3
    • สิ่งนี้จะมอบวิธีการทำงานข้ามแพลตฟอร์มที่เกี่ยวข้องกับกราฟิก 3D ในเกม

  • การใช้งานภาษา Zig

    • การใช้ Zig เองเป็นภาษา shading เป็นเรื่องที่เจ๋งมาก
    • Zig เป็นภาษาจริง ๆ เป็นทั้ง build system และภาษา shading

  • การแสดงความขอบคุณต่องานด้านโครงสร้างพื้นฐาน

    • อ่านแล้วน่ายินดี เพราะงานโครงสร้างพื้นฐานแบบนี้เปิดประตูได้อีกมากมาย

  • การกล่าวถึงการออกเสียง DXIL

    • DXIL ออกเสียงว่า "dixel" โดยเหมือนกับคำว่า "pixel" แต่เปลี่ยน 'p' เป็น 'd'