JP2015530683A - 異種計算システムにおけるコールド変換索引バッファミスを低減させること - Google Patents

Abstract

コンピュータシステムにおけるコールド変換索引バッファ（ＴＬＢ）ミスを回避するための方法および装置が提供される。典型的なシステムは、共通メモリアドレス空間を共有する少なくとも１つの中央処理装置（ＣＰＵ）および１つ以上のグラフィックス処理装置（ＧＰＵ）を有する異種計算システムとして構成されている。各処理装置（ＣＰＵおよびＧＰＵ）は、独立したＴＬＢを有している。タスクを特定のＣＰＵから特定のＧＰＵへオフロードする場合には、変換情報が、タスク割り当てとともに送信される。変換情報は、ＧＰＵが、タスクを実行する前にアドレス変換データを１つ以上のＧＰＵに関連付けられたＴＬＢへロードすることができるようにする。ＧＰＵのＴＬＢをプレロードすることは、そうでなければ本開示によってもたらされる利益なしに発生するであろうコールドＴＬＢを、低減または回避する。【選択図】図４

Description

本開示の実施形態は、共通メモリアドレス空間（物理的および仮想的の両方を含む）を有する異なるタイプの処理装置（例えば、中央処理装置、グラフィックス処理装置、ディジタル信号プロセッサまたは様々なタイプのアクセラレータ）を採用する異種計算システムの分野に関する。さらに詳しくは、本開示の実施形態は、タスクが一方のプロセッサタイプから他方のプロセッサタイプへオフロードされたときに、かかる計算システムにおけるコールド変換索引バッファ（ＴＬＢ）ミスを低減または回避する分野に関する。

異種計算システムは、典型的には、異なるタイプの処理装置を採用している。例えば、異種計算システムは、共通メモリアドレス空間（物理アドレス空間および仮想アドレス空間の両方）を共有する中央処理装置（ＣＰＵ）およびグラフィックス処理装置（ＧＰＵ）を使用し得る。ＧＰＵを使用する汎用計算（ＧＰＧＰＵ計算）において、ＧＰＵは、従来ＣＰＵによって実行されていたいくつかの作業あるいはタスクを実行するのに用いられている。ＣＰＵは、タスクをＧＰＵへハンドオフまたはオフロードし、次に、ＧＰＵは、当該タスクを実行して、結果、データまたは他の情報を、直接的にＣＰＵに提供し、または、情報を記憶することによってＣＰＵに提供するであろう。ここで、ＣＰＵは、必要とされる場合には、その情報を検索することができる。

ＣＰＵおよびＧＰＵが、多くの場合、共通メモリアドレス空間を共有する一方で、これらの色々なタイプの処理装置にとっては、特定のタイプの処理装置に最適化され得る独立したアドレス変換機構または階層を有することが一般的なことである。言い換えれば、現代の処理装置は、典型的には、メモリ空間をアドレス指定するために仮想アドレススキームを利用する。したがって、処理装置が、実行すべき命令および／または処理すべきデータを見つけることができるように、変換索引バッファ（ＴＬＢ）が、仮想アドレスを物理アドレスに変換するために用いられ得る。タスクハンドオフの場合には、オフロード済タスクを完了するのに必要とされる変換情報が他のプロセッサタイプのＴＬＢから失われており、結果として、コールド（初期の）ＴＬＢミスとなる。ＴＬＢミスから回復するためには、タスクを受信するプロセッサは、タスク処理が開始される前に変換情報を取得するために、メモリのページを探索（一般的に「ページウォーク」と称される）しなければならない。多くの場合、処理遅延またはＴＬＢミスからの待ち時間は、クロックサイクルの１０倍から１００倍となる。

少なくとも１つの中央処理装置（ＣＰＵ）と、１つ以上のグラフィックス処理装置（ＧＰＵ）と、を有する異種計算システムにおけるコールドＴＬＢミスを回避するための方法が提供される。少なくとも１つのＣＰＵと、１つ以上のＧＰＵとは、共通メモリアドレス空間を共有するとともに、独立した変換索引バッファ（ＴＬＢ）を有している。特定のＣＰＵから特定のＧＰＵへタスクをオフロードするための方法は、タスクおよび変換情報を特定のＧＰＵへ送信することを含む。ＧＰＵは、タスクを受信し、当該タスクを実行する前に、１つ以上のＧＰＵに関連するＴＬＢへアドレス変換情報をロードするために前記変換情報を処理する。

異種コンピュータシステムは、タスクを実行し、または、少なくとも１つの中央処理装置（ＣＰＵ）に接続された第１の変換索引バッファ（ＴＬＢ）に前記タスクをオフロードするための前記少なくとも１つのＣＰＵを含む。異種コンピュータシステムは、前記タスクを実行することの可能な１つ以上のグラフィックス処理装置（ＧＰＵ）と、前記１つ以上のＧＰＵに接続された第２のＴＬＢと、をさらに含む。共通メモリアドレス空間は、第１および第２のＴＬＢに接続されており、前記少なくとも１つのＣＰＵおよび前記１つ以上のＧＰＵによって共有されている。タスクが特定のＣＰＵから特定のＧＰＵへオフロードされる場合に、前記タスクの実行前に、変換情報が、特定のＧＰＵがアドレス変換データを第２のＴＬＢへロードするタスクハンドオフに含まれる。

実施形態は、下記の図面に関連して以下に説明される。図面において、類似の符号は類似の要素を示す。

異種コンピュータシステムの簡略化された例示のブロック図である。 いくつかの実施形態によるタスクオフロードを示す、図１のブロック図である。 いくつかの実施形態によるタスクをオフロードするための方法を示すフロー図である。 いくつかの実施形態によるオフロード済タスクを実行するための方法を示すフロー図である。

以下の詳細な説明は、単に例示的なものであり、本開示または本願、および、本開示の利用を制限することを意図するものではない。ここで用いられるように、「例示的な」という用語は、「実例、具体例または例示として機能する」ことを意味している。このため、本明細書にて「例示的な」と記載された任意の実施形態は、他の実施形態よりも好ましいまたは有利である、と解釈すべきではない。本明細書に記載された全ての実施形態は、開示された実施形態を当業者が実施または利用することができる場合、または、特許請求の範囲に定義された開示の範囲を制限しない場合には、例示的な実施形態である。また、前述した技術分野、背景、概要、以下の詳細な説明によって示され、または、特定のコンピュータシステムについて示された明示的もしくは暗示的な如何なる理論においても、制約される意図は全く存在しない。

本明細書において、第１の、第２の、などの関係語は、１つのエンティティまたははアクションを、かかるエンティティまたはアクション同士間で実際にかかる関係または順序を要求または暗示することなく、別のエンティティまたはアクションから区別するために専ら使用され得る。「第１の」、「第２の」、「第３の」などの番号は、複数のもののうち何れか１つのものを単に示しており、クレームの言語によって特別に定義されない限り、如何なる順序性または連続性を暗示するものではない。

また、以下の説明では、ともに「接続され（ｃｏｎｎｅｃｔｅｄ）」または「連結され（ｃｏｕｐｌｅｄ）」ている要素または構成を言及する。本明細書で用いられるように、「接続された」とは、１つの要素／構成が、別の要素／構成へ直接的もしくは間接的に結合（もしくは直接通信）され、または、必ずしも機械的にではなく結合（もしくは直接通信）していることを言及し得る。同様に、「連結された」とは、１つの要素／構成が、別の要素／構成へ直接または間接的に結合され、または、必ずしも機械的にではなく結合（もしくは直接あるいは間接的に通信）していることを言及し得る。しかしながら、２つの要素が「接続され」ていると以下に記載されたとしても、類似の要素が「連結され」ていてもよく、この逆も同様である、と理解すべきである。このため、本明細書に示されたブロック図は、要素の例示の配置を記載しているものの、実際の実施形態には、付加的に介在する要素、装置、構成または構成要素が存在していてもよい。

最後に、簡潔に表現するために、コンピュータシステムおよびコンピュータシステムの他の態様（および同システムの個々の動作要素）に関連した従来の技術および構成要素は、本明細書にて詳細に説明しないことがある。また、本願の図面に示された接続線は、様々な要素間の例示的な機能的関係および／または物理的連結を表現することを意図している。実施形態には、多くの代案または付加的な機能的関係もしくは物理的接続が存在していてもよい、ことに留意すべきである。

図１を参照すると、共通メモリ（アドレス空間）１１０を共有する中央処理装置（ＣＰＵ）１０２_０−１０２_Ｎ（全体として１０２）およびグラフィックス処理装置（ＧＰＵ）１０４_０−１０４_Ｍ（全体として１０４）を採用する異種コンピュータシステム１００を示す簡略化された例示的なブロック図が示されている。メモリ１１０は、ＳＤＲＡＭなどのダイナミックランダムアクセスメモリ（ＤＲＡＭ）、様々な型の静的ＲＡＭ（ＳＲＡＭ）、および、様々なタイプの不揮発性メモリ（例えば、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュ、ＰＣＭまたはＳＴＴ−ＭＲＡＭ）を含む任意のタイプの適切なメモリであってよい。

ＣＰＵ１０２およびＧＰＵ１０４は、同一の共通メモリ（アドレス空間）１１０を利用するものであるが、これらの異なるタイプの処理装置の各々は、いくつかの実施形態において特定のタイプの処理装置（すなわち、ＣＰＵまたはＧＰＵ）へ最適化することの可能な独立したアドレス変換機構を有している。言い換えれば、基本的な実施形態において、ＣＰＵ１０２およびＧＰＵ１０４は、仮想アドレススキームを利用して共通メモリ１１０をアドレス指定する。したがって、仮想アドレスを物理アドレスに変換するために変換索引バッファ（ＴＬＢ）が使用されるので、上記の処理装置は、実行する命令かつ／または処理するためのデータを見つけることができる。図１に示されたように、ＣＰＵ１０２は、ＴＬＢ_ｃｐｕ１０６を利用し、ＧＰＵ１０４は、独立したＴＬＢ_ｇｐｕ１０８を利用する。本明細書で用いられるように、ＴＬＢは、共通メモリ１１０のページテーブル１１２から間もなく使用される変換マッピングとして、最近使用されまたは予測されているキャッシュであり、仮想メモリアドレス変換速度を改善するために使用される。ページテーブル１１２は、仮想メモリアドレスと物理メモリアドレスとの間のマッピングを記憶するために使用されるデータを備えている。仮想メモリアドレスは、アクセス処理ごとに固有のものであり、物理メモリアドレスは、ＣＰＵ１０２およびＧＰＵ１０４ごとに固有のものである。ページテーブル１１２は、命令を処理し、および／または、データをロード／記憶するために、実行処理で見られた仮想メモリアドレスを、ＣＰＵ１０２およびＧＰＵ１０４によって使用される物理メモリアドレスに変換するのに用いられる。

したがって、ＣＰＵ１０２またはＧＰＵ１０４が共通メモリ１１０へアクセスしようと試みる（例えば、特定の仮想メモリアドレスに配置されたデータもしくは命令を取り出すように、または、データを特定の仮想メモリアドレスへ記憶するように試みる）場合に、当該仮想メモリアドレスは、対応する物理メモリアドレスへ変換されなければならない。このため、ＴＬＢは、高速変換を提供する試みにおいて、仮想メモリアドレスを物理メモリアドレスへ変換するときに、最初に探索される。典型的には、ＴＬＢは、仮想メモリアドレスを物理メモリアドレスへマップするアドレス変換データ（エントリ）を含む固定数のスロットを有している。ＴＬＢは、通常、探索キーが仮想メモリアドレスであり、探索結果が物理メモリアドレスである、内容参照メモリ（ｃｏｎｔｅｎｔ−ａｄｄｒｅｓｓａｂｌｅ ｍｅｍｏｒｙ）である。いくつかの実施形態において、ＴＬＢは、単一のメモリキャッシュである。いくつかの実施形態において、ＴＬＢは、当該技術分野において知られているように、ある階層でネットワーク化または編成されている。しかしながら、ＴＬＢは、要求されたアドレスが当該ＴＬＢ内に存在すると（すなわち、「ＴＬＢヒット」）、探索がマッチを速くもたらし、かつ、物理メモリアドレスが戻されることによって、実現される。要求されたアドレスがＴＬＢ内に存在しない（すなわち、「ＴＬＢミス」）場合には、変換は、「ページウォーク」と一般に称される処理において、ページテーブル１１２を調べることによって進行する。物理メモリアドレスが決定された後に、物理メモリアドレスへの仮想メモリアドレスのマッピングが、（何れのタイプのプロセッサ（ＣＰＵまたはＧＰＵ）にアドレスマッピングが要求されているかに依存して）ＴＬＢ１０６またはＴＬＢ１０８にロードされる。

ＧＰＵを使用する汎用計算（ＧＰＧＰＵ計算）において、ＧＰＵは、典型的に、従来ＣＰＵによって実行された何らかの作業またはタスクを実行するために用いられる（逆も同様である）。このようにするために、ＣＰＵは、タスクをＧＰＵへハンドオフまたはオフロードし、次いで、ＧＰＵは、当該タスクを実行し、結果、データもしくは他の情報を、直接的にＣＰＵに提供し、または、情報を共通メモリ１１０に記憶することによってＣＰＵに提供するであろう。ここで、ＣＰＵは、必要とされる場合に、記憶された情報を検索することができる。タスクのハンドオフの場合には、オフロード済タスクを実行するために必要とされる変換情報が、他のプロセッサタイプのＴＬＢから失われており、結果として、コールド（初期の）ＴＬＢミスになるであろう。上述したように、ＴＬＢミスから回復するためには、タスクを受信するプロセッサは、メモリ１１０のページテーブル１１２を探索して（一般的に「ページウォーク」と称される）、タスク処理が開始される前に変換情報を取得することが要求される。

図２を参照すると、図１の計算システム１００は、いくつかの実施形態による例示的なタスクオフロード（またはハンドオフ）を実行することが示されている。簡潔さと便宜のために、タスクオフロードは、ＣＰＵ_ｘ１０２_ｘからＧＰＵ_ｙ１０４_ｙまでのものとして検討されているが、ＧＰＵ_ｙ１０４_ｙからＣＰＵ_ｘ１０２_ｘまでのタスクオフロードも本開示の範囲内にある、ということが理解できるであろう。いくつかの実施形態において、ＣＰＵ_ｘ１０２_ｘは、オフロードされるタスクをＧＰＵ_ｙ１０４_ｙへバンドルまたはアセンブルするとともに、当該タスクの記述（またはポインタ）をキュー２００に配置する。いくつかの実施形態において、当該タスクの記述（または当該タスクのポインタ）は、ＧＰＵｙ１０４ｙへ直接送信され、または、共通メモリ１１０内の記憶位置を介して送信される。後の時点で、ＧＰＵ_ｙ１０４_ｙは、関連するＴＬＢ_ｇｐｕ１０８から第１の仮想アドレス変換を呼び出すことで、当該タスクを実行し始めるであろう。しかしながら、タスクがオフロードされており、ＴＬＢ_ｃｐｕ１０６において先取りまたはロードされた如何なる変換情報もＧＰＵ１０４にとって使用可能なものではないことから、変換情報がＴＬＢ_ｇｐｕ１０８内に存在しない場合がある。このことは、オフロードされたタスクが実行され始める前にページウォークを必要とする第１の命令（または、当該第１の命令についてのアドレス変換の呼び出し）からのコールド（初期の）ＴＬＢミスという結果になるであろう。かかる処理に含まれる付加的な待ち時間は、タスクハンドオフを最初から行うことによって、要求された増大効率を損なう。

したがって、いくつかの実施形態では、タスクの開始前または当該タスクの実行中に、ＧＰＵ_ｙ１０４_ｙのディスパッチャまたはスケジューラ２０２がアドレス変換データをＴＬＢ_ｇｐｕ１０８にロード（プレロード）することの可能な変換情報を用いて、タスクハンドオフ記述（ポインタ）を向上または補足することを予期する。いくつかの実施形態において、変換情報は、確定的であり、または、ＴＬＢ_ｇｐｕ１０８へロードされたアドレス変換データに直接関連する。確定的な変換情報の非限定的な例は、ＴＬＢ_ｇｐｕ１０８へ直接ロードすることの可能なＴＬＢ_ｃｐｕ１０６からのアドレス変換データ（ＴＬＢエントリ）であろう。これに代えて、ＴＬＢ_ｇｐｕ１０８は、必要とされるアドレス変換データを配置するために、ＴＬＢ_ｃｐｕ１０６の何処を探査すべきか助言され得る。いくつかの実施形態において、変換情報は、ＴＬＢ_ｇｐｕ１０８のためのアドレス変換データを予測または導出するために使用される。予測した変換情報の非限定的な例は、特定の任意のインプリメンテーションに採用され得る、コンパイラ分析、動的ランタイム分析またはハードウェア追跡を含んでいる。いくつかの実施形態において、変換情報は、ＧＰＵ_ｙ１０４_ｙがアドレス変換データを得ることの可能なタスクハンドオフに含まれる。この種の変換情報の非限定的実例は、アドレス変換データを得るするために構文解析されるであろう将来のアドレスアクセスのためのパターンまたはコード化を含んでいる。一般に、コールドＴＬＢミス（および、その後のページウォーク）の発生を低減または回避するために、ＧＰＵ_ｙ１０４_ｙがＴＬＢ_ｇｐｕ１０８にアドレス変換データを直接または間接的にロードすることのできる任意の変換情報は、本開示によって予期されている。

図３〜図４は、コールドＴＬＢミスを回避するための本開示の方法を理解するのに有用なフロー図である。上述したように、簡潔さおよび便宜のために、タスクオフロードおよび実行の方法は、ＣＰＵ_ｘ１０２_ｘからＧＰＵ_ｙ１０４_ｙまでのものとして検討されているが、ＧＰＵ_ｙ１０４_ｙからＣＰＵ_ｘ１０２_ｘまでのタスクオフロードも本開示の範囲内にある、ということが理解できるであろう。図３〜図４の方法に関連して実行される様々なタスクは、ソフトウェア、ハードウェア、ファームウェアまたはこれらの組み合わせによって実行することができる。例示的な目的のために、図３〜図４の方法についての以下の説明は、図１〜図２に関連して上述した要素に言及することができる。実際に、図３〜図４の方法の一部は、説明されたシステムの異なる要素で実行することができる。図３〜図４の方法が、任意数の付加的または代替のタスクを含んでもよいことと、図３〜図４の方法が本明細書で詳しく説明されていない付加的機能を有するより包括的な任意の数の手順または処理に組み込まれてもよいということと、が理解できるであろう。さらに、図３〜図４に示された１つ以上のタスクは、意図された全体の機能が失われることなく残る限り、図３〜図４の方法についての実施形態から省略することができる。

図３を参照すると、いくつかの実施形態によるタスクをオフロードするための方法３００を示すフロー図が表されている。この方法３００は、ステップ３０２において開始される。ここでは、変換情報が、オフロードされるタスクに含まれるように蓄積または収集される。前述したように、この変換情報は、確定的であってもよいし、ＴＬＢ_ｇｐｕ１０８へロードされるアドレス変換データ（例えば、ＴＬＢ_ｃｐｕ１０６からのアドレス変換データ）に直接関連があってもよい。また、変換情報は、ＴＬＢ_ｇｐｕ１０８のためのアドレス変換データを予測または導出するために使用されてもよい。ステップ３０４において、タスクおよび関連する変換情報は、一方のプロセッサタイプから他方のプロセッサタイプへ（例えば、ＣＰＵからＧＰＵへ、または逆も同様である）送信される。判断３０６において、タスクをハンドオフしたプロセッサ（本例ではＣＰＵ１０２）は、ハンドオフを受信するプロセッサがタスクを完了したかどうかを判定する。いくつかの実施形態において、オフロードするプロセッサは、他のプロセッサがタスクを完了したことを確かめるために、周期的にチェックを行う。いくつかの実施形態において、ハンドオフを受信するプロセッサは、割り込み信号または他の信号を、判断３０６の肯定的判定を引き起こすであろう、オフロードするプロセッサへ送信する。肯定的判定が達成されるまで、ルーチンが判断３０６の周りでループする。このオフロード済タスクが完了すると、必要であれば（例えば、このオフロード済タスクがより大きいタスクのサブステップまたは副処理であった場合など）、ステップ３０８において、さらに別の処理を実行することができる。また、オフロードするプロセッサは、いくつかのサブタスクを他のプロセッサへオフロードしてもよく、全てのプロセスまたはタスクを完了するために、サブタスクの結果をコンパイルまたは組み合わせる必要がある。この後に、ルーチンが終了する（ステップ３１０）。

図４を参照すると、いくつかの実施形態によるオフロード済タスクを実行するための方法４００を示すフロー図が表されている。この方法４００は、ステップ４０２において開始される。ここでは、タスクハンドオフを伴う変換情報が抽出または調査される。次に、判断４０４は、変換情報が、ハンドオフを受け取るプロセッサのＴＬＢ（例えば、ＣＰＵからＧＰＵへのハンドオフのためのＴＬＢ_ｇｐｕ１０８）へ直接ロードすることの可能なアドレス変換データから構成されているか否かを判定する。ここでの肯定的判定は、オフロードするＴＬＢ（例えば、ＴＬＢ_ｃｐｕ１０６）からＴＬＢエントリが提供されたこと、または、変換情報が、アドレス変換データを配置するために他のプロセッサのＴＬＢを何処で探査するかを、タスクを受信するプロセッサタイプに助言すること、を意味している。このデータは、ステップ４０６において、ＴＬＢ（本例ではＴＬＢ_ｇｐｕ１０８）へロードされる。

判断４０４の否定的判定は、変換情報がアドレス変換データに直接関連付けられていない、ということを意味している。したがって、判断４０８は、オフロードするプロセッサが、変換情報からアドレス変換を取得（ステップ４１０）しなければならないかどうかを判定する。このような事例は、オフロードするプロセッサが、変換情報に基づいて（あるいは変換情報から）、アドレス変換データを予測または導出することを必要とする事例であろう。上述したように、アドレス変換データは、特定の任意のインプリメンテーションに採用することのできるコンパイラ分析、動的ランタイム分析またはハードウェア追跡から予測されるであろう。また、アドレス変換データは、ステップ４１０において、アドレス変換データを導出するために将来のアドレスアクセスのためのパターンまたはコード化を構文解析することによって、取得されるであろう。採用されたアドレス変換データを取得する方法にかかわらず、アドレス変換データを表現するＴＬＢエントリは、ステップ４０６においてロードされる。しかしながら、判断４０８は、アドレス変換データを取得する（あるいは、取得することを試みる）ことがない（あるいは、すべきではない）と判断するであろう。このような事例は、変換情報が無効であることがわかったかどうか、または、要求された変換がもはや物理メモリ空間にない（例えば、第２の記憶媒体へ移動した）かどうかという事例であろう。この事例において、判断４０８は、変換情報を基本的に無視し、ルーチンは、タスクを開始する（ステップ４１２）ように進行する。

オフロード済タスクの処理を開始するために第１の変換が要求され、判断４１４は、ＴＬＢミスがあったかどうかを判定する。ステップ４０６を介してステップ４１２に移行した場合、ＴＬＢミスは回避されるべきであり、ＴＬＢヒットが戻される。しかしながら、判断４０８の否定的判定を介してステップ４１２へ移行した場合には、ＴＬＢミスが発生した可能性があり、かかる場合には、ステップ４１８において従来のページウォークが実行される。ルーチンは、タスクを実行する（ステップ４１６）ことを継続し、各々のステップ後、タスクが完了したかどうかを判断４２０において判定する。タスクがまだ完了していない場合には、ルーチンは、別のアドレス変換を含み得る次のステップ（ステップ４２２）を実行するために、ループバックする。言い換えれば、オフロード済タスクの実行中に、いくつかのアドレス変換が必要とされてもよく、いくつかの場合には、ＴＬＢミスが発生して、ページウォーク（ステップ４１８）が必要とされるであろう。しかしながら、ステップ４０６を介してタスクの実行に移行した場合には、ページウォーク（およびそれに関連した待ち時間）は、いくつかのハンドオフについて実質的に低減または排除されるべきである。増大した効率および減少した電力消費量は、本開示のハンドオフシステムおよび処理によってもたらされた直接的な利益である。

タスクが完了したことを判断４２０が判定すると、タスク結果が、ステップ４２４においてオフロードプロセッサへ送信される。このことは、１つの実施形態において、タスクが完了しているかどうかを判定するために、オフロードプロセッサからの問い合わせに応答することによって、実現することができる。別の実施形態では、タスクハンドオフを受け取るプロセッサは、割り込みを誘発するか、または、タスクが完了していることを表示するオフロードプロセッサへ別の信号を送信することがある。そのタスク結果が戻されると、ルーチンは、ステップ４２６で終了する。

コンピュータシステム１００の例示的なデータ構造および／またはコンピュータ可読記憶媒体に含まれるデータ構造の一部は、あるプログラムによって読み取ることができ、かつ、コンピュータシステム１００を備えるハードウェアを組み立てるために直接または間接的に使用することができるデータベースまたは他のデータ構造であってよい。例えば、このデータ構造は、ＶｅｒｉｌｏｇまたはＶＨＤＬなどの高水準設計用言語（ＨＤＬ）におけるハードウェア機能の動作レベル記述またはレジスタトランスファレベル（ＲＴＬ）記述であってよい。これらの記述は、合成ライブラリからのゲートのリストを備えるネットリストを生成するために、これらの記述を合成することのできる合成ツールによって読み取ることができる。このネットリストは、コンピュータシステム１００を備えるハードウェアの機能を表現する一組のゲートを備えている。このネットリストは、その後、マスクへ適用される幾何学的形状を記述するデータの組を生成するために配置されるとともに経路指定され得る。マスクは、その後、コンピュータシステム１００に対応する半導体回路を製造するために、様々な半導体組立ステップにおいて使用されることがある。これに代えて、コンピュータ可読記憶媒体におけるデータベースは、要望どおり、ネットリスト（合成ライブラリが備わっているか、または、備わっていない）またはデータ組であってもよい。また、グラフィックスデータシステム（ＧＤＳ）ＩＩデータであってもよい。

図３〜図４に示された方法は、コンピュータ可読記憶媒体の内に記憶されており、かつ、コンピュータシステム１００の少なくとも１つのプロセッサによって実行される命令によって管理することができる。図３〜図４に示された各々の動作は、非一時的なコンピュータメモリまたはコンピュータ可読記憶媒体に記憶された命令に対応することができる。様々な実施形態において、非一時的なコンピュータ可読記憶媒体は、磁気的もしくは光学的なディスク記憶装置、フラッシュメモリなどのソリッドステート記憶装置、または、他の不揮発性メモリ装置を含んでいる。非一時的なコンピュータ可読記憶媒体に記憶されたコンピュータ可読命令は、１つ以上のプロセッサによって解釈され、かつ／または、実行可能であるソースコード、アセンブリ言語コード、オブジェクトコードもしくは他の命令フォーマットであってよい。

例示的な実施形態が上記の詳細な説明において提示されてきたが、膨大な数の変形例が存在するということはわかるであろう。例示的な実施形態は、単なる実例であり、範囲、適用性または形態をどのような方法においても制限することを意図していない、ということがわかるであろう。どちらかと言えば、上記の詳細な説明は、例示的な実施形態を実施するための便利な指針を当業者に提供するが、例示的な実施形態に記載された要素の機能および配置には、添付の特許請求の範囲に説明された範囲およびそれらの法律的な均等物から逸脱することなく、様々な変更を行うことができるということが理解されよう。

Claims (20)

1. 第１のプロセッサタイプから第２のプロセッサタイプへ、前記第２のプロセッサタイプによって実行されるタスクをオフロードするための方法であって、
   前記第１のプロセッサから前記タスクを受信することであって、前記第１のプロセッサおよび前記第２のプロセッサが共通メモリアドレス空間を利用することと、
   前記タスクのための変換情報を前記第１のプロセッサタイプから受信することと、
   前記タスクを実行する前にアドレス変換データを前記第２のプロセッサタイプの変換索引バッファ（ＴＬＢ）へロードするために、前記変換情報を使用することと、を含む、方法。
2. 前記第１のプロセッサタイプは中央処理装置（ＣＰＵ）であり、前記第２のプロセッサタイプはグラフィックス処理装置（ＧＰＵ）である、請求項１に記載の方法。
3. 前記第１のプロセッサタイプはＧＰＵであり、前記第２のプロセッサタイプはＣＰＵである、請求項１に記載の方法。
4. 前記変換情報はページテーブルエントリを含み、
   前記タスクを実行する前に、前記ページテーブルエントリを前記第２のプロセッサタイプのＴＬＢへロードすることをさらに含む、請求項１に記載の方法。
5. 前記変換情報に基づいて前記アドレス変換データを取得することと、
   前記タスクを実行する前に、前記アドレス変換データを前記第２のプロセッサタイプの前記ＴＬＢへロードすることと、をさらに含む、請求項１に記載の方法。
6. 前記アドレス変換データを取得することは、前記第１のプロセッサタイプに関連付けられたＴＬＢを探ることを含む、請求項５に記載の方法。
7. 前記アドレス変換データを取得することは、今後のアドレスアクセスのパターンを構文解析することを含む、請求項５に記載の方法。
8. 前記アドレス変換データを取得することは、今後のアドレスアクセスを予測することを含む、請求項５に記載の方法。
9. 前記今後のアドレスアクセスを予測することは、今後のアドレスアクセスを、変換情報源のグループを構成する、コンパイラ分析、動的ランタイム分析およびハードウェア追跡のうち１つ以上から予測することを含む、請求項８に記載の方法。
10. 前記アドレス変換データを取得することは、前記変換情報を無視することと、ページウォークを実行することと、を含む、請求項５に記載の方法。
11. 第１のプロセッサタイプから第２のプロセッサタイプへ、前記第２のプロセッサタイプによって実行されるタスクをオフロードするための方法であって、
    前記タスクを前記第２のプロセッサタイプへ送信することと、
    変換情報を前記第２のプロセッサタイプへ送信することと、を含み、
    前記変換情報は、前記第２のプロセッサタイプが前記タスクを実行する前にアドレス変換データを前記第２のプロセッサタイプの変換索引バッファ（ＴＬＢ）へロードするために、前記第２のプロセッサタイプによって使用し得る、方法。
12. 前記変換情報は、ページテーブルエントリである、請求項１１に記載の方法。
13. 前記アドレス変換データは、前記変換情報を使用して前記第２のプロセッサタイプによって取得され、前記アドレス変換データは、前記タスクを実行する前に、前記第２のプロセッサタイプに関連付けられたＴＬＢへロードされる、請求項１１に記載の方法。
14. 前記第２のプロセッサタイプは、今後のアドレスアクセスのパターンを構文解析することによって、前記アドレス変換データを取得する、請求項１３に記載の方法。
15. 前記第２のプロセッサタイプは、今後のアドレスアクセスを予測することによって、前記アドレス変換データを取得する、請求項１３に記載の方法。
16. 前記第２のプロセッサタイプは、前記変換情報を無視することと、ページウォークを実行することとによって、前記アドレス変換データを取得する、請求項１３に記載の方法。
17. 第１の変換索引バッファ（ＴＬＢ）を含む第１のプロセッサタイプであって、タスクと、前記タスクのための変換情報とを第２のプロセッサタイプへ送信するように構成された第１のプロセッサタイプと、
    第２のＴＬＢを含む第２のプロセッサタイプであって、前記タスクおよび前記変換情報を前記第１のプロセッサから受信し、前記タスクを実行する前にアドレス変換データを前記第２のＴＬＢへロードするために、前記変換情報を使用するように構成された第２のプロセッサタイプと、
    前記第１のプロセッサタイプおよび前記第２のプロセッサタイプに接続されたメモリであって、前記第１のプロセッサタイプおよび前記第２のプロセッサタイプは、前記メモリの共通メモリアドレス空間を利用する、メモリと、を備える、異種計算システム。
18. 前記変換情報は、ページテーブルエントリである、請求項１７に記載の異種計算システム。
19. 前記第１のプロセッサタイプは中央処理装置（ＣＰＵ）であり、前記第２のプロセッサタイプはグラフィックス処理装置（ＧＰＵ）である、請求項１７に記載の異種計算システム。
20. 前記第１のプロセッサタイプはグラフィックス処理装置（ＧＰＵ）であり、前記第２のプロセッサタイプは中央処理装置（ＣＰＵ）である、請求項１７に記載の異種計算システム。