JP2018533122A - マルチバージョンタスクの効率的なスケジューリング - Google Patents

Abstract

マルチプロセッサコンピューティングデバイスが複数の処理ユニット上でマルチバージョンタスクをスケジューリングするための方法、デバイス、システム、および非一時的プロセッサ可読記憶媒体。具現化方法は、複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューするためのプロセッサ実行可能動作であって、各特殊化されたバージョンは、複数の処理ユニットの異なる処理ユニットによって実行されるように構成される、エンキューするためのプロセッサ実行可能動作と、第1の処理ユニットがマルチバージョンタスクの対応する特殊化されたバージョンを即座に実行するのに使用可能であるときに、第1の処理ユニットにマルチバージョンタスクに対する所有権を提供するためのプロセッサ実行可能動作と、第1の処理ユニットにマルチバージョンタスクに対する所有権を提供することに応答して、マルチバージョンタスクの他の特殊化されたバージョンを破棄するためのプロセッサ実行可能動作とを含むことができる。この方法の様々な動作は、ランタイム機能性を介して実行され得る。

Description

並列プログラミングは、敏感に反応する高性能ソフトウェアを提供するためにコンピューティングデバイスが計算を作業の小さい塊(タスクと称する)に分割するための技法である。マルチコアまたはマルチプロセッサのコンピューティングデバイス(たとえば、異種システムオンチップ(SOC))においては、異なるタスクが、デバイスの様々な処理ユニットに割り当てられ(またはオフロードされ)得、一部のタスクは、タスク依存性に起因して他のタスクが終了した後に走行するように指定される。通常、ランタイムエンジン(またはタスクスケジューラ)は、タスクがどの処理ユニットに割り当てられ得るのかを判定し、そのような判定は、通常は、様々なデバイス、処理ユニット、および/またはタスクの特性もしくは条件に基づくものとされ得る。

一部のタスクは、特定の処理ユニットに向けられ、またはそのために設計され得る。たとえば、第1のタスクは、中央処理装置(CPU)による実行のために設計され得、第2のタスクは、グラフィックス処理ユニット(GPU)上での実行のために設計され得、第3のタスクは、デジタル信号プロセッサ(DSP)上での実行のために設計され得る。異なる処理ユニットのためのタスクは、しばしば、異なるプログラミング言語でまたは異なる仕様を使用して記述される。たとえば、CPUタスクとしてベクトル加算計算を実施するコードと、GPUタスクとして行列乗算計算を実施するコードとは、異なる言語および/または構文を使用する可能性がある。コンピューティングデバイス内の異なる処理ユニットを十分に利用するために、一般的な汎用タスクの異なるバージョンが、同時にサポートされ得る。「マルチバージョン」タスクは、同一の論理機能またはルーチンの複数の実施態様に関連付けられまたは他の形でこれを含むことができ、各実施態様は、特定の処理ユニットによる実行のために特殊化される。たとえば、ベクトル加算計算は、両方が異なる言語および/または構文を使用するCPUタスクおよびGPUタスクとして実施され得る。

米国特許出願第14/604,821号

様々な実施形態は、マルチプロセッサコンピューティングデバイスが複数の処理ユニット上でマルチバージョンタスクをスケジューリングするための方法、デバイス、システム、および非一時的プロセッサ可読記憶媒体を提供する。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスのプロセッサによって実行される方法は、複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューするステップであって、各特殊化されたバージョンは、複数の処理ユニットの異なる処理ユニットによって実行されるように構成され得る、エンキューするステップと、複数の処理ユニットの第1の処理ユニットにマルチバージョンタスクに対する所有権を提供するステップであって、第1の処理ユニットは、複数の処理ユニットの他の処理ユニットがマルチバージョンタスクの他の特殊化されたバージョンを実行するのに使用可能になる前に、マルチバージョンタスクの第1の特殊化されたバージョンを即座に実行するのに使用可能になり得る、提供するステップと、第1の処理ユニットにマルチバージョンタスクに対する所有権を提供することに応答して、マルチバージョンタスクの他の特殊化されたバージョンを破棄するステップとを含むことができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、複数の処理ユニットをスケジューリングするように構成されたランタイム機能性を実行し得る。

いくつかの実施形態において、複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューするステップは、複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンに関連するポインタをエンキューするステップを含むことができる。いくつかの実施形態において各ポインタは、マルチバージョンタスクおよびマルチバージョンタスクの特殊化されたバージョンの識別を含むことができる。いくつかの実施形態において、マルチバージョンタスクの特殊化されたバージョンの識別は、各ポインタの最下位4ビット内に含まれ得る。いくつかの実施形態において、複数の処理ユニットの第1の処理ユニットにマルチバージョンタスクに対する所有権を提供するステップは、マルチバージョンタスクに関連するデータを記憶するステップを含むことができる。

いくつかの実施形態は、第1の処理ユニットのタスクキューからの次のタスクがマルチバージョンタスクに関連するかどうかを判定するステップと、次のタスクがマルチバージョンタスクに関連するとの判定に応答して、第1の処理ユニットに関するマルチバージョンタスクに対する所有権を要求するステップとをさらに含むことができる。いくつかの実施形態は、所有権の要求に応答して第1の処理ユニットに関するマルチバージョンタスクに対する所有権を獲得するステップと、第1の処理ユニットに関するマルチバージョンタスクに対する所有権の獲得に応答して次のタスクを実行するステップとをさらに含むことができる。いくつかの実施形態において、第1の処理ユニットのタスクキューからの次のタスクがマルチバージョンタスクに関連するかどうかを判定するステップは、第1の処理ユニットのタスクキューからのポインタにビットマスクを適用することによって識別子を入手するステップと、識別子がマルチバージョンタスクの第1の特殊化されたバージョンに対応するとの判定に応答して、次のタスクがマルチバージョンタスクに関連すると判定するステップとを含むことができる。

いくつかの実施形態において、第1の処理ユニットのタスクキューからの次のタスクがマルチバージョンタスクに関連するかどうかを判定するステップは、第1の処理ユニットのタスクキューからポインタを取り出すステップであって、ポインタは、複数の処理ユニットの各々のタスクキュー内に配置された共通のマルチバージョンタスクポインタである、取り出すステップと、ポインタがマルチバージョンタスクの特殊化されたバージョンのリストに関連するかどうかを判定するステップと、ポインタがマルチバージョンタスクの特殊化されたバージョンのリストに関連するとの判定に応答して、マルチバージョンタスクの特殊化されたバージョンのリストからマルチバージョンタスクの第1の特殊化されたバージョンを識別するステップであって、第1の特殊化されたバージョンは、第1の処理ユニットによって実行される次のタスクである、識別するステップとを含むことができる。

いくつかの実施形態は、次のタスクがマルチバージョンタスクに関連しないとの判定に応答して次のタスクを実行するステップをさらに含むことができる。いくつかの実施形態は、第1の処理ユニットに関する所有権の要求に応答して、マルチバージョンタスクに対する所有権が第2の処理ユニットによって獲得されたと判定するステップと、マルチバージョンタスクに対する所有権が第2の処理ユニットによって獲得されたとの判定に応答して次のタスクを破棄するステップとをさらに含むことができる。いくつかの実施形態は、第1の処理ユニットに関連するタスクキュー内に優先順位タスクがあるかどうかを判定するステップと、第1の処理ユニットを介して優先順位タスクを実行するステップとをさらに含むことができ、次のタスクがマルチバージョンタスクに関連するとの判定に応答して第1の処理ユニットに関するマルチバージョンタスクに対する所有権を要求するステップは、プロセッサを介して、優先順位タスクの実行に応答して第1の処理ユニットに関するマルチバージョンタスクに対する所有権を要求するステップを含むことができる。いくつかの実施形態において、プロセッサは、第1の処理ユニットとすることができる。

さらなる実施形態は、上で説明された方法の動作を実行するためにプロセッサ実行可能命令を用いて構成されたコンピューティングデバイスを含む。さらなる実施形態は、上で説明された方法の機能を実行するための手段を含むコンピューティングデバイスを含む。さらなる実施形態は、コンピューティングデバイスに上で説明された方法の動作を実行させるように構成されたプロセッサ実行可能命令をその上に記憶された非一時的プロセッサ可読媒体を含む。

本明細書に組み込まれ、本明細書の一部を構成する添付図面は、例示的な実施形態を示し、上記で与えた一般的な説明および以下に与える発明を実施するための形態とともに、特許請求の範囲の特徴を説明する役割を果たす。

様々な実施形態における使用に適する例示的なマルチプロセッサコンピューティングデバイス(たとえば、異種システムオンチップ(SoC))のタスクキューおよび処理ユニットを示す構成要素ブロック図である。 マルチバージョンタスクの特殊化されたバージョンの従来の早期束縛を示す構成要素ブロック図である。 マルチバージョンタスクの特殊化されたバージョンの従来の早期束縛を示す構成要素ブロック図である。 様々な実施形態によるマルチプロセッサコンピューティングデバイスによるマルチバージョンタスクの特殊化されたバージョンの例示的な遅延束縛を示す構成要素ブロック図である。 様々な実施形態によるマルチプロセッサコンピューティングデバイスによるマルチバージョンタスクの特殊化されたバージョンの例示的な遅延束縛を示す構成要素ブロック図である。 様々な実施形態によるマルチプロセッサコンピューティングデバイスによるマルチバージョンタスクの特殊化されたバージョンの例示的な遅延束縛を示す構成要素ブロック図である。 マルチバージョンタスクの特殊化されたバージョンをスケジューリングするためにマルチプロセッサコンピューティングデバイスによって実行される具現化方法を示すプロセス流れ図である。 マルチバージョンタスクの実行を管理するためにマルチプロセッサコンピューティングデバイスによって実行される具現化方法を示すプロセス流れ図である。 様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを作成し、スケジューリングする(またはディスパッチする)ためにマルチプロセッサコンピューティングデバイスによって実行されるルーチンの擬似コードを示す図である。 様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを作成し、スケジューリングする(またはディスパッチする)ためにマルチプロセッサコンピューティングデバイスによって実行されるルーチンの擬似コードを示す図である。 様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイスによって実行される具現化方法を示すプロセス流れ図である。 様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイスによって実行されるルーチンの擬似コードを示す図である。 優先順位タスクおよびマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイスによって実行される具現化方法を示すプロセス流れ図である。 いくつかの実施形態における使用に適するマルチプロセッサコンピューティングデバイスを示す構成要素ブロック図である。

様々な実施形態が、添付図面を参照して詳細に説明される。可能な場合はいつでも、同一のまたは同様の部分を指すために、図面全体を通して同一の参照番号が使用される。特定の例および実施態様に対して行われる参照は、例示のためのものであり、実施形態または特許請求の範囲の範囲を限定することは意図されていない。

「例示的」という単語は、本明細書では、「例、実例、または例示として働く」を意味するのに使用される。本明細書で「例示的」と説明されるすべての実施態様は、必ずしも、他の実施態様より好ましいまたは有利とは考えられない。

「コンピューティングデバイス」という用語は、本明細書において、少なくとも1つのプロセッサを備えた電子デバイスを指すために使用される。コンピューティングデバイスの例は、モバイルデバイス(たとえば、セルラー電話、ウェアラブルデバイス、スマートフォン、ウェブパッド、タブレットコンピュータ、インターネット対応セルラー電話、Wi-Fi(登録商標)対応電子デバイス、携帯情報端末(PDA)、ラップトップコンピュータなど)、パーソナルコンピュータ、およびサーバコンピューティングデバイスを含むことができる。様々な実施形態において、コンピューティングデバイスは、様々なメモリおよび/またはデータストレージならびに、広域ネットワーク(WAN)接続(たとえば、セルラーネットワーク接続など)および/またはローカルエリアネットワーク(LAN)接続(たとえば、インターネットへの有線接続/Wi-Fi(登録商標)ルータを介するワイヤレス接続など)を確立するように構成されたネットワークトランシーバおよびアンテナなどのネットワーキング能力を伴って構成され得る。

「マルチプロセッサコンピューティングデバイス」という用語は、本明細書において、2つ以上の処理ユニットを有して構成されたコンピューティングデバイスを指すのに使用される。マルチプロセッサコンピューティングデバイスは、2つ以上の処理ユニットを使用して様々なタスク(たとえば、ルーチン、関数、計算、命令セットなど)を実行することができる。たとえば、マルチプロセッサコンピューティングデバイスは、それぞれが特殊化されたおよび/または汎用の作業負荷を実行するように構成された異なる処理ユニットを有する異種コンピューティングデバイス(たとえば、システムオンチップ(SoC))とされ得る。そのような処理ユニットは、様々なプロセッサデバイス、コア、複数のコアなどを含むことができる。たとえば、マルチプロセッサコンピューティングデバイスの処理ユニットは、アプリケーションプロセッサ(たとえば、CPU)ならびに/またはGPUおよびDSPなどの特殊化された処理デバイスを含むことができ、それらのいずれもが1つまたは複数の内部コアを含むことができる。

様々な実施形態は、マルチプロセッサコンピューティングデバイスによるマルチバージョンタスクの特定の(または特殊化された)バージョンを効率的にスケジューリングし、実行するための方法、デバイス、システム、および非一時的プロセッサ可読記憶媒体を提供する。様々な実施形態の概要として、マルチバージョンタスク(たとえば、複数のサポートされる実施態様またはバージョンを有する汎用タスク)が実行されるときに、マルチバージョンタスクの特殊化されたバージョンが、サポートされる処理ユニット(たとえば、CPU、GPU、DSPなど)ごとにエンキューされ得る。たとえば、行列乗算汎用タスクの複数のバージョンが、CPUおよびGPUと共に使用するために使用可能である場合に、コンピューティングデバイスは、CPU特殊化されたバージョンをCPUのタスクキューにエンキューすると同時に、GPU特殊化されたバージョンをGPUのタスクキューにエンキューすることができる。そのようなエンキューは、サポートされるバージョンを有する処理ユニットごとにタスクキュー内にポインタ(たとえば、マルチバージョンタスクと特殊化されたバージョンとの両方を示すポインタ)を配置することを含むことができる。処理ユニットが、対応するタスクキュー内のタスクを実行するときに、最終的に、第1の処理ユニットが、マルチバージョンタスクの第1の特殊化されたタスクを即座に実行するのに使用可能になる場合がある。第1の処理ユニットは、マルチバージョンタスクに対する所有権を要求するためにアプリケーションプログラマインターフェース(API)呼出しを行うことによるなど、マルチバージョンタスクに対する所有権を獲得することができる。第1の処理ユニットによって獲得された後に、その特定のマルチバージョンタスクに対する所有権をその後に要求するすべての他の処理ユニットは、所有権を受け取ることができず、したがって、マルチバージョンタスクの対応する特集化されたバージョンを実行することができない。そうではなく、これらの他の処理ユニットは、待つことなく、特殊化されたバージョンポインタを単純にデキューし、破棄し、他のタスクの処理に進むことができる。

マルチバージョンタスクが第1の処理ユニットによって所有される状態で、マルチプロセッサコンピューティングデバイスは、その処理ユニットが第1の特殊化されたバージョンの実行を完了した後に終了するようにマルチバージョンタスクを構成することができる。たとえば、第1の処理ユニットは、「finish_after()」API呼出しを実行することができる。そのような「finish after」動作は、第1の処理ユニットが第1の特殊化されたバージョンの実行を終了することに応答して、マルチバージョンタスクが、終了されたものとしてマークされることを保証することができる。これは、マルチバージョンタスクのすべてのバージョンのタスク依存性、待機、および寿命が一緒に結び付けられることを保証することができる。言い換えると、メインマルチバージョンタスクは、特殊化されたバージョンの完了によって自動的に完了され得る。この形で、「遅延束縛」技法が、特殊化されたバージョンを実際に実行するのに使用可能なるのが最速である処理ユニットによってマルチバージョンタスクが完了されることを可能にするために提供される。

いくつかの実施形態において、処理ユニットのタスクキュー内に特殊化されたバージョンの指示を明示的に配置する必要がない場合がある。その代わりに、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクによってサポートされるすべての処理ユニット(すなわち、それに関してマルチバージョンタスクの特殊化されたバージョンがあるすべての処理ユニット)のタスクキュー内に共通のマルチバージョンタスクポインタを配置することによって、マルチバージョン技法を実施することができる。たとえば、DSPは、タスクポインタをデキューし、タスクに対する所有権を獲得することができる。DSPは、タスクが代替物を有するかどうか(すなわち、タスクの複数の特殊化されたバージョンがあるかどうか)をチェックすることができる。代替物がある場合には、タスクは、マルチバージョンタスクとして識別され得、DSPは、マルチバージョンタスクの代替物(または特殊化されたバージョン)のリストをスキャンし、DSP用の対応する特殊化されたバージョンを実行することができる。

いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、実行されるべきタスクがマルチバージョンタスクであるかどうかを判定するアルゴリズムを実行することができる。タスクがマルチバージョンタスクではない場合に、そのタスクは、通常実行のために処理ユニットのタスクキュー内にエンキューされ得る。しかし、タスクがマルチバージョンタスクである場合には、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクのすべてのサポートされる(または要求される)特殊化されたバージョン(たとえば、GPU、CPU、DSPなどに関するバージョン)についてポインタを作成し、それらのポインタを適当な処理ユニットに対応するタスクキュー内に配置することができる。たとえば、行列乗算タスクのDSPバージョンのポインタは、DSPのタスクキューに入力され得るなどである。いくつかの場合において、処理ユニットアイデンティティまたは他のバージョン関連付けは、ポインタの最下位4ビット内でコア識別子(ID)を符号化するなど、ポインタ自体の中に記憶され得る。いくつかの実施形態において、マルチバージョンタスクが実行のために開始されるときに、そのタスクは、準備ができたとき(たとえば、先行物(predecessor)依存性を有しないとき)またはタスクがスケジューリング最適化の対象である場合にはより早くのいずれかにスケジューリングに関して検討され得る。

いくつかの実施形態において、マルチバージョンタスクは、タスク、引数、およびマルチバージョンタスクの特殊化されたバージョンを実行できる潜在的な処理ユニット(たとえば、コア)を指示するAPI呼出しを介して作成され得る。マルチバージョンタスクは、プログラマ、コンパイラ、またはランタイムシステムによって作成され得る。いくつかの実施形態において、特殊化されたバージョンがAPI呼出し内で提示される順序は、相対的なプリファレンスまたは優先順位を指示することができる。そのようなAPI呼出し内の特殊化されたバージョン(または実施態様)ごとに、マルチプロセッサコンピューティングデバイスは(たとえば、ランタイム機能性を介して)、サポートされる処理ユニットのタスクキュー内にエンキューされるべきタスク(またはタスクポインタ)を作成することができる。たとえば、CPUまたはGPUのいずれかによる実行のために調整された行列乗算タスクの特殊化されたバージョンは、API呼出しがプログラマによってコード内でまたはコンパイラ/ランタイムシステムによって呼び出されることに応答して、適当なタスクキュー内にエンキューされ得る。

様々な実施形態において、特定の処理ユニットは、スレッドプール内の関連付けられたスレッドを介して、エンキューされたタスク(またはタスクポインタ)を処理するように構成され得る。たとえば、DSPスレッドは、DSPのタスクキューからマルチバージョンタスクの特殊化されたバージョンのポインタをデキューすることができる。以下は、そのようなスレッドによる動作の非限定的な例示である。DSPに関連付けられたスレッドは、ポインタビット内のバージョン番号を識別するためにマスクを適用することによるなど、デキューされたタスク(またはポインタ)がマルチバージョンタスクに関連するか否かを判定する動作を実行することができる。デキューされたタスクがマルチバージョンタスクに関しない場合に、DSPのスレッドは、デキューされたタスクを単純に実行することができる。しかし、デキューされたタスク(またはポインタ)がマルチバージョンタスクに関する場合に、DSPスレッドは、マルチバージョンタスクに対する所有権を要求し、したがって、任意の他のスレッドがマルチバージョンタスクに対する所有権を既に獲得済みであるかどうかを調べることができる。所有権が獲得される場合に、DSPスレッドは、DSPに関連する特殊化されたバージョンタスクの実行の後に終了するようにマルチバージョンタスクをセットする(または、マルチバージョンタスクがセットされるように要求する)ことができ、その特殊化されたバージョンを実行することができる。デキューされたタスクがマルチバージョンであるが、所有権が、そのスレッドによって獲得され得ない場合には、DSPスレッドは、デキューされたタスク(たとえば、そのタスクのデキューされたタスクポインタ)を単純に破棄し、DSPスレッドに関連するタスクキュー内の任意の他のタスクを処理することができる。

マルチプロセッサコンピューティングデバイスの処理ユニットは、それぞれ、特定のタイプのタスクにネイティブに関連付けられ得る。たとえば、GPUは、主に、タッチスクリーン上に表示され得るグラフィックスをレンダリングするための動作を実行するためにSoCモバイルデバイス内で使用され得るなどである。コンピューティングデバイスの主たる機能は、処理ユニットが、並列処理スケジューリングに起因するなど、ネイティブ動作に正しく優先順位を付けることに失敗する場合に損害を受ける可能性がある。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスの処理ユニットは、マルチバージョンタスクのすべての特殊化されたバージョンの前に実行されなければならない任意の優先順位タスクを識別するために、タスクキュー内のタスクを評価するように構成され得る。たとえば、次にデキューされ、GPUにおいて実行されるタスクが、行列乗算タスクの1バージョンである場合があるが、GPUは、まず、高優先順位レンダリングを実行し、キュー内のバージョンタスクの背後にあるタスクを表示することができる。この形において、処理ユニットが優先順位タスクを実行するときに別の処理タスクがマルチバージョンタスクに関して使用可能になる可能性があるので、処理ユニットが、マルチバージョンタスクの特殊化されたバージョンに対する所有権を獲得する機会を逃すことが可能になる場合がある。たとえば、マルチバージョンタスクに対する所有権を要求する前に、GPUが表示動作を完了する間に、DSPがマルチバージョンタスクに対する所有権を獲得する場合がある。ネイティブ作業負荷に汎用マルチバージョンタスクより高い優先順位を与えることによって、処理ユニットは、マルチバージョンタスクを実行するためにまだ競合しながら、優先順位、ネイティブ能力(たとえば、レンダリング、信号処理など)を維持することができる。

本明細書で説明される「遅延束縛」スケジューリング技法は、割当時に処理ユニットに対する相対負荷を査定せず、したがって、マルチバージョンタスクに達するのが実際に最速である処理ユニットが、タスクの対応するバージョンを実行し始めることを保証する。たとえば、DSPのタスクキューが、第1の時にGPUより少数のエンキューされた作業アイテムを有する場合であっても、実施形態技法を実施するマルチプロセッサコンピューティングデバイスは、より高速のGPUが第2の時にマルチバージョンタスクの対応する特殊化されたバージョンを実行することを可能にすることができる。したがって、実施形態技法は、マルチプロセッサコンピューティングデバイスのリソース消費(たとえば、メモリ、処理ユニットなど)の全体的な効率、負荷平衡化、および熱管理を改善するのに有益である。たとえば、マルチバージョンタスクのバージョンに関する遅延束縛を提供することによって、実施形態技法は、マルチプロセッサコンピューティングデバイス内での実行のホットスポットを減少させ、個々の処理ユニットが不釣り合いに酷使されない可能性があるのでコンピューティングデバイス全体でのより多くの処理を可能にすることができる。

処理ユニットが、即座の実行を開始するために実際に使用可能であるときに限って汎用のマルチバージョンタスクの特殊化されたバージョンを実行する権利を獲得することを可能にすることによって、実施形態技法は、タスクのジャストインタイムスケジューリングを提供する。この形において、実施形態技法は、すべてのマルチバージョンタスクを走行させるのに最良の処理ユニットを識別するために、潜在的に不正確でコストの高い計算および/または測定値に頼らない。そうではなく、処理ユニットは、マルチバージョンタスクの特殊化されたバージョンを実行するために競合するように構成され、これによって、タスクの実行を開始する実際の能力に基づいてコンピューティングデバイス全体で作業負荷を拡散する。そのような技法は、通常のマルチバージョンスケジューリング方式を用いて考慮される場合もされない場合もある予見されない動作条件を自然に考慮に入れ、より高い性能、より低いエネルギー消費、およびより少ないメモリ消費をもたらす。

実施形態技法は、どの処理ユニットにタスクを割り当てられるのかを選択するために現在の作業負荷を計算し、またはありそうな作業負荷および/もしくは処理ユニットの能力を予測する場合がある従来の技法などの従来の方式とは別個である。そのような従来の方式は、しばしば、予測された実行時間に影響し得るメモリからのデータ負荷など、タスクの実行中に処理ユニットが出会う可能性がある動的イベントを考慮に入れることに失敗する場合がある。いくつかの従来の方式は、タスクの最良の宛先の先験的予測を実行するのにプロファイルまたは他の事前に計算されたデータをも使用する場合がある。逆に、実施形態技法は、複数のバージョンを同時にディスパッチし、処理ユニットが共通のマルチバージョンタスクの所有権について競合することを可能にする。言い換えると、実施形態技法は、マルチバージョンタスクの特殊化されたバージョンを割り当てるために事前定義の優先順位、コスト、および/または予測モデルを使用するのではなく、その代わりに、マルチバージョンタスクを実際に実行するのに最初に使用可能になる処理ユニットに基づいて実行割当を行う。

さらに、いくつかの従来の方式とは異なって、実施形態技法は、仮想メモリアドレス空間の考慮または特殊なタスクキューを必要としない。具体的には、いくつかの従来の方式は、すべての処理ユニットがそこからマルチバージョンタスクを盗むことができる特殊なタスクキューを利用する場合がある。そのような特殊なキュー方式は、サポートされる実施態様の異なる組合せを有するタスクに対処するために無数のキューが要求される可能性があるので、有限のリソースを有するシステム内でのオープンエンドスケジューリングに関して実現可能ではない可能性がある。たとえば、第1のマルチバージョンタスクが、CPU実施態様およびGPU実施態様だけを有する場合があり、第2のマルチバージョンタスクが、CPU実施態様、GPU実施態様、およびDSP実施態様を有する場合があり、第3のマルチバージョンタスクが、複数のCPU実施態様を含み、それぞれが別々の特殊なタスクキューを必要とする場合がある。そのような従来の技法は、処理ユニットが、割り当てられ、処理ユニット上で実行され得るタスクを識別するために各特殊なタスクキューをスキャンすることを要求する可能性がある。実施形態技法は、そのような従来の方式より効率的であり、単一バージョンタスに必要なものと同数のタスクキューだけを必要とする。

様々な実施形態において、マルチプロセッサコンピューティングデバイスは、マルチバージョンまたは他のタスクのスケジューリングまたはディスパッチのための様々な動作を実行するために1つまたは複数のランタイム機能性(たとえば、ランタイムサービス、ルーチン、スレッド、論理、または他のソフトウェア要素など)を実行することができる。そのようなランタイム機能性は、オペレーティングシステム、サービス、および/または他のシステム関連ソフトウェアを実行するように構成された汎用プロセッサまたはアプリケーションプロセッサなどのコンピューティングデバイスのプロセッサによって実行され得る専用のランタイム機能性を含むことができる。たとえば、アプリケーションプロセッサ上で実行するランタイム機能性は、マルチバージョンタスクの特殊化されたバージョンを実行するために処理ユニットに所有権を提供するように構成され得る。個々の処理ユニットにおいてタスクを処理するための専用の機能性など、他のランタイム機能性も使用され得る。

図1は、様々な実施形態と共に使用するのに適する例示的なマルチプロセッサコンピューティングデバイス101(たとえば、異種システムオンチップ(SoC)デバイス)の様々な構成要素を示す図100である。マルチプロセッサコンピューティングデバイス101は、第1のCPU102(図1内では「CPU_A」102と称する)、第2のCPU112(図1内では「CPU_B」112と称する)、GPU122、およびDSP132などの複数の処理ユニットを含むことができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイス101は、「ARM big.Little」アーキテクチャを利用することができ、第1のCPU102は、相対的に高い処理能力を有するが相対的に高い電力要件をも有する「ビッグ」処理ユニットとすることができ、第2のCPU112は、第1のCPU102よりも相対的に低い処理能力を有するが相対的に低い電力要件をも有する「リトル」処理ユニットとすることができる。

マルチプロセッサコンピューティングデバイス101は、様々な処理ユニット102、112、122、132の間での並列処理、ワークシェアリング、および/またはワーク「スティーリング」(work stealing)をサポートするように構成され得る。具体的には、処理ユニット102、112、122、132の任意の組合せは、実行のために別個の作業アイテム(たとえば、タスク)を作成し、かつ/または受け取るように構成され得る。処理ユニット102、112、122、132の各々は、処理ユニット102、112、122、132によって実行されるタスク(および/またはタスクに関連するデータ)を一時的に記憶し、編成するために1つまたは複数のキュー(またはタスクキュー)を利用することができる。たとえば、図1を参照すると、第1のCPU102は、第1のCPU102によるローカル実行のためにタスクキュー166、168、176からタスクを取り出すことができ、他のデバイスによる実行のためにキュー170、172、174にタスクを配置することができ、第2のCPU112は、第2のCPU112によるローカル実行のためにキュー174、178、180からタスクを取り出すことができ、他のデバイスによる実行のためにキュー170、172、176にタスクを配置することができ、GPU122は、キュー172からタスクを取り出すことができ、DSP132は、キュー170からタスクを取り出すことができる。いくつかの実施形態において、いくつかのタスクキュー170、172、174、176は、いわゆるマルチプロデューサ、マルチコンシューマキューとすることができ、いくつかのタスクキュー166、168、178、180は、いわゆるシングルプロデューサ、マルチコンシューマキューとすることができ、他のタスクキューは、いわゆるシングルプロデューサ、シングルコンシューマキューとすることができる。いくつかの場合に、タスクは、ある種の計算を分割する、作業負荷のプログラマによる指定など、コード内のインジケータに基づいて生成され得る。さらに、処理ユニット102、112、122、132の任意の組合せは、通常、ランタイム機能性による分配のためにサブミットされ得る作業負荷内のタスクを識別できる可能性がある。

いくつかの実施形態において、ランタイム機能性(たとえば、ランタイムエンジン、タスクスケジューラなど)は、処理ユニット102、112、122、132にタスクをディスパッチするための宛先を判定するように構成され得る。たとえば、処理ユニット102、112、122、132のいずれかにオフロードされ得る新しい汎用タスクを識別することに応答して、ランタイム機能性は、タスクを実行するために最良の処理ユニットを識別することができ、それ相応にタスクをディスパッチすることができる。そのようなランタイム機能性は、第1のCPU102などのアプリケーションプロセッサまたはメインプロセッサ上で実行され得る。具体的には、ランタイム機能性は、1つまたは複数のオペレーティングシステム対応スレッド(たとえば、「メインスレッド」150)を介して実行され得る。たとえば、ランタイム機能性の判定に基づいて、メインスレッド150は、様々なタスクキュー166、170、172、180にタスクデータを供給することができる。

いくつかの実施形態において、各処理ユニット102、112、122、132は、お互いにタスクを供給できる場合がある。たとえば、DSP132は、第1のCPU102、第2のCPU112、および/またはGPU122のタスクを作成することができ、逆も同様である。別の例として、GPU122は、第1のCPU102、第2のCPU112、および/またはDSP132のタスクを作成することができ、逆も同様である。

図2A〜図2Bは、マルチプロセッサコンピューティングデバイス(たとえば、異種システムオンチップ(SoC)デバイス)がマルチバージョンタスクの特殊化されたバージョンの従来の「早期束縛」を実行するシナリオを示す。通常、マルチバージョンタスクに関する従来のタスクスケジューリングは、マルチバージョンタスクの特定のバージョンを実行するのに最もよく使用可能であるか実行することができると予測される処理ユニットを先験的に識別することができる。そのような早期束縛技法は、しばしば、タスクキュー内のタスクの個数、タスクサイズ、ならびに処理ユニットの速度および/または効率に影響する他の要因を評価することによるなど、スケジューリング時の適用可能な処理ユニット(たとえば、コア)上に存在する負荷を評価する。言い換えると、スケジューリング時に最も軽い負荷を有する処理ユニットが、タスクを割り当てられ得る。たとえば、GPUの現在のタスクキューが評価時にCPUおよびDSPのタスクキューより少数の作業アイテムを含むとの判定に応答して、スケジューラは、CPUまたはDSPではなくGPUにマルチバージョンタスクのバージョンを割り当てることができる。これらの評価(または予測)は、割り当てられた処理ユニットがマルチバージョンタスクの特殊化されたバージョンを実行するのに実際に使用可能であるときの前に発生し得る。

しかし、実行速度と、プログラムへの入力および計算リソースの可用性などの様々なランタイム条件との相違に起因して、現在のまたは予測された負荷評価に基づく処理ユニットへのタスクの先験的割当は、準最適である可能性がある。たとえば、マルチバージョンタスクのバージョンが、関連するタスクキュー内にGPUのタスクキュー内より少数のタスクを有するリトルCPUに割り当てられる場合であっても、GPUは、リトルCPUの相対的に弱い計算能力(たとえば、より低い周波数、サイクル当たりの命令など)に起因して、リトルCPUより高速により多くのタスクを終了することができる。したがって、GPUは、リトルCPUの前にマルチバージョンタスクを実行し終える可能性がある。そのような従来のスケジューリング技法は、近視眼的であり、全体的なシステム性能に悪影響を及ぼす可能性がある。

従来の早期束縛技法は、特殊化されたバージョンの割当が動的負荷平衡化に関して再割当され得ないので、マルチバージョンタスクに関してさらに問題である可能性がある。具体的には、対応するタスクキュー内に作業アイテムを有しない使用可能な処理ユニットが他のタスクキューからの作業アイテムを採用することを可能にする「ワークスティーリング」ポリシーは、タスクキュー内の特殊化されたバージョンが特定のタイプの処理ユニット上でのみ実行され得るので、適用可能ではない可能性がある。たとえば、作業に使用可能であるDSPは、CPUのタスクキューからのマルチバージョンタスクの特殊化されたバージョンを採用できない場合がある。というのは、その特殊化されたタスクが、CPUのために特に構成されているからである。

図2Aは、第1の時のマルチプロセッサコンピューティングデバイス101によってマルチバージョンタスク201(図2A内では「タスク_1」と称する)の特定のバージョンの例示的な早期束縛スケジューリング(またはディスパッチ)を示す図200を含む。マルチバージョンタスク201は、様々な処理ユニットが実行できる可能性がある計算などの(たとえば、行列乗算計算など)汎用タスクとすることができる。マルチバージョンタスク201は、共通の計算、処理、および/または機能を達成するようにそれぞれ構成されたマルチバージョンタスク201の複数の特殊化されたバージョンを含み、または他の形でこれに関連付けられ得る。たとえば、マルチバージョンタスク201は、第1のCPU102(図2A〜図2B内では「構成要素CPU_A」と称する)上での実行のために構成された第1の特殊化されたバージョン202a、第2のCPU112(図2A〜図2B内では「構成要素CPU_B」と称する)上での実行のために構成された第2の特殊化されたバージョン202b、GPU122上での実行のために構成された第3の特殊化されたバージョン202c、およびDSP132上での実行のために構成された第4の特殊化されたバージョン202dを含むことができる。

任意の第1の時に、処理ユニット102、112、122、132の現在の作業負荷に基づいてタスクをスケジューリングするように構成された従来の負荷ベースのスケジューラモジュール210は、マルチバージョンタスク201が実行のためにスケジューリングされる準備ができていると判定することができる。負荷ベースのスケジューラモジュール210は、新しいタスクを受け取り、最小の作業負荷(たとえば、最小個数のキュータスク)を有する処理ユニットによる実行のためにディスパッチするアプリケーションプロセッサを介してスレッドを介して実行されるスケジューラ機能性とすることができる。単純さのために、負荷ベースのスケジューラモジュール210は、図2A〜図2B内では、スレッド(たとえば、メインスレッド150)を介して実行されるように構成された単一のモジュール(たとえば、ソフトウェア、コンポーネント、命令、ルーチン、論理など)として図示されている。しかし、負荷ベースのスケジューラモジュール210は、単一の(またはメイン)スレッドによって使用可能にされる場合とされない場合とがある機能性を表しまたは他の形で含むことができる。たとえば、いくつかの実施形態において、負荷ベースのスケジューラモジュール210は、マルチプロセッサコンピューティングデバイス101内の複数のスレッドにまたがって実行され、使用可能にされる論理、コンポーネント、ルーチン、命令、および/または他の機能性からなるものとすることができる。

負荷ベースのスケジューラモジュール210は、処理されるために現在キューに入れられている最小個数のタスクを現在有する処理ユニットを識別することによるなど、複数の処理ユニット102、112、122、132の動作状態を評価することができる。たとえば、図2Aの図示に関して、第1の時に、負荷ベースのスケジューラモジュール210は、第1のCPU102に関連する第1のタスクキュー220aが、キューに入れられた4つのタスク230aを有する可能性があり、第2のCPU112に関連する第2のタスクキュー220bが、キューに入れられた2つのタスク230bを有する可能性があり、GPU122に関連する第3のタスクキュー220cが、キューに入れられた5つのタスク230cを有する可能性があり、DSP132に関連する第4のタスクキュー220dが、キューに入れられた3つのタスク230dを有する可能性があることを識別することができる。タスクキュー220a〜220d内の現在キューに入れられているタスクの個数に基づいて、負荷ベースのスケジューラモジュール210は、第2のタスクキュー220bが最少の現在キューに入れられているタスク230bを有することに起因して、マルチバージョンタスク201のバージョンを実行するのに適する処理ユニットとして第2のCPU112を識別することができる。負荷ベースのスケジューラモジュール210は、第2の特殊化されたバージョン202b(または第2の特殊化されたバージョン202bの表現)を第2のタスクキュー220b内に配置することによって、第2のCPU112にマルチバージョンタスク201を割り当てることができる。

しかし、異なる処理ユニット102、112、122、132が、異なる速度で動作を実行する可能性があり、かつ/またはタスクが負荷ベースのスケジューラモジュール210によって割り当てられた後の様々な予見されない要因もしくは条件によって影響される可能性があるので、マルチバージョンタスク201は、マルチプロセッサコンピューティングデバイス101によって準最適に実行される可能性がある。たとえば、負荷ベースのスケジューラモジュール210の判定が、発生し、作業アイテムが処理ユニットによって実行される速度にその後に影響する可能性がある動的なデバイス動作条件、実行される作業アイテムの複雑さなどを考慮することに失敗する場合がある。ランダムデバイス障害または非効率性など、異なる処理ユニット102、112、122、132に、最終的に、他の処理ユニットの前に使用可能(または使用不能)にならせるいくつかの条件が、予測可能であるか測定され得る場合とそうでない場合とがある。言い換えると、処理ユニット102、112、122、132の処理能力を予測しかつ/または測定することは、不正確および/または不明確である可能性があり、したがって、準最適なタスク割当をもたらす可能性がある。

図2Bは、図2A内に示された従来の早期束縛スケジューリングに起因する第2の時のコンピューティングデバイス101のそのような非効率な条件を示す図250を含む。具体的には、その間に処理ユニット102、112、122、132が対応するタスクキュー220a〜220d内のタスクを処理する時間の期間の後に、GPU122は、使用可能になり、したがって、空のタスクキュー220cに起因して非アクティブになる可能性がある。さらに、第1の時における負荷ベースのスケジューラモジュール210による負荷判定にもかかわらず、マルチバージョンタスク201の第2の特殊化されたバージョン202bは、第2の時においてまだ第2のCPU112による実行を開始していない。言い換えると、第1の時においてタスクキュー220b内に最少のタスクを有するにもかかわらず、第2のCPU112は、第2のCPU112が第2の特殊化されたバージョン202bの実行を開始できない間にGPU122が第2の時において使用可能になるので、マルチバージョンタスク201を実行するための最終的な最良の選択ではなかった。したがって、従来の先験的「早期束縛」ポリシーの明白な制限に起因して、マルチプロセッサコンピューティングデバイス内のマルチバージョンタスクスケジューリングを改善する機会がある。

図3A〜図3Cは、図2A〜図2Bに示されたものなど、マルチバージョンタスクの先駆的スケジューリングポリシーの短所を克服するのに使用され得るいくつかの実施形態による例示的な「遅延束縛」技法を示す。具体的には、実施形態遅延束縛動作は、処理ユニットの実行の相対速度に基づいてマルチバージョンタスクの特殊化されたバージョンを割り当てることができる。これは、タスクがタスクキュー内に配置されるときのマルチプロセッサコンピューティングデバイスの処理ユニットに対する相対負荷にかかわりなく、特殊化されたバージョンを実行する準備ができる最速の処理ユニットがマルチバージョンタスクを実行できることを保証することができる。

図3A〜図3C内に示された構成要素は、例示のためのみに提供され、様々な実施形態による方法を実施するのに適する特定の構造的実施態様に実施形態または特許請求の範囲を限定することは意図されていない。たとえば、タスクキュー220a〜220dは、マルチプロセッサコンピューティングデバイス内の様々なデータ構造および/または他の同等の構造内で表現され得る。別の例として、並列スケジューラモジュール311は、マルチプロセッサコンピューティングデバイスの1つまたは複数の処理ユニットによってサポートされ得る1つまたは複数のコンポーネント、論理、デバイス、および/または他の機能性を表すことができる。

図3Aは、汎用動作(たとえば、計算など)を実行するために作成され得るマルチバージョンタスク301を示す図300を含む。マルチバージョンタスク301(図3A〜図3C内では「タスク_2」と称する)は、マルチバージョンタスク301の複数の特殊化されたバージョン302a〜302dを含み、または他の形でこれに関連付けられ得る。たとえば、マルチバージョンタスク301は、第1のCPU102上での実行のために構成された第1の特殊化されたバージョン302a、第2のCPU112上での実行のために構成された第2の特殊化されたバージョン302b、GPU122上での実行のために構成された第3の特殊化されたバージョン302c、およびDSP132上での実行のために構成された第4の特殊化されたバージョン302dを含むことができる。

いくつかの実施形態において、マルチバージョンタスク301は、処理ユニット102、112、122、132がマルチバージョンタスク301にどのようにアクセスしまたは他の形で実行するのかを制御するためにマルチプロセッサコンピューティングデバイス101によって使用され得る記憶されたデータに関連付けられることも可能である。たとえば、マルチバージョンタスク301は、マルチバージョンタスク301を実行する権利を獲得した処理ユニットの識別子(またはID)(すなわち、マルチバージョンタスク301に対する「所有権」を有する処理ユニットのID)を記憶するデータフィールドなど、所有権データ310を含みまたは他の形でこれに関連付けられ得る。いくつかの実施形態において、所有権データ310は、識別子を記憶するのではなく、マルチバージョンタスク301に対する所有権がいずれかの処理ユニットによって獲得されたか否かを示すデータ(たとえば、所有されている/所有されていないを示す単一のビット)を単純に記憶することができる。

マルチバージョンタスク301が処理ユニットによって所有される前に、所有権データ310は、ヌルとすることができる。マルチバージョンタスク301に関連する記憶されたデータは、マルチバージョンタスク301の任意の特殊化されたバージョン302a〜302dが完了されたかどうかを示す情報を記憶するデータフィールドなど、完了データ312をも含むことができる。たとえば、デフォルトとして、完了データ312は、否定の値(たとえば、0、「N」、「no」など)にセットされ得るが、マルチバージョンタスク301に対する所有権を有する処理ユニットが特殊化されたバージョン302a〜302dのうちの1つを実行した後に、完了データ312は、タスクが完了されることを示すために肯定の値(たとえば、1、「Y」、「yes」など)にセットされ得る。いくつかの実施形態において、データフィールド310〜312は、データアレイ、システム変数、レジスタ、および/またはマルチプロセッサコンピューティングデバイス101からアクセス可能な他の構造など、揮発性メモリまたは不揮発性メモリ内に記憶され得る。

任意の第1の時に、タスクをスケジューリングするように構成されたランタイム機能性(すなわち、並列スケジューラモジュール311)は、マルチバージョンタスク301が実行のために作成されまたは他の形でスケジューリングされる準備ができていると判定することができる。たとえば、並列スケジューラモジュール311は、新しいタスクを受け取り、ディスパッチするアプリケーションプロセッサによってスレッドを介して実行されるスケジューラ機能性とすることができる。単純さのために、並列スケジューラモジュール311は、図3A〜図3C内では、スレッド(たとえば、メインスレッド150)を介して実行されるように構成された単一のモジュール(たとえば、ソフトウェア、コンポーネント、命令、ルーチン、論理など)として図示されている。しかし、並列スケジューラモジュール311は、単一の(またはメイン)スレッドによってイネーブルされる場合もされない場合もある機能性を表しまたは他の形でそれらからなることができる。たとえば、いくつかの実施形態において、並列スケジューラモジュール311は、マルチプロセッサコンピューティングデバイス101内の複数のスレッドにまたがって実行され、イネーブルされる論理、コンポーネント、ルーチン、命令、および/または他の機能性からなることができる。いくつかの実施形態において、並列スケジューラモジュール311は、必ずしもマルチプロセッサコンピューティングデバイス101の様々な処理ユニット(たとえば、GPU122、DSP132など)とは別々の実行エンティティではない場合がある。たとえば、並列スケジューラモジュール311は、説明されるようにマルチバージョンタスクを実行する動作の一部として任意のプロセッサまたはデバイス(たとえば、GPU122など)によってインラインで実行され得る論理機能性を表すことができる。

第1の時の処理ユニット102、112、122、132の作業負荷(たとえば、他のタスク230a〜230d)にかかわりなく、並列スケジューラモジュール311は、処理ユニット102、112、122、132のタスクキュー220a〜220dに特殊化されたバージョン302a〜302dのそれぞれを同時に割り当てることができる。たとえば、並列スケジューラモジュール311は、第1のCPU102に関連する第1のタスクキュー220aにCPUによる実行のために構成された第1の特殊化されたバージョン302aを、第2のCPU112に関連する第2のタスクキュー220bにCPUによる実行のために構成された第2の特殊化されたバージョン302bを、GPU122に関連する第3のタスクキュー220cにGPUによる実行のために構成された第3の特殊化されたバージョン302cを、DSP132に関連する第4のタスクキュー220dにDSPによる実行のために構成された第4の特殊化されたバージョン302dを送ることができる。いくつかの実施形態において、特殊化されたバージョン302a〜302dを送ることは、適当なタスクキュー220a〜220d内に特殊化されたバージョン302a〜302dのタスクポインタまたは他のデータ表現を配置することを含むことができる。

図3Bは、マルチバージョンタスク301に対する所有権を獲得する処理ユニット(すなわち、GPU122)を示す図350を含む。たとえば、図3A内に示された第1の時の後に、GPU122は、第3のタスクキュー220c内のすべての他のタスク230cを完了し、したがって、マルチバージョンタスク301の第3の特殊化されたバージョン302cを実行するのに使用可能になる場合がある。GPU122は、マルチバージョンタスク301に対する所有権を獲得するために、並列スケジューラモジュール311(すなわち、ランタイム機能性)と信号352を交換することができる。たとえば、第3のタスクキュー220c内の次に実行すべきタスクが第3の特殊化されたバージョン302cであると判定したときに、GPU122は、並列スケジューラモジュール311に要求信号を送信することができ、これに応答して、並列スケジューラモジュール311は、GPU122が所有権を獲得したかどうかを示す応答信号を送信することができる。いくつかの実施形態において、信号352は、GPU122がマルチバージョンタスク301の特殊化されたバージョンを終了することに応答して終了するように構成されるようにマルチバージョンタスク301を構成するためのGPU122からのAPI呼出しを含むことができる。たとえば、GPU122からの信号352は、並列スケジューラモジュール311に、第3の特殊化されたバージョン302cが完了したことの判定に応答してマルチバージョンタスク301のすべての関連するバージョン(たとえば、302a、302b、302d)を完了し、取り消し、または他の形で終了するようにマルチバージョンタスク301を構成させる「finish_after()」呼出しを含むことができる。言い換えると、「finish_after()」は、マルチバージョンタスクの1つのみの特殊化されたバージョンの実行の後にマルチバージョンタスクに終了させる機構とすることができる。

いくつかの実施形態において、並列スケジューラモジュール311は、GPU122からのシグナリング352の受信に応答してマルチバージョンタスク301に関連する所有権データ310をチェックし、かつ/または更新するために動作354を実行することができる。たとえば、並列スケジューラモジュール311は、処理ユニット識別子が既にセットされているかどうかを判定するために所有権データ310を照会することができ、そうでない場合には、GPU122の識別子(たとえば、「GPU」)を所有権データ310内に記憶させることができる。

GPU122がマルチバージョンタスク301に対する所有権を獲得した(すなわち、GPU122が、マルチバージョンタスク301の特殊化されたバージョンを実行する排他的権利を有した)後に、他の処理ユニット102、112、132は、他のタスクを最終的に完了し、特殊化されたバージョン302a、302b、302dを実行するのに使用可能になることができる。しかし、並列スケジューラモジュール311との交換に応答して、これらの他の処理ユニット102、112、132は、マルチバージョンタスク301に対する所有権を拒否され得、したがって、対応する特殊化されたバージョン302a、302b、302dの実行から除外され得る。その代わりに、他の処理ユニット102、112、132は、そのような所有権否定に起因して、特殊化されたバージョン302a、302b、302dを実行せずに単純に破棄するように構成され得る。たとえば、特殊化されたバージョン302a、302b、302dは、GPU122がマルチバージョンタスク301に対する所有権を獲得することに応答して破棄され得る。いくつかの場合において、GPU122は、他の処理ユニット102、112、132が対応する特殊化されたバージョン302a、302b、302dを実行する準備ができるときまでに第3の特殊化されたバージョン302cの実行を既に完了し終えている場合があり、したがって、他の処理ユニット102、112、132は、特殊化されたバージョン302a、302b、302dをデキューし、破棄し、対応するタスクキュー220a、220b、220d内に入力された他のタスクの実行を単純に開始することができる。

図3Cは、GPU122が第3の特殊化されたバージョン302cの実行を完了し、したがってマルチバージョンタスク301を完了した後に発生するシグナリングを示す図375を含む。いくつかの実施形態において、GPU122は、第3の特殊化されたバージョン302cの完了を示す信号376を並列スケジューラモジュール311に送信することができ、次に、並列スケジューラモジュール311は、データ312を更新する(たとえば、「Y」値を記憶する)ために動作378を実行することができる。いくつかの実施形態において、並列スケジューラモジュール311は、他の処理ユニット102、112、132に、マルチバージョンタスク301の対応する特殊化されたバージョン302a、302b、302dをデキューさせまたはディスエーブルさせ、対応するタスクキュー220a、220b、220d内の他のタスクの実行を再開させる信号380を他の処理ユニット102、112、132と交換することができる。たとえば、特殊化されたバージョン302a、302b、302dを実行する準備ができたときに、他の処理ユニット102、112、132は、所有権を要求することができる。これに応答して、信号380は、マルチバージョンタスク301の所有権が入手不能であることを示すことができ、したがって、処理ユニット102、112、132は、特殊化されたバージョン302a、302b、302dをディスエーブルし、マルチバージョンタスク301に関連しない他のタスクに進むことができる。

いくつかの実施形態において、動作378は、マルチバージョンタスク301に関連するデータをメモリから除去することによるなど、マルチバージョンタスク301をデキューし、および/または他の形で削除することを含むことができる。いくつかの実施形態において、マルチバージョンタスク301に対する所有権を獲得するための元の信号352が、他の処理ユニット102、112、132がそれぞれの特殊化されたバージョン302a、302b、302dを実行することをディスエーブルするのに適当である場合があるので、GPUは、信号376を送信することを要求されない場合がある。たとえば、信号352が送られた後に、DSP132は、第4の特殊化されたバージョン302dをデキューし、関連するマルチバージョンタスク301がGPU122によって既に所有されていると判定し(たとえば、並列スケジューラモジュール311へのシグナリングを介して)、したがって、第4の特殊化されたバージョン302dを単純に破棄することができる。

図4Aは、マルチバージョンタスクの特殊化されたバージョンをスケジューリングし、様々な処理ユニットタスクキューにディスパッチするためにマルチプロセッサコンピューティングデバイスによって実行される方法400を示す。説明されるように、マルチプロセッサコンピューティングデバイス(たとえば、図1〜図3C内のマルチプロセッサコンピューティングデバイス101)は、複数の処理ユニット、たとえばマルチバージョンタスクに関してサポートされるいくつかのまたはすべての処理ユニットに特殊化されたバージョンを同時に割り当てることによって、ランタイムにマルチバージョンタスクの遅延束縛を実行するように構成され得る。方法400は、様々な処理ユニットの適当なタスクキュー内に特殊化されたバージョンを配置するためにマルチプロセッサコンピューティングデバイスによって実行され得る。いくつかの実施形態において、方法400の様々な動作は、図1〜図3Cのマルチプロセッサコンピューティングデバイス101のCPU102、GPU122、またはDSP132などのマルチプロセッサコンピューティングデバイスの処理ユニットを介して実行するランタイム機能性(たとえば、図3A〜図3Cの並列スケジューラモジュール311)によって実行され得る。

マルチプロセッサコンピューティングデバイスは、ブロック402において、複数の処理ユニットのうちの1つの上で実行される特殊化されたバージョンを有するマルチバージョンタスクを識別することができる。各特殊化されたバージョンは、複数の処理ユニット(たとえば、GPU、CPU、DSPなど)の異なる処理ユニットによって実行されるように構成され得る。識別は、マルチプロセッサコンピューティングデバイスによってスケジューリングされるタスクが特殊化されたバージョン(または代替タスク/識別子)に関連するかどうかを判定することを含むことができる。たとえば、マルチプロセッサコンピューティングデバイスは、スケジューリングされる新しいタスクが特殊化されたバージョンを示す代替番号を有するかどうかを判定する動作(たとえば、図5B内の「has_alternatives()」関数呼出し)を実行することができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、処理ユニットによるマルチバージョンタスクの作成に応答して、そのような識別を行うことができる。たとえば、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクとしてサポートされる特殊化されたバージョンを示すAPI呼出しを介して作成されるすべての新しいタスクを識別することができる。マルチバージョンタスクを作成する例示的なコードが、図5A内に示されている。

実行のために開始されるときに、マルチバージョンタスクは、マルチバージョンタスクが先行物依存性を有しないとき、および/または様々なスケジューリング最適化によって定義されるときなどに、マルチプロセッサコンピューティングデバイスによってスケジューリングに関して考慮され得る。いくつかの実施形態において、マルチバージョンタスクは、部分グラフを見つけるために様々なプロパティ(たとえば、処理ユニットタイプなど)によってタスクグラフを評価するスケジューリングポリシーに基づいてスケジューリングされ得る。たとえば、マルチバージョンタスクは、大きいタスクグラフ内でGPUに関するすべてのタスクの部分グラフを識別し、GPU上での実行のために部分グラフ全体を即座にディスパッチすることができる。そのようなディスパッチは、部分グラフ内のすべてのタスクの終了を示すために単一のGPUからCPUへのコールバックを含み、スケジューリングのためのCPUとGPUとの間のラウンドトリップの回数を減らすことができる。

ブロック404において、マルチプロセッサコンピューティングデバイスは、複数の処理ユニットのうちの適当な処理ユニットのタスクキュー内にマルチバージョンタスクの特殊化されたバージョンのそれぞれをエンキューすることができる。たとえば、CPU、GPU、およびDSPに関して使用可能な特殊化されたバージョンがある場合に、マルチプロセッサコンピューティングデバイスは、CPUのタスクキュー内にCPU特殊化されたバージョンを、GPUのタスクキュー内にGPU特殊化されたバージョンを、DSPのタスクキュー内にDSP特殊化されたバージョンをエンキューすることができる。マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクによってサポートされる処理ユニットのタスクキュー内に特殊化されたバージョンをエンキューすることだけができる。たとえば、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクのCPU特殊化されたバージョンおよびGPU特殊化されたバージョンだけがプログラマによって供給される場合に、GPUのタスクキューおよびCPUのタスクキュー内に特殊化されたバージョンをエンキューすることだけができ、サポートされない処理ユニット(たとえば、DSPなど)を無視することができる。

マルチプロセッサコンピューティングデバイスは、ブロック402で動作を継続することができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、図4B内のブロック404の動作を継続することができる。

いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、各適当なタスクキュー内に特殊化されたバージョンごとにタスクポインタ(または他の同様のデータ)をエンキューすることができる。マルチバージョンタスクの様々な特殊化されたバージョンのポインタの例示的なエンキューが、図5B内に示されている(たとえば、コードサブセクション526およびコードセクション528)。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、ポインタ内にタスク識別情報を符号化することができる。具体的には、ポインタは、それぞれ、マルチバージョンタスクならびに個々の特殊化されたバージョンを示すデータを含むことができる。ポインタ内のそのようなタスク情報は、異なるビットマスクを適用することによって個々の処理ユニットによってアクセスされ得る。たとえば、第1の処理ユニット(たとえば、GPU)は、関連するタスクキューからデキューされたポインタに親マスクを適用することによってマルチバージョンタスクを識別することができ、同一のポインタに第2のマスク(または代替マスク)を適用することによって特殊化されたバージョンを識別することができる。いくつかの実施形態において、特殊化されたバージョンを示すデータは、各ポインタの最下位4ビット内に含まれ得る。ポインタの例示的な符号化が、図5B内に示され(たとえば、コードサブセクション526)、タスク識別情報を取り出すための処理ユニットによるそのようなマスクの適用が、図7内に示されている(たとえば、コードセクション702)。

図4Bは、マルチバージョンタスクの実行を管理するためにマルチプロセッサコンピューティングデバイス(たとえば、図1〜図3C内のマルチプロセッサコンピューティングデバイス101)によって実行される方法405を示す。説明されるように、マルチバージョンタスクの特殊化されたバージョンがすべてのサポートされる処理ユニットに割り当てられた後に、関連するタスクキュー内にエンキューされた特殊化されたバージョンを即座に実行する準備ができるようになる、サポートされる処理ユニットのうちの第1の処理ユニットは、マルチバージョンタスクに対する所有権を入手することができる。そのような所有権獲得は、他のサポートされる処理ユニットが同一のマルチバージョンタスクの対応する特殊化されたバージョンを実行するのを防ぐことができる。たとえば、所有権を入手することができない処理ユニットのタスクキュー内の特殊化されたバージョンは、第1の処理ユニットが所有権を既に獲得しており、対応する特殊化されたバージョンを完了したとの判定に応答してなど、実行せずに単純に終了することができる。マルチバージョンタスクに対する所有権の獲得は、各マルチバージョンタスクが、適当な特殊化されたバージョンを実行する準備のできた最速の単一の処理ユニットによって実行されることを保証することができ、これによって、潜在的に不正確な先験的予測方式よりよい性能を提供する。

いくつかの実施形態において、方法405は、マルチプロセッサコンピューティングデバイス内でアクティブなマルチバージョンタスクごとに実行され得る。たとえば、マルチプロセッサコンピューティングデバイスは、1つまたは複数のマルチバージョンタスクの管理を処理するために方法405の1つまたは複数のインスタンス(たとえば、方法405を実行するための1つまたは複数のスレッド)を同時に実行することができる。いくつかの実施形態において、方法405の様々な動作は、図1〜図3Cのマルチプロセッサコンピューティングデバイス101のCPU102、GPU122、またはDSP132など、マルチプロセッサコンピューティングデバイスの処理ユニットを介して実行するランタイム機能性(たとえば、図3A〜図3Cの並列スケジューラモジュール311)によって実行され得る。様々な実施形態において、方法405は、図4Aを参照して説明された方法400と組み合わせて実行され得る。たとえば、ランタイム機能性は、様々な実施形態に従って複数の処理ユニットにまたがってマルチバージョンタスクを識別し、ディスパッチし、次いで管理するために、方法400と405との両方を実行するように構成され得る。

マルチバージョンタスクの特殊化されたバージョンが、複数の処理ユニットのタスクキューに分配された後しばらくしてから(たとえば、方法400のブロック404の実行の後に)、マルチプロセッサコンピューティングデバイスは、判定ブロック406において、マルチバージョンタスクの所有権の要求が要求する処理ユニットから受信されたかどうかを判定することができる。そのような要求は、コンピューティングデバイスの処理ユニットの間で共有され得る、プロセッサ間信号、割込み、レジスタ、および/または他のデータを介して送られ得る。たとえば、GPUは、GPUのタスクキュー内の特殊化されたバージョンに関連するマルチバージョンタスクに対する所有権を要求するのにAPI呼出しを使用することができる。処理ユニットによる例示的な要求呼出しまたは関数が、図7内に示されている(たとえば、コードセクション706内の「t->request_ownership()」)。

マルチバージョンタスクの所有権の要求が要求する処理ユニットから受信されたとの判定(すなわち、判定ブロック406=「Yes」)に応答して、マルチプロセッサコンピューティングデバイスは、判定ブロック412において、マルチバージョンタスクの所有権が別の処理ユニットに既に与えられたかどうかを判定することができる。たとえば、マルチプロセッサコンピューティングデバイスは、「所有権」変数、フラグ、および/または他のインジケータがセットされ、処理ユニットがその特定のマルチバージョンタスクに対する所有権を以前に獲得済みであることを示すかどうかを判定するために、マルチバージョンタスクに関連する記憶されたデータを評価することができる。

所有権が別の処理ユニットに既に与えられているとの判定(すなわち、判定ブロック412=「Yes」)に応答して、マルチプロセッサコンピューティングデバイスは、ブロック414において、マルチバージョンタスクに対する所有権の要求を送信した要求する処理ユニットに拒絶信号を送信することができる。そのような拒絶信号は、要求する処理ユニットに、マルチバージョンタスクのデキューされた特殊化されたバージョンを破棄させることができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスが、処理ユニットが所有権を与えられないことを示すために所有権の要求に応答することに単純に失敗することができるので、ブロック414の動作は、オプションとすることができる。

所有権が処理ユニットに既に与えられてはいないとの判定(すなわち、判定ブロック412=「No」)に応答して、要求する処理ユニットは、マルチバージョンタスクの対応する特殊化されたバージョンにアクセスする第1の処理ユニットになることができ、したがって、所有者として識別され得る。したがって、ブロック416において、マルチプロセッサコンピューティングデバイスは、肯定応答を送信することによるなど、要求する処理ユニットに要求されたマルチバージョンタスクの所有権信号を送信することができる。

ブロック418において、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクに関連するデータ構造、変数、および/またはレジスタ内に要求する処理ユニットのアイデンティティを表すデータを記憶することによるなど、要求する処理ユニットによる所有権を示すためにマルチバージョンタスクに関連する記憶されたデータを更新することができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクが現在は処理ユニットによって所有されることを単純に示す、マルチバージョンタスクのデータを記憶することができる。

ブロック420において、マルチプロセッサコンピューティングデバイスは、対応する特殊化されたバージョンの要求する処理ユニットの実行の後続の完了時に終了するか他の形で完了するようにマルチバージョンタスクを構成することができる。たとえば、要求する処理ユニットが対応する特殊化されたバージョンの実行を完了してしばらくすると、マルチプロセッサコンピューティングデバイスは、完了としてマルチバージョンタスクをマークすることができる。言い換えると、マルチプロセッサコンピューティングデバイスは、単一の特殊化されたバージョンが単一の処理ユニットによって実行されることに応答して、マルチバージョンタスクを「所有されている」としてセットし、破棄される(たとえば、実行されない)ようにすべての関連する特殊化されたバージョンをセットすることができる。

ブロック420の動作の実行に応答して、マルチプロセッサコンピューティングデバイスは、特殊化されたバージョンの完了を示し、かつ/または所有権を要求する、後に受信された信号を識別するためなど、判定ブロック406における判定動作に継続することができる。

いくつかの実施形態において、構成は、マルチバージョンタスクに遅延された終了を経験させるAPIコマンド「finish_after()」への呼出しを含むことができる。たとえば、マルチバージョンタスクに対する所有権の入手に応答して、要求する処理ユニットおよび/または別の処理ユニットもしくはマルチプロセッサコンピューティングデバイスの機能性は、所有権を獲得した要求する処理ユニットによって実行される特殊化されたバージョンの寿命に接続されるようにマルチバージョンタスクの寿命をセットするために、「finish_after()」コマンドを実行することができる。マルチバージョンタスクに対するすべてのタスク依存性、待機などは、特殊化されたバージョンの実行によって自動的に完了され得る。そのような「finish_after()」コマンドの例示的な使用が、図7内に示されている(たとえば、コードサブセクション708)。そのような「finish_after()」コマンドを実施する技法は、その内容全体が参照によって本明細書に組み込まれている、本願の譲受人が所有する、2015年1月26日に出願した本願の権利者が所有する米国特許出願第14/604,821号内で見出され得る。

マルチバージョンタスクの所有権の要求が処理ユニットから受信されなかったとの判定(すなわち、判定ブロック406=「No」)に応答して、マルチプロセッサコンピューティングデバイスは、判定ブロック402においてマルチバージョンタスクの所有権に関する後続の要求をリッスンし続けることができる。

いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、処理ユニットがマルチバージョンタスクに対する所有権を獲得した後に、マルチバージョンタスクの特殊化されたバージョンが完了済みであるかどうかを周期的に判定するように構成され得る。そのような判定は、マルチバージョンタスクに対する所有権を有する処理ユニットから受信される信号に基づき、マルチバージョンタスクに対する所有権を有する処理ユニットによって更新され得るビット、変数、レジスタ、もしくは他のデータの評価に基づき、および/または事前定義の時間期間の満了に基づくものとすることができる。たとえば、マルチプロセッサコンピューティングデバイスは、GPUがそれぞれの特殊化されたバージョンの実行を完了済みであることを示し、したがってマルチバージョンタスクも終了できることを示す、マルチバージョンタスクに対する所有権を既に獲得しているGPUからの着信信号をリッスンすることができる。この形において、様々な実施形態において、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクの特殊化されたバージョンの完了を検出する(またはそれについて通知される)ために周期的ポーリングおよび/またはイベント駆動機構を使用するように構成され得る。

いくつかの実施形態において、マルチバージョンタスクの特殊化されたバージョンが完了済みであるとの判定に応答して、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクを終了するための動作を実行することができる。たとえば、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクを終了する(たとえば、デキューする、無効化するなど)ことができる。

いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、マルチバージョンタスクの特殊化されたバージョンの識別された(たとえば、検出されたまたは通知された)完了に応答して、終了されたマルチバージョンタスクの関連する特殊化されたバージョンを終了する動作を実行することもできる。たとえば、GPUがGPU特殊化されたバージョンを完了したとの判定に応答して、CPUおよびDSPの特殊化されたバージョンは、実行せずに完了または終了するようにセットされ得る。マルチバージョンタスクの関連する特殊化されたバージョン(たとえば、実行されないそれらの特殊化されたバージョン)を終了するためにマルチプロセッサコンピューティングデバイスによって実行され得る動作の他の例は、特殊化されたバージョンに、タスクグループから去らせることおよび/または関連する実行されない特殊化されたバージョンに割り振られたメモリを解放することを含むことができる。いくつかの実施形態において、マルチプロセッサコンピューティングデバイスは、信号もしくは割込みを送信し、レジスタをセットし、かつ/またはマルチバージョンタスクの他の特殊化されたバージョンが実行されてはならないことを様々な処理ユニットに能動的に指示する他の動作を実行し、これによって、すべての実行されないが、まだエンキューされている特殊化されたバージョンを無効にすることができる。次いで、マルチバージョンタスクが1つのみの特殊化されたバージョンの実行を介して処理され終えたので、方法405は終了することができる。

図5A〜図5Bは、様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを作成し、タスクキューにディスパッチするためにマルチプロセッサコンピューティングデバイス(たとえば、コンピューティングデバイス101)によって実行され得る命令を表す非限定的な例示的な擬似コード500、520を示す。いくつかの実施形態において、擬似コード500、520は、マルチプロセッサコンピューティングデバイス上で実行するランタイムスケジューラ機能性(たとえば、サービス、スレッド、アプリケーションなど)によって実行される動作を表すことができる。いくつかの実施形態において、擬似コード500は、様々なメイン実施態様(たとえば、versions[0]、…versions[n])のために使用され得、したがって、実施形態および/または特許請求の範囲を限定することは意図されていない。

図5Aを参照すると、擬似コード500は、それぞれマルチプロセッサコンピューティングデバイスの特定の処理ユニット上で実行されるように設計された1つまたは複数の特殊化されたバージョンを有する新しいマルチバージョンタスクを作成するために処理ユニット(たとえば、CPU102、アプリケーションプロセッサなど)によって実行され得る命令の非限定的な例を表す。具体的には、擬似コード500は、作成されるマルチバージョンタスクに関してサポートされる特殊化されたバージョンを指示するタプルを含む、様々な引数と共に呼び出され得る関数(すなわち、「create_task」関数)を表すことができる。たとえば、タプルは、GPU特殊化されたバージョン、DSP特殊化されたバージョン、およびCPU特殊化されたバージョンが作成されなければならないことを示すことができる。いくつかの実施形態において、特殊化されたバージョンが関数のタプル引数内で指示される順序は、相対プリファレンスまたは相対優先順位を指示することができる。

擬似コード500は、第1のコードセクション502内の命令によってそれ自体が呼び出され得る再帰関数を含む第1のコードセクション502を含むことができる。たとえば、「create_task」関数を使用してタスクを作成する第1のコードサブセクション504が、含まれ得る。第1のコードサブセクション504が特定のタスクに関して初めて実行されるときに、「メイン」マルチバージョンタスクが作成され得る。第2のコードサブセクション506(たとえば、「for」ループ)は、メインマルチバージョンタスクに関してリンクされ(またはこれによって参照され)得る特殊化されたバージョン(または「代替物」)を作成するために実行され得る。たとえば、特殊化されたバージョン(または「代替物」)ごとのポインタデータが、メインマルチバージョンタスクに関連して記憶され得る。

いくつかの実施形態において、タスク作成は、プログラマ(たとえば、タスクを作成するためにコード内に関数呼出しまたはAPI呼出しを挿入するなど)および/またはコンパイラもしくはランタイムシステムに基づいて開始されまたは他の形で実行され得る。

図5Bを参照すると、擬似コード520は、デバイスの処理ユニット(たとえば、CPU102、CPU112、GPU122、DSP132など)のタスクキューに、マルチバージョンまたは他の様々なタスクをスケジューリングする(またはディスパッチする)ために、処理ユニット(たとえば、CPU102、アプリケーションプロセッサなど)によって周期的に実行される1つまたは複数の方法、関数、ルーチン、または他の論理の命令の非限定的な例を表す。擬似コード520内の特定の処理ユニット(たとえば、big.Littleコア、GPUなど)への参照は、例示のためのものであり、したがって、実施形態または特許請求の範囲を任意の特定の処理ユニットに限定することは意図されていない。

擬似コード520は、タスクをスケジューリングするための第1のコードセクション522を含むことができる。第1のコードセクション522は、タスクが代替物を有しない(すなわち、タスクがマルチバージョンタスクではない)との判定に応答して実行され得る第1のコードサブセクション524(たとえば、「if」ブロック)を含むことができ、タスクは、処理ユニットのタスクキュー内に単純にエンキューされる。

第2のコードサブセクション526(たとえば、「else」ブロック)は、識別されたタスクが代替物を有する(すなわち、タスクがマルチバージョンタスクである)との判定に応答して実行され得、コンピューティングデバイスの様々な処理ユニットのタスクキューのうちの1つ内のマルチバージョンタスクの特殊化されたバージョン(または「代替物」)の各々のポインタをエンキューするための動作を含むことができる。そのようなポインタは、ポインタの最下位4ビットなど、未使用ビット内で符号化される識別子を有することができる。たとえば、第2のコードサブセクション526は、適当なタスクキューにN個のタスクポインタをプッシュするために実行され得、Nは、所与のマルチバージョンタスクの特殊化されたバージョン(または実施態様)の個数とすることができ、個々の代替物番号は、各タスクポインタ内に符号化される。第2のコードセクション528は、タスクポインタにマスク(またはビットマスク)を適用することによって生成される識別子に基づいて処理ユニットの適当なタスクキュー内にタスクをエンキューするための動作を含むことができる。タスクがデキューされるまでタスクの代替物符号化を保持するコードセクション528内の様々な「push(task)」動作が、実行され得る。

図6は、様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイス(たとえば、図1〜図3Cのマルチプロセッサコンピューティングデバイス101)の処理ユニット(たとえば、図1〜図3Cの処理ユニット102、112、122、132)によって実行される方法600を示す。様々な実施形態において、マルチプロセッサコンピューティングデバイスの処理ユニットの各々は、本明細書で説明されるようにマルチバージョンタスクの特殊化されたバージョンを処理するために方法600を継続的に実行するように構成され得る。たとえば、第1のCPU(たとえば、図1〜図3Cの処理ユニット102)、第2のCPU(たとえば、図1〜図3Cの処理ユニット112)、GPU(たとえば、図1〜図3Cの処理ユニット122)、およびDSP(たとえば、図1〜図3Cの処理ユニット132)は、すべて、マルチバージョンタスクに対する所有権を獲得し、関連する特殊化されたバージョンを実行するために、方法600の独立のインスタンスを独立に同時に実行するように構成され得る。方法600の様々な動作は、処理ユニットを制御し、他の形で動作させるように構成された様々なソフトウェア、スレッド、ルーチン、命令、および/または他の機能性を介して実行され得る。たとえば、スレッド(たとえば、タスクキューに関連するスレッドプール内のDSPスレッド)は、タスクキューからタスクポインタをデキューするために方法600を実行し、適当なときにマルチバージョンタスクの所有権を獲得する動作を実行することができる。

ブロック602において、処理ユニットは、処理ユニットによって実行される次のタスクをデキューすることができる。いくつかの実施形態において、次のタスクのデキューは、タスクキューからポインタを除去することを含むことができる。判定ブロック604において、処理ユニットは、デキューされたタスクがマルチバージョンタスクの特殊化されたバージョンであるかどうかを判定することができる。たとえば、処理ユニットは、識別子を入手するためにポインタに様々なビットマスクを適用することができ、識別子がマルチバージョンタスクの任意の特殊化されたバージョン(または「代替物番号」)に対応するかどうかを判定することができる。判定を実行するための例示的な動作が、図7内に示されている(たとえば、コードセクション702、コードセクション704内のコマンド「t->has_alternatives」)。

いくつかの実施形態において、処理ユニットは、デキューされたタスクの識別子を、デキューされたタスクがマルチバージョンタスクまたは単に1つのバージョンだけを有する通常のタスクのどちらであるのかを指示する記憶されたデータと比較するために、テーブルまたは他のデータ構造内のルックアップを実行することができる。そのような実施態様は、特殊化されたバージョンを識別するために、タスクキュー内に配置された個々のポインタにビットマスクが適用されることを必要としない可能性がある。以下は、そのような実施態様の例示である。処理ユニットは、第1の処理ユニットのタスクキューからポインタを取り出す(またはデキューする)ことができ、ポインタは、マルチバージョンタスクのサポートされる特殊化されたバージョンを有する処理ユニットごとにタスクキュー内に配置された共通のマルチバージョンタスクポインタとすることができる。取り出された後に、処理ユニットは、ポインタがマルチバージョンタスクの特殊化されたバージョンのリストに関連するかどうかを判定する(すなわち、ポインタに関連する代替物があるかどうかを判定する)ことができる。ポインタに関連する特殊化されたバージョンのリストがある場合に、マルチプロセッサコンピューティングデバイスは、次いで、処理ユニットに対応する特殊化されたバージョンのリストからマルチバージョンタスクの特殊化されたバージョンを識別することができる。たとえば、処理ユニットがGPUである場合に、処理ユニットは、リスト内のGPU特殊化されたバージョンを識別することができる。対応する特殊化されたバージョンがリスト内で識別される場合に、処理ユニットは、次いで、マルチバージョンタスクに対する所有権の入手に進み、対応する特殊化されたバージョンを実行することができる。

デキューされたタスクがマルチバージョンタスクの特殊化されたバージョンではないとの判定(すなわち、判定ブロック604=「No」)に応答して、処理ユニットは、ブロック612において、デキューされたタスクを実行することができる。いくつかの実施形態において、処理ユニットは、オプションのブロック614において、デキューされたタスクの完了を示す信号を送信するように構成され得る。いくつかの実施形態において、デキューされたタスクの完了は、その代わりに、デキューされたタスクが完全に実行されたことをマルチプロセッサコンピューティングデバイス(および/または様々な処理ユニット)に指示するために変数、フラグ、ビット、または他の記憶されたデータをセットすることによって指示され得る。

デキューされたタスクが、マルチバージョンタスクの特殊化されたバージョンであるとの判定(すなわち、判定ブロック604=「Yes」)に応答して、処理ユニットは、オプションの判定ブロック606において、別の処理ユニットによってマルチバージョンタスクが既に所有されており、かつ/または完了されている(したがって、マルチバージョンタスク全体が完了されている)かどうかを判定する。言い換えると、処理ユニットは、対応するタスクキューからの特殊化されたバージョンがまだ有効であり、所有権が獲得され得る場合に処理ユニットによって実行されなければならないかどうかを判定することができる。マルチバージョンタスクの所有権が、処理ユニットによって獲得され得ない場合には、マルチバージョンタスクは、別の処理ユニットによって完了され終えているか、完了されつつあり、したがって処理ユニットは、そのタスクを単純に破棄し、他のタスクの処理に継続することができる。処理ユニットは、マルチバージョンタスクの状況を示すビット、変数、レジスタ、および/もしくは他の記憶された情報を評価すること、ランタイム機能性に更新要求を送信すること、ならびに/またはデキューされた特殊化されたバージョンに関連して記憶された情報が完了された状況を示すかどうかを評価することなどによって、様々な形においてマルチバージョンタスクが完了されたかどうかを判定することができる。

マルチバージョンタスクが既に所有され、かつ/または完了されているとの判定(すなわち、オプションの判定ブロック606=「Yes」)に応答して、処理ユニットは、ブロック607において、未実行のデキューされたタスク(処理ユニットに割り当てられた特殊化されたバージョンを表す)のデータを破棄し、ブロック602におけるデキュー動作に戻る。

マルチバージョンタスクの他の特殊化されたバージョンが別の処理ユニットによって完了されていないとの判定(すなわち、オプションの判定ブロック606=「No」)に応答して、マルチバージョンタスクは、まだ所有されておらず、したがって、処理ユニットは、それでも、対応する特殊化されたバージョンを実行できる可能性がある。したがって、ブロック608において、処理ユニットは、マルチバージョンタスクをスケジューリングし、かつ/または管理するように構成されたランタイム機能性に要求信号を送信することによるなど、マルチバージョンタスクの所有権を要求することができる。所有権を要求するための例示的な呼出しが、図7内に示されている(たとえば、コードセクション706)。

判定ブロック610において、処理ユニットは、マルチバージョンタスクの所有権が処理ユニットによって獲得されたかどうかを判定することができる。たとえば、処理ユニットは、マルチバージョンタスクをスケジューリングし、管理するように構成されたランタイム機能性からの応答が、処理ユニットにマルチバージョンタスクの所有権を与えたかどうかを判定するために、着信メッセージバッファならびに/または記憶されたビット、変数、レジスタ、および/もしくは他の情報を継続的に監視することができる。

所有権が処理ユニットによって獲得されていないとの判定(すなわち、判定ブロック610=「No」)に応答して、マルチバージョンタスク(したがって、処理ユニットに割り当てられたが処理ユニットによって実行されない特殊化されたバージョン)は、別の処理ユニットによって所有されると考えられ得、したがって、プロセッサは、ブロック607において、未実行のデキューされたタスクのデータを破棄することができる。たとえば、処理ユニットは、マルチバージョンタスクの特殊化されたバージョンのタスクポインタを破棄することができる。次いで、処理ユニットは、ブロック602におけるデキュー動作に継続することができる。

所有権が処理ユニットによって獲得されたとの判定(すなわち、判定ブロック610=「Yes」)に応答して、処理ユニットは、ブロック611において、マルチバージョンタスクの他の特殊化されたバージョンがデキューされたときにディスエーブルされなければならないことを示す信号を送信することができる。たとえば、他の特殊化されたバージョンをディスエーブルするために処理ユニットの特殊化されたバージョンの完了まで待つ必要がないので、この信号は、他の処理ユニットに、エンキューされた他の特殊化されたバージョンをディスエーブルさせ、かつ/またはマルチバージョンタスクの他の特殊化されたバージョンのデキューされたタスクポインタデータを破棄させることができる。

いくつかの実施形態では、処理ユニットは、マルチバージョンタスクに遅延された終了を経験させるAPIコマンド「finish_after()」への呼出しを実行することができる(たとえば、マルチバージョンタスクは、処理ユニットがデキューされたタスクを完全に実行するまで完了することができない)。たとえば、処理ユニットは、デキューされたタスクの寿命に接続されるようにマルチバージョンタスクの寿命をセットし、したがって、ランタイム機能性にマルチバージョンタスク(およびそのマルチバージョンタスクに関連するすべての他の特殊化されたバージョン)を終了させるために、「finish_after()」コマンドを実行することができる。そのような「finish_after()」コマンドの例示的な使用が、図7内に示されている(たとえば、コードサブセクション708)。

処理ユニットは、ブロック612においてデキューされたタスク(すなわち、マルチバージョンタスクの特殊化されたバージョン)を実行することと、オプションの動作ブロック614においてデキューされたタスクが完了されたことを示す信号を送信することとによって継続し、ブロック602におけるデキュー動作に継続することができる。

図7は、様々な実施形態によるマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイス(たとえば、図1〜図3Cのマルチプロセッサコンピューティングデバイス101)の処理ユニットによって実行され得る命令を表す例示的な擬似コード700を示す。たとえば、擬似コード700は、マルチバージョンまたは他の形の様々なタスクを処理するために処理ユニット(たとえば、CPU102、CPU112、GPU122、DSP132など)によって周期的に実行される1つまたは複数のメソッド、関数、ルーチン、または他の論理の命令を表すことができる。

非限定的な例示として、擬似コード700は、処理ユニットのタスクキューからポインタをデキューするための第1のコードセクション702を含むことができ、マスク(たとえば、ビットマスク)が、タスク(たとえば、マルチバージョンタスクアイデンティティ)およびタスクの他の識別(たとえば、マルチバージョンタスクの代替物番号またはバージョン番号)を識別するためにポインタに適用され得る。第2のコードセクション704(たとえば、「if」ブロック)は、識別されたタスクが代替物を有しない(すなわち、タスクがマルチバージョンタスクではない)ことの判定に応答して実行され得る。第3のコードセクション706(たとえば、「else」ブロック)は、識別されたタスクが代替物を有する(すなわち、タスクがマルチバージョンタスクである)ことの判定に応答して実行され得、マルチバージョンタスクに対する所有権を要求し/獲得するための動作を含むことができる。第3のコードセクション706は、マルチバージョンタスクの所有権が処理ユニットによって獲得されたとの判定に応答して処理ユニットによって実行され得る第1のコードサブセクション708(たとえば、「if」ブロック)を含むことができる。第1のコードサブセクション708は、バージョンの完了時に終了する(または終わる)ようにマルチバージョンタスクを構成するための動作ならびにバージョンを実行するための動作を含むことができる。第3のコードセクション706は、空であり得、マルチバージョンタスクの所有権が処理ユニットによって獲得されなかったとの判定に応答して処理ユニットによって実行される動作を他の形では含み得ない第2のコードサブセクション710(たとえば、「else」ブロック)を含むこともできる。たとえば、所有権が、マルチバージョンタスクの特殊化されたバージョンに関して獲得され得ないときに、処理ユニットは、特殊化されたバージョンを実行するのではなく、その代わりに、特殊化されたバージョンのデータを破棄し、タスクキュー内の他のタスクの処理に進むことができる。

図8は、優先順位タスクおよびマルチバージョンタスクの特殊化されたバージョンを実行するためにマルチプロセッサコンピューティングデバイスの処理ユニットによって実行される方法800を示す。方法800は、方法800が、優先順位タスクを識別し、処理するための追加の動作を含み得ることを除いて、図6の方法600に類似するものとすることができる。説明されるように、そのような優先順位タスクは、処理ユニットに独自に適する可能性があり、したがって、マルチバージョンタスクの並列処理に参加するリソースを消費する前に処理ユニットによって実行されなければならない。たとえば、代替的にDSPまたはCPUにおいて実行され得る他のバージョンを有する共通のマルチバージョンタスクのGPUバージョンを実行するのではなく、GPU処理ユニットは、マルチバージョンタスクに対する所有権を獲得する動作を実行し、GPUバージョンを実行する前に、レンダリングタスクを実行することができる。この形において、処理ユニットは、処理ユニットのネイティブアクティビティを弱体化させることなく、並列処理ポリシーに参加することができる。

ブロック602〜ブロック614の動作は、図6を参照して説明した同様の符号のブロックの動作に類似するものとすることができる。デキューされたタスクが、マルチバージョンタスクの特殊化されたバージョンであるとの判定(すなわち、判定ブロック604=「Yes」)と、マルチバージョンタスクが別の処理ユニットによって既に所有されておらず、かつ/または完了されていないとの判定(すなわち、オプションの判定ブロック606=「No」)とに応答して、処理ユニットは、判定ブロック802において、タスクキュー内に1つまたは複数の優先順位タスクがあるかどうかを判定することができる。たとえば、処理ユニットは、いずれかが処理ユニットの優先順位として事前に定義されたコード、機能、および/またはアクティビティに対応するかどうかを判定するために、タスクキュー内に現在エンキューされている他のタスクのタイプおよび機能を分析することができる。別の例として、GPU処理ユニットは、ディスプレイおよび/またはレンダリング関連タスクが現在エンキューされているかどうかを判定することができる。いくつかの実施形態において、優先順位タスク、マルチバージョンタスク、および通常のタスクは、すべて、同一の優先順位キュー内にあるものとすることができる。いくつかの実施形態において、優先順位タスクは、マルチバージョンタスクおよび他のタスクとは異なるキュー内にあるものとすることができ、処理ユニットは、非優先順位キュー内のタスクを処理する前に優先順位キュー内のタスクを処理するように構成され得る。

タスクキュー内に優先順位タスクがないとの判定(すなわち、判定ブロック802=「No」)に応答して、処理ユニットは、ブロック608において、デキューされた特殊化されたバージョンに関連するマルチバージョンタスクに対する所有権を要求することができる。

タスクキュー内の少なくとも1つの優先順位タスクがあるとの判定(すなわち、判定ブロック802=「Yes」)に応答して、処理ユニットは、優先順位タスクを先に処理するためにマルチバージョンタスクのデキューされた特殊化されたバージョンを延期することができる。ブロック804において、処理ユニットは、1つまたは複数の優先順位タスクをデキューし、実行することができる。いくつかの実施形態において、処理ユニットは、一時に1つまたは代替的にバッチで優先順位タスクを実行することができる。ブロック806において、処理ユニットは、マルチバージョンタスクの特殊化されたバージョンをタスクキューに戻ってプッシュすることができる。いくつかの実施形態において、優先順位タスクを取り出すためにデキューされた他のタスクも、順番にタスクキューに戻ってプッシュされる必要がある。マルチプロセッサコンピューティングデバイスは、ブロック602において、処理ユニットによって実行される次のタスクをデキューすることができる。

いくつかの実施形態において、ブロック804〜ブロック806の動作は、処理ユニットが、特定の実行順序を要求する可能性がある依存性または制約がないと判定することに応答してのみ実行され得る。たとえば、処理ユニットは、優先順位タスクが、マルチバージョンタスクおよび/または優先順位タスクの前にあるキュー内の他のタスクに依存しないとの判定に応答してのみ、マルチバージョンタスクの特殊化されたバージョンの前に優先順位タスクをデキューし、実行することができる。

パーソナルコンピュータ、モバイルデバイス、およびラップトップコンピュータを含む様々な形のマルチプロセッサコンピューティングデバイスが、様々な実施形態を実施するのに使用され得る。そのようなコンピューティングデバイスは、通常、例のマルチプロセッサコンピューティングデバイス900を示す図9内に示された構成要素を含むことができる。様々な実施形態において、モバイルデバイス900は、タッチスクリーンコントローラ904および内部メモリ902に結合されたプロセッサ901を含むことができる。プロセッサ901は、汎用または特定の処理タスクのために設計された複数のマルチコアICを含むことができる。いくつかの実施形態において、他の処理ユニットも、含まれ、プロセッサ901(たとえば、GPU、DSPなど)に結合され得る。

内部メモリ902は、揮発性および/または不揮発性メモリとされ得、セキュアおよび/もしくは暗号化されたメモリ、またはアンセキュアおよび/もしくは暗号化されないメモリ、またはその組合せともされ得る。タッチスクリーンコントローラ904およびプロセッサ901は、抵抗感知型タッチスクリーン、容量性タッチスクリーン、赤外線感知タッチスクリーン、その他などのタッチスクリーンパネル912にも結合され得る。モバイルデバイス900は、互いに結合され、かつ/またはプロセッサ901に結合された、送受信のための、1つまたは複数の無線信号トランシーバ908(たとえば、Bluetooth(登録商標)、ZigBee(登録商標)、Wi-Fi(登録商標)、RF無線)、およびアンテナ910を有することができる。トランシーバ908およびアンテナ910は、様々なワイヤレス伝送プロトコルスタックおよびインターフェースを実施するために、上述した回路内で使用されてもよい。モバイルデバイス900は、セルラーネットワークを介する通信を使用可能にされ、プロセッサ901に結合されたセルラーネットワークワイヤレスモデムチップ916を含むことができる。モバイルデバイス900は、プロセッサ901に結合された周辺デバイス接続インターフェース918を含むことができる。周辺デバイス接続インターフェース918は、1つのタイプの接続を受け入れるように単一に構成され、または、USB、FireWire、Thunderbolt、もしくはPCIeなどの共通のもしくはプロプライエタリな様々なタイプの物理接続および通信接続を受け入れるように多重に構成され得る。周辺デバイス接続インターフェース918は、同様に構成された周辺デバイス接続ポート(図示せず)に結合されてもよい。また、モバイルデバイス900は、音声出力を提供するためのスピーカー914を含むことも可能である。モバイルデバイス900は、本明細書で説明される構成要素のすべてまたは一部を含むための、プラスティック、金属、または材料の組合せから構成されたハウジング920をも含むことができる。モバイルデバイス900は、使い捨てまたは充電可能なバッテリなどの、プロセッサ901に結合された電源922を含むことができる。充電可能なバッテリは、モバイルデバイス900の外部のソースから充電電流を受け取るために周辺デバイス接続ポートにも結合され得る。

本明細書で説明される様々なプロセッサ(または処理ユニット)は、本明細書で説明される様々な実施形態の機能を含む様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る任意のプログラム可能マイクロプロセッサ、マイクロプロセッサ、または複数のプロセッサチップとすることができる。様々なデバイスにおいて、ワイヤレス通信機能専用の1つのプロセッサおよび他のアプリケーションを実行するため専用の1つのプロセッサなどの、複数のプロセッサが設けられてもよい。通常、ソフトウェアアプリケーションは、それらがアクセスされ、プロセッサにロードされる前に、内部メモリ内に記憶され得る。プロセッサは、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含むことができる。多くのデバイスにおいて、内部メモリは、揮発性メモリもしくはフラッシュメモリなどの不揮発性メモリ、またはその両方の混合とされ得る。この説明の目的において、メモリへの全般的な参照は、様々なデバイスに接続される内部メモリもしくはリムーバブルメモリおよびプロセッサ内のメモリを含む、プロセッサによってアクセス可能なメモリを指す。

前述の方法の説明およびプロセス流れ図は、単に例示的な例として提供され、様々な実施形態の動作が提示された順序で実行されなければならないことを要求しまたは暗示することは意図されていない。当業者によって了解されるように、前述の実施形態の動作の順序は、任意の順序で実行され得る。「その後」、「次いで」、「次に」などの単語は、動作の順序を限定するものではなく、これらの単語は単に、方法の説明を通じて読者を導くために使用される。さらに、たとえば、冠詞「a」、「an」、または「the」を使用する単数形でのクレーム要素へのいかなる参照も、要素を単数形に限定するものとして解釈すべきではない。

本明細書で開示される実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズム動作は、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実施され得る。ハードウェアとソフトウェアとのこの交換可能性を明瞭に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、および動作は、上で、全般的にその機能性に関して説明された。そのような機能性がハードウェアまたはソフトウェアのどちらで実施されるのかは、特定の応用例と、システム全体に課せられる設計制約とに依存する。当業者は、特定の応用例ごとに様々な形で説明された機能性を実施することができるが、そのような実施判断が、本特許請求の範囲の範囲からの逸脱を引き起こすと解釈してはならない。

本明細書で開示される実施形態に関連して説明された様々な例示的な論理、論理ブロック、モジュール、および回路を実施するのに使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくはたのプログラム可能論理デバイス、ディスクリートゲート論理もしくはトランジスタ論理、ディスクリートハードウェア構成要素、または本明細書で説明される機能を実行するように設計されたその任意の組合せを用いて実施されまたは実行され得る。汎用プロセッサは、マイクロプロセッサとされ得るが、代替案では、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とされ得る。プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアに関連する1つまたは複数のマイクロプロセッサ、または任意の他のそのような構成としても実施され得る。代替的に、いくつかの動作または方法が、所与の機能に固有の回路網によって実行され得る。

1つまたは複数の例示的実施形態において、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはその任意の組合せにおいて実施され得る。ソフトウェアにおいて実施される場合に、機能は、非一時的プロセッサ可読媒体、コンピュータ可読媒体またはサーバ可読媒体もしくは非一時的プロセッサ可読記憶媒体上の1つまたは複数の命令またはコードとして記憶されまたは送信され得る。本明細書で開示される方法またはアルゴリズムの動作は、非一時的コンピュータ可読記憶媒体、非一時的サーバ可読記憶媒体、および/または非一時的プロセッサ可読記憶媒体上に存在し得る、プロセッサ実行可能ソフトウェアモジュールまたはプロセッサ実行可能ソフトウェア命令において具現化され得る。様々な実施形態において、そのような命令は、記憶されたプロセッサ実行可能命令または記憶されたプロセッサ実行可能ソフトウェア命令であり得る。有形の非一時的コンピュータ可読記憶媒体は、コンピュータによってアクセスされ得る任意の使用可能な媒体とされ得る。限定ではなく例として、そのような非一時的コンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク(disc)ストレージ、磁気ディスク(disk)ストレージもしくは他の磁気データストレージデバイス、または命令の形の所望のプログラムコードもしくはデータ構造を記憶するのに使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含むことができる。ディスク(disk)およびディスク(disc)は、本明細書で使用されるときに、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピディスク(disk)、およびブルーレイディスク(disc)(登録商標)を含み、ディスク(disk)は、通常はデータを磁気的に再生し、ディスク(disc)はレーザを用いてデータを光学的に再生する。上記の組合せも、非一時的コンピュータ可読媒体の範囲内に含まれなければならない。さらに、方法またはアルゴリズムの動作は、有形の非一時的プロセッサ可読記憶媒体および/またはコンピュータ可読媒体上のコードおよび/または命令のうちの1つまたは任意の組合せまたはセットとして存在することができ、これは、コンピュータプログラム製品内に組み込まれ得る。

開示される実施形態の先行する説明は、当業者が特許請求の範囲の実施形態技法を作りまたは使用することを可能にするために提供される。これらの実施形態に対する様々な変更は、当業者にたやすく明白になり、本明細書で開示される包括的な原理は、特許請求の範囲の範囲から逸脱することなく他の実施形態に適用され得る。したがって、本開示は、本明細書において示される実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書において開示された原理および新規の特徴に一致する最大の範囲を与えられるものである。

100 図
101 マルチプロセッサコンピューティングデバイス
102 第1のCPU、CPU_A
112 第2のCPU、CPU_B
122 GPU
132 DSP
150 メインスレッド
166 タスクキュー
168 タスクキュー
170 タスクキュー
172 タスクキュー
174 タスクキュー
176 タスクキュー
178 タスクキュー
180 タスクキュー
200 図
201 マルチバージョンタスク
202a 第1の特殊化されたバージョン
202b 第2の特殊化されたバージョン
202c 第3の特殊化されたバージョン
202d 第4の特殊化されたバージョン
210 負荷ベースのスケジューラモジュール
220a 第1のタスクキュー
220b 第2のタスクキュー
220c 第3のタスクキュー
220d 第4のタスクキュー
230a タスク
230b タスク
230c タスク
230d タスク
250 図
301 マルチバージョンタスク
302a 第1の特殊化されたバージョン
302b 第2の特殊化されたバージョン
302c 第3の特殊化されたバージョン
302d 第4の特殊化されたバージョン
310 所有権データ
311 並列スケジューラモジュール
312 完了データ
350 図
352 信号、シグナリング
354 動作
375 図
376 信号
378 動作
380 信号
400 方法
405 方法
500 擬似コード
502 第1のコードセクション
504 第1のコードサブセクション
506 第2のコードサブセクション
520 擬似コード
522 第1のコードセクション
524 第1のコードサブセクション
526 第2のコードサブセクション
528 第2のコードセクション
600 方法
700 擬似コード
702 第1のコードセクション
704 第2のコードセクション
706 第3のコードセクション
708 第1のコードサブセクション
710 第2のコードサブセクション
800 方法
900 マルチプロセッサコンピューティングデバイス、モバイルデバイス
901 プロセッサ
902 内部メモリ
904 タッチスクリーンコントローラ
908 無線信号トランシーバ
910 アンテナ
912 タッチスクリーンパネル
914 スピーカー
916 セルラーネットワークワイヤレスモデムチップ
918 周辺デバイス接続インターフェース
920 ハウジング
922 電源

Claims (30)

1. 複数の処理ユニット上でマルチバージョンタスクをスケジューリングするマルチプロセッサコンピューティングデバイスのための方法であって、
   前記複数の処理ユニットのプロセッサを介して、前記複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューするステップであって、各特殊化されたバージョンは、前記複数の処理ユニットの異なる処理ユニットによって実行されるように構成される、エンキューするステップと、
   前記プロセッサを介して、前記複数の処理ユニットの第1の処理ユニットに前記マルチバージョンタスクに対する所有権を提供するステップであって、前記第1の処理ユニットは、前記複数の処理ユニットの他の処理ユニットが前記マルチバージョンタスクの他の特殊化されたバージョンを実行するのに使用可能になる前に、前記マルチバージョンタスクの第1の特殊化されたバージョンを即座に実行するのに使用可能である、提供するステップと、
   前記プロセッサを介して、前記第1の処理ユニットに前記マルチバージョンタスクに対する前記所有権を提供することに応答して、前記マルチバージョンタスクの前記他の特殊化されたバージョンを破棄するステップと
   を含む方法。
2. 前記マルチプロセッサコンピューティングデバイスは、前記複数の処理ユニットをスケジューリングするように構成されたランタイム機能性を実行している、請求項1に記載の方法。
3. 前記プロセッサを介して、前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンをエンキューするステップは、
   前記プロセッサを介して、前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンに関連するポインタをエンキューするステップ
   を含む、請求項1に記載の方法。
4. 各ポインタは、前記マルチバージョンタスクおよび前記マルチバージョンタスクの前記特殊化されたバージョンの識別を含む、請求項3に記載の方法。
5. 前記マルチバージョンタスクの前記特殊化されたバージョンの前記識別は、各ポインタの最下位4ビット内に含まれる、請求項4に記載の方法。
6. 前記プロセッサを介して、前記複数の処理ユニットの前記第1の処理ユニットに前記マルチバージョンタスクに対する前記所有権を提供するステップは、前記マルチバージョンタスクに関連するデータを記憶するステップを含む、請求項1に記載の方法。
7. 前記プロセッサを介して、前記第1の処理ユニットの前記タスクキューからの次のタスクが前記マルチバージョンタスクに関連するかどうかを判定するステップと、
   前記プロセッサを介して、前記次のタスクが前記マルチバージョンタスクに関連するとの判定に応答して、前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求するステップと
   をさらに含む、請求項1に記載の方法。
8. 前記プロセッサを介して、前記所有権の要求に応答して前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を獲得するステップと、
   前記第1の処理ユニットを介して、前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権の獲得に応答して前記次のタスクを実行するステップと
   をさらに含む、請求項7に記載の方法。
9. 前記プロセッサを介して、前記第1の処理ユニットの前記タスクキューからの前記次のタスクが前記マルチバージョンタスクに関連するかどうかを判定するステップは、
   前記プロセッサを介して、前記第1の処理ユニットの前記タスクキューからのポインタにビットマスクを適用することによって識別子を入手するステップと、
   前記プロセッサを介して、前記識別子が前記マルチバージョンタスクの前記第1の特殊化されたバージョンに対応するとの判定に応答して、前記次のタスクが前記マルチバージョンタスクに関連すると判定するステップと
   を含む、請求項7に記載の方法。
10. 前記プロセッサを介して、前記第1の処理ユニットの前記タスクキューからの前記次のタスクが前記マルチバージョンタスクに関連するかどうかを判定するステップは、
    前記プロセッサを介して、前記第1の処理ユニットの前記タスクキューからポインタを取り出すステップであって、前記ポインタは、前記複数の処理ユニットの各々の前記タスクキュー内に配置された共通のマルチバージョンタスクポインタである、取り出すステップと、
    前記プロセッサを介して、前記ポインタが前記マルチバージョンタスクの特殊化されたバージョンのリストに関連するかどうかを判定するステップと、
    前記プロセッサを介して、前記ポインタが前記マルチバージョンタスクの特殊化されたバージョンの前記リストに関連するとの判定に応答して、前記マルチバージョンタスクの特殊化されたバージョンの前記リストから前記マルチバージョンタスクの前記第1の特殊化されたバージョンを識別するステップであって、前記第1の特殊化されたバージョンは、前記第1の処理ユニットによって実行される前記次のタスクである、識別するステップと
    を含む、請求項7に記載の方法。
11. 前記第1の処理ユニットを介して、前記次のタスクが前記マルチバージョンタスクに関連しないとの判定に応答して前記次のタスクを実行するステップ
    をさらに含む、請求項7に記載の方法。
12. 前記プロセッサを介して、前記第1の処理ユニットに関する前記所有権の要求に応答して、前記マルチバージョンタスクに対する前記所有権が第2の処理ユニットによって獲得されたと判定するステップと、
    前記プロセッサを介して、前記マルチバージョンタスクに対する前記所有権が前記第2の処理ユニットによって獲得されたとの判定に応答して前記次のタスクを破棄するステップと
    をさらに含む、請求項7に記載の方法。
13. 前記プロセッサを介して、前記第1の処理ユニットに関連する前記タスクキュー内に優先順位タスクがあるかどうかを判定するステップと、
    前記第1の処理ユニットを介して、前記優先順位タスクを実行するステップと
    をさらに含み、前記プロセッサを介して、前記次のタスクが前記マルチバージョンタスクに関連するとの判定に応答して前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求するステップは、前記プロセッサを介して、前記優先順位タスクの実行に応答して前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求するステップを含む、
    請求項7に記載の方法。
14. 前記プロセッサは、前記第1の処理ユニットである、請求項1に記載の方法。
15. マルチプロセッサコンピューティングデバイスであって、
    メモリと、
    前記メモリに結合された複数の処理ユニットであって、前記複数の処理ユニットのプロセッサは、
    前記複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューする動作であって、各特殊化されたバージョンは、前記複数の処理ユニットの異なる処理ユニットによって実行されるように構成される、エンキューする動作と、
    前記複数の処理ユニットの第1の処理ユニットに前記マルチバージョンタスクに対する所有権を提供する動作であって、前記第1の処理ユニットは、前記複数の処理ユニットの他の処理ユニットが前記マルチバージョンタスクの他の特殊化されたバージョンを実行するのに使用可能になる前に、前記マルチバージョンタスクの第1の特殊化されたバージョンを即座に実行するのに使用可能である、提供する動作と、
    前記第1の処理ユニットに前記マルチバージョンタスクに対する前記所有権を提供することに応答して、前記マルチバージョンタスクの前記他の特殊化されたバージョンを破棄する動作と
    を含む動作を実行するためにプロセッサ実行可能命令を用いて構成される、複数の処理ユニットと
    を含むマルチプロセッサコンピューティングデバイス。
16. 前記プロセッサは、前記マルチプロセッサコンピューティングデバイスが、前記複数の処理ユニットをスケジューリングするように構成されたランタイム機能性を実行しているときに前記動作を実行するように構成される、請求項15に記載のマルチプロセッサコンピューティングデバイス。
17. 前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンをエンキューする動作が、
    前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンに関連するポインタをエンキューする動作
    を含むように、前記プロセッサは動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項15に記載のマルチプロセッサコンピューティングデバイス。
18. 各ポインタが、前記マルチバージョンタスクおよび前記マルチバージョンタスクの前記特殊化されたバージョンの識別を含むように、前記プロセッサは動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項17に記載のマルチプロセッサコンピューティングデバイス。
19. 前記マルチバージョンタスクの前記特殊化されたバージョンの前記識別が、各ポインタの最下位4ビット内に含まれるように、前記プロセッサは動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項18に記載のマルチプロセッサコンピューティングデバイス。
20. 前記複数の処理ユニットの前記第1の処理ユニットに前記マルチバージョンタスクに対する前記所有権を提供する動作が、前記マルチバージョンタスクに関連するデータを記憶する動作を含むように、前記プロセッサは動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項15に記載のマルチプロセッサコンピューティングデバイス。
21. 前記プロセッサは、
    前記第1の処理ユニットの前記タスクキューからの次のタスクが前記マルチバージョンタスクに関連するかどうかを判定する動作と、
    前記次のタスクが前記マルチバージョンタスクに関連するとの判定に応答して、前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項15に記載のマルチプロセッサコンピューティングデバイス。
22. 前記プロセッサは、
    前記所有権の要求に応答して前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を獲得する動作と、
    前記第1の処理ユニットを介して、前記マルチバージョンタスクに対する前記所有権の獲得に応答して前記次のタスクを実行する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項21に記載のマルチプロセッサコンピューティングデバイス。
23. 前記プロセッサは、前記第1の処理ユニットの前記タスクキューからの前記次のタスクが前記マルチバージョンタスクに関連するかどうかを判定する動作が、
    前記第1の処理ユニットの前記タスクキューからのポインタにビットマスクを適用することによって識別子を入手する動作と、
    前記識別子が前記マルチバージョンタスクの前記第1の特殊化されたバージョンに対応するとの判定に応答して、前記次のタスクが前記マルチバージョンタスクに関連すると判定する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項21に記載のマルチプロセッサコンピューティングデバイス。
24. 前記プロセッサは、前記第1の処理ユニットの前記タスクキューからの前記次のタスクが前記マルチバージョンタスクに関連するかどうかを判定する動作が、
    前記第1の処理ユニットの前記タスクキューからポインタを取り出す動作であって、前記ポインタは、前記複数の処理ユニットの各々の前記タスクキュー内に配置された共通のマルチバージョンタスクポインタである、取り出す動作と、
    前記ポインタが前記マルチバージョンタスクの特殊化されたバージョンのリストに関連するかどうかを判定する動作と、
    前記ポインタが前記マルチバージョンタスクの特殊化されたバージョンの前記リストに関連するとの判定に応答して、前記マルチバージョンタスクの特殊化されたバージョンの前記リストから前記マルチバージョンタスクの前記第1の特殊化されたバージョンを識別する動作であって、前記第1の特殊化されたバージョンは、前記第1の処理ユニットによって実行される前記次のタスクである、識別する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項21に記載のマルチプロセッサコンピューティングデバイス。
25. 前記プロセッサは、
    前記第1の処理ユニットを介して、前記次のタスクが前記マルチバージョンタスクに関連しないとの判定に応答して前記次のタスクを実行する動作
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項21に記載のマルチプロセッサコンピューティングデバイス。
26. 前記プロセッサは、
    前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権の要求に応答して、前記マルチバージョンタスクに対する前記所有権が第2の処理ユニットによって獲得されたと判定する動作と、
    前記マルチバージョンタスクに対する前記所有権が前記第2の処理ユニットによって獲得されたとの判定に応答して前記次のタスクを破棄する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成される、請求項21に記載のマルチプロセッサコンピューティングデバイス。
27. 前記プロセッサは、
    前記第1の処理ユニットに関連する前記タスクキュー内に優先順位タスクがあるかどうかを判定する動作と、
    前記第1の処理ユニットを介して、前記優先順位タスクを実行する動作と
    をさらに含む動作を実行するようにプロセッサ実行可能命令を用いて構成され、前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求する動作は、前記優先順位タスクの実行に応答して前記第1の処理ユニットに関する前記マルチバージョンタスクに対する前記所有権を要求する動作を含む、請求項21に記載のマルチプロセッサコンピューティングデバイス。
28. マルチプロセッサコンピューティングデバイスのプロセッサに、
    複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューする動作であって、各特殊化されたバージョンは、前記複数の処理ユニットの異なる処理ユニットによって実行されるように構成される、エンキューする動作と、
    前記複数の処理ユニットの第1の処理ユニットに前記マルチバージョンタスクに対する所有権を提供する動作であって、前記第1の処理ユニットは、前記複数の処理ユニットの他の処理ユニットが前記マルチバージョンタスクの他の特殊化されたバージョンを実行するのに使用可能になる前に、前記マルチバージョンタスクの第1の特殊化されたバージョンを即座に実行するのに使用可能である、提供する動作と、
    前記第1の処理ユニットに前記マルチバージョンタスクに対する前記所有権を提供することに応答して、前記マルチバージョンタスクの前記他の特殊化されたバージョンを破棄する動作と
    を含む動作を実行させるように構成されたプロセッサ実行可能命令をその上に記憶された非一時的プロセッサ可読記憶媒体。
29. 前記記憶されたプロセッサ実行可能命令は、前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンをエンキューする動作が、
    前記複数の処理ユニットの各々の前記タスクキュー内に前記マルチバージョンタスクの前記特殊化されたバージョンに関連するポインタをエンキューする動作
    を含むように、前記マルチプロセッサコンピューティングデバイスの前記プロセッサに動作を実行させるように構成される、請求項28に記載の非一時的プロセッサ可読記憶媒体。
30. マルチプロセッサコンピューティングデバイスであって、
    複数の処理ユニットの各々のタスクキュー内にマルチバージョンタスクの特殊化されたバージョンをエンキューするための手段であって、各特殊化されたバージョンは、前記複数の処理ユニットの異なる処理ユニットによって実行されるように構成される、エンキューするための手段と、
    前記複数の処理ユニットの第1の処理ユニットに前記マルチバージョンタスクに対する所有権を提供するための手段であって、前記第1の処理ユニットは、前記複数の処理ユニットの他の処理ユニットが前記マルチバージョンタスクの他の特殊化されたバージョンを実行するのに使用可能になる前に、前記マルチバージョンタスクの第1の特殊化されたバージョンを即座に実行するのに使用可能である、提供するための手段と、
    前記第1の処理ユニットに前記マルチバージョンタスクに対する所有権を提供することに応答して、前記マルチバージョンタスクの前記他の特殊化されたバージョンを破棄するための手段と
    を含むマルチプロセッサコンピューティングデバイス。

Images