WebGPU là chuẩn API đồ hoạ thế hệ mới của web, cho phép JavaScript giao tiếp trực tiếp với GPU của thiết bị ở mức thấp, hiệu năng gần native. Khác với WebGL chỉ vẽ hình lên canvas, WebGPU hỗ trợ cả tính toán song song (GPGPU), mở đường cho các ứng dụng nặng chạy ngay trong trình duyệt mà không cần plugin hay phần mềm riêng.
Bài viết này giải thích vì sao WebGL cần được thay thế, kiến trúc phân tầng của WebGPU, cách xin GPU adapter và device, khác biệt giữa render pipeline và compute pipeline, cùng trạng thái hỗ trợ thực tế trên trình duyệt.
WebGL đã hỏng ở đâu?
WebGL xuất hiện quanh năm 2011, là bản JavaScript port của OpenGL ES 2.0. Nó cho phép trang web đẩy phép tính render xuống GPU ở tốc độ cao, mở ra kỷ nguyên game 3D, video nhạc và công cụ mô hình trực tiếp trên web. Nhờ đó, ba thư viện lớn ra đời: Three.js, Babylon.js và PlayCanvas.
Nhưng WebGL dính ba vấn đề cấu trúc không thể vá bằng bản vá:
- Đã đến hạn API nền tảng. Trong khi thế giới native chuyển sang Direct3D 12, Metal và Vulkan, OpenGL không còn được cập nhật tính năng. WebGL không thể hưởng lợi từ compute shader, binding thân thiện hơn với GPU hiện đại hay các tiến bộ về hiệu năng driver.
- Không phải API tính toán. Toàn bộ thiết kế xoay quanh vẽ hình vào canvas. Khi cần chạy mô hình học máy trong trình duyệt, WebGL trở nên nặng nề và khó tối ưu.
- Tải đồ hoạ ngày càng nặng. Số lượng vật thể cần render đồng thời và các tính năng render mới đều tăng nhanh, trong khi chi phí quản lý phía CPU của WebGL tăng theo.
WebGPU ra đời để sửa trọn vẹn cả ba điểm.
Kiến trúc phân tầng của WebGPU
Giữa GPU vật lý và trang web có nhiều lớp trừu tượng. Hiểu rõ các lớp này giúp bạn biết mình đang nói chuyện với ai khi code.
GPU vật lý
Thiết bị có một hoặc nhiều GPU. Có ba loại phổ biến: GPU tích hợp nằm chung bo mạch với CPU và dùng chung bộ nhớ, GPU rời nằm trên bo riêng, và GPU phần mềm chạy hoàn toàn trên CPU.
API GPU native và driver
Mỗi hệ điều hành có API riêng để ứng dụng native dùng GPU, ví dụ Metal trên macOS hay Vulkan trên Android và Linux. Lệnh được gửi xuống GPU qua driver, và phản hồi quay lại theo chiều ngược lại.
WebGPU adapter
Bản triển khai WebGPU trong trình duyệt giao tiếp với GPU thông qua driver native. Một adapter hiện diện cho một GPU vật lý cùng driver tương ứng trên hệ thống. Trong code, adapter là hình ảnh đại diện cho GPU mà trình duyệt cho phép bạn dùng.
GPUDevice
Device là lớp trừu tượng để một ứng dụng web truy cập năng lực GPU trong vùng cách ly riêng. Cần lớp này vì GPU vật lý phục vụ nhiều ứng dụng và tiến trình cùng lúc, mỗi ứng dụng phải được cô lập về mặt bảo mật và logic.
Xin adapter và device
Quy trình gồm ba bước: lấy đối tượng GPU qua Navigator.gpu (hoặc WorkerNavigator.gpu nếu chạy trong worker), xin adapter bằng requestAdapter(), rồi xin device bằng adapter.requestDevice().
async function getGPU() {
if (!navigator.gpu) {
throw new Error("Trinh duyet khong ho tro WebGPU");
}
const adapter = await navigator.gpu.requestAdapter();
if (!adapter) {
throw new Error("Khong tim thay GPU adapter phu hop");
}
return await adapter.requestDevice();
}Cả hai lời gọi đều nhận đối tượng tùy chọn. Với adapter, bạn có thể yêu cầu chế độ tương thích, adapter hiệu năng cao hoặc tiết kiệm năng lượng. Với device, descriptor cho phép chỉ định chính xác các tính năng và giới hạn mà bạn muốn. Nếu bỏ qua cả hai, bạn vẫn nhận được cấu hình mặc định hợp lý cho đa số ứng dụng.
Chế độ tương thích
Mặc định, adapter hỗ trợ toàn bộ tính năng và giới hạn cốt lõi của WebGPU, tức “core WebGPU”. Ngoài ra còn có chế độ tương thích, cho phép chạy trên các API đồ hoạ cũ hơn như OpenGL ES 3.1 và Direct3D 11. Bật bằng cách truyền featureLevel: "compatibility" vào requestAdapter().
Ứng dụng chạy ở chế độ tương thích vẫn là ứng dụng WebGPU hợp lệ vì nó hỗ trợ một tập con của core, nên vẫn chạy trên mọi trình duyệt hỗ trợ WebGPU. Muốn biết mình đang ở chế độ nào, kiểm tra xem tính năng core-features-and-limits có tồn tại hay không.
Hai loại pipeline trong WebGPU
Render pipeline
Render pipeline vẽ đồ hoạ, thường vào một phần tử <canvas> nhưng cũng có thể render ra ngoài màn hình. Nó có hai giai đoạn chính:
- Vertex stage: vertex shader nhận dữ liệu vị trí, áp dụng phép xoay, tịnh tiến hay phối cảnh để định vị các đỉnh trong không gian 3D. Các đỉnh được ghép thành hình cơ bản như tam giác, rồi GPU rasterize để xác định pixel nào thuộc về hình đó.
- Fragment stage: fragment shader chạy cho từng pixel, quyết định màu sắc cuối cùng dựa trên dữ liệu vị trí, texture, ánh sáng và các biến nội suy.
Điểm khác biệt quan trọng so với WebGL là phần lớn công việc chuẩn bị, như loại bỏ đối tượng bị che khuất hay biến đổi mô hình có xương (skinned mesh), chuyển sang chạy trực tiếp trên GPU thay vì trên CPU. Kết quả là chi phí CPU cho mỗi vật thể giảm đáng kể, và giải pháp hậu kỳ như bloom, tô màu, làm nét, mô phỏng độ sâu trường ảnh trở nên rẻ hơn nhiều.
Compute pipeline
Compute pipeline dành cho tính toán song song thuần túy, không vẽ gì cả. Đây là phần đáp ứng trực tiếp nhu cầu GPGPU trong trình duyệt: chạy mô hình học máy, mô phỏng vật lý, xử lý hình ảnh hoặc giải bài toán khoa học ngay trên máy người dùng mà không cần gửi dữ liệu lên server.
Nhờ đó, các ứng dụng từng bắt buộc cài phần mềm riêng bắt đầu chuyển sang phiên bản web: phần mềm chỉnh sửa video, trình xem phần mềm 3D, hay các công cụ mô phỏng kỹ thuật.
WGSL: ngôn ngữ shader của WebGPU
WebGPU dùng WGSL thay cho GLSL của WebGL. WGSL là ngôn ngữ kiểu tĩnh, có kiểu an toàn, cấu trúc cú pháp gần với Rust, với hỗ trợ song song ở mức ngôn ngữ. Điểm khác biệt nổi bật: WGSL phân biệt rõ kiểu số như f32 và i32, ép buộc khai báo kiểu tường minh, và không có trạng thái ẩn của GLSL.
Đổi lại, shader của bạn được biên dịch sẵn và kiểm tra kiểu trước khi chạy, giúp phát hiện lỗi sớm hơn nhiều so với shader GLSL thường chỉ lộ lỗi khi hiển thị lên màn hình.
Trạng thái hỗ trợ thực tế
WebGPU đã được triển khai trên các trình duyệt lớn trên máy tính và di động. Điểm cần lưu ý là khác biệt giữa bản desktop và bản di động, cùng yêu cầu phần cứng không quá cũ. Với người dùng còn dùng trình duyệt cũ hoặc thiết bị yếu, bạn vẫn nên giữ một nhánh fallback về WebGL.
Cách kiểm tra nhanh nhất trước khi khởi tạo:
if ("gpu" in navigator) {
// thuong co the dung WebGPU
} else {
// fallback ve WebGL hoac thong bao khong ho tro
}Tham khảo tài liệu đầy đủ của MDN tại WebGPU API trên MDN Web Docs. Khuyến nghị thực tế từ MDN: chỉ bật chế độ tương thích khi thật sự cần, vì chế độ này giới hạn tính năng và có thể khiến hiệu năng thấp hơn trên phần cứng mạnh.
WebGPU có thay thế WebGL không?
Không phải ngay lập tức. WebGL vẫn có độ phủ trình duyệt rộng hơn, đặc biệt trên thiết bị di động cũ và các môi trường nhúng. Chiến lược hợp lý cho tới khi WebGPU phủ rộng: dùng WebGPU khi có, WebGL khi không, thông qua thư viện trừu tượng như Three.js đã hỗ trợ cả hai backend.
Với ứng dụng mới, WebGPU là lựa chọn mặc định hợp lý: hiệu năng cao hơn, compute shader có sẵn, và API còn được tiếp tục phát triển thêm trong khi WebGL đã đứng yên. Lịch sử lặp lại với WebAssembly: ngôn ngữ mới đến muộn hơn, nhưng khi đến thì thay thế hẳn tiền nhiệm.
