内部の仕組み（ファームウェアまたはカーネルの一部ではない）

Question

私がこれまでhttps://github.com/raspberrypi/userland

私の理解からラズベリーパイグラフィックスドライバコードのユーザランド部分を理解しようとしているが、次のとおりです。 - ファームウェアブロブGPUで実行され、より低いレベルで、メッセージ（バイト配列）（他のVCHIQキューには無関係であるVCHIQと呼ばれる複数の28ビット・ワードFIFOのトップに通過に基づいており、OpenGLのようなインタフェースを提供グラフィックス） - CPU部分では、OpenGLコールはGPUへのメッセージに変換されます。低レベルの機能（メッセージ・キューまたはVCHIQどちらか - 私はコードではまだその部分を発見していない）へのアクセスは、Linuxカーネルモジュールが必要ですが、ない高レベルの論理がそこに起こりません。 - GPUの部分は閉じていますが、それは私の目的では問題ありません。私の最終的な目標は、ベアメタル（Linuxなし）で動作するGPUとの通信を得ることですが、クローズドファームウェアブロブはそのままです。最初の目標として、OpenGLコールが実際にGPUにどのように渡されるかを理解したいと思います。それを超えるものはこの質問の一部ではありません。

はしかし、私はこのための実際のコードを見つけることにこだわっています。 OpenGL呼び出しはRPC_CALL *を使用し、RPC_DOはkhronos_server_lock_func_table（）を呼び出します。しかし、その機能はコードから抜けているようだが、私の驚いたことに、私はGoogle上でそれについて有用なものを見つけることができなかった。

私の質問： - 私はARMのCPU側でまだ午前、または私が気付かずGPUの土地に移動したのですか？後者が当てはまる場合は、どこでその行を交差させましたか？ - 私はまだCPU側にいると仮定します - その関数のコードはどこですか？それはまったく開いているのですか、実際にはここでCPU側に残っている部品が閉じられていますか？ Web上のすべてのソースは、CPUのコードが100％開いていることを示しているようです。 - その時点でC OpenGLの機能の実装は、実際にはGPUにメッセージを送信しますか？おそらくデバイスファイルとして実装されているVCHIQを表すカーネル機能への呼び出しをある程度期待しています。

Answer 1

Linuxを使用せずにGPUにアクセスする方法を完全に理解していません。私はその技術に精通していませんが、私のプライベートプロジェクトのGPUを掘り下げています私が知っていることを教えてくれるでしょう。

GPUはVideoCore IVであり、そのドキュメントはBroadcom's websiteで提供されています。

また、左側の図にはVCHIQがカーネルドライバに含まれていることがわかるので、カーネルのソースコードで実装の詳細を調べることができます。

多分これは助けのかもしれません：VideoCore IV Programmer's Manual。ドキュメントについて：

これは静的解析と実際のハードウェアの試行錯誤の組み合わせによる独立したドキュメントプロジェクトです。この作業は、Broadcomまたはその代理店から100％独立しています。一般に公開されているものを超えるBroadcomの文書や資料は使用されていません。

ソフトウェア自体については、The Khronos GroupはOpenGL ESとOpenVGの実装を提供しますが、オープンソースではありません。ウェブサイトからドキュメントを入手できますが、そのような低レベルで何かを見つけることはできません。

希望します。