Linux: コミュニティ向けのRPi固有のOS開発計画の可視性?

作成日 2018年02月13日  ·  8コメント  ·  ソース: raspberrypi/linux

Eric AnholtのVC4ドライバーに関する最近の
エベンはフォーラムで時折それらを与えましたが、止まったようです(または私はそれらを見るのをやめましたか?)。

たぶん、他の人もこの問題を見て、コメントしたり、親指を立てたり下げたりする反応で自分の気持ちを示したいと思っています。

良いアプローチは、githubの「Milestone」または「Project」機能を使用して可視性を作成することです。
他のプロジェクトが彼らの意図と優先順位をどのように伝えるかについての私の見解からの良い例はここにあり

その他の関連する未解決のトピックは、貢献とガバナンスのプロセスです。
良い例はここます

最も参考になるコメント

個人的には、より詳細な変更ログを確認したいと思います(たとえば、常に「新しいカーネル、新しいファームウェア」と表示されますが、何が変更または修正されたかについての説明はありません)。

たとえば、カーネルとファームウェアについては、ここGithubで非常にオープンですが、Raspbianリリースについては、そのいずれも表示されません。Raspbianリリースは「今どこからでもポップアップする」ように見えます;)

全てのコメント8件

過去数年間を振り返って、コミュニティが事前の通知から恩恵を受けたであろう進展として何を特定しますか?

夜が明けると、Linuxのバージョン数は増えます。 すべてのリリース候補が製品コードに到達するわけではありませんが、各リリース候補の動作バージョンをできるだけ早く入手するようにしています。 同時に、ペースははるかに遅いものの、Debianはメジャーリリースを発表しており、将来的にはバスターに移行する可能性があります。

Raspberry Pi自身のソフトウェア開発は通常、ハードウェアリリースに関連付けられており、それらの事前通知を期待している場合は、がっかりするでしょう。

Philが言うように、多くのものがハードウェアのリリースに関係しています。

エリックが報告しているもののほとんどすべては、しばらくの間進行中のものですが、彼がここにいる間、私たちは(偽の)KMSをメインラインに近づけるために不足しているビットについて話し合い、特定する機会がありました。
彼はコーデックとカメラの経験が非常に限られていますが、3DとKMSについてはたくさんあります。 私はV3Dについての知識が非常に限られており、一般的な構成についてはさらに知識があり、コーデックとカメラについてはたくさんの知識があります。 2つを組み合わせて、知識の一部を渡すと、ある程度の進歩が得られます:-)

個人的には、より詳細な変更ログを確認したいと思います(たとえば、常に「新しいカーネル、新しいファームウェア」と表示されますが、何が変更または修正されたかについての説明はありません)。

たとえば、カーネルとファームウェアについては、ここGithubで非常にオープンですが、Raspbianリリースについては、そのいずれも表示されません。Raspbianリリースは「今どこからでもポップアップする」ように見えます;)

@pelwellが頭のてっぺんから離れて、

参照: https

@pelwell @ 6by9 VC、ファームウェア、デスクトップなどのRPIスペシャルに関する事前通知の恩恵を受けます。
新しいハードウェアは明らかに範囲外です。

例はVC4ドライバーで、Ericのブログ投稿は「誰かがする必要がある」と説明されている「いくつかのルーズエンド」を示しています。
マイルストーンを介して必要なすべてのアクティビティを結び付けると、貢献者を引き付けてそれらをピックアップする可能性があり、その結果、計画されたVC4の改善を「

マイルストーンを介して必要なすべてのアクティビティを結び付けると、貢献者を引き付けてそれらをピックアップする可能性があり、その結果、計画されたVC4の改善を「もうgpu_mem =を必要としない」より早くマージできるようになります。

それはファームウェア内で重要な作業を必要とし、それに伴うvc-smの新しいバージョンでの作業(アップストリームの可能性が少ないことを願っています)を考えると、それは共有できるものではありません。

次に、gpu_memからcmaへの移行をどのように管理するかについて必要な主要な議論があります。 vc-smを介した新しいリモート割り当てでは、メモリを割り当てるためのラウンドトリップレイテンシがパフォーマンスを低下させるため、レガシーファームウェアGLESスタックが機能しなくなります(ビデオデコード/カメラがすべての割り当てを前もって行うため、比較的マイナーなセットアップです)時間の増加)。 したがって、CMAとgpu_memを切り替えるには、ユーザーが実行しているモードを特定するために、デバイスツリーノードを確認するファームウェアに何らかの魔法が必要になります。現在のデバイスツリーの処理はすべてgpu_memの後に行われるため、さらに複雑になります。すでに割り当てられています。
ファームウェアのように共有することはできないため、マイルストーンとして設定してもメリットはありません。

KMS用に提案されたDispmanXシム、および場合によっては転置用のライトバックコネクタの詳細をレイアウトすることには、いくつかの利点がある可能性があります。 前者は、DispmanXを知っているように、主にRPT次第ですが、主な障害は、X11とコンソールベースのシステムの間で異なるソリューションを用意する必要があることです。 後者のエリックはいくつかのアイデアを持っているので、肉付けするのは彼次第です。

@ 6by9に感謝します。
将来のある時点で、「gpu_memからcmaへの移行を管理する方法」の計画についてもっと見るのを楽しみにしています。

これは実際にはカーネルの問題ではないので、終了します。 ただし、問題の最後にコメントを追加してください。

このページは役に立ちましたか?
0 / 5 - 0 評価