アカウント名:
パスワード:
デスクトップのコンポジット処理をグラフィクスapiからkmsのプレーンに移すのは、多くのハードウェアで消費電力上有利だと思われる、また例えばゲームなどgpuのレンダリング作業から切り分けれるので、性能をわずかでもより引き出せるだろう。
linuxのXorgでは、プライマリプレーンとカーソル用のプレーンの2つだけしか使えない仕組みだったが、waylandでは、コンポジターが直接ハードウェアオーバーレイをkmsを通じて扱えるので、さらなる最適化が可能である。
しかし、現状kwinもmutterもwlrootsもカーソル用以上にオーバレイを活用していない、wlrootsのコントリビューターであるemersionはlibliftoffなどのオーバーレイ管理用のライブラリに取り組んでいるが、まだコンポジターの作業を適切にオフロードするところまで行ってないようだ。(ちなみに、westonは部分的にオフロードしてると聞いた)
libliftoffが取り組んでいるのはコンポジターが要求するサーフェスの要件に合うオーバーレイを探し、なるべく効率良く使うため、どのように割り当てるのか、また再割り当ての挙動をどうするのかなどであったと思う。
また、ハードウェアによって扱えるオーバーレイに制限がそれぞれあり、オフロードできる作業が異なっている点や、ctrtのコネクターとエンコーダーの組み合わせによってもそれぞれ制限があることだ。
ハードウェアの低レベルなアクセスなので仕方ないが、libliftoffなどのライブラリがうまく抽象化してコンポジターから扱いやすくなり、wlrootsなどでうまくオフロードできるようになり、消費電力が減り、ノートパソコンのバッテリー駆動時間が伸びることを願う。
(自分の理解だと、gpuのフレームバッファからエンコーダへの転送時、暗黙のメモリコピーが発生するが、この時、読み取る順番や配置する位置などハードウェアによっていじることができるものがあって、追加のメモリコピーなしに、一部のコンポジット作業を肩代わりさせられる)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
オーバレイによるコンポジットのオフロード (スコア:1)
デスクトップのコンポジット処理をグラフィクスapiからkmsのプレーンに移すのは、多くのハードウェアで
消費電力上有利だと思われる、また例えばゲームなどgpuのレンダリング作業から切り分けれるので、性能をわずかでもより引き出せるだろう。
linuxのXorgでは、プライマリプレーンとカーソル用のプレーンの2つだけしか使えない仕組みだったが、
waylandでは、コンポジターが直接ハードウェアオーバーレイをkmsを通じて扱えるので、さらなる最適化が可能である。
しかし、現状kwinもmutterもwlrootsもカーソル用以上にオーバレイを活用していない、
wlrootsのコントリビューターであるemersionはlibliftoffなどのオーバーレイ管理用のライブラリに取り組んでいるが、
まだコンポジターの作業を適切にオフロードするところまで行ってないようだ。
(ちなみに、westonは部分的にオフロードしてると聞いた)
libliftoffが取り組んでいるのはコンポジターが要求するサーフェスの要件に合うオーバーレイを探し、
なるべく効率良く使うため、どのように割り当てるのか、また再割り当ての挙動をどうするのかなどであったと思う。
また、ハードウェアによって扱えるオーバーレイに制限がそれぞれあり、オフロードできる作業が異なっている点や、
ctrtのコネクターとエンコーダーの組み合わせによってもそれぞれ制限があることだ。
ハードウェアの低レベルなアクセスなので仕方ないが、
libliftoffなどのライブラリがうまく抽象化してコンポジターから扱いやすくなり、
wlrootsなどでうまくオフロードできるようになり、消費電力が減り、ノートパソコンのバッテリー駆動時間が伸びることを願う。
(自分の理解だと、gpuのフレームバッファからエンコーダへの転送時、暗黙のメモリコピーが発生するが、
この時、読み取る順番や配置する位置などハードウェアによっていじることができるものがあって、追加のメモリコピーなしに、一部のコンポジット作業を肩代わりさせられる)
Re:オーバレイによるコンポジットのオフロード (スコア:1)