- API กราฟิกเชิงทดลอง sysgpu ของ Mach engine ต้องการผลลัพธ์ shader สำหรับ Direct3D 12 จึงสร้าง Microsoft DXC ใหม่ให้อยู่ในรูปแบบที่ใช้งานแบบ static และข้ามแพลตฟอร์มได้ง่าย
- DXIL ของ Direct3D 12 มีลักษณะใกล้เคียงกับ LLVM bitcode หลังการประมวลผล ที่ fork ของ LLVM/Clang 3.7 จาก Microsoft ส่งออก ทำให้โครงสร้างพึ่งพา “เอาต์พุตจริงของคอมไพเลอร์” มากกว่าสเปก
- runtime ในสาย WebGPU มักแปลง WGSL เป็น HLSL แล้วใช้ FXC หรือ DXC สร้าง DXBC/DXIL แต่เพราะภาระในการแจกจ่าย DXC จึงมักทำให้ FXC ที่เก่าและช้ากลายเป็นค่าเริ่มต้น
- DXC เดิมทำ static link ได้ยาก และ ไบนารีสำหรับเซ็น/ตรวจสอบแบบ proprietary ชื่อ
dxil.dll ถูกแจกจ่ายโดยเน้น Windows และ Linux x86 เท่านั้น ทำให้การคอมไพล์ DirectX shader แบบออฟไลน์บน macOS หรือ Arm Linux CI ถูกปิดกั้น
mach-dxcompiler เขียนระบบ build แบบ CMake ใหม่เป็น Zig build.zig และตัด dependency ต่อ DLL ออก เพื่อให้มีไลบรารี dxcompiler แบบ static และ CLI dxc แต่ยังมีข้อจำกัดด้าน MSVC ABI, การทดสอบ musl, เอาต์พุต SPIR-V และการรองรับ SM6.7
ทำไม Mach จึงสร้าง DXC ใหม่
- Mach engine กำลังสร้าง API กราฟิกเชิงทดลองชื่อ sysgpu ด้วย Zig โดยตั้งเป้ารองรับ backend อย่าง Metal, Vulkan, Direct3D และ OpenGL
- ใน backend ของ Direct3D 12 ต้องคอมไพล์โปรแกรม shader ให้อยู่ในรูปแบบที่ Direct3D 12 ใช้งานได้
- ในกระบวนการนี้พบว่า DirectX Shader Compiler DXC ของ Microsoft สร้างประสบการณ์การแจกจ่ายที่ซับซ้อนและไม่สะดวกสำหรับนักพัฒนาเกม
การคอมไพล์ DirectX shader ที่ย้ายจาก FXC ไป DXC
- API กราฟิก DirectX ใช้ HLSL เป็นภาษา shading
- คอมไพเลอร์ HLSL ก่อน Direct3D 11 เรียกว่า FXC หรือ effects compiler
- ในหมู่นักพัฒนาเกม FXC เป็นที่รู้จักว่าเป็นคอมไพเลอร์ที่ช้าและคุณภาพการสร้างโค้ดไม่ดี
- อาจเสียเปรียบทั้งความเร็วในการคอมไพล์ shader และประสิทธิภาพตอนรัน
- ใน Direct3D 12 และ Shader Model 6.0 Microsoft ประกาศ deprecate FXC ที่เคยรวมมากับ Windows OS อย่างเป็นทางการ และนำ DXC ซึ่งเป็น fork บนฐาน LLVM/Clang v3.7 มาใช้
- DXC เปิดเป็นโอเพนซอร์สที่ Microsoft/DirectXShaderCompiler และ Microsoft ยังแจกจ่ายไบนารีที่ build ไว้ล่วงหน้าด้วย
- ใน LLVM fork ของ Microsoft การเปลี่ยนแปลงที่เกี่ยวกับ HLSL ถูกทำเครื่องหมายด้วยคอมเมนต์
// HLSL Change Start, // HLSL Change End
DXBC และ DXIL ที่ไดรเวอร์ Direct3D ใช้งาน
- ผู้ผลิต GPU แต่ละรายมีโครงสร้างฮาร์ดแวร์และข้อกำหนดต่างกัน ทำให้ native binary ที่ HLSL จะถูกรันจริงในท้ายที่สุดแตกต่างกันไปตาม GPU ของ Intel, NVIDIA และ AMD
- Microsoft ให้บริการ frontend API อย่าง Direct3D และ HLSL ส่วน IHV เช่น Intel, AMD และ NVIDIA เขียนไดรเวอร์เพื่อเชื่อมสิ่งเหล่านี้เข้ากับรูปแบบที่ใกล้กับ ISA ของฮาร์ดแวร์
- ใน DirectX 9~11 ไดรเวอร์จะใช้ DXBC
- นักพัฒนาเกมคอมไพล์ HLSL เป็น DXBC ด้วย CLI
fxc.exe หรือ API d3dcompiler
- ไดรเวอร์แปลง DXBC เป็นไบนารีที่จะรันบน GPU จริง
- DXBC เป็นรูปแบบ proprietary แบบไม่เปิดเผยที่ใช้กันระหว่าง Microsoft กับผู้ผลิตไดรเวอร์ GPU
- หลัง DirectX 12 และ Shader Model 6.0 เป็นต้นมา DXIL กลายเป็นรูปแบบทางการที่ผู้ผลิตไดรเวอร์ DirectX 12 ใช้งาน
- DXIL มีลักษณะใกล้เคียงกับ bitcode หลัง code generation และ optimization pass ของ LLVM 3.7 โดยเพิ่ม container/wrapper แบบ custom ขนาดเล็กเข้าไป
- เอกสารของ DXIL ไม่ได้เป็นสเปกแยกต่างหากมากนัก แต่พึ่งพา bitcode ที่ fork ของ LLVM 3.7 จาก Microsoft ส่งออกจริงหลังการเปลี่ยนแปลงและการ optimize สำหรับ HLSL
แผน DXIR ที่หายไปและการย้ายเข้าสู่ upstream ของ LLVM
- ในช่วง DirectX 12 และ Shader Model 6.0 Microsoft เคยมีแนวคิดจะสร้าง DXIR ซึ่งเป็น IR ระดับสูงที่ยังไม่ optimize แล้วให้ DXC ลดระดับลงเป็น DXIL ที่ optimize แล้ว
- ในปี 2021 ข้อความที่บอกเป็นนัยถึงความเป็นไปได้ในการสร้าง DXIR ถูกนำออกไป
- ในปี 2019 พนักงาน Microsoft ตอบว่าแทบไม่มีเอกสารเกี่ยวกับกระบวนการลดระดับจาก DXIR เป็น DXIL และ DXIR ไม่ใช่รูปแบบทางการ แต่ใกล้เคียงกับ LLVM IR ตัวแรกหลัง CodeGen
- ในปี 2023 พนักงาน Microsoft ระบุว่า LLVM fork ของ DXC ได้ลบหรือทำให้ชั้น code generation และโครงสร้างพื้นฐานจำนวนมากของ LLVM เสียหาย
- หากต้องการเพิ่มการสร้าง DXBC ให้ DXC ต้องกู้คืนฟีเจอร์ LLVM ที่เสียไป และ DXC จะไม่จัดการเรื่องนี้
- ตั้งแต่เดือนมีนาคม 2022 Microsoft ได้เสนอและกำลังดำเนินงาน upstream การรองรับการคอมไพล์ HLSL เข้าสู่สายหลักของ LLVM/Clang
- แผนการเปลี่ยนผ่านนี้ยังรวมถึงการเพิ่มการรองรับ legacy LLVM v3.7 bitcode writing กลับเข้าไปใน LLVM/Clang สมัยใหม่ด้วย
ภาระการแจกจ่าย DXC สำหรับ WebGPU และเกมเอนจิน
- abstraction layer ด้านกราฟิกที่ต้องการรวม API กราฟิกสมัยใหม่อย่าง Metal, Direct3D 12 และ Vulkan เข้าด้วยกัน ก็ต้องมีภาษา shading แบบรวมศูนย์ด้วย
- ปัจจุบัน implementation ของ WebGPU บางส่วนตั้งเป้าระยะยาวไปที่เส้นทางการปล่อย DXIL โดยตรง แต่ในทางปฏิบัติส่วนใหญ่ยังไม่ทำเช่นนั้น
- เส้นทาง WebGPU ทั่วไปมีดังนี้
- แปลงภาษาแบบข้อความ WGSL เป็น HLSL ตอน runtime
- คอมไพล์ HLSL เป็น DXBC หรือ DXIL ด้วยคอมไพเลอร์ HLSL
- ส่ง DXBC/DXIL ที่ optimize แล้วให้ไดรเวอร์กราฟิก จากนั้นไดรเวอร์จะแปลงเป็น intermediate representation และ machine code เฉพาะ vendor
- Vulkan/SPIR-V ก็มีโครงสร้างที่ไดรเวอร์ต้องคอมไพล์ SPIR-V เป็น native binary เช่นกัน
- ไดรเวอร์บางตัวอาจถือว่า SPIR-V ถูก optimize มาแล้ว แต่จะแตกต่างกันตาม GPU มือถือและเดสก์ท็อป
- Fossilize ของ Valve เก็บ cache ของไบนารีจริงที่ไดรเวอร์คอมไพล์ไว้ตามชุดผสมของ GPU และเวอร์ชันไดรเวอร์
- DXIL เป็น LLVM bitcode หลัง optimization pass เสมอ ในขณะที่ SPIR-V อาจอยู่ในรูปแบบที่ optimize แล้วหรือไม่ก็ได้
- มีเพียง Apple Metal เท่านั้นที่รองรับ API สำหรับคอมไพล์โดยตรงเป็นรูปแบบ native binary ของฮาร์ดแวร์เป้าหมายจริง
ตัวเลือกที่เกิดจาก dxcompiler.dll และ dxil.dll
- runtime ของ WebGPU ทำการแปลง WGSL→HLSL→DXIL ตอน runtime จึงต้องเลือกอย่างใดอย่างหนึ่งระหว่าง DXC ใหม่กับ FXC เก่า
- ตามเอกสารของ Bevy นั้น FXC เก่า ช้า และไม่ได้รับการดูแลต่อ แต่ไม่จำเป็นต้องแจกจ่าย DLL เพิ่ม
- ในทางกลับกัน DXC ใหม่ เร็ว และได้รับการดูแลต่อ แต่ต้องแจกจ่าย
dxcompiler.dll และ dxil.dll ไปพร้อมกับแอปพลิเคชัน
- ปัญหาการเลือกนี้ไม่ได้ส่งผลเฉพาะ Bevy เท่านั้น แต่ยังกระทบผู้ใช้ Rust ของ
wgpu และผู้ใช้ Dawn WebGPU ด้วย
- ผลคือซอฟต์แวร์จำนวนมากเลือกใช้ FXC ที่เก่า ช้า และไม่ได้รับการดูแลต่อเป็นค่าเริ่มต้น
เหตุผลที่ static link DXC ได้ยาก
- LLVM fork ของ Microsoft ไม่รองรับ static link
- หากเปลี่ยน
SHARED เป็น STATIC ในไฟล์ CMake จะได้ static library ประมาณ 15 รายการ แต่ประสบการณ์การ link แย่กว่าการมีไลบรารีเดียว
- หากพยายามใช้ไลบรารี
OBJECT ของ CMake การเปลี่ยนแปลง HLSL ของ Microsoft จะทำให้เห็น dependency แฝงระหว่างกัน โดยไม่ขึ้นกับ dependency เชิงตรรกะ
- implementation บางส่วนของ COM interface ใน DXC ถูกออกแบบให้โหลด
dxcompiler.dll และ dxil.dll เป็น dynamic library แล้วเรียกตัวเอง
- แค่เปลี่ยนการตั้งค่า build อย่างเดียวจึงทำให้สร้าง DXC แบบ static ได้ยาก
dxil.dll proprietary และการเซ็น shader
dxil.dll ไม่ถูกสร้างขึ้นแม้จะ build DirectXShaderCompiler จากซอร์ส แต่มีแจกจ่ายใน GitHub release สำหรับ Windows x86/Arm และ Linux x86- ตาม D3D12 Shader Cache API specification D3D12 รับเฉพาะ shader ที่ถูกเซ็นแล้ว และหากมีการ optimize หรือ patch ตอน runtime จะต้องตรวจสอบและเซ็น shader ใหม่
- ใน release preview ของ Shader Model 6.8 ไม่มี
dxil.dll/libdxil.so ให้
- DXIL เป้าหมาย SM6.8 ที่คอมไพเลอร์ดังกล่าวสร้างยังไม่ใช่ฉบับสุดท้ายและตรวจสอบไม่ได้
- ไม่รองรับการแจกจ่ายหรือรันบนเครื่องที่ไม่ใช่ Developer Mode
- หากไม่มี
dxil.dll shader จะไม่ถูกเซ็น/ตรวจสอบ
- shader ที่ไม่ได้เซ็น/ตรวจสอบจะรันไม่ได้หากเครื่อง Windows ไม่ได้อยู่ใน Developer Mode
การคอมไพล์ออฟไลน์และข้อจำกัดด้านแพลตฟอร์ม
- Mach ต้องการหลีกเลี่ยงการแจกจ่าย dependency ขนาดหนักของ DXC เมื่อจำเป็น และต้องการทำ การคอมไพล์ shader แบบออฟไลน์
- Microsoft แจกจ่าย
dxil.dll เฉพาะสำหรับ Windows x86/Arm และ Linux x86 เท่านั้น
- ไม่มีไบนารี Linux aarch64 และ macOS
- ดังนั้นจึงไม่สามารถสร้าง build เกมข้ามแพลตฟอร์มสำหรับ Windows บน macOS หรือคอมไพล์ DirectX shader แบบออฟไลน์ใน pipeline CI ของ Arm Linux ได้
- หากต้องการรันไบนารีสำหรับเซ็นแบบ proprietary จำเป็นต้องใช้เครื่อง Windows หรือ x86_64 Linux
สิ่งที่ mach-dxcompiler เปลี่ยนไป
- เขียนระบบ build CMake เดิมประมาณ 10.5k บรรทัดใหม่เป็น
build.zig ของ Zig
- ตั้งเป้าหมาย build เฉพาะสองส่วนที่ผู้ใช้งานมักต้องการ ได้แก่ ไลบรารี
dxcompiler.dll และไบนารี dxc.exe สำหรับคอมไพล์/ทดสอบแบบออฟไลน์
- ผลคือถูกจัดระเบียบเป็นลอจิก
build.zig ประมาณ 1k บรรทัด
- fork codebase ของ Microsoft เพื่อแก้โครงสร้างที่ DXC คาดหวังการมีอยู่ของ
dxcompiler.dll และ dxil.dll
- จำลอง DLL entrypoint
- ปิดฟีเจอร์แสดงข้อมูลเวอร์ชันคอมไพเลอร์ที่มาจาก DLL
- จำลองการโหลด function pointer ของ dynamic library
mach-dxcompiler ถูกจัดรูปแบบให้ ไม่พึ่งพา dxil.dll- บนเครื่อง macOS สามารถคอมไพล์ HLSL shader โดยไม่มี
dxil.dll แบบ proprietary และสร้างไฟล์ที่เหมือนกัน byte-for-byte กับ DXIL bytecode ที่รันบนเครื่อง Windows ทั่วไปได้
ผลลัพธ์และวิธีใช้งาน
- release มีไลบรารี
dxcompiler แบบ static และไบนารีที่ build ไว้ล่วงหน้าของ CLI dxc
- ไม่มี dependency ต่อ
dxil.dll แบบ proprietary
- target ที่ build ใน pipeline CI มีดังนี้
- macOS: Apple Silicon aarch64 และ Intel x86_64
- Linux: musl และ glibc, aarch64 และ x86_64
- Windows: x86_64 และ aarch64 รวมถึง MinGW/GNU ABI
- ไลบรารีเปิด C API ขนาดเล็ก เป็นทางเลือกแทน COM API เดิม
- นักพัฒนาเกม Zig สามารถใช้ Zig API ใน repository ได้ และดูตัวอย่างการใช้งานได้จาก test ใน
src/main.zig
- โดยค่าเริ่มต้นจะดาวน์โหลดและใช้ไบนารีที่ build ไว้ล่วงหน้า
- การ build จากซอร์สทำได้ใน repository mach-dxcompiler ด้วยเพียง
zig และ git โดยต้องใช้เวอร์ชัน Zig ที่กำหนด
git clone https://github.com/hexops/mach-dxcompiler
cd mach-dxcompiler/
zig build -Dfrom_source -Dtarget=aarch64-macos
zig build -Dfrom_source -Dtarget=x86_64-windows-gnu
zig build -Dfrom_source -Dtarget=x86_64-linux-gnu
ข้อจำกัดปัจจุบันและเงื่อนไขการดูแลต่อ
- ไบนารี Windows MSVC ABI ยัง build ไม่ได้ในตอนนี้ เพราะมีบั๊กเล็ก ๆ ใน C binding
- ไบนารี Linux musl build ได้แล้ว แต่ยังไม่ได้ทดสอบ
- Mach engine มีแผนใช้ Zig เองเป็นภาษา shading แทน HLSL จึงไม่ build การรองรับเอาต์พุต SPIR-V และไม่มีแผนเพิ่ม
- ขณะนี้ยังไม่มีแผนอัปเดตรองรับ SM6.7 ที่เพิ่ง release
- ระบบ build CMake บางส่วนของ LLVM ยังไม่ได้ถูกย้ายทั้งหมด และรายละเอียดที่เกี่ยวข้องยังคงอยู่ใน
generated-include/
- โปรเจกต์นี้มีอยู่เพื่อแก้ปัญหาของ Mach และปัจจุบันมีคนเดียวที่จัดการ issue
- หากพบเส้นทางที่ดีกว่า โปรเจกต์นี้อาจถูก deprecate
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เป็นบทความที่สรุปได้ดีมากว่าระดับล่างสุดของการคอมไพล์เชดเดอร์ข้าม 3D API นั้นยุ่งเหยิงแค่ไหน
แม้จะโฟกัสที่ D3D และ Microsoft แต่ 3D API อื่น ๆ ก็ไม่ได้ดีกว่ากันมากนัก ตัวอย่างเช่น บนโฮสต์ Linux ไม่สามารถครอสคอมไพล์ Metal shader ได้ และทำได้เฉพาะบน macOS กับ Windows รุ่นค่อนข้างใหม่เท่านั้น
ถ้าทีม Mach ทำให้แนวคิดการใช้ Zig เป็นคอมไพเลอร์เชดเดอร์ข้าม 3D API ลื่นไหลได้พอ ๆ กับ “Zig ในฐานะ toolchain สำหรับ cross compile” นี่อาจเป็นหนึ่งในเรื่องใหญ่ที่สุดของวงการคอมพิวเตอร์กราฟิกนับตั้งแต่ราวปี 1995 เลยก็ได้
เรื่องนี้เกี่ยวข้องกับ Godot ด้วย
เขาบอกว่า “เหตุผลที่ทำให้เป็นตัวเลือกเสริมก็เพราะการรองรับ Direct3D 12 ในตอนนี้ต้องพึ่งการแจกจ่ายไลบรารี dxil.dll แบบ proprietary ของ DirectX Shader Compiler ไปพร้อมกับ Godot และการแจกจ่ายซอฟต์แวร์แบบ proprietary นั้นขัดกับพันธกิจของโครงการ Godot”
https://godotengine.org/article/dev-snapshot-godot-4-3-dev-3...
ฉันแค่อยากให้ GPU, Wi‑Fi และ Bluetooth ใช้งานได้ ดังนั้นถ้าติ๊กค่าเริ่มต้นไว้เลยก็ดี
สำหรับประเด็นที่ว่า “ไม่จำเป็นต้องแจกจ่าย .dll เพิ่มไปพร้อมกับแอปพลิเคชัน” นั้น ทุกวันนี้วิดีโอเกมจำนวนมากก็แจกจ่าย proprietary middleware อย่าง Bink, SpeedTree, PhysX แบบนั้นอยู่แล้ว
ตัว launcher ส่วนใหญ่ เช่น Steam, GOG, Epic ก็ต้องใช้ .DLL ของตัวเอง และหลายเกมก็ใช้ D3D11On12 ด้วย มีเกมที่วางขายจำนวนมากซึ่งในรายการไฟล์ที่ติดตั้งมี dxil.dll รวมอยู่ด้วย
เพราะงั้นก็เลยสงสัยจริง ๆ ว่า การแจกจ่าย DLL เพิ่มอีกหนึ่งตัวมันมีปัญหาอะไร? งานรีเวิร์สเอนจิเนียร์ลายเซ็นโค้ดและทำซ้ำขึ้นมาใหม่นี้ยอดเยี่ยมมาก โดยเฉพาะที่ผลลัพธ์ตรงกับ dxil.dll แบบบิตต่อบิต แต่ฉันขี้เกียจเกินเหตุและคงเลือกทางง่ายกว่าคือแจก DLL ไปเลย
ตัวอย่างเช่น เอนจิน Mach สามารถใช้สิ่งนี้ตอนสร้างคอมไพเลอร์ที่คอมไพล์โค้ด Zig ไปเป็นเชดเดอร์สำหรับแพลตฟอร์มเป้าหมายต่าง ๆ และผู้ใช้ปลายทางก็ใช้ได้จากความสามารถหลักของ Mach ทันทีโดยไม่ต้องตั้งค่าเพิ่มหรือมี dependency เพิ่มเติม
แม้แต่ในเกม AAA และซอฟต์แวร์อื่น ๆ การมีdependency เพิ่มเติมก็หมายถึงมีสิ่งที่อาจพังได้โดยอยู่นอกการควบคุมของคุณ ที่บริษัทเก่าของฉัน เคยต้องใช้ middleware บางตัวที่มีให้แค่ในรูป DLL และไลบรารีสำหรับลิงก์ ทำให้ต้องลงแรงกับการอัปเกรด Visual Studio มากขึ้น และยังต้องขอเวอร์ชันใหม่มาอีก เพราะบริษัท middleware นั้นไม่ได้เตรียมการอัปเกรดฝั่งตัวเองไว้ สุดท้ายเราต้องทำ QA ความเข้ากันได้กับ VS เวอร์ชันใหม่เองด้วย
แน่นอนว่าการมีซอร์สโค้ดไม่ได้แปลว่าการอัปเดตจะไร้แรงเสียดทานเสมอไป แต่แรงเสียดทานจะน้อยลงมาก และไม่ต้องรอคนอื่นอีกต่อไป ดูเหมือนว่า Visual Studio รุ่นหลัง ๆ จะพยายามรักษาความเข้ากันได้ย้อนหลังของไลบรารี C++ แบบไบนารี แต่ฉันไม่คิดว่านี่เป็นคุณสมบัติที่พึ่งพาได้ในระยะยาว
และทั้งหมดนี้ยังตั้งอยู่บนสมมติฐานว่าโค้ดยังคงอยู่บนแพลตฟอร์มและเป้าหมายเดิม วันหนึ่งคุณอาจอยากใช้แพลตฟอร์มอื่นเป็นโฮสต์หรือเป็นเป้าหมาย และถ้าไม่มีซอร์สโค้ด มันอาจยากมากหรือถึงขั้นเป็นไปไม่ได้ แม้กับสิ่งที่ดูเฉพาะแพลตฟอร์มอย่าง DXIL ซึ่งอาจเหมือนไม่ใช่ปัญหาใหญ่ แต่ในบทความก็ระบุว่าเพราะ DXIL มีลักษณะเป็น binary blob ทำให้ไม่สามารถพรีคอมไพล์เชดเดอร์ได้นอกเหนือจากสถาปัตยกรรม Windows และ Linux บางแบบที่ Microsoft มี DLL ให้
ลายเซ็น ที่
DXIL.dllทำ[1] ท้ายที่สุดก็เป็นแค่ MD5 ที่ดัดแปลงแล้วเท่านั้นหรือ?1: https://github.com/hexops/DirectXShaderCompiler/blob/4190bb0...
ถ้าใครอ่านมาถึงตรงนั้นอย่างตั้งใจ ก็น่าจะพอเดาได้ว่ามันต้องเป็นแฮชพื้นฐานหรืออะไรทำนองนั้น และอย่างแย่ที่สุดก็แค่ให้ใครสักคนไปรีเวิร์สเอนจิเนียร์แอสเซมบลีเอา
หลังจากพยายามขนาดนั้นแล้ว จะวิจารณ์ Microsoft แบบเปิดเผยเลยก็ได้ โดยเฉพาะเมื่อเป็นเรื่องของโค้ดโอเพนซอร์สที่ใครสนใจก็ขุดลงไปหาได้อยู่แล้ว และก็ขอบคุณ msk ที่ไปหามาให้
https://github.com/baldurk/renderdoc/blob/4a620bb5a16b4de4e2...
ชอบคำพูดอ้างอิงนี้[0] จากฝั่ง Microsoft ฟอร์ก LLVM ของ DXC ได้ตัดทิ้งหรือทำให้ชั้น code generation และโครงสร้างพื้นฐานของ LLVM พังไปเยอะมาก ดังนั้นถ้าจะรองรับการสร้าง DXBC ใน DXC ก็ต้องมีงานใหญ่ระดับมหาศาลเพื่อซ่อมและกู้ฟีเจอร์ LLVM ที่พังเหล่านั้นกลับมา
เพราะปัญหามีขนาดใหญ่และทรัพยากรของทีมมีจำกัด พวกเขาจึงบอกว่าจะไม่แก้เรื่องนี้ในคอมไพเลอร์ DXC ตัวใหม่ และแม้อนาคต Clang อาจรองรับการสร้าง DXBC ได้ แต่ในช่วงหลายปีข้างหน้าน่าจะยังเริ่มไม่ได้ เพราะต้องโฟกัสกับการรองรับการสร้าง DXIL และ SPIR-V ก่อน การบอกให้ชัดว่า จะไม่ทำอะไร แบบนี้ถือว่าสดใหม่ดี
[0] https://github.com/microsoft/DirectXShaderCompiler/issues/57...
แนะนำให้ลองดู ecosystem ของ Mach จริง ๆ โดยเฉพาะ mach-sysgpu ซึ่งเป็นการ reimplement WebGPU แบบสมบูรณ์ และส่วนใหญ่เขียนโดย Ali Chraghi ที่อายุ 17 ปี
ฝั่ง SDL ก็กำลังสร้างภาษาเชดเดอร์ในรูปแบบ SDL_gpu ที่ต่างจากของเดิม เพื่อนำเข้า SDL3 ผมจับตาดูอยู่พักใหญ่แล้ว เพราะมันอาจกลายเป็นแนวทางข้ามแพลตฟอร์มสำหรับงานกราฟิก 3D ในเกมได้
ถ้าจะต่างก็คงแค่ SDL_gpu ยังอยู่ช่วงเริ่มต้น ส่วน WebGPU มี implementation สาธารณะที่ดีอยู่แล้วสองตัว
วิธีที่ปวดหัวน้อยกว่าน่าจะเป็นแนว HLSL/GLSL → SPIR-V ↔ DXIL หรือไม่ก็เขียนเชดเดอร์เป็น SPIR-V ไปเลย
ใน vkd3d ของ Wine ดูเหมือนจะมีตัวแปลง DXIL → SPIR-V อยู่ และเพราะมันเป็นภาษากลางที่เรียบง่ายกว่าตัวแปลงภาษาสำหรับเชดเดอร์ระดับสูงมาก จึงอาจแข็งแรงกว่า
แต่ก็สงสัยว่ามี คอมไพเลอร์ HLSL → DXIL ที่อิง C99 ล้วน ๆ เรียบง่าย และคอมไพล์ได้โดยไม่ต้องใช้ GCC หรือ Clang อยู่ไหม นอกจากสัตว์ประหลาด LLVM ตัวนี้
ถ้าจะตอบคำถามก็คือ ไม่มี การแปลงจาก HLSL ไป DXIL นั้นในทางปฏิบัติ Microsoft ถือไพ่ไว้แทบทั้งหมด และแทบไม่เคยมีความพยายามจะหนีออกจากจุดนั้น
การใช้ Zig เองเป็นภาษาเชดเดอร์นั้นเท่มาก Zig เป็นภาษาเดียวอย่างแท้จริง เป็นทั้ง build system และเป็นทั้งภาษาเชดเดอร์ด้วย!