▶ アドバンスト・マイクロ・ディバイシズ・インコーポレイテッドの特許一覧 ▶ エーティーアイ・テクノロジーズ・ユーエルシーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-20
(54)【発明の名称】最適化されたサービスベースのパイプラインの提供
(51)【国際特許分類】
G06F 9/50 20060101AFI20240912BHJP
【ＦＩ】
G06F9/50 120Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024519003
(86)(22)【出願日】2022-09-23
(85)【翻訳文提出日】2024-05-09
(86)【国際出願番号】 US2022044605
(87)【国際公開番号】W WO2023055670
(87)【国際公開日】2023-04-06
(31)【優先権主張番号】17/487,480
(32)【優先日】2021-09-28
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】591016172
【氏名又は名称】アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド
【氏名又は名称原語表記】ＡＤＶＡＮＣＥＤ ＭＩＣＲＯ ＤＥＶＩＣＥＳ ＩＮＣＯＲＰＯＲＡＴＥＤ
(71)【出願人】
【識別番号】508301087
【氏名又は名称】エーティーアイ・テクノロジーズ・ユーエルシー
【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ
【住所又は居所原語表記】Ｏｎｅ Ｃｏｍｍｅｒｃｅ Ｖａｌｌｅｙ Ｄｒｉｖｅ Ｅａｓｔ， Ｍａｒｋｈａｍ， Ｏｎｔａｒｉｏ， Ｌ３Ｔ ７Ｘ６ Ｃａｎａｄａ
(74)【代理人】
【識別番号】100108833
【弁理士】
【氏名又は名称】早川 裕司
(74)【代理人】
【識別番号】100111615
【弁理士】
【氏名又は名称】佐野 良太
(74)【代理人】
【識別番号】100162156
【弁理士】
【氏名又は名称】村雨 圭介
(72)【発明者】
【氏名】ダニエル ウェイヒム ウォン
(72)【発明者】
【氏名】アレン ジェイ． ポーター
(57)【要約】
最適化されたサービスベースのパイプラインは、アプリケーション等のワークロードイニシエータからワークロードの記述を含むリクエストを受信するリソースマネージャを含む。リソースマネージャは、複数の処理リソースのランタイム利用率メトリクスを特定し、複数の処理リソースは、少なくとも第１のグラフィックス処理ユニット（ＧＰＵ）及び第２のＧＰＵを含む。リソースマネージャは、利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロードに対するワークロード割り当て推奨を決定する。その結果、ワークロードイニシエータは、システムのランタイム挙動及びワークロードの確立されたポリシーに基づいて、特定の処理リソース上にワークロードを配置することが好ましいかどうかを判断することができる。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
サービスベースのパイプラインを提供する方法であって、ワークロードイニシエータからワークロードの記述を含むリクエストを受信することと、
少なくとも第１のグラフィックス処理ユニット（ＧＰＵ）及び第２のＧＰＵを含む複数の処理リソースのランタイム利用率メトリクスを調べることと、
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することと、を含む、
方法。
【請求項2】
前記第１のＧＰＵは、中央処理装置（ＣＰＵ）と統合された統合型ＧＰＵであり、前記第２のＧＰＵは、ディスクリートＧＰＵである、請求項１の方法。
【請求項3】
前記複数の処理リソースは、ビデオ符号化／復号アクセラレータ、オーディオ符号化／復号アクセラレータ、ディスプレイコントローラ、バスインターフェースコントローラ、及び、メモリサブシステムコントローラのうち少なくとも１つを含む、請求項１の方法。
【請求項4】
前記ワークロードイニシエータに、前記リクエストを送信するためのアプリケーションプログラミングインターフェース（ＡＰＩ）を公開することを含む、請求項１の方法。
【請求項5】
前記リクエストに応じて、前記ワークロードイニシエータに前記ワークロード割り当て推奨を提供することを含む、請求項１の方法。
【請求項6】
少なくとも前記ワークロードの記述に基づいて、前記ランタイム利用率メトリクス及び前記１つ以上のポリシーを特定することを含む、請求項１の方法。
【請求項7】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける前記複数の処理リソースに対する利用率影響を予測することを含む、
請求項１の方法。
【請求項8】
複数のワークロード割り当ては、前記１つ以上のポリシーに記述されている、請求項７の方法。
【請求項9】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記１つ以上のポリシーで指定された１つ以上の要因に基づいて、複数のワークロード割り当てをスコア付けすることを含む、
請求項７の方法。
【請求項10】
リソース管理通知のために前記ワークロードイニシエータを登録することと、能力の変化及び利用率の変化のうち少なくとも１つに応じて、前記ワークロードイニシエータにリソースの利用可能性を通知することと、を含む、
請求項１の方法。
【請求項11】
サービスベースのパイプラインを提供するための装置であって、前記装置は、
コンピュータプロセッサと、
前記コンピュータプロセッサに動作可能に結合されたコンピュータメモリと、を備え、
前記コンピュータメモリは、コンピュータプログラム命令を含み、
前記コンピュータプログラム命令は、前記コンピュータプロセッサによって実行されると、
ワークロードイニシエータからワークロードの記述を含むリクエストを受信するステップと、
少なくとも第１のグラフィックス処理ユニット（ＧＰＵ）及び第２のＧＰＵを含む複数の処理リソースのランタイム利用率メトリクスを調べるステップと、
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定するステップと、
を前記装置に実行させる、
装置。
【請求項12】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける前記複数の処理リソースに対する利用率影響を予測することを含む、
請求項１１の装置。
【請求項13】
複数のワークロード割り当ては、前記１つ以上のポリシーに記述されている、請求項１２の装置。
【請求項14】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記１つ以上のポリシーで指定された１つ以上の要因に基づいて、複数のワークロード割り当てをスコア付けすることを含む、
請求項１２の装置。
【請求項15】
前記コンピュータプログラム命令は、実行されると、リソース管理通知のために前記ワークロードイニシエータを登録するステップと、
能力の変化及び利用率の変化のうち少なくとも１つに応じて、前記ワークロードイニシエータにリソースの利用可能性を通知するステップと、
を前記装置に実行させる、
請求項１１の装置。
【請求項16】
サービスベースのパイプラインを提供するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品は、コンピュータ可読記憶媒体に設けられており、
前記コンピュータプログラム製品は、コンピュータプログラム命令を含み、
前記コンピュータプログラム命令は、実行されると、
ワークロードイニシエータからワークロードの記述を含むリクエストを受信するステップと、
少なくとも第１のグラフィックス処理ユニット（ＧＰＵ）及び第２のＧＰＵを含む複数の処理リソースのランタイム利用率メトリクスを調べるステップと、
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定するステップと、
をコンピュータに実行させる、
コンピュータプログラム製品。
【請求項17】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける前記複数の処理リソースに対する利用率影響を予測することを含む、
請求項１６のコンピュータプログラム製品。
【請求項18】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、ワークロード内の複数のストリームに対してアトミックに実行される、請求項１７のコンピュータプログラム製品。
【請求項19】
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することは、前記１つ以上のポリシーで指定された１つ以上の要因に基づいて、複数のワークロード割り当てをスコア付けすることを含む、
請求項１７のコンピュータプログラム製品。
【請求項20】
前記コンピュータプログラム命令は、実行されると、リソース管理通知のために前記ワークロードイニシエータを登録するステップと、
能力の変化及び利用率の変化のうち少なくとも１つに応じて、前記ワークロードイニシエータにリソースの利用可能性を通知するステップと、
を前記コンピュータに実行させる、
請求項１６のコンピュータプログラム製品。
【発明の詳細な説明】
【背景技術】
【0001】
コンピューティングシステムは、多くの場合、命令を取り出して実行し、実行した命令の結果を適切な場所に記憶することができる、いくつかの処理リソース（例えば、１つ以上のプロセッサ）を含む。そのようなコンピュータシステム上で実行されるアプリケーションに、特定のワークロードを実行するために特定の処理リソースを選択する機会を与えることができる。例えば、中央処理装置（central processing unit、ＣＰＵ）と、グラフィックス処理ユニット（graphics processing unit、ＧＰＵ）等の１つ以上の高速化処理デバイスと、を含むコンピューティングシステムにおいては、アプリケーションは、アプリケーションのワークロードを実行するために特定のプロセッサを選択することができる。アプリケーションは、コンピューティングシステムのオペレーティングシステムに問い合わせることによって、何れの処理リソースがコンピューティングシステムに存在しているかを判断することができる。一例では、マルチメディア再生アプリケーションは、メディア再生が可能なデバイスのリストについてオペレーティングシステムに問い合わせ、例えば、ビデオ再生のワークロードを実行するための特定のＧＰＵを選択することができる。
【図面の簡単な説明】
【0002】
【図1】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供するための例示的なシステムのブロック図である。
【図2】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図である。
【図3】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図である。
【図4】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図である。
【図5】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する他の例示的な方法を説明するフロー図である。
【図6】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する他の例示的な方法を説明するフロー図である。
【図7】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する他の例示的な方法を説明するフロー図である。
【図8】本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する他の例示的な方法を説明するフロー図である。
【発明を実施するための形態】
【0003】
いくつかのシナリオでは、アプリケーションが実行のためにワークロードを割り当てる準備ができている場合に、アプリケーションは、最初にオペレーティングシステムに問い合わせを行い、何れの処理リソースが利用可能であるかを判断する。例えば、ワークロードが、グラフィックスのワークロード（例えば、ゲームのグラフィックスレンダリング）又はマルチメディアのワークロード（例えば、マルチメディア再生）である場合、アプリケーションは、最初にＧＰＵがコンピューティングデバイス内に存在するかどうかを判断し得る。いくつかのコンピューティングデバイスでは、２つ以上のＧＰＵが存在し得る。例えば、コンピューティングデバイスは、統合されたＣＰＵ及びＧＰＵを含むことができる一方で、ディスクリートＧＰＵ（すなわち、個別のチップ上）も含むことができる。更に、アプリケーションは、例えば、何れのビデオコーデックがＧＰＵによってサポートされるかを判断して、ワークロードを何処に配置するかを決定することができる。例えば、ストリーミングメディアサービスプレーヤは、ソース解像度、ビットレート、コーデック、ディスプレイ解像度、フレームレート等に関して特定のワークロード（例えば、映画）を記述し、ワークロードを実行することができる処理リソースについてオペレーティングシステムに問い合わせることができる。オペレーティングシステムは、ワークロードを実行する能力を有するＧＰＵを特定することによって応答することができる。オペレーティングシステムの応答に基づいて、アプリケーションは、ＧＰＵを選択し、そのＧＰＵにワークロードを割り当てることができる。例えば、統合型ＧＰＵは、通常、ディスクリートＧＰＵよりも少ない電力消費であるから、アプリケーションは、統合型ＧＰＵにワークロードを割り当てることができる。これは、コンピューティングデバイスがバッテリ電力で動作して場合ときに特に懸念され得る。
【0004】
しかしながら、オペレーティングシステムがコンピューティングデバイスの能力に関する情報を提供する場合、オペレーティングシステムは、システムのランタイム挙動に関する如何なる洞察もなしにそれを行う。すなわち、オペレーティングシステムは、統合型ＧＰＵのビデオコーデックがどのくらいビジーであるかを知らない。アプリケーションが、ビデオ会議アプリケーション等の他のビデオのワークロードも実行している可能性のある統合型ＧＰＵ上にワークロードを置くことを決定した場合、統合型ＧＰＵのビデオコーデックが過剰な利用申請になる可能性がある。言い換えれば、アプリケーション及びオペレーティングシステムは、処理リソースの実際のランタイム利用率に関して可視性がなく、その結果としてコンピューティングデバイスがワークロードに対して期待されるユーザエクスペリエンスを提供できるかどうかを知らない。
【0005】
これらの制限に対処するために、本開示は、アプリケーション又は他のワークロードイニシエータが、処理リソースをワークロードに割り当てる前に、ワークロードに関するランタイム利用率メトリクス及びポリシーに基づいたワークロード割り当て推奨（workload allocation recommendation）を受信することができる、最適化されたサービスベースのパイプラインのためのメカニズムを提供する。
【0006】
実施形態は、最適化されたサービスベースのパイプラインを提供する方法を対象とする。この方法は、ワークロードイニシエータからワークロードの記述を含むリクエストを受信することを含む。また、この方法は、ワークロード記述に基づいて複数の処理リソースのランタイム利用率メトリクスを調べることを含み、複数の処理リソースは、少なくとも第１のＧＰＵ及び第２のＧＰＵを含む。また、この方法は、利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することを含む。いくつかの実施形態では、第１のＧＰＵは、ＣＰＵと統合された統合型ＧＰＵであり、第２のＧＰＵは、ディスクリートＧＰＵである。いくつかの実施形態では、利用率メトリクスが特定される複数の処理リソースとしては、ビデオ符号化／復号アクセラレータ、オーディオ符号化／復号アクセラレータ、ディスプレイコントローラ、バスインターフェースコントローラ、及び、メモリサブシステムコントローラのうち少なくとも１つを更に含む。
【0007】
いくつかの実施形態では、この方法は、リクエストをサブミットするためのアプリケーションプログラミングインターフェース（ＡＰＩ）をワークロードイニシエータに公開することを含む。これらの実施形態では、この方法は、リクエストに応じて、ワークロード割り当て推奨をワークロードイニシエータに提供することを含む。いくつかの実施形態では、この方法は、少なくともワークロードの記述に基づいて、ランタイム利用率メトリクス及び１つ以上のポリシーを特定することを含む。
【0008】
いくつかの実施形態では、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定することは、ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける複数の処理リソースに対する利用率影響（utilization impact）を予測することを含む。これらの実施形態では、複数のワークロード割り当てを１つ以上のポリシーに記述することができる。また、これらの実施形態は、１つ以上のポリシーにおいて指定された１つ以上の要因に基づいて複数のワークロード割り当てをスコア付けすることを含むことができる。
【0009】
いくつかの実施形態では、この方法は、リソース管理通知用にワークロードイニシエータを登録すること及び能力の変化又は利用率の変化に応じてリソースの利用可能性をワークロードイニシエータに通知することを含む。
【0010】
実施形態の変形例は、最適化されたサービスベースのパイプラインを提供するための装置を対象とする。装置は、コンピュータプロセッサと、コンピュータプロセッサに動作可能に結合されたコンピュータメモリと、を含み、コンピュータメモリは、コンピュータプログラム命令を内部に設けており、コンピュータプログラム命令は、コンピュータプロセッサによって実行されると、装置に、ワークロードイニシエータからワークロードの記述を含むリクエストを受信させる。また、コンピュータプログラム命令は、装置に、ワークロード記述に基づいて複数の処理リソースのランタイム利用率メトリクスを調べさせ、ここで複数の処理リソースは、少なくとも第１のＧＰＵ及び第２のＧＰＵを含む。さらに、コンピュータプログラム命令は、装置に、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定させる。
【0011】
いくつかの実施形態では、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定することは、ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける複数の処理リソースに対する利用率影響を予測することを含む。これらの実施形態では、複数のワークロード割り当ては、１つ以上のポリシーに記述される。いくつかの実施形態では、コンピュータプログラム命令は、装置に、１つ以上のポリシーにおいて指定された１つ以上の要因に基づいて複数のワークロード割り当てをスコア付けさせる。
【0012】
いくつかの実施形態では、コンピュータプログラム命令は、装置に、リソース管理通知用にワークロードイニシエータを登録させ、能力の変化又は利用率の変化に応じてリソースの利用可能性をワークロードイニシエータに通知させる。
【0013】
実施形態の更に別の変形例は、最適化されたサービスベースのパイプラインを提供するためのコンピュータプログラム製品を対象とする。コンピュータプログラム製品は、コンピュータ可読記憶媒体上に設けられており、実行されると、コンピュータに、ワークロードイニシエータからワークロードの記述を含むリクエストを受信させるコンピュータプログラム命令を含む。また、コンピュータプログラム命令は、コンピュータに、ワークロード記述に基づいて複数の処理リソースのランタイム利用率メトリクスを調べさせ、ここで複数の処理リソースは、少なくとも第１のＧＰＵ及び第２のＧＰＵを含む。また、コンピュータプログラム命令は、コンピュータに、利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定させる。
【0014】
いくつかの実施形態では、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定することは、ランタイム利用率メトリクスに基づいて、特定のワークロード割り当てにおける複数の処理リソースに対する利用率影響を予測することを含む。これらの実施形態では、複数のワークロード割り当てを１つ以上のポリシーに記述することができる。いくつかの実施形態では、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定することは、ワークロード内の複数のストリームについてアトミックに実行される。これらの実施形態では、コンピュータプログラム命令は、装置に、１つ以上のポリシーにおいて指定された１つ以上の要因に基づいて複数のワークロード割り当てをスコア付けさせる。
【0015】
いくつかの実施形態では、コンピュータプログラム命令は、コンピュータに、リソース管理通知用にワークロードイニシエータを登録させ、能力の変化又は利用率の変化に応じて、リソースの利用可能性をワークロードイニシエータに通知させる。
【0016】
本開示による実施形態を図１から更に詳細に説明する。明細書及び図面を通じて、同じ符号は同じ要素を指す。図１は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供するための例示的なシステム１００のブロック図を示す。図１の例示的なシステム１００は、ラップトップ又はデスクトップパーソナルコンピュータ、サーバ、スマートフォン又はタブレット等のモバイルデバイス、ゲームコンソール等のコンピューティングデバイスにおいて実装することができる。例示的なシステム１００は、２つのＧＰＵ１０４、１３４を含むが、当業者であれば、本開示の趣旨から逸脱することなく、他のシステムがより多くのＧＰＵを含むことができ、又は、他のタイプの高速化処理デバイスを使用することができることを理解するであろう。
【0017】
図１の実施例では、例示的なシステム１００は、ＣＰＵ１０６及びＧＰＵ１０４（本明細書では「統合型ＧＰＵ」と呼ぶ）を統合する高速化処理ユニット（accelerated processing unit、ＡＰＵ）を含む。ＣＰＵ１０６及び統合型ＧＰＵ１０４は、同じチップ上に実装することができ、その結果としていくつかのコンポーネント及びインターフェースを共有することができる。例えば、ＣＰＵ及びＧＰＵは、システムメモリ１６０、メモリコントローラ１１４、ダイレクトメモリアドレッシング（direct memory addressing、ＤＭＡ）エンジン１１８、パーソナルコンピューティングインターフェースエクスプレス（personal computing interface express、ＰＣＩｅ）インターフェース１１６等のバスインターフェース、並びに、ネットワークインターフェース、ユニバーサルシリアルバス（universal serial bus、ＵＳＢ）インターフェース、永続ストレージインターフェース等を含む、図１に示されていない他のインターフェース及びアダプタを共有することができる。ＣＰＵ１０６は、１つ以上のコア１０８（すなわち、実行エンジン）、キャッシュ構造（図示せず）、パイプラインコンポーネント（図示せず）等を含む。ＣＰＵ１０６及び他の共有コンポーネントは、高速オンチップ通信ファブリック（図示せず）を介してＧＰＵ１０４に接続される。
【0018】
図１の例示的なシステム１００では、統合型ＧＰＵ１０４は、いくつかの並列処理ユニット（図示せず）を有する複数の単一命令複数データ（single instruction multiple data、ＳＩＭＤ）処理コア１１２を含むＧＰＵ計算エンジン１１０を含む。ＧＰＵ計算エンジン１１０は、ジオメトリプロセッサ、ラスタライザ、グラフィックコマンドプロセッサ、ハードウェアスケジューラ、非同期計算エンジン、キャッシュ、データ共有等のように、図１に示されていない他のコンポーネントも含み得る。図１の例では、統合型ＧＰＵ１０４は、高速化ビデオ符号化及び復号のためのビデオエンコーダ／デコーダ１２０（すなわち、「コーデック」）、高速化オーディオ符号化及び復号のためのオーディオコーデック１２２、高速化表示処理のためのディスプレイコントローラ１２４、並びに、高速化セキュリティプロトコルの実施及び準拠のためのセキュリティプロセッサ１２６等のように、特定用途向け集積回路又は機能論理ブロックの形態のハードウェアアクセラレータも含む。
【0019】
図１の例では、ＡＰＵ１０２は、ＰＣＩｅインターコネクト１９０等のインターコネクトを介してディスクリート（個別型）ＧＰＵ１３４と通信する。ＡＰＵ１０２のＰＣＩｅインターフェース１１６及びディスクリートＧＰＵ１３４のＰＣＩｅインターフェース１４６は、ＰＣＩｅインターコネクト１９０を介して通信する。いくつかの例では、ＡＰＵ１０２及びディスクリートＧＰＵ１３４は、同じ回路基板（例えば、プリント回路基板）上に実装されてもよい。別の例では、ディスクリートＧＰＵ１３４は、ＡＰＵ１０２の回路基板とは別のビデオカード又はグラフィックスカード上に実装されてもよい。ＡＰＵ１０２及びディスクリートＧＰＵ１３４は、保護されたビデオコンテンツ等の機密データを共有するために、ＰＣＩｅインターコネクト１９０を介したセキュア通信プロトコルを実現することができる。
【0020】
統合型ＧＰＵ１０４と同様に、図１の例のディスクリートＧＰＵ１３４は、多くの並列処理ユニット（図示せず）を有する複数のＳＩＭＤ処理コア１４２を含むＧＰＵ実行エンジン１４０を含む。ＧＰＵ実行エンジン１４０は、図１に示されていない他のコンポーネント、例えばジオメトリプロセッサ、ラスタライザ、グラフィックコマンドプロセッサ、ハードウェアスケジューラ、非同期計算エンジン、キャッシュ、データ共有等を含んでもよい。図１の例では、ディスクリートＧＰＵ１３４は、高速化ビデオ符号化及び復号のためのビデオエンコーダ／デコーダ１５０（すなわち、「コーデック」）、高速化オーディオ符号化及び復号のためのオーディオコーデック１５２、高速化表示処理のためのディスプレイコントローラ１５４、並びに、高速化セキュリティプロトコルの実施及び準拠のためのセキュリティプロセッサ１５６等のように、特定用途向け集積回路又は機能論理ブロックの形態のハードウェアアクセラレータも含む。また、ディスクリートＧＰＵ１３４は、グラフィックスメモリ１８０にアクセスするためのメモリコントローラ１４４及びＤＭＡエンジン１４８を含む。いくつかの例では、メモリコントローラ１４４及びＤＭＡエンジン１４８は、システムメモリ１６０の共有部分にアクセスするように構成される。
【0021】
図１の例示的なシステム１００では、システムメモリ１６０（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））は、上述した処理リソース（すなわち、ＡＰＵ及びディスクリートＧＰＵ並びにそれらの構成コンポーネント）用のデバイスドライバ１６６とインターフェースするオペレーティングシステム１６４をホストする。システムメモリ１６０は、１つ以上のアプリケーション１６２もホストする。本開示に関連して、１つ以上のアプリケーションは、グラフィックスアプリケーション、マルチメディアアプリケーション、ビデオ編集アプリケーション、ビデオ会議アプリケーション、高性能コンピューティングアプリケーション、機械学習アプリケーション、又は、統合型ＧＰＵ１０４及びディスクリートＧＰＵ１３４の並列性並びに／若しくはグラフィックス及びビデオ機能を活用する他のアプリケーションであってもよい。この１つ以上のアプリケーション１６２は、オペレーティングシステム１６４への呼び出しによって、統合型ＧＰＵ１０４又はディスクリートＧＰＵ１３４（若しくは両方の組み合わせ）に割り当てられるワークロード（例えば、グラフィックスレンダリングのワークロード、オーディオ／ビデオ転置のワークロード、メディア再生のワークロード、機械学習のワークロード等）を生成する。当業者であれば、この１つ以上のアプリケーションは、様々なワークロードタイプを生成する様々な追加のアプリケーションタイプであってもよく、その全てがここに特定されているわけではないことを理解するであろう。しかしながら、本開示内のアプリケーションタイプ及びワークロードタイプへの具体的な言及は、アプリケーションタイプ及びワークロードタイプをここで特定されているものに限定すると解釈すべきではない。
【0022】
また、システムメモリ１６０は、アプリケーション１６２等のワークロードイニシエータからワークロードの記述を含むリクエストを受信させ、統合型ＧＰＵ１０４及びディスクリートＧＰＵ１３４を含む複数の処理リソースのランタイム利用率メトリクスを調べ、少なくとも利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定するリソースマネージャ１７０をホストする。いくつかの例では、リソースマネージャ１７０は、有形のコンピュータ可読記憶媒体上に記憶されるコンピュータ実行可能命令において具現化され、プロセッサによって実行されると、システム１００に、上述したステップ、並びに、以下で説明されるリソースマネージャによって実行される他のステップ及び動作を実行させる。
【0023】
いくつかの実施形態では、リソースマネージャ１７０はＡＰＩ１７２を含み、アプリケーション１６２は、アプリケーションがワークロードを特定のＧＰＵに割り当てる前に、そのＡＰＩを通してリソースマネージャ１７０にワークロード割り当て推奨をリクエストすることができる。このコンテキストでは、ワークロード割り当て推奨は、ワークロードを何処に（すなわち、何れのＧＰＵ上に）配置すべきか（すなわち、ワークロードの実行のために）に関する推奨である。ワークロード割り当て推奨は、例えば、ワークロード記述、システム１００内の処理リソース等のハードウェア能力、システム１００内の様々な処理リソースの利用可能性、システム１００内の様々な処理リソースの利用率メトリクス、及び、ワークロード又はワークロードのタイプに関する１つ以上のポリシーに基づいている。いくつかの例において、リソースマネージャ１７０は、処理リソースのランタイム利用率メトリクスの現在の値に基づいて、ＧＰＵ１０４、１３４へのワークロードの最適な割り当てを決定することに関連する１つ以上のポリシー１７６を解釈するポリシーエンジン１７４を含む。次に、ワークロード割り当て推奨は、アプリケーション１６２に返され、アプリケーション１６２は、ワークロードを何処に配置するかを決定するためにそれを使用することができる。いくつかの例では、リソースマネージャ１７０は、ドライバ１６６と通信して、利用率メトリクスの値を取得することができ、又は、他のメカニズムによって利用率メトリクスの値を取得することができる。そのような例では、ドライバ１６６は、特定の処理リソース用の利用率モニタと、利用率メトリクス値をリソースマネージャ１７０に提供するためのインターフェースと、を含むことができる。ワークロードイニシエータからワークロードの記述を含むリクエストを受信すること、統合型ＧＰＵ１０４及びディスクリートＧＰＵ１３４を含む複数の処理リソースのランタイム利用率メトリクスを調べること、少なくとも利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定すること、並びに、リソースマネージャ１７０の他の機能及び利点について説明する追加の詳細が、以下に提供される。
【0024】
更なる説明のために、図２は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図２の例示的な方法は、ワークロードイニシエータからワークロードの記述を含むリクエストを受信すること２１０を含む。いくつかの例では、ワークロードイニシエータからワークロードの記述を含むリクエストを受信すること２１０は、リソースマネージャ１７０がワークロードイニシエータに公開したＡＰＩを介した呼び出しとしてクエリを受信することによって実行される。ワークロードがビデオ処理タスク又はグラフィックス処理タスクを含む例では、ワークロードを実行するコンピューティングシステム（例えば、図１のシステム１００）は、ワークロードを実行することができる複数のＧＰＵを含むことができる。特定の例では、コンピューティングシステムは、統合型ＧＰＵ（例えば、図１の統合型ＧＰＵ１０４）及びディスクリートＧＰＵ（例えば、図１のディスクリートＧＰＵ１３４）を含む。そのような例では、ワークロードイニシエータからのリクエストは、ワークロードが統合型ＧＰＵ上に配置されるべきか、ディスクリートＧＰＵ上に配置されるべきか、又は、それらの組み合わせ上に配置されるべきかについてのリソースマネージャ１７０へのクエリである。場合によっては、ワークロードは、統合型ＧＰＵ上で実行することができる作業項目と、ディスクリートＧＰＵ上で同時に実行することができる他の作業項目と、を含むことができる。
【0025】
様々なタイプのアプリケーションがワークロードイニシエータであってもよく、それぞれが様々なタイプのワークロードを有する。いくつかの例では、ワークロードイニシエータからのリクエストは、ワークロードのタイプ、ワークロード特性、処理要件、及び／又は、ワークロードに対する性能期待値を記述する。例えば、メディアプレーヤアプリケーションは、コンピューティングシステム上で実行されることを意図するメディア再生のワークロードとして特定されるワークロードを有することができる。そのような例では、ワークロードの記述は、再生のワークロード用のソース解像度、ディスプレイ解像度、ビットレート、ビデオコーデック、オーディオコーデック、及び、フレームレートを含む。別の例として、ビデオ会議アプリケーションは、コンピューティングシステムを実行しようとするためのトランスコードのワークロードとして特定されるワークロードを有することができる。そのような例では、ワークロードの記述は、ソースビデオコーデック、ターゲットビデオコーデック、及び、フレームレートを含むことができる。ビデオ会議アプリケーションは、注視補正又は画面上の参加者の背景を除去／置換するための人工知能（artificial intelligence、ＡＩ）アルゴリズムを含むＡＩのワークロードを含むこともできる。
【0026】
いくつかの例では、ワークロードの記述は、リソースマネージャが解析できる記述言語を使用して提供される。例えば、この記述言語は、ビットレートの記述子タグ、ディスプレイ解像度の記述子タグ、ビデオ符号化プロトコルの記述子タグ等を含むことができる。これらの例では、ワークロードの記述は、ワークロードの構造化された記述である。いくつかの例では、以下でより詳細に説明するように、リクエストに含まれる記述言語は、リソースマネージャ１７０のポリシーエンジン１７４によって解析できる。
【0027】
図２の例示的な方法は、ワークロード記述に基づいて複数の処理リソースのランタイム利用率メトリクスを調べること２２０を含む。処理リソースは、少なくとも第１のＧＰＵ及び第２のＧＰＵを含む。いくつかの例では、ランタイム利用率メトリクスを調べること２２０は、リソースマネージャが統合型ＧＰＵ及びディスクリートＧＰＵからメトリクスを収集することによって実行される。統合型ＧＰＵ及びディスクリートＧＰＵの利用率は、当業者によって認識される様々な方法で表現することができる。例えば、統合型ＧＰＵ及びディスクリートＧＰＵの利用率メトリクスには、アイドル時間とビジー時間の比として、アクティブプロセスの数として、アクティブスレッドの数として、電力消費として、又は、それらの組み合わせとしてのプロセッサ利用率が含まれ得る。統合型ＧＰＵ及びディスクリートＧＰＵは、これらのメトリクスを提供するための様々なカウンタを含むことができる。ビジー対アイドルに関係するメトリクスは、クロックレートも考慮に入れることができる。例えば、計算能力は、クロック当たりのスループット、エンジンの数、及び／又は、クロックレートに関連し得る。スループットは、ワークロードに応じて変化し得る。例えば、高ダイナミックレンジビデオのスケーリング／トーンマッピング／色補正は、１つのＧＰＵ上で実行される場合、標準ダイナミックレンジ素材のスケーリング／色補正よりもピクセル当たりのワークロードが重い。しかしながら、その同じワークロードが異なるエンジンで実行された場合、コスト関数が著しく異なる可能性がある。その結果として、クロックレート及びクロックサイクル当たりのスループットも、利用率メトリクスの表現であり得る。
【0028】
いくつかの例では、第１のＧＰＵ及びその構成リソース（例えば、計算ユニット、ビデオコーデック、オーディオコーデック、ディスプレイエンジン等の処理エンジン）並びに第２のＧＰＵ及びその構成リソース（例えば、計算ユニット、ビデオコーデック、オーディオコーデック、ディスプレイエンジン等の処理エンジン）は、リソースのプールとみなすことができ、各ＧＰＵの個々のリソースはワークロードをサポートするためにパーティション分割できる。すなわち、１つ以上の処理エンジンを単一のワークロードに関連付けることができる。例えば、復号のワークロードは、第１のＧＰＵのビデオコーデックと第２のＧＰＵのビデオコーデックとにわたって分割され得る。したがって、処理リソースは、統合型ＧＰＵ又はディスクリートＧＰＵ等の一般的な計算リソース、又は、コーデック、シェーダ、ディスプレイエンジン等の特定の計算リソースであり得る。
【0029】
いくつかの例では、複数の処理リソースのランタイム利用率メトリクスを調べること２２０は、ビデオコーデック及びオーディオコーデック等のマルチメディアアクセラレータ、ディスプレイコントローラ、セキュリティプロセッサ、ＤＭＡエンジン及びメモリコントローラ等のメモリサブシステム、並びに、ＰＣＩｅインターフェース等のバスインターフェースを含む追加の処理リソースからランタイム利用率メトリクスの値を収集することも含むことができる。マルチメディアアクセラレータ、ディスプレイコントローラ、セキュリティプロセッサ及び他のアクセラレータの利用率は、アイドル時間とビジー時間の比、アクティブプロセスの数、アクティブスレッドの数、電力消費、又は、それらの組み合わせ等のメトリクスによって表すことができる。これらのコンポーネントは、これらのメトリクスを提供するための様々なカウンタを含むことができ、これらのメトリクスは、例えば、対応するドライバの呼び出しを介して調べることができる。メモリサブシステム利用率は、現在の期間内にインターフェースを介して発行された読取りパケットの数及び書込みパケットの数、入口及び出口キュー又はバッファの現在の利用率、データ転送時間及び待ち時間等のメトリクスによって表すことができる。バスインターフェース利用率は、帯域幅（例えば、ピーク帯域幅及び平均帯域幅）等のメトリクスによって表すことができる。特に、ＡＰＵとディスクリートＧＰＵとの間のバスインターフェースの利用率は、ワークロードが統合型ＧＰＵとディスクリートＧＰＵとの間で分割される場合に重要であり、バスインターフェースの帯域幅は、統合型ＧＰＵ及びディスクリートＧＰＵの結果データを共有する能力に制約を課す。
【0030】
いくつかの例では、ワークロード記述に基づいた複数の処理リソースのランタイム利用率メトリクスを調べること２２０は、リソースマネージャが複数の処理リソースのそれぞれのドライバに問い合わせて、ワークロード開始前の実行時の利用率メトリクスを取得することによって実行される。例えば、ワークロードイニシエータからのワークロードの記述を含むリクエストに応じて、リソースマネージャは、ワークロード記述に基づいてワークロードの実行をサポートするために必要な処理リソースの特定のコンポーネント（例えば、計算ユニット、シェーダ、コーデック等）を決定する。次いで、リソースマネージャは、複数の処理リソースのそれぞれのドライバに利用率メトリクスを問い合わせて、それらの処理リソース上に割り振られる可能性のあるワークロードに関係するコンピューティングデバイスの利用状態を構築する。例えば、ワークロードがメディア再生のワークロードであることをワークロード記述が示す場合、リソースマネージャは、特にビデオコーデック及びオーディオコーデックの利用率メトリクスを調べて、メディア再生のワークロードに関連する利用状態を構築する。
【0031】
図２の例示的な方法は、利用率メトリクス及び１つ以上のポリシーに基づいてワークロード割り当て推奨を決定すること２３０を含む。いくつかの例では、ワークロード割り当て推奨を決定すること２３０は、リソースマネージャが、少なくともコンピューティングデバイス及びその構成処理リソースの利用状態に基づいて、何れの処理リソース又は処理リソースの組み合わせにワークロードを、それらのリソースが過剰に利用申請されないように割り当てることができるかを決定することによって実行される。これらの例では、リソースマネージャは、コンピューティングデバイス内で利用可能な処理リソースを特定し、ワークロードの記述に基づいて、処理リソースのうち何れがワークロードを実行することができるかを判断する。例えば、（例えば、統合型ＧＰＵ及びディスクリートＧＰＵにおいて）利用可能な処理リソース、及び、ワークロードの要件（例えば、サポートされるビデオ符号化／復号規格）に合致するそれらの処理リソースの能力に基づいて、リソースマネージャは、ワークロード割り当て推奨を決定する２３０際に、利用可能で能力のある処理リソースの利用状態を調べる。
【0032】
これらの例では、ワークロード割り当て推奨を決定すること２３０は、そのような配置が処理リソースの過剰な利用申請をもたらさないことを前提に、１つ以上のポリシーに基づいてワークロードの推奨される配置を決定することも含むことができる。一例として、ポリシーは、ワークロードが追加されるＡＰＵによる全体的な電力消費がより少ないという理由で、可能であればワークロードが統合型ＧＰＵに置かれるべきであると述べてもよい。その結果として、新しいワークロードが統合型ＧＰＵの過剰な利用申請をもたらすと予測されない場合、ワークロード割り当て推奨は、ワークロードが統合型ＧＰＵに配置されることである。いくつかの例では、ワークロード割り当て推奨を決定すること２３０は、ワークロード内の複数のストリームに対してアトミックに実行される。その結果として、複数のストリームを含むワークロード（例えば、ビデオ符号化ストリーム及びビデオ復号ストリームがあるトランスコードのワークロード）がある場合、ワークロード割り当て推奨は、ワークロード内の各ストリームに対してアトミックに決定される。例えば、ビデオ符号化ストリームに対してワークロード割り当て推奨を行うことができ、同じワークロードのビデオ復号ストリームに対して第２のワークロード割り当て推奨を行うことができる。
【0033】
いくつかの例では、ワークロード割り当て推奨を決定すること２３０は、リクエストが関係するワークロードのタイプに基づいてポリシーを特定することを含む。ポリシーを推進する要因は、電力消費以外にもあり得る。いくつかの変形形態では、ゲームのワークロード用のポリシーは、ある処理リソースが他の処理リソースよりも良好にタスクを実行するという性能要因に基づく。一例では、ポリシーは、ゲームのワークロードがディスクリートＧＰＵの過剰な利用申請をもたらすと予測されない限り、ゲームのワークロードがディスクリートＧＰＵに配置されるべきと述べてもよい。いくつかの変形例では、ポリシーは、能力に基づく。例えば、ポリシーが、ビデオ再生がＡＶ１コーデックを使用して実行されるべきと述べることがある。一例として、ＧＰＵの一方がＡＶ１コーデックアクセラレータを含み、他方が含まない場合があり得る。その結果、ワークロード割り当て推奨を決定すること２３０は、システム内で利用可能な処理リソースの能力を判断することを含むこともできる。いくつかの例において、ワークロード割り当ては、新しいワークロード又は更新された利用情報に基づいて、リソースマネージャによって無効にされ得る。
【0034】
いくつかの実施形態では、ワークロード割り当て推奨を決定すること２３０は、ワークロードが必要とするコンポーネント処理リソースを特定することと、それらのリソースの利用率メトリクスを特定することと、を含むこともできる。一例として、統合型ＧＰＵのビデオコーデックが高い利用率にある場合、ビデオコーデックを利用しないグラフィックスワークロードは、リソースの過剰な利用申請をもたらすことなく、統合型ＧＰＵに配置することができる。対照的に、ビデオコーデックを利用するビデオ再生のワークロードは、ビデオコーデックの過剰な利用申請をもたらすであろう。この例では、低電力消費ポリシーにも関わらず、ワークロード割り当て推奨は、ワークロードをディスクリートＧＰＵ上に置くことになる。その結果、ワークロードの追加が、プロセッサシステム（例えば、統合型ＧＰＵ）の任意のコンポーネント処理リソース（例えば、ビデオコーデック）の過剰な利用申請をもたらす場合、リソースマネージャは、ワークロードを別のシステム（例えば、ディスクリートＧＰＵ）に配置することが好ましいと判断する。いくつかの例では、ポリシーは、ワークロードのタイプに対する予想を記述することができる。例えば、ポリシーは、毎秒６０フレームでの４Ｋの高ダイナミックレンジ（high dynamic range、ＨＤＲ）のワークロードが、Ｎ個のサイクル及び量Ｍのメモリ帯域幅を消費すると予想され得ることを示すことができる。
【0035】
いくつかの例では、ポリシーは、統合型ＧＰＵ及びディスクリートＧＰＵの両方の利用率を最大化するようにワークロードが割り振られるべきと述べることができる。一例として、複数の復号及び符号化ストリームを含むことができるビデオ編集ワークロードを考える。そのような例では、リソースマネージャは、第１の復号ストリームが統合型ＧＰＵの利用可能性に基づいて統合型ＧＰＵ上に配置されるべきで、第１の符号化ストリームがディスクリートＧＰＵの利用可能性に基づいてディスクリートＧＰＵ上に配置されるべきと判断することができる。第２の復号ストリームについて、リソースマネージャは、統合型ＧＰＵ及びディスクリートＧＰＵの利用状態に基づいて第２の復号ストリームが統合型ＧＰＵ上に配置されるべきと判断し、このワークロード割り当てを推奨することができる。第３の復号ストリームに関して、リソースマネージャは、統合型ＧＰＵ及びディスクリートＧＰＵの利用状態に基づいて第３の復号ストリームがディスクリートＧＰＵ上に配置されるべきと判断し、このワークロード割り当てを推奨することができる。
【0036】
高効率ビデオコーディング（High Efficiency Video Coding、ＨＥＶＣ）フォーマットから高度ビデオコーディング（Advanced Video Coding、ＡＶＣ）フォーマットへのトランスコードのワークロードの例を考えると、リソースマネージャは、利用可能性に基づいて、ＨＥＶＣ復号ストリームが統合型ＧＰＵ上に配置されるべきと判断し、これをワークロード割り当て推奨とすることができる。ＡＶＣ符号化ストリームの場合、リソースマネージャは、予想される利用率に基づいて、ＡＶＣ符号化ストリームがディスクリートＧＰＵ上に配置されるべきと判断し、これをワークロード割り当て推奨とすることができる。
【0037】
ＡＯＭｅｄｉａビデオ１（ＡＶ１）フォーマットからＡＶＣフォーマットへのトランスコードのワークロードの例を考える。この例では、ＡＶ１フォーマットは、ディスクリートＧＰＵによってのみサポートされている。そのような例では、リソースマネージャは、システムの能力に基づいて、ＡＶ１復号ストリームがディスクリートＧＰＵ上に配置されるべきと判断し、これをワークロード割り当て推奨とすることができる。予想される利用率に基づいて、リソースマネージャは、ＡＶＣ符号化ストリームが統合型ＧＰＵ上に配置されるべきと判断し、これをワークロード割り当て推奨とすることができる。
【0038】
更なる説明のために、図３は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図３の方法は、図３の例がリクエストをサブミットするためのアプリケーションプログラミングインターフェース（ＡＰＩ）をワークロードイニシエータに公開すること３１０を含むことを除いて、図２の方法と同様である。いくつかの実施形態では、リソースマネージャは、コンピューティングシステム上でワークロードを実行しようとするアプリケーション（例えば、図１のアプリケーション１６２）にＡＰＩを公開する。ＡＰＩは、アプリケーションがワークロード記述をサブミットし（例えば、上述した記述子言語を使用して）、コンピューティングシステムの処理リソース間のワークロード割り当てについての推奨をリクエストするためのメカニズムを提供する。いくつかの変形例では、記述子は、引数としてＡＰＩ呼び出しに追加される。例えば、統合型ＧＰＵ又はディスクリートＧＰＵの何れにワークロードを配置するかを決定する前に、アプリケーションは、リソースマネージャを呼び出して、ワークロード割り当ての推奨をリクエストすることができる。ＡＰＩ呼び出しにおいて、アプリケーションは、記述子言語を使用してワークロードの構造化された記述を含めることができる。ワークロードイニシエータがワークロード割り当て推奨をリクエストできるようにするＡＰＩを提供することによって、ワークロードイニシエータは、統合型ＧＰＵ及びディスクリートＧＰＵのランタイム特性を使用して、ワークロードのために、現在の利用率に関係なくＧＰＵを選択するのではなく、（例えば、処理リソースの過剰な利用申請による）性能の低下をもたらすことなくワークロードを配置することができる場所を特定する機会を与えられる。ＡＰＩ呼び出しは、ワークロードの開始時（例えば、メディア再生開始の開始時）にアプリケーションによって行われ、ワークロード内の各ワークアイテム（例えば、フレーム復号ごと）に対して行われるわけではない。いくつかの例では、第１のＧＰＵ及び第２のＧＰＵは、処理リソースが単一のシステムとして見え、インターフェースが複数のサブシステム（例えば、コーデック、計算ユニット等）にマッピングするように抽象化され得る。
【0039】
更なる説明のために、図４は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図４は、リクエストに応じてワークロードイニシエータにワークロード割り当て推奨を提供すること４１０を含むことを除いて、図２のものと同様である。例えば、リソースマネージャは、リクエストを開始したリクエストしているアプリケーションにワークロード割り当て推奨を返す。いくつかの例では、結果は、ＡＰＩ呼び出しに対する応答として返される。ワークロード割り当て推奨は、ワークロードが統合型ＧＰＵに配置されるべきか、又は、ディスクリートＧＰＵに配置されるべきかを示す。いくつかの変形例では、ワークロード割り当て推奨は、ある作業項目（例えば、合成）が統合型ＧＰＵ上に配置されるべきである一方で、他の作業項目（例えば、ビデオ復号）がディスクリートＧＰＵ上に配置されるべきといった、ワークロード内の特定の作業項目が配置される場所を示す。いくつかの例では、ワークロードのタイプに関連付けられたポリシーは、リソースマネージャがワークロードイニシエータにどのように応答すべきかを記述する。例えば、ポリシーは、過剰な利用申請が何れかのＧＰＵ上への配置から生じる場合、リソースマネージャは、ポリシーによって好まれる配置を示す応答を、能力を超えた利用申請が生じ得るという警告とともに返すべきであることを示すことができる。場合によっては、リソースマネージャは、アプリケーションが、予測された利用率への影響に基づいて、ワークロードを何処に配置するかを決定できるように、各ＧＰＵに対する予測された利用率影響を示す結果を返すことができる。
【0040】
更なる説明のために、図５は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図５は、少なくともワークロードの記述に基づいてランタイム利用率メトリクス及び１つ以上のポリシーを特定すること５１０を含む。いくつかの例では、少なくともワークロードの記述に基づいてランタイム利用率メトリクス及び１つ以上のポリシーを特定すること５１０は、リソースマネージャがワークロード記述からワークロードのタイプを決定することによって実行される。ワークロードのタイプから、リソースマネージャは、ワークロードが必要とする処理リソース（例えば、シェーダエンジン、ビデオ又はオーディオコーデックアクセラレータ、メモリサブシステム又はバスインターフェース等）を特定することができる。追加的又は代替的に、リソースマネージャは、ワークロードの構造化記述内のワークロード特性（例えば、ビデオ又はオーディオ符号化パラメータ、アップスケーリング解像度パラメータ、セキュリティパラメータ等）から必要な処理リソースを特定することができる。特定された処理リソースに基づいて、リソースマネージャは、それらのリソースの利用率メトリクスを調べる。処理リソースの利用率メトリクスは、連続的に監視及びサンプリングされ得るか、又は、リクエストへの応答として取得され得る。
【0041】
ワークロード記述から取得されたワークロードのタイプに基づいて、ワークロードに関する１つ以上のポリシーも特定される。例えば、ワークロードの各タイプ（例えば、メディア再生、ビデオ編集、ビデオ会議等）は、それに関連するポリシーのセットを有することができる。そのポリシーのセットには、ポリシーエンジン（例えば、図１のポリシーエンジン１７４）向けに、ワークロード割り当て推奨のための判断を行う方法が記述される。例えば、ポリシーのセットは、ワークロード又はワークロードのコンポーネントが何処に配置されるべきかについての選好度、ワークロードの態様（例えば、速度、電力消費、画像品質等）に対する列挙された優先度、ワークロードに対する基本要件（例えば、フレームレート、レイテンシ、出力解像度）、ワークロードに対する重要リソース（例えば、どのリソースがワークロードによって頻繁に利用されるか）、セキュリティ及び保護ポリシー等を指定することができる。いくつかの例では、ポリシーのセットは、ワークロード割り当て推奨を決定する際に、何れの利用率メトリクスが調べられ、信頼されるべきかを示す。
【0042】
更なる説明のために、図６は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図６の例示的な方法では、ワークロード割り当て推奨を決定すること２３０は、ランタイム利用率メトリクスに基づいて特定のワークロード割り当てにおける複数の処理リソースに対する利用率影響を予測すること６１０を含む。いくつかの実施形態では、特定のワークロード割り当てにおける複数の処理リソースに対する利用率影響を予測すること６１０は、特定のワークロード割り当てを特定するリソースマネージャによって実行される。例えば、特定のワークロード割り当ては、統合型ＧＰＵ上若しくはディスクリートＧＰＵ上へのワークロード全体の配置、又は、統合型ＧＰＵ及びディスクリートＧＰＵにわたるワークロードの分配であり得る。特定のワークロード割り当てについて、ワークロードのタイプ及びランタイム利用率メトリクスに基づいて、リソースマネージャは、提案されたワークロード割り当てにおける処理リソースの利用率に対する影響を予測する。例えば、ワークロードのタイプに基づいて、リソースマネージャは、新たなワークロードが追加された場合に、統合型ＧＰＵのＧＰＵコアが過剰な利用申請がなされると判断することができる。いくつかの変形例では、リソースマネージャは、新しいワークロードの数値的影響を予測する。例えば、ワークロードのタイプに基づいて、リソースマネージャは、ワークロードが統合型ＧＰＵに配置される場合、統合型ＧＰＵのＧＰＵコアの利用率が２０％増加すると判断することができる。いくつかの変形例では、利用率に対する影響は、特定のタイプのワークロードを実行するときの処理リソースの傾向、モデル及び／又は以前の利用観察に基づいて予測することができる。
【0043】
上述したように、リソース利用率分析は、特定のリソースに限定されず、システム全体に適用することができる。ビデオ復号及び合成のジョブを、ディスクリートＧＰＵのビデオコーデック及びシェーダエンジン上に配置することができ、ビデオ符号化のジョブを統合型ＧＰＵのビデオコーデック上に配置することができる、トランスコードのワークロードのための提案されたワークロード割り当ての例を考える。この例では、両方のＧＰＵは過剰利用なしにワークロードに対応することができるが、ディスクリートＧＰＵから統合型ＧＰＵへのＰＣＩｅインターコネクトを介した構成の転送は、このインターフェースの過剰利用をもたらす。ビデオ再生に関する別の例を考慮すると、再生のワークロードは、統合型ＧＰＵ又はディスクリートＧＰＵの何れかによって受け入れることができる。しかしながら、統合型ＧＰＵは、メモリコントローラを通じてシステムメモリへのアクセスにおいてＣＰＵと競合するため、統合型ＧＰＵ上にワークロードを配置すると、必要なユーザエクスペリエンスを提供するにはレイテンシが大きくなりすぎる可能性がある。そのようなシナリオでは、電力消費がより高くても、ディスクリートＧＰＵにワークロードを配置することが望ましい場合がある。
【0044】
いくつかの例では、ワークロードタイプに関連付けられた１つ以上のポリシーは、複数のワークロード割り当て案を指定する。トランスコードのワークロードの例では、ポリシーは、ビデオ復号及び合成をディスクリートＧＰＵのビデオコーデック及びシェーダエンジン上に配置し、ビデオ符号化を統合型ＧＰＵのビデオコーデック上に配置することを第１希望として指定することができる。ポリシーは、ワークロード全体をディスクリートＧＰＵ上に配置することを第２希望として指定することができる。ポリシーは、ワークロード全体を統合型ＧＰＵ上に配置することを第３希望として指定することができる。いくつかの変形例では、ポリシーは、リソース制約によって上書きされ得る。例えば、何れかのＧＰＵがコンテンツ保護をサポートしておらず、ビデオのワークロードが保護されたコンテンツを含む場合、ポリシーがコンテンツ保護をサポートしていないＧＰＵにワークロードを配置するとしても、ワークロードは、コンテンツ保護をサポートするＧＰＵに配置されなければならない。
【0045】
更なる説明のために、図７は、図６に示された方法を拡張するフロー図を示す。複数の特定のワークロード割り当ての利用率への影響を予測した後に、図７の方法は、１つ以上のポリシーにおいて指定された１つ以上の要因に基づいて複数のワークロード割り当てをスコア付けすること７１０に続く。いくつかの実施形態では、ワークロード割り当てをスコア付けすること７１０は、リソースマネージャのポリシーエンジンが複数の可能なワークロード割り当てのスコアを計算することによって実行される。スコアは、ポリシー又はポリシーのセットにおいて特定された要因に基づいて計算される。例えば、スコアは、特定のワークロード割り当ての性能特性（例えば、出力フレームレート、出力解像度等）、電力消費又は効率係数、負荷分散係数等に関連付けることができる。上記のトランスコードの例を続けると、スコアはフレームレートに基づくことができる。ビデオ復号及び合成のジョブをディスクリートＧＰＵ上に配置し、ビデオ符号化ジョブを統合型ＧＰＵ上に配置する第１のワークロード割り当てが、毎秒２００フレームのフレームレートを達成することができると仮定する。第２のワークロード割り当ては、ワークロード全体をディスクリートＧＰＵに配置し、毎秒１５０フレームのフレームレートを達成することができ、第３のワークロード割り当ては、ワークロード全体を統合型ＧＰＵに配置し、毎秒１００フレームのフレームレートを達成することができる。これらのワークロード割り当てが、トランスコードのワークロード用のポリシーにおいて指定されるように、フレームレートに基づいてスコア付けされる場合、第１のワークロード割り当てが、推奨ワークロード割り当てとして決定されるであろう。しかしながら、この同じ例において、ＰＣＩｅインターフェース利用率が実質的により高かった場合、統合型ＧＰＵとディスクリートＧＰＵとの間のデータの転送により、第１のワークロード割り当てのフレームレートが毎秒１２５フレームに減少する可能性がある。この例では、フレームレートのみを使用するスコアリングシステムに基づくと、第２のワークロード割り当てが好まれる。
【0046】
いくつかの変形例では、特定のワークロード割り当てをスコア付けするために使用される要因が重み付けされる。トランスコードの例を続けると、ポリシーは、フレームレートが出力解像度よりも優先されるように、フレームレート及び出力解像度を重み付けすることができる。ＰＣＩｅ利用率が高い例では、より少ないデータしかＰＣＩｅインターフェースを介して送信しなくてもよいように出力解像度が下げられる場合、毎秒２００フレームのフレームレートが達成可能であり得る。そのようなシナリオでは、第２のワークロード割り当て及び第３のワークロード割り当ては、同じシステム内で符号化と復号の両方を実行することによって依然として制限され、この性能を向上させるために出力解像度を低下させることができない。しかしながら、第１のワークロード割り当ては、出力解像度を低下させて、ＰＣＩｅインターフェースを介したデータレートを増加させることができる。その結果として、フレームレートが出力解像度よりも高く重み付けされる場合、第１のワークロード割り当てスコアが他の２つよりも高くなる。
【0047】
上記の例では、ポリシーエンジンは、ワークロード割り当てごとにスコアを計算する。これらのワークロード割り当ては、上述したように、ポリシー自体において指定することができる。次に、最も高いスコアを有するワークロード割り当てが、ワークロードに対する推奨ワークロード割り当てとしてワークロードイニシエータに対してリソースマネージャによって特定される。いくつかの例では、スコアは、ワークロード割り当てがリソースの過剰な利用申請をもたらすかどうかに関する指標を含むことができる。
【0048】
更なる説明のために、図８は、本開示のいくつかの実施形態による、最適化されたサービスベースのパイプラインを提供する例示的な方法を説明するフロー図を示す。図８の例示的な方法は、リソース管理通知用にワークロードイニシエータを登録すること８１０を含む。いくつかの実施形態では、リソース管理通知用にワークロードイニシエータを登録すること８１０は、リソースマネージャが、アプリケーションがリソース管理通知用の登録をリクエストするという指標を受信することによって実行される。リソース管理通知用の登録がリクエストされると、リソースマネージャは、以前に推奨されたワークロード割り当てに影響を及ぼし得るリソース利用率又はリソース能力に対する変化があった場合にアプリケーションに通知する。アプリケーションは、リソースマネージャへのＡＰＩコールを介して登録をリクエストすることができる。いくつかの変形例では、アプリケーションは、ワークロード割り当て推奨のための初期リクエストを行うＡＰＩ呼び出しの一部として登録をリクエストすることができる。他の例では、アプリケーションは、別のＡＰＩコールにおいて登録をリクエストすることができる。
【0049】
図８の例示的な方法は、能力の変化及び利用率の変化のうち少なくとも１つに応じてワークロードイニシエータにリソースの利用可能性を通知すること８２０を含む。いくつかの実施形態では、能力の変化及び利用率の変化のうち少なくとも１つに応じてワークロードイニシエータにリソースの利用可能性を通知すること８２０は、コンピューティングシステムの能力又はコンピューティングリソースの利用率の変化を検出するリソースマネージャによって実行される。例えば、リソースマネージャは、競合するアプリケーションが終了したことを検出することができ、その結果として処理リソースの利用可能量を増加させる。リソースマネージャは、コンピューティングシステムがバッテリ電力から接続電力に切り替わったことを検出することができ、その結果としてディスクリートＧＰＵの大きな電力消費の重要度を減らす。そのような変更の検出に応じて、リソースマネージャは、そのような通知用に登録したアプリケーションに通知する。いくつかの例では、リソースマネージャによる通知は、アプリケーションに、ワークロード割り当て推奨のための新しいリクエストをサブミットするように促す。他の例では、通知は、更新されたワークロード割り当て推奨を含む。いくつかの例では、リソースマネージャは、それらに割り当てられたリソースを解放するために、アプリケーションが依然としてアクティブであり、クラッシュ又は不完全なシャットダウンしていないかどうかを検出する。
【0050】
上記を考慮して、当業者の読者は、本開示によるいくつかの実施形態がいくつかの利点を提供することを理解するであろう。実施形態は、アプリケーションが過度に利用されるリソース上にワークロードを置かないように、システムのランタイム挙動への可視性を有するマルチＧＰＵシステム上でワークロードを開始することを意図するアプリケーションを提供する。更に、特徴／ワークロードタイプに対するポリシーは、リソースマネージャのポリシーエンジンが、その特徴／ワークロードタイプに対する最適なワークロード割り当て推奨を行うことを可能にする定義を提供する。その結果、システムは、ワークロードが予想通りに実行されることを保証することができ、又は、アプリケーションは、ワークロードを開始する前に、性能が保証され得ないことが通知される。このようにして、ユーザエクスペリエンスが改善される。
【0051】
実施形態は、システム、装置、方法及び／又は論理回路であり得る。本開示のコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（instruction-set-architecture、ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、又は、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語、並びに、「Ｃ」プログラミング言語又は同様のプログラミング言語等の従来の手続き型プログラミング言語等１つ以上のプログラミング言語の任意の組み合わせで書かれたソースコード若しくはオブジェクトコードの何れかであり得る。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールドプログラマブルゲートアレイ（field-programmable gate arrays、ＦＰＧＡ）又はプログラマブル論理アレイ（programmable logic arrays、ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を用いることによって、コンピュータ可読プログラム命令を実行し得る。
【0052】
本開示の態様は、本開示のいくつかの実施形態による方法、装置（システム）及び論理回路のフローチャート及び／又はブロック図を参照して本明細書に記載されている。フローチャート及び／又はブロック図の各ブロック、並びに、フローチャート及び／又はブロック図におけるブロックの組み合わせは、論理回路によって実施され得ることが理解されよう。
【0053】
論理回路は、プロセッサ、他のプログラマブルデータ処理装置又は他のデバイスに実装され、一連の動作ステップをプロセッサ、他のプログラマブル装置又は他のデバイス上で実行させて、コンピュータによって実行されるプロセスを生成することができ、それにより、コンピュータ、他のプログラマブル装置又は他のデバイス上で実行する命令が、フローチャート及び／又はブロック図のブロックで指定された機能／行為を実行する。
【0054】
図中のフローチャート及びブロック図は、本開示の様々な実施形態によるシステム、方法及び論理回路の可能な実施形態のアーキテクチャ、機能及び動作を示す。これに関して、フローチャート又はブロック図の各ブロックは、指定された論理機能を実行するための１つ以上の実行可能命令を含む、命令のモジュール、セグメント又は部分を表すことができる。いくつかの代替的な実施形態では、ブロックに記載されている機能は、図に記載された順序から外れて発生する可能性がある。例えば、連続して示される２つのブロックは、実際には実質的に同時に実行されてもよく、又は、ブロックは、関与する機能に応じて、逆の順序で実行されてもよい。ブロック図及び／又はフローチャートの各ブロック、並びに、ブロック図及び／又はフローチャートのブロックの組み合わせは、専用ハードウェアベースのシステムによって、指定された機能若しくは行為を実行するか、又は、専用ハードウェアとコンピュータ命令の組み合わせで実行することで実施することができることにも留意されたい。
【0055】
本開示は、その実施形態を参照して具体的に示され、説明されてきたが、以下の特許請求の範囲の趣旨及び範囲から逸脱することなく、形態及び詳細において様々な変更が行われ得ることを理解されたい。したがって、本明細書に記載された実施形態は、説明のためのものに過ぎず、本発明を限定するものではない。本開示は、詳細な説明ではなく添付の特許請求の範囲によって定義され、その範囲内の全ての差異は、本発明に含まれると解釈されるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【手続補正書】
【提出日】2024-05-29
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
装置であって、前記装置は、
コンピュータプロセッサと、
前記コンピュータプロセッサに動作可能に結合されたコンピュータメモリと、を備え、
前記コンピュータメモリは、コンピュータプログラム命令を含み、
前記コンピュータプログラム命令は、前記コンピュータプロセッサによって実行されると、
ワークロードイニシエータからワークロードの記述を含むリクエストを受信することと、
少なくとも第１のグラフィックス処理ユニット（ＧＰＵ）及び第２のＧＰＵを含む複数の処理リソースのランタイム利用率メトリクスを調べることと、
前記利用率メトリクス及び１つ以上のポリシーに基づいて、ワークロード割り当て推奨を決定することと、
を前記コンピュータプロセッサに実行させる、
装置。
【請求項2】
前記ランタイム利用率メトリクスに基づいて特定のワークロード割り当てにおける前記複数の処理リソースに対する利用率影響を予測することによって、前記ワークロード割り当て推奨を生成することを前記コンピュータプロセッサに実行させるコンピュータプログラム命令を含む、請求項１の装置。
【請求項3】
複数のワークロード割り当ては、前記１つ以上のポリシーに記述されている、請求項２の装置。
【請求項4】
前記１つ以上のポリシーで指定された１つ以上の要因に基づいて複数のワークロード割り当てをスコア付けすることによって、前記ワークロード割り当て推奨を生成することを前記コンピュータプロセッサに実行させるコンピュータプログラム命令を含む、請求項２の装置。
【請求項5】
リソース管理通知のために前記ワークロードイニシエータを登録することと、能力の変化及び利用率の変化のうち少なくとも１つに応じて、前記ワークロードイニシエータにリソースの利用可能性を通知することと、
を前記コンピュータプロセッサに実行させるコンピュータプログラム命令を含む、
請求項１の装置。
【国際調査報告】