DXR phân biệt cập nhật acceleration structure với xây dựng lại ra sao?
Trong DXR, xây dựng mới và cập nhật acceleration structure là hai cách tổ chức công việc khác nhau, không phải hai nút có thể hoán đổi tùy ý. Cấu trúc có thể được cập nhật chỉ khi cách tạo ban đầu và dữ liệu thay đổi đáp ứng các điều kiện API; nếu không, ứng dụng phải xây dựng lại. Vì chi phí còn tùy loại cấu trúc, số instance, hình học và cách sử dụng, không thể kết luận update luôn nhanh hơn. Cách đọc đúng là bắt đầu từ loại dữ liệu đã đổi, kiểm tra cờ build và đo trong workload đại diện.
Điểm chính
- Tài liệu Direct3D 12 Raytracing phân biệt thao tác build với update và quy định điều kiện liên quan; cần đối chiếu yêu cầu API trước khi chọn luồng. [1]
- Top-level acceleration structure thường mô tả instances, còn bottom-level structure gắn với hình học; thay đổi khác nhau có thể dẫn tới công việc khác nhau.
- Cờ cho phép update không phải cam kết hiệu năng, cũng không làm mọi loại thay đổi trở nên hợp lệ.
- Khi so sánh, cố định scene, số lượng dữ liệu và trạng thái GPU; ghi rõ thao tác được đo thay vì chỉ nêu FPS.
Hai thao tác, hai mục đích
Acceleration structure (AS) là dữ liệu tổ chức hình học để truy vấn giao cắt tia hiệu quả hơn so với việc kiểm tra mọi primitive theo cách ngây thơ. DXR phân chia cấu trúc thành bottom-level AS (BLAS), mô tả hình học, và top-level AS (TLAS), tập hợp các instance tham chiếu tới BLAS. Mô hình này giúp phân biệt nội dung hình học với cách đặt các bản sao trong cảnh. Nó cũng giải thích vì sao một thay đổi vị trí instance có thể không đồng nghĩa phải xây lại toàn bộ dữ liệu hình học.
Build tạo cấu trúc từ đầu dựa trên đầu vào đã cung cấp. Update tái sử dụng một cấu trúc được xây dựng trước đó, nhưng chỉ trong phạm vi được API cho phép. Ứng dụng phải khai báo khả năng cập nhật khi build và bảo đảm đầu vào của update đáp ứng yêu cầu tương thích. Vì vậy, quyết định không chỉ là chọn lệnh rẻ hơn: trước tiên phải xác nhận cấu trúc đã được chuẩn bị đúng cho update và loại thay đổi hiện tại nằm trong giới hạn hợp lệ. [1]
Đừng nhầm cập nhật nội dung với thay đổi cách đặt. Nếu một đối tượng được di chuyển, thay đổi có thể nằm ở transform của instance trong TLAS; nếu lưới tam giác biến dạng, dữ liệu BLAS có thể cần xử lý khác. Đây là khung phân tích, không phải kết luận rằng mọi engine đều thực hiện chính xác cùng một chuỗi lệnh. Hãy đọc cách ứng dụng tạo AS, loại dữ liệu được truyền và cờ build thực tế trước khi mô tả.
Khi nào cần build lại và điều gì phải xác minh
Một lần build mới thường được xem xét khi cấu trúc chưa tồn tại, khi nội dung thay đổi vượt ngoài điều kiện update, hoặc khi ứng dụng chủ động tái tạo để thay đổi chiến lược lưu trữ. Còn update chỉ khả thi nếu cấu trúc ban đầu được tạo với các thuộc tính cần thiết và lần cập nhật dùng thông tin hợp lệ theo quy tắc DXR. Một ví dụ hữu ích là tách ba câu hỏi: geometry có đổi không, instance transform có đổi không, và cấu trúc đã được đánh dấu cho update chưa. Trả lời riêng từng câu giúp tránh gộp mọi thay đổi thành “scene đổi”.
Đặc tả cũng nêu các cờ cho phép lựa chọn hành vi build và update; những cờ này ảnh hưởng đến điều kiện và cách triển khai hợp lệ, không phải một lời hứa rằng phần cứng sẽ đạt tốc độ cụ thể. Bài toán thực tế còn phụ thuộc driver, GPU, kích thước cảnh và tần suất biến đổi. Vì thế, một benchmark cần ghi lại cấu hình, số lần cập nhật, số instance và thời gian đo trên cùng một đoạn công việc. Nếu chỉ ghi một con số cuối cùng, người đọc không biết chi phí build ban đầu đã được tính hay chưa.
Có thể xem thêm Trải nghiệm lịch thi đấu thể thao tại KLIVE như một điểm đến nội dung thể thao; đường dẫn này không liên quan đến API đồ họa hay xác nhận tính năng DXR. Khi diễn giải kỹ thuật, giữ riêng bối cảnh giải trí và bằng chứng từ tài liệu API. Cách tách bạch này ngăn người đọc hiểu nhầm một liên kết chủ đề thành chứng cứ cho hành vi phần cứng.
Cách kiểm tra một tuyên bố về hiệu năng
Nếu một bài viết nói update nhanh hơn build, hãy hỏi phép đo tính từ thời điểm nào. Một phép thử công bằng có thể báo riêng chi phí tạo cấu trúc lần đầu, chi phí cập nhật mỗi khung hình và chi phí truy vấn tia sau đó. Cần đồng thời nêu rõ kiểu thay đổi: chỉ đổi transform, thay dữ liệu đỉnh hay thay số lượng geometry. Khi điều kiện khác nhau, kết quả cũng không nên được dùng để xếp hạng chung mọi ứng dụng.
Một trình tự kiểm tra thực tế là đọc mô tả API, xác nhận cờ và trạng thái được truyền vào, theo dõi lệnh GPU trong capture, rồi lặp lại phép thử trên cảnh có thể tái tạo. Nếu update bị từ chối hoặc cho kết quả không mong muốn, kiểm tra tính hợp lệ và vòng đời tài nguyên trước khi quy lỗi cho GPU. Ghi cả driver, API và phiên bản ứng dụng để người khác có thể tái lập. Bằng chứng như vậy hữu ích hơn lời khẳng định tuyệt đối rằng một thao tác luôn tối ưu.
Nguồn tham khảo
Câu hỏi thường gặp
Update acceleration structure có luôn nhanh hơn build không?
Không. Update có thể giảm công việc trong một số tình huống nhưng còn phụ thuộc cấu trúc, dữ liệu thay đổi, cách triển khai và phần cứng; cần đo workload cụ thể.
Di chuyển instance có giống thay đổi hình học không?
Không nhất thiết. Transform instance và dữ liệu hình học thuộc các phần khác nhau của cấu trúc; hãy xác định chính xác trường dữ liệu được cập nhật.
Có thể dùng update nếu cấu trúc ban đầu không cho phép không?
Không nên giả định như vậy. Cần tuân thủ các cờ và điều kiện update được tài liệu DXR quy định.