ฝั่ง SteamDeck จะใช้วิธีคอมไพล์ shader เป็น vulkan ก่อนเข้าเกม ซึ่งผมสงสัยว่ามันรู้ได้ไงว่าโค๊ด shader อยู่ที่ไหน

"มันไม่รู้" แต่เรา "ช่วยมันหา" ได้

ก่อนอื่นเราต้องแบ่งสถานะของโค้ด Graphics API ออกเป็น 3 ส่วนใหญ่ ๆ ก่อน เพราะมันสำคัญถ้าเราจะเข้าใจถึง Graphics Stack อันแสนยุ่งเหยิง ถ้าจะถามว่าทำไม ให้ไปด่าผู้ผลิต GPU ก่อนเลยว่าทำไมไม่ทำมาตรฐานเดียวกันมา

ส่วนแรกสุดคือ (1) Shader ดิบ ๆ ส่วนนี้ CPU/Driver จะต้องมารับหน้าที่ "คอมไพล์" Shader ออกมาเป็น (2) Persistent Object ที่จะเอาไปใช้กับฝั่ง Driver ทำการ Compile Shader เป็น (3) Pipeline เข้าหา GPU อีกที โดยส่วน (1) และ (2) โดยรวมแล้วสามารถใช้แบบ Cross-platform ได้ แต่ (3) เป็น GPU-dependent

เปรียบเทียบง่าย ๆ (1) เป็นเหมือนโค้ดข้อความ (2) เป็นไบนารี IL และ (3) คือระดับใกล้ GPU มาก ๆ แล้ว

แต่ขั้นตอนที่หินของจริงคือขั้น (3) นี่แหละ

อย่างที่ได้เกริ่นไป เพราะว่า GPU แต่ละเจ้าก็ออกแบบ Hardware มาต่างกัน ทำให้การ Compile Shader เข้าไปหา GPU ออกมาแตกต่างกันด้วย ส่วนนี้เราไม่มีทางรู้ได้เลยว่า Shader จะตกไปอยู่ส่วนไหนของ GPU กันแน่ และเป็นหน้าที่ของ Driver ที่จะไปกำหนดปลายทาง เป็น Black Box อย่างหนึ่งเลย แต่ Driver บอกปลายทางตอนที่คอมไพล์เสร็จแล้ว และเราสามารถ Cache ส่วนนี้กลับมาใช้งานต่อได้ ไม่ต้องคอมไพล์ใหม่ แต่ถ้าเปลี่ยน Driver หรือ GPU ใหม่ ก็ต้องเริ่มต้นใหม่หมด

ทีนี้มันมี Strategy ที่จะทำให้ประสบการณ์ใช้งานแบบ Stutter-free มากที่สุด ซึ่งขั้น (1), (2), และ (3) ต่างก็มีผู้พัฒนาที่ทำเครื่องมือออกมา Support ช่วย

กรณีของ Vulkan ถ้าเราสามารถล่วงรู้ Presistent Object ทุกสถานะได้ (e.g., เราเป็น Developer) เราสามารถแก้ไขปัญหาตรงจุดที่ (1) และ (2) โดย "แพ็ก" ออบเจกต์เหล่านี้แล้วโยนไปให้เครื่อง Client ทำการ "เล่นย้อนหลัง" (Replay) เพื่อสร้าง Shader Cache ไว้ล่วงหน้าได้ ซึ่งมันก็คือขั้นตอนสามัญของเกมยุคใหม่แทบจะทุกเกมเลยมั้ง ถ้าเกมไหนใช้ Shader ไม่ได้ซับซ้อนอะไรก็อาจจะไม่มีขั้นตอน Compile Shader เลย ปล่อยให้ Compile ไประหว่างเล่นนั่นแหละ แต่ถ้ามันซับซ้อนมากขึ้นจนก่อ Stutter ทุกครั้งที่เกิด Shader Compilation ก็อาจจะต้องเปลี่ยน Strategy ไปคอมไพล์ตอนเริ่มเกมครั้งแรกแทน รอตั้งแต่ไม่กี่วิ ไปจนถึงหลักนาทีถึงชั่วโมงโน่นเลยกว่าจะได้เล่น แถม Update เกมใหม่ ก็ต้องมา Compile Shader ใหม่ ว้าวุ่นกันเลยทีเดียว

แน่นอนว่าวิธีนี้มันยังไม่ดีพอ Valve เลยได้ร่วมมือกับ Community ทำ Solution ออกมาคือโปรเจกต์ Fossilize ที่จะรัน Shader Compilation ก่อนที่เราจะเริ่มเล่นเกมกันเลย ปัญหามีอยู่อย่างเดียว คือมันกินทรัพยากรเครื่องตอนที่เราอาจจะกำลังทำอย่างอื่นอยู่

แต่ถ้ากรณีที่เราไม่รู้สถานะเหล่านี้ล่วงหน้า (e.g., เราเป็นผู้พัฒนา Translation Layer เช่น DXVK) ก็ต้องมีหน่วยกล้าตายเข้าไปเล่นเกมแล้วดักจับเอาสถานะเหล่านั้นออกมาเป็น Persistent Object เก็บไว้ให้เครื่องอื่นรอเอาไปคอมไพล์อีกที ซึ่งฟอร์แมตก็จะแตกต่างจากที่กล่าวข้างบนบ้าง แต่หลักการคล้าย ๆ กัน

อีกวิธีที่ง่ายยิ่งกว่า คือแทนที่จะไปดักจับสถานะแล้วคอมไพล์ เราสามารถข้ามไปขั้น (3) "ดูด" เอา Shader Pre-cache มาใช้ได้เลย แต่ก็อย่างที่เกริ่นไปคือ ในขั้น (3) มันกลายเป็นของ GPU แยกแตกต่างกันแล้ว และไม่ใช่แค่ยี่ห้อด้วย แค่ Model ต่างกัน Shader Cache ก็ไม่เหมือนกันแล้ว ทางด้านคลาวด์ก็ต้องขยันเก็บ Cache ของ GPU หลากหลายโมเดลหน่อย ถ้าเป็น Common Hardware อย่าง Steam Deck ก็ไม่ค่อยเจอปัญหา แต่ถ้าเป็นการ์ดที่คนไม่ค่อยใช้ก็ซวยหน่อย

Valve เสนอทางเลือกทั้งหมดที่กล่าวมาบน Steam หมดเลย แล้วแต่ว่าผู้พัฒนาจะสะดวกแบบไหน หรือถ้ากรณีของเกม Windows ที่ใช้ Proton ทาง Valve ก็ทำ Strategy ที่ผมไม่รู้ในการเก็บข้อมูลที่กล่าวมาทั้งหมดกลายเป็นคลาวด์แห่ง Shader ขนาดใหญ่ที่เอามา Combat ปัญหาใหญ่ของ Modern GPU ปัจจุบัน และผมคิดว่าไม่น่าจะมี Storefront หน้าไหนที่ทำถึงเท่า Valve แล้ว

ใน Game Engine ที่มี Primitive Shader ก็เริ่มมีคอนเซปต์ของ "God Shader" หรือ Ubershader ที่เน้นโยนเป็นก้อน ๆ ให้ Driver เอาไปคอมไพล์รอใช้งาน แล้วแทบจะขจัดปัญหา Stutter ออกไปเลยสำหรับเกมง่าย ๆ ที่ไม่ได้ Custom Shader เองเยอะแยะ เช่น Godot

เดาว่าของอีมูคือ transpile จาก pssl (สมมติว่า PS4-5) เป็น HLSL/GLSL เฉย ๆ แล้วต้องคอมไพล์อีกทีตอนเรียกใช้