- WebGPU ได้รับการรองรับอย่างเป็นทางการใน Firefox 141 เวอร์ชัน Windows หลังจากพัฒนามาอย่างยาวนาน
- WebGPU คือ อินเทอร์เฟซ GPU บนเว็บ สำหรับการประมวลผลกราฟิกสมัยใหม่และงานคำนวณประสิทธิภาพสูง ซึ่งคาดว่าจะยกระดับ เกม·การแสดงผลข้อมูล·การประมวลผลภายในเครื่อง ได้อย่างมาก
- การติดตั้งใช้งาน WebGPU ของ Firefox ถูกสร้างขึ้นบนไลบรารี WGPU ที่พัฒนาด้วย Rust และรองรับแบ็กเอนด์หลายแบบ เช่น Direct3D 12, Metal, Vulkan
- ขณะนี้เปิดใช้งานอย่างเป็นทางการเฉพาะบน Windows เท่านั้น โดยจะรองรับ Mac, Linux, Android ในอนาคต
- ยังมีงานพัฒนาเพิ่มเติมที่เหลืออยู่ เช่น การปรับปรุงประสิทธิภาพ และ การทำตามมาตรฐาน
ความหมายของการรองรับ WebGPU บน Windows
- WebGPU ที่พัฒนามาอย่างยาวนานถูกบรรจุอย่างเป็นทางการใน Firefox 141 สำหรับสภาพแวดล้อม Windows
- WebGPU เป็นมาตรฐานสมัยใหม่ที่ช่วยให้คอนเทนต์บนเว็บเชื่อมต่อกับ GPU ของผู้ใช้ ได้โดยตรง เพื่อสร้าง กราฟิก และ การประมวลผลแบบขนาน ประสิทธิภาพสูง
- ด้วยเทคโนโลยีนี้ คาดว่าขีดจำกัดด้านประสิทธิภาพในหลายสาขา เช่น เกมบนเว็บ, การแสดงผลข้อมูล, แมชชีนเลิร์นนิง จะขยายออกไปอย่างมาก
- สามารถเรียนรู้และทดลองได้ผ่าน WebGPU บทช่วยสอน, WebGPU ตัวอย่าง, เอกสาร MDN
- WebGPU ถูกกำหนดไว้ใน มาตรฐาน WebGPU ของ W3C และ มาตรฐาน WGSL โดย Mozilla มีส่วนร่วมอย่างแข็งขันในกระบวนการทำมาตรฐานมาตั้งแต่ปี 2017
สถานะของ WebGPU ในแต่ละเบราว์เซอร์
- Chrome รองรับ WebGPU แล้วตั้งแต่ปี 2023
- Safari 26 มีกำหนดเปิดตัวในช่วงฤดูใบไม้ร่วงปีนี้
- Firefox 141 รองรับอย่างเป็นทางการเฉพาะ Windows ในตอนนี้ ส่วน Mac/Linux/Android จะขยายการรองรับผ่านอัปเดตในอนาคต
- ในเวอร์ชัน Firefox Nightly ที่ผ่านมา สามารถใช้งานแบบทดลองได้บน ทุกแพลตฟอร์มยกเว้น Android
การติดตั้งใช้งาน WebGPU ของ Firefox
- WebGPU ของ Firefox พัฒนาขึ้นบนพื้นฐานของไลบรารีโอเพนซอร์ส Rust อย่าง ** WGPU**
- WGPU เชื่อมต่อกับกราฟิก API ระดับล่าง เช่น Direct3D 12, Metal, Vulkan ให้เหมาะกับฮาร์ดแวร์ของแต่ละแพลตฟอร์ม
- Mozilla เป็นหนึ่งในผู้มีส่วนร่วมหลักของโครงการ WGPU
- หากเป็นนักพัฒนา Rust การเริ่มต้นจากโครงการ WGPU เป็นแนวทางที่เหมาะสมหากต้องการมีส่วนร่วมกับ Firefox WebGPU
- WGPU ถูกใช้อย่างแพร่หลายนอกเหนือจาก Firefox ด้วย และมีชุมชนที่เคลื่อนไหวอย่างคึกคัก
งานหลักและการปรับปรุง
- WebGPU เป็น API ขนาดใหญ่และซับซ้อน และจนถึงตอนนี้มุ่งเน้นการทำให้เสถียรโดยอิงจากเดโมหลักและกรณีใช้งานจริง
- ด้านที่ยังต้องปรับปรุงเพิ่มเติม:
- แก้ปัญหาประสิทธิภาพที่ลดลงจาก IPC แบบไม่บัฟเฟอร์ กับ โปรเซส sandbox ของ GPU (บั๊ก 1968122, มีแผนปรับปรุงประสิทธิภาพใน Firefox 142)
- เวลารอที่เพิ่มขึ้นเพราะตรวจจับเวลาสิ้นสุดงานของ GPU ได้ด้วย interval timer เท่านั้น (บั๊ก 1870699, กำลังปรับปรุงด้วยวิธีที่ดีกว่า)
- ยังไม่รองรับ importExternalTexture ทำให้ไม่สามารถอ่านข้อมูลวิดีโอจากตัวถอดรหัสไปยัง GPU ได้โดยตรง (บั๊ก 1827116, อยู่ระหว่างพัฒนา)
- หากพบปัญหาในการใช้งานจริง ควรแจ้งผ่าน WebGPU component ของ Bugzilla พร้อมแนบรายละเอียดให้ครบถ้วน
แผนต่อจากนี้
- หลังจาก Windows จะทยอยขยายการรองรับอย่างเป็นทางการไปยัง Mac, Linux, Android
- มีแผนปรับปรุงอย่างต่อเนื่องในด้าน ประสิทธิภาพ, ความเข้ากันได้, การทำตามมาตรฐาน
- คาดว่าการรองรับ WebGPU อย่างเป็นทางการจะเปิดความเป็นไปได้ใหม่ ๆ ให้กับ เว็บแอปพลิเคชัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เป็นข่าวที่น่าตื่นเต้นมาก ขอแสดงความยินดีกับทีม Firefox
บริษัทของฉันกำลังพัฒนาให้ Unreal รันในเบราว์เซอร์ได้ และได้สร้าง WebGPU RHI แบบคัสตอมสำหรับ Unreal Engine 5
ถ้าใครอยากดูเทคเดโมด้วยตัวเอง ดูลิงก์ด้านล่างได้
(ใช้งานได้เฉพาะบนเบราว์เซอร์เดสก์ท็อปที่ใช้ Chromium และโทรศัพท์ Android บางรุ่นเท่านั้น)
Cropout: https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
Car configurator: https://garage.cjponyparts.com/
ลองทดสอบบน Firefox 142 (nightly) แล้ว
Cropout ค้างอยู่ที่ 0% เป็นเวลานาน พร้อมกับมี network request มากกว่า 1200 รายการ
สุดท้ายโหลดไปถึงเมนูได้ แต่พื้นหลังเป็นสีดำและเห็นแค่องค์ประกอบ UI
เกิด error จำนวนมากตอน parse shader และยังมี error อื่น ๆ อีก
ส่วน Car configurator ขึ้น error หลายรายการ ค้างที่ 0% และไม่โหลดต่อ
มีข้อความว่า "ไฟล์เกมหายไป ทำให้ไม่สามารถเริ่มต้น global shader และคอนเทนต์ได้"
อยากให้มีการทดสอบบน Firefox ขั้นพื้นฐานก่อนจะแชร์ด้วย
คุณระบุว่า "ใช้งานได้เฉพาะบนเบราว์เซอร์ที่ใช้ Chromium" แต่โพสต์นี้พูดถึง WebGPU ของ Firefox โดยตรง
เลยอยากรู้ว่ามีแผนจะทดสอบหรือออกเวอร์ชันที่รองรับ Firefox ไหม
ลองรัน "cropout" บน Android Chrome ใน Pixel 7a แล้วค้างที่ 0%
ส่วน "car configurator" ไปถึง 97~98% แต่หลังจากนั้นไม่ขยับต่อ
อยากรู้ว่ามันทำงานบน Windows ที่ใช้ Firefox 141 ได้ไหม
ถ้าไม่ได้ อยากรู้ว่าเพราะอะไร
บน Google Chrome สำหรับ macOS ลิงก์แรกค้างที่ 0% และไม่ขยับ
เดโมที่สองค้างที่ 98% หรือ 97%
บน Safari ก็เป็นอาการเดียวกัน
ถ้ามองสถานการณ์ของกราฟิกส์ API ตอนนี้ รู้สึกเหมือนถอยหลังยิ่งกว่ายุค OpenGL เสียอีก
API ยุคใหม่ดูเหมือนไม่ได้ให้ทั้งความง่ายในการใช้งานและความ portable หรือ cross-platform ที่แท้จริง
การต้องสร้าง wrapper แบบคัสตอมให้กับกราฟิกส์แบ็กเอนด์หลายแบบอย่าง Vulkan, Metal, DirectX12 แทบจะเป็นการเสียเวลาเปล่า
มันให้ความรู้สึกคล้ายกับการย้อนกลับไปใช้ char array แทน string เพื่อแลกกับประสิทธิภาพ
ไม่รู้เหมือนกันว่ามีใครเคยให้สัญญาอะไรไว้ หรือใครเป็นคนให้สัญญานั้น
จุดประสงค์ของกราฟิกส์ API ก็คือส่งโค้ดกับข้อมูลเข้า GPU ให้เร็วที่สุด ไม่ใช่ให้ความสำคัญกับประสบการณ์นักพัฒนาเป็นอันดับแรก
สำหรับ WebGPU ฉันรู้สึกว่ามันห่อ compute และ render ในเบราว์เซอร์ได้ค่อนข้างดี
แม้ยังไม่สมบูรณ์ แต่คิดว่ามันใช้งานเข้าใจง่ายและสำรวจได้ดีกว่า WebGL หรือ OpenGL
ผมไม่ค่อยเห็นว่าปัญหาอยู่ตรงไหน
ในสแต็กกราฟิกส์มี low-level API มานานมากแล้ว (เช่น Gallium ของ Mesa) และตอนนี้ก็แค่ถูกทำให้เป็นมาตรฐานและให้ผู้ใช้เลือกใช้เอง
high-level API ก็ยังมีอยู่ และ OpenGL ก็ยังรองรับบนแพลตฟอร์มที่สมเหตุสมผล
WebGPU เองก็ใช้งานได้ค่อนข้างดีใน native code
การที่ low-level API พกพาข้ามแพลตฟอร์มได้ไม่ดีจริง ๆ แทบทั้งหมดเป็นเพราะ Apple กับผู้ผลิตคอนโซล
แต่กับผู้ผลิตคอนโซล เดิมทีก็ไม่เคยคาดหวังความร่วมมืออยู่แล้ว
บทเรียนจากยุค OpenGL คือ ต่อให้ทุกแพลตฟอร์มใช้ high-level API เดียวกัน ก็ไม่ได้แปลว่าจะได้ผลลัพธ์ที่ดีเสมอไป
สุดท้ายสิ่งสำคัญคือมี API ที่ควบคุมฮาร์ดแวร์ของแพลตฟอร์มนั้นได้ดีหรือไม่
เราจำเป็นต้องมี wrapper ที่แปล OpenGL อยู่เสมอ และในอดีตก็ไม่มีทางหลีกเลี่ยง wrapper แบบนี้ได้
วิธีที่ให้ผลดีที่สุดแยกตามฮาร์ดแวร์แต่ละประเภทนั้นใช้งานจริงได้ไม่ดีนัก
สิ่งที่สำคัญจริง ๆ คือมี translation layer ที่ทำได้ง่ายหรือไม่
ถ้าอยากเข้าถึงฮาร์ดแวร์แบบลึกจริง ๆ ก็ยิ่งต้องการ API ที่เข้าถึงฮาร์ดแวร์ได้โดยตรง มากกว่าจะใช้อินเทอร์เฟซที่เรียบง่ายหรือเป็นแบบทั่วไป
OpenGL หลัง 2.0 ทำให้ API ซับซ้อนเกินไป และ WebGPU ก็กำลังห่อความสามารถของ Vk, D3D12, Metal ได้ค่อนข้างสะดวก
ผมคิดว่ามันออกแบบมาดีกว่า OpenGL มาก
อีกอย่าง D3D11 กับ Metalv1 น่าจะเป็นจุดสมดุลที่เหมาะที่สุดทั้งด้านการใช้งานและประสิทธิภาพ (โดยเฉพาะประสิทธิภาพของ D3D11 ที่แม้แต่ Vulkan, D3D12 ก็ยังตามให้ทันได้ยาก)
ฉันก็เห็นด้วย
ฉันจะพัฒนาต่อไปด้วย OpenGL และ CUDA interop
Vulkan ซับซ้อนเกินความจำเป็นมาก แต่ไม่ได้ให้ประโยชน์จริงในการใช้งาน เลยสุดท้ายกลับไปใช้ CUDA แทน
ยังหวังว่า WebGPU จะขยายออกนอกเบราว์เซอร์ได้สำเร็จ
และกลายเป็น API แบบ cross-platform ที่ใช้งานง่ายซึ่งอยู่ในสเปกทางการ (พูดอีกแบบคือเป็นตัวแทนของ opengl)
แต่ยกเว้นฝั่ง Rust แล้ว ก็ไม่ค่อยรู้สึกว่ามีกระแสใช้ WebGPU ใน native code มากนัก
เช่น ไม่เคยได้ยินว่ามีโปรเจ็กต์ใหญ่ไหนใช้ Dawn
ส่วนหนึ่งอาจเป็นเพราะ WebGPU มาช้าเกินไป จนคนส่วนใหญ่สร้าง abstraction layer ของตัวเองบน dx, vulkan, metal ไปหมดแล้ว
สุดท้ายผมคิดว่ามันคงไม่แพร่หลาย
มันมีความเรียบง่ายอยู่บ้าง แต่ก็ขาดความสามารถไปมาก
ฟีเจอร์บางอย่างที่เป็น optional ใน Vulkan (เช่น render pass) ยังเป็นสิ่งบังคับใน WebGPU
bind group ก็เป็นแบบ static เลยไม่ค่อยสะดวก
แถม WebGPU ยังมีข้อจำกัดและองค์ประกอบที่ไม่จำเป็นหลายอย่าง
ตัวอย่างเช่น ไม่สามารถเขียนตรงเข้า buffer subregion จากโฮสต์ได้ และต้องใช้ buffer กลาง (staging buffer) เสมอ
ถ้าไม่มีทางเลือกก็คงใช้บนเว็บ แต่บนเดสก์ท็อปผมจะใช้เฟรมเวิร์ก OpenGL+CUDA interop ต่อไป
ผมหวังว่าจะมีกราฟิกส์ API สมัยใหม่ที่สมเหตุสมผลกว่านี้ออกมา
ถ้างานที่ควรจบได้ง่าย ๆ ด้วย cuMemAlloc, cuMemcpy กลับต้องซับซ้อนด้วยการจัดสรรและ bind buffer ที่ยุ่งยาก, pipeline, explicit sync, binding group, descriptor set และองค์ประกอบไร้ประโยชน์อื่น ๆ แบบนี้ ผมก็ไม่อยากใช้
WebGPU ไม่ได้ให้ทั้งการ optimize และการควบคุมละเอียดระดับ Vulkan และโดยทั่วไปประสิทธิภาพก็สู้ Vulkan ไม่ได้
extension ต่าง ๆ ที่มีใน Vulkan ก็ยังไม่รองรับใน WebGPU เช่นกัน
มีมิดเดิลแวร์ที่มีอยู่แล้ว
นอกเบราว์เซอร์ ผมไม่คิดว่าจำเป็นต้องรอ WebGPU
เพราะ API ที่ออกแบบโดยโฟกัสกับ browser sandbox ตั้งแต่แรก ย่อมมีข้อจำกัดติดมาด้วย
ผมคิดว่าชื่อก็เป็นปัญหาใหญ่เหมือนกัน
ผมเป็นนักพัฒนา native ล้วน ๆ เลยเข้าใจมาตลอดหลายปีว่า "web gpu" เป็นเทคโนโลยีสำหรับเว็บเท่านั้น เลยไม่สนใจ
แต่พอไปดูจริง ๆ กลับพบว่าเข้าใจผิด
ดีใจมากที่ crate ของเรา gpu-allocator https://github.com/Traverse-Research/gpu-allocator/ น่าจะเป็นที่รู้จักในวงกว้างมากขึ้น
ก่อนหน้านี้มันถูกใช้กับ dx12 backend ของ wgpu หรือไม่ก็ในผลิตภัณฑ์ gpu benchmark ของเราอย่าง evolve https://www.evolvebenchmark.com/
ต่อจากนี้ก็น่าจะถูกใช้งานได้กว้างขึ้นอีก
เพิ่งรู้ตอนนี้เองว่าใช้ WebGPU บน Firefox Nightly สำหรับ macOS ได้แล้ว
ผมโหลด nightly สำหรับ Mac จาก https://www.mozilla.org/en-US/firefox/channel/desktop/
แล้วลองรันเดโม https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu ซึ่งทำงานได้ดี
เดโมนี้ใช้โมเดล SmolLM2 ที่คอมไพล์เป็น WebAssembly เพื่อดึงข้อมูลแบบมีโครงสร้าง
ก่อนหน้านี้ผมคิดว่ามันทำงานได้แค่บน Chrome แต่บน Firefox รุ่นปกติ (Stable) ขึ้น error ว่า "WebGPU ไม่รองรับ"
การรองรับ macOS จะเปิดใช้อย่างเป็นทางการเร็ว ๆ นี้
นอกจาก Windows แล้ว เรามีแผนรองรับ WebGPU บน Mac, Linux และสุดท้าย Android ในเร็ว ๆ นี้ด้วย
รู้สึกดีที่ได้ยินว่า "มีแผนรองรับ WebGPU บน Mac, Linux และสุดท้าย Android"
แต่ ณ ตอนนี้ยังยากจะคาดหวังมากนัก
ผมคิดว่าเหตุผลที่การรองรับ WebGPU บนเบราว์เซอร์ Linux ยังทำไม่ได้มาตลอด น่าจะเป็นเพราะการสร้าง attack surface ใหม่เป็นเรื่องยากเกินไป
ความซับซ้อนแบบนี้เองที่สะท้อนให้เห็นถึงขนาดมหึมาของมาตรฐานเว็บซึ่งทำให้การพัฒนาเบราว์เซอร์ยากลำบาก
อิทธิพลจากการตัดสินใจออกแบบที่สืบทอดมาตั้งแต่ยุค Netscape ดูจะยังคงอยู่จนถึงตอนนี้ และเป็นรากของความกังวลเรื่องการรวมศูนย์ของเว็บเบราว์เซอร์ ปัญหาด้านเงินทุน และอื่น ๆ
บน Android/Linux, WebOS/Linux, ChromeOS/Linux ตอนนี้ก็รองรับ WebGPU อยู่แล้ว
แต่นี่ก็เป็นหลักฐานเหมือนกันว่า สำหรับ GNU/Linux แล้ว การรองรับเวิร์กโหลดแบบนี้ไม่ได้อยู่ในลำดับความสำคัญสูงของผู้พัฒนาเบราว์เซอร์
กำลังรอ implementation สำหรับ Linux อยู่เหมือนกัน
อยากรู้ว่ามีเดโมอะไรที่น่าลองบ้างเมื่อ WebGPU มาแล้ว
เดโมที่น่าประทับใจที่สุดตัวหนึ่งคือ
https://github.com/ArthurBrussee/brush
เป็นการเทรนและเรนเดอร์ Gaussian splatting ที่ใช้ WebGPU
ขอแนะนำเดโมที่ทำด้วย Unity ด้วย
เดโมส่วนใหญ่จะอยู่ในรูปแบบเว็บเดโม
ส่วนตัวผมชอบ Compute Toys https://compute.toys/
มันทำให้ทดลอง WebGPU compute shader ได้ในสไตล์ Shadertoy
ถ้าอยากดูเดโมเพิ่มก็มี https://github.com/mikbry/awesome-webgpu
หรือโปรเจ็กต์ทดลองด้วยตัวเองอย่าง https://github.com/s-macke/WebGPU-Lab ก็มี
ตัวอย่างของเอนจิน Bevy ก็มีทั้ง WebGL และ WebGPU ให้ดู
เหมาะกับการเรียนรู้แบบเปรียบเทียบ
ลิงก์อ้างอิง: https://bevy.org/examples-webgpu/, https://bevy.org/examples
อีกเดโมที่ผมว่าเจ๋งมากคือ https://huggingface.co/spaces/webml-community/kokoro-webgpu
ถึงไม่มี WebGPU ก็ยังทำงานได้ แต่จะช้ามาก
ดูเหมือน Firefox จะรองรับ WebGPU บน Linux ได้ก่อน Chrome
ทั้งที่ dawn (implementation ของ webgpu จาก Google) บน Linux ก็ทำงานได้ค่อนข้างดี แต่กลับเป็น Firefox ที่รองรับก่อน
ในที่สุด WebGPU ก็เริ่มได้รับการรองรับแล้ว ขอปรบมือให้ทุกคน
ก่อนหน้านี้รู้สึกคาใจนิดหน่อยที่ต้องทดลองกับ WebGPU บน Chrome อย่างเดียว
ส่วน Safari เองก็เริ่มรองรับในเวอร์ชันพรีวิวล่าสุดเหมือนกัน
ฉันใช้ wgpu ในโปรเจ็กต์หลักมาเกือบ 2 ปีแล้ว
หวังว่าการขยายตัวของ WebGPU ครั้งนี้จะทำให้มีผู้ดูแลเพิ่มขึ้น
และ issue ที่เปิดไว้ตั้งแต่ 18 เดือนก่อนจะได้รับการแก้ไขเร็วขึ้น
ฉันยังไม่ได้เริ่มใช้ Rust แต่ก็หวังว่าสักวันจะมีทั้งแรงจูงใจและเวลาพอที่จะช่วย contribute ด้วยตัวเอง
ตอนนี้พึ่งพา binding ของ wgpu-native อยู่ ซึ่งการอัปเดตมาถึงช้า
เช่น สัปดาห์ก่อนเพิ่งได้ใช้ v25 แต่ไม่กี่วันก่อนก็มี v26 ออกมาแล้ว