- Trình bày một cách tiếp cận tận dụng cấu trúc sparse strip để tăng hiệu quả trong kết xuất đồ họa 2D dựa trên CPU
- Nghiên cứu tập trung vào cấu trúc dữ liệu và phương thức xử lý nhằm hiện thực hóa kết xuất hiệu năng cao trên CPU thay vì GPU
- Thông qua biểu diễn dữ liệu thưa, giảm mức sử dụng bộ nhớ và vẫn đảm bảo tốc độ kết xuất nhanh ngay cả với các cảnh phức tạp
- Thiết kế này cải thiện hiệu quả xử lý song song và khả năng tận dụng cache so với các phương pháp kết xuất CPU truyền thống
- Nghiên cứu cho thấy khả năng tạo ra đồ họa 2D chất lượng cao chỉ với CPU
Tổng quan nghiên cứu
- Bài luận văn này hướng tới kết xuất đồ họa 2D hiệu năng cao trên CPU, đồng thời khám phá cách giảm sự phụ thuộc vào GPU
- Khái niệm cốt lõi là cấu trúc dữ liệu sparse strip, lưu trữ hiệu quả chỉ những phần cần thiết thay vì dữ liệu liên tục ở cấp độ pixel
- Nhờ cấu trúc này, có thể đạt được giảm chi phí truy cập bộ nhớ và tăng tốc độ kết xuất
Cấu trúc sparse strip
- Strip biểu thị một đoạn pixel liên tiếp của ảnh 2D, và ở dạng sparse chỉ lưu những phần cần thiết
- Cách làm này đặc biệt hiệu quả với hình ảnh có nhiều vùng trống hoặc đồ họa vector phức tạp
- So với kết xuất dựa trên buffer toàn phần truyền thống, nó giúp giảm mức dùng bộ nhớ và tăng hiệu quả cache
Hiệu năng và triển khai
- Tận dụng lệnh SIMD và đa luồng của CPU để tối đa hóa hiệu năng xử lý song song
- Kết quả thử nghiệm cho thấy cùng một cảnh có thể được xử lý ở mức hiệu năng đủ cho kết xuất thời gian thực ngay cả khi không dùng GPU
- Phần triển khai được viết trên nền C++, và đã được thử nghiệm ở nhiều độ phân giải cũng như mức độ phức tạp của cảnh khác nhau
Khả năng ứng dụng
- Có thể ứng dụng trong các môi trường lấy CPU làm trung tâm như kết xuất UI, engine đồ họa vector, pipeline 2D của game engine
- Cũng có thể hỗ trợ xử lý đồ họa 2D hiệu năng cao trong các hệ thống nhúng hoặc môi trường máy chủ nơi GPU bị hạn chế
Kết luận
- Cách tiếp cận dựa trên sparse strip chứng minh khả năng giảm nút thắt cổ chai của kết xuất CPU và cải thiện hiệu quả bộ nhớ
- Nó cho thấy tiềm năng như một mô hình thay thế cho kiến trúc xử lý đồ họa phụ thuộc vào GPU
- Các số liệu hoặc dữ liệu so sánh bổ sung trong bản gốc cần được xem trực tiếp trong PDF
1 bình luận
Ý kiến trên Hacker News
Cấu trúc
struct Stripđược định nghĩa trong bài báo trông có kích thước 64 bit (8 byte), nhưng trong phần nội dung lại ghi rằng một strip là 64 byteTính ra thì thực tế có vẻ là khoảng 259×8 + 7296 ≈ 9KB. Có lẽ đơn vị nào đó đã bị ghi sai
Có thể chỉ là lỗi gõ đơn giản, nhưng cũng có khả năng mỗi strip được cấp phát theo đơn vị cache line (64 byte).
Nếu vậy thì có thể tránh false sharing, nên renderer có lẽ đã cố ý làm như thế
Bài báo chủ yếu tập trung vào so sánh thời gian chạy, còn không bàn đến so sánh dung lượng lưu trữ
Cũng nên xem thêm Blaze: Parallel Rasterization on CPU
Dự án này rất thú vị. Xem mục 3.9 thì đầu ra ở dạng bitmap, nên cuối cùng có lẽ vẫn phải chép hình ảnh sang GPU
Skia đang chuyển sang WebGPU, và WebGPU hỗ trợ compute shader, nên 2D graphics ngày càng có vẻ là bài toán đã được giải quyết về mặt tính di động và hiệu năng
Tuy vậy, vẫn có những trường hợp CPU renderer còn hữu ích — ví dụ trong môi trường web, shader phải được biên dịch ở runtime khi tải trang
Về lý thuyết, cũng có thể làm kiểu giống JS JIT: khởi đầu bằng CPU renderer rồi chuyển sang GPU khi shader đã sẵn sàng
Một lợi điểm nữa là kích thước binary nhỏ. WebGPU (dựa trên dawn) khá lớn
Liên kết tham khảo
Trong dự án lớn hơn còn có một phiên bản tên là Vello Hybrid, xử lý hình học trên CPU và phần tô pixel trên GPU
Ý tưởng dùng CPU renderer trong lúc biên dịch shader cũng đã được cân nhắc, nhưng chưa được triển khai
Ngược lại, nếu render trên GPU thì lại phải chép ảnh ngược ra, nên kém hiệu quả hơn
Gần đây tôi đã viết mã để render quỹ đạo N-body độ chính xác cao với hàng triệu đỉnh,
nên tôi tự hỏi liệu cách biểu diễn RLE được đề xuất trong bài báo này có hoạt động tốt trên GPU mà vẫn giữ được sự đơn giản hay không
Video demo
Thú vị đấy. Tôi muốn xem hiệu năng đơn nhân của các renderer được đem ra so sánh.
Điều đó có lẽ sẽ cho thấy hiệu quả của mã. Các renderer phổ biến có thể chậm hơn về tốc độ nhưng lại dùng ít CPU hơn
Ngoài ra cũng có thể xem kết quả ở benchmark chính thức của Blend2D hoặc
vello_chart do tôi làm, có bổ sung thêm các renderer khác
Không biết có phải một trong các giáo sư hướng dẫn, Raph Levien, chính là tác giả của thư viện Libart trước đây không?
Hơi lạc đề một chút, nhưng tôi tò mò không biết từ khi nào xem trước PDF trên GitHub lại chỉ tải một số trang
Tôi vẫn nghĩ cách cũ là tải toàn bộ PDF một lần rồi để trình duyệt render sẽ tốt hơn
Tôi muốn biết có benchmark nào để kiểm chứng độ đúng (correctness) của renderer hay không
Cách làm là đo radiosity của cảnh thật rồi so sánh với kết quả mô phỏng
Trong render thời gian thực, đôi khi người ta cũng so sánh với các renderer offline như Arnold hoặc Octane làm chuẩn
Wiki Cornell box
Không có renderer nào tái hiện thực tại một cách hoàn hảo, tất cả đều phải chấp nhận một mức đánh đổi nhất định