JP6072834B2 - 方法、プログラム、装置、およびシステム - Google Patents

Description

多目的のグラフィクスプロセッシングユニット（ＧＰＧＰＵ）は、従来は中央処理装置（ＣＰＵ）によって実行されてきたいくつかのタスクを、グラフィクスプロセッシングユニット（ＧＰＵ）に実行させるために開発されてきた。典型的なＧＰＵの多重で並行な処理スレッドは、いくつかの処理タスクにはよく適しているが他のタスクにはあまり適していない。
近年、オペレーティングシステムはいくつかのタスクがＧＰＵに割り当てられるように開発されてきた。加えて、ＯｐｅｎＣＬ（Ｏｐｅｎ Ｃｏｍｐｕｔｉｎｇ Ｌａｎｇｕａｇｅ）のようなフレームワークは、命令が異なる種類の処理リソースを用いて実行されるように開発されている。

同時に、通常は複数のＧＰＵによって実行されるいくつかのタスクは、複数のＣＰＵによって実行されてもよく、ＣＰＵにいくつかのグラフィックスタスクを割り当てることが可能なハードウェアシステムとソフトウェアシステムがある。同じパッケージ内に又は同じダイ上にさえＣＰＵとＧＰＵを含む複数の統合された異種のシステムは、タスクの分配をより効率的にする。しかし、異なる種類の処理リソース間でのタスクのシェアリングとバランシングのための最適なバランスを見つけることは困難である。

様々な異なるプロキシは、ＧＰＵとＣＰＵへの負荷を見積もるために用いられてよい。ソフトウェア命令又はデータ待ち行列は、よりビジーであるコアを決定するために用いられて、他のコアにタスクを割り当ててよい。同様に、出力は、現在の仕事量の進行を決定するために比較されてよい。コマンド内のカウンタ又は実行ストリームもまた、監視されてよい。これらのメトリックは、その仕事量でコアの進行又は結果の直接的尺度を提供する。しかし、そのようなメトリックの集合は、複数のリソースを必要とし、与えられたものでどのように実行しているかのみで、コアの潜在的な能力を示さない。

同じ参照番号が同じ要素を参照する添付図面の図において、発明の実施形態は、限定的な例ではなく、一例として示される。
発明の実施形態に従って、ソフトウエア・アプリケーションを実行するためのダイナミックロードバランシングを実行するシステムの図である。 発明の実施形態に従って、ゲームを実行するためのダイナミックロードバランシングを実行するシステムの図である。 発明の実施形態に従って、ダイナミックロードバランシングを実行する処理フローダイアグラムである。 発明の実施形態に従って、ダイナミックロードバランシングを実行する処理フローダイアグラムである。 発明の実施形態に従って、ダイナミックロードバランシングを実行するための電力バジェットを決定する処理フローダイアグラムである。 発明の実施形態を実施するために適したコンピューティングシステムのブロック図である。 図５のシステムが具体化されうる小型フォームファクタデバイスの実施形態を示す。

発明の実施形態は、プログラムできるものとプロセッシングタスクのダイナミックバランスをサポートするものとを含む、様々な異なるＣＰＵとＧＰＵの組み合わせのいずれかに適用されてよい。その技術は、ＣＰＵとＧＰＵの両方を含む又はＣＰＵコアとＧＰＵコアの両方を含む単一のダイに適用されてもよく、同様に、ＣＰＵ機能とＧＰＵ機能の個別のダイを含むパッケージに適用されてもよい。別個のダイの、別個のパッケージの、又は周辺アダプタカードのような別個のプリント基板さえの個別のグラフィックスにも適用されてよい。発明の実施形態は、プロセッシングタスクの負荷が、ＣＰＵとＧＰＵの電力メーターに基づいてＣＰＵとＧＰＵの処理リソースの間で動的にバランシングされるようにする。発明は、ＣＰＵとＧＰＵが同じ電力バジェットを共有するシステムに適用されるときに特に有用であってよい。そのようなシステムにおいて、電力消費量と電力傾向を考慮にいれることができる。

ダイナミックロードバランシングは、３Ｄ（３次元）処理に特に有用であってよい。ＣＰＵの計算及び電力ヘッドルームは、ＣＰＵが３Ｄ処理を援助することができるようにし、この方法で、システムの合計計算リソースがより多く使用される。ＯｐｅｎＣＬのようなＣＰＵ／ＧＰＵ ＡＰＩｓ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅｓ）は、ＣＰＵとＧＰＵの間の複数のダイナミックロードバランシングカーネルからも恩恵を受ける。他の処理リソースがより実行できるようにすることによってより高いパフォーマンスを提供するダイナミックロードバランシングのための多くの他の応用がある。ＣＰＵとＧＰＵの間の作業のバランシングは、プラットフォームの計算及び電力リソースがより効率的かつ最大限に用いられることを可能にする。

いくつかのシステムにおいて、パワー制御ユニット（ＰＣＵ）は、電力メーター機能も提供する。電力メーターからの値は、クエリーを実行されて収集されてもよい。これは、電力が、分離可能な電力供給されたユニットのそれぞれについての作業負荷要求に基づいて分配されるようにするために用いられる。本開示において、電力メーター値は作業負荷要求を調節するために用いられる。

複数の電力メーターは、電力消費量の代用（ｐｒｏｘｙ）として用いられてよい。電力消費量は、負荷の代用としても用いられてよい。高い電力消費量は、コアがビジー状態であることを示唆する。低い電力消費量はコアがビジー状態ではないことを示唆する。しかし、低い電力の重要な例外がある。そのような例外の１つは、サンプラーが全て最大限に使用されているため、ＧＰＵがビジー状態になりうるが、まだＧＰＵが電力バジェットを最大限には使用していないというものである。

電力メーターと、ＰＣＵ等の電力管理ハードウェアからの他の表示とは、ＣＰＵとＧＰＵが電力に関してどれほどビジー状態であるかの評価を助けるために用いられてよい。中央処理コア又はグラフィックスコアのいずれかの評価は、他方のコアの各自のヘッドルームが決定されるようにもする。このデータは、プロセッシングプラットフォームのリソースをさらに使用する効率的な作業負荷のバランシングエンジンを動作させるために用いられる。

ビジー状態及びアイドル状態のような一般に用いられているパフォーマンスメトリックは、コアの電力ヘッドルームのいかなる表示も提供しない。電力メトリックを用いると、ロードバランシングエンジンは、特定のタスクにとってより効率的であるコアが最大の周波数で動作するようにでき、より効率的ではないコアが残りの電力で動作するようにできる。タスク又はプロセスが変わると、他のコアが代わりにフルパワーで動作されうる。

現在、いくつかのＩｎｔｅｌ（登録商標）のプロセッサは、プロセッサが短い時間ではるかに高いクロックスピードで動作可能なターボブースト（Ｔｕｒｂｏ Ｂｏｏｓｔ（商標））モードを用いる。これは、プロセッサに電力をより消費させ、熱をより生成させることになるが、プロセッサがより低いスピード、より低い電力モードに十分に素早く戻ると、プロセッサが過熱から守られる。電力メーター又は他の電力表示を用いることは、ターボブーストモードの使用を低減することなくＣＰＵ電力ヘッドルームを決定するための助けとなる。ターボブーストモードのＧＰＵの場合、ＧＰＵは、所望の時にその最大周波数で作業することができるようにされてもよく、それでもＣＰＵは残りの電力を消費することができる。

ＣＰＵとＧＰＵが同じ電力バジェットを共有するシステムにおいて、電力メーターのような電力表示は、ＣＰＵ又はＧＰＵにタスクがオフロードされることができるか決定するために用いられてよい。グラフィックス処理のために、ＧＰＵは、電力のほとんどを使用するようにされてよく、その上、ＣＰＵは可能な時、例えば十分な電力ヘッドルームがある時に助けるようにされてよい。ＧＰＵは、通常グラフィックス処理タスクを処理することがより効率的である。一方、ＣＰＵは他のほとんどのタスクと木構造の走査のような全般的なタスクとを実行することが、通常はより効率的である。このような場合、ＣＰＵは電力のほとんどを使用するようにされてよく、その際は、可能な時にＧＰＵが助けるようにされてよい。

多目的の処理のためのアーキテクチャ例が、図１に示されている。コンピュータシステムパッケージ１０１は、ＣＰＵ１０３、ＧＰＵ１０４、及び電力ロジック１０５を含む。これらは全て同じ又は異なるダイ上にあってよい。あるいは、それらは、異なるパッケージ内で、マザーボードに直接又は複数のソケットを介して別々に取り付けられてよい。コンピュータシステムは、オペレーティングシステム又はカーネル等のようなランタイム１０８をサポートする。並列データ又はグラフィックスを有するアプリケーション１０９は、ランタイムの頂点上で動作し、複数の呼び出し又は実行ファイルをランタイムへ生成する。ランタイムは、これらの呼び出し又は実行ファイルをコンピューティングシステムのためにドライバ１０６に渡す。ドライバはこれらを複数のコマンド又は命令としてコンピューティングシステム１０１へ提供する。操作が処理される方法を制御するために、ドライバ１０６は、上述したようにＣＰＵとＧＰＵの間で複数の負荷を分配するロードバランシングエンジン１０７を含む。

単一のＣＰＵとＧＰＵは、発明を不明瞭にしないために順番に記載されるが、それぞれが別個のパッケージ内又は１つのパッケージ内にあってもよい複数の例がそれぞれありうる。コンピューティング環境が、図１に示された単純な構造を有してよく、又は、共通のワークステーションが、４又は６個のコアをそれぞれ有する２つのＣＰＵと、自身のパワー制御ユニットをそれぞれ有する２又は３個の別々のＧＰＵとを有してもよい。本明細書で述べる技術は、このようなシステムに適用されてよい。

図２は、３Ｄゲーム１２９を実行するコンテキストのコンピューティングシステム１２１の例を示す。３Ｄゲーム１２９は、ＤｉｒｅｃｔＸ又は同様のランタイム１２８上で動作し、ユーザモードドライバ１２６を介してコンピューティングシステム１２１へ送信されるグラフィックス呼び出しを発行する。コンピューティングシステムは、本質的には図１のシステムと同じであってよく、ＣＰＵ１２３、ＧＰＵ１２４及び電力ロジック１２５を含んでよい。

図１の例において、コンピューティングシステムは主にＣＰＵで処理されるアプリケーションを実行している。しかし、アプリケーションが複数の並列データ操作とグラフィックス要素を含むという点で、これらはＧＰＵで処理されてよい。いくらかの作業負荷をＣＰＵからＧＰＵへシフトさせるために、ロードバランシングエンジンは、複数の適切な命令又はコマンドをロードバランシングエンジンへ送信するために用いられてよい。逆に図２の例では、３Ｄゲームが主にＧＰＵで処理される。しかし、ロードバランシングエンジンは、いくらかの作業負荷をＧＰＵからＣＰＵへシフトしてよい。

本明細書で記載したロードバランシング技術は、図３Ａの処理フローダイアグラムを考慮することによってより理解されてよい。「１」では、システムが命令を受信する。これは、概してドライバで受信されて、ロードバランシングエンジンに利用可能となる。図３Ａの例において、ロードバランシングエンジンは、図１のコンピュータ構成の場合には、ＣＰＵの方に偏る。命令は、コマンド、ＡＰＩ、又は、アプリケーションとランタイムに応じた他の様々な形態として受信されてよい。ドライバ又はロードバランシングエンジンはコマンドを、ＣＰＵとＧＰＵで独立して処理される、より単純な又はより基本的な命令へパースしてよい。

「２」では、システムは命令を調べて、命令が割り当てられることができるかを決定する。パースされた複数の命令又は受信されたままの複数の命令は、３つの区分に分類されてよい。いくつかの命令は、ＣＰＵで処理されるべきである。大容量記憶装置へファイルをセーブする操作又は電子メールを送信及び受信する操作は、ほとんど全ての命令が概してＣＰＵで実行されるべき操作の例である。他の命令はＧＰＵで処理されるべきである。表示のためにピクセルをラスター化又は変換する命令は、概してＧＰＵで実行されるべきである。物理計算又はシェーディング及びジオメトリ命令のような第３区分の命令は、ＣＰＵ又はＧＰＵのいずれかで処理されてよい。第３グループの命令について、ロードバランシングエンジンは処理のために命令をどこに送信するか決定してよい。

命令が割り当てられることができない場合には、「３」において、命令は、「２」で命令がどのように分類されたかに応じてＣＰＵ又はＧＰＵのいずれかに送信される。

命令が割り当てられることができた場合には、ロードバランシングエンジンは、ＣＰＵ又はＧＰＵのいずれに命令を割り当てるか決定する。ロードバランシングエンジンは様々なメトリックを使用して、スマートな決定をしてよい。複数のメトリックは、ＧＰＵ利用度、ＣＰＵ利用度、及び電力計画等を含んでよい。

発明のいくつかの実施形態では、ロードバランシングエンジンは複数のコアの１つが最大限に利用されているかを決定してよい。決定ブロック４は、特定の実施形態に応じて使用されうる選択的な分岐である。「４」では、エンジンはＣＰＵが最大限に負荷を負っているか検討する。負っていない場合には、「７」で、命令がＣＰＵに移される。
これは、命令の割り当てをＣＰＵの方に偏らせ、「５」での決定ブロックを回避する。

ＣＰＵが最大限に負荷を負っている場合には、「５」で、命令がＧＰＵへ移されるかを決定するために、複数の電力バジェットが比較される。割り当て可能である命令の場合には、この選択的な分岐４を行わずに、命令は「５」での決定のために直接移される。あるいは、図３Ｂに示されるように、エンジンは、ＧＰＵが最大限に負荷を負っているか検討してよく、その場合、ＣＰＵ電力バジェットに空きがあるならＣＰＵへ命令を渡す。どちらの場合にも、「４」での操作は除かれてよい。

最大限に負荷を負っている又は最大限に使用されているようなプロセッサコアの状態は、いずれかの様々な異なる方法で決定されてよい。
１例として、命令又はソフトウェアキューは監視されてよい。最大限の状態である又はビジー状態である場合には、コアは最大限に負荷を負っていると考えてよい。より正確な決定のために、コマンドを保持するソフトウェアキューの状態が期間監視されることができ、期間中、ビジー時間の長さが空き時間の長さと比較されて、利用の相対量を決定することができる。ビジー時間の割合が期間について決定されてよい。その上、この又は他の利用量は、「４」での決定のために閾値と比較されることができる。

プロセッサコアの状態は、複数のハードウェアカウンタを検査することによって決定されてもよい。ＣＰＵとＧＰＵコアは、監視されうるいくつかの異なるカウンタを有する。これらがビジー状態又はアクティブ状態である場合には、コアがビジー状態である。キュー監視と同様に、活動量が期間中測定されることができる。複数のカウンタがモニターされてよく、複数の結果が、加算、平均値算出、又は他の方法によって組み合わされてよい。例として、複数の処理コア又はシェーダーコア、テクスチャーサンプラー、計算ユニット、及びプロセッサ内の他の種類の実行ユニットのような実行ユニットのカウンタが監視されてよい。

発明のいくつかの実施形態では、複数の電力メーターがロードバランシングエンジン決定の一部として使用されてよい。ロードバランシングエンジンは、バックグランドで収集された過去の電力データも、ＣＰＵとＧＰＵからの現在の電力測定値も用いてよい。現在と過去のデータを用いて、例のための図４に示すように、ロードバランシングエンジンは、ＧＰＵ又はＣＰＵへ作業をオフロードするために利用可能な電力バジェットを計算する。例えば、ＣＰＵが８Ｗ（１５ＷのＴＤＰ（合計ダイ電力）を有する）であり、ＧＰＵが９Ｗ（１１ＷのＴＤＰを有する）である場合には、両方のダイが最大電力未満で動作している。この場合のＣＰＵは、７Ｗの電力バジェットを有し、ＧＰＵは２Ｗの電力バジェットを有する。これらのバジェットに基づいて、ロードバランシングエンジンによってＧＰＵからＣＰＵへタスクがオフロードされてよく、逆もまた同様である。

より良い決定のために、ＧＰＵとＣＰＵの複数の電力メーター測定値は、例えば最後の１０ｍｓの期間にわたって、積分され、平均値算出され、又は他の方法で組み合わされてよい。結果の積分された値は、製造場で設計されてよい又は経時的に設定されてよい「安全」閾値と比較されることができる。ＣＰＵが支障なく実行されていた場合には、複数のＧＰＵタスクがＣＰＵにオフロードされてよい。電力メーター値又は積分された値は、電力バジェットと比較されることができる。現在の作業見積もりがバジェットに適合する場合には、ＧＰＵにオフロードされることができる。他の電力バジェットシナリオのために、作業が代わりにＣＰＵにオフロードされてもよい。

「５」では、ロードバランシングエンジンがＧＰＵバジェットを閾値Ｔと比較して、命令をどこに送信するかを決定する。ＧＰＵバジェットがＴより大きい場合には、または言い換えると、ＧＰＵバジェットに空きがある場合には、「６」で命令がＧＰＵへ送信される。一方、ＧＰＵバジェットに空きが不足していることを意味する、ＧＰＵバジェットがＴより小さい場合には、命令は「７」でＣＰＵへ送信される。閾値Ｔは、命令がＣＰＵで成功裏に処理されるようにできる電力バジェットの最小量を示す。閾値は、最良のＴに調整するために、作業負荷のセットを実行することによってオフラインで決定されてよい。閾値は、経時的に複数のコアの活動的な作業負荷を学習することに基づいて動的に変更されることもできる。

「５」での決定は、システム上で実行しているソフトウェアの特定の種類をサポートするために、バイアスをかけられることができる。ゲームのために、ロードバランシングエンジンは、ＧＰＵバジェット閾値Ｔをより小さく設定することによって、ＧＰＵを優先するように構成されてよい。これは、ＧＰＵが重いグラフィックス要求をより円滑に処理できるので、より良いパフォーマンスを提供できる。これは、「４」での操作を用いて又は他の方法で実施されてもよい。

「４」での選択的な決定ブロックと同様の他の選択的な決定ブロックを用いて、ＧＰＵは、最大限の負荷を負っているか又は利用可能な追加の電力ヘッドルームを有するかを決定するためにテストされてもよい。これは、ＧＰＵに送信可能な全ての命令がＧＰＵへ送信されるようにするために用いられてよい。逆に、ＧＰＵが追加の電力ヘッドルームを有さない場合にはＣＰＵが選択される。あるいは、おそらく、ＧＰＵがＣＰＵに比べて弱く、ＧＰＵが援助される場合はゲームプレイが改善されるため、ロードバランシングエンジンは、ＣＰＵを優先するように構成されてよい。この場合、ロードバランシングエンジンは反対の方法で機能する。ＣＰＵが利用可能な追加の電力ヘッドルームを有する場合は、ＣＰＵが選択されてよい。逆に、ＣＰＵが追加の電力ヘッドルームを有さない場合のみ、ＧＰＵが選択されてよい。これは、ほとんどの命令がＧＰＵで処理されるべきであるゲーミング環境において、ＣＰＵへ送信された命令を最大化する。

この種のバイアスは、ハードウェア構成に基づいて、動作するアプリケーションのタイプに基づいて、又はロードバランシングエンジンによって調べられる呼び出しのタイプに基づいて、システムに組み込まれてよい。バイアスは、スケーリング又はファクターを決定に適用することによって小さくされてもよい。

この処理フロー中で参照されたバジェットは、パワー制御ユニットからの電力メーター値に基づいた電力バジェットである。一例として、バジェットは、ＣＰＵシステムの熱限界を超えることなく次の期間のために消費されることができるワット数である。このように例えば、次の期間（例えば１ｍｓ）について費やされることができる１Ｗのバジェットがある場合には、それがＧＰＵからＣＰＵへ命令をオフロードするのに十分なバジェットである。バジェット決定における１つの検討事項は、ターボブーストのようなＧＰＵターボモードに対する影響である。ＧＰＵターボモードを維持するために、バジェットが決定されて用いられる。

バジェットは、パワー制御ユニット（ＰＣＵ）から得られてもよい。パワー制御ユニットの構成及び位置は、コンピューティングシステムのアーキテクチャに依存する。図１と２の図示した例では、パワー制御ユニットは、複数の処理コアとアンコアを有する組み込まれたホモジニアスダイのアンコアの一部である。しかし、パワー制御ユニットは、システムボード上の様々な異なる位置から電力情報を収集する別個のダイであってよい。図１と２の例において、電力消費量、オーバヘッド、及びバジェットについての情報を収集するために、ドライバ１０６、１２６がＰＣＵへ接続する。

様々な異なる手法が、電力バジェットの決定のために用いられてよい。一例として、複数の電力値は、ＰＣＵから定期的に受信され、その後格納されて、割り当てられることができる命令が受信されるたびに用いられる。改善された決定プロセスが、定期的な電力値を用いて経時的に電力値の履歴をトラッキングすることによって、より複雑な計算コストで実施されることができる。履歴は、各コアの未来の電力予測値を提供すべく、外挿されることができる。
その後、ＣＰＵ又はＧＰＵのコアが予測された未来の電力値に基づいて選択される。

バジェット値が、瞬間の、現在の又は予測されたいずれかの電力消費値の比較であってよく、電力消費値をコアの最大可能電力消費量と比較することによって決定されることができる。例えば、コアが１２Ｗ消費しており、１９Ｗの最大電力消費量を有する場合には、コアが７Ｗの残りのバジェット又はオーバヘッドを有する。バジェットは同様に、他のコアを考慮に入れてもよい。合計の利用可能な電力は、全てのコアが消費できる合計最大電力より小さくてもよい。例えば、ＣＰＵが１９Ｗの最大電力を有し、ＧＰＵが２２Ｗの最大電力を有するが、ＰＣＵが２７Ｗしか供給できない場合には、両方のコアが同時に最大電力で動作することはできない。このような構成は、コアが一時的により高速に動作するようにするために望ましい。ロードバランシングエンジンは、両方のコアがそれぞれの最大電力レベルに到達するレートで命令を供給することはできない。利用可能な電力バジェットは、ＰＣＵの能力を構成するために、適宜に減らされてよい。

図３Ｂは、図２のコンテキストで用いれるようなＧＰＵを優先するプロセスの処理フローダイアグラムである。「２１」では、例えばドライバ１２６のようなシステムが命令を受信する。これは、ＧＰＵに偏ったロードバランシングエンジンに利用可能にされる。ドライバ又はロードバランシングエンジンは、実装に応じてコマンドを分析又はパースして、当該コマンドをＣＰＵとＧＰＵによって独立に処理されうる複数の命令へ縮小する。

「２２」では、システムは命令を検査して、命令が割り当て可能かを決定する。ＣＰＵ又はＧＰＵで処理されるべき複数の命令が、それらの各宛先へ送信される。

命令が割り当てられることができる場合には、ロードバランシングエンジンは、ＣＰＵ及びＧＰＵのいずれかに命令を割り当てるかを決定する。図３Ａのように、選択的な操作が、決定ブロック４でＧＰＵが最大限の負荷を負っているかを決定するために用いられる。そうでない場合には、命令が「２７」でＧＰＵに渡され、「２５」の決定ブロックは回避される。ＧＰＵが最大限の負荷を負っている場合には、複数の電力バジェットが「２５」で分析され、命令がＣＰＵへ渡されてよいかを決定する。

「２５」では、ロードバランシングエンジンがＣＰＵバジェットを閾値Ｔと比較し、命令をどこに送信するかを決定する。ＣＰＵバジェットがＴより大きい場合には、「２６」で命令がＣＰＵへ送信される。一方、ＣＰＵバジェットがＴより小さい場合には、「２７」で命令がＧＰＵへ送信される。閾値Ｔは、ＣＰＵの電力バジェットの最小量を表し、図３Ａの閾値と同じ方法で決定されてよい。

図４は、図３Ａ又は図３Ｂの処理フローで利用されるバジェット決定のための並列の処理フローを示す。図４において、「１１」では、各コア又は複数のコアのグループの現在の電力消費量が受信される。複数のＣＰＵコア及び複数のＧＰＵコアを有するコンピューティングシステムにおいて、複数の命令が、各コアに個別に割り当てられ、又は中央とグラフィックス処理の間で分配される。複数のＣＰＵコアの別個のプロセスが、その後、存在する場合には複数のコアと複数のスレッドの間に複数の命令を分配するために用いられてよい。同様に、この又は別個のプロセス又は両方は、複数の中央処理コア間又は複数のグラフィクスプロセッシングコア間に複数の命令を分配するために用いられてよい。

「１２」で、受信された現在の電力消費量が、最大電力消費量と比較されて、各コアの現在のバジェットを決定する。「１３」で、この値が記憶される。複数の現在の電力消費値が定期的に受信され、「１１」、「１２」、及び「１３」の操作が繰り返されてよい。ＦＩＦＯ（先入れ先出し）バッファが、バジェット値のいくつかのみが格納されるように用いられてよい。直近の値が、図３の操作で用いられるか、又は何かしらの操作が「１４」のように複数の値に実行されてよい。

「１４」で、現在と前のバジェット値が比較され、計画バジェットを決定する。計画バジェットはその後、図３の操作のバジェット値として使用される。比較は、特定の実装に応じて様々な異なる方法で実行されてよい。一例として、平均値がとられてよい。他の例として、外挿法又は積分が実行されてよい。外挿法は、電力制御システムの他の既知の態様に基づいて最大値及び最小値に限定されてよい。さらなる複雑な解析的で統計的な手法が、特定の実装に応じて代わりに用いられてよい。

図３Ａと３Ｂに記載された手法の代わりの手法として、現在の処理コア電力負荷が、単に合計利用可能値と比較されてよい。ＴＤＰ＝通常操作電力エンベロープ上述したように、ＴＤＰ（合計ダイ電力）は、ＰＣＵによって又はダイの熱設計の制約によって決定される。バジェットは、ＴＤＰからＣＰＵコアとＧＰＵコアの現在の電力負荷を単に減じることによって決定されてよい。バジェットは、バジェットの閾値量と比較されてよい。バジェットが閾値より大きい場合には、命令が他のコアへ割り当てられることができる。

更なる操作として、他のコアがチェックされ、命令がオフロードされる前に、割り当てられた電力範囲内で動作しているかを決定することもできる。この簡素化された手法は、様々な異なるシステムに適用されてよく、ＣＰＵ、ＧＰＵ、又は特定のコアへ複数の命令をオフロードするために用いられてよい。

図５は、システム５００の実施形態を示す。実施形態において、システム５００はこのコンテキストに限定されないが、システム５００はメディアシステムであってよい。例えば、システム５００が、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、ウルトラ−ラップトップ・コンピュータ、タブレット、タッチパッド、ポータブル・コンピュータ、ハンドヘルド・コンピュータ、パームトップ・コンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、携帯電話／ＰＤＡ組み合わせ、テレビ、スマート・デバイス（例えばスマートフォン、スマートタブレット、又はスマートテレビ）、モバイル・インターネット・デバイス（ＭＩＤ）、メッセージング・デバイス、データ通信デバイス等に組み込まれてよい。

実施形態において、システム５００は、ディスプレイ５２０に連結されたプラットフォーム５０２を含む。プラットフォーム５０２が、コンテント・サービス・デバイス５３０、コンテント配信デバイス５４０、又は他の同様のコンテンツソース等のコンテンツ装置からコンテンツを受信してよい。１又は複数のナビゲーション機能を有するナビゲーションコントローラ５５０は、例えばプラットフォーム５０２及び／又はディスプレイ５２０と交信するために用いられてよい。これらの構成要素のそれぞれが、以下でより詳細に説明される。

実施形態において、プラットフォーム５０２は、チップセット５０５、プロセッサ５１０、メモリ５１２、ストレージ５１４、グラフィックスサブシステム５１５、アプリケーション５１６、及び／又は無線５１８のいずれかの組み合わせを含んでよい。チップセット５０５は、プロセッサ５１０、メモリ５１２、ストレージ５１４、グラフィックスサブシステム５１５、アプリケーション５１６、及び／又は無線５１８の間での相互通信を提供してよい。例えば、チップセット５０５は、ストレージ５１４との相互通信の提供が可能なストレージアダプタ（不図示）を含んでよい。

プロセッサ５１０は、複合命令セットコンピュータ（ＣＩＳＣ）又は縮小命令セットコンピュータ（ＲＩＳＣ）のプロセッサ、Ｘ８６命令セット互換プロセッサ、マルチコア、又は他のマイクロプロセッサ、又は中央処理装置（ＣＰＵ）として実装されてよい。実施形態において、プロセッサ５１０は、デュアルコアプロセッサ（複数の場合もあり）、及びデュアルコアモバイルプロセッサ（複数の場合もあり）等を含んでよい。

メモリ５１２は、これらに限定されないが、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、又はスタティックＲＡＭ（ＳＲＡＭ）等の揮発性メモリ装置として実装されてよい。

ストレージ５１４は、これらに限定されないが、磁気ディスクドライブ、光学ディスクドライブ、テープドライブ、内部ストレージ装置、アタッチトストレージ装置、フラッシュメモリ、バッテリーバックアップＳＤＲＡＭ（シンクロナスＤＲＡＭ）、及び／又はネットワークアクセス可能ストレージデバイス等の不揮発性ストレージ装置として実装されてよい。実施形態において、ストレージ５１４は、例えば、複数のハードドライブが含まれるときに、有用なデジタル媒体のストレージパフォーマンス拡張保護を増す技術を含んでよい。

グラフィックスサブシステム５１５は、表示のための写真又は動画のようなイメージの処理を実行してよい。グラフィックスサブシステム５１５は、例えば、ラフィクスプロセッシングユニット（ＧＰＵ）又はビジュアルプロセッシングユニット（ＶＰＵ）であってよい。アナログインタフェース又はデジタルインタフェースが、グラフィックスサブシステム５１５とディスプレイ５２０を通信可能に接続してよい。例えば、インタフェースが、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ、ＤｉｓｐｌａｙＰｏｒｔ、無線ＨＤＭＩ（登録商標）、及び／又は無線ＨＤ準拠技術のいずれかであってよい。グラフィックスサブシステム５１５が、プロセッサ５１０又はチップセット５０５に組み込まれてよい。グラフィックスサブシステム５１５が、チップセット５０５に通信可能に接続されたスタンドアローンカードであってよい。

本明細書に記載されたグラフィックス及び／又は動画処理技術は、様々なハードウェアアーキテクチャに実装されてよい。例えば、グラフィックス及び／又は動画機能は、チップセット内に組み込まれてよい。あるいは、個別のグラフィックス及び／又は動画プロセッサが用いられてよい。また他の実施形態として、グラフィックス及び／又は動画機能が、マルチコアプロセッサを含む多目的プロセッサによって実装されてよい。さらなる実施形態において、機能は、コンシューマー電子装置に実装されてよい。

無線５１８は、様々な適した無線通信技術を用いて信号を送受信することが可能な１又は複数の無線を含んでよい。このような技術は、１又は複数の無線ネットワークにわたる通信を行ってよい。代表的な無線ネットワークは、（ただしこれに限定されないが）ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）、ワイヤレスメトロポリタンエリアネットワーク（ＷＭＡＮ）、携帯電話ネットワーク、及び衛星ネットワークを含む。このような複数のネットワークにわたる通信において、無線５１８は、任意のバージョンの１又は複数の適用規格に従って動作してよい。

実施形態において、ディスプレイ５２０は、任意のテレビタイプモニター又はディスプレイを含んでよい。ディスプレイ５２０は、例えば、コンピュータディスプレイスクリーン、タッチスクリーンディスプレイ、動画モニター、テレビのような装置、及び／又はテレビを含んでよい。ディスプレイ５２０は、デジタル及び／又はアナログであってよい。実施形態において、ディスプレイ５２０は、ホログラフィーディスプレイであってよい。また、ディスプレイ５２０は、ビジュアル投影を受けることができる透明な表面であってよい。このような投影は、情報、像、及び／又は物体のざまざまな形態を伝達してよい。例えば、このような投影は、モバイル拡張現実（ＭＡＲ）アプリケーションのビジュアルオーバーレイであってよい。ソフトウエア・アプリケーション５１６の制御下で、プラットフォーム５０２が、ディスプレイ５２０上にユーザインタフェース５２２を表示してよい。

実施形態において、例えば、コンテント・サービス・デバイス５３０（複数の場合もある）は、国の、国際的な、及び／又は独立したサービスによってホストされ、このためインターネットを介してプラットフォーム５０２にアクセス可能であってよい。コンテント・サービス・デバイス５３０（複数の場合もある）は、プラットフォーム５０２及び／又はディスプレイ５２０に接続されてよい。プラットフォーム５０２及び／又はコンテント・サービス・デバイス５３０（複数の場合もある）は、ネットワーク５６０から及びネットワーク５６０へメディア情報を通信する（例えば送信及び／又は受信する）ために、ネットワーク５６０に接続されてよい。コンテント配信デバイス５４０は、プラットフォーム５０２及び／又はディスプレイ５２０に接続されてもよい。

実施形態において、コンテント・サービス・デバイス（複数の場合もある）５３０は、ケーブルテレビボックス、パーソナルコンピュータ、ネットワーク、電話、インターネット使用可能装置又はデジタル情報及び／又はコンテントを配信できる家庭用器具、及び、コンテントプロバイダとプラットフォーム５０２とディスプレイ５２０との間でネットワーク５６０を介してあるいは直接に一方向又は双方向でコンテントを通信できる他の同様の装置を含んでよい。コンテントが、システム５００の構成要素及びコンテント・プロバイダのいずれかへ及びいずれかから、ネットワーク５６０を介して一方向に及び／又は双方向に通信されてもよいことを理解されたい。コンテントの例は、例えば動画、音楽、医療、及びゲーミング情報等を含む任意のメディア情報を含んでよい。

コンテント・サービス・デバイス５３０が、メディア情報、デジタル情報、及び／又は他のコンテントを含むケーブルテレビ番組のようなコンテントを受信する。コンテント・プロバイダの例は、任意のケーブルもしくは衛星テレビ、又は無線もしくはインターネットコンテント・プロバイダを含んでよい。示した例は、発明の実施形態を限定するものではない。

実施形態において、プラットフォーム５０２は、１又は複数のナビゲーション機能を有するナビゲーションコントローラ５５０から制御信号を受信してよい。コントローラ５５０のナビゲーション機能は、例えば、ユーザインタフェース５２２と交信するために用いられてよい。実施形態において、ナビゲーションコントローラ５５０は、ユーザが空間的な（例えば、連続した及び多次元の）データをコンピュータに入力するようにさせるコンピュータハードウェア構成要素（具体的にはヒューマン・インタフェース・デバイス）のようなポインティングデバイスであってよい。グラフィカルユーザインタフェース（ＧＵＩ）、テレビ、及びモニターのような多くのシステムは、ユーザが物理的なジェスチャーを用いてコンピュータ又はテレビへデータを制御して提供できるようにする。

コントローラ５５０のナビゲーション機能の移動は、ポインター、カーソル、フォーカスリング、又はディスプレイ上に表示された他のビジュアルインジケーターの移動によって、ディスプレイ（例えばディスプレイ５２０）上に影響されてよい。例えば、ソフトウエア・アプリケーション５１６の制御下で、ナビゲーションコントローラ５５０に設けられたナビゲーション機能が、例えばユーザインタフェース５２２上に表示されたバーチャルナビゲーション機能にマッピングされてよい。実施形態において、コントローラ５５０は、分離した構成要素ではなく、プラットフォーム５０２及び／又はディスプレイ５２０に組み込まれてよい。実施形態はしかし、本明細書で示された又は説明された要素に又はコンテキスト内に限定されない。

実施形態において、複数のドライバ（不図示）は、例えば、ユーザが、最初の立ち上げ後可能なときにボタンのタッチでテレビのようなプラットフォーム５０２を直ちにオン及びオフすることができる技術を含んでよい。プログラムロジックは、プラットフォームがオフにされている時にプラットフォーム５０２がコンテンツをメディアアダプタ又は他のコンテント・サービス・デバイス５３０又はコンテント配信デバイス５４０に流すことができるようにしてよい。さらに、チップセット５０５は、例えば、５．１サラウンド・サウンド・オーディオ及び／又は高精細度７．１サラウンド・サウンド・オーディオのためのハードウェア及び／又はソフトウェアサポートを含んでよい。複数のドライバは、統合グラフィックスプラットフォーム用のグラフィックスドライバを含んでよい。実施形態において、グラフィックスドライバは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）エクスプレスグラフィックスカードを含んでよい。

様々な実施形態において、システム５００に示された任意の１又は複数の構成要素は一体にされてよい。例えば、プラットフォーム５０２とコンテント・サービス・デバイス５３０が一体にされ、又は、プラットフォーム５０２とコンテント配信デバイス５４０が一体にされ、又は、例えば、プラットフォーム５０２とコンテント・サービス・デバイス５３０とコンテント配信デバイス５４０とが例えば一体にされてよい。様々な実施形態において、プラットフォーム５０２とディスプレイ５２０は統合ユニットであってよい。例えば、ディスプレイ５２０とコンテント・サービス・デバイス５３０が一体にされ、又はディスプレイ５２０とコンテント配信デバイス５４０が一体にされてよい。これらの例は、発明を限定するものではない。

様々な実施形態において、システム５００は、無線システム、有線システム、又は両方の組み合わせとして実装されてよい。無線システムとして実装された場合、システム ５００は、１又は複数のアンテナ、送信装置、受信装置、トランシーバー、増幅器、フィルター、及び制御ロジック等のような無線共有媒体上で通信するのに適した構成要素とインタフェースを含んでよい。一例の無線共有媒体は、ラジオ波スペクトル等のような無線スペクトルの複数の部分を含んでよい。有線システムとして実装される場合には、システム５００は、入出力（Ｉ／Ｏ）アダプタ、対応する有線通信媒体にＩ／Ｏアダプタを接続する物理コネクタ、ネットワークインタフェースカード（ＮＩＣ）、ディスクコントローラ。動画コントローラ、及びオーディオコントローラ等のような有線通信媒体上で通信するのに適した構成要素とインタフェースを含んでよい。一例の有線通信媒体は、ワイヤー、ケーブル、金属リード、プリント回路基板（ＰＣＢ）、バックプレーン、スイッチ構造、半導体材料、ツイストペアワイヤー、同軸ケーブル、及びファイバーオプティックス等を含んでよい。

プラットフォーム５０２は、情報を通信するために、１又は複数の論理又は物理チャネルを確立してよい。情報は、メディア情報とコントロール情報を含んでよい。メディア情報は、ユーザ用であるコンテンツを示すいずれかのデータを参照してよい。コンテントの例は、例えば、音声対話、ビデオ会議、ストリーミング動画、電子メール（ｅｍａｉｌ）メッセージ、ボイスメールメッセージ、英数字記号、グラフィックス、イメージ、動画、及びテキスト等からのデータを含んでよい。音声対話からのデータは、例えば、スピーチ情報、沈黙期間、バックグラウンドノイズ、コンフォートノイズ、及び音色等であってよい。コントロール情報は、自動システム用のコマンド、命令、又は制御ワードを示す任意のデータを参照してよい。例えば、コントロール情報は、メディア情報をシステムを介して送るために、又は、ノードが所定の方法でメディア情報を処理するように指示するために、用いられてよい。実施形態はしかし、図５に示され又は説明されたコンテキスト内又は要素に限定されない。

上述したように、システム５００は、物理的な様式又はフォームファクターを変更して具体化されてよい。図６は、システム５００が具体化された小型フォームファクタデバイス６００の実施形態を示す。実施形態において、例えば、装置６００は無線性能を有するモバイル・コンピューティング・デバイスとして実装されてよい。モバイル・コンピューティング・デバイスは、例えば、処理システムと、１又は複数のバッテリーのようなモバイル電力源又は電源とを有する任意の装置を参照してよい。

上記したように、モバイル・コンピューティング・デバイスの例は、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、ウルトラ-ラップトップ・コンピュータ、タブレット、タッチパッド、ポータブル・コンピュータ、ハンドヘルド・コンピュータ、パームトップ・コンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、携帯電話／ＰＤＡ組み合わせ、テレビ、スマート・デバイス（例えばスマートフォン、スマートタブレット、又はスマートテレビ）、モバイル・インターネット・デバイス（ＭＩＤ）、メッセージング・デバイス、及びデータ通信デバイス等を含んでよい。

モバイル・コンピューティング・デバイスの例は、リストコンピュータ、フィンガーコンピュータ、リングコンピュータ、眼鏡コンピュータ、ベルトクリップコンピュータ、アームバンドコンピュータ、靴コンピュータ、衣類コンピュータ、及び他のウェアラブルコンピュータのような人が身につけるようにされたコンピュータも含んでよい。実施形態において、例えば、モバイル・コンピューティング・デバイスは、音声通信及び／又はデータ通信とコンピュータアプリケーションも実行できるスマートフォンとして実装されてよい。いくつかの実施形態は、例としてスマートフォンとして実装されたモバイル・コンピューティング・デバイスで説明されるが、他の実施形態は、同様に他のワイヤレス・モバイル・コンピューティング・デバイスを用いて実装されうることが理解されてよい。実施形態は、このコンテキストに限定されない。

図６に示すように、装置６００は、ハウジング６０２、ディスプレイ６０４、入出力（Ｉ／Ｏ）装置６０６、及びアンテナ６０８を含んでよい。装置６００はまた、複数のナビゲーション機能６１２を含んでよい。ディスプレイ６０４は、モバイル・コンピューティング・デバイスのために適切な情報を表示する任意の適切なディスプレイを含んでよい。Ｉ／Ｏデバイス６０６は、モバイル・コンピューティング・デバイスに情報を入力するための任意の適切なＩ／Ｏデバイスを含んでよい。Ｉ／Ｏデバイス６０６の例は、英数字キーボード、数字キーボード、タッチパッド、入力キー、ボタン、スイッチ、ロッカースイッチ、マイク、スピーカー、音声認識デバイス、及びソフトウェア等を含んでよい。情報は、例えばマイクで装置６００に入力されてもよい。このような情報は、音声認識デバイスでデジタル化されてよい。実施形態は、このコンテキストに限定されない。

様々な実施形態は、ハードウェア要素、ソフトウェア要素、又はこれら両方の組み合わせを用いて実装されてよい。ハードウェア要素の例は、プロセッサ、マイクロプロセッサ、回路、回路要素（例えばトランジスタ、レジスタ、キャパシタ、及びインダクタ等）、集積回路、アプリケーションに特化した集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、及びチップセット等を含んでよい。ソフトウェアの例は、ソフトウェア構成要素、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、機械プログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、ファンクション、方法、処理手続き、ソフトウェアインタフェース、アプリケーションプログラムインタフェース（ＡＰＩ）、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、記号、又はこれらの任意の組み合わせを含んでよい。実施形態がハードウェア要素及び／又はソフトウェア要素を用いて実装されるかの決定は、所望の計算速度、電力レベル、耐熱性、処理サイクルバジェット、入力データレート、出力データレート、メモリリソース、データバススピード、及び、他の設計又はパフォーマンス制約のようないくつかの要素に応じて変わってよい。

少なくとも１つの実施形態の１又は複数の態様は、プロセッサ内の様々なロジックを代表し、機械に読み込まれた時に機械がロジックを組み立てて本明細書で説明された技術を実行する、機械読み取り可能媒体上に格納された代表的な命令によって実装されてよい。「ＩＰコア」として知られるこのような代表は、有形の機械読み取り可能媒体上に格納され、様々なカスタマー又は製造設備に供給されて、ロジック又はプロセッサを実際に作成する製造機械にロードされてよい。

「１つの実施形態」、「実施形態」、「例の実施形態」、「様々な実施形態」等の記載は、そのように記載された発明の実施形態が、特定の特徴、構造又は特性を含んでよいが、実施形態の全てが必ずしも特定の特徴、構造又は特性を含まないことを示す。さらに、いくつかの実施形態は、他の実施形態について記載された特徴のいくつかを有し、全てを有し、又はいずれも有さないこともある。

以下の記載及び請求項において、「接続」という言葉は、その派生語とともに用いられてよい。「接続」は、２つ又はそれより多い要素が互いに協力する又は交信することを示すために用いられるが、それらが、それらの間に介在する物理的又は電気的な構成要素を含む場合があり又は含まない場合もある。

請求項で用いられるように、順序を示す形容詞「第１の」「第２の」「第３の」等の使用が別で特定されない限り、共通の要素を説明し、同様の要素の異なる例が参照されることを単に示し、そのように記載された要素が、時間的、空間的、序列、又は他の方法のいずれかの一定の順序であるべきことを意味することを意図したものではない。

図面及び上述の説明は、実施形態の例を示す。当業者であれば、１又は複数の説明した要素が単一の機能要素にうまく組み合わされてよいことが理解できる。あるいは、ある要素が複数の機能要素に分割されてもよい。１つの実施形態からの要素が、他の実施形態に追加されてよい。例えば、本明細書で説明したプロセスの順序は変更されてよく、本明細書で説明した方法に限定されない。いかなるフロー図の動作も、示された順序で実施される必要はなく、必ずしも全ての動作が実施される必要は無い。また、他の動作に依存していないこれらの動作が、他の動作と並列に実行されてよい。実施形態の範囲は、これらの特定の例に限定されない。明細書中に明確に示されていようがいまいが、構造、寸法、及び材料の使用の違い等の多数の変更が可能である。実施形態の範囲は、以下の請求項によって示されたものと少なくとも同じ広さである。

Claims (23)

1. 方法であって、
   命令を受信する段階と、
   中央処理コア（ＣＰＵ）とグラフィクスプロセッシングコア（ＧＰＵ）の電力値を受信する段階と、
   前記受信された電力値を用いて前記ＣＰＵと前記ＧＰＵについて電力バジェットを決定する段階と、
   前記ＣＰＵの電力バジェットおよび前記ＧＰＵの電力バジェットの少なくとも一方を閾値と比較することによって、前記受信された電力値に基づいて、前記ＣＰＵと前記ＧＰＵの中からコアを選択する段階と、
   前記命令を、処理のための前記選択されたコアへ送信する段階とを含む
   方法。
2. 電力値を受信する段階は、現在の電力消費値を受信する段階を含む、
   請求項１に記載の方法。
3. 電力値を受信する段階は、電力値を定期的に受信する段階と、命令を受信した時に用いるために、前記受信された電力値を記憶する段階とを含む、
   請求項１又は２に記載の方法。
4. 前記定期的な電力値を用いて、経時的に電力値の履歴をトラッキングする段階と、
   前記トラッキングされた履歴に基づいて、各コアについて未来の電力値を予測する段階とを更に含み、
   コアを選択する段階は、前記予測された未来の電力値に基づいてコアを選択する段階を含む、
   請求項３に記載の方法。
5. 履歴をトラッキングする段階は、前記コアについて、最大可能電力消費量と比較した電力消費量の履歴をトラッキングする段階を含む、
   請求項４に記載の方法。
6. コアを選択する段階は、最も大きい前記電力バジェットを有する前記コアを選択することによってコアを選択する段階を含む、
   請求項１から５のいずれか１項に記載の方法。
7. 電力バジェットを決定する段階は、最大可能電力消費量と比較した計画された未来の電力消費量を決定する段階を含む、
   請求項６に記載の方法。
8. コアを選択する段階は、前記ＧＰＵが利用可能な追加の電力ヘッドルームを有する場合には前記ＧＰＵを選択する段階と、前記ＧＰＵが追加の電力ヘッドルームを有さない場合には前記ＣＰＵを選択する段階とを含む、
   請求項１から７のいずれか１項に記載の方法。
9. 命令を受信する段階は、コマンドを受信する段階と、前記コマンドを、独立して処理されうる複数の命令にパースする段階とを含む、
   請求項１から８のいずれか１項に記載の方法。
10. 前記複数の命令を、前記ＣＰＵで処理されるべき命令、前記ＧＰＵで処理されるべき命令、及び前記ＣＰＵ又は前記ＧＰＵのいずれかで処理できる命令に分類する段階を更に含み、
    前記命令を送信する段階は、処理のための前記選択されたコアへ、前記ＣＰＵ又は前記ＧＰＵのいずれかで処理できる前記命令を送信する段階を含む、
    請求項９に記載の方法。
11. 複数の命令を有するプログラムであって、前記命令が、コンピュータで動作された時に、前記コンピュータに、
    命令を受信する段階と、
    中央処理コア（ＣＰＵ）とグラフィクスプロセッシングコア（ＧＰＵ）の電力値を受信する段階と、
    前記受信された電力値を用いて前記ＣＰＵと前記ＧＰＵについて電力バジェットを決定する段階と、
    前記ＣＰＵの電力バジェットおよび前記ＧＰＵの電力バジェットの少なくとも一方を閾値と比較することによって、前記受信された電力値に基づいて、前記ＣＰＵと前記ＧＰＵの中からコアを選択する段階と、
    処理のための前記選択されたコアへ前記命令を送信する段階と
    を含む動作を実行させる、
    プログラム。
12. 電力値を受信する段階は、電力値を定期的に受信する段階と、命令を受信した時に用いるために、前記受信された電力値を記憶する段階とを含み、
    前記動作はさらに、
    前記定期的な電力値を用いて、経時的に電力値の履歴をトラッキングする段階と、
    前記トラッキングされた履歴に基づいて、各コアについて未来の電力値を予測する段階とを更に含み、
    コアを選択する段階は、前記予測された未来の電力値に基づいてコアを選択する段階を含む、
    請求項１１に記載のプログラム。
13. 命令を受信する段階は、コマンドを受信する段階と、前記コマンドを、独立して処理されうる複数の命令にパースする段階とを含む、
    請求項１１又は１２に記載のプログラム。
14. 命令を受信する処理ドライバと、
    中央処理コア（ＣＰＵ）とグラフィクスプロセッシングコア（ＧＰＵ）の電力値をロードバランシングエンジンへ送信するパワー制御ユニットと、
    受信された前記電力値を用いて前記ＣＰＵと前記ＧＰＵについて電力バジェットを決定し、前記ＣＰＵの電力バジェットおよび前記ＧＰＵの電力バジェットの少なくとも一方を閾値と比較することによって前記受信された電力値に基づいて、前記ＣＰＵと前記ＧＰＵの中からコアを選択し、処理のための前記選択されたコアへ前記命令を送信する前記ロードバランシングエンジンと、
    を備える装置。
15. 前記パワー制御ユニットは、現在の電力消費値を送信する、
    請求項１４に記載の装置。
16. 前記ロードバランシングエンジンは、最も大きい前記電力バジェットを有する前記コアを選択することによってコアを選択する、
    請求項１４又は１５に記載の装置。
17. 中央処理コア（ＣＰＵ）と、
    グラフィクスプロセッシングコア（ＧＰＵ）と、
    複数のソフトウェア命令とデータを格納するメモリと、
    前記ＣＰＵと前記ＧＰＵの電力値をロードバランシングエンジンへ送信するパワー制御ユニット（ＰＣＵ）と、
    前記メモリ内に受信された前記電力値を格納し、受信された前記電力値を用いて前記ＣＰＵと前記ＧＰＵについて電力バジェットを決定し、前記ＣＰＵの電力バジェットおよび前記ＧＰＵの電力バジェットの少なくとも一方を閾値と比較することによって受信された前記電力値に基づいて前記ＣＰＵと前記ＧＰＵの中からコアを選択し、処理のために前記選択されたコアへ前記命令を送信する前記ロードバランシングエンジンとを備える、
    システム。
18. 前記ロードバランシングエンジンは、前記ＧＰＵが利用可能な追加の電力ヘッドルームを有する場合には前記ＧＰＵを選択し、前記ＧＰＵが追加の電力ヘッドルームを有さない場合には前記ＣＰＵを選択することによってコアを選択する、
    請求項１７に記載のシステム。
19. 前記ロードバランシングエンジンは更に、複数の前記命令を、前記ＣＰＵで処理されるべき命令、前記ＧＰＵで処理されるべき命令、及び前記ＣＰＵ又は前記ＧＰＵのいずれかで処理できる命令に分類し、処理のための前記選択されたコアへ、前記ＣＰＵ又は前記ＧＰＵのいずれかで処理できる命令のみを送信する、
    請求項１７又は１８に記載のシステム。
20. 前記閾値は、実行しているソフトウェアの特定の種類をサポートするために前記コアの選択にバイアスをかけるように設定される
    請求項１から１０のいずれか１項に記載の方法。
21. 前記閾値は、実行しているソフトウェアの特定の種類をサポートするために前記コアの選択にバイアスをかけるように設定される
    請求項１１から１３のいずれか１項に記載のプログラム。
22. 前記閾値は、実行しているソフトウェアの特定の種類をサポートするために前記コアの選択にバイアスをかけるように設定される
    請求項１４から１６のいずれか１項に記載の装置。
23. 前記閾値は、実行しているソフトウェアの特定の種類をサポートするために前記コアの選択にバイアスをかけるように設定される
    請求項１７から１９のいずれか１項に記載のシステム。

Images