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

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

Info

Publication number
JP5639274B2
JP5639274B2 JP2013529523A JP2013529523A JP5639274B2 JP 5639274 B2 JP5639274 B2 JP 5639274B2 JP 2013529523 A JP2013529523 A JP 2013529523A JP 2013529523 A JP2013529523 A JP 2013529523A JP 5639274 B2 JP5639274 B2 JP 5639274B2
Authority
JP
Japan
Prior art keywords
processor
shared
virtual
gpu
virtual table
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013529523A
Other languages
English (en)
Other versions
JP2013542497A (ja
Inventor
イエン，ショウムオン
ルオ，サイ
ジョウ，シヤオチュヨン
ガオ，イーン
チェン，ホゥ
サハ，ブラティン
Original Assignee
インテル コーポレイション
インテル コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by インテル コーポレイション, インテル コーポレイション filed Critical インテル コーポレイション
Publication of JP2013542497A publication Critical patent/JP2013542497A/ja
Application granted granted Critical
Publication of JP5639274B2 publication Critical patent/JP5639274B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1072—Decentralised address translation, e.g. in distributed shared memory systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/447—Target code generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G06F9/3863—Recovery, e.g. branch miss-prediction, exception handling using multiple copies of the architectural state, e.g. shadow registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Multi Processors (AREA)
  • Stored Programmes (AREA)

Description

計算プラットフォームは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、シンメトリックプロセッサとアシンメトリックプロセッサなどのヘテロジニアスプロセッサを含むかもしれない。クラスインスタンス（又はオブジェクト）は、ＣＰＵ−ＧＰＵプラットフォームの第１サイド（ＣＰＵなど）に関する第１メモリにあるかもしれない。第２サイド（ＧＰＵサイド）は、ＣＰＵ−ＧＰＵプラットフォームの第１サイド（ＣＰＵサイド）に関する第１メモリにあるオブジェクト及び関連するメンバ関数を呼び出すことが有効とされていないかもしれない。また、第１サイドは、第２サイド（ＧＰＵサイド）上の第２メモリにあるオブジェクト及び関連するメンバ関数を呼び出すことが有効とされていないかもしれない。クラスインスタンス又はオブジェクトが異なるアドレススペースに格納されているとき、既存の通信機構は、単にヘテロジニアスプロセッサ（ＣＰＵ及びＧＰＵ）の間の一方向通信がクラスインスタンス及び関連するバーチャル関数を呼び出すことしか可能にしないかもしれない。
このような一方向通信アプローチは、ヘテロジニアスプロセッサの間のクラスインスタンスの自然な機能分割を妨げる。オブジェクトは、スループット指向メンバ関数といくつかのスカラメンバ関数を有する。例えば、ゲームアプリケーションのシーンクラスは、ＧＰＵに適したレンダリング関数を有し、さらにＣＰＵ上の実行に適した物理及び人工知能（ＡＩ）関数を有するかもしれない。現在の一方向通信機構では、典型的には、ＣＰＵ（上記の例における物理及び人工知能）メンバ関数とＧＰＵ（ＧＰＵに適したレンダリング関数）メンバ関数をそれぞれ有する２つの異なるシーンクラスである必要がある。ＣＰＵのための１つとＧＰＵのための１つとの２つの異なるシーンクラスを有することは、データが２つのシーンクラスの間で互いにコピーされることを要求するかもしれない。
ここに開示される本発明が、添付した図面により限定することなく例示的に説明される。説明の簡単化のため、図面に示される要素は、必ずしもスケーリングして示されていない。例えば、いくつかの要素の大きさは、簡単化のため他の要素に対して誇張されるかもしれない。さらに、適切であると考えられる場合、対応する又は類似する要素を示す参照番号は、図面において繰り返されている。
図１は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするプラットフォーム１００を示す。 図２は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするプラットフォーム１００により実行される処理を示すフローチャートである。 図３は、一実施例による共有オブジェクトからバーチャル関数ポインタをロードするためのＣＰＵサイド及びＧＰＵサイドのコードを示す。 図４は、第１実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数の共有をサポートするためのテーブルを生成するため、プラットフォーム１００により実行される処理を示すフローチャートである。 図５は、一実施例によるヘテロジニアスプロセッサにより共有されるオブジェクトのメンバ関数を介しＣＰＵ１１０とＧＰＵ１８０との間の双方向通信をサポートするためプラットフォーム１００により利用されるフロー図を示す。 図６は、第１実施例によるＣＰＵサイドにより行われるＧＰＵバーチャル関数及びＧＰＵ関数のコールの処理を示すフロー図を示す。 図７は、一実施例によるヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするバーチャルな共有非コヒーラント領域を利用するため、プラットフォーム１００により実行される処理を示すフローチャートである。 図８は、一実施例によるヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするためバーチャル共有非コヒーラント領域の利用を示す関係図である。 図９は、一実施例によるコンピュータプラットフォームに備えられるヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数を共有するためのサポートを提供するコンピュータシステムを示す。
以下の説明は、計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリに格納されるバーチャル関数を共有するための技術を説明する。以下の説明では、ロジック実現形態、リソース分割、共有、重複実現形態、システムコンポーネントのタイプ及び相互関係、及びロジック分割若しくは統合選択などの多数の具体的詳細が、本発明のより完全な理解を提供するため提供される。しかしながら、本発明がこのような具体的詳細なしに実現可能であることは当業者に理解されるであろう。他の例では、本発明を不明りょうにしないため、制御構成、ゲートレベル回路及びフルソフトウェア命令シーケンスは、詳細には説明されない、当業者は、含まれている説明によって、過度な実験なしに適切な機能を実現可能であろう。
明細書における“一実施例”、“実施例”、“一例となる実施例”という表現は、説明された実施例が特定の特徴、構成又は特性を含むが、すべての実施例が必ずしも当該特徴、構成又は特性を含む必要がないことを示す。さらに、このような表現は、必ずしも同一の実施例を参照しているとは限らない。さらに、特定の特徴、構成又は特性が実施例に関して説明されているとき、明示的に説明されているか否かに関係なく、他の実施例に関してこのような特徴、構成又は特性に影響を与えることが当業者の知識の範囲内であることが主張される。
本発明の実施例は、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。本発明の実施例はまた、１以上のプロセッサにより読み込まれ、実行されるマシーン可読媒体に格納される命令として実現されてもよい。マシーン可読記憶媒体は、マシーン（計算装置など）により可読な形式により情報を格納又は送信するための何れかの機構を含むものであってもよい。
例えば、マシーン可読記憶媒体は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイスを含むものであってもよい。さらに、ファームウェア、ソフトウェア、ルーチン及び命令は、特定のアクションを実行するとしてここでは説明される。しかしながら、このような説明は単に便宜的なものであり、このようなアクションは実際には、計算装置、プロセッサ、コントローラ及び他の装置がファームウェア、ソフトウェア、ルーチン及び命令を実行することにより生じることが理解されるべきである。
一実施例では、計算プラットフォームは、共有されるオブジェクトを詳細に分割することによって、共有オブジェクトのバーチャル関数などのメンバ関数を介しヘテロジニアスプロセッサ（ＣＰＵとＧＰＵなど）の間の双方向通信（関数コール）を可能にするための１以上の技術をサポートするものであってもよい。一実施例では、計算プラットフォームは、“テーブルベース”技術として参照される第１技術を用いて、ＣＰＵとＧＰＵとの間の双方向通信を可能にするものであってもよい。他の実施例では、計算プラットフォームは、バーチャル共有非コヒーラント領域がバーチャル共有メモリにおいて生成される“非コヒーラント領域”技術として参照される第２技術を用いて、ＣＰＵとＧＰＵとの間の双方向通信を可能にするものであってもよい。
一実施例では、テーブルベース技術の利用中、ＣＰＵからＧＰＵサイドに共有オブジェクトにアクセスするのに利用可能な共有オブジェクトのＣＰＵサイドｖｔａｂｌｅポインタが、ＧＰＵサイドテーブルが存在する場合、ＧＰＵ ｖｔａｂｌｅを決定するのに利用されてもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅは、＜“ｃｌａｓｓＮａｍｅ”，ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ，ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ＞を含むものであってもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅアドレスを取得し、ＧＰＵサイドテーブルを生成するための技術が、以下において詳細に説明される。
他の実施例では、非コヒーラント領域技術の利用中、共有非コヒーラント領域が共有バーチャルメモリ内に生成される。一実施例では、共有非コヒーラント領域は、データ一貫性を維持しないかもしれない。一実施例では、共有非コヒーラント領域内のＣＰＵサイドデータとＧＰＵサイドデータとは、ＣＰＵサイドとＧＰＵサイドから観察されるように同一のアドレスを有してもよい。しかしながら、共有バーチャルメモリはランタイム中にコヒーレンシを維持しなくてもよいため、ＣＰＵサイドデータのコンテンツは、ＧＰＵサイドデータのものと異なるものであってもよい。一実施例では、共有非コヒーラント領域は、共有される各クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、このようなアプローチは、同一のアドレスにおいてバーチャルテーブルを維持するようにしてもよい。
図１において、ＣＰＵとＧＰＵなどのヘテロジニアスプロセッサの間で共有されるバーチャル共有メモリにおけるバーチャル関数を提供する計算プラットフォーム１００の実施例が説明される。一実施例では、プラットフォーム１００は、ＣＰＵ１１０、ＣＰＵ１１０に関連するオペレーティングシステム（ＯＳ）１１２、ＣＰＵプライベートスペース１１５、ＣＰＵコンパイラ１１８、共有バーチャルメモリ（又はマルチバージョン共有メモリ）１３０、ＧＰＵ１８０、ＧＰＵ１８０に関するオペレーティングシステム（ＯＳ）１８２、ＧＰＵプライベートスペース１８５、及びＧＰＵコンパイラ１８８を有する。一実施例では、ＯＳ１１２及びＯＳ１８２はそれぞれ、ＣＰＵ１１０及びＣＰＵプライベートスペース１１５と、ＧＰＵ１８０及びＧＰＵプライベートスペース１８５とのリソースを管理する。一実施例では、共有バーチャルメモリ１３０をサポートするため、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５、マルチバージョンデータのコピーを有する。一実施例では、メモリ一貫性を維持するため、オブジェクト１３１などのメタデータが、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５に格納されているコピーを同期するのに利用されてもよい。他の実施例では、マルチバージョンデータが、共有メモリ９５０（後述される図９の）などの物理的共有メモリに格納されてもよい。一実施例では、共有バーチャルメモリは、ヘテロジニアスプロセッサＣＰＵ１１０，ＧＰＵ１８０のＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５などの物理的なプライベートメモリスペース、又はヘテロジニアスプロセッサにより共有される共有メモリ９５０などの物理的共有メモリによりサポートされてもよい。
一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８はそれぞれ、ＣＰＵ１１０及びＧＰＵ１８０に接続されるか、又は他のプラットフォーム若しくはコンピュータシステムにリモートに備えられてもよい。ＣＰＵ１１０に関連するコンパイラ１１８は、ＣＰＵ１１０のためのコンパイルされたコードを生成し、ＧＰＵ１８０に関連するコンパイラ１８８は、ＧＰＵ１８０のためのコンパイルされたコードを生成してもよい。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、オブジェクト指向言語などのハイレベル言語によりユーザにより提供されるオブジェクトの１以上のメンバ関数をコンパイルすることによって、コンパイルされたコードを生成するようにしてもよい。一実施例では、コンパイラ１１８，１８８は、共有メモリ１３０にオブジェクトを格納し、共有オブジェクト１３１は、ＣＰＵサイド１１０又はＧＰＵサイド１８０に配分されたメンバ関数を有してもよい。一実施例では、共有メモリ１３０に格納されている共有オブジェクト１３１は、バーチャル関数ＶＦ１３３−Ａ〜１３３−Ｋや非バーチャル関数ＮＶＦ１３６−Ａ〜１３６−Ｌなどのメンバ関数を有してもよい。一実施例では、ＣＰＵ１１０とＧＰＵ１８０との間の双方向通信は、共有オブジェクト１３１のＶＦ１３３やＮＶＦ１３６などのメンバ関数により提供されてもよい。
一実施例では、動的なバインディング目標を達成するため、ＶＦ１３３−Ａ（例えば、Ｃ＋＋バーチャル関数など）などのバーチャル関数が、バーチャル関数テーブル（ｖｔａｂｌｅ）をインデックス化することを介し、ＣＰＵ１１０又はＧＰＵ１８０によりコールされてもよい。一実施例では、バーチャル関数テーブルは、共有オブジェクト１３１の隠しポインタにより示されてもよい。しかしながら、ＣＰＵ１１０及びＧＰＵ１８０は、異なる命令セットアーキテクチャ（ＩＳＡ）を有してもよく、異なるＩＳＡを有するＣＰＵ１１０，ＧＰＵ１８０に対して関数がコンパイルされている間、コンパイラ１１８，１８８によりコンパイルされる同一の関数を表すコードは、異なるサイズを有してもよい。同じ方法によりＧＰＵサイドとＣＰＵサイド上でコードをレイアウトすることは困難であるかもしれない（すなわち、共有クラスのバーチャル関数のＣＰＵバージョンと、共有クラスの同一のバーチャル関数のＧＰＵバージョン）。共有クラスＦｏｏ（）に３つのバーチャル関数がある場合、コードのＣＰＵバージョンでは、関数はアドレスＡ１，Ａ２，Ａ３に配置されてもよい。しかしながら、コードのＧＰＵバージョンでは、関数は、Ａ１，Ａ２，Ａ３と異なるものであってもよいアドレスＢ１，Ｂ２，Ｂ３に配置されてもよい。共有クラスにおける同一の関数のためのＣＰＵサイドとＧＰＵサイドとの異なるアドレス位置は、共有オブジェクト（すなわち、共有クラスのインスタンス）が２つのｖｔａｂｌｅ（第１ｖｔａｂｌｅ及び第２ｖｔａｂｌｅ）を要求するかもしれない。第１ｖｔａｂｌｅは、関数のＣＰＵサイドバージョンのアドレス（Ａ１，Ａ２，Ａ３）を有し、オブジェクトがＣＰＵサイドにおいて利用されている間（又はＣＰＵサイド関数を呼び出すため）、利用されてもよい。第２ｖｔａｂｌｅは、関数のＧＰＵバージョンのアドレス（Ｂ１，Ｂ２，Ｂ３）を有し、第２ｖｔａｂｌｅは、オブジェクトがＧＰＵサイドにおいて利用されている間（又はＧＰＵサイド関数を呼び出すため）、利用されてもよい。
一実施例では、ＣＰＵ１１０とＧＰＵ１８０との間で共有されるバーチャルメモリに格納されているバーチャル関数の共有は、第１及び第２ｖｔａｂｌｅを共有オブジェクト１３１に関連付けることによって可能とされてもよい。一実施例では、ＣＰＵサイドとＧＰＵサイドとの双方においてバーチャル関数コールに利用可能な共通のｖｔａｂｌｅが、共有オブジェクト１３１の第１及び第２ｖｔａｂｌｅを関連付けることによって生成されてもよい。
図２のフローチャートにおいて、共有バーチャルメモリに格納されているバーチャル関数を共有するヘテロジニアスプロセッサＣＰＵ１１０，ＧＰＵ１８０の実施例が示される。ブロック２１０において、ＣＰＵ１１０などの第１プロセッサは、共有オブジェクト１３１の第１プロセッササイドｖｔａｂｌｅポインタ（ＣＰＵサイドｖｔａｂｌｅポインタ）を特定する。一実施例では、ＣＰＵサイドｖｔａｂｌｅポインタは、共有オブジェクト１３１がＣＰＵサイド又はＧＰＵサイドによりアクセスされるか否かに関係なく、共有オブジェクト１３１について存在してもよい。
一実施例では、ＣＰＵ専用環境などの計算システムにおける通常のバーチャル関数コールについて、コードシーケンスが、図３のブロック３１０において示される。一実施例では、ヘテロジニアスプロセッサを含む１００などの計算システムにおいてさえ、通常のバーチャル関数コールのＣＰＵサイドコードシーケンスは、図３のブロック３１０に示されるものと同一であってもよい。ブロック３１０に示されるように、ライン３０１のコードＭｏｖ ｒ１，［ｏｂｊ］は、変数ｒ１に共有オブジェクト１３１のｖｔａｂｌｅをロードする。ライン３０５のコード（Ｃａｌｌ＊［ｒ１＋ｏｆｆｓｅｔＦｕｎｃｔｉｏｎ］）は、共有オブジェクト１３１のＶＦ１３３−Ａなどのバーチャル関数を呼び出すものであってもよい。
ブロック２５０において、ＧＰＵ１８０などの第２プロセッサは、共有オブジェクト１３１の第１プロセッササイドのｖｔａｂｌｅポインタ（ＣＰＵサイドｖｔａｂｌｅポインタ）を利用して、第２プロセッササイドテーブル（ＧＰＵテーブル）が存在する場合、第２プロセッササイドｖｔａｂｌｅ（ＧＰＵサイドｖｔａｂｌｅ）を決定する。一実施例では、第２プロセッササイドテーブル（ＧＰＵテーブル）は、＜“ｃｌａｓｓＮａｍｅ”，ｆｉｒｓｔ ｐｒｏｃｅｓｓｏｒ ｓｉｄｅ ｖｔａｂｌｅ ａｄｄｒｅｓｓ，ｓｅｃｏｎｄ ｐｒｏｃｅｓｓｏｒ ｓｉｄｅ ｖｔａｂｌｅ ａｄｄｒｅｓｓ＞を含むものであってもよい。
一実施例では、ＧＰＵサイドにおいて、ＧＰＵ１８０は、ブロック３１０に示されるコードシーケンスと異なるものであってもよいブロック３５０に示されるコードシーケンスを生成するものであってもよい。一実施例では、ＧＰＵコンパイラ１８８はタイプからすべての共有可能なクラスを認識しているため、ＧＰＵ１８０は、共有オブジェクト１３１などの共有オブジェクトからバーチャル関数ポインタをロードするため、ブロック３５０に示されるコードシーケンスを生成可能である。一実施例では、ライン３５１のコードＭｏｖ ｒ１，［ｏｂｊ］はＣＰＵのｖｔａｂｌｅ ａｄｄｒをロードし、ライン３５３のコードＲ２＝ｇｅｔＶｔａｂｌｅＡｄｄｒｅｓｓ（ｒ１）は、ＧＰＵテーブルからＧＰＵｖｔａｂｌｅを取得してもよい。一実施例では、ライン３５８のコード（Ｃａｌｌ＊［ｒ２＋ｏｆｆｓｅｔＦｕｎｃｔｉｏｎ］）は、ＣＰＵｖｔａｂｌｅアドレスを用いて生成されるＧＰＵｖｔａｂｌｅに基づきバーチャル関数をコールしてもよい。一実施例では、ｇｅｔＶｔａｂｌｅＡｄｄｒｅｓｓ関数は、ＣＰＵサイドｖｔａｂｌｅアドレスを用いて、ＧＰＵサイドｖｔａｂｌｅを決定するためにＧＰＵテーブルにインデックス化するようにしてもよい。
ブロック２８０において、第１プロセッサ（ＣＰＵ１１０）及び第２プロセッサ（ＧＰＵ１８０）は、共有オブジェクト１３１を用いた双方向通信のため可能とされてもよい。
図４のフローチャートを用いてＧＰＵテーブルを生成する実施例が説明される。ブロック４１０において、テーブルは、一実施例では、共有可能なクラス（共有オブジェクト１３１）のレジストレーション関数への関数ポインタを初期化セクション（ＭＳ Ｃ＋＋のためのＣＲＴ＄ＸＣＩセクションなど）に含めることによって、初期化時間中に生成可能である。例えば、共有可能クラスのレジストレーション関数は、ＭＳ ＣＲＴ＄ＸＣＩセクションの初期化セクションに含まれてもよい。
ブロック４２０において、レジストレーション関数は、初期化時間中に実行されてもよい。レジストレーション関数への関数ポインタを初期化セクションに含めた結果として、レジストレーション関数は、初期化セクションの実行中に実行されてもよい。
ブロック４３０において、第１プロセッササイド（ＣＰＵサイド）上で、レジストレーション関数は、“ｃｌａｓｓＮａｍｅ”及び“ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ”を第１テーブルに登録する。ブロック４４０において、第２プロセッササイド（ＧＰＵサイド）上で、レジストレーション関数は、“ｃｌａｓｓＮａｍｅ”及び“ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ”を第２テーブルに登録する。
ブロック４８０において、第１テーブルと第２テーブルとが、１つの共通のテーブルにマージされる。例えば、第１テーブルと第２テーブルとが同一の“ｃｌａｓｓＮａｍｅ”を有する場合、第１テーブルの第１エントリは、第２テーブルの第１エントリと合成されてもよい。マージの結果として、第１テーブルと第２テーブルの合成されたエントリは、単一のｃｌａｓｓＮａｍｅを有する１つのエントリとして現れる。一実施例では、共通のテーブルはＧＰＵサイドにあり、共通のテーブル又はＧＰＵテーブルは、“ｃｌａｓｓＮａｍｅ”、ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ及びＧＰＵ ｖｔａｂｌｅ ａｄｄｒを含むものであってもよい。
一実施例では、共通のテーブル又はＧＰＵテーブルの作成は、ＣＰＵサイド及びＧＰＵサイドにおけるｖｔａｂｌｅアドレスを一致させる要求を回避してもよい。また、ＧＰＵテーブルは、ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）をサポートしてもよい。一実施例では、クラスは、共有オブジェクト１３１がＧＰＵサイドにおいて初期化又は利用される前に、ＣＰＵサイドにロードされてもよい。しかしながら、アプリケーションはＣＰＵサイドに一般にロードされるため、ＧＰＵテーブルは、アプリケーション及びＳＬＬ（Ｓｔａｔｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）に規定されるクラスについて、ＣＰＵ１１０とＧＰＵ１８０との間の双方向通信を可能にする。ＤＬＬについて、ＤＬＬはＣＰＵサイドにロードされ、ＧＰＵテーブルはＤＬＬの双方向通信に利用されてもよい。
共有可能なオブジェクト１３１は、ＣＰＵサイドｖｔａｂｌｅを有し、ＧＰＵサイドｖｔａｂｌｅのための余分なｖｔａｂｌｅポインタを有さなくてもよい。一実施例では、インオブジェクトＣＰＵ ｖｔａｂｌｅポインタを利用して、ＧＰＵ ｖｔａｂｌｅポインタは、ブロック３５０及び図４に示されるように生成されてもよい。一実施例では、ＧＰＵサイドでＧＰＵ ｖｔａｂｌｅポインタがバーチャル関数コールのために利用される間、ＣＰＵサイドのＣＰＵ ｖｔａｂｌｅポインタは、そのまま利用されてもよい。一実施例では、そのようなアプローチは、リンカ／ローダの変更又は関与を伴わず、共有オブジェクト１３１の余分なｖｐｔｒポインタフィールドを要求しない。このようなアプローチは、ＣＰＵ１１０とＧＰＵ１８０との間のオブジェクト指向言語により記述されたアプリケーションの詳細な分割を可能にする。
図５において、ヘテロジニアスプロセッサにより共有されるオブジェクトのメンバ関数を介しＣＰＵ１１０とＧＰＵ１８０との間の双方向通信をサポートするため、計算プラットフォーム１００により利用されるフロー図の実施例が示される。一実施例では、ＧＰＵコンパイラ１８８は、ＧＰＵ関数のためのＣＰＵスタブ５１０と、ＣＰＵサイド１１０上のＣＰＵリモートコールＡＰＩ５２０とを生成する。また、ＧＰＵコンパイラ１８８は、第１メンバ関数のためのＧＰＵサイド１８０のＧＰＵ関数のためのＧＰＵサイドグルーイングロジック（ｇｌｕｉｎｇ ｌｏｇｉｃ）５３０を生成する。一実施例では、ＣＰＵ１１０は、第１パスの第１イネーブリングパス（スタブロジック５１０、ＡＰＩ５２０及びグルーイングロジック５３０を有する）を用いて、第１メンバ関数へのコールを生成してもよい。一実施例では、第１イネーブリングパスは、ＣＰＵ１１０がＧＰＵサイド１８０とのリモートコールを確立し、ＣＰＵサイド１１０からＧＰＵサイド１８０に情報を伝送することを可能にする。一実施例では、ＧＰＵサイドグルーイングロジック５３０は、ＧＰＵ１８０がＣＰＵサイド１１０から伝送される情報を受信することを可能にする。
一実施例では、ＣＰＵスタブ５１０は、第１メンバ関数（すなわち、オリジナルＧＰＵメンバ関数）と同じ名前を有するが、ＣＰＵ１１０からのコールをＧＰＵ１８０に導くため、ＡＰＩ５２０を含むものであってもよい。一実施例では、ＣＰＵコンパイラ１１８により生成されるコードは、第１メンバ関数をそのままコールするが、当該コールはＣＰＵスタブ５１０及びリモートコールＡＰＩ５２０にリダイレクトされてもよい。また、リモートコールの作成中、ＣＰＵスタブ５１０は、第１メンバ関数がコールされていることを表す一意的な名前、共有オブジェクトへのポインタ、及びコールされた第１メンバ関数の他の引数を送信してもよい。一実施例では、ＧＰＵサイドのグルーイングロジック５３０は、引数を受信し、第１メンバ関数コールをディスパッチする。一実施例では、ＧＰＵコンパイラ１８８は、第１パラメータとしてわたされたオブジェクトポインタにより第１メンバ関数のＧＰＵサイド関数アドレスをコールすることによって、非バーチャル関数をディスパッチするグルーイングロジック（又はディスパッチャ）を生成する。一実施例では、ＧＰＵコンパイラ１８８は、ＣＰＵスタブ５１０がＧＰＵサイドのグルーイングロジック５３０と通信することを可能にするため、ＧＰＵサイドグルーイングロジック５３０を登録するためＧＰＵサイドにおいてジャンプテーブルレジストレーションコールを生成する。
一実施例では、ＧＰＵコンパイラ１８８は、ＣＰＵ関数のためのＧＰＵスタブ５５０、ＧＰＵサイド１８０上のＧＰＵリモートコールＡＰＩ５７０及びＣＰＵ１１０に配分された第２メンバ関数のためのＣＰＵサイドグルーイングロジック５８０を有する第２イネーブリングパスを生成する。一実施例では、ＧＰＵ１８０は、第２イネーブリングパスを用いてＣＰＵサイド１１０に対するコールを作成する。一実施例では、ＧＰＵスタブ５６０及びＡＰＩ５７０は、ＧＰＵ１８０がＣＰＵサイド１１０とのリモートコールを確立し、ＧＰＵサイド１８０からの情報をＣＰＵサイド１１０に伝送することを可能にする。一実施例では、ＣＰＵサイドグルーイングロジック５８０は、ＣＰＵ１１０がＧＰＵサイド１８０から伝送された情報を受信することを可能にする。
一実施例では、第２メンバ関数コールをサポートするため、ＧＰＵコンパイラ１８８は、ＣＰＵサイドグルーイングロジック５８０のためのジャンプテーブルレジストレーションを生成する。一実施例では、第２メンバ関数のＣＰＵサイド関数アドレスが、ＣＰＵグルーイングロジック５８０においてコールされる。一実施例では、ＣＰＵグルーイングロジック５８０により生成されるコードは、ＣＰＵコンパイラ１１８により生成される他のコードとリンクされてもよい。このようなアプローチは、ヘテロジニアスプロセッサ１１０と１８０との間の双方向通信をサポートするためのパスを提供する。一実施例では、ＣＰＵスタブロジック５１０及びＣＰＵサイドグルーイングロジック５８０は、ＣＰＵリンカ５９０を介しＣＰＵ１１０に接続されてもよい。一実施例では、ＣＰＵリンカ５９０は、ＣＰＵスタブ５１０、ＣＰＵサイドグルーイングロジック５８０及びＣＰＵコンパイラ１１８により生成される他のコードを用いて、ＣＰＵエグゼキュータブル（ＣＰＵ ｅｘｅｃｕｔａｂｌｅ）５９５を生成する。一実施例では、ＧＰＵスタブロジック５６０及びＧＰＵサイドグルーイングロジック５７０は、ＧＰＵリンカ５４０を介しＧＰＵ１８０に接続される。一実施例では、ＧＰＵリンカ５４０は、ＧＰＵグルーイングロジック５７０、ＧＰＵスタブ５６０及びＧＰＵコンパイラ１８８により生成される他のコードを用いて、ＧＰＵエグゼキュータブル（ＧＰＵ ｅｘｅｃｕｔａｂｌｅ）５４５を生成する。
図６において、上述したテーブルベース技術を用いてＧＰＵバーチャル関数とＧＰＵ非バーチャル関数とがＣＰＵサイド１１０によりコールされるフロー図６００の実施例が示される。ブロック６１０は、バーチャル関数（例えば、ＶＦ１３３−Ａなど）とバーチャル関数コール“Ｖｉｒｔｕａｌ ｖｏｉｄ ＳｏｍｅＶｉｒｔＦｕｎｃ（）”とを注釈付けする第１アノテーションタグ＃Ｐｒａｇｍａ ＧＰＵと、非バーチャル関数（例えば、ＮＶＦ１３６−Ａなど）と非バーチャル関数コール“ｖｏｉｄ ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”とを注釈付けする第２アノテーションタグ＃Ｐｒａｇｍａ ＧＰＵとを含む共有クラスインスタンス又は共有クラスＦｏｏ（）のタイトルのオブジェクトを有して示される。
一実施例では、“ｐＦｏｏ”は、クラスＦｏｏ（）の共有オブジェクト１３１を指定し、ＣＰＵサイド１１０からＧＰＵサイド１８０へのリモートバーチャル関数コールが完了する。一実施例では、“ｐＦｏｏ（）＝ｎｅｗ（Ｓｈａｒｅｄ ＭｅｍｏｒｙＡｌｌｏｃａｔｏｒ（））Ｆｏｏ（）；”は、共有されたメモリ割当て／リリースランタイムコールにより新たなオペレータを上書き又は削除するための１つの可能な方法である。一実施例では、ＣＰＵコンパイラ１１８は、ブロック６１０における“ｐＦｏｏ→ＳｏｍｅＶｉｒｔｕＦｕｎｃ（）”のコンパイルに応答して、ブロック６２０に示されるタスクを開始する。
ブロック６２０において、ＣＰＵサイド１１０は、ＧＰＵバーチャル関数をコールする。ブロック６３０において、ＣＰＵサイドスタブ（ＧＰＵメンバ関数のための）５１０及びＡＰＩ５２０は、ＧＰＵサイド１８０に情報（引数）を送信する。ブロック６４０において、ＧＰＵサイドグルーイングロジック（ＧＰＵメンバ関数のための）５３０は、ＴＨＩＳオブジェクトからｐＧＰＵＶｐｔｒ（ＣＰＵサイドｖｔａｂｌｅポインタ）を取得し、ＧＰＵ ｖｔａｂｌｅを検出する。ブロック６５０において、ＧＰＵサイドグルーイングロジック５４０（又はディスパッチャ）は、ＣＰＵサイドｖｔａｂｌｅポインタを用いてＧＰＵサイドｖｔａｂｌｅを取得するため、上述されたブロック３５０に示されるコードシーケンスを有してもよい。
一実施例では、ブロック６１０における＃Ｐｒａｇｍａ ＧＰＵ“ｖｏｉｄ ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”のコンパイルに応答して、ＧＰＵコンパイラ１８８は、ブロック６７０に示されるタスクを開始するため、“ｐＦｏｏ→ＳｏｍｅＮｏｎＶｉｒｔｕＦｕｎｃ（）”を利用するためのコードを生成する。ブロック６７０において、ＣＰＵサイド１１０は、ＧＰＵ非バーチャル関数をコールする。ブロック６８０において、ＣＰＵサイドスタブ５１０及びＡＰＩ５２０は、ＧＰＵサイド１８０に情報（引数）を送信する。ブロック６９０において、ＧＰＵサイドグルーイングロジック５３０は、パラメータをプッシュし、関数のアドレスが既知であるとき、直接アドレスをコールする。
図７のフローチャートにおいて、バーチャル共有非コヒーラント領域を用いてヘテロジニアスプロセッサの間のバーチャル関数の共有をサポートするため計算プラットフォーム１００により実行される処理の実施例が示される。ＣＰＵ１１０及びＧＰＵ１８０などのヘテロジニアスプロセッサを含む計算システム１００などの計算システムでは、ＣＰＵ１１０及びＧＰＵ１８０は、１１８及び１８８などの異なるコンパイラ（又は異なるターゲットを有する同一のコンパイラ）により生成される異なるコードを実行し、同一のバーチャル関数が、同一のアドレスに配置されることを保証されなくてもよい。バーチャル関数の共有をサポートするためコンパイラ／リンカ／ローダを修正可能であるが、後述される“非コヒーラント領域”アプローチ（ランタイムオンリーアプローチ）は、ＣＰＵ１１０とＧＰＵ１８０との間のバーチャル関数の共有を可能にするためのよりシンプルな技術である。このようなアプローチは、Ｍｉｎｅ／Ｙｏｕｒｓ／Ｏｕｒｓ（ＭＹＯ）などの共有されたバーチャルメモリシステムが容易に受け入れられ、配置されることを可能にする。Ｃ＋＋オブジェクト指向言語が一例として利用されるが、以下のアプローチは、バーチャル関数をサポートする他のオブジェクト指向プログラミング言語に適用可能であってもよい。
ブロック７１０において、ＣＰＵ１１０は、ＣＰＵ１１０とＧＰＵ１８０との共有クラスのｖｔａｂｌｅを格納するため、共有バーチャルメモリ１３０内に共有非コヒーラント領域を生成する。一実施例では、共有非コヒーラント領域は、共有バーチャルメモリ１３０内の領域への非コヒーラントタグを指定することによって生成されてもよい。一実施例では、ＭＹＯランタイムは、バーチャル共有領域（ＭＹＯの用語では“アリーナ”と呼ばれ、このような多数のアリーナがＭＹＯにおいて生成されてもよい）を生成するため、１以上のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｆａｃｅ）関数を提供する。例えば、ｍｙｏＡｒｅｎａＣｒｅａｔｅ（ｘｘｘ，．．．，ＮｏｎＣｏｈｅｒｅｎｔＴａｇ）又はｍｙｏＡｒｅｎａＣｒｅａｔｅＮｏｎＣｏｈｅｒｅｎｔＴａｇ（ｘｘｘ，．．．）が利用されてもよい。一実施例では、上記タグの利用は、コヒーラントアリーナ又は非コヒーラントアリーナを生成する。しかしながら、他の実施例では、ＡＰＩ関数は、メモリチャンク（又は部分）の性質を変更するのに利用されてもよい。例えば、ｍｙｏＣｈａｎｇｅＴｏＮｏｎＣｏｈｅｒｅｎｔ（ａｄｄｒ ｓｉｚｅ）は、非コヒーラント領域又はアリーナとして第１領域を生成し、コヒーラントアリーナとして第２領域（又は部分）を生成するのに利用されてもよい。一実施例では、第１領域はアドレスサイズにより指定されてもよい。
一実施例では、データ一貫性を維持することなくデータ共有を可能にするメモリアリーナ（すなわち、管理されたメモリチャンク）が生成され、このようなメモリアリーナは、共有非コヒーラント領域と呼ばれてもよい。一実施例では、共有非コヒーラント領域に格納されているＣＰＵデータ及びＧＰＵデータは、ＣＰＵ１１０とＧＰＵ１８０との双方により観察されるような同一のアドレスを有してもよい。しかしながら、ＭＹＯなどの共有バーチャルメモリ１３０がランタイム時に一貫性を維持しなくてもよいため、コンテンツ（ＣＰＵデータ及びＧＰＵデータ）は異なるものであってもよい。一実施例では、共有非コヒーラント領域は、各共有クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、ＣＰＵ１１０及びＧＰＵ１８０から観察されるようなバーチャル関数テーブルアドレスは同一であってもよく、しかしながら、バーチャル関数テーブルは異なるものであってもよい。
ブロック７５０において、初期化時間中、共有可能な各クラスのｖｔａｂｌｅは、ＣＰＵプライベートスペース１１５及びＧＰＵプライベートスペース１８５から共有バーチャルメモリ１３０にコピーされる。一実施例では、ＣＰＵサイドｖｔａｂｌｅは、共有バーチャルメモリ１３０内の非コヒーラント領域にコピーされ、ＧＰＵサイドｖｔａｂｌｅはまた、共有バーチャルメモリ１３０内の非コヒーラント領域にコピーされてもよい。一実施例では、共有スペースにおいて、ＣＰＵサイドｖｔａｂｌｅ及びＧＰＵサイドｖｔａｂｌｅは、同一アドレスに配置されてもよい。
一実施例では、ツールチェーンサポートが利用可能である場合、ＣＰＵコンパイラ１１８又はＧＰＵコンパイラ１８８は、特別なデータセクションにおいてＣＰＵ及びＧＰＵｖｔａｂｌｅデータを有してもよく、ローダ５４０又は５７０は、共有非コヒーラント領域に特別なデータセクションをロードする。他の実施例では、ＣＰＵコンパイラ１１８又はＧＰＵコンパイラ１８８は、例えば、ｍｙｏＣｈａｎｇｅＴｏＮｏｎＣｏｈｅｒｅｎｔなどのＡＰＩコールなどを用いて、特別なデータセクションが共有非コヒーラント領域に生成されることを可能にする。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅが特別なデータセクション内の同一のオフセットアドレスに配置されることを保証してもよい（存在しない場合には、適切なパディングによって）。一実施例では、多重継承の場合、オブジェクトレイアウトに複数のｖｔａｂｌｅポインタがあってもよい。一実施例では、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８はまた、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅポインタがオブジェクトレイアウトにおいて同一のオフセットに配置されることを保証するようにしてもよい。
ツールチェーンサポートがない場合、一実施例では、ユーザは、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを共有非コヒーラント領域にコピーすることが可能とされてもよい。一実施例では、１以上のマクロが、ＣＰＵ及びＧＰＵテーブルを共有非コヒーラントメモリ領域に手動によりコピーすることを容易にするため生成される。
ランタイム時、共有オブジェクト１３１などの共有オブジェクトが生成された後、多重継承のために複数の“ｖｐｔｒ”を有するオブジェクトレイアウト８０１が生成される。一実施例では、オブジェクトテーブル８０１の共有オブジェクト１３１のバーチャルテーブルポインタ（ｖｐｔｒ）は、共有非コヒーラント領域におけるバーチャル関数テーブルの新たなコピーを指定するため更新（パッチ）される。一実施例では、共有オブジェクトのバーチャルテーブルポインタは、バーチャル関数を含むクラスのコンストラクタを用いて更新される。一実施例では、クラスがバーチャル関数を有さない場合、当該クラスのデータ及び関数が共有され、ランタイム中に更新（又はパッチ）する必要はない。
ブロック７８０において、ｖｐｔｒ（ｖｔａｂｌｅポインタ）は、共有オブジェクト１３１を作成しながら、共有非コヒーラント領域を示すよう変更される。一実施例では、デフォルトによりプライベートなｖｔａｂｌｅ（ＣＰＵ ｖｔａｂｌｅ又はＧＰＵ ｖｔａｂｌｅ）を示すｖｐｔｒは、共有非コヒーラント領域８６０を示すよう変更される（図８の実線８０２−Ｃにより示されるように）。一実施例では、バーチャル関数は以下のようにコールされてもよい。
Ｍｏｖ ｅａｘ，［ｅｃｘ］ ＃ｅｃｘは“ｔｈｉｓ”ポインタを含み、ｅａｘはｖｐｔｒを含む
Ｃａｌｌ［ｅａｘ，ｖｆｕｎｃ］ ＃ｖｆｕｎｃはバーチャル関数テーブルにおけるバーチャル関数インデックスである
ＣＰＵサイドにおいて、上記コードはバーチャル関数のＣＰＵの実装をコールし、ＧＰＵサイドでは、上記コードはバーチャル関数のＧＰＵ実装をコールしてもよい。このようなアプローチは、クラスに対するデータ共有及びバーチャル関数共有を可能にする。
図８において、ヘテロジニアスプロセッサの間のバーチャル関数共有をサポートするためのバーチャル共有非コヒーラント領域の利用を示す関係図８００の実施例が示される。一実施例では、オブジェクトレイアウト８０１は、第１スロット８０１−Ａのバーチャルテーブルポインタ（ｖｐｔｒ）と、スロット８０１−Ｂ及び８０１−Ｃのフィールド１及びフィールド２などの他のフィールドとを含む。一実施例では、以降に、ＣＰＵコンパイラ１１８及びＧＰＵコンパイラ１８８は、スロット８０１−Ａに配置されるｖｔａｂｌｅポインタ（ｖｐｔｒ）を実行し、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅ（破線８０２−Ｂに示されるように）を生成する（破線８０２−Ａに示されるように）。ＣＰＵバーチャル関数テーブル（ＣＰＵ ｖｔａｂｌｅ）は、ＣＰＵプライベートアドレススペース１１５内のアドレス８１０に配置され、ＧＰＵ ｖｔａｂｌｅは、ＧＰＵプライベートアドレススペース１８５内のアドレス８４０に配置されてもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１及びｖｆｕｎｃ２などの関数ポインタを含み、ＧＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１’及びｖｆｕｎｃ２’などの関数ポインタを含むようにしてもよい。一実施例では、関数ポインタ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）及び（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）はまた、これらのポインタが同一の関数の異なる実装を指定するとき、異なるものであってもよい。
一実施例では、ｖｐｔｒを変更した結果として（ブロック７８０に示されるように）、ｖｐｔｒは、共有バーチャルメモリ１３０内の共有非コヒーラント領域８６０を指示する。一実施例では、ＣＰＵ ｖｔａｂｌｅはアドレスＡｄｄｒｅｓｓ ８７０に配置され、ＧＰＵ ｖｔａｂｌｅは同一アドレスＡｄｄｒｅｓｓ ８７０に配置されてもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１及びｖｆｕｎｃ２などの関数ポインタを含み、ＧＰＵ ｖｔａｂｌｅは、ｖｆｕｎｃ１’及びｖｆｕｎｃ２’などの関数ポインタを含むものであってもよい。一実施例では、関数ポインタ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）及び（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）は異なるものであってもよい。一実施例では、ＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを共有非コヒーラント領域８６０に保存することは、ＣＰＵ１１０及びＧＰＵ１８０がそれぞれ同一のアドレス位置Ａｄｄｒｅｓｓ ８７０にＣＰＵ ｖｔａｂｌｅ及びＧＰＵ ｖｔａｂｌｅを参照することを可能にするが、ＣＰＵ ｖｔａｂｌｅのコンテンツ（ｖｆｕｎｃ１及びｖｆｕｎｃ２）は、ＧＰＵ ｖｔａｂｌｅのコンテンツ（ｖｆｕｎｃ１’及びｖｆｕｎｃ２’）と異なるものであってもよい。
図９において、双方向通信をサポートするヘテロジニアスプロセッサを有するコンピュータシステム９００の実施例が示される。図９を参照すると、コンピュータシステム９００は、ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）プロセッサとＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）９０５とを含む汎用プロセッサ（又はＣＰＵ）９０２を有する。一実施例では、ＣＰＵ９０２は、マシーン可読記憶媒体９２５にエンハンスメント処理を提供するため、他の各種タスクの実行又は命令シーケンスの格納に加えて、エンハンスメント処理を実行する。しかしながら、命令シーケンスはまた、ＣＰＵプライベートメモリ９２０又は他の何れか適切な記憶媒体に格納されてもよい。一実施例では、ＣＰＵ９０２は、ＣＰＵレガシコンパイラ９０３及びＣＰＵリンカ／ローダ９０４に関連付けされてもよい。一実施例では、ＧＰＵ９０５は、ＧＰＵ専用コンパイラ９０６及びＧＰＵリンカ／ローダ９０７に関連付けされてもよい。
図９では独立したＧＰＵ９０５が示されるが、いくつかの実施例では、プロセッサ９０２は、他の例としてエンハンスメント処理を実行するのに利用されてもよい。コンピュータシステム９００を処理するプロセッサ９０２は、ロジック９３０に接続された１以上のプロセッサコアであってもよい。ロジック９３０は、コンピュータシステム９００とのインタフェースを提供する１以上のＩ／Ｏデバイス９６０に接続されてもよい。例えば、ロジック９３０は、一実施例では、チップセットロジックとすることができる。ロジック９３０は、光、磁気又は半導体ストレージを含む何れかのタイプのストレージとすることが可能なメモリ９２０に接続される。グラフィックプロセッサユニット９０５は、フレームバッファを介しディスプレイ９４０に接続される。
一実施例では、コンピュータシステム９００は、共有オブジェクトを詳細に分割することによって、共有オブジェクトのバーチャル関数などのメンバ関数を介しヘテロジニアスプロセッサＣＰＵ９０２とＧＰＵ９０５との間の双方向通信（関数コール）を可能にするための１以上の技術をサポートする。一実施例では、コンピュータシステム９００は、“テーブルベース”技術と呼ばれる第１技術を用いて、ＣＰＵ９０２とＧＰＵ９０５との間の双方向通信を可能にする。他の実施例では、計算プラットフォームは、バーチャル共有非コヒーラント領域がプライベートＣＰＵメモリ９２０、プライベートＧＰＵメモリ９３０又は共有メモリ９５０の何れかに配置されるバーチャル共有メモリに作成される“非コヒーラント領域”技術と呼ばれる第２技術を利用して、ＣＰＵ９０２とＧＰＵ９０５との間の双方向通信を可能にする。一実施例では、共有メモリ９５０などの独立した共有メモリはコンピュータシステム９００に設けられなくてもよく、このような場合、共有メモリは、ＣＰＵメモリ９２０又はＧＰＵメモリ９３０などのプライベートメモリの１つに設けられてもよい。
一実施例では、テーブルベース技術を利用しながら、ＣＰＵ１１０又はＧＰＵ１８０から共有オブジェクトにアクセスするのに利用される共有オブジェクトのＣＰＵサイドｖｔａｂｌｅポインタが、ＧＰＵサイドテーブルが存在する場合、ＧＰＵ ｖｔａｂｌｅを決定するのに利用されてもよい。一実施例では、ＧＰＵサイドｖｔａｂｌｅは、＜“ｃｌａｓｓＮａｍｅ”，ＣＰＵ ｖｔａｂｌｅ ａｄｄｒ，ＧＰＵ ｖｔａｂｌｅ ａｄｄｒ＞を含むものであってもよい。一実施例では、ＧＰＵサイドのｖｔａｂｌｅアドレスを取得し、ＧＰＵサイドテーブルを生成するための技術が上述された。
他の実施例では、“非コヒーラント領域”技術を利用しながら、共有非コヒーラント領域が共有バーチャルメモリ内に作成される。一実施例では、共有非コヒーラント領域は、データ一貫性を維持しなくてもよい。一実施例では、共有非コヒーラント領域内のＣＰＵサイドデータとＧＰＵサイドデータとは、ＣＰＵサイド及びＧＰＵサイドから参照されるように同一のアドレスを有してもよい。しかしながら、ＣＰＵサイドデータのコンテンツは、共有バーチャルメモリがランタイム中に一貫性を維持しないとき、ＧＰＵサイドデータのものと異なるものになってもよい。一実施例では、共有非コヒーラント領域は、各共有クラスについてバーチャルメソッドテーブルの新たなコピーを格納するのに利用されてもよい。一実施例では、このようなアプローチは、同一のアドレスにおいてバーチャルテーブルを維持してもよい。
ここに開示されたグラフィックス処理技術は、各種ハードウェアアーキテクチャにより実現されてもよい。例えば、グラフィックス機能は、チップセット内に統合されてもよい。あるいは、独立したグラフィックプロセッサが利用されてもよい。さらなる他の実施例として、グラフィックス関数は、マルチコアプロセッサを含む汎用プロセッサにより、又はマシーン可読媒体に格納されるソフトウェア命令セットとして実現されてもよい。

Claims (31)

  1. 計算プラットフォームにおける方法であって、
    複数のバーチャル関数を含む共有オブジェクトを生成するステップと、
    前記共有オブジェクトを共有バーチャルメモリに格納するステップと、
    第１プロセッサと第２プロセッサとの間で前記複数のバーチャル関数の少なくとも１つを共有するステップと、
    を有し、
    前記計算プラットフォームは、前記第１プロセッサと前記第２プロセッサとを含み、
    前記第１プロセッサと前記第２プロセッサとはヘテロジニアスプロセッサである方法。
  2. 第２プロセッササイドテーブルが、クラスネーム、第１プロセッササイドバーチャルテーブルアドレス及び第２プロセッササイドバーチャルテーブルアドレスを有する場合、第１プロセッササイドバーチャルテーブルポインタを用いて第２プロセッササイドバーチャルテーブルを決定するステップを有する、請求項１記載の方法。
  3. 前記第１プロセッササイドバーチャルテーブルポインタを前記共有オブジェクトに含めるステップをさらに有する、請求項２記載の方法。
  4. プログラムを実行する初期化段階中に前記第２プロセッササイドテーブルを生成するステップを有する、請求項２記載の方法。
  5. 前記共有オブジェクトのレジストレーション関数への関数ポインタを初期化セクションに含めるようにし、
    前記方法は、さらに、前記初期化セクションに含められた、前記共有オブジェクトのレジストレーション関数への関数ポインタを用いて、前記初期化セクションに基づく初期化段階中に前記レジストレーション関数を実行するステップを有する、請求項４記載の方法。
  6. 前記第１プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第１プロセッササイドバーチャルテーブルアドレスを第１テーブルに登録するステップと、
    前記第２プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第２プロセッササイドバーチャルテーブルアドレスを第２テーブルに登録するステップと、
    前記第１テーブルと前記第２テーブルとをマージすることによって、前記第２プロセッササイドテーブルを生成するステップと、
    を有する、請求項５記載の方法。
  7. 前記第２プロセッササイドテーブルは、ＤＬＬ（Ｄｙｎａｍｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）及びＳＬＬ（Ｓｔａｔｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂａｒｙ）をサポートする、請求項６記載の方法。
  8. 前記第１プロセッサのバーチャルテーブルと前記第２プロセッサのバーチャルテーブルとを格納するため、前記共有バーチャルメモリ内に共有非コヒーラント領域を生成するステップを有する、請求項１記載の方法。
  9. 前記共有非コヒーラント領域を生成するため、非コヒーラントタグを前記共有バーチャルメモリの領域に加えるステップを有する、請求項８記載の方法。
  10. 前記第１プロセッサと前記第２プロセッサとのプライベートアドレススペースから前記共有非コヒーラント領域に前記共有オブジェクトのバーチャルテーブルをコピーするステップを有し、
    前記第１プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第１プロセッササイドバーチャルテーブルのコンテンツと、前記第２プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第２プロセッササイドバーチャルテーブルのコンテンツが異なる場合でさえ、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルは、前記共有非コヒーラント領域において、同一のアドレスに配置される、請求項８記載の方法。
  11. 前記共有オブジェクトの生成中、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルとを指示するバーチャルポインタを前記共有非コヒーラント領域を指示するよう変更するステップを有する、請求項１０記載の方法。
  12. 実行されることに応答して、
    複数のバーチャル関数を含む共有オブジェクトを生成するステップと、
    前記共有オブジェクトを共有バーチャルメモリに格納するステップと、
    第１プロセッサと第２プロセッサとの間で前記複数のバーチャル関数の少なくとも１つを共有するステップと、
    を計算プラットフォームに含まれるプロセッサに実行させる複数の命令を有するマシーン可読記憶媒体であって、
    前記計算プラットフォームは、前記第１プロセッサと前記第２プロセッサとを有し、
    前記第１プロセッサと前記第２プロセッサとは、ヘテロジニアスプロセッサであるマシーン可読記憶媒体。
  13. 第２プロセッササイドテーブルが、クラスネーム、第１プロセッササイドバーチャルテーブルアドレス及び第２プロセッササイドバーチャルテーブルアドレスを有する場合、第１プロセッササイドバーチャルテーブルポインタを用いて第２プロセッササイドバーチャルテーブルを決定するステップをプロセッサに実行させるための命令を有する、請求項１２記載のマシーン可読記憶媒体。
  14. 前記第１プロセッササイドバーチャルテーブルポインタを前記共有オブジェクトに含めるステップをプロセッサに実行させるための命令を有する、請求項１３記載のマシーン可読記憶媒体。
  15. プログラムを実行する初期化段階中に前記第２プロセッササイドテーブルを生成するステップをプロセッサに実行させるための命令を有する、請求項１３記載のマシーン可読記憶媒体。
  16. 前記共有オブジェクトのレジストレーション関数への関数ポインタを初期化セクションに含めるようにし、
    前記マシーン可読記憶媒体は、
    前記初期化セクションに含められた、前記共有オブジェクトのレジストレーション関数への関数ポインタを用いて、初期化セクションに基づく初期化段階中に前記レジストレーション関数を実行するステップを、
    プロセッサに実行させるための命令を有する、請求項１５記載のマシーン可読記憶媒体。
  17. 前記第１プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第１プロセッササイドバーチャルテーブルアドレスを第１テーブルに登録するステップと、
    前記第２プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第２プロセッササイドバーチャルテーブルアドレスを第２テーブルに登録するステップと、
    前記第１テーブルと前記第２テーブルとをマージすることによって、前記第２プロセッササイドテーブルを生成するステップと、
    をプロセッサに実行させるための命令を有する、請求項１６記載のマシーン可読記憶媒体。
  18. 前記第２プロセッササイドテーブルは、ＤＬＬ（Ｄｙｎａｍｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂｒａｒｙ）及びＳＬＬ（Ｓｔａｔｉｃａｌｌｙ Ｌｉｎｋｅｄ Ｌｉｂａｒｙ）をサポートする、請求項１７記載のマシーン可読記憶媒体。
  19. 前記第１プロセッサのバーチャルテーブルと前記第２プロセッサのバーチャルテーブルとを格納するため、前記共有バーチャルメモリ内に共有非コヒーラント領域を生成するステップをプロセッサに実行させるための命令を有する、請求項１２記載のマシーン可読記憶媒体。
  20. 前記共有非コヒーラント領域を生成するため、非コヒーラントタグを前記共有バーチャルメモリの領域に加えるステップをプロセッサに実行させるための命令を有する、請求項１９記載のマシーン可読記憶媒体。
  21. 前記マシーン可読記憶媒体は、前記第１プロセッサと前記第２プロセッサとのプライベートアドレススペースから前記共有非コヒーラント領域に前記共有オブジェクトのバーチャルテーブルをコピーするステップをプロセッサに実行させるための命令を有し、
    前記第１プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第１プロセッササイドバーチャルテーブルのコンテンツと、前記第２プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第２プロセッササイドバーチャルテーブルのコンテンツが異なる場合でさえ、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルは、前記共有非コヒーラント領域において、同一のアドレスに配置される、請求項１９記載のマシーン可読記憶媒体。
  22. 前記共有オブジェクトの生成中、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルとを指示するバーチャルポインタを前記共有非コヒーラント領域を指示するよう変更するステップをプロセッサに実行させるための命令を有する、請求項２１記載のマシーン可読記憶媒体。
  23. 第１コンパイラに接続される第１プロセッサと、第２コンパイラに接続される第２プロセッサとを有する複数のヘテロジニアスプロセッサを有する装置であって、
    前記第１コンパイラは、共有オブジェクトに含まれる、前記第１プロセッサに割り当てられた第１バーチャルメンバ関数のコンパイルされたコードを生成するものであり、前記第２コンパイラは、共有オブジェクトに含まれる、前記第２プロセッサに割り当てられた第２バーチャルメンバ関数のコンパイルされたコードを生成するものであり、
    前記第１プロセッサは、複数のバーチャル関数を含む共有オブジェクトを生成し、前記共有オブジェクトを共有バーチャルメモリに格納し、前記複数のバーチャル関数の少なくとも１つを第２プロセッサと共有する装置。
  24. 前記第２プロセッサは、第２プロセッササイドテーブルがクラスネーム、第１プロセッササイドバーチャルテーブルアドレス及び第２プロセッササイドバーチャルテーブルアドレスを含む場合、第１プロセッササイドバーチャルテーブルポインタを用いて、第２プロセッササイドバーチャルテーブルを決定する、請求項２３記載の装置。
  25. 前記第１プロセッササイドバーチャルテーブルポインタは、前記共有オブジェクトに含まれる、請求項２４記載の装置。
  26. 前記第１プロセッサと前記第２プロセッサは、協働して、プログラムを実行する初期化段階中に前記第２プロセッササイドテーブルを生成する、請求項２４記載の装置。
  27. 前記共有オブジェクトのレジストレーション関数への関数ポインタを初期化セクションに含めるようにし、
    前記装置は、さらに、
    前記初期化セクションに含められた、前記共有オブジェクトのレジストレーション関数への関数ポインタを用いて、前記初期化セクションに基づく初期化段階中に前記レジストレーション関数を実行するものである、請求項２６記載の装置。
  28. 前記第１プロセッサと前記第２プロセッサは、協働して、
    前記第１プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第１プロセッササイドバーチャルテーブルアドレスを第１テーブルに登録し、
    前記第２プロセッササイドで前記レジストレーション関数を実行中に、前記クラスネーム及び前記第２プロセッササイドバーチャルテーブルアドレスを第２テーブルに登録し、
    前記第１テーブルと前記第２テーブルとをマージすることによって、前記第２プロセッササイドテーブルを生成する、ことをサポートする、請求項２７記載の装置。
  29. 前記第１プロセッサは、前記第１プロセッサのバーチャルテーブルと前記第２プロセッサのバーチャルテーブルとを格納するため前記共有バーチャルメモリ内に共有非コヒーラント領域を生成し、
    前記共有非コヒーラント領域は、非コヒーラントタグを前記共有バーチャルメモリの領域に加えることによって生成される、請求項２３記載の装置。
  30. 前記第１プロセッサと前記第２プロセッサとは、前記第１プロセッサと前記第２プロセッサとのプライベートアドレススペースから前記共有非コヒーラント領域に前記共有オブジェクトのバーチャルテーブルをコピーすることをサポートし、
    前記第１プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第１プロセッササイドバーチャルテーブルのコンテンツと、前記第２プロセッサのプライベートアドレススペースから前記共有非コヒーラント領域にコピーされたバーチャルテーブルである第２プロセッササイドバーチャルテーブルのコンテンツが異なる場合でさえ、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルは、前記共有非コヒーラント領域において、同一のアドレスに配置される、請求項２９記載の装置。
  31. 前記第１プロセッサは、前記共有オブジェクトの生成中、前記共有非コヒーラント領域を指示するように、前記第１プロセッササイドバーチャルテーブルと前記第２プロセッササイドバーチャルテーブルとを指示するバーチャルポインタを変更することをサポートする、請求項３０記載の装置。
JP2013529523A 2010-09-24 2010-09-24 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有 Active JP5639274B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2010/001470 WO2012037706A1 (en) 2010-09-24 2010-09-24 Sharing virtual functions in a shared virtual memory between heterogeneous processors of a computing platform

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2014216090A Division JP5902273B2 (ja) 2014-10-23 2014-10-23 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有

Publications (2)

Publication Number Publication Date
JP2013542497A JP2013542497A (ja) 2013-11-21
JP5639274B2 true JP5639274B2 (ja) 2014-12-10

Family

ID=45873372

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013529523A Active JP5639274B2 (ja) 2010-09-24 2010-09-24 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有

Country Status (7)

Country Link
US (2) US8997113B2 (ja)
EP (2) EP3043269B1 (ja)
JP (1) JP5639274B2 (ja)
KR (3) KR101534037B1 (ja)
CN (1) CN103109286B (ja)
TW (1) TWI573094B (ja)
WO (1) WO2012037706A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101534037B1 (ko) 2010-09-24 2015-07-08 인텔 코포레이션 컴퓨팅 플랫폼의 이종 프로세서들 간의 공유 가상 메모리에서의 가상 함수들의 공유
US8806503B2 (en) * 2011-01-24 2014-08-12 Nec Laboratories America, Inc. Method and system for memory aware runtime to support multitenancy in heterogeneous clusters
GB2489278B (en) * 2011-03-24 2019-12-25 Advanced Risc Mach Ltd Improving the scheduling of tasks to be performed by a non-coherent device
US8949777B2 (en) * 2011-04-22 2015-02-03 Intel Corporation Methods and systems for mapping a function pointer to the device code
CN104335162B (zh) 2012-05-09 2018-02-23 英特尔公司 使用多个页表的执行
US9733953B2 (en) * 2012-06-22 2017-08-15 Microsoft Technology Licensing, Llc API redirection for limited capability operating systems
US9405556B2 (en) 2012-06-28 2016-08-02 Microsoft Technology Licensing, Llc Dynamic addition and removal of operating system components
US9830172B2 (en) * 2012-06-30 2017-11-28 Microsoft Technology Licensing, Llc Implementing functional kernels using compiled code modules
US9405561B2 (en) * 2012-08-08 2016-08-02 Nvidia Corporation Method and system for memory overlays for portable function pointers
US9378572B2 (en) * 2012-08-17 2016-06-28 Intel Corporation Shared virtual memory
US9881592B2 (en) 2013-10-08 2018-01-30 Nvidia Corporation Hardware overlay assignment
US20150106587A1 (en) * 2013-10-16 2015-04-16 Advanced Micro Devices, Inc. Data remapping for heterogeneous processor
US9436395B2 (en) 2014-03-14 2016-09-06 Advanced Micro Devices, Inc. Mechanisms to save user/kernel copy for cross device communications
US9720832B2 (en) * 2015-03-27 2017-08-01 International Business Machines Corporation Store operations to maintain cache coherence
US10140104B2 (en) * 2015-04-14 2018-11-27 Micron Technology, Inc. Target architecture determination
US9830676B2 (en) * 2015-07-28 2017-11-28 Intel Corporation Packet processing on graphics processing units using continuous threads
KR101897624B1 (ko) 2016-01-19 2018-10-04 서울대학교산학협력단 이종 시스템에서의 데이터 분배 기법
CN107239315B (zh) 2017-04-11 2019-11-15 赛灵思公司 面向神经网络异构计算平台的编程模型
KR102403379B1 (ko) * 2017-09-12 2022-06-02 주식회사 코코링크 다중 gpu간 데이터 공유 방법
US12086705B2 (en) * 2017-12-29 2024-09-10 Intel Corporation Compute optimization mechanism for deep neural networks
CN109086086B (zh) * 2018-08-06 2021-06-08 深圳忆联信息系统有限公司 一种非空间共享的多核cpu的启动方法及装置
CN112673348A (zh) * 2018-09-19 2021-04-16 英特尔公司 混合虚拟gpu协同调度
US11467812B2 (en) * 2019-11-22 2022-10-11 Advanced Micro Devices, Inc. Compiler operations for heterogeneous code objects
US11256522B2 (en) 2019-11-22 2022-02-22 Advanced Micro Devices, Inc. Loader and runtime operations for heterogeneous code objects
US11599467B2 (en) * 2021-05-27 2023-03-07 Arm Limited Cache for storing coherent and non-coherent data
DE102022107294A1 (de) * 2022-03-28 2023-09-28 Bayerische Motoren Werke Aktiengesellschaft Steuerung eines Fahrzeugs

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6184740A (ja) 1984-10-03 1986-04-30 Hitachi Ltd 汎用オブジエクトコ−ド生成方式
US5297284A (en) * 1991-04-09 1994-03-22 Microsoft Corporation Method and system for implementing virtual functions and virtual base classes and setting a this pointer for an object-oriented programming language
EP0620520A1 (en) * 1993-03-30 1994-10-19 AT&T Corp. Method for making persistent data objects having hidden pointers
FR2717280B1 (fr) * 1994-03-10 1996-04-05 Bull Sa Procédé de gestion de l'héritage multiple d'objets persistants et partagés.
US5802367A (en) * 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
US5812852A (en) * 1996-11-14 1998-09-22 Kuck & Associates, Inc. Software implemented method for thread-privatizing user-specified global storage objects in parallel computer programs via program transformation
JPH10207709A (ja) 1997-01-20 1998-08-07 Meidensha Corp オブジェクトの共有方法
US6189046B1 (en) * 1997-03-27 2001-02-13 Hewlett-Packard Company Mechanism and method for merging cached location information in a distributed object environment
JPH10320203A (ja) * 1997-05-22 1998-12-04 Meidensha Corp 共有メモリシステム
US6446259B2 (en) * 1997-09-15 2002-09-03 Compaq Computer Corporation System and method for generating an object structure at run time in an object-oriented programming language
US6148438A (en) * 1998-01-06 2000-11-14 National Instruments Corporation System and method for creating composite classes for objects having virtual functions for avoidance of user mode/kernel mode transitions
US6049668A (en) * 1998-04-13 2000-04-11 Intel Corporation Method and apparatus for supporting multiple processor-specific code segments in a single executable
US7409694B2 (en) * 1998-09-09 2008-08-05 Microsoft Corporation Highly componentized system architecture with loadable virtual memory manager
US6704924B1 (en) * 1999-02-03 2004-03-09 William H. Gates, III Method and system for implementing virtual functions of an interface
US6286092B1 (en) * 1999-05-12 2001-09-04 Ati International Srl Paged based memory address translation table update method and apparatus
US6754887B1 (en) * 1999-10-22 2004-06-22 International Business Machines Corporation Methods for implementing virtual bases with fixed offsets in object oriented applications
US6810519B1 (en) * 2000-09-29 2004-10-26 International Business Machines Corporation Achieving tight binding for dynamically loaded software modules via intermodule copying
JP3874603B2 (ja) 2000-11-21 2007-01-31 株式会社日立製作所 計算機システムの共有メモリ構築方法
US6684305B1 (en) 2001-04-24 2004-01-27 Advanced Micro Devices, Inc. Multiprocessor system implementing virtual memory using a shared memory, and a page replacement method for maintaining paged memory coherence
US7000238B2 (en) * 2001-10-10 2006-02-14 Borland Software Corporation Development system providing extensible remoting architecture
US6842759B2 (en) * 2002-01-16 2005-01-11 International Business Machines Corporation Single-instance class objects across multiple JVM processes in a real-time system
US7093080B2 (en) 2003-10-09 2006-08-15 International Business Machines Corporation Method and apparatus for coherent memory structure of heterogeneous processor systems
US20060070069A1 (en) * 2004-09-30 2006-03-30 International Business Machines Corporation System and method for sharing resources between real-time and virtualizing operating systems
US7653789B2 (en) * 2006-02-01 2010-01-26 Sun Microsystems, Inc. Multiprocessor system that supports both coherent and non-coherent memory accesses
US20070283336A1 (en) * 2006-06-01 2007-12-06 Michael Karl Gschwind System and method for just-in-time compilation in a heterogeneous processing environment
US7490191B2 (en) * 2006-09-22 2009-02-10 Intel Corporation Sharing information between guests in a virtual machine environment
US7941791B2 (en) * 2007-04-13 2011-05-10 Perry Wang Programming environment for heterogeneous processor resource integration
US8156307B2 (en) * 2007-08-20 2012-04-10 Convey Computer Multi-processor system having at least one processor that comprises a dynamically reconfigurable instruction set
US7996628B2 (en) * 2008-02-14 2011-08-09 International Business Machines Corporation Cross adapter shared address translation tables
JP5151559B2 (ja) 2008-02-29 2013-02-27 富士通株式会社 プログラム実行システム
US8531471B2 (en) * 2008-11-13 2013-09-10 Intel Corporation Shared virtual memory
US8307350B2 (en) * 2009-01-14 2012-11-06 Microsoft Corporation Multi level virtual function tables
US9117071B2 (en) * 2009-06-03 2015-08-25 Apple Inc. Methods and apparatuses for secure compilation
KR101534037B1 (ko) 2010-09-24 2015-07-08 인텔 코포레이션 컴퓨팅 플랫폼의 이종 프로세서들 간의 공유 가상 메모리에서의 가상 함수들의 공유

Also Published As

Publication number Publication date
WO2012037706A1 (en) 2012-03-29
EP2619687B1 (en) 2016-04-06
EP3043269A1 (en) 2016-07-13
TWI573094B (zh) 2017-03-01
KR20150006903A (ko) 2015-01-19
KR101534037B1 (ko) 2015-07-08
JP2013542497A (ja) 2013-11-21
EP2619687A4 (en) 2014-04-09
KR20160008245A (ko) 2016-01-21
KR20130040264A (ko) 2013-04-23
EP2619687A1 (en) 2013-07-31
US20130173894A1 (en) 2013-07-04
EP3043269B1 (en) 2017-07-26
US8997113B2 (en) 2015-03-31
US20150113255A1 (en) 2015-04-23
CN103109286A (zh) 2013-05-15
TW201214325A (en) 2012-04-01
KR101761650B1 (ko) 2017-07-28
CN103109286B (zh) 2016-08-24
KR101581796B1 (ko) 2016-01-04

Similar Documents

Publication Publication Date Title
JP5639274B2 (ja) 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有
US8719839B2 (en) Two way communication support for heterogenous processors of a computer platform
US11175896B2 (en) Handling value types
US9830176B2 (en) Methods, systems, and media for binary compatible graphics support in mobile operating systems
KR101240092B1 (ko) 컴퓨터 플랫폼에서의 방법 및 컴퓨터 플랫폼
Andrus et al. Cider: Native execution of ios apps on android
JP6280581B2 (ja) 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有
JP5902273B2 (ja) 計算プラットフォームのヘテロジニアスプロセッサの間で共有されるバーチャルメモリにおけるバーチャル機能の共有
Szabó et al. Real-time rendering with OpenGL and Vulkan in C#
Bieniusa et al. The architecture of the DecentVM: Towards a decentralized virtual machine for many-core computing
CN104536740B (zh) 计算平台的异质处理器之间的共享虚拟存储器中的虚函数共享
Cohen et al. NDK and C/C++ optimization
Ciocarlie et al. Considerations regarding the implementation of the ESPL programming language
Silva et al. Mercury: a reflective middleware for automatic parallelization of bags-of-tasks
Bieniusa et al. The Architecture of the DecentVM
Goyal et al. Function Overloading and Default Arguments
Molina Huemul–A Smalltalk Implementation

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140422

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140520

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140818

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140924

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141023

R150 Certificate of patent or registration of utility model

Ref document number: 5639274

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250