Ngày xửa ngày xưa, khi> nhanh hơn <Chờ Chờ thì sao?

Tôi đang đọc một hướng dẫn OpenGL tuyệt vời . Nó thực sự tuyệt vời, tin tôi đi. Chủ đề tôi hiện đang ở là Z-buffer. Ngoài việc giải thích tất cả những gì về nó, tác giả đề cập rằng chúng ta có thể thực hiện các bài kiểm tra độ sâu tùy chỉnh, chẳng hạn như GL_LESS, GL_ALWAYS, v.v. Ông cũng giải thích rằng ý nghĩa thực sự của các giá trị độ sâu (là trên cùng và không phải) tùy chỉnh. Tôi hiểu cho đến nay. Và sau đó tác giả nói một điều không thể tin được:

Phạm vi zNear có thể lớn hơn phạm vi zFar; nếu có, thì các giá trị không gian cửa sổ sẽ bị đảo ngược, xét về những gì cấu thành gần nhất hoặc xa nhất với người xem.

Trước đó, người ta đã nói rằng giá trị Z của không gian cửa sổ là 0 gần nhất và 1 là xa nhất. Tuy nhiên, nếu các giá trị Z không gian clip của chúng tôi bị phủ định, độ sâu 1 sẽ gần nhất với chế độ xem và độ sâu 0 sẽ xa nhất. Tuy nhiên, nếu chúng ta lật hướng kiểm tra độ sâu (GL_LESS sang GL_GREATER, v.v.), chúng ta sẽ nhận được kết quả chính xác tương tự. Vì vậy, nó thực sự chỉ là một quy ước. Thật vậy, lật dấu Z và kiểm tra độ sâu đã từng là một tối ưu hóa hiệu suất quan trọng cho nhiều trò chơi.

Nếu tôi hiểu chính xác, khôn ngoan về hiệu suất, lật dấu Z và kiểm tra độ sâu thì không có gì khác ngoài việc thay đổi <so sánh thành >so sánh. Vì vậy, nếu tôi hiểu chính xác và tác giả không nói dối hoặc làm cho mọi thứ trở nên tồi tệ, thì việc thay đổi <thành >sử dụng là một tối ưu hóa quan trọng cho nhiều trò chơi.

Được tác giả làm cho mọi thứ lên, tôi hiểu lầm gì đó, hoặc là nó thực sự là trường hợp đó một lần <là chậm ( cực kỳ quan , như tác giả nói) hơn >?

Cảm ơn đã làm rõ vấn đề khá tò mò này!

_{Tuyên bố miễn trừ trách nhiệm: Tôi hoàn toàn biết rằng độ phức tạp của thuật toán là nguồn chính để tối ưu hóa. Hơn nữa, tôi nghi ngờ rằng ngày nay nó chắc chắn sẽ không tạo ra bất kỳ sự khác biệt nào và tôi không yêu cầu điều này để tối ưu hóa bất cứ điều gì. Tôi chỉ là vô cùng, đau đớn, có thể nghiêm túc tò mò.}

Nếu tôi hiểu chính xác, khôn ngoan về hiệu suất, lật dấu Z và kiểm tra độ sâu không gì khác ngoài việc thay đổi <so sánh với so sánh>. Vì vậy, nếu tôi hiểu chính xác và tác giả không nói dối hoặc làm cho mọi thứ trở nên phức tạp, thì việc thay đổi <thành> được sử dụng là một tối ưu hóa quan trọng cho nhiều trò chơi.

Tôi đã không giải thích điều đó đặc biệt tốt, bởi vì nó không quan trọng. Tôi chỉ cảm thấy đó là một chút thú vị để thêm vào. Tôi không có ý định đi qua thuật toán cụ thể.

Tuy nhiên, bối cảnh là chìa khóa. Tôi chưa bao giờ nói rằng <so sánh nhanh hơn so sánh>. Hãy nhớ rằng: chúng ta đang nói về các bài kiểm tra độ sâu phần cứng đồ họa, không phải CPU của bạn. Không phải operator<.

Những gì tôi đã đề cập đến là một tối ưu hóa cụ thể cũ trong đó một khung hình bạn sẽ sử dụng GL_LESSvới phạm vi [0, 0,5]. Khung tiếp theo, bạn kết xuất với GL_GREATERphạm vi [1.0, 0.5]. Bạn qua lại, theo nghĩa đen là "lật dấu Z và kiểm tra độ sâu" mọi khung hình.

Điều này làm mất một chút độ chính xác độ sâu, nhưng bạn không phải xóa bộ đệm độ sâu, mà trước đây, nó là một hoạt động khá chậm. Vì việc xóa độ sâu không chỉ miễn phí trong những ngày này mà còn thực sự nhanh hơn kỹ thuật này, mọi người không làm điều đó nữa.

Câu trả lời gần như chắc chắn là đối với bất kỳ hiện thân nào của chip + trình điều khiển đã được sử dụng, HV phân cấp chỉ hoạt động theo một hướng - đây là một vấn đề khá phổ biến vào thời đó. Việc lắp ráp / phân nhánh ở mức độ thấp không liên quan gì đến nó - Bộ đệm Z được thực hiện trong phần cứng chức năng cố định và được xử lý theo đường ống - không có suy đoán và do đó, không có dự đoán chi nhánh.

Tối ưu hóa như thế sẽ ảnh hưởng đến hiệu suất trên nhiều giải pháp đồ họa nhúng vì nó sẽ khiến bộ đệm khung giải quyết kém hiệu quả hơn. Xóa bộ đệm là một tín hiệu rõ ràng cho trình điều khiển rằng nó không cần lưu trữ và khôi phục bộ đệm khi tạo thùng.

Thông tin cơ bản ít: một rasterizer ốp lát / xử lý màn hình với số lượng các ô rất nhỏ phù hợp với bộ nhớ trên chip. Điều này làm giảm ghi và đọc vào bộ nhớ ngoài làm giảm lưu lượng trên bus bộ nhớ. Khi một khung hoàn thành (hoán đổi được gọi, hoặc các bộ xếp hình bị xóa vì chúng đầy đủ, các ràng buộc bộ đệm khung thay đổi, v.v.) bộ đệm khung phải được giải quyết; điều này có nghĩa là mọi thùng được xử lý lần lượt.

Người lái xe phải cho rằng các nội dung trước đó phải được bảo tồn. Việc bảo quản có nghĩa là thùng phải được ghi ra bộ nhớ ngoài và sau đó được khôi phục từ bộ nhớ ngoài khi thùng được xử lý lại. Hoạt động rõ ràng cho trình điều khiển rằng nội dung của thùng được xác định rõ: màu rõ ràng. Đây là một tình huống không quan trọng để tối ưu hóa. Ngoài ra còn có phần mở rộng để "loại bỏ" nội dung bộ đệm.

Nó phải làm với các bit cờ trong lắp ráp được điều chỉnh cao.

x86 có cả hướng dẫn jl và jg, nhưng hầu hết các bộ xử lý RISC chỉ có jl và jz (không có jg).