リソースダッシュボード: 見た目のプロトタイプ¶

index.html をブラウザーで直接開いてください。サーバー、インストール、ネットワーク接続、ハードウェアへのアクセスはいずれも不要です。計測値、ハードウェア名、過去のサンプルはすべて合成データです。

xdg-open examples/resource-dashboard/index.html

暗い背景の 1920 × 1080 の構成は、幅の狭いウィンドウでは全体が縮小されます。映像領域だけを表示するには index.html?video=1 を開きます。この場合も DEMO DATA は表示されたままです。このモードで映像ストリームが生成されるわけではありません。CPU/GPU/DRAM の各パネルは、現在の計測値と塗りつぶしのグラフを組み合わせて表示します。Memory は下段の半分を占め、Power、VCN、VPE が残りの半分を分け合います。CPU/GPU の名前、日付、計測値、グラフは、NVR の小さなタイルに合わせた大きさにしています。軸ラベル、説明用の注記、クロック周波数、プロセスごとの計測値、APU/GFX 別の電力は省いています。

映像領域の外にあるコントロールで、Idle、CPU load、GPU load、Mixed load の選択、一時停止/再開、GPU メトリクスの欠損のシミュレーションを行えます。シナリオの変更は新しいサンプルに適用され、それまでの履歴は保持されます。一時停止すると収集とサンプルの時計が止まり、再開するとシミュレーション上のタイムラインが続きから進みます。メトリクス欠損の設定変更は、次のサンプルから、または再開後に反映されます。

プレビューは生成した 60 秒分の履歴から始まり、100 ms ごとに更新します。履歴は最大 601 サンプル、60 秒の時間幅に制限されます。欠損した計測値、有限でない計測値、存在しない計測値は N/A と表示し、利用できないバーは縞模様にします。線も塗りつぶしも、欠損したサンプルや大きな時間の空きをまたいでは描画しません。CPU/GPU のスケールは 0–100% で固定です。DRAM の読み出し/書き込みは、データに合わせて決まる共通のスケールを 10 進の GB/s で使い、見出しの値は両者の合計です。理論帯域に対する割合は前提にしていません。日付と時刻は、サンプルのタイムスタンプをブラウザーのローカルタイムゾーンで表示します。

合成データによるダッシュボードの例

起動時の電力上限¶

Power バーのスケールの既定値は 48 W です。URL に powerMaxW を指定すると、ワット単位の正の有限な上限値を設定できます。たとえば index.html?powerMaxW=48 や index.html?video=1&powerMaxW=65 のように指定します。映像のみのリンクでもこの設定は保たれます。コントロールには選択中のスケールが表示されます。設定がない場合は 48 W を使います。不正な値、0、負の値の場合は 48 W にフォールバックし、コントロールの横に注記を表示します。

バーは、現在のソケット電力を設定した上限値で割った値を表します。設定した上限を超える計測値もそのまま表示され、バーだけが 100% で振り切れます。欠損した計測値や不正な計測値は N/A と表示し、バーを縞模様にします。この設定は表示用のスケールであり、検出したハードウェアの上限でも、マシンの電力制限を変更するコマンドでもありません。有効な設定は snapshot().config.powerMaxW で確認できます。HTML は引き続き合成の電力値を使います。

メモリの計上方法¶

模擬データは 32 GiB を想定し、Host の容量 30 GiB と、iGPU 用に予約された 2 GiB に分けています。予約された容量と、その予約領域内で実際に使われている量を区別します。メモリの値はすべて 2 進の GiB で表します。

Host、Reserved、Available の各計測値には GiB の単位を付けて表示します。メインのバーの容量は hostTotalGiB + vramReservedGiB で、次の内容を表示します。

Host: hostUsedGiB。OS が計上する GTT 由来のページを含みます。
Reserved: 予約領域 vramReservedGiB の全体。一部が使われていない場合も全体を含みます。
Available: hostTotalGiB − hostUsedGiB。

見出しには、その容量に対する Host used + VRAM reserved を表示します。これは使用できない容量または割り当て済みの容量を表し、アプリケーションが常駐させているバイト数ではありません。メインのセグメントには、GTT を追加の割り当てとして含めることはありません。下段の 2 つの独立したバーで、GTT allocation / GTT allocation limit と VRAM used / VRAM reserved を表示します。GTT は Host から差し引きません。GTT の計上は、独立した物理的なメモリプールを厳密に定めるものではないためです。これらのバーの値をメインのバーに加算してはいけません。GTT の模擬データでは、Host の容量 30 GiB とは独立に、割り当て上限を 24 GiB としています。GTT は使用量/上限として表示し、バーはその上限で正規化します。上限が欠損、0、または不正な場合は GTT の計測値を利用不可とし、Host の容量で代用することはありません。調査した開発用 PC では mem_info_gtt_total から 24 GiB が報告されますが、実際の収集ではこの値を検出する必要があります。

必要な入力が利用できない場合や整合しない場合は、値を 0 として扱わず、該当するバーを縞模様にし、計測値を N/A と表示します。既知の Host の値と独立したバーは読み取れる状態のままです。VRAM の予約領域が利用できない場合は、メインの合計も利用不可になります。負の量や、対応する容量を超える使用量は不正な値です。

今後実装するコレクターは、32 GiB の模擬データではなく、検出した OS の容量と GPU の予約領域を使う必要があります。両者の合計は管理対象の領域を表し、物理的に搭載されたすべての RAM と一致するとは限りません。ファームウェアによる予約や起動時のメモリ制限によって、さらにメモリが除外されることがあります。計画段階で確認した開発用 PC では、起動引数に mem=16G が指定されており、Linux は約 14.27 GiB を報告し、VRAM の予約領域は 2 GiB でした。これらの設定は変更していません。模擬データは計測値ではなく、現在 32 GiB を OS から利用できることを示すものでもありません。

今後のコレクター向けのメトリクスの取得元¶

メトリクスの選定は、参照リポジトリのリソース使用率に関する説明とモニターの実装に従っています。ここでは取得元を記載しているだけで、このバージョンはこれらを収集しません。

表示	想定する取得元と意味
CPU	`/proc/stat` の差分。システム全体の使用率、0–100%
GPU	amdgpu の `gpu_busy_percent`。デバイス全体
Host used / capacity	`/proc/meminfo`、`MemTotal − MemAvailable` / `MemTotal`
VRAM reservation / used	amdgpu の `mem_info_vram_total` / `mem_info_vram_used`
GTT allocation / limit	amdgpu の `mem_info_gtt_used` / `mem_info_gtt_total`。上限は搭載 RAM 量ではない
DRAM read / write	`gpu_metrics` v3.0 の `dram_reads` / `dram_writes`。MB/s を GB/s に換算。SoC 全体で、CPU と GPU の合計
Power	`gpu_metrics` v3.0 のソケット電力。mW を W に換算
VCN	`vcn_busy_percent`。対応している場合のコーデックエンジンの使用率
VPE	観測可能な DRM クライアントの `drm-engine-vpe` のビジー時間の差分を、経過時間とエンジン容量で割った値

メモリの報告と DRM の使用統計については、カーネルのドキュメントを参照してください。GPU メトリクスは、100 ms ごとにサンプリングしても、SMU によって約 1 秒のフィルタリングがかかっている場合があります。欠損したメトリクスや非対応のメトリクスは、利用不可のままにする必要があります。参照マシンの DRAM 理論帯域 256 GB/s は、ほかの APU の既定値ではありません。

VCN は、このシステムがコーデックブロックに付けている名前です（VCU と呼ばれることもあります）。調査した PC では、VPE には vpe_busy_percent に相当するシステム全体の値がありません。今後実装する VPE のコレクターは、デバイスと drm-client-id でクライアントの重複を除き、連続した観測値を使い、公開されているエンジン容量を考慮する必要があります。最初のサンプル、アクセスできないカウンター、非対応のハードウェアでは N/A とする必要があります。クライアントの出現と終了、カウンターのリセットには明示的な処理が必要です。結果は観測可能なクライアントを対象とし、システム全体を網羅するとは限りません。NVR の特定の PID を指定する必要はありません。この HTML の VPE は合成データによるデザイン例にすぎません。

データの境界と次の段階¶

window.ResourceDashboard.ingest(sample) はサンプルのコピーを受け取って描画します。snapshot() は最新のサンプルと履歴の件数を返します。手動でデータを注入する前に、デモを一時停止してください。タイムスタンプはエポックからのミリ秒で、厳密に増加する必要があります。不正なタイムスタンプや順序の乱れたタイムスタンプは拒否されます。実際のコレクターとの連携はありません。サンプルのフィールドは次のとおりです。

{
  timestampMs,
  cpuPct, gpuPct, dramReadGBs, dramWriteGBs,
  hostUsedGiB, hostTotalGiB, vramReservedGiB, vramGiB, gttGiB, gttTotalGiB,
  socketW, vcnPct, vpePct
}

vramGiB は引き続き VRAM の使用量を表し、vramReservedGiB はその容量です。初期のプロトタイプにあったクロック、APU/GFX 別の電力、プロセスのフィールドは削除しました。マシン名は HTML の模擬データのままで、実際のコレクターでは検出したメタデータに置き換えます。データの提供元は、欠損した値に null を指定する必要があります。

ネイティブの RTSP サンプルは、実際の収集、ヘッドレスでの GPU 描画、ハードウェアによる H.264 エンコードを実装しています。この HTML は画面構成を定めるもので、映像のソースとしてブラウザーのキャプチャーを使うことを求めるものではありません。ネイティブの経路では、GPU で描画した共有サーフェスと GPU での色変換を使い、CPU による画素の読み戻しは行わずに、エンコードした出力を RTSP で配信します。HTML 自体はエンコーダーや RTSP サーバーを追加せず、既存の NVR アプリケーションも変更しません。

プロトタイプの検証¶

Chromium でローカルの file:// から読み込んで確認しました。対象は、4 つのシナリオすべて、一時停止/再開、VCN/VPE とメモリを含む GPU メトリクスの欠損と復帰、上限付きの履歴での 125 秒間の高速更新です。サンプル注入による確認では、GTT と VRAM の使用量が変化してもメインの合計が膨らまないこと、予約容量が使用量と区別されたままであること、検出した容量、不正な値、一部だけのデータが正しく扱われることを検証しました。Canvas の画素の確認では、有効なデータの下が塗りつぶされ、欠損したサンプルをまたいでは塗りつぶされないことを検証しました。

画面構成は 1080p でパネルが切れることなく収まり、幅 1920、960、480、320 ピクセルで横方向にはみ出すことなく縮小されます。480 ピクセルでも、主要な計測値、ハードウェア名、グラフの傾向は判別できます。メモリの詳細ラベルは補助的な扱いです。ブラウザーのエラーや外部へのネットワーク要求は発生しませんでした。ローカルの検証記録は artifacts/resource-dashboard/validation-revised.json です。