Làm cách nào để biết nếu tôi trừu tượng hóa API đồ họa quá chặt?

23

Khi tạo trình kết xuất hỗ trợ nhiều API đồ họa, bạn thường muốn trừu tượng mã của mình trong một loại thư viện cấp thấp được gắn với một số API đồ họa như OpenGL, Vulkan, D3D11, v.v.

Chúng hoạt động rất khác nhau, do đó, làm cho một API chung tốt trở nên cần thiết; Tôi đã đọc rằng bạn thường muốn sử dụng "back-end" thực hiện chức năng cơ bản cho từng API mà bạn muốn hỗ trợ và "front-end", thứ được lập trình viên sử dụng để vẽ nội dung trên màn.

Làm thế nào để tôi biết nếu tôi thực hiện quá nhiều sự trừu tượng chặt chẽ?

graphics-programming

— Gabriele Vierti
nguồn

5

Bạn có chắc chắn 100% rằng trình bao bọc + Vulkan hoặc D3D11 của bạn nhanh hơn so với việc luôn sử dụng OpenGL không?

— Vịt Mooing

@Mooing Duck nếu sử dụng đúng cách, vâng.

— Gabriele Vierti

4

Tôi thực sự nghi ngờ điều đó. Hầu hết các lợi ích trong Vulkan đến từ cấp độ rất thấp và làm mọi thứ theo một cách rất đặc biệt, cụ thể. Một cái gì đó đủ chung chung cũng có thể làm tương tự trong OpenGL hoặc D3D gần như chắc chắn không thể làm điều đó. Thực hiện lại các công cụ tương tự như OpenGL (giống như nhiều hướng dẫn của Vulkan, trớ trêu thay) mang lại hiệu suất tương đương 99,99%, với 20 lần công việc.

— Damon

@Damon đúng, nhưng các API mới hơn được thiết kế riêng (và không được điều chỉnh như OpenGL) để hoạt động trên gpus hiện đại; nói về Vulkan, bạn có thể khá nhiều sử dụng API giống nhau trên mỗi nền tảng được hỗ trợ, trái với OpenGL, nơi bạn cần phải sử dụng phiên bản "Embedded Systems". Khác với các tính năng ưa thích và ít cpu hơn, chúng tôi không có nhiều, nhưng trong tương lai, chúng tôi có thể có một số kỹ thuật khá đáng ngạc nhiên có thể chạy nhanh hơn bằng Vk hoặc D3D12 thay vì OGL hoặc D3D11

— Gabriele Vierti

44

Trước hết, hãy xem xét nếu nó thực sự đáng để hỗ trợ nhiều hơn một API đồ họa. Chỉ cần sử dụng OpenGL sẽ bao trùm hầu hết các nền tảng và sẽ "đủ tốt" cho tất cả các dự án có tham vọng đồ họa nhất. Trừ khi bạn làm việc cho một studio trò chơi rất lớn có thể đủ khả năng để thực hiện vài nghìn giờ để thực hiện và thử nghiệm nhiều phụ trợ kết xuất và trừ khi có một số tính năng cụ thể của DirectX hoặc Vulcan mà bạn thực sự muốn thể hiện, nó thường không gây rắc rối . Đặc biệt là xem xét rằng bạn có thể tiết kiệm rất nhiều công việc bằng cách sử dụng lớp trừu tượng do người khác tạo (thư viện bên thứ 3 hoặc công cụ trò chơi).

Nhưng hãy giả sử rằng bạn đã đánh giá các lựa chọn của mình và đi đến kết luận rằng nó vừa khả thi và đáng để bạn dành thời gian để tự mình thực hiện.

Sau đó, thẩm phán chính của kiến trúc phần mềm lớp trừu tượng của bạn là các lập trình viên đầu cuối của bạn.

Họ có thể thực hiện các hệ thống trò chơi mà họ muốn thực hiện mà không phải băn khoăn về bất kỳ chi tiết cấp thấp nào không?
Họ có thể hoàn toàn bỏ qua rằng có nhiều hơn một API đồ họa không?
Về mặt lý thuyết có thể thêm một phụ trợ kết xuất khác mà không thay đổi bất kỳ mã mặt trước nào không?

Nếu vậy, bạn đã thành công.

— Phi-líp
nguồn

2

Một đề xuất bổ sung: có đáng nhấn mạnh rằng mục tiêu là đạt được các mục tiêu trong các gạch đầu dòng với mức độ nỗ lực tối thiểu - chỉ cần bắn trúng mục tiêu và không tiến xa hơn? Mặt khác, mỗi một trong số chúng có thể biến thành một lỗ thỏ cho nhà phát triển điển hình (bao gồm cả tôi) thường không biết khi nào nên để một mình đủ tốt. :) Và cũng là cách đáng tin cậy duy nhất để đánh giá thành công là phát triển và thử nghiệm API lặp lại với người dùng thực tế ; không thể đoán chính xác và dẫn đến một kịch bản lỗ thỏ về kỹ thuật quá mức.

— bob

5

Tôi sẽ nói thêm rằng, nếu bạn thực sự phải hỗ trợ nhiều thư viện đồ họa, gần như chắc chắn là một thư viện sẵn có làm mọi thứ bạn cần, vì vậy ngay cả khi đó bạn thực sự không nên tự mình cuộn. (Tất nhiên, có những trường hợp ngoại lệ, nhưng nếu bạn đủ kinh nghiệm để hỏi "làm thế nào chặt chẽ của một trừu tượng tôi nên làm cho" có lẽ bạn đang không làm việc trên một dự án mà đòi hỏi bạn phải làm điều đó)

— Vụ kiện Quỹ Monica

Tôi không phải là một nhà phát triển đồ họa, nhưng nhìn vào các khung tương thích từ lịch sử của cơ sở dữ liệu và hệ điều hành, tôi nói thêm rằng gần như chắc chắn nó không xứng đáng để tạo khung chung của riêng bạn . Khung này gần như chắc chắn sẽ phải hy sinh hiệu năng để tương thích, điều đó có nghĩa là bạn không thể làm gì nhiều với các tính năng chuyên dụng này. Các khung hiện tại gần như chắc chắn để xử lý các vấn đề đó tốt hơn do sử dụng rộng rãi hơn. Bây giờ, nếu bạn có ngân sách khổng lồ mà bạn mô tả và muốn xây dựng một khung chuyên biệt (giả sử cho một trò chơi hoặc loạt), điều đó có thể dễ thực hiện hơn.

— jpmc26

6

Bắt đầu bằng cách xác định những gì bạn thực sự cần từ phần "trình bao bọc" của API. Nói chung, rất đơn giản: bạn cần các tài nguyên cơ bản (bộ đệm, đổ bóng, kết cấu, trạng thái đường ống) và cách sử dụng các tài nguyên đó để tạo khung bằng cách gửi một số lệnh gọi.

Cố gắng giữ bất kỳ logic cấp cao nào ra khỏi phần trình bao bọc của API. Nếu bạn triển khai một kỹ thuật loại bỏ cảnh thông minh trong phần này của API, thì bây giờ bạn đang ở trên móc để sao chép logic đó trong tất cả các triển khai phụ trợ. Đó là rất nhiều nỗ lực thêm, vì vậy hãy giữ nó đơn giản. Quản lý cảnh phải là một phần của API cấp cao hơn sử dụng trình bao bọc thay vì là một phần của chính trình bao bọc.

Chọn các mục tiêu bạn sẽ hỗ trợ và hiểu chúng. Thật khó để viết các trình bao bọc tốt cho "mọi thứ", và có lẽ bạn không cần phải (có thể nói rằng bạn không cần phải viết một trình bao bọc duy nhất, như đã lưu ý trong câu trả lời của Philipp ). Hầu như không thể viết một trình bao bọc hợp lý nếu bạn không biết các API bạn sẽ bọc.

Đánh giá trạng thái API của bạn thường xuyên. Nhìn chung, nó phải có diện tích bề mặt nhỏ hơn các API được bao bọc bên dưới; nếu bạn thấy mình đang tạo các loại trình bao bọc một-một cho mọi cấu trúc D3D hoặc mọi lệnh gọi hàm OpenGL, có lẽ bạn đang bỏ qua khóa học.

Nhìn vào những gì công việc đã đi trước. Sokol và BGFX là các API cung cấp các mức độ bất khả tri có thể hữu ích cho bạn và tương đối dễ hiểu (đặc biệt là trước đây).

— Josh
nguồn

3

Một điểm khác chưa được đề cập mà bạn nên xem xét là mục tiêu hiệu suất của bạn là gì. Nếu mục tiêu của bạn là có một thư viện đồ họa mang lại hiệu năng tốt từ nền tảng phần cứng giá rẻ, nhưng cũng có thể sử dụng được trên nhiều nền tảng mạnh hơn rất nhiều nhưng sử dụng API khác, thì có thể hợp lý khi thiết kế API của bạn bất cứ điều gì trừu tượng được sử dụng nguyên bản trên nền tảng mà hiệu suất là một vấn đề. Ngay cả khi điều này gây ra sự suy giảm tốc độ 50% trên các nền tảng mạnh hơn, nó có thể đáng giá nếu nó cho phép cải thiện tốc độ 20% trên nền tảng nơi hiệu suất quan trọng nhất.

— siêu mèo
nguồn