OpenXLA には誰でも貢献でき、すべての貢献を高く評価しています。投稿方法はいくつかあります。
OpenXLA のディスカッション フォーラム（openxla-discuss）での質問への回答
OpenXLA のドキュメントの改善または拡張
OpenXLA のコードベースへの貢献
OpenXLA 上に構築されたライブラリのより広範なエコシステムに上記の方法で貢献する
OpenXLA プロジェクトは、Google のオープンソース コミュニティ ガイドラインに準拠しています。
始める前に
コントリビューター ライセンス契約に署名する
このプロジェクトへの投稿には、投稿者ライセンス契約（CLA）が必要です。コントリビューションの著作権は、あなた（またはあなたの雇用主）が保持します。このライセンスは、プロジェクトの一部としてコントリビューションを使用および再配布する権限を Google に付与するものです。
あなたまたは現在の雇用主がすでに Google CLA に署名している場合（別のプロジェクトのものであっても）、再度署名する必要はない可能性があります。
現在の契約を確認したり、新しい契約に署名したりするには、<https://cla.developers.google.com/> にアクセスしてください。
行動規範を確認する
このプロジェクトは、Tensorflow の行動規範に準拠しています。
投稿プロセス
デベロッパー ガイド
コードの取得、ビルド、テストの実行、変更の送信など、OpenXLA の開発環境の設定方法については、デベロッパー ガイドをご覧ください。
貢献ガイド
コンパイラのアーキテクチャは、次のコンポーネントで構成されています。
最適化パス
最適化パスは、HLO で変換を実行して計算効率を高めます。これらの変換は、アーキテクチャに依存しない高レベルの改善から、ハードウェア固有の調整（NVIDIA GPU など）まで多岐にわたります。
通常、承認されるもの:
- 複数のワークロードにわたって一般化され、パフォーマンス ベンチマークに明確かつ大きなプラスの影響を与えるパス。
通常、不承認となるもの:
- 特定のモデルを対象とした独自の最適化を実行するパス。
Fusion パス
融合は、複数の HLO オペレーションを 1 つのカーネルに結合して、メモリ I/O とカーネル起動のオーバーヘッドを削減する重要な最適化です。
すべてのフュージョン パスは、フュージョン パイプラインにのみ追加する必要があります。前や後に追加してはいけません。つまり、事前最適化された HLO モジュールには融合命令を含めるべきではありません。融合がパイプラインの早い段階で形成されると、最適化パスの障壁になります。融合が遅れて形成されると、生成された融合のバックエンドを選択して調整する機能が失われます。
カスタム呼び出しへの統合（プロデューサー/コンシューマーとのパターン マッチング カスタム呼び出し、および新しいカスタム呼び出しへの書き換え）は許可されていません。その場合は、適切なフュージョン パスに置き換える必要があります。
水平方向のスケーリング
水平スケーリングへの貢献には、HLO の最適化、費用モデルの改善、ライブラリの更新、さまざまなインフラストラクチャの変更が含まれます。パフォーマンスの向上を再現することが難しいことと、マルチホスト構成の社内での必要性が限られているため、厳しい承認基準を遵守しています。
リスクの低い最小限の変更を優先します。
通常、承認されるもの:
GPU 間またはホスト間通信を処理するライブラリの更新。
新しいプラットフォームのパフォーマンス表を更新しました。
通常、不承認となるもの:
特定のモデルに合わせて調整された HLO の書き換えまたはランタイムの変更。
新しいフラグ、技術的負債、回帰を導入するインフラストラクチャの変更。
バックエンドと自動チューニング
ネストされていないオペレーション（カスタム呼び出しやフュージョンなど）のバックエンドは、CodegenBackend インターフェースを実装する必要があります。
このインターフェースは、最適なバックエンドの選択を可能にするために必要です。これは、特定の HLO 命令のパラメータを自動チューナーの検索空間に含めるメソッドを提供するためです。
// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
GetSupportedConfigs(const HloInstruction& instr);
// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
const HloInstruction& instr);
ランタイム
XLA コンパイル パイプラインの最終結果は、シリアル化可能なサンク シーケンスです。
新しいサンク型はすべてシリアル化可能である必要があります。つまり、GpuCompiler または CpuCompiler でプログラムをコンパイルしてシリアル化し、後で XLA ランナーがプログラムを読み込んで実行できるようにする必要があります。つまり、HloInstruction やコンパイラの他の部分、StreamExecutor へのポインタは存在しないはずです。
コード標準
コーディング スタイル: Google のコード スタイルガイドに沿って作成します。特に、C/C++ ガイドと Python ガイドをご覧ください。提出されるコードはすべて、これらのスタイルガイドに厳密に準拠している必要があります。
変更をコンパクトに: Google のエンジニアリング プラクティスに準拠しています。特に、コンパクトな変更の作成に関するガイドをご覧ください。そうすることで、レビューのしやすさが向上し、変更による意図しない副作用が発生する可能性が低くなるため、コードをマージする速度が大幅に向上します。大きな変更がある場合でも、それをより段階的な変更に分割するための戦略はたくさんあります。
テスト カバレッジ: すべての変更には適切な単体テストを含める必要があります。単体テストは特定のハードウェア（CPU、GPU など）のタイミングに依存すべきではなく、決定論的で集中的なテストを行うために、モックとフェイクを自由に使用すべきです。現在テストが難しい既存のコードを拡張しようとする変更では、テスト可能性を適切に改善する必要があります。
変更のメリットを明確に理解できるように、変更のタイトルには適切なベンチマーク結果もすべて含める必要があります。
コード内の規約について不明な点がある場合は、既存のコードを調べて、OpenXLA で既に確立されているパターンに従うことをおすすめします。
審査プロセス
プロジェクト メンバーによる送信を含め、すべての送信には審査が必要です。この目的で GitHub pull リクエストを使用します。pull リクエストの使用方法については、GitHub ヘルプをご覧ください。
コードは、審査前に上記のすべての基準を満たしている必要があります。これらは省略できません。変更をタイムリーに受け入れるためには、レビューをリクエストする前に、コードが準拠していることを提出者が確認することが重要です。
すべてのテストに合格する必要があります。テストが壊れていて、その問題がビルド環境や変更に関連していない場合は、メンテナーにお問い合わせください。
審査プロセス中にスコープ クリープが発生しないようにしてください。これは、送信者と審査担当者の両方の責任です。変更が大きくなりすぎた場合は、複数の変更に分割することを検討してください。
変更が統合される前に、Google 内部のコードや他のハードウェア ベンダーのコードを使用した内部テストが行われます。公開 CI で検出されない内部テストの失敗がある場合、審査プロセスに余分な手順が追加される可能性があります。変更を審査する Google 社員が、内部テストの失敗について連絡し、修正が必要な内容を説明します。
よくある質問（FAQ）
「このインフラストラクチャの変更は私の PR とは関係ありません。なぜそうする必要があるのですか？」
XLA チームには専用のインフラストラクチャ チームがないため、ヘルパー ライブラリを構築し、技術的負債を回避するのは私たち全員の責任です。これは XLA の変更の通常のプロセスの一部と見なされ、すべての人が参加することが期待されます。通常、コードを記述するときに必要に応じてインフラストラクチャを構築します。
XLA レビュー担当者から、作成した PR とともにインフラストラクチャの構築（または PR の大幅な変更）を求められることがあります。このリクエストは、不要であるか、変更しようとしている内容と直交しているように見えるかもしれません。これは、構築する必要があるインフラストラクチャの量に関する期待と、レビュー担当者の期待との間に不一致があることが原因である可能性があります。
期待の不一致は問題ありません。プロジェクトに慣れていない場合は、このようなことが起こる可能性があります（経験豊富なメンバーにも起こることがあります）。過去に携わったプロジェクトでは、異なる期待が寄せられていた可能性があります。これも問題なく、想定内です。どちらのプロジェクトのアプローチが間違っているというわけではなく、単にアプローチが異なるだけです。インフラストラクチャ リクエストと他のすべてのレビュー コメントを、このプロジェクトで求められていることを学ぶ機会として捉えてください。
「今後の PR でコメントについて言及してもよろしいでしょうか？」
PR のインフラストラクチャ リクエスト（またはその他の大規模なリクエスト）に関してよくある質問は、変更を元の PR で行う必要があるかどうか、または将来の PR でフォローアップとして行うことができるかどうかです。
一般に、XLA では、PR の作成者がフォローアップ PR でレビュー コメントに対応することはできません。レビュー担当者が特定の PR で対応が必要な事項があると判断した場合、リクエストされた変更が大規模なものであっても、通常は作成者がその PR で対応することが求められます。この基準は、外部だけでなく Google 内部にも適用されます。
XLA がこのアプローチを採用している理由はいくつかあります。
信頼: レビュー担当者の信頼を得ることが重要な要素です。オープンソース プロジェクトでは、コントリビューターは自由に現れたり消えたりできます。PR を承認した後、レビュー担当者は、約束されたフォローアップが実際に実行されることを確認する方法がありません。
他のデベロッパーへの影響: XLA の特定の部分に触れる PR を送信した場合、他のユーザーも同じ部分を見ている可能性が高くなります。PR で技術的負債が受け入れられると、このファイルを閲覧しているすべてのユーザーは、フォローアップが送信されるまでこの負債の影響を受けます。
審査担当者の帯域幅: 変更をフォローアップに延期すると、すでに過負荷状態の審査担当者に複数のコストがかかります。レビュー担当者は、フォローアップを待っている間に最初の PR の内容を忘れてしまい、次のレビューが難しくなる可能性があります。また、審査担当者は、予定されているフォローアップを追跡し、実際にフォローアップが行われるようにする必要があります。変更が元の PR と完全に直交するように行われ、他のレビュー担当者がレビューできる場合は、帯域幅の問題はそれほど大きくありません。経験上、このようなケースはまれです。