JP2015038770A - 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有 - Google Patents

Abstract

【課題】計算プラットフォームのヘテロジニアスプロセッサ間で共有されるバーチャルメモリにおけるバーチャル機能の共有技術を提供する。【解決手段】ＣＰＵ１１０から共有オブジェクト１３１にアクセスするのに利用されるＣＰＵサイドｖｔａｂｌｅポインタは、ＧＰＵサイドテーブルが存在する場合ＧＰＵ＿ｖｔａｂｌｅを決定するのに利用される。データ一貫性を維持しない共有非コヒーラント領域が共有バーチャルメモリ内に生成される。共有非コヒーラント領域内に格納されるＣＰＵ及びＧＰＵサイドデータは、ＣＰＵ及びＧＰＵサイドから参照されるような同一のアドレスを有する。ＣＰＵサイドデータのコンテンツは、共有バーチャルメモリ１３０がランタイム中に一貫性を維持しないため、ＧＰＵサイドデータのものと異なる。ｖｐｔｒは、共有バーチャルメモリ１３０に格納されているＣＰＵ＿ｖｔａｂｌｅ及びＧＰＵ＿ｖｔａｂｌｅを指示するよう変更される。【選択図】図１

Description

本発明は、バーチャルメモリに関する。

計算プラットフォームは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、シンメトリックプロセッサとアシンメトリックプロセッサなどのヘテロジニアスプロセッサを含むかもしれない。クラスインスタンス（又はオブジェクト）は、ＣＰＵ−ＧＰＵプラットフォームの第１サイド（ＣＰＵなど）に関する第１メモリにあるかもしれない。第２サイド（ＧＰＵサイド）は、ＣＰＵ−ＧＰＵプラットフォームの第１サイド（ＣＰＵサイド）に関する第１メモリにあるオブジェクト及び関連するメンバ関数を呼び出すことが有効とされていないかもしれない。また、第１サイドは、第２サイド（ＧＰＵサイド）上の第２メモリにあるオブジェクト及び関連するメンバ関数を呼び出すことが有効とされていないかもしれない。クラスインスタンス又はオブジェクトが異なるアドレススペースに格納されているとき、既存の通信機構は、単にヘテロジニアスプロセッサ（ＣＰＵ及びＧＰＵ）の間の一方向通信がクラスインスタンス及び関連するバーチャル関数を呼び出すことしか可能にしないかもしれない。

このような一方向通信アプローチは、ヘテロジニアスプロセッサの間のクラスインスタンスの自然な機能分割を妨げる。オブジェクトは、スループット指向メンバ関数といくつかのスカラメンバ関数を有する。例えば、ゲームアプリケーションのシーンクラスは、ＧＰＵに適したレンダリング関数を有し、さらにＣＰＵ上の実行に適した物理及び人工知能（ＡＩ）関数を有するかもしれない。現在の一方向通信機構では、典型的には、ＣＰＵ（上記の例における物理及び人工知能）メンバ関数とＧＰＵ（ＧＰＵに適したレンダリング関数）メンバ関数をそれぞれ有する２つの異なるシーンクラスである必要がある。ＣＰＵのための１つとＧＰＵのための１つとの２つの異なるシーンクラスを有することは、データが２つのシーンクラスの間で互いにコピーされることを要求するかもしれない。

上述した問題点を鑑み、本発明の課題は、計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有のための技術を提供することである。

上記課題を解決するため、本発明の一態様は、
計算プラットフォームにおける方法であって、
複数のバーチャル関数を含む共有オブジェクトを生成するステップと、
前記共有オブジェクトを共有バーチャルメモリに格納するステップと、
第１プロセッサと第２プロセッサとの間で前記複数のバーチャル関数の少なくとも１つを共有するステップと、
を有し、
前記計算プラットフォームは、前記第１プロセッサと前記第２プロセッサとを含み、
前記第１プロセッサと前記第２プロセッサとはヘテロジニアスプロセッサである方法に関する。

本発明の他の態様は、
実行されることに応答して、
複数のバーチャル関数を含む共有オブジェクトを生成するステップと、
前記共有オブジェクトを共有バーチャルメモリに格納するステップと、
第１プロセッサと第２プロセッサとの間で前記複数のバーチャル関数の少なくとも１つを共有するステップと、
をプロセッサに実行させる複数の命令を有するマシーン可読記憶媒体であって、
前記計算プラットフォームは、前記第１プロセッサと前記第２プロセッサとを有し、
前記第１プロセッサと前記第２プロセッサとは、ヘテロジニアスプロセッサであるマシーン可読記憶媒体に関する。

本発明の他の態様は、
第１コンパイラに接続される第１プロセッサと、第２コンパイラに接続される第２プロセッサとを有する複数のヘテロジニアスプロセッサを有する装置であって、
前記第１コンパイラは、前記第１プロセッサに割り当てられた第１バーチャルメンバ関数と、前記第２プロセッサに割り当てられた第２バーチャルメンバ関数とを含む共有オブジェクトを生成し、
前記第１プロセッサは、複数のバーチャル関数を含む共有オブジェクトを生成し、前記共有オブジェクトを共有バーチャルメモリに格納し、前記複数のバーチャル関数の少なくとも１つを第２プロセッサと共有する装置に関する。

本発明によると、計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有のための技術を提供することができる。

図１は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするプラットフォーム１００を示す。 図２は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするプラットフォーム１００により実行される処理を示すフローチャートである。 図３は、一実施例による共有オブジェクトからバーチャル関数ポインタをロードするためのＣＰＵサイド及びＧＰＵサイドのコードを示す。 図４は、第１実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするためのテーブルを生成するため、プラットフォーム１００により実行される処理を示すフローチャートである。 図５は、一実施例によるヘテロジニアスプロセッサにより共有されるオブジェクトのメンバ関数を介しＣＰＵ１１０とＧＰＵ１８０との間の双方向通信をサポートするためプラットフォーム１００により利用されるフロー図を示す。 図６は、第１実施例によるＣＰＵサイドにより行われるＧＰＵバーチャル関数及びＧＰＵ関数のコールの処理を示すフロー図を示す。 図７は、一実施例によるヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするバーチャルな共有非コヒーラント領域を利用するため、プラットフォーム１００により実行される処理を示すフローチャートである。 図８は、一実施例によるヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするためバーチャル共有非コヒーラント領域の利用を示す関係図である。 図９は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数を共有するためのサポートを提供するコンピュータシステムを示す。

ここに開示される本発明が、添付した図面により限定することなく例示的に説明される。説明の簡単化のため、図面に示される要素は、必ずしもスケーリングして示されていない。例えば、いくつかの要素の大きさは、簡単化のため他の要素に対して誇張されるかもしれない。さらに、適切であると考えられる場合、対応する又は類似する要素を示す参照番号は、図面において繰り返されている。

以下の説明は、計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数を共有するための技術を説明する。以下の説明では、ロジック実現形態、リソース分割、共有、重複実現形態、システムコンポーネントのタイプ及び相互関係、及びロジック分割若しくは統合選択などの多数の具体的詳細が、本発明のより完全な理解を提供するため提供される。しかしながら、本発明がこのような具体的詳細なしに実現可能であることは当業者に理解されるであろう。他の例では、本発明を不明りょうにしないため、制御構成、ゲートレベル回路及びフルソフトウェア命令シーケンスは、詳細には説明されない、当業者は、含まれている説明によって、過度な実験なしに適切な機能を実現可能であろう。

明細書における“一実施例”、“実施例”、“一例となる実施例”という表現は、説明された実施例が特定の特徴、構成又は特性を含むが、すべての実施例が必ずしも当該特徴、構成又は特性を含む必要がないことを示す。さらに、このような表現は、必ずしも同一の実施例を参照しているとは限らない。さらに、特定の特徴、構成又は特性が実施例に関して説明されているとき、明示的に説明されているか否かに関係なく、他の実施例に関してこのような特徴、構成又は特性に影響を与えることが当業者の知識の範囲内であることが主張される。

本発明の実施例は、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。本発明の実施例はまた、１以上のプロセッサにより読み込まれ、実行されるマシーン可読媒体に格納される命令として実現されてもよい。マシーン可読記憶媒体は、マシーン（計算装置など）により可読な形式により情報を格納又は送信するための何れかの機構を含むものであってもよい。

例えば、マシーン可読記憶媒体は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、電気又は光形態の信号を含むものであってもよい。さらに、ファームウェア、ソフトウェア、ルーチン及び命令は、特定のアクションを実行するとしてここでは説明される。しかしながら、このような説明は単に便宜的なものであり、このようなアクションは実際には、計算装置、プロセッサ、コントローラ及び他の装置がファームウェア、ソフトウェア、ルーチン及び命令を実行することにより生じることが理解されるべきである。

一実施例では、計算プラットフォームは、共有されるオブジェクトを詳細に分割することによって、共有オブジェクトのバーチャル関数などのメンバ関数を介しヘテロジニアスプロセッサ（ＣＰＵとＧＰＵなど）の間の双方向通信（関数コール）を可能にするための１以上の技術をサポートするものであってもよい。一実施例では、計算プラットフォームは、“テーブルベース”技術として参照される第１技術を用いて、ＣＰＵとＧＰＵとの間の双方向通信を可能にするものであってもよい。他の実施例では、計算プラットフォームは、バーチャル共有非コヒーラント領域がバーチャル共有メモリにおいて生成される“非コヒーラント領域”技術として参照される第２技術を用いて、ＣＰＵとＧＰＵとの間の双方向通信を可能にするものであってもよい。

一実施例では、テーブルベース技術の利用中、ＣＰＵからＧＰＵサイドに共有オブジェクトにアクセスするのに利用可能な共有オブジェクトのＣＰＵサイドｖｔａｂｌｅポインタが、ＧＰＵサイドテーブルが存在する場合、ＧＰＵ ｖｔａｂｌｅを決定するのに利用されてもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅは、＜“ｃｌａｓｓＮａｍｅ”，ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ，ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ＞を含むものであってもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅアドレスを取得し、ＧＰＵサイドテーブルを生成するための技術が、以下において詳細に説明される。

他の実施例では、非コヒーラント領域技術の利用中、共有非コヒーラント領域が共有バーチャルメモリ内に生成される。一実施例では、共有非コヒーラント領域は、データ一貫性を維持しないかもしれない。一実施例では、共有非コヒーラント領域内のＣＰＵサイドデータとＧＰＵサイドデータとは、ＣＰＵサイドとＧＰＵサイドから観察されるように同一のアドレスを有してもよい。しかしながら、共有バーチャルメモリはランタイム中にコヒーレンシを維持しなくてもよいため、ＣＰＵサイドデータのコンテンツは、ＧＰＵサイドデータのものと異なるものであってもよい。一実施例では、共有非コヒーラント領域は、共有される各クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、このようなアプローチは、同一のアドレスにおいてバーチャルテーブルを維持するようにしてもよい。

図１において、ＣＰＵとＧＰＵなどのヘテロジニアスプロセッサの間で共有されるバーチャル共有メモリにおけるバーチャル関数を提供する計算プラットフォーム１００の実施例が説明される。一実施例では、プラットフォーム１００は、ＣＰＵ１１０、ＣＰＵ１１０に関連するオペレーティングシステム（ＯＳ）１１２、ＣＰＵプライベートスペース１１５、ＣＰＵコンパイラ１１８、共有バーチャルメモリ（又はマルチバージョン共有メモリ）１３０、ＧＰＵ１８０、ＧＰＵ１８０に関するオペレーティングシステム（ＯＳ）１８２、ＧＰＵプライベートスペース１８５、及びＧＰＵコンパイラ１８８を有する。一実施例では、ＯＳ１１２及びＯＳ１８２はそれぞれ、ＣＰＵ１１０及びＣＰＵプライベートスペース１１５と、ＧＰＵ１８０及びＧＰＵプライベートスペース１８５とのリソースを管理する。一実施例では、共有バーチャルメモリ１３０をサポートするため、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５、マルチバージョンデータのコピーを有する。一実施例では、メモリ一貫性を維持するため、オブジェクト１３１などのメタデータが、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５に格納されているコピーを同期するのに利用されてもよい。他の実施例では、マルチバージョンデータが、共有メモリ９５０（後述される図９の）などの物理的共有メモリに格納されてもよい。一実施例では、共有バーチャルメモリは、ヘテロジニアスプロセッサＣＰＵ１１０，ＧＰＵ１８０のＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５などの物理的なプライベートメモリスペース、又はヘテロジニアスプロセッサにより共有される共有メモリ９５０などの物理的共有メモリによりサポートされてもよい。

一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８はそれぞれ、ＣＰＵ１１０及びＧＰＵ１８０に接続されるか、又は他のプラットフォーム若しくはコンピュータシステムにリモートに備えられてもよい。ＣＰＵ１１０に関連するコンパイラ１１８は、ＣＰＵ１１０のためのコンパイルされたコードを生成し、ＧＰＵ１８０に関連するコンパイラ１８８は、ＧＰＵ１８０のためのコンパイルされたコードを生成してもよい。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、オブジェクト指向言語などのハイレベル言語によりユーザにより提供されるオブジェクトの１以上のメンバ関数をコンパイルすることによって、コンパイルされたコードを生成するようにしてもよい。一実施例では、コンパイラ１１８，１８８は、共有メモリ１３０にオブジェクトを格納し、共有オブジェクト１３１は、ＣＰＵサイド１１０又はＧＰＵサイド１８０に配分されたメンバ関数を有してもよい。一実施例では、共有メモリ１３０に格納されている共有オブジェクト１３１は、バーチャル関数ＶＦ１３３−Ａ〜１３３−Ｋや非バーチャル関数ＮＶＦ１３６−Ａ〜１３６−Ｌなどのメンバ関数を有してもよい。一実施例では、ＣＰＵ１１０とＧＰＵ１８０との間の双方向通信は、共有オブジェクト１３１のＶＦ１３３やＮＶＦ１３６などのメンバ関数により提供されてもよい。

一実施例では、動的なバインディング目標を達成するため、ＶＦ１３３−Ａ（例えば、Ｃ＋＋バーチャル関数など）などのバーチャル関数が、バーチャル関数テーブル（ｖｔａｂｌｅ）をインデックス化することを介し、ＣＰＵ１１０又はＧＰＵ１８０によりコールされてもよい。一実施例では、バーチャル関数テーブルは、共有オブジェクト１３１の隠しポインタにより示されてもよい。しかしながら、ＣＰＵ１１０及びＧＰＵ１８０は、異なる命令セットアーキテクチャ（ＩＳＡ）を有してもよく、異なるＩＳＡを有するＣＰＵ１１０，ＧＰＵ１８０に対して関数がコンパイルされている間、コンパイラ１１８，１８８によりコンパイルされる同一の関数を表すコードは、異なるサイズを有してもよい。同じ方法によりＧＰＵサイドとＣＰＵサイド上でコードをレイアウトすることは困難であるかもしれない（すなわち、共有クラスのバーチャル関数のＣＰＵバージョンと、共有クラスの同一のバーチャル関数のＧＰＵバージョン）。共有クラスＦｏｏ（）に３つのバーチャル関数がある場合、コードのＣＰＵバージョンでは、関数はアドレスＡ１，Ａ２，Ａ３に配置されてもよい。しかしながら、コードのＧＰＵバージョンでは、関数は、Ａ１，Ａ２，Ａ３と異なるものであってもよいアドレスＢ１，Ｂ２，Ｂ３に配置されてもよい。共有クラスにおける同一の関数のためのＣＰＵサイドとＧＰＵサイドとの異なるアドレス位置は、共有オブジェクト（すなわち、共有クラスのインスタンス）が２つのｖｔａｂｌｅ（第１ｖｔａｂｌｅ及び第２ｖｔａｂｌｅ）を要求するかもしれない。第１ｖｔａｂｌｅは、関数のＣＰＵサイドバージョンのアドレス（Ａ１，Ａ２，Ａ３）を有し、オブジェクトがＣＰＵサイドにおいて利用されている間（又はＣＰＵサイド関数を呼び出すため）、利用されてもよい。第２ｖｔａｂｌｅは、関数のＧＰＵバージョンのアドレス（Ｂ１，Ｂ２，Ｂ３）を有し、第２ｖｔａｂｌｅは、オブジェクトがＧＰＵサイドにおいて利用されている間（又はＧＰＵサイド関数を呼び出すため）、利用されてもよい。

一実施例では、ＣＰＵ１１０とＧＰＵ１８０との間で共有されるバーチャルメモリに格納されているバーチャル関数の共有は、第１及び第２ｖｔａｂｌｅを共有オブジェクト１３１に関連付けることによって可能とされてもよい。一実施例では、ＣＰＵサイドとＧＰＵサイドとの双方においてバーチャル関数コールに利用可能な共通のｖｔａｂｌｅが、共有オブジェクト１３１の第１及び第２ｖｔａｂｌｅを関連付けることによって生成されてもよい。

図２のフローチャートにおいて、共有バーチャルメモリに格納されているバーチャル関数を共有するヘテロジニアスプロセッサＣＰＵ１１０，ＧＰＵ１８０の実施例が示される。ブロック２１０において、ＣＰＵ１１０などの第１プロセッサは、共有オブジェクト１３１の第１プロセッササイドｖｔａｂｌｅポインタ（ＣＰＵサイドｖｔａｂｌｅポインタ）を特定する。一実施例では、ＣＰＵサイドｖｔａｂｌｅポインタは、共有オブジェクト１３１がＣＰＵサイド又はＧＰＵサイドによりアクセスされるか否かに関係なく、共有オブジェクト１３１について存在してもよい。

一実施例では、ＣＰＵ専用環境などの計算システムにおける通常のバーチャル関数コールについて、コードシーケンスが、図３のブロック３１０において示される。一実施例では、ヘテロジニアスプロセッサを含む１００などの計算システムにおいてさえ、通常のバーチャル関数コールのＣＰＵサイドコードシーケンスは、図３のブロック３１０に示されるものと同一であってもよい。ブロック３１０に示されるように、ライン３０１のコードＭｏｖ ｒ１，［ｏｂｊ］は、変数ｒ１に共有オブジェクト１３１のｖｔａｂｌｅをロードする。ライン３０５のコード（Ｃａｌｌ＊［ｒ１＋ｏｆｆｓｅｔＦｕｎｃｔｉｏｎ］）は、共有オブジェクト１３１のＶＦ１３３−Ａなどのバーチャル関数を呼び出すものであってもよい。

ブロック２５０において、ＧＰＵ１８０などの第２プロセッサは、共有オブジェクト１３１の第１プロセッササイドのｖｔａｂｌｅポインタ（ＣＰＵサイドｖｔａｂｌｅポインタ）を利用して、第２プロセッササイドテーブル（ＧＰＵテーブル）が存在する場合、第２プロセッササイドｖｔａｂｌｅ（ＧＰＵサイドｖｔａｂｌｅ）を決定する。一実施例では、第２プロセッササイドテーブル（ＧＰＵテーブル）は、＜“ｃｌａｓｓＮａｍｅ”，ｆｉｒｓｔ ｐｒｏｃｅｓｓｏｒ ｓｉｄｅ ｖｔａｂｌｅ ａｄｄｒｅｓｓ，ｓｅｃｏｎｄ ｐｒｏｃｅｓｓｏｒ ｓｉｄｅ ｖｔａｂｌｅ ａｄｄｒｅｓｓ＞を含むものであってもよい。

一実施例では、ＧＰＵサイドにおいて、ＧＰＵ１８０は、ブロック３１０に示されるコードシーケンスと異なるものであってもよいブロック３５０に示されるコードシーケンスを生成するものであってもよい。一実施例では、ＧＰＵコンパイラ１８８はタイプからすべての共有可能なクラスを認識しているため、ＧＰＵ１８０は、共有オブジェクト１３１などの共有オブジェクトからバーチャル関数ポインタをロードするため、ブロック３５０に示されるコードシーケンスを生成可能である。一実施例では、ライン３５１のコードＭｏｖ ｒ１，［ｏｂｊ］はＣＰＵのｖｔａｂｌｅ ａｄｄｒをロードし、ライン３５３のコードＲ２＝ｇｅｔＶｔａｂｌｅＡｄｄｒｅｓｓ（ｒ１）は、ＧＰＵテーブルからＧＰＵｖｔａｂｌｅを取得してもよい。一実施例では、ライン３５８のコード（Ｃａｌｌ＊［ｒ２＋ｏｆｆｓｅｔＦｕｎｃｔｉｏｎ］）は、ＣＰＵｖｔａｂｌｅアドレスを用いて生成されるＧＰＵｖｔａｂｌｅに基づきバーチャル関数をコールしてもよい。一実施例では、ｇｅｔＶｔａｂｌｅＡｄｄｒｅｓｓ関数は、ＣＰＵサイドｖｔａｂｌｅアドレスを用いて、ＧＰＵサイドｖｔａｂｌｅを決定するためにＧＰＵテーブルにインデックス化するようにしてもよい。

ブロック２８０において、第１プロセッサ（ＣＰＵ１１０）及び第２プロセッサ（ＧＰＵ１８０）は、共有オブジェクト１３１を用いた双方向通信のため可能とされてもよい。

図４のフローチャートを用いてＧＰＵテーブルを生成する実施例が説明される。ブロック４１０において、テーブルは、一実施例では、共有可能なクラス（共有オブジェクト１３１）のレジストレーション関数への関数ポインタを初期化セクション（ＭＳ Ｃ＋＋のためのＣＲＴ＄ＸＣＩセクションなど）に含めることによって、初期化時間中に生成可能である。例えば、共有可能クラスのレジストレーション関数は、ＭＳ ＣＲＴ＄ＸＣＩセクションの初期化セクションに含まれてもよい。

ブロック４２０において、レジストレーション関数は、初期化時間中に実行されてもよい。レジストレーション関数への関数ポインタを初期化セクションに含めた結果として、レジストレーション関数は、初期化セクションの実行中に実行されてもよい。

ブロック４３０において、第１プロセッササイド（ＣＰＵサイド）上で、レジストレーション関数は、“ｃｌａｓｓＮａｍｅ”及び“ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ”を第１テーブルに登録する。ブロック４４０において、第２プロセッササイド（ＧＰＵサイド）上で、レジストレーション関数は、“ｃｌａｓｓＮａｍｅ”及び“ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ”を第２テーブルに登録する。

ブロック４８０において、第１テーブルと第２テーブルとが、１つの共通のテーブルにマージされる。例えば、第１テーブルと第２テーブルとが同一の“ｃｌａｓｓＮａｍｅ”を有する場合、第１テーブルの第１エントリは、第２テーブルの第１エントリと合成されてもよい。マージの結果として、第１テーブルと第２テーブルの合成されたエントリは、単一のｃｌａｓｓＮａｍｅを有する１つのエントリとして現れる。一実施例では、共通のテーブルはＧＰＵサイドにあり、共通のテーブル又はＧＰＵテーブルは、“ｃｌａｓｓＮａｍｅ”、ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ及びＧＰＵ ｖｔａｂｌｅ ａｄｄｒを含むものであってもよい。

一実施例では、共通のテーブル又はＧＰＵテーブルの作成は、ＣＰＵサイド及びＧＰＵサイドにおけるｖｔａｂｌｅアドレスを一致させる要求を回避してもよい。また、ＧＰＵテーブルは、ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）をサポートしてもよい。一実施例では、クラスは、共有オブジェクト１３１がＧＰＵサイドにおいて初期化又は利用される前に、ＣＰＵサイドにロードされてもよい。しかしながら、アプリケーションはＣＰＵサイドに一般にロードされるため、ＧＰＵテーブルは、アプリケーション及びＳＬＬ（Ｓｔａｔｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）に規定されるクラスについて、ＣＰＵ１１０とＧＰＵ１８０との間の双方向通信を可能にする。ＤＬＬについて、ＤＬＬはＣＰＵサイドにロードされ、ＧＰＵテーブルはＤＬＬの双方向通信に利用されてもよい。

共有可能なオブジェクト１３１は、ＣＰＵサイドｖｔａｂｌｅを有し、ＧＰＵサイドｖｔａｂｌｅのための余分なｖｔａｂｌｅポインタを有さなくてもよい。一実施例では、インオブジェクトＣＰＵ ｖｔａｂｌｅポインタを利用して、ＧＰＵ ｖｔａｂｌｅポインタは、ブロック３５０及び図４に示されるように生成されてもよい。一実施例では、ＧＰＵサイドでＧＰＵ ｖｔａｂｌｅポインタがバーチャル関数コールのために利用される間、ＣＰＵサイドのＣＰＵ ｖｔａｂｌｅポインタは、そのまま利用されてもよい。一実施例では、そのようなアプローチは、リンカ／ローダの変更又は関与を伴わず、共有オブジェクト１３１の余分なｖｐｔｒポインタフィールドを要求しない。このようなアプローチは、ＣＰＵ１１０とＧＰＵ１８０との間のオブジェクト指向言語により記述されたアプリケーションの詳細な分割を可能にする。

図５において、ヘテロジニアスプロセッサにより共有されるオブジェクトのメンバ関数を介しＣＰＵ１１０とＧＰＵ１８０との間の双方向通信をサポートするため、計算プラットフォーム１００により利用されるフロー図の実施例が示される。一実施例では、ＧＰＵコンパイラ１８８は、ＧＰＵ関数のためのＣＰＵスタブ５１０と、ＣＰＵサイド１１０上のＣＰＵリモートコールＡＰＩ５２０とを生成する。また、ＧＰＵコンパイラ１８８は、第１メンバ関数のためのＧＰＵサイド１８０のＧＰＵ関数のためのＧＰＵサイドグルーイングロジック（ｇｌｕｉｎｇ ｌｏｇｉｃ）５３０を生成する。一実施例では、ＣＰＵ１１０は、第１パスの第１イネーブリングパス（スタブロジック５１０、ＡＰＩ５２０及びグルーイングロジック５３０を有する）を用いて、第１メンバ関数へのコールを生成してもよい。一実施例では、第１イネーブリングパスは、ＣＰＵ１１０がＧＰＵサイド１８０とのリモートコールを確立し、ＣＰＵサイド１１０からＧＰＵサイド１８０に情報を伝送することを可能にする。一実施例では、ＧＰＵサイドグルーイングロジック５３０は、ＧＰＵ１８０がＣＰＵサイド１１０から伝送される情報を受信することを可能にする。

一実施例では、ＣＰＵスタブ５１０は、第１メンバ関数（すなわち、オリジナルＧＰＵメンバ関数）と同じ名前を有するが、ＣＰＵ１１０からのコールをＧＰＵ１８０に導くため、ＡＰＩ５２０を含むものであってもよい。一実施例では、ＣＰＵコンパイラ１１８により生成されるコードは、第１メンバ関数をそのままコールするが、当該コールはＣＰＵスタブ５１０及びリモートコールＡＰＩ５２０にリダイレクトされてもよい。また、リモートコールの作成中、ＣＰＵスタブ５１０は、第１メンバ関数がコールされていることを表す一意的な名前、共有オブジェクトへのポインタ、及びコールされた第１メンバ関数の他の引数を送信してもよい。一実施例では、ＧＰＵサイドのグルーイングロジック５３０は、引数を受信し、第１メンバ関数コールをディスパッチする。一実施例では、ＧＰＵコンパイラ１８８は、第１パラメータとしてわたされたオブジェクトポインタにより第１メンバ関数のＧＰＵサイド関数アドレスをコールすることによって、非バーチャル関数をディスパッチするグルーイングロジック（又はディスパッチャ）を生成する。一実施例では、ＧＰＵコンパイラ１８８は、ＣＰＵスタブ５１０がＧＰＵサイドのグルーイングロジック５３０と通信することを可能にするため、ＧＰＵサイドグルーイングロジック５３０を登録するためＧＰＵサイドにおいてジャンプテーブルレジストレーションコールを生成する。

一実施例では、ＧＰＵコンパイラ１８８は、ＣＰＵ関数のためのＧＰＵスタブ５５０、ＧＰＵサイド１８０上のＧＰＵリモートコールＡＰＩ５７０及びＣＰＵ１１０に配分された第２メンバ関数のためのＣＰＵサイドグルーイングロジック５８０を有する第２イネーブリングパスを生成する。一実施例では、ＧＰＵ１８０は、第２イネーブリングパスを用いてＣＰＵサイド１１０に対するコールを作成する。一実施例では、ＧＰＵスタブ５６０及びＡＰＩ５７０は、ＧＰＵ１８０がＣＰＵサイド１１０とのリモートコールを確立し、ＧＰＵサイド１８０からの情報をＣＰＵサイド１１０に伝送することを可能にする。一実施例では、ＣＰＵサイドグルーイングロジック５８０は、ＣＰＵ１１０がＧＰＵサイド１８０から伝送された情報を受信することを可能にする。

一実施例では、第２メンバ関数コールをサポートするため、ＧＰＵコンパイラ１８８は、ＣＰＵサイドグルーイングロジック５８０のためのジャンプテーブルレジストレーションを生成する。一実施例では、第２メンバ関数のＣＰＵサイド関数アドレスが、ＣＰＵグルーイングロジック５８０においてコールされる。一実施例では、ＣＰＵグルーイングロジック５８０により生成されるコードは、ＣＰＵコンパイラ１１８により生成される他のコードとリンクされてもよい。このようなアプローチは、ヘテロジニアスプロセッサ１１０と１８０との間の双方向通信をサポートするためのパスを提供する。一実施例では、ＣＰＵスタブロジック５１０及びＣＰＵサイドグルーイングロジック５８０は、ＣＰＵリンカ５９０を介しＣＰＵ１１０に接続されてもよい。一実施例では、ＣＰＵリンカ５９０は、ＣＰＵスタブ５１０、ＣＰＵサイドグルーイングロジック５８０及びＣＰＵコンパイラ１１８により生成される他のコードを用いて、ＣＰＵエグゼキュータブル（ＣＰＵ ｅｘｅｃｕｔａｂｌｅ）５９５を生成する。一実施例では、ＧＰＵスタブロジック５６０及びＧＰＵサイドグルーイングロジック５７０は、ＧＰＵリンカ５４０を介しＧＰＵ１８０に接続される。一実施例では、ＧＰＵリンカ５４０は、ＧＰＵグルーイングロジック５７０、ＧＰＵスタブ５６０及びＧＰＵコンパイラ１８８により生成される他のコードを用いて、ＧＰＵエグゼキュータブル（ＧＰＵ ｅｘｅｃｕｔａｂｌｅ）５４５を生成する。

図６において、上述したテーブルベース技術を用いてＧＰＵバーチャル関数とＧＰＵ非バーチャル関数とがＣＰＵサイド１１０によりコールされるフロー図６００の実施例が示される。ブロック６１０は、バーチャル関数（例えば、ＶＦ１３３−Ａなど）とバーチャル関数コール“Ｖｉｒｔｕａｌ ｖｏｉｄ ＳｏｍｅＶｉｒｔＦｕｎｃ（）”とを注釈付けする第１アノテーションタグ＃Ｐｒａｇｍａ ＧＰＵと、非バーチャル関数（例えば、ＮＶＦ１３６−Ａなど）と非バーチャル関数コール“ｖｏｉｄ ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”とを注釈付けする第２アノテーションタグ＃Ｐｒａｇｍａ ＧＰＵとを含む共有クラスインスタンス又は共有クラスＦｏｏ（）のタイトルのオブジェクトを有して示される。

一実施例では、“ｐＦｏｏ”は、クラスＦｏｏ（）の共有オブジェクト１３１を指定し、ＣＰＵサイド１１０からＧＰＵサイド１８０へのリモートバーチャル関数コールが完了する。一実施例では、“ｐＦｏｏ（）＝ｎｅｗ（Ｓｈａｒｅｄ ＭｅｍｏｒｙＡｌｌｏｃａｔｏｒ（））Ｆｏｏ（）；”は、共有されたメモリ割当て／リリースランタイムコールにより新たなオペレータを上書き又は削除するための１つの可能な方法である。一実施例では、ＣＰＵコンパイラ１１８は、ブロック６１０における“ｐＦｏｏ→ＳｏｍｅＶｉｒｔｕＦｕｎｃ（）”のコンパイルに応答して、ブロック６２０に示されるタスクを開始する。

ブロック６２０において、ＣＰＵサイド１１０は、ＧＰＵバーチャル関数をコールする。ブロック６３０において、ＣＰＵサイドスタブ（ＧＰＵメンバ関数のための）５１０及びＡＰＩ５２０は、ＧＰＵサイド１８０に情報（引数）を送信する。ブロック６４０において、ＧＰＵサイドグルーイングロジック（ＧＰＵメンバ関数のための）５３０は、ＴＨＩＳオブジェクトからｐＧＰＵＶｐｔｒ（ＣＰＵサイドｖｔａｂｌｅポインタ）を取得し、ＧＰＵ ｖｔａｂｌｅを検出する。ブロック６５０において、ＧＰＵサイドグルーイングロジック５４０（又はディスパッチャ）は、ＣＰＵサイドｖｔａｂｌｅポインタを用いてＧＰＵサイドｖｔａｂｌｅを取得するため、上述されたブロック３５０に示されるコードシーケンスを有してもよい。

一実施例では、ブロック６１０における＃Ｐｒａｇｍａ ＧＰＵ“ｖｏｉｄ ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”のコンパイルに応答して、ＧＰＵコンパイラ１８８は、ブロック６７０に示されるタスクを開始するため、“ｐＦｏｏ→ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”を利用するためのコードを生成する。ブロック６７０において、ＣＰＵサイド１１０は、ＧＰＵ非バーチャル関数をコールする。ブロック６８０において、ＣＰＵサイドスタブ５１０及びＡＰＩ５２０は、ＧＰＵサイド１８０に情報（引数）を送信する。ブロック６９０において、ＧＰＵサイドグルーイングロジック５３０は、パラメータをプッシュし、関数のアドレスが既知であるとき、直接アドレスをコールする。

図７のフローチャートにおいて、バーチャル共有非コヒーラント領域を用いてヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするため計算プラットフォーム１００により実行される処理の実施例が示される。ＣＰＵ１１０及びＧＰＵ１８０などのヘテロジニアスプロセッサを含む計算システム１００などの計算システムでは、ＣＰＵ１１０及びＧＰＵ１８０は、１１８及び１８８などの異なるコンパイラ（又は異なるターゲットを有する同一のコンパイラ）により生成される異なるコードを実行し、同一のバーチャル関数が、同一のアドレスに配置されることを保証されなくてもよい。バーチャル関数の共有をサポートするためコンパイラ／リンカ／ローダを修正可能であるが、後述される“非コヒーラント領域”アプローチ（ランタイムオンリーアプローチ）は、ＣＰＵ１１０とＧＰＵ１８０との間のバーチャル関数の共有を可能にするためのよりシンプルな技術である。このようなアプローチは、Ｍｉｎｅ／Ｙｏｕｒｓ／Ｏｕｒｓ（ＭＹＯ）などの共有されたバーチャルメモリシステムが容易に受け入れられ、配置されることを可能にする。Ｃ＋＋オブジェクト指向言語が一例として利用されるが、以下のアプローチは、バーチャル関数をサポートする他のオブジェクト指向プログラミング言語に適用可能であってもよい。

ブロック７１０において、ＣＰＵ１１０は、ＣＰＵ１１０とＧＰＵ１８０との共有クラスのｖｔａｂｌｅを格納するため、共有バーチャルメモリ１３０内に共有非コヒーラント領域を生成する。一実施例では、共有非コヒーラント領域は、共有バーチャルメモリ１３０内の領域への非コヒーラントタグを指定することによって生成されてもよい。一実施例では、ＭＹＯランタイムは、バーチャル共有領域（ＭＹＯの用語では“アリーナ”と呼ばれ、このような多数のアリーナがＭＹＯにおいて生成されてもよい）を生成するため、１以上のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｆａｃｅ）関数を提供する。例えば、ｍｙｏＡｒｅｎａＣｒｅａｔｅ（ｘｘｘ，．．．，ＮｏｎＣｏｈｅｒｅｎｔＴａｇ）又はｍｙｏＡｒｅｎａＣｒｅａｔｅＮｏｎＣｏｈｅｒｅｎｔＴａｇ（ｘｘｘ，．．．）が利用されてもよい。一実施例では、上記タグの利用は、コヒーラントアリーナ又は非コヒーラントアリーナを生成する。しかしながら、他の実施例では、ＡＰＩ関数は、メモリチャンク（又は部分）の性質を変更するのに利用されてもよい。例えば、ｍｙｏＣｈａｎｇｅＴｏＮｏｎＣｏｈｅｒｅｎｔ（ａｄｄｒ ｓｉｚｅ）は、非コヒーラント領域又はアリーナとして第１領域を生成し、コヒーラントアリーナとして第２領域（又は部分）を生成するのに利用されてもよい。一実施例では、第１領域はアドレスサイズにより指定されてもよい。

一実施例では、データ一貫性を維持することなくデータ共有を可能にするメモリアリーナ（すなわち、管理されたメモリチャンク）が生成され、このようなメモリアリーナは、共有非コヒーラント領域と呼ばれてもよい。一実施例では、共有非コヒーラント領域に格納されているＣＰＵデータ及びＧＰＵデータは、ＣＰＵ１１０とＧＰＵ１８０との双方により観察されるような同一のアドレスを有してもよい。しかしながら、ＭＹＯなどの共有バーチャルメモリ１３０がランタイム時に一貫性を維持しなくてもよいため、コンテンツ（ＣＰＵデータ及びＧＰＵデータ）は異なるものであってもよい。一実施例では、共有非コヒーラント領域は、各共有クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、ＣＰＵ１１０及びＧＰＵ１８０から観察されるようなバーチャル関数テーブルアドレスは同一であってもよく、しかしながら、バーチャル関数テーブルは異なるものであってもよい。

ブロック７５０において、初期化時間中、共有可能な各クラスのｖｔａｂｌｅは、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５から共有バーチャルメモリ１３０にコピーされる。一実施例では、ＣＰＵサイドｖｔａｂｌｅは、共有バーチャルメモリ１３０内の非コヒーラント領域にコピーされ、ＧＰＵサイドｖｔａｂｌｅはまた、共有バーチャルメモリ１３０内の非コヒーラント領域にコピーされてもよい。一実施例では、共有スペースにおいて、ＣＰＵサイドｖｔａｂｌｅ及びＧＰＵサイドｖｔａｂｌｅは、同一アドレスに配置されてもよい。

一実施例では、ツールチェーンサポートが利用可能である場合、ＣＰＵコンパイラ１１８又はＧＰＵコンパイラ１８８は、特別なデータセクションにおいてＣＰＵ及びＧＰＵｖｔａｂｌｅデータを有してもよく、ローダ５４０又は５７０は、共有非コヒーラント領域に特別なデータセクションをロードする。他の実施例では、ＣＰＵコンパイラ１１８又はＧＰＵコンパイラ１８８は、例えば、ｍｙｏＣｈａｎｇｅＴｏＮｏｎＣｏｈｅｒｅｎｔなどのＡＰＩコールなどを用いて、特別なデータセクションが共有非コヒーラント領域に生成されることを可能にする。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅが特別なデータセクション内の同一のオフセットアドレスに配置されることを保証してもよい（存在しない場合には、適切なパディングによって）。一実施例では、多重継承の場合、オブジェクトレイアウトに複数のｖｔａｂｌｅポインタがあってもよい。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８はまた、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅポインタがオブジェクトレイアウトにおいて同一のオフセットに配置されることを保証するようにしてもよい。

ツールチェーンサポートがない場合、一実施例では、ユーザは、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを共有非コヒーラント領域にコピーすることが可能とされてもよい。一実施例では、１以上のマクロが、ＣＰＵ及びＧＰＵテーブルを共有非コヒーラントメモリ領域に手動によりコピーすることを容易にするため生成される。

ランタイム時、共有オブジェクト１３１などの共有オブジェクトが生成された後、多重継承のために複数の“ｖｐｔｒ”を有するオブジェクトレイアウト８０１が生成される。一実施例では、オブジェクトテーブル８０１の共有オブジェクト１３１のバーチャルテーブルポインタ（ｖｐｔｒ）は、共有非コヒーラント領域におけるバーチャル関数テーブルの新たなコピーを指定するため更新（パッチ）される。一実施例では、共有オブジェクトのバーチャルテーブルポインタは、バーチャル関数を含むクラスのコンストラクタを用いて更新される。一実施例では、クラスがバーチャル関数を有さない場合、当該クラスのデータ及び関数が共有され、ランタイム中に更新（又はパッチ）する必要はない。

ブロック７８０において、ｖｐｔｒ（ｖｔａｂｌｅポインタ）は、共有オブジェクト１３１を作成しながら、共有非コヒーラント領域を示すよう変更される。一実施例では、デフォルトによりプライベートなｖｔａｂｌｅ（ＣＰＵ ｖｔａｂｌｅ又はＧＰＵ ｖｔａｂｌｅ）を示すｖｐｔｒは、共有非コヒーラント領域８６０を示すよう変更される（図８の実線８０２−Ｃにより示されるように）。一実施例では、バーチャル関数は以下のようにコールされてもよい。

Ｍｏｖ ｅａｘ，［ｅｃｘ］ ＃ｅｃｘは“ｔｈｉｓ”ポインタを含み、ｅａｘはｖｐｔｒを含む
Ｃａｌｌ［ｅａｘ，ｖｆｕｎｃ］ ＃ｖｆｕｎｃはバーチャル関数テーブルにおけるバーチャル関数インデックスである
ＣＰＵサイドにおいて、上記コードはバーチャル関数のＣＰＵの実装をコールし、ＧＰＵサイドでは、上記コードはバーチャル関数のＧＰＵ実装をコールしてもよい。このようなアプローチは、クラスに対するデータ共有及びバーチャル関数共有を可能にする。

図８において、ヘテロジニアスプロセッサの間のバーチャル関数共有をサポートするためのバーチャル共有非コヒーラント領域の利用を示す関係図８００の実施例が示される。一実施例では、オブジェクトレイアウト８０１は、第１スロット８０１−Ａのバーチャルテーブルポインタ（ｖｐｔｒ）と、スロット８０１−Ｂ及び８０１−Ｃのフィールド１及びフィールド２などの他のフィールドとを含む。一実施例では、以降に、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、スロット８０１−Ａに配置されるｖｔａｂｌｅポインタ（ｖｐｔｒ）を実行し、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅ（破線８０２−Ｂに示されるように）を生成する（破線８０２−Ａに示されるように）。ＣＰＵバーチャル関数テーブル（ＣＰＵ ｖｔａｂｌｅ）は、ＣＰＵプライベートアドレススペース１１５内のアドレス８１０に配置され、ＧＰＵ ｖｔａｂｌｅは、ＧＰＵプライベートアドレススペース１８５内のアドレス８４０に配置されてもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１及びｖｆｕｎｃ２などの関数ポインタを含み、ＧＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１’及びｖｆｕｎｃ２’などの関数ポインタを含むようにしてもよい。一実施例では、関数ポインタ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）及び（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）はまた、これらのポインタが同一の関数の異なる実装を指定するとき、異なるものであってもよい。

一実施例では、ｖｐｔｒを変更した結果として（ブロック７８０に示されるように）、ｖｐｔｒは、共有バーチャルメモリ１３０内の共有非コヒーラント領域８６０を指示する。一実施例では、ＣＰＵ ｖｔａｂｌｅはアドレスＡｄｄｒｅｓｓ ８７０に配置され、ＧＰＵ ｖｔａｂｌｅは同一アドレスＡｄｄｒｅｓｓ ８７０に配置されてもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１及びｖｆｕｎｃ２などの関数ポインタを含み、ＧＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１’及びｖｆｕｎｃ２’などの関数ポインタを含むものであってもよい。一実施例では、関数ポインタ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）及び（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）は異なるものであってもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを共有非コヒーラント領域８６０に保存することは、ＣＰＵ１１０及びＧＰＵ１８０がそれぞれ同一のアドレス位置Ａｄｄｒｅｓｓ ８７０にＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを参照することを可能にするが、ＣＰＵ ｖｔａｂｌｅのコンテンツ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）は、ＧＰＵ ｖｔａｂｌｅのコンテンツ（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）と異なるものであってもよい。

図９において、双方向通信をサポートするヘテロジニアスプロセッサを有するコンピュータシステム９００の実施例が示される。図９を参照すると、コンピュータシステム９００は、ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）プロセッサとＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）９０５とを含む汎用プロセッサ（又はＣＰＵ）９０２を有する。一実施例では、ＣＰＵ９０２は、マシーン可読記憶媒体９２５にエンハンスメント処理を提供するため、他の各種タスクの実行又は命令シーケンスの格納に加えて、エンハンスメント処理を実行する。しかしながら、命令シーケンスはまた、ＣＰＵプライベートメモリ９２０又は他の何れか適切な記憶媒体に格納されてもよい。一実施例では、ＣＰＵ９０２は、ＣＰＵレガシコンパイラ９０３及びＣＰＵリンカ／ローダ９０４に関連付けされてもよい。一実施例では、ＧＰＵ９０５は、ＧＰＵ専用コンパイラ９０６及びＧＰＵリンカ／ローダ９０７に関連付けされてもよい。

図９では独立したＧＰＵ９０５が示されるが、いくつかの実施例では、プロセッサ９０２は、他の例としてエンハンスメント処理を実行するのに利用されてもよい。コンピュータシステム９００を処理するプロセッサ９０２は、ロジック９３０に接続された１以上のプロセッサコアであってもよい。ロジック９３０は、コンピュータシステム９００とのインタフェースを提供する１以上のＩ／Ｏデバイス９６０に接続されてもよい。例えば、ロジック９３０は、一実施例では、チップセットロジックとすることができる。ロジック９３０は、光、磁気又は半導体ストレージを含む何れかのタイプのストレージとすることが可能なメモリ９２０に接続される。グラフィックプロセッサユニット９０５は、フレームバッファを介しディスプレイ９４０に接続される。

一実施例では、コンピュータシステム９００は、共有オブジェクトを詳細に分割することによって、共有オブジェクトのバーチャル関数などのメンバ関数を介しヘテロジニアスプロセッサＣＰＵ９０２とＧＰＵ９０５との間の双方向通信（関数コール）を可能にするための１以上の技術をサポートする。一実施例では、コンピュータシステム９００は、“テーブルベース”技術と呼ばれる第１技術を用いて、ＣＰＵ９０２とＧＰＵ９０５との間の双方向通信を可能にする。他の実施例では、計算プラットフォームは、バーチャル共有非コヒーラント領域がプライベートＣＰＵメモリ９２０、プライベートＧＰＵメモリ９３０又は共有メモリ９５０の何れかに配置されるバーチャル共有メモリに作成される“非コヒーラント領域”技術と呼ばれる第２技術を利用して、ＣＰＵ９０２とＧＰＵ９０５との間の双方向通信を可能にする。一実施例では、共有メモリ９５０などの独立した共有メモリはコンピュータシステム９００に設けられなくてもよく、このような場合、共有メモリは、ＣＰＵメモリ９２０又はＧＰＵメモリ９３０などのプライベートメモリの１つに設けられてもよい。

一実施例では、テーブルベース技術を利用しながら、ＣＰＵ１１０又はＧＰＵ１８０から共有オブジェクトにアクセスするのに利用される共有オブジェクトのＣＰＵサイドｖｔａｂｌｅポインタが、ＧＰＵサイドテーブルが存在する場合、ＧＰＵ ｖｔａｂｌｅを決定するのに利用されてもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅは、＜“ｃｌａｓｓＮａｍｅ”，ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ，ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ＞を含むものであってもよい。一実施例では、ＧＰＵサイドのｖｔａｂｌｅアドレスを取得し、ＧＰＵサイドテーブルを生成するための技術が上述された。

他の実施例では、“非コヒーラント領域”技術を利用しながら、共有非コヒーラント領域が共有バーチャルメモリ内に作成される。一実施例では、共有非コヒーラント領域は、データ一貫性を維持しなくてもよい。一実施例では、共有非コヒーラント領域内のＣＰＵサイドデータとＧＰＵサイドデータとは、ＣＰＵサイド及びＧＰＵサイドから参照されるように同一のアドレスを有してもよい。しかしながら、ＣＰＵサイドデータのコンテンツは、共有バーチャルメモリがランタイム中に一貫性を維持しないとき、ＧＰＵサイドデータのものと異なるものになってもよい。一実施例では、共有非コヒーラント領域は、各共有クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、このようなアプローチは、同一のアドレスにおいてバーチャルテーブルを維持してもよい。

ここに開示されたグラフィックス処理技術は、各種ハードウェアアーキテクチャにより実現されてもよい。例えば、グラフィックス機能は、チップセット内に統合されてもよい。あるいは、独立したグラフィックプロセッサが利用されてもよい。さらなる他の実施例として、グラフィックス関数は、マルチコアプロセッサを含む汎用プロセッサにより、又はマシーン可読媒体に格納されるソフトウェア命令セットとして実現されてもよい。

１００ 計算プラットフォーム
１１０ ＣＰＵ
１８０ ＧＰＵ
９００ コンピュータシステム

Claims (1)

1. 計算プラットフォームにおける方法であって、
   複数のバーチャル関数を含む共有オブジェクトを生成するステップと、
   前記共有オブジェクトを共有バーチャルメモリに格納するステップと、
   第１プロセッサと第２プロセッサとの間で前記複数のバーチャル関数の少なくとも１つを共有するステップと、
   を有し、
   前記計算プラットフォームは、前記第１プロセッサと前記第２プロセッサとを含み、
   前記第１プロセッサと前記第２プロセッサとはヘテロジニアスプロセッサである方法。

Images