Có bao nhiêu đa giác trong một cảnh có thể đạt được phần cứng hiện đại trong khi duy trì thời gian thực và làm thế nào để đến đó?

Một câu hỏi khá cơ bản, theo một số cách, nhưng một câu hỏi mà nhiều người, bao gồm cả tôi, không thực sự biết câu trả lời. Các nhà sản xuất GPU thường trích dẫn số lượng rất cao và sự chênh lệch giữa số lượng đa giác mà các công cụ trò chơi khác nhau tuyên bố hỗ trợ thường kéo dài nhiều đơn đặt hàng độ lớn, và sau đó vẫn phụ thuộc rất nhiều vào nhiều biến số.

Tôi biết rằng đây là một câu hỏi mở rộng, khá nhiều câu hỏi mở và tôi xin lỗi vì điều đó, tôi chỉ nghĩ rằng đó sẽ là một câu hỏi có giá trị ở đây.

Tôi nghĩ người ta thường chấp nhận rằng thời gian thực là tất cả mọi thứ nằm trên mức tương tác. Và tương tác được định nghĩa là "phản hồi đầu vào nhưng không mượt mà trong thực tế là hoạt hình có vẻ lởm chởm".
Vì vậy, thời gian thực sẽ phụ thuộc vào tốc độ của các chuyển động mà người ta cần đại diện. Các dự án điện ảnh ở 24 FPS và đủ thời gian thực cho nhiều trường hợp.

Sau đó, có bao nhiêu đa giác mà một máy có thể xử lý dễ dàng kiểm chứng bằng cách tự kiểm tra. Chỉ cần tạo một bản vá VBO nhỏ như một thử nghiệm đơn giản và bộ đếm FPS, nhiều mẫu DirectX hoặc OpenGL sẽ cung cấp cho bạn giường thử nghiệm hoàn hảo cho điểm chuẩn này.

Bạn sẽ tìm thấy nếu bạn có một card đồ họa cao cấp mà bạn có thể hiển thị khoảng 1 triệu đa giác trong thời gian thực. Tuy nhiên, như bạn đã nói, các công cụ sẽ không yêu cầu hỗ trợ dễ dàng như vậy vì dữ liệu cảnh trong thế giới thực sẽ gây ra một số lượng hiệu suất không liên quan đến số lượng đa giác.

Bạn có:

• tỷ lệ lấp đầy
  • lấy mẫu kết cấu
  • Đầu ra ROP
• thực hiện cuộc gọi
• kết xuất chuyển mạch mục tiêu
• cập nhật bộ đệm (thống nhất hoặc khác)
• rút tiền
• độ phức tạp shader
• độ phức tạp của đường ống (bất kỳ thông tin phản hồi nào được sử dụng? lặp lại hình học bóng? tắc?)
• đồng bộ điểm với CPU (pixel đọc lại?)
• sự đa dạng

Tùy thuộc vào điểm yếu và điểm mạnh của một card đồ họa cụ thể, một hoặc một trong những điểm này sẽ là nút cổ chai. Nó không giống như bạn có thể nói chắc chắn "ở đó, đó là một".

BIÊN TẬP:

Tôi muốn thêm rằng, người ta không thể sử dụng thông số kỹ thuật của GFlops của một thẻ cụ thể và ánh xạ tuyến tính theo khả năng đẩy đa giác. Bởi vì thực tế là việc xử lý đa giác phải trải qua một nút cổ chai liên tiếp trong đường ống đồ họa như được giải thích rất chi tiết ở đây: https://fgiesen.wordpress.com/2011/07/03/a-trip- phiên-the-graphics -pipeline-2011-part-3 /
TLDR: các đỉnh phải vừa với một bộ đệm nhỏ trước khi lắp ráp nguyên thủy vốn là một thứ liên tiếp (thứ tự bộ đệm đỉnh là vấn đề).

Nếu bạn so sánh GeForce 7800 (9yr cũ?) Với 980 năm nay, có vẻ như số lượng hoạt động mỗi giây mà nó có khả năng đã tăng gấp một nghìn lần. Nhưng bạn có thể đặt cược rằng nó sẽ không đẩy đa giác nhanh hơn gấp ngàn lần (sẽ là khoảng 200 tỷ một giây theo số liệu đơn giản này).

EDIT2:

Để trả lời câu hỏi "người ta có thể làm gì để tối ưu hóa động cơ", như trong "không để mất quá nhiều hiệu quả trong các công tắc trạng thái và các chi phí khác".
Đó là một câu hỏi cũ như chính động cơ. Và đang trở nên phức tạp hơn khi lịch sử tiến bộ.

Thật vậy, trong tình huống thực tế, dữ liệu cảnh điển hình sẽ chứa nhiều vật liệu, nhiều kết cấu, nhiều shader khác nhau, nhiều mục tiêu và đường chuyền kết xuất, và nhiều bộ đệm đỉnh, v.v. Một công cụ tôi đã làm việc với khái niệm gói:

Một gói là những gì có thể được kết xuất với một cuộc gọi rút thăm.
Nó chứa định danh để:

• đỉnh đệm
• chỉ số đệm
• máy ảnh (cung cấp mục tiêu vượt qua và kết xuất)
• id vật liệu (cung cấp cho shader, kết cấu và UBO)
• khoảng cách đến mắt
• có thể nhìn thấy

Vì vậy, bước đầu tiên của mỗi khung là chạy một sắp xếp nhanh trên danh sách gói bằng cách sử dụng hàm sắp xếp với toán tử ưu tiên cho khả năng hiển thị, sau đó chuyển, sau đó là vật liệu, sau đó là hình học và cuối cùng là khoảng cách.

Vẽ các đối tượng gần sẽ được ưu tiên để tối đa hóa việc loại bỏ Z sớm.
Pass là những bước cố định, vì vậy chúng tôi không có lựa chọn nào khác ngoài việc tôn trọng chúng.
Vật liệu là thứ đắt nhất để chuyển đổi trạng thái sau khi kết xuất mục tiêu.

Ngay cả giữa các ID vật liệu khác nhau, một đơn đặt hàng phụ có thể được thực hiện bằng cách sử dụng tiêu chí heuristic để giảm số lượng thay đổi shader (đắt nhất trong các hoạt động chuyển đổi trạng thái vật liệu) và thay đổi liên kết kết cấu thứ hai.

Sau tất cả thứ tự này, người ta có thể áp dụng kết cấu lớn, kết cấu ảo và kết xuất ( liên kết ) không có thuộc tính nếu thấy cần thiết.

Về API công cụ cũng có một điều phổ biến là trì hoãn việc ban hành các lệnh thiết lập trạng thái theo yêu cầu của khách hàng. Nếu máy khách yêu cầu "đặt camera 0", tốt nhất là chỉ lưu trữ yêu cầu này và nếu sau đó máy khách gọi "đặt camera 1" nhưng không có lệnh nào khác ở giữa, động cơ có thể phát hiện ra sự vô dụng của lệnh đầu tiên và thả nó . Đây là loại bỏ dư thừa, có thể bằng cách sử dụng mô hình "giữ lại hoàn toàn". Bằng cách phản đối mô hình "ngay lập tức", đó sẽ chỉ là một trình bao bọc phía trên API gốc và đưa ra các lệnh theo đúng lệnh của mã máy khách. ( ví dụ: virtrev )

Và cuối cùng, với phần cứng hiện đại, một bước rất tốn kém (để phát triển), nhưng có khả năng rất đáng để thực hiện là chuyển API sang kiểu kim loại / mantle / Vulkan / DX12 và chuẩn bị các lệnh kết xuất bằng tay.

Một công cụ chuẩn bị các lệnh kết xuất sẽ tạo ra một bộ đệm chứa "danh sách lệnh" được ghi đè ở mỗi khung.

Thông thường có một khái niệm về "ngân sách" khung, một trò chơi có thể đủ khả năng. Bạn cần thực hiện mọi thứ trong 16 mili giây, do đó, bạn phân vùng rõ ràng thời gian GPU "2 ms cho lightpre pass", "4 ms cho vật liệu vượt qua", "6 ms cho ánh sáng gián tiếp", "4 ms cho quá trình hậu xử lý" ...