3Dゲームでハードウェアアクセラレーションを取得するには、グラフィックスAPIを使用する必要がありますか?OpenGL、DirectX 、CUDA、OpenCLなどのグラフィックスカードAPIへの依存関係をどの程度まで解放できますか?
ゲーム用に独自のグラフィックスAPIまたはライブラリを作成できますか?たとえ難しい場合でも、3Dアプリケーションが独立してグラフィックスドライバーに接続し、GPUですべてをレンダリングすることは理論的に可能ですか?
3Dゲームでハードウェアアクセラレーションを取得するには、グラフィックスAPIを使用する必要がありますか?OpenGL、DirectX 、CUDA、OpenCLなどのグラフィックスカードAPIへの依存関係をどの程度まで解放できますか?
ゲーム用に独自のグラフィックスAPIまたはライブラリを作成できますか?たとえ難しい場合でも、3Dアプリケーションが独立してグラフィックスドライバーに接続し、GPUですべてをレンダリングすることは理論的に可能ですか?
回答:
多くの答えは重要な点を見落としていると思います。ハードウェアに直接アクセスするアプリを作成できますが、最新のオペレーティングシステムでは作成できません。これは単なる時間の問題ではなく、「選択の余地がない」問題です。
Windows、Linux、OSXなどはすべて、任意のアプリケーションへの直接ハードウェアアクセスを禁止しています。これはセキュリティ上の理由から重要です。ランダムアプリがシステムメモリを読み取れないようにするため、ランダムアプリが任意のGPUメモリを読み取れないようにする必要があります。銀行口座のフレームバッファや、GPUメモリに存在しないものなど。そのようなものを分離して保護し、OSによってアクセスを制御する必要があります。
ほとんどのハードウェアと直接通信できるのはドライバーのみです。ドライバーと通信する唯一の方法は、OSの公開されたHALと各ドライバーの独自仕様で互換性のないインターフェイスを使用することです。そのドライバーインターフェイスはベンダーごとに異なるだけでなく、ドライバー自体のバージョン間でも異なるため、コンシューマアプリケーションのインターフェイスと直接対話することはほぼ不可能です。これらの層は、多くの場合、アプリケーションがそれらにアクセスする機能をさらに制限するアクセス制御で覆われています。
もちろん、DOSなどの安全でないオペレーティングシステムのみをターゲットにしている場合を除き、ゲームでハードウェアを直接使用することはできません。また、現代のコンシューマオペレーティングシステムでのゲームの唯一の実行可能なオプションは、DirectX、OpenGL、バルカン。
事実上必要です、はい。必要なのは、本質的に多数の異なるハードウェア構成のドライバーコードを何年も書きたい場合を除き、すべての一般的なオペレーティングシステムとハードウェアに対してGPUベンダーが作成した既存のドライバーに対して統合するAPIを使用する必要があるためです。
唯一の現実的な選択肢は、3Dアクセラレーションを使用せず、代わりにソフトウェアレンダリングに移行することです。これは、Cのような本当に移植性のあるもので記述されていれば、ほぼすべてのシステム/デバイスで実行できます。これは、小さなゲームには問題ありません... SDLのようなものがこの目的に適しています...他にもあります。しかし、これには固有の3D機能がないため、自分で構築する必要があります...これは簡単な作業ではありません。
また、CPUレンダリングは非効率的であり、GPUと比較してパフォーマンスが低下します。
PCをMS-DOSで起動します。次に、PC Game Programmers Encyclopediaのコピーを使用して、カードのVESAレジスタとビデオメモリに直接書き込むことができます。私はこれを20年前に書いて、ソフトウェアで初歩的な3Dをレンダリングするためのコードをまだ持っています。
または、DirectXを使用できます。これは非常に薄い抽象化レイヤーであり、ビデオバッファーに直接書き込み、画面にスワップすることもできます。
独自のビデオハードウェアを構築するという極端なアプローチもあります。
他の答えはあなたの主な質問に非常にうまく答えます:技術的には可能ですが、実際には、目標が顧客基盤を広げることである場合、実際には反対のことをしています。サポートする必要がある何千もの異なるハードウェアとOS構成のサポートに多大な労力を費やしている間。
ただし、特定のAPIに100%依存する必要があるわけではありません。独自の抽象化レイヤーをいつでもコード化してから、より具体的な実装(DirectX実装、OpenGL実装など)を交換することができます。
それでも、おそらくそれは価値がありません。目的に十分合ったものを選んで、それで完了です。あなたはインディーズゲームのメーカーです-ミヌエーではなく、ゲームを作るものに集中する必要があります。ゲームを作ってください!
要約すると、理論的には可能ですが、それは実行不可能であり、利点は得られません。今日、APIの制限は日々少なくなっており、CUDAとOpenCL、シェーダーがあります。したがって、完全に制御することは問題ではありません。
詳細な説明:
これを答えること退屈ですはい。本当の質問はなぜですか?
学習目的以外でこれを行う理由はほとんど想像できません。ある時点で、開発者はCPUレンダリングの実装で何でもできる自由があり、誰もが独自のAPIを持っていて、「パイプライン」のすべてを制御していたことを知っておく必要があります。固定パイプラインとGPUの導入により、誰もが切り替えました。
GPUを使用すると、「より良い」パフォーマンスが得られますが、多くの自由が失われます。グラフィック開発者はその自由を取り戻そうとしています。したがって、より多くのカスタマイズパイプラインが毎日行われます。ドライバーに触れることなく、CUDA / OpenCLとシェーダーを使用してほとんど何でもできます。
ハードウェアと話したい。ハードウェアと通信する方法を使用する必要があります。その方法がハードウェアへのインターフェースです。それがOpenGL、DirectX、CUDA、OpenCLなどです。
下位レベルのインターフェイスを使用している場合でも、下位レベルのインターフェイスを使用していますが、インターフェイスを使用している場合は、上位レベルのカードほど多くの異なるカードで動作しないインターフェイスのみを使用します。
従来のAPIを使用せずに3Dハードウェアアクセラレーションを取得するには、基本的にグラフィックドライバーの機能を複製する独自のコードを記述する必要があります。そのため、これを行う方法を学ぶ最良の方法は、グラフィックスドライバーのコードを調べることです。
NVIDIAカードについては、オープンソースのnouveauプロジェクトをご覧ください。彼らはここに素晴らしいリソースのコレクションを持っています。
他のブランドのグラフィックカードについては、同様のプロジェクトとドキュメントを見つけることができます。
他の回答で述べたように、最新のオペレーティングシステムのほとんどは、ユーザー空間プログラムがハードウェアに直接アクセスすることを防ぐため、コードを記述してオペレーティングシステムドライバーとしてインストールする必要があります。別の方法として、FreeDOSオペレーティングシステムを使用することもできます。これには、このような制限はなく、(理論上)ハードウェアに直接アクセスし、3Dハードウェアアクセラレーショングラフィックスをレンダリングする通常のプログラムを作成できます。既存のオープンソースグラフィックスドライバーからのコードを利用しても、これは非常に重要な量の非自明な作業になることに注意してください(そして、私が知る限り、これまで行われたことはなく、さまざまな理由により、実際にはそうではないかもしれません)技術的に可能)。
DirectXまたはOpenGlを削除しても、依存関係は削除されず、さらに多くの依存関係が発生します。他の回答には、グラフィックスハードウェアと直接対話することさえできない理由がいくつかあります(少なくとも実現不可能です)が、私の最初の答えは次のとおりです。実際にすべての一般的な3Dを抽象化するライブラリを作成した場合グラフィックハードウェアを単一のAPIに統合すると、DirectX / OpenGlを効果的に書き直すことができます。コードを使用してゲームを記述する場合、DirectX / OpenGlを依存関係として持つように、新しいライブラリを新しい依存関係として追加します。
DirectXまたはOpenGlを使用することにより、依存関係は基本的に「このコードはライブラリに依存して、異なるグラフィックカードで特定のコマンドを実行する方法を説明するコードを提供します」と言っています。そのようなライブラリなしで行った場合、「このコードは、ゲームをビルドしたときに存在したハードウェアとまったく同じように動作するグラフィックハードウェアに依存します」という依存関係を導入します。
OpenGlやDirectXなどの抽象化により、ハードウェアメーカーは、共通のコードベースにつながる独自のコード(ドライバー)を提供できるため、ゲームが作成された時点では存在していなかったハードウェアでゲームが実行される可能性が高くなります。
まず第一に、CUDAとOpenCLはグラフィックスAPIではありません。それらはコンピューティングAPIです。
独自のグラフィックAPIを記述する際の問題は、非常に複雑なことです。ハードウェアと直接インターフェースすることもできますが、X CPU、X GPU、X量のRAM、Xオペレーティングシステムを搭載したシステムで動作する場合、Y CPU、Y GPUなどを搭載したシステムで動作するという保証はありません。 1つの良い点は、DirectXがカーネルモードドライバーで動作することです。カーネルに根ざしています。また、グラフィックAPIはGPUをサポートするように構築されていません。GPU(およびそのドライバー)は、それらをサポートするために構築されています。したがって、独自のOSを構築し、x86が提供するVGA割り込みを使用しない限り、グラフィックAPIを構築することはほとんどできません。ただし、GPUと適切にインターフェイスすることはできず、低解像度でスタックすることになります。
エンジンなどを使用せずに、すべてを自分で構築したいことを理解しています。ただし、独自のグラフィックAPIを作成すると、ユーザーに不便が生じるだけです。
独自のドライバーとAPIを作成できます。あなたの能力と知識レベル以外に何も止められません。良い学習経験でなければ、実際の問題は、以前のグラフィック経験があまりなくても、あなたが優れたプログラマーであっても、おそらくあなたがする必要があることに途方に暮れることです...または始めましょう。
それでも、自分で作成したインターフェイスは、背中の後ろで絶えず更新されるものよりも使いやすく、安定しています。だから、もっと多くの人がこのルートに行かないのは少し驚いていますが、現実には技術的な洞察力を持っている人はほとんどいません。誰もがこれを行う方法を学ぶために何年も誰かにお金を払って欲しくないのです彼らは会社を去り、急いで放置します。標準化に関して彼らにとって良いことは、従業員をより使いやすくし、リスクを減らすことです。