Tôi có thực sự cần sử dụng API đồ họa không?

Có nhất thiết phải sử dụng API đồ họa để tăng tốc phần cứng trong trò chơi 3D không? Ở mức độ nào có thể thoát khỏi sự phụ thuộc vào các API thẻ đồ họa như OpenGL, DirectX , CUDA, OpenCL hoặc bất cứ điều gì khác?

Tôi có thể tạo API đồ họa hoặc thư viện cho trò chơi của mình không? Ngay cả khi khó khăn, về mặt lý thuyết, ứng dụng 3D của tôi có thể liên lạc độc lập với trình điều khiển đồ họa và hiển thị mọi thứ trên GPU không?

Tôi nghĩ rằng rất nhiều câu trả lời bỏ lỡ một điểm quan trọng: bạn có thể viết các ứng dụng truy cập trực tiếp vào phần cứng, nhưng không phải trên các hệ điều hành hiện đại . Đó không chỉ là vấn đề thời gian, mà là vấn đề "bạn không có lựa chọn".

Windows, Linux, OSX, v.v ... đều cấm truy cập phần cứng trực tiếp vào các ứng dụng tùy ý. Điều này rất quan trọng vì lý do bảo mật: bạn không muốn bất kỳ ứng dụng ngẫu nhiên nào có thể đọc bộ nhớ GPU tùy ý vì lý do tương tự bạn không muốn bất kỳ ứng dụng ngẫu nhiên nào có thể đọc bộ nhớ hệ thống. Những thứ như bộ đệm khung cho tài khoản ngân hàng của bạn hoặc không có gì trong bộ nhớ GPU. Bạn muốn những thứ đó bị cô lập và bảo vệ và quyền truy cập được kiểm soát bởi HĐH của bạn.

Chỉ các trình điều khiển mới có thể nói chuyện trực tiếp với hầu hết các phần cứng và cách duy nhất để nói chuyện với trình điều khiển là thông qua HAL tiếp xúc với hệ điều hành và giao diện không tương thích và độc quyền của mỗi trình điều khiển. Giao diện trình điều khiển đó sẽ không chỉ khác nhau đối với mỗi nhà cung cấp mà thậm chí sẽ khác nhau giữa các phiên bản của trình điều khiển, khiến cho việc nói chuyện trực tiếp với giao diện trong ứng dụng khách hàng gần như không thể. Các lớp này thường được bao phủ bởi các điều khiển truy cập nhằm hạn chế hơn nữa khả năng ứng dụng truy cập chúng.

Vì vậy, không, trò chơi của bạn không thể chỉ sử dụng phần cứng trực tiếp, trừ khi bạn chỉ nhắm mục tiêu các hệ điều hành không an toàn như DOS và tùy chọn khả thi duy nhất của bạn cho trò chơi trên các hệ điều hành tiêu dùng hiện đại là nhắm mục tiêu API công khai như DirectX, OpenGL hoặc Vulkan.

Thực tế cần thiết của nó, có. Điều này là cần thiết bởi vì trừ khi bạn muốn dành nhiều năm để viết mã trình điều khiển cơ bản cho vô số cấu hình phần cứng khác nhau, bạn cần sử dụng API hợp nhất với các trình điều khiển hiện có được viết bởi các nhà cung cấp GPU cho tất cả các hệ điều hành và phần cứng phổ biến.

Sự thay thế thực tế duy nhất là bạn không sử dụng khả năng tăng tốc 3D, và thay vào đó là kết xuất phần mềm, với điều kiện nó được viết bằng thứ gì đó thực sự di động như C, sẽ có thể chạy trên bất kỳ hệ thống / thiết bị nào. Điều đó tốt cho các trò chơi nhỏ hơn ... một cái gì đó như SDL phù hợp với mục đích này ... cũng có những thứ khác. Nhưng điều này thiếu khả năng 3D vốn có nên bạn phải tự xây dựng chúng ... đó không phải là một nhiệm vụ tầm thường.

Cũng nên nhớ rằng kết xuất CPU không hiệu quả và chịu hiệu năng kém so với GPU.

Các API như OpenGL hoặc DirectX được hệ điều hành triển khai một phần và được thực hiện một phần bởi chính trình điều khiển đồ họa.

Điều đó có nghĩa là khi bạn muốn tạo API cấp thấp của riêng mình, sử dụng các khả năng của GPU hiện đại, về cơ bản bạn cần phải viết trình điều khiển đồ họa của riêng mình. Đảm bảo rằng trình điều khiển của bạn hoạt động với tất cả các card đồ họa thông thường sẽ là một thách thức khá lớn, đặc biệt là vì các nhà cung cấp thường không cởi mở với thông số kỹ thuật của họ.

Khởi động PC của bạn vào MS-DOS. Sau đó, bằng cách sử dụng bản sao của bách khoa toàn thư lập trình trò chơi PC , bạn có thể ghi trực tiếp vào các thanh ghi VESA của thẻ và vào bộ nhớ video. Tôi vẫn có mã tôi đã viết 20 năm trước để làm điều này và đưa ra 3D thô sơ trong phần mềm.

Ngoài ra, bạn chỉ có thể sử dụng DirectX; đó là một lớp trừu tượng thực sự mỏng và cũng cho phép bạn viết trực tiếp vào bộ đệm video và sau đó hoán đổi chúng ra màn hình.

Ngoài ra còn có cách tiếp cận cực đoan trong việc xây dựng phần cứng video của riêng bạn .

Các câu trả lời khác trả lời câu hỏi chính của bạn khá độc đáo: về mặt kỹ thuật, điều đó là có thể, nhưng trên thực tế, nếu mục tiêu của bạn là mở rộng cơ sở khách hàng, bạn thực sự đang làm điều ngược lại. Trong khi lãng phí một lượng lớn công việc để hỗ trợ hàng ngàn cấu hình phần cứng và hệ điều hành khác nhau mà bạn cần hỗ trợ.

Tuy nhiên, điều đó không có nghĩa là bạn phải phụ thuộc 100% vào một API cụ thể. Bạn luôn có thể mã hóa lớp trừu tượng của riêng mình và sau đó trao đổi các triển khai cụ thể hơn (ví dụ: triển khai DirectX, triển khai OpenGL, ...) trong và ngoài.

Ngay cả sau đó, nó có thể không xứng đáng. Chỉ cần chọn một cái gì đó hoạt động đủ tốt cho mục đích của bạn, và được thực hiện với nó. Bạn là một nhà sản xuất trò chơi độc lập - bạn cần tập trung vào những thứ tạo ra trò chơi, không phải trên minutae. Chỉ cần làm cho trò chơi!

Tóm lại: Về mặt lý thuyết bạn có thể, nhưng điều đó là không khả thi, và bạn sẽ không nhận được bất kỳ lợi thế nào. Các API hạn chế ngày nay trở nên ít hơn mỗi ngày, bạn có CUDA và OpenCL và các trình đổ bóng. Vì vậy, có toàn quyền kiểm soát không còn là vấn đề.

Giải thích đầy đủ hơn:

Trả lời đây là một nhàm chán có . Câu hỏi thực sự là tại sao ?

Tôi hầu như không tưởng tượng được tại sao bạn muốn làm điều này ngoài mục đích học tập. Bạn phải biết rằng tại một số điểm, các nhà phát triển có quyền tự do làm bất cứ điều gì với việc triển khai kết xuất CPU của họ, mọi người đều có API riêng, họ kiểm soát mọi thứ trong "đường ống". Với việc giới thiệu các đường ống và GPU cố định, mọi người đã chuyển sang ..

Với GPU, bạn có được hiệu năng "tốt hơn", nhưng mất rất nhiều sự tự do. Các nhà phát triển đồ họa đang đẩy mạnh để lấy lại sự tự do đó. Do đó, nhiều đường ống tùy biến hơn mỗi ngày. Bạn có thể làm hầu hết mọi thứ bằng CUDA / OpenCL và thậm chí cả shader mà không cần chạm vào trình điều khiển.

Bạn muốn nói chuyện với phần cứng. Bạn cần sử dụng một cách để nói chuyện với phần cứng. Đó là giao diện cho phần cứng. Đó là những gì OpenGL, DirectX, CUDA, OpenCL và bất cứ thứ gì khác.

Nếu bạn ở cấp độ thấp hơn, bạn chỉ đang sử dụng giao diện cấp thấp hơn, nhưng bạn vẫn đang sử dụng một giao diện, chỉ có một giao diện không hoạt động với nhiều thẻ khác nhau như cấp độ cao hơn.

Để có được Tăng tốc phần cứng 3D mà không cần sử dụng API truyền thống, về cơ bản bạn cần phải viết mã của riêng mình để sao chép chức năng của trình điều khiển đồ họa. Vì vậy, cách tốt nhất để học cách làm điều này là xem mã của trình điều khiển đồ họa.

Đối với thẻ NVIDIA, bạn nên xem dự án nouveau nguồn mở . Họ có một bộ sưu tập các tài nguyên tuyệt vời ở đây .

Đối với các thương hiệu card đồ họa khác, bạn có thể tìm thấy các dự án và tài liệu tương tự.

Lưu ý rằng như đã được đề cập trong các câu trả lời khác, hầu hết các hệ điều hành hiện đại sẽ ngăn các chương trình không gian người dùng truy cập trực tiếp vào phần cứng, vì vậy bạn sẽ cần phải viết mã của mình và cài đặt nó làm trình điều khiển hệ điều hành. Ngoài ra, bạn có thể sử dụng hệ điều hành FreeDOS, không có hạn chế đó và sẽ cho phép bạn (về lý thuyết) truy cập trực tiếp vào phần cứng và cho phép bạn viết chương trình thông thường hiển thị đồ họa tăng tốc phần cứng 3D. Lưu ý rằng, ngay cả việc tận dụng mã từ trình điều khiển đồ họa nguồn mở hiện tại, đây sẽ là một số lượng lớn công việc không tầm thường (và theo như tôi biết, chưa bao giờ được thực hiện và vì nhiều lý do, thực tế có thể không được về mặt kỹ thuật có thể).

Loại bỏ DirectX hoặc OpenGl sẽ không loại bỏ các phụ thuộc, nó sẽ giới thiệu nhiều hơn về chúng. Các câu trả lời khác đã có một số điểm tốt tại sao thậm chí không thể nói chuyện trực tiếp với phần cứng đồ họa (ít nhất là không khả thi), nhưng câu trả lời đầu tiên của tôi sẽ là: Nếu thực tế bạn đã viết một thư viện trừu tượng tất cả 3d phổ biến phần cứng đồ họa thành một API duy nhất mà bạn đã viết lại DirectX / OpenGl một cách hiệu quả. Nếu bạn sử dụng mã của mình để viết một trò chơi, bạn sẽ thêm thư viện mới của mình làm phụ thuộc mới, giống như bây giờ bạn có DirectX / OpenGl làm phụ thuộc.

Bằng cách sử dụng DirectX hoặc OpenGl, các phụ thuộc của bạn về cơ bản nói rằng "Mã này phụ thuộc vào thư viện để cung cấp mã giải thích cách chạy các lệnh nhất định trên các thẻ đồ họa khác nhau". Nếu bạn không có thư viện như vậy, bạn sẽ giới thiệu sự phụ thuộc của "Mã này phụ thuộc vào phần cứng đồ họa hoạt động giống hệt như phần cứng tồn tại khi tôi xây dựng trò chơi."

Các tóm tắt như OpenGl hoặc DirectX cho phép các nhà sản xuất phần cứng cung cấp mã của chính họ (trình điều khiển) dẫn đến một cơ sở mã chung, vì vậy các trò chơi có nhiều khả năng chạy trên phần cứng thậm chí không tồn tại khi trò chơi được viết.

Trước hết, CUDA và OpenCL không phải là apis đồ họa. Họ là apis tính toán.

Vấn đề với việc viết api đồ họa của riêng bạn là nó rất phức tạp. Bạn có thể giao tiếp với phần cứng trực tiếp, nhưng không có gì đảm bảo rằng nếu nó hoạt động trên hệ thống có CPU X, GPU X, lượng ram và hệ điều hành X thì nó sẽ hoạt động trên hệ thống có CPU Y, GPU Y, v.v. Một điểm hay là DirectX hoạt động với trình điều khiển chế độ kernel. Nó được bắt nguồn từ kernel. Ngoài ra, apis đồ họa không được xây dựng để hỗ trợ GPU. GPU (và trình điều khiển của chúng) được xây dựng để hỗ trợ chúng. Vì vậy, bạn gần như không thể xây dựng một api đồ họa trừ khi bạn xây dựng hệ điều hành của riêng mình và sử dụng các ngắt VGA được cung cấp x86. Nhưng bạn vẫn không thể giao tiếp đúng với GPU và bạn sẽ bị kẹt ở độ phân giải thấp.

Tôi hiểu rằng bạn muốn tự mình xây dựng mọi thứ và không sử dụng động cơ hay bất cứ thứ gì tương tự. Nhưng làm api đồ họa của riêng bạn sẽ chỉ tạo ra sự bất tiện cho người dùng.

Bạn có thể viết trình điều khiển và API của riêng bạn, không có gì ngăn cản bạn ngoài khả năng và trình độ kiến ​​thức của bạn. Nếu không có gì khác thì đó sẽ là một trải nghiệm học tập tốt, vấn đề thực sự là nếu không có nhiều kinh nghiệm đồ họa trước đó thì ngay cả khi bạn là một lập trình viên tuyệt vời, bạn có thể sẽ không biết những gì bạn cần làm ... hoặc thậm chí để bắt đầu.

Tuy nhiên, giao diện bạn tự làm sẽ dễ sử dụng và ổn định hơn cho bạn so với thứ gì đó được cập nhật sau lưng liên tục. Vì vậy, có một chút ngạc nhiên với tôi rằng nhiều người không đi theo con đường này, nhưng thực tế là có rất ít người có sự nhạy bén về kỹ thuật và không ai muốn trả tiền cho ai đó trong nhiều năm để học cách làm tất cả những điều này, sau đó có thể có họ rời khỏi công ty và bỏ mặc họ Điều tốt cho họ về tiêu chuẩn hóa là nó làm cho nhân viên chi tiêu nhiều hơn và giảm thiểu rủi ro.