メインコンテンツまでスキップ

Scheduler と LLiMa の依存関係を使って Core をビルドする

Core は Scheduler と LLiMa の 2 つの依存関係に対してビルドされます。Palette SDK 内の Core チェックアウトで build.sh を実行します。

./build.sh --all --no-doc

既定では、build.sh は次を行います。

  1. 公開済みの Scheduler セットと LLiMa パッケージを Vulcan からダウンロードします。
  2. Scheduler セットをチェックアウトの deps/ フォルダーに展開し、LLiMa を SDK の sysroot にインストールします。
  3. Core をビルドします。

build.sh は Scheduler セットを SDK の sysroot にインストールしないため、1 つの SDK コンテナー内で、複数の Core チェックアウトを異なる Scheduler セットに対して同時にビルドできます。これらのチェックアウトは sysroot の LLiMa を共有します。sysroot に同じパッケージがすでにある場合、build.sh は LLiMa のインストールを省略します。

SDK の sysroot を Scheduler セットに合わせる​

各 Scheduler セットには、ビルド対象の sysroot バージョンが記録されています。build.sh はそれを sysroot status と比較し、一致しない場合は正確な sysroot update コマンドを示す警告を表示します。ビルドの一部として sysroot を更新するには、--update-sysroot を指定します。

./build.sh --all --no-doc --update-sysroot

このオプションは、Core のコンパイル対象となるプラットフォームパッケージを指定して sudo sysroot update <version> を実行します。CI では常にこのオプションを指定します。

ローカルの Scheduler または LLiMa パッケージを使用する​

独自の Scheduler または LLiMa ビルドに対して Core をビルドするには、その DEB フォルダーを渡します。

./build.sh --scheduler ../scheduler-debs --llima ../llima/dist/debs

各オプションは単独で使用できます。もう一方の依存関係は、build.sh が引き続きダウンロードします。指定した Scheduler セットは、このチェックアウトの deps/ フォルダー内の公開済みセットを置き換えます。指定した LLiMa パッケージは、SDK の sysroot 内の LLiMa を置き換えます。

Scheduler フォルダーには、Scheduler のビルドに使用した完全なセットを入れます。

  • simaai-scheduler
  • Scheduler のビルドに使用した simaai-runner と simaai-kernels-dev パッケージ
  • EV 対応ビルド用の、対応する simaai-kernels-firmware パッケージ
  • Scheduler が Codecs を使用する場合の neat-codecs と neat-codecs-dev のペア
  • 任意で simaai-runtime。テストビルドでは simaai-scheduler-client-test-dev

Core は Kernels、Runner、Codecs を選択しません。これらのいずれかの変更をテストするには、Scheduler のビルドガイドに従ってその変更に対して Scheduler をビルドし、生成されたパッケージを 1 つのフォルダーに入れて、--scheduler で渡してください。Scheduler のコーディネーターがパッケージの整合性を確認し、整合しない場合はビルドを停止します。

NEAT_KERNELS_*、NEAT_RUNNER_*、NEAT_SCHEDULER_*、NEAT_CODECS_* のソースまたはパッケージ変数が設定されていると、build.sh はエラーで停止します。LLiMa なしでビルドするには --no-llima を使用します。

プラットフォーム依存関係​

Kernels、Runner、Scheduler、Core を同じ Platform 3.0 SDK/ツールチェーンでビルドします。既定以外のツールチェーンを選ぶ場合は CMAKE_TOOLCHAIN_FILE を設定してください。Kernels と Runner の記録は、ターゲット/コンパイラー、カーネル契約、使用したビルド設定が一致する必要があります。標準パッケージワークフローでは、使用した Kernels ペイロードの正確な識別情報も必要です。Kernels パッケージを変更したら、Runner のソースが変わらなくても、選択した SDK に対して Runner パッケージを再ビルドしてください。その後 Core は対応する Scheduler クライアント実装に再リンクします。下位の数値パッケージは Scheduler が使用します。 Core のソース優先 DEB は、選択された Scheduler と数値 SDK のバージョンを固定します。Runner は Kernels を固定し、Scheduler は Runner、Kernels、有効なコーデックバックエンドを固定します。テストを有効にした Core ビルドには、同じ生成元による Scheduler の個別パッケージ simaai-scheduler-client-test-dev も、同じ Scheduler フォルダー内に必要です。コーディネーターは本番用記録、ソース、ペイロード、アーカイブを確認してから、テスト専用の CMake コンポーネントを公開します。ランタイムのみのビルドには不要です。 ビルドでは、正確な Runner/Scheduler 依存関係を持つメタデータ専用の simaai-runtime 互換パッケージを構成します。標準パッケージのファイル所有権は重複せず、既存のローダー設定は Runner のみが所有します。単一パッケージを置き換えるのではなく、対応するディストリビューション全体をインストールしてください。

GStreamer ヘッダー所有権の移行​

Core 0.6.0 では、/usr/include/gst/SimaaiGstErrors.h の所有権を Scheduler に移します。インクルードパスは変わりません。Core は独自実装やこのファイルのインストールを行わなくなり、コンシューマーはインストール済み Scheduler ヘッダーと SimaScheduler::Headers ターゲットを使用します。

完全な一致するディストリビューションを使って、Core と Scheduler を一緒にアップグレードしてください。 Scheduler は、修正済み Core 0.6.0 パッケージを非互換とせずに、0.6.0 系パッケージからのヘッダー移管を宣言します。 APT がファイルを変更する前に、インストーラーは認証済みの Scheduler 所有権チェックを使います。 以前の所有パッケージは、同じパッケージセット内でそのファイルを含まないパッケージに置き換えるか、明示的に宣言され承認された廃止の対象である必要があります。 受信パッケージ間の重複所有や、無関係な所有権の競合は拒否されます。

Platform 3.0 では、完全な分割パッケージセットへの移行に伴い、モノリシックな neat-runtime、neat-gst-plugins、neat-internals-dev の 0.4、0.5、0.6.0 系も、開発ビルドを含めて廃止します。 廃止には、新しい所有パッケージによる、バージョン範囲を限定した一致する Breaks と Replaces の宣言が必要です。 0.6.1~ 以降のバージョンは対象外です。無関係なパッケージの削除を許可するものではなく、廃止された API との互換性も保証しません。 ランタイムとプラグインのファイル移管は Scheduler が宣言し、完全なランタイムには実行依存関係として一致する Runner も必要です。 Runner 単体のインストールでは、モノリシックな 0.6.0 パッケージは廃止しません。

EV を有効にした Modalix ディストリビューションには、Scheduler が選択した対応する simaai-kernels-firmware パッケージが必要です。 ファームウェアが不足しているか一致しない場合、受け入れ検証は失敗します。 古い neat-ev74-firmware パッケージを置き換えるには、選択したそのファームウェアパッケージが、対象バージョンに一致する Replaces と、Breaks または Conflicts を宣言する必要があります。通常のトランザクション検証と削除検証も適用されます。 ファームウェアの有効化には、有効化ヘルパーを提供する唯一の受信パッケージだけを使用します。 インストール済みパッケージの識別情報と、ヘルパーの所有権、実行モード、バイト列が、選択したパッケージと一致する必要があります。 選択したヘルパーが一致しない場合、インストールは失敗します。 EV74 ファームウェアを必要としないディストリビューションでは、ヘルパーがなくても既存のファームウェアは変更されません。 インストーラーは、以前のインストールで残されたヘルパーを使用しません。

DevKit でのインストールが中断された場合は、検証済みの完全なディストリビューションを再実行してください。 インストーラーが未完了のパッケージを復旧できるのは、そのパッケージが受信セットに属し、アーキテクチャが一致する場合だけです。 復旧では、無関係なパッケージを変更せず、選択した正確なバージョンをインストールする必要があります。 削除できるのは、受信コホートが廃止を明示的に宣言し、既存の削除チェックが承認した、設定済みで保留されていない旧パッケージだけです。 復旧では、まず承認された移行を完了し、パッケージの状態を確認してから、削除を禁止した状態で選択済みの全パッケージを再インストールします。インストールが成功するのは、この最終再インストールが完了した後だけです。 無関係なパッケージデータベースの不整合は別途修復してください。インストーラーは一般的な APT 修復を行わず、ロールバックも保証しません。

既存の Core 開発パッケージがある環境に Scheduler の DEB だけをインストールしたり、--force-overwrite を使ったり、dpkg 所有のファイルを削除したりしないでください。 独立した Scheduler テストイメージに Core は不要ですが、既存の Core インストールには協調したアップグレードが必要です。

増分ビルドとインストール​

ビルドのたびに、選択された Scheduler セットが deps/scheduler/ で更新され、そのパッケージが deps/backend/ にステージングされます。CMake は Core を増分ビルドします。--clean は Core のビルドも削除します。

リンク前に Scheduler の依存関係コーディネーターが、インストール済みカーネルヘッダーを記録と照合し、Runner が使用した契約と Scheduler の正確な Runner 入力を確認します。デプロイ用パッケージをステージングする前には、各 Debian パッケージの /usr ペイロードが選択済みインストールツリーと一致することを検証します。旧 Internals パッケージの選択やダウンロードは行いません。

Core が使用するのはインストール済み SimaScheduler クライアントコンポーネントであり、隣接ソースのインクルードや下位の開発インターフェースではありません。下位ランタイムの識別情報は検証済みの依存関係一式に残ります。生成された依存関係の選択は build/resolved_manifest.json と build/buildinfo.json に記録されます。完全なビルドだけが最終インストールに進みますが、これは SDK やデバイスへのインストールにトランザクション型ロールバックを保証するものではありません。

CMake 設定前のパッケージビルド情報は暫定値です。コンパイル後、build.sh はインストール確認やパッケージ化の前に、そのビルドの CMake キャッシュ、設定済みコンパイラー、ターゲット Python ヘッダー、ビルドした拡張から情報を更新します。ターゲット Python の ABI フラグは拡張のサフィックスと一致する必要があります。ホスト Python バージョンは使用しません。Python 無効ビルドは Python ABI を付けずにそのプロファイルを記録します。

compatibility.host_sdk はビルドホストで観測された SDK リリースを表し、compatibility.target_sdk は選択済み sysroot とコンパイラーを表します。ターゲット SDK リリースを取得できなければ、ホスト SDK リリースが存在しても未取得のままです。マニフェストのプラットフォームバージョンは別の互換性要件であり、未観測の SDK バージョンを代用しません。ELXR_SDK_RELEASE_FILE はホストのリリースファイルを選択します。NEAT_TARGET_SDK_RELEASE_FILE でターゲットのリリースファイルを明示できますが、選択した sysroot 内のリリースファイルと一致する必要があります。NEAT_BUILDINFO_TOOLCHAIN は、設定済みコンパイラー識別情報を置き換えず、その横に明示的な表示ラベルを保持します。

メタデータ確認は、矛盾するコンパイル sysroot、ヘッダー、拡張 ABI タグを拒否します。このメタデータ経路は、コンパイル/リンクで異なる sysroot や、追加の CMake コンパイラー引数/ターゲット/ツールチェーンコンテキストには対応しません。未検証のターゲット識別情報を報告するのではなく失敗します。マーカー付き NumPy 要件は、単一の無条件の最小値にまとめず、pyproject.toml からそのまま保持します。

ソース記録は実際のチェックアウトのコミットと変更状態を使用します。追跡対象の変更と、無視対象でない未追跡ファイル/シンボリックリンクの識別情報は別々に記録します。無視されたビルド生成物はソーススナップショットではありません。自己参照を避けるため、メタデータ出力自体は未追跡コンテンツのダイジェストから除外します。変更のあるローカル候補を、クリーンな公開アーティファクトとして識別することはありません。

ヘッダーのみの依存関係準備では、--install-deps-only は --scheduler フォルダーを使用するか、公開済みセットをダウンロードします。A65/EV コードのビルドや実行はせず、ヘッダーをコピーします。ネイティブ clang-tidy 解析には、選択した Scheduler と対応するテスト支援パッケージのプレフィックスを使って scripts/run_cpp_tidy.sh を実行します。TIDY_INSTALL_DEPS=1 はネイティブホストの解析前提条件をインストールします。スクリプトは各パッケージの公開 CMake エクスポートを直接使用し、SDK sysroot の有効化や変更はしません。LLiMa を使用する GenAI 実装ファイルは、このホスト専用解析プロファイルの対象外です。スクリプトは選択済みビルドの依存関係を、環境内の SDK LLiMa パッケージで置き換えません。ドキュメントのみのビルドではネイティブ依存関係を準備しません。

EV デバイスのビルドは、引き続きライセンスを必要とする別のワークフローです。これらのコマンドが暗黙に MetaWare を呼び出したり、ファームウェアを置き換えたり、変更したファームウェアを検証済みとしたりすることはありません。

公開済み CI 依存関係​

通常の Vulcan ビルドは deps/manifest.json の Scheduler ポリシーを sima-cli で解決し、選択した不変の公開物をダウンロードします。LLiMa と同様に、ブランチの snap はまず現在の Core ブランチを試します。解決に失敗し、Scheduler の公開ブランチ一覧でそのブランチが存在しないと確認できた場合に限り、フォールバックを通知して develop:latest を再試行します。一覧を取得できない場合や一覧が無効な場合を含め、その他の検索失敗はエラーのままです。タグの snap と明示的なブランチ/コミット指定はフォールバックしません。デバイスと PCIe ホストの取得はこのポリシーを共有し、PCIe の --scheduler-spec <commit> も厳密に適用されます。解決後のダウンロード、検証、ブートストラップ、ステージングの失敗はエラーのままです。記録には実際に選択したブランチと不変のコミットが保持されます。tools/ci/acquire_scheduler.py は公開元ハッシュを検証してから Scheduler のブートストラップを実行します。インストール済み Scheduler コーディネーターが、同梱された Runner、Kernels、Codecs のアーカイブを区分して検証します。Core がこれらのリポジトリを個別に解決することはありません。

選択した Scheduler パッケージは、正確な SDK ポリシーをインストールします。SDK 内では、build.sh が scripts/ci/prepare_scheduler_sdk.sh を実行します。このスクリプトが sysroot のバージョンを確認し、Runner が使用する正確なプラットフォームアーカイブを専用の APT 設定で deps/ にダウンロードします。sysroot update は --update-sysroot を指定した場合にのみ実行します。コーディネーターは実際の GCC14 バージョン/ターゲットとターゲット SDK 識別情報を確認し、NEAT_RUNNER_PLATFORM_RUNTIME_DEBS を通して Runner が使用した正確なランタイムプロバイダーアーカイブを選択します。ネイティブ ARM64 コンパイラーとクロスコンパイラーの実行ファイルのバイト列は同一でなくてもかまいませんが、ターゲット ABI と選択したプラットフォームは一致する必要があります。この段階でデバイスへのインストールやファームウェアの検証は行いません。

--scheduler フォルダーがダウンロードと混在したり、ダウンロードに置き換えられたりすることはありません。既存の tools/ci/materialize_dependencies.py --manifest ... --output-root ... コマンドは、別途レビュー済みの不変マニフェストを転送するための任意の手段として残ります。既定のワークフローではなく、暗黙の ci/dependencies.json もありません。

コード衛生チェックは tools/ci/acquire_scheduler.py を使い、同じ依存関係ポリシーに従って公開済み Scheduler を個別に取得するため、Core のビルド完了を待ちません。Scheduler のブートストラップがパッケージ群を検証します。ホスト解析は、そのフロントエンドと対応するテスト支援用の CMake エクスポートを使用し、SDK の有効化やターゲット実行は行いません。

保護された性能レーンに必要なターゲット側スーパーバイザーについては、ハードウェアテストの所有権を参照してください。

完成したディストリビューションを検証する​

build.sh --all はパッケージメタデータを生成した後、完成したディストリビューションを確認します。CI では scripts/ci/verify_core_dist.sh が、選択された sima-cli の Python 環境で同じ読み取り専用チェックを実行します。インタープリターが選択済み CLI 実行ファイルと同じ場所にない場合は、SIMA_CLI_PYTHON を明示的に設定してください。

チェックでは、依存パッケージのバイト列、互換性フィールド、インストーラーの許可リスト、全リソースのチェックサム、公開 wheel の分離、インストール済み CTest ツリーを検証します。既存の生成元記録を使用し、依存関係の解決や修復は行いません。次の文書を区別してください。

  • dist/manifest.json: プラットフォーム、Model Zoo、ABI の互換性。
  • dist/resolved-deps-manifest.json: 選択済みバックエンド記録の完全なコピー。
  • build/resolved_manifest.json: より詳細な Core ビルドの解決結果。

この確認後にファイルを置き換えたり、選択されたチェックサムを再計算したりしないでください。アーティファクトが変わった場合はメタデータを再生成し、ディストリビューション全体を再検証します。

明示的なプラットフォームプロバイダーパッケージ​

Core の本番用ボックス/マスク公開は int32 座標を使用します。標準 Kernels レンダリングと対応する Runner 実行 API を使用してビルドされた Scheduler を選択してください。SIMANEAT_REQUIRE_INT32_RENDERER の既定値はランタイムアーティファクト要件に従い、インストール済み Scheduler にこの機能がなければ設定は失敗します。OFF にしてよいのは、Core のボックス/マスクレンダリングを使わない Core プロファイルだけです。

レンダリングは、個別のプラットフォームレンダラーアーカイブではなく、選択された Kernels/Runner パッケージを使用します。要求 API リビジョン 2 に向けてコホート全体を一緒に再ビルドしてください。

SDK 内では、build.sh が scripts/ci/prepare_scheduler_sdk.sh を通して次を設定します。SDK 外では、次を用意します。

  • NEAT_RUNNER_PLATFORM_RUNTIME_DEBS: Runner が選択した正確なランタイムプロバイダー DEB の絶対パスを並べた JSON 配列。必須の SimaHeap ランタイムアーカイブと、有効な場合は MLA および TVM ランタイムアーカイブを含めます。この配列に開発アーカイブを含めないでください。Runner は実際のローダー名とライブラリのバイト列を検証します。Scheduler は正確なアーカイブ識別情報とペイロード一覧をビルド証拠として保持します。Runner が Platform 所有と宣言したプロバイダーは Core のインストール可能 DEB 一式には含めず、未宣言のプロバイダーは正確なアーカイブ構成を維持します。

この選択は、--scheduler フォルダーを使う場合も明示的に行います。不変の 4 コンポーネント取得ツールは、プラットフォームプロバイダーアーカイブを取得しません。Core を呼び出す前に、対応する生成元から取得してください。プロバイダーが欠けているか実際に使用されていない場合は、sysroot にフォールバックせず失敗します。コンパイルには対応する開発パッケージを使用します。DevKit では、Scheduler の認証済み実行許可ツールが、パッケージ変更の前に、インストール済み Platform プロバイダーが導入予定のコンシューマーに適合するか確認します。インストーラーはこれらのプロバイダーを置換/削除する APT 計画を拒否し、処理後にプロバイダー識別情報とインストール済みコンシューマーの依存関係全体を検証します。FORCE_INSTALL はこの確認を免除しません。非公開 DSO をリリース済みプロバイダーと表示するためだけに DEB を再ビルドしないでください。

パッケージ構成チェックは、ペイロード所有権の非重複、正確な依存バージョン、アーカイブが未変更であることを確認します。これらのビルド時チェックは、数値実行、動的マスク、ハードウェアの終了を検証済みとするものではありません。それらには、選択したターゲットコホートで対応する統合テストが必要です。