JP2005524907A - ホストプロセッサとグラフィックプロセッサとの間のメモリの最適共有を行うための方法及びシステム - Google Patents

Abstract

本発明による方法及びシステムは、１以上のＣＰＵ上で実行されるアプリケーションと、
グラフィックプロセッサなどのコンピュータシステムのアクセラレーションコプロセッサとの間のメモリの共有化を提供するものであり、当該コンピュータシステムでは、共有されたメモリは、ＣＰＵとグラフィックプロセッサの両方の最大パフォーマンスに有利なそれの最適なキャッシュ及びアクセス属性を維持する。本方法は、ビュー状態にある共有されたメモリの配置を次のオーナーにわたす前に、共有されたメモリが前のオーナーに関して一貫性を有するようにされるオーナー権限の分割に関する。この調停は、オーナー権限があるクライアントから他のクライアントに移行されるインタフェースに関する。このようなオーナー権限の移行において、プロセッサ低レベルキャッシュ制御指示の利用を介し共有メモリのプロセッサキャッシュ属性をアクティブに変更することにより、メモリはあるビューから他のビューに変更され、及び/またはグラフィックプロセッサはデータ一貫性の実施に用いられるフラッシュアルゴリズムを提供する。本発明の実施例は、クライアント間のデータの移動または複製によるオーバヘッドなしで、データを共有するすべてのクライアントに対する最大アクセス効率を向上させる。

Description

発明の詳細な説明

［発明の技術分野］
本発明は、コンピュータグラフィックシステムに関し、より詳細には、ＣＰＵ（中央処理ユニット）とグラフィックプロセッサにより共有されるメモリの使用を最適化することに関する。
［背景］
既知の多くのコンピュータシステムにおいて、ホストＣＰＵは、実行対象のグラフィック処理を呼び出すアプリケーションを実行するかもしれない。そのようなグラフィック処理を実現するため、典型的には、アプリケーションは（以下に限定されるものではないが、ネットワーク、ＣＤあるいはハードドライブディスク記憶装置を含む）オフラインの記憶装置から（以下に限定されるものではないが、テクスチャ、ジオメトリ、モデルなどを含む）初期的グラフィックデータ及びプリミティブ（ｐｒｉｍｉｔｉｖｅ）をフェッチし、オンラインシステムメモリに当該グラフィックデータ及びプリミティブのコピーを生成する。アプリケーションは、オンラインシステムメモリのグラフィック画素、データモデル及びプリミティブ上で動作し、その後ある時点で、典型的にはホストＣＰＵから低レベルのレンダリングタスクをオフロードするため、グラフィックデータとプリミティブ上で動作するため、コンピュータシステムのグラフィックプロセッサを呼び出すようにしてもよい。

既知の実現形態によると、グラフィックプロセッサにより処理が呼び出されると、アプリケーションはオフライン記憶装置からオンラインシステムメモリに初期的にロードされるコピーとは別に、グラフィックプロセッサが動作するグラフィックデータ及びプリミティブの第２コピーを生成する。この別の第２コピー（ここでは、「エイリアス（ａｌｉａｓｅｄ）」コピーと呼ばれる）は、典型的には、グラフィックプロセッサによる利用のため用意されるという理由から、「グラフィックメモリ」と呼ばれるオンラインシステムメモリの一領域に配置されてもよい。グラフィックメモリの各種実現形態が当該技術分野において知られている。例えば、個別のアドイングラフィックアダプタカードは、当該カード上のプライベートメモリバスによりローカルに接続されるグラフィックメモリを含んでもよく、これは「ローカルビデオメモリ」と典型的に呼ばれる。他の例では、既知のインテル（登録商標）ハブアーキテクチャを有するチップセットでは、システムメモリの一領域が指定されたＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）メモリがグラフィックメモリとして利用される。ＡＧＰメモリはまた、「非ローカルビデオメモリ」と呼ばれるかもしれない。

グラフィックプロセッサは、典型的には、ある期間グラフィックメモリのグラフィックデータのエイリアスコピー上で動作する。典型的には、このグラフィックデータのエイリアスコピーを有するグラフィックメモリが、ホストＣＰＵのメモリページ属性テーブルのアンキャッシュ属性に割り当てられ、このことはグラフィックデータへのアプリケーションアクセスは、当該データがグラフィックプロセッサにより処理されるアンキャッシュグラフィックメモリ領域にある間、ホストＣＰＵのキャッシュを利用しないということを意味する。このアンキャッシュエイリアスコピーはある期間グラフィックプロセッサにより処理された後、グラフィックデータのさらなる処理のため、典型的にはアプリケーションに戻す必要がある。しかしながら、上述の実現形態によると、アプリケーションは、システムメモリのグラフィックデータのコピー上で動作する。このシステムメモリは、典型的には、ＣＰＵがキャッシュモードでアプリケーションの処理を実行できるように、キャッシュ属性に割り当てられていた。周知のように、ＣＰＵによるキャッシュ処理はアンキャッシュ処理よりＣＰＵがより効率的になることを可能にする。

アプリケーションがグラフィックプロセッサの後のグラフィックデータ上での動作を継続できるように、もちろん、グラフィックプロセッサによるエイリアスコピーへの変更はアプリケーションにより使用されるシステムメモリのコピーに反映する必要がある。

アプリケーションは、キャッシュモードではある期間においてシステムメモリのコピーの処理を継続し、その後再び処理をグラフィックプロセッサに引き継ぐかもしれない。当然のことながら、システムメモリのコピーに対する変更は、グラフィックプロセッサが再び引き継ぐとき、グラフィックメモリのエイリアスコピーに反映されねばならない。アプリケーションとグラフィックプロセッサとの間の上記やりとりは何回も繰り返されるかもしれない。

上記構成は問題点を有すると認識されるであろう。１つの問題点は、同一のグラフィックデータの２つのコピーが維持される必要があり、貴重なシステムメモリリソースが消費されるというものである。さらに、これら２つの別々のコピーの生成及び維持において、特に複数のインタフェース間のバスを介した２つのコピー間の各更新の伝搬において、貴重なＣＰＵ帯域幅が消費される。

上述の２つのグラフィックデータのコピーの維持を伴わない実現形態が知られている。そのような実現形態の１つによると、キャッシュ可能なシステムメモリがグラフィックメモリとして利用するためグラフィックプロセッサに利用可能となり、グラフィックプロセッサとホストＣＰＵは、グラフィックメモリのグラフィックデータに対して処理を実行する。前述のように、グラフィックプロセッサとホストＣＰＵは、交替でグラフィックデータに対する処理を行う。当該メモリはキャッシュ可能であるため、ＣＰＵは効率性の向上のためキャッシュモードでの動作が可能である。

しかしながら、このアプローチはデータ「一貫性の欠如（ｉｎｃｏｈｅｒｅｎｃｙ）」の可能性を生じる。すなわち、ＣＰＵはキャッシュモードでグラフィックメモリを利用するため、グラフィックプロセッサが処理の実行を依頼されたデータはまだフラッシュ（すなわち、キャッシュから消去され、グラフィックメモリに書き込まれる）されていないかもしれない。むしろ、データはＣＰＵ内部とＬ１及びＬ２キャッシュ間頂点のどこかに配置され、実際にはグラフィックメモリにはまだ届いていないかもしれない。従って、グラフィックプロセッサが必要なデータに処理を実行するためグラフィックメモリにアクセスするとき、この必要なデータの最も最近のものを検出することができないかもしれない。代わりに、グラフィックメモリのデータは「古い（ｓｔａｌｅ）」ものであるかもしれない。さらに悪いことに、グラフィックプロセッサがデータ位置へのアクセスを完了した直後に、キャッシュからデータが除去され、これにより当該処理が無効となるかもしれない。

一貫性欠如の問題を処理するため、チップセットの「スヌープサイクル（ｓｎｏｏｐ ｃｙｃｌｅ）が利用されてきた。スヌープサイクルは、グラフィックプロセッサがグラフィックメモリへのアクセスを許可される前に、グラフィックプロセッサがチップセットにグラフィックメモリに関するＣＰＵキャッシュの一貫的にすることに関するものである。しかしながら、スヌープサイクルは、システムパフォーマンスを低下させるかなりのオーバヘッド量を必要とする欠点を伴う。スヌープサイクルは、位置単位でメモリデータを調べ、必要とされる位置のデータが依然としてＣＰＵのキャッシュにある場合、それは抽出され、一貫的とされる。このような処理はインタフェース間の多くの「ハンドシェイク（ｈａｎｄｓｈａｋｅ）」を必要とし、それらは位置単位あるいはライン単位で実行されなければならないため非効率である。

他の実現形態によると、グラフィックメモリは厳密にアンキャッシュモードで使用される。この方法では、グラフィックメモリのデータは、ＣＰＵがグラフィックメモリに対してデータの読み出しまたは書き込みを所望するときはいつでも、この書き込み処理は常に直接的に即座にグラフィックメモリに行われ、キャッシュ処理されないため、一貫性を維持する。しかしながら、この方法に関する１つの欠点は、キャッシュ処理によるＣＰＵパフォーマンスの向上が利用できないということである。

上記考察により、既存の実現形態の問題点を解消する方法及びシステムが求められる。
［詳細な説明］
本発明による方法及びシステムの実施例において、最適に共有化されたグラフィックメモリがホストＣＰＵあるいはグラフィックプロセッサにより使用されるかどうかに依存して割り当てられるキャッシュ属性を有する最適共有化グラフィックメモリが提供される。最適共有化メモリに割り当てられる属性は、当該メモリがＣＰＵにより使用されているときにはＣＰＵのパフォーマンスに有利に、また当該メモリがグラフィックプロセッサにより使用されているときにはグラフィックプロセッサのパフォーマンスに有利となるよう選択される。

この実施例によると、最適共有化メモリの割り当てられたキャッシュ属性は、当該メモリをホストＣＰＵが使用しているモードと、当該メモリをグラフィックプロセッサが使用しているモードとの間の移行中に変更されるかもしれない。

ＣＰＵによる使用中に最適共有化メモリに割り当てられる属性は、キャッシュ属性であるかもしれない。ここで、「キャッシュ属性」とは、ＣＰＵによる動作をそれの内部クロック速度で可能にするため、最適共有化メモリ宛のデータ部分がまずＣＰＵのキャッシュに転送され、そこで機能するようにされる。グラフィックプロセッサが最適共有化メモリのデータ上で動作するモードへの移行の発生時には、ＣＰＵキャッシュのデータは一貫性を有するようにされ、最適共有化メモリの割り当てられたキャッシュ属性はアンキャッシュ属性に変更される。ここで、「アンキャッシュ属性」とは、読み出し及び書き込み動作に対して、ＣＰＵのキャッシュからデータをフェッチしないということを意味する。むしろ、データは、キャッシュが存在しなかったかのように、外部のシステムメモリバスを介してシステムメモリに直接流出する。

他の実施例では、最適共有化メモリは常にキャッシュ属性に割り当てられるが、グラフィックプロセッサが最適共有化メモリのデータ上で動作するモードへの移行の発生時には、ＣＰＵのキャッシュのデータは一貫性を有するようにされる。この移行が行われる前に一貫性を確立することの効果は、グラフィックプロセッサのＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）はそれがあたかもすでに一貫性を備えているかのように最適共有化メモリを扱うことが可能であるため、スヌープサイクルとそれに関するパフォーマンスの低下が回避されうるということである。これにより、グラフィックコントローラからのＣＰＵキャッシュのサイクルのスヌープ処理の実行が不要となり、最適共有化メモリはあたかもそれがアンキャッシュ属性により使用されていたかのように効果的に扱われるかもしれない。

図１及び図２の以下の説明は、従来技術により「共有可能な（ｓｈａｒｅａｂｌｅ）」グラフィックメモリ領域がどのように与えられるかを説明するものである。以下で用いられる「共有可能」とは、以降においてより詳細に説明されるように、本発明の実施例による「最適共有化（ｏｐｔｉｍａｌｌｙ ｓｈａｒｅｄ）」と区別するためのものであるということは理解されるべきである。

図１は、商業的に入手可能であり、本発明の実施例の実現に適したインテルコーポレーションにより製造されるコンピュータシステムの各種要素を示す。図１に示されるブロック１１０は、グラフィック機能がシステム全体に統合されている「統合グラフィック」システムの要素を示す。より詳細には、グラフィックプロセッサは、チップセットのメモリコントローラハブ（ＭＣＨ）コンポーネントに統合されてもよい。

図１に示されるシステムでは、共有可能なグラフィックメモリは以下のように与えられる。グラフィックプロセッサページトランスレーションテーブル（ＧＴＴ）１０７は、グラフィックプロセッサユニット（ＧＰＵ）パイプライン１０９を介しグラフィックプロセッサにアクセス可能である。ＧＴＴ１０７は、トランスレーションルックアサイドバッファ（ＴＬＢ）１０８を用いて、物理的アドレス空間１００のグラフィックアパーチャ（ｇｒａｐｈｉｃｓ ａｐｅｒｔｕｒｅ）１０６にシステムメモリページ１０２をマッピングする。グラフィックアパーチャ１０６のアドレスは、システムメモリの最上位より高位なものである。グラフィックアパーチャ１０６は、グラフィックプロセッサにとって「可視的（ｖｉｓｉｂｌｅ）」なものである（すなわち、対応するシステムメモリページへのアクセスに利用することができる）。

グラフィックアパーチャ１０６はまた、ホストＣＰＵページテーブル１０４に保持されるマッピング（ＧＴＴ１０７のマッピングに対応する）を介してホストＣＰＵに可視的なものである。ホストＣＰＵページテーブル１０４は、ホストＣＰＵパイプライン１０３を介しホストＣＰＵにアクセス可能である。ページテーブル１０４は、トランスレーションルックアサイドバッファ（ＴＬＢ）１０５を利用し、システムメモリページ１０２の直接的マッピングを維持する。ここで、このマッピングは「バーチャルマッピング（ｖｉｒｔｕａｌ ｍａｐｐｉｎｇ）」と呼ばれる。グラフィックアパーチャに対してＧＴＴ１０７により維持されるマッピングと、ホストＣＰＵページテーブル１０４により維持されるバーチャルマッピングは、各自が物理的アドレス空間の非重複領域のアドレスにマッピングするため互いに異なるが、各々は同一のシステムメモリページに対応している。何れのマッピングもホストＣＰＵにより実行されるアプリケーションにとって可視的なものである。従って、グラフィックプロセッサとホストＣＰＵの両方に可視的な共有可能なメモリの領域が提供されてもよい。

統合されたグラフィックを利用する他の実施例では、グラフィックプロセッサとホストＣＰＵの両方に可視的なグラフィックアパーチャのマッピングのみが提供されるかもしれない。

図２は、共有可能なグラフィックメモリを提供するシステムの他の可能な実施例を示す。図２の実施例では、グラフィック機能はシステム全体に統合されてはいないが、代わりに独立した「アドイン（ａｄｄ−ｉｎ）」グラフィックカードにより提供されている。このアドインカードは、コンピュータシステム全体のＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（１．Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔインタフェース仕様書，改訂版１．０，インテルコーポレーション，１９９６年７月３１日、２．Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔインタフェース仕様書，改訂版２．０，インテルコーポレーション，１９９８年５月４日、３．改訂版３．０起案０．９５，インテルコーポレーション，２００１年６月１２日、等を参照せよ））、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｐｏｒｔ（ＰＣＩ ＳＧＩ（Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ）ＰＣＩローカルバス仕様書，改訂版２．２，１９９８年１２月１８日発行、ＢＣＰＲサービス印コーポレーションＥＩＳＡ仕様書，３．１２版，１９９２年発行、ＵＳＢ仕様書，１．１版，１９９８年９月２３日発行、または他の同様の周辺バスに関する仕様書などを参照せよ））、他の「ソケット」、あるいはアダプタインタフェースにプラグインされてもよい。

図２に示されるアドインカードシステムでは、共有可能なグラフィックメモリは以下のように与えられる。ＧＡＲＴ（Ｇｒａｐｈｉｃｓ Ａｐｅｒｔｕｒｅ Ｒｅｌｏｃａｔｉｏｎ Ｔａｂｌｅ）２０９は、システムメモリページ２０２を物理的アドレス空間２００のＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）メモリエリア２０５にマッピングする。ＡＧＰメモリエリア２０５は、グラフィックプロセッサユニット（ＧＰＵ）パイプライン２０６とＡＧＰバスを介してグラフィックプロセッサに可視的なものである。

ＡＧＰメモリエリア２０５はまた、ＣＰＵパイプラインに関連したホストＣＰＵに対し可視的なものである。ＣＰＵパイプライン２０３にアクセス可能なホストＣＰＵページテーブル２０４は、ＡＧＰメモリ２０５の（ＧＡＲＴ２０９のマッピングに対応する）マッピングを維持する。ページテーブル２０４はまた、システムメモリページ２０２の直接的なマッピング（すなわち、上述のような「バーチャルマッピング」）を維持する。ＡＧＰメモリエリア２０５に対してＧＡＲＴ２０９により維持されるマッピングと、ホストＣＰＵページテーブル２０４により維持されるバーチャルマッピングは、各自が物理的アドレス空間の非重複領域のアドレスをマッピングするため互いに異なるものであるが、各々は同一のシステムメモリページに対応する。両方のマッピングは、ホストＣＰＵにより実行されるアプリケーションにより可視的なものである。従って、グラフィックプロセッサとホストＣＰＵの両方に可視的な共有可能なメモリが与えられてもよい。

図２に示されるようなアドインカードシステムはまた、グラフィックアパーチャ２０７にマッピングされるローカルビデオメモリ２０８を有するようにしてもよい。

前述のように、ＣＰＵとグラフィックプロセッサは、メモリの同一領域のデータに対して処理を実行するようにしてもよい。各アクセスは、典型的には、同時でなく逐次的に実行される。すなわち、典型的には、ＣＰＵにより実行されるアプリケーションは、グラフィックプロセッサによる処理を必要となするデータを生成し、ＣＰＵが当該データをグラフィックメモリに書き込むようにしてもよい。そのとき、アプリケーションは、グラフィックプロセッサに当該データによるレンダリング機能の実行を要求し、グラフィックプロセッサに対する処理を「ハンドオフ（ｈａｎｄ ｏｆｆ）」してもよい。グラフィックプロセッサが要求された処理の実行を完了すると、次にアプリケーションに処理をハンドオフするようにしてもよい。

上記ハンドオフ処理を考慮するに、本発明の実施例は共有可能なメモリを最適な方法により利用することを可能にする。従って、以降では、共有可能なメモリが本発明の実施例に従って生成または修正される場合には、当該メモリは「最適共有化メモリ」と呼ばれる。

図３は、本発明の実施例によるＣＰＵとグラフィックプロセッサとの間のハンドオフ処理を示す状態図である。図３は、最適共有化メモリをホストＣＰＵが使用しているモードと、最適共有化メモリをグラフィックプロセッサが使用しているモードとの間の移行を示している。便宜上、ＣＰＵが最適共有化メモリを使用しているとき、当該メモリは「ＣＰＵビュー（ＣＰＵ ｖｉｅｗ）」、「ＣＰＵ最適化ビュー（ＣＰＵ ｏｐｔｉｍｉｚｅｄ ｖｉｅｗ）」または「ＣＰＵ最適ビュー（ＣＰＵ ｏｐｔｉｍａｌ ｖｉｅｗ）」にあると呼ばれ、グラフィックプロセッサが最適共有化メモリを使用しているとき、当該メモリは「グラフィックビュー（ｇｒａｐｈｉｃｓ ｖｉｅｗ）」、「グラフィック最適化ビュー（ｇｒａｐｈｉｃｓ ｏｐｔｉｍｉｚｅｄ ｖｉｅｗ）」または「グラフィック最適ビュー（ｇｒａｐｈｉｃｓ ｏｐｔｉｍａｌ ｖｉｅｗ）」にあると呼ばれるかもしれない。

楕円３０２は、最適共有化メモリがグラフィックプロセッサビューにある期間を表す。当該ビューは、最適共有化メモリのキャッシュ属性がグラフィックプロセッサのパフォーマンスに有利となるように割り当てられているという点で「最適化」されているかもしれない。

最適共有化メモリのグラフィック最適化ビューとＣＰＵ最適化ビューとの間の移行段階が存在するかもしれない。本発明の実施例によると、ＣＰＵのパフォーマンスに有利な最適共有化メモリの属性は、グラフィック最適化ビューとＣＰＵ最適化ビューとの間の移行段階において割り当てられてもよい。

この移行段階は、楕円３０３に示されるような「ロック（Ｌｏｃｋ）」処理を含むものであってもよい。このロック処理は、本発明の実施例により利用される既知のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を参照する。ＬｏｃｋＡＰＩは、ＣＰＵにより実行されるアプリケーションにより呼び出されてもよい。一般に、ＬｏｃｋＡＰＩは、当該ロックを発したアプリケーションの排他的使用のためメモリ領域を予約する。

楕円３００は、最適共有化メモリがＣＰＵビューにある期間を表す。本発明の実施例によると、このＣＰＵビューは、最適共有化メモリのキャッシュ属性がＣＰＵのパフォーマンスに有利となるよう割り当てられているという点で「最適化」されている（例えば、最適共有化メモリがキャッシュ処理されてもよい）。特に、例えば、最適共有化メモリはホワイト−ブラック（Ｗｈｉｔｅ−Ｂｌａｃｋ）属性に割り当てられてもよい。

最適共有化メモリのＣＰＵ最適化ビューとグラフィック最適化ビューとの間には移行段階があってもよい。本発明の実施例によると、グラフィックプロセッサのパフォーマンスに有利な最適共有化メモリの属性は、ＣＰＵ最適化ビューとグラフィック最適化ビューとの間の移行段階中において割り当てられてもよい。

この移行段階は、楕円３０１に示されるような「アンロック（Ｕｎｌｏｃｋ）」処理を含むものであってもよい。アンロック処理は、本発明の実施例により利用される既知のＡＰＩを参照する。ＵｎｌｏｃｋＡＰＩは、ＣＰＵにより実行されるアプリケーションにより呼び出されてもよい。一般に、ＵｎｌｏｃｋＡＰＩは、以前に実行されたＬｏｃｋＡＰＩのアンドゥまたはリバースを行う。アプリケーションは、グラフィックプロセッサに当座はＣＰＵが最適共有かメモリを使用しておらず、最適共有化が現在グラフィックプロセッサによりアクセス可能であるということを通知するため、ＵｎｌｏｃｋＡＰＩを呼び出すようにしてもよい。

本発明の実施例によると、ＣＰＵ最適化ビューからグラフィック最適化ビューへの移行段階中に、キャッシュ一貫性が、以降においてより詳細に説明されるように、最適共有化メモリに課されるかもしれない（すなわち、ＣＰＵキャッシュの必要なデータがメモリに戻されるということが保証されるかもしれない）。

グラフィック「サーファスまたは面（ｓｕｒｆａｃｅ）」は、上述のようなＣＰＵ最適化ビューとグラフィック最適化ビューとの間の移行が行われた最適共有化メモリにあるデータの一種である。しかしながら、一般に、グラフィックサーファスは、共有化メモリに配置される必要はない。

グラフィックサーファスは、様々な目的から利用される。サーファスは、アプリケーションからグラフィックプロセッサに送信されるコマンド、画素または頂点などのデータのバッファであるかもしれない。サーファスは、出力表示装置に表示されるか、あるいは単にアプリケーションに返すレンダリングの結果を含んでもよい。サーファスは、グラフィックプロセッサの中間結果の一時的格納のため生成され、それ自体グラフィックプロセッサに可視的なものである必要はない。

図４Ａは、「矩形サーファス」と通常呼ばれるグラフィックサーファス４００の一例を示す。矩形サーファスは、典型的には、画素からなる所定のピッチと幅により走査線に水平に構成されるグラフィック画素を有する。複数の走査線がサーファスを形成するため垂直的に結合されてもよい。このようなグラフィックサーファスは、典型的には、所与の水平方向の幅と垂直方向の走査線カウントを有する出力表示装置への伝達を可能にするように、あるいは以降の処理において表示または利用される他のサーファス上へのテクスチャパッチなどのサーファスのレンダリングを可能にするように構成されてもよい。

グラフィックサーファスのエリアは、ベースメモリアドレス４０１からのそれのオフセットと、サーファスのベースメモリ位置４０１からのエンドポイント４０２のオフセットに関して通常定義されるそれのサイズにより定義されるかもしれない。画成されたサブエリアが、画成されたサブエリア４０３などのサーファス内に定義されてもよい。画成されたサブエリアは、グラフィックアプリケーションやグラフィックプロセッサが当該サブエリア上で動作しているとき、「アクティブ状態」であるといわれる。画成されたサブエリアのメモリ位置は、当該サブエリアのベース座標ｘとｙ、これらベース座標からのオフセットｗとｈに関して定義されてもよいし、あるいは画成されたサブエリアの上端、左端、右端及び下端の座標として表現されてもよい。上記座標システムはまた、サーファス原点に対する矩形の四方の座標によりサーファス全体を記述するのに利用することができる。以降では、矩形サーファスやサブエリアの表現は、パラメータの略記であるＲＥＣＴ（ｔ，ｌ，ｂ，ｒ）により参照されるであろう。ここで、ｔ，ｌ，ｂ，ｒはそれぞれ、サーファス原点に対する矩形の上端、左端、右端及び下端の座標を示す。

図４Ｂは、「リニアサーファス」と通常呼ばれるグラフィックサーファス４１０の他の可能な構成を示す。グラフィックサーファス４１０では、画成されたサブエリア４１１が当該サーファスのピッチに沿って伸びている。画成されたサブエリア４１１に対して、Ｓｔａｒｔ ＯｆｆｓｅｔアドレスとＬｅｎｇｔｈが指定されてもよい。サーファスの画素のアドレス位置は、Ｓｔａｒｔ ＯｆｆｅｓｔアドレスからＥｎｄアドレスまで線形にインクリメントされる。以降では、サブエリアの表現は、パラメータの略称であるＬＩＮ（ｏ，ｌ）により参照される。ここで、ｏとｌはそれぞれ、サーファスの原点に対するＳｔａｒｔ−Ｏｆｆｓｅｔと、Ｓｔａｒｔ−Ｏｆｆｓｅｔに対するサブエリアの長さを表す。このようなサーファスは、典型的には、レンダリングコマンドのリスト、頂点あるいは頂点インデックスのリスト、あるいは映像またはテクスチャ圧縮技術を用いた圧縮画素データなどのグループ化されたグラフィカルデータを伝達するバッファに対して利用される。

図３に関して説明されたＬｏｃｋＡＰＩ及びＵｎｌｏｃｋＡＰＩは、特定のパラメータが指定されることを可能とするものであってもよい。これらのパラメータは、例えば、ロックまたはアンロック対象のサーファス内の画成されたサブエリアのみの詳細、ロックまたはアンロック対象のサーファス全体の詳細を含むものであってもよい。通常、ＬｏｃｋＡＰＩとそれに続くＵｎｌｏｃｋＡＰＩは、ロックまたはその後のアンロック対象の同一の画成されたサブエリアまたはサーファス全体を指定する。

グラフィックサーファスが生成され、アプリケーションが当該サーファス内部の画素を処理するとき、サーファスの一部はある期間においてホストＣＰＵのキャッシュに置かれるかもしれない。当該キャッシュ内部では、ユニットとして扱われるサーファスデータの一部は当該データの「粒度（ｇｒａｎｕｌａｒｉｔｙ）」と呼ばれる。図５は、画成されたサブエリア４０３などの画成されたサブエリアがキャッシュには位置されている間での画成されたサブエリアの一例を示す。走査線Ｎ及びＮ＋１は画素を有し、画成されたサブエリア４０３の上に位置する。

さらに、画成されたサブエリア内の走査線Ｎ＋１の範囲は、走査線が「上部（ｕｐｐｅｒ）」セグメント、「全体（ｗｈｏｌｅ）」セグメント及び「下部（ｌｏｗｅｒ）」セグメントにより構成されるものとしてどのようにみることができるか示す。「上部」及び「下部」の各セグメントは、キャッシュラインの長さより小さい範囲を有し、「全体」セグメントはキャッシュラインの長さに等しい範囲を有する。

１つのキャッシュラインからすべてのラインまでの特定の粒度に基づきキャッシュ内のデータラインの低レベルでの制御を可能にするキャッシュ制御「プリミティブ（ｐｒｉｍｉｔｉｖｅｓ）」が存在する。このようなプリミティブは、キャッシュ内のデータ領域またはキャッシュ全体上でのキャッシュの一貫性を課すため利用されてもよい。例えば、「Ｃａｃｈｅ−Ｌｉｎｅ Ｆｌｕｓｈ（ＣＬＦＬＵＳＨ）」と呼ばれる既知のインテル（登録商標）Ｐｅｎｔｉｕｍ（登録商標）４プロセッサキャッシュ制御指示プリミティブは、供給される論理メモリアドレスパラメータに関するすべてのキャッシュラインに対して、キャッシュラインの長さに等しい粒度によりキャッシュデータをフラッシュする。

好ましくは、本発明の実施例によると、サーファスの画成されたサブエリアは、ＣＬＦＬＵＳＨなどのプリミティブを用いることにより、キャッシュラインの長さあるいはそれ以下のセグメントにおいて一貫性を備えるようにしてもよい。そのようなアプローチは、画成されたサブエリアをキャッシュラインの長さあるいはそれ以下のセグメントにおいて一貫性を備えるようにするための時間が、より粗い粒度を有するプリミティブを利用することにより、あるいはＬ１/Ｌ２キャッシュ全体をフラッシュすることにより画成されたサブエリアを一貫性を備えるようにするための時間より少ない場合には、特に効果的である。

他方、上述のような画成されたサブエリアをセグメントにおいて一貫性を有するようにするのに要する時間が、単にＬ１/Ｌ２キャッシュ全体をフラッシュするのに要する時間を超えるようにすることができる。与えられた画成されたサブエリアをセグメントにおいて一貫性を有するようにするために必要な最大時間が、外部のメモリバスのスピードと幅及び外部バスの幅単位で一貫性を課す対象となるキャッシュエリアのサイズに基づき計算することができる。キャッシュ全体をフラッシュするのに要する最大時間は、キャッシュサイズ及び外部のメモリバススピードと幅、それらと共に他のプロセッサのオーバヘッドに基づき同様にして計算することができる。以下で詳細に説明されるような本発明の実施例によると、所与の画成されたサブエリアをセグメントにおいて一貫性を有するようにするのに必要な最大時間が、キャッシュ全体をフラッシュするのに要する最大時間と比較され、最小時間で済むアプローチを用いて、この画成されたサブエリアを一貫性を有するようにしてもよい。

他のプリミティブとして、ページの粒度によりキャッシュデータをフラッシュする「Ｃａｃｈｅ Ｐａｇｅ Ｆｌｕｓｈ（ＣＰＦＬＵＳＨ）」が知られている。所与の状況下において、Ｃａｃｈｅ Ｐａｇｅ Ｆｌｕｓｈは、Ｃａｃｈｅ−Ｌｉｎｅ Ｆｌｕｓｈより高速かつ効率的であるかもしれない。同様に、より大きな粒度のキャッシュフラッシュが容易に考えられるであろう。例えば、「Ｐｈｙｓｉｃａｌ Ａｄｄｒｅｓｓ Ｒｅｇｉｏｎ Ｃａｃｈｅ−Ｆｌｕｓｈ」プリミティブは、メモリなどの物理的ページ（例えば、４ＫＢ）に関するグラフィック画素データのすべてのラインに対して一貫性を効率的に課すことができる。

本発明の実施例による最適共有化メモリが、異なる状況下において生成及び利用されてもよい。アプリケーションは、それが最適共有化メモリの生成及び利用を所望していることを明示的に指定するようにしてもよい。他方、最適共有化メモリは、意識することなく、すなわち、アプリケーションが最適共有化メモリを使用しているということを意識することなくアプリケーションに与えられているようにしてもよい。

前者の場合、グラフィックドライバは、まずアプリケーションに対してグラフィックサブシステムによりサポートされているサーファスタイプのリストを列挙または「アドバイス」し、その後、アプリケーションはこのリストから「最適共有化」タイプを選択し、この最適共有化タイプのメモリ領域の割り当てをリクエストする。最適共有化メモリ領域を割り当てるため、アプリケーションはグラフィックドライバに対するＡＰＩを介して、以前に列挙された最適共有化タイプを有するメモリ領域を要求するようにしてもよい。例えば、アプリケーションは、最適共有化メモリタイプを有するグラフィックサーファスの生成をリクエストするようにしてもよい。

後者の場合には、アプリケーションには上述のような列挙されたリストは提示されず、代わりに、最適共有化メモリがアプリケーションのためのグラフィックドライバにより意識することなく、あるいは「水サーファス下で」提供されてもよい。グラフィックドライバは、アプリケーションから受信する情報に基づく「利用ポリシー」に従って最適共有化メモリの使用を決定するようにしてもよい。例えば、列挙されたリストから最適共有化メモリタイプを明示的に選択する代わりに、アプリケーションはグラフィカルＡＰＩのアプリケーションからグラフィックドライバにわたされる「ヒント」を通じてグラフィックサーファスをどのように使用するか示すようにしてもよい。ヒントの例としては、例えば、アプリケーションがサーファスから読み出し/書き込みを行っていること、あるいはサーファスが不透明であることを示す情報があげられる（書き込み専用、すなわち例えば、グラフィックプロセッサのレンダリングのターゲットとしてのみ利用され、アプリケーションによっては読み返されない）。ヒントに基づき、グラフィックドライバは、アプリケーションに対して意識させることなく、最適共有化メモリサーファスを割り当て、どのようにしてパフォーマンスを最も良く向上させられるかの評価に基づきそれのキャッシュ属性を割り当てるようにしてもよい。

他の実施例では、グラフィックドライバは、利用と要求を判断することにより、一つのメモリタイプまたは位置で以前に生成されたグラフィックメモリが最適共有化タイプへの変更により良好に適しているということを決定するようにしてもよい。それ以降のある時点で、アプリケーションのアクセス利用パターンにおける転換に基づき、当該グラフィックメモリタイプはもとのタイプ及び/または位置に戻るように変更されてもよい。

前述のように、本発明の実施例では、最適共有化メモリは、それがＣＰＵまたはグラフィックプロセッサにより使用されるかに依存して割り当てられるキャッシュ属性を有するようにしてもよい。ＣＰＵビューとグラフィックプロセッサビューとの間の移行が発生すると、割り当てられた属性が変更されるかもしれない。この移行がＣＰＵビューからグラフィックプロセッサビューへのものであるとき、ＣＰＵのキャッシュの中のデータは、最適共有化メモリがグラフィックプロセッサに対してハンドオフされる前に、一貫性を有するようにしてもよい。このような実施例は、例えば、アプリケーションが最適共有化メモリを所望することを明示的に指定せず、代わりにグラフィックドライバが最適共有化メモリの使用を動的に決定するとき（例えば、上述のヒントを通じて）、効果的に利用されるかもしれない。このような場合、グラフィックメモリはすでに「古い」、すなわち、他のタイプとして使用されていることになるであろう。

他方、他の実施例によると、最適共有化メモリは常にキャッシュ属性を有するかもしれない（すなわち、割り当てられた属性に変更がない）。このような実施例は、例えば、アプリケーションが最適共有化メモリの生成及び利用を所望しているということを発生から決定するとき、効果的に利用されるかもしれない。そのような実施例は、ＣＰＵビューからグラフィックプロセッサビューへの移行が発生すると、ＣＰＵのキャッシュの中のデータが、最適共有化メモリがグラフィックプロセッサに対してハンドオフされる前に、一貫性を有するようにされてもよい。スヌープサイクルをトリガーしないために、グラフィックプロセッサのメモリインタフェースエンジンは、プログラム可能なＤＭＡレジスタ設定、グラフィックプロセッサページテーブルエントリのページ属性、あるいは他の手段を通じて、最適共有化メモリがグラフィックプロセッサビューにあるとき、あたかもこの最適共有化メモリがアンキャッシュされているかのように最適共有化メモリを扱うよう指示されてもよい。ほとんどのプロセッサは、一貫性の問題に対する大部分の解決法がグラフィックメモリをアンキャッシュとして利用することに関するものであるため、典型的には、ＣＰＵのページテーブルキャッシュ属性設定とは独立に、グラフィックメモリをアンキャッシュとして扱うことをサポートしている。しかしながら、このメモリに対するＣＰＵのページテーブルエントリでは、当該メモリはキャッシュ属性を継続して有する。

割り当てられた属性がＣＰＵビューとグラフィックプロセッサビューとの間の移行中に変更される実施例が、以下においてより詳細に説明される。

図６は、サーファスがどちらのビューにあるかに依存して最適共有化メモリサーファスのキャッシュ属性を設定するプロセスフローを示す。

ブロック６００に示されるように、最適共有化サーファスが初期的に生成される。サーファスの生成時に、処理を容易にするため各種データ構造が当該サーファスと関連付けされる。例えば、一実施例によると、一意的な識別子または「Ｓｕｒｆａｃｅ ｈａｎｄｌｅ」がサーファスに関連付けされ、当該サーファスへのポインタとして機能する。この「Ｓｕｒｆａｃｅ ｈａｎｄｌｅ」はさらに、「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ ｈａｎｄｌｅ」にポインタ指定され、次に「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」にポインタ指定される。「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」は、メモリタイプ記述子（例えば、当該メモリが最適に共有化されているかなど）、サーファスのメモリベースオフセット、画素深さ、サイズ（幅、高さ）及び当該サーファスの他の特性などの情報を含むプライベートデータ構造を含むものであってもよい。このプライベートデータ構造はまた、「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」に関する情報を有する「メンバー」を含むものであってもよい。

最適共有化メモリサーファスがブロック６００に示されるように生成された後、ブロック６０１において決定されるように、当該メモリの属性がこのサーファスがどちらのビューにあるかに依存して設定されてもよい。

サーファスがグラフィックプロセッサのビューにある場合、ブロック６０２に示されるように、当該サーファスの属性は「Ｗｒｉｔｅ−Ｃｏｍｂｉｎｅ」（またはアンキャッシュ）属性に設定されてもよい。その後、「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」内で、ブロック６０４に示されるように、このメモリがグラフィックプロセッサの使用のため現在最適にマッピングされているということを示すタイプ記述子「ｔａｇ」が設定される。

他方、サーファスがＣＰＵのビューにある場合、当該サーファスの属性は、ブロック６０３に示されるように、「Ｗｒｉｔｅ−Ｂａｃｋ」（キャッシュ）属性に設定され、そしてブロック６０５に示されるように、当該サーファスがＣＰＵの利用に対して現在最適にマッピングされていることを示す「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」タイプ記述子がタグ付けされる。

サーファスが生成されると、アプリケーションは、ＬｏｃｋＡＰＩまたはＵｎｌｏｃｋＡＰＩを呼び出すことにより、サーファスのロックまたはアンロックを要求するかもしれない。ＬｏｃｋＡＰＩとＵｎｌｏｃｋＡＰＩは、典型的には、Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔのｈａｎｄｌｅや「Ｂｏｕｎｄｅｄ Ａｒｅａ」パラメータなどのパラメータを含む。「Ｂｏｕｎｄｅｄ Ａｒｅａ」パラメータは、前述のようなサーファスのサブエリアを記述するものである。サーファスのロック処理は、アプリケーションによるサーファスへのデータの書き込みを可能にする。

最適共有化メモリがＣＰＵにより初期的に使用され、当該最適共有化メモリが初期的にキャッシュモードで使用されていたと仮定すると、アプリケーションが最適共有化メモリへのさらなるアクセスを少なくとも当座は実行しない処理のあるポイントに到達すると、その後アプリケーションはグラフィックプロセッサに処理をハンドオフするかもしれない。そうするため、アプリケーションは、ＵｎｌｏｃｋＡＰＩを呼び出し、グラフィックプロセッサに最適共有化メモリ領域が現在アクセス可能であるということを通知する。Ｕｎｌｏｃｋ処理では、グラフィックドライバは、アプリケーションがサーファスの変更処理を完了し、当該サーファスがもはやＣＰＵによりアクセスされないということを暗黙的に知る。このため、ＣＰＵビューに有利なキャッシュ属性を有するサーファスに割り当てられた最適共有化メモリは、グラフィックプロセッサビューに有利なものに変更されたキャッシュ属性を有するかもしれない。

共有化メモリのキャッシュ属性がＣＰＵ最適化モード（すなわち、キャッシュ）からグラフィックプロセッサ最適化モード（すなわち、アンキャッシュ）に変更されるため、最適共有化メモリは一貫性を有するようにされるべきである。

図７Ａは、プロセスが一貫性を課すようにメモリのキャッシュ属性の変更を含むときに、ＣＰＵビューからグラフィックプロセッサビューに最適共有化メモリを変換するプロセスフローを示す。ブロック７０１に示されるように、まずＣＰＵにより処理される共有化メモリの一領域がサーファス全体であるか、あるいは単なるサーファスのサブエリアであるか判断される。このサブエリアまたはサーファス全体は、上述のＬｏｃｋＡＰＩとＵｎｌｏｃｋＡＰＩにわたされる「Ｂｏｕｎｄｅｄ Ａｒｅａ」または「Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ」パラメータに対応するかもしれない。

最適共有化メモリ領域がサブエリアである場合、ブロック７０２に示されるように、当該サブエリアのスタート及びエンドアドレスが計算される。図４Ａに関して説明されたように、サブエリアは、当該サブエリアの位置とサイズを記述するＲＥＣＴ（ｔ，ｌ，ｂ，ｒ）パラメータにより記述されてもよい。あるいは、図４Ｂで説明されたように、サブエリアは、サーファスベースアドレスとＬｅｎｇｔｈパラメータからのＳｔａｒｔ Ｏｆｆｓｅｔにより記述されてもよい。その後、当該プロセスフローはブロック７０３に進む。

他方、最適共有化メモリ領域がサブエリアでない（すなわち、それがサーファス全体である）場合、プロセスフローはブロック７０３に直接進む。ブロック７０３において、開始ページがメモリの開始アドレスから、当該アドレスをページにより揃えられたスタートにダウン調整することにより導出されてもよい。これは、典型的には、当該アドレスの最下位ビットをページサイズまで破棄することにより行われる。例えば、ページが４ＫＢである場合、当該アドレスと（４ＫＢ−１）のページ粒状スタートアドレスの１の補数逆元とのビット単位のＡＮＤ演算により、「ａｄｄｒ」が導出できる。

次に、ブロック７０４に示されるように、アドレス「ａｄｄｒ」を有するキャッシュラインが、例えば、「ａｄｄｒ」パラメータを「ＣＬＦＬＵＳＨ」のようなキャッシュラインフラッシュプリミティブにわたすことによりフラッシュされてもよい。

キャッシュラインのフラッシュ処理は、ブロック７０５と７０６に示されるように、すべてのキャッシュラインがフラッシュされるまで継続されてもよい。ブロック７０５において、フラッシュされるべきキャッシュラインが残っているか判断される。ブロック７０５の判定結果が肯定的なものである場合、サブエリアの次のラインが、ブロック７０６に示されるように、「ａｄｄｒ」パラメータをインクリメントすることによりフラッシュされ、ブロック７０４に戻るようにしてもよい。

すべてのキャッシュラインがフラッシュされると、プロセスフローはブロック７０７に進み、最適共有化メモリのキャッシュ属性がキャッシュ（Ｗｒｉｔｅ−Ｂａｃｋなど）からアンキャッシュ（Ｗｒｉｔｅ−Ｃｏｍｂｉｎｅなど）に変更される。その後、ブロック７０８に示されるように、当該プロセスは、ＩＮＶＬＰＧなどの既知のインテル（登録商標）プロセッサキャッシュ制御指示を用いて、前のキャッシュ属性を有するページＴＬＢ（Ｔｒａｎｓｌａｔｉｏｎ Ｌｏｏｋａｓｉｄｅ Ｂｕｆｆｅｒ）エントリを無効にするようにしてもよい。この処理は、メモリ属性の変更が実効され、インテルプロセッサ通信バスを用いてシステム内の他のＣＰＵへの伝達を可能にするよう実行される。

当該プロセスは、ブロック７０９と７１０に示されるように、最適共有化メモリの各ページに対して継続されるかもしれない。ブロック７０９において、フラッシュされるべきページが残っているか判断される。ブロック７０９の判定結果が肯定的なものである場合、ブロック７１０に示されるように、「ａｄｄｒ」パラメータをインクリメントすることにより次のページがフラッシュされ、ブロック７０４に戻る。

フラッシュされるべきページがもはや残っていない場合、プロセスフローはブロック７１１に進み、当該サーファスに対する以降の処理においてサーファスの現在のビューの追跡を可能にするため、最適共有かメモリが現在グラフィックプロセッサビューにあることを示すＳｕｒｆａｃｅ−Ｏｂｊｅｃｔのメモリタイプ記述子がタグ付けされる。

ある期間最適共有化メモリのデータ上での処理後、グラフィックプロセッサはＣＰＵに最適共有メモリをハンドオフしてもよい。このハンドオフ中、最適共有化メモリのキャッシュ属性がグラフィックプロセッサに有利なものからＣＰＵに有利なものへ変更されてもよい。本発明の実施例によると、ＣＰＵへのハンドオフの移行段階の最中、最適共有化メモリがグラフィック最適化ビューにある間に、グラフィックプロセッサが以前に動作していたサーファスまたはサブエリアが、当該サーファス上のラスタ処理のためアクティブまたはキューされる任意のペンディングレンダリングコマンドに関して、これらコマンドが完了するまで待機することにより同期されてもよい。さらに、グラフィックドライバは、ペンディングされているラスタ処理を追跡し、グラフィックプロセッサに残っているすべての関連する画素にサーファスに移動させ、レンダキャッシュ（ｒｅｎｄｅｒ ｃａｃｈｅ）をフラッシュする。

図７Ｂは、上述のような任意のペンディングされているレンダリングコマンドに関して最適共有化メモリを同期化するため、グラフィックプロセッサビューからＣＰＵビューへの移行段階中に実現される方法の可能な一実施例を示すフロー図である。

ブロック７２１に示されるように、グラフィックプロセッサにより以前に用いられたサーファスが、それに関するペンディングされている処理を有するものとして特定される。これらペンディングされている処理は、当該サーファスに対するグラフィック処理が開始されるとき、以前に設定されたＳｕｒｆａｃｅ−Ｏｂｊｅｃｔ内の記述子とメンバーにより示されてもよい。その後、ブロック７２２に示されるように、当該サーファスに対する任意のレンダリングの出力が緯線としてペンディング状態であるか決定され、この場合、ＣＰＵに戻される前に、サーファスはグラフィックプロセッサに関して一貫性を有するようにされねばならない。ブロック７２２の判定結果が否定的なものである場合、さらなる処理は必要とされない。当該プロセスフローはブロック７２７に進む。

他方、サーファスに対するレンダリングがペンディングされ、まだ完全にはレンダリングされていないサーファス画素とまだメモリに書き戻されていないデータが存在することを示す場合、当該プロセスフローはブロック７２３に進む。ブロック７２３において、当該サーファス内の任意のサブエリアに対するレンダリングがペンディングされているか、グラフィックドライバによりＳｕｒｆａｃｅ−Ｏｂｊｅｃｔのメンバーまたは記述子により蓄積されたプライベートデータを用いて判断される。レンダリングがペンディングされていない場合、当該プロセスフローはブロック７２７に進む。

他方、ブロック７２３の判定結果が肯定的なものである場合、当該プロセスフローはブロック７２４に進む。ブロック７２４において、グラフィックプロセッサにおいて依然としてペンディング中のハンドオフされているサーファスに適用される任意のレンダリングコマンドが処理される。これには、最適共有化サーファスにレンダリングするコマンドと、無関係なサーファスにレンダリングするコマンドの両方を含む。ここでは、最適共有化サーファスの画素が無関係なサーファスに至る結果の生成に利用される。

その後、当該プロセスフローはブロック７２５に進み、以前に特定されたレンダリングコマンドの実行結果、すなわち、レンダリングされた画素が、当該サーファスがグラフィックプロセッサに関して一貫性を有することを保証するため、任意の内部レンダリングキューからフラッシュされる。当該プロセスフローはブロック７２６に続き、レンダリングコマンドとレンダリングした出力が完全に完了したと保証されるまで、ブロック７２３〜７２６の繰返しの処理が継続される。ブロック７２３〜７２６は、関連するレンダリング出力が残らなくなるまで、連続的に繰返される。

ブロック７２２の判定結果が否定的なものである場合、当該プロセスフローはブロック７２７に進み、共有化メモリのキャッシュ属性がアンキャッシュ（Ｗｒｉｔｅ−Ｃｏｍｂｉｎｅなど）からキャッシュ（Ｗｒｉｔｅ−Ｂａｃｋなど）に変更される。その後、ブロック７２８に示されるように、ＩＮＶＬＰＧなどの既知のインテル（登録商標）プロセッサキャッシュ制御指示を用いて、前のキャッシュ属性を有するページＴＬＢを無効にする。この処理は、ページ属性の変更を実効化し、プロセッサ間の通信バスを通じてシステム内の他のプロセッサに伝達することを可能にするよう実行される。

当該プロセスは、共有化メモリの各ページに対して継続されてもよい。ブロック７２９において、キャッシュ属性を変更させるページが残っているか判断される。ブロック７２９の判定結果が肯定的なものである場合、当該プロセスはブロック７２７と７２８を繰り返す。

キャッシュ属性の変更対象となるページがもはや残っていない場合、当該プロセスフローはブロック７３０に進み、Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ記述子が、最適共有化メモリが現在ＣＰＵ及びアプリケーションソフトウェアのビューにあることを示すためタグ付けされる。

最適共有化メモリには常にＣＰＵ最適キャッシュ属性が割り当てられ、ＣＰＵビューからグラフィックプロセッサビューへの移行が発生するとき、グラフィックプロセッサが最適共有かメモリをアンキャッシュと扱うことができるように、ＣＰＵのキャッシュのデータが一貫性を有するようにされる。グラフィックプロセッサビューからホストＣＰＵビューへの移行時に、グラフィックデータはグラフィックプロセッサのキャッシュに関して一貫性を有するようにされる。

図８は、後者の実施例による最適共有化メモリサーファスの生成または割り当てを行う可能な一実施例によるプロセスフローを示す。図８に示されるプロセスでは、最適共有化サーファスが、キャッシュ（Ｗｒｉｔｅ−Ｂａｃｋなど）属性を常に有するように生成される。すなわち、最適共有化メモリのキャッシュ属性は、ＣＰＵが当該メモリを使用しているか、あるいはグラフィックプロセッサが当該メモリを使用しているかに依存しない。むしろ、メモリがグラフィックプロセッサビューにあるとき、あたかもグラフィックプロセッサがアンキャッシュされているかのように、最適共有化メモリを扱うようグラフィックプロセッサは指示される。典型的には、グラフィックプロセッサは、グラフィックプロセッサのメモリにインタフェースを示し、当該メモリがプロセッサによりキャッシュされているか論理を送信するインタフェース制御レジスタまたはページテーブル記述子（図１の１０７のような）を有し、アクセスはスヌープ処理を必要とする。しかしながら、本発明の実施例による方法を適用することにより、最適共有化サーファスは、ＣＰＵビューとグラフィックプロセッサビューとの間の移行段階において一貫性を有するようにされ、スヌープ処理の必要性が回避される。

ブロック８００と８０１に示されるように、最適共有化メモリサーファスがＷｒｉｔｅ−Ｂａｃｋ（ＷＢ）キャッシュ属性に割り当てられたページに割り当てられる。その後、ブロック８０２に示されるように、タイプ記述子またはヒントから、新たに割り当てられたメモリがどのように使用されるか、例えば、ＣＰＵによる読み出し/書き込み、または単なるオパーク（ｏｐａｑｕｅ）（グラフィックプロセッサによる使用のみ）などが判断される。

ＣＰＵが初期的に当該サーファスを使用している場合、プロセスフローは直接ブロック８０４に進み、この新たに割り当てられたサーファスがそれの現在のビューを示すように、Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔのメモリタイプ記述子にタグ付けされる。他方、グラフィックプロセッサが初期的に当該サーファスを使用している場合、メモリの以前及び/または無関係なアプリケーションの利用から依然としてキャッシュにあるサーファスに関する任意のデータを消去するようサーファスは一貫性を有するようにされる。この処理はブロック８０３に示され、インテル（登録商標）プロセッサキャッシュ制御指示ＷＢＩＮＶＤ（Ｗｒｉｔｅ−Ｂａｃｋ Ｉｎｖａｌｉｄａｔｅ Ｃａｃｈｅ）、ＩＮＶＤ（Ｉｎｖａｌｉｄａｔｅ Ｃａｃｈｅ）あるいはＣＬＦＬＵＳＨなどの既知の一貫性実施プリミティブによるキャッシュの任意のページのフラッシュ処理から構成される。ＣＰＦＬＵＳＨ（Ｃａｃｈｅ Ｐａｇｅ Ｆｌｕｓｈ）あるいは他のプロセッサキャッシュ制御プリミティブがこの目的のため利用することが可能である。その後、ブロック８０４に示されるように、新たに割り当てられたサーファスがそれの現在のビューを示すため、Ｓｕｒｆａｃｅ−Ｏｂｊｅｃｔ内のメモリタイプ記述子を介し特定またはタグ付けされるかもしれない。

当該サーファスが初期的にＣＰＵビューに割り当てられる場合、アプリケーションは、グラフィックドライバによりアプリケーションにわたされたサーファスに対してハンドルを用いて、サーファスをロックするよう要求する。このサーファスのロックにより、アプリケーションがサーファスにデータを書き込むことを可能にする。アプリケーションは、上述のように、ＬｏｃｋＡＰＩを呼び出すことにより、このロックを要求してもよい。

当該サーファスのビューがグラフィックプロセッサビューに変更すると、ＣＰＵは使用時に最適共有化メモリに対し読み出し及び書き込みを行っていたかもしれないため、最適共有化メモリはグラフィックプロセッサに関して一貫性を有するようにされる必要がある。図９Ａは、一貫性を実施するための方法の可能な一実施例を示すフロー図である。

ブロック９０１に示されるように、まず、ＣＰＵ上で実行するアプリケーションソフトウェアにより使用されている最適共有化メモリの一領域がサーファス全体をカバーしているか、あるいは単にサーファス内部の画成されたサブエリアをカバーしているか決定される。この画成されたサブエリアあるいはサーファス全体のエリアは、上述のようなＬｏｃｋ及びＵｎｌｏｃｋに従う画成されたエリアまたはサーファス全体のエリアに対応する。

最適共有化メモリの当該領域がサブエリアでない（すなわち、サーファス全体である）と判断されると、ブロック９０２に示されるように、このサーファスを一貫性を有するようにするための時間が、（本発明の実施例はマルチＣＰＵシステムで利用されているため）すべてのＣＰＵのすべてのキャッシュのフラッシュを実行するのに要する時間の１/２以上かかるか判断するため計算が行われる。

ブロック９０２の計算結果が肯定的なものである場合、ブロック９０３に示されるように、ＣＰＵのＬ１及びＬ２キャッシュ全体のフラッシュが、最適共有化メモリのこれらキャッシュのコンテンツを格納し、当該メモリを一貫性を有するようにするため実行される。その後、ブロック９１２に示されるように、サーファスがグラフィックプロセッサの使用に最適なビューであることを示すＳｕｒｆａｃｅ−Ｏｂｊｅｃｔのメモリタイプ記述子がタグ付けされる。ブロック９０２の計算結果が否定的なものである場合、プロセスフローは後述されるブロック９０５に進む。

最適共有化メモリ領域がサブエリアである場合、ブロック９０４に示されるように、当該サブエリアのスタート及びエンドアドレスが計算されてもよい。このサブエリアは図４Ａと同様にＲＥＣＴ（ｔ，ｌ，ｂ，ｒ）パラメータにより記述されてもよい。ここで、サブエリアの画成された形状は、当該サブエリアの位置とサイズを示す矩形の上下左右の座標を用いて記述される。あるいは、サブエリアは、図４Ｂと同様にＳｔａｒｔ ＯｆｆｓｅｔアドレスとＬｅｎｇｔｈにより記述される線形サーファスであってもよい。

サブエリアのスタート及びエンドアドレスが計算されると、プロセスフローはブロック９０５に進み、当該サブエリアがキャッシュラインの途中から始まるか検出される。ブロック９０５の判定結果が肯定的なものである場合、ブロック９０６が実行され、一貫性が課されるエリアのスタートが再び揃えられ、ダーティ（ｄｉｒｔｙ）なキャッシュラインがキャッシュラインフラッシュにより一貫性が課される特定アドレスで無効にされ、プロセスフローはブロック９０７に進む。

ブロック９０５の判定結果が否定的なものである場合、プロセスフローはブロック９０７に進む。ブロック９０７において、アドレス「ａｄｄｒ」に対応するキャッシュデータを有するキャッシュラインは、例えば、「ａｄｄｒ」パラメータを「ＣＬＦＬＵＳＨ」などのキャッシュラインフラッシュプリミティブにわたすことによりフラッシュされてもよい。

その後、ブロック９０９に示されるように、矩形または線形サブエリアのラインのエンドに到達したか判断される。ブロック９０９の判定結果が否定的なものである場合、ブロック９０８に示されるように、キャッシュラインのサイズに等しい分だけ「ａｄｄｒ」パラメータをインクリメントすることにより、次のキャッシュラインがフラッシュされ、ブロック９０７に戻る。

ブロック９０９の判定結果が肯定的なものである場合、プロセスフローはブロック９１０に進む。ブロック９１０において、サブエリアのエンドに到達したか判断される。サブエリアのエンドに到達していれば、グラフィックプロセッサによる利用のため最適メモリ領域を一貫性を有するようにするため、サブエリア全体がフラッシュされ、プロセスフローはブロック９１２に進む。

そうでない場合には、矩形のサブエリアの次のラインが、ブロック９１１に示されるように、任意の位置合わせのため調整されるサブエリアのサーファスピッチから幅を差し引いたサイズに等しい分だけ「ａｄｄｒ」パラメータをインクリメントすることによりフラッシュされ、ブロック９０５に戻る。

上記プロセスに用いられるキャッシュラインフラッシュ（ＣＬＦＬＵＳＨ）は、相対的に小さな粒度を有する（すなわち、相対的に小さなデータ部分を扱う）。対照的に、ページフラッシュ（ＣＰＦＬＵＳＨ）は、メモリの一ページに関するキャッシュラインのすべてをフラッシュする。従って、実施例によると、最適共有化メモリが後述のグラフィックプロセッサに対しハンドオフされるとき、一貫性を実施するプロセスは、最小のプロセッサオーバヘッドによりグラフィカルデータのより大きな部分に対して一貫性を実施するため、キャッシュラインフラッシュでなくページフラッシュを利用するようにしてもよい。所与の条件の下、ページフラッシュ用いたプロセスは、共有領域をラインに分割するオーバヘッドを行うよりも高速かつ効率的であるかもしれない。

あるいは、メモリ領域をパラメータとし、当該領域のすべてのデータがキャッシュ一貫性を有することを保証することにより、与えられたメモリ領域を効率的に処理するＣＰＵ指示が考えられる。

最適共有化メモリが上記プロセスにより一貫性を有するようにされると、この最適共有化メモリのデータは、あたかもそれがアンキャッシュまたはＷｒｉｔｅ−Ｃｏｍｂｉｎｅページキャッシュ属性を使用しているかのように、グラフィックプロセッサにより処理されることが可能である。

ある期間において最適共有化メモリのサーファス及びデータの使用後、グラフィックプロセッサは、共有メモリをＣＰＵにハンドオフしてもよい。本発明の実施例によると、ＣＰＵへのハンドオフの移行段階中に、共有メモリがグラフィック最適化ビューにある間に、グラフィックプロセッサにより以前に処理されたサーファスまたはサブエリアは、当該サーファス上でラスタ処理されるためアクティブまたはキューされる任意のペンディングレンダリングコマンドの完了を含む、グラフィックプロセッサに関して同期化される。さらに、グラフィックドライバは、これらのレンダリングコマンドのペンディングされているラスタ処理を追跡し、当該サーファスが一貫性を有することを保証するためレンダキャッシュをフラッシュする。

図９Ｂは、上記処理を実現する方法の可能な一実施例を示すフロー図である。

ブロック９２１に示されるように、グラフィックプロセッサにより以前に利用されたサーファスが、それに関連するペンディングされている処理を有するものとして特定される。これらのペンディングされている処理は、当該サーファスに対するグラフィック処理の開始時に設定されたＳｕｒｆａｃｅ−Ｏｂｊｅｃｔ内の記述子とメンバーにより示されるかもしれない。その後、ブロック９２２に示されるように、その後、ブロック９２２に示されるように、サーファスに対する任意のレンダリングの出力が依然としてペンディングされているか判断される。その場合、当該サーファスは、ＣＰＵに戻すことが可能となる前に、グラフィックプロセッサに関して一貫性を有するようにされねばならない。ブロック９２２の判定結果が否定的なものである場合、さらなる処理は必要とされない。プロセスフローはブロック９２７に進み、当該サーファスがＣＰＵ及びアプリケーションのビューにおいて現在最適であるということを示すＳｕｒｆａｃｅ−Ｏｂｊｅｃｔのメモリタイプ記述子がタグ付けされる。

他方、サーファスに対するレンダリングがペンディングされ、まだ完全にレンダリングされていないサーファス画素と、まだメモリに書き改めていないデータがあると示している場合、プロセスフローはブロック９２３に進む。ブロック９２３において、当該サーファスの中の任意のサブエリアに対するレンダリングがペンディングされているか、グラフィックドライバによりＳｕｒｆａｃｅ−Ｏｂｊｅｃｔのメンバーまたは記述子に蓄積されているプライベートデータを用いて判断される。レンダリングがペンディングされていない場合、プロセスフローはブロック９２７に進む。

他方、ブロック９２３の判定結果が肯定的なものである場合、プロセスフローはブロック９２４に進む。ブロック９２４において、グラフィックプロセッサにおいて依然としてペンディングされている、ハンドオフされているサーファスに適用される任意のレンダリングコマンドが処理される。これには、最適共有化サーファスに対するコマンドと、無関係なサーファスに対するコマンドの両方が含まれるが、最適共有化サーファスの画素は無関係なサーファスにもたらされる結果を生成するのに利用される。

その後、プロセスフローはブロック９２５に進み、以前に特定されたレンダリングコマンドの実行結果、すなわち、レンダリングされた画素が、当該サーファスがグラフィックプロセッサに関して一貫性を有することを保証するため、内部の任意のレンダリングキューからフラッシュされる。プロセスフローはブロック９２６に進み、レンダリングコマンドとレンダリングの出力が完全に完了したことが確認されるまで、ブロック９２３〜９２６の繰り返しが継続される。ブロック９２３〜９２６は、関連するレンダリング出力が残らなくなるまで、連続的に繰り返される。

本発明の実施例によると、ＣＰＵに有利なキャッシュ属性を有するようにするための最適共有化メモリの変換は、ＬｏｃｋＡＰＩまたは意味的に等価なインタフェース内で行われるが、グラフィックプロセッサに有利な属性を有するようにするための最適共有化メモリの変換は、ＵｎｌｏｃｋＡＰＩまたは意味的に等価なインタフェース内で行われる。いくつかの実施例では、Ｌｏｃｋ及びＵｎｌｏｃｋＡＰＩはグラフィック装置ドライバレベルで実行されるかもしれない。しかしながら、本発明の実施例はこの変換をＬｏｃｋ及びＵｎｌｏｃｋＡＰＩ内で実行することに限定されるものではない。例えば、共有されたオーナー権限を容易にする上でのアクセスの開始と終了を交渉する意味的に等価なアクションを示す、ＢｅｇｉｎＡｃｃｅｓｓやＥｎｄＡｃｃｅｓｓＡＰＩなどの同様のインタフェースＡＰＩが知られている。この変換は、例えば、他のインタフェース、内部のメモリ管理及び他の動作内の各種他のコードレベルで実行することができる。

より一般的には、例示されたプロセスフローなどの開示されたプログラミング構造、及び特定されたＡＰＩやキャッシュ制御プリミティブは、任意なものであり、任意に割り当てられた記憶法により呼び出された広範なコンピュータ指示シーケンスにおいて実現することが可能な機能を代表するものである。

本発明の実現形態は、ディスケット、磁気テープ、ディスクあるいはＣＤ−ＲＯＭなどのコンピュータ使用可能な媒体上に格納及び搬送されるコンピュータ実行可能な指示として具体的に実現されてもよい。これらの指示は、例えば、グラフィック装置ドライバにおいて実現することが可能である。これらの指示は、適切な読取装置を介してコンピュータメモリにダウンロードされ、そこから本発明の効果的特徴を実効化するようプロセッサにより指示はフェッチ及び実行される。

本発明の実施例は、様々な用途に効果的である。例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔ Ｇｒｏｕｐ Ｐｏｒｔ（１．ＩＳＯ/ＩＥＣ１１１７２−１/２/３（パート１：システム/２：映像/３：音声）：約１．５メガビット/秒までのデジタル記憶媒体に対する動画及びそれに関する音声の符号化、２．ＩＳＯ/ＩＥＣ１３８１８−１/２/３（パート１：システム/２：映像/３：音声）：動画とそれに関する音声情報の汎用的符号化、を参照せよ）アプリケーションは、メモリに格納され、以降においてＣＰＵにより読み出される「キーフレーム」を生成し、このキーフレームに基づき補間された中間フレームを生成する。キーフレームをＣＰＵによる読み出しに実質的に最適な共有メモリに格納することを可能にすることにより、エイリアシング、スヌープサイクル及び従来アプローチによる同様のものを回避しながら、ＭＰＥＧアプリケーションのパフォーマンスを実質的に向上させることができる。

本発明の他の用途は、３Ｄアプリケーションに関するものである。そのようなアプリケーションでは、頂点バッファが典型的には生成される。頂点バッファは、ポリゴンの点または頂点により満たされたバッファであり、これらの頂点はインデックス付けを行うことが可能である。アプリケーションによる生成後、典型的には、頂点バッファはレンダリング対象のグラフィックプロセッサにハンドオフされる。アプリケーションは、例えば、グラフィカルオブジェクトが互いに「衝突」するか検出するため、頂点バッファのデータを読み出す必要がある。あるいは、例えば、アプリケーションは、グラフィカルオブジェクトに「モーフィング（ｍｏｒｐｈ）」、屈曲などを行わせるためグラフィカルオブジェクトを操作できるように、頂点の変更をする必要ができる。

本発明の実施例によると、頂点バッファは共有メモリタイプを有するように生成することができる。その後、頂点バッファは、ＣＰＵビュー（アプリケーションによる頂点データの読み出しのため）とグラフィックビュー（頂点データに対するレンダリング処理を実行するため）の両方からバッファに効率的にアクセスすることを可能にするフォーマットを有するようになる。

本発明の他の有用な用途は、従来の３Ｄパイプラインにおけるグラフィックスの「変形及びライティング」処理に関するものであったり、あるいは最新の「プログラム可能な頂点シェーダ（Ｖｅｒｔｅｘ Ｓｈａｄｅｒｓ）」における複雑な頂点操作に関するものである。何れの例でも、アプリケーションは、レンダリング対象のオブジェクトの頂点を含む幾何のバッファを生成するようにしてもよい。これらの頂点は、他のオブジェクト共に画サーファス上にレンダリングすることが可能な可視空間にモデルが生成される「ワールドスペース（ｗｏｒｌｄ ｓｐａｃｅ）」から変形及びライティングする必要があるポリゴンを記述する。このプロセスでは、頂点は、頂点データの読み出し、変更及び書き込みに関する操作が行われる必要がある。

コンピュータチップセットの中には、変形及びライティングアプリケーションの実行に特化したグラフィックハードウェアを含むものもある。あるいは、ＣＰＵの特殊命令セットの一部は、変形及びライティング処理の高速化のために利用されてもよい。

後者の場合には、プロセッサメーカーは、ソフトウェアベンダが特殊な変形及びライティングハードウェアを含まないグラフィックチップセットを利用できるように、「ＰＳＧＰ（Ｐｒｏｃｅｓｓｏｒ−Ｓｐｅｃｉｆｉｃ Ｇｒａｐｈｉｃｓ Ｐｉｐｅｌｉｎｅ）」としてＣＰＵのパイプラインの一部を提供する。ＰＳＧＰパイプラインは、ホストＣＰＵを用いて、変形及びライティング処理を実行し、これにより変形及びライティング処理された頂点データはレンダリングでの利用のためグラフィックプロセッサに以降でわたされる。

ＣＰＵにより変形及びライティング処理が実行されている期間においては、当該処理がキャッシュモードで実行することが可能である場合に最も効率的である。「クリッピング（ｃｌｉｐｐｉｎｇ）」を伴う場合、ＣＰＵによりデータが読み出され、操作される必要がある。これにはメモリバッファからのデータの読み出し、操作及びバッファへの書き込みを要するため、メモリがキャッシュモードであるときにこれらの処理は最適に実行することができる。さらに、頂点に対し実行される処理がプログラム的に複雑である場合、フルにプログラム可能な頂点シェーダから明らかに可能である。１つの頂点の処理は、オブジェクトサーファス移動マッピングや環境ライティング効果などの複雑な効果を行うため、各頂点と共に他の多数の頂点の多数の読み出し及び書き込みを伴う。

本発明によると、共有メモリは何れのビューに対しても最適にフォーマット化されるため、変形及びライティング処理をとても効率的に実行することができ、バッファやデータのエイリアシングは必要でない。

本発明の他の可能な用途は、ハードウェアによって直接的には必ずしもサポートされる必要のない高度なレンダリングを実行することができるグラフィックのＡＰＩの実現に関するものである。ＡＰＩにより与えられるレンダリングの一部は、「ハードウェア高速化可能」（グラフィックプロセッサによる実行が可能な）であり、また他の部分はそうでなくてもよい。高速化可能な処理をグラフィックプロセッサ上で可能な限りＣＰＵ処理とパラレルに実行する効率性を向上させるかもしれない。これは、グラフィックプロセッサにより実行される場合には、ＣＰＵがベジエ曲線などの複雑な形状の次の頂点を自由に生成したり、あるいはレンダリング効果の複雑なラスタ処理工程を実行することができるようにＭｏｖｅ、Ｆｉｌｌまたは整数とブール処理などのレンダリングプロセス内のよくあるレンダリング処理に対して特に真である。

本発明のいくつかの実施例が具体的に例示及び説明された。しかしながら、本発明の変更及び変形が、上記教示によりカバーされ、本発明の趣旨及び範囲から逸脱することなく添付したクレームの範囲内にあるということは理解されるであろう。

図１は、ＣＰＵとグラフィックプロセッサとの間で共有されるコンピュータメモリの可能な一実施例を示す。 図２は、ＣＰＵとグラフィックプロセッサとの間で共有されるコンピュータメモリの可能な他の実施例を示す。 図３は、ＣＰＵにより最適共有化メモリが使用されているモードと、グラフィックプロセッサにより最適共有化メモリが使用されているモードとの間の移行を示す状態図を示す。 図４Ａは、グラフィックサーファスとバッファと共に、サーファスパラメータを介し記述可能なサーファスのサブエリアのタイプの例を示す。 図４Ｂは、グラフィックサーファスとバッファと共に、サーファスパラメータを介し記述可能なサーファスのサブエリアのタイプの例を示す。 図５は、グラフィックサーファスの画成されたエリアの走査線を示す。 図６は、一実施例による最適共有メモリ領域を割り当てるプロセスのフロー図を示す。 図７Ａは、図６の実施例によるサーファスまたはサーファスの画成されたサブエリアを一貫性を有するようにするためのプロセスのフロー図を示す。 図７Ｂは、図６の実施例によるグラフィックサーファスに対するペンディングされているレンダリング処理の完了及び当該グラフィックサーファスのキャッシュ属性の変更のためのフロー図を示す。 図８は、他の実施例による最適共有化メモリ領域を割り当てるプロセスのフロー図を示す。 図９Ａは、図８の実施例によるサーファスまたはサーファスの画成されたサブエリアを一貫性を有するようにするためのプロセスのフロー図を示す。 図９Ｂは、図８の実施例によるグラフィックサーファスに対するペンディングされているレンダリング処理の完了及び当該グラフィックサーファスのキャッシュ属性の変更のためのフロー図を示す。

Claims (40)

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. ＣＰＵとグラフィックプロセッサとの間の共有化のためメモリ領域を配分するステップと、
    前記共有化されたメモリ領域にキャッシュ属性を割り当てるステップと、
    前記ＣＰＵが前記メモリ領域を使用している第１モードから、前記グラフィックプロセッサが前記メモリ領域を使用している第２モードへの移行を実行するステップと、
    前記第２モードにおいて、前記グラフィックプロセッサに前記共有化されたメモリ領域をあたかもアンキャッシュであるかのように扱わせるステップとからなることを特徴とする方法。
32. 請求項３１記載の方法であって、前記第１モードから前記第２モードへの移行中、前記共有化されたメモリ領域は一貫性を有するようにされることを特徴とする方法。
33. ＣＰＵとグラフィックプロセッサとの間の共有化のためメモリ領域を配分するステップと、
    前記メモリ領域にキャッシュ属性を割り当てるステップと、
    前記ＣＰＵ上で前記共有化されたメモリ領域のデータの読み出し、変更あるいは書き込みを行うアプリケーションを実行するステップと、
    前記共有化されたメモリ領域を一貫性を有するようにするステップと、
    前記データのレンダリングのため前記グラフィックプロセッサに対して前記共有化されたメモリ領域をハンドオフするステップと、
    前記グラフィックプロセッサに前記共有化されたメモリ領域をあたかもアンキャッシュであるかのように扱わせるステップとからなることを特徴とする方法。
34. 請求項３３記載の方法であって、さらに、
    前記グラフィックプロセッサにより前記データに対してレンダリング処理を実行するステップと、
    さらなる処理のため前記ＣＰＵに対して前記共有化されたメモリ領域をハンドオフするステップとを有することを特徴とする方法。
35. 請求項３３記載の方法であって、前記メモリ領域は、グラフィックサーファスであることを特徴とする方法。
36. プロセスを実現するプロセッサによる実行時にコンピュータ実行可能な指示を格納するコンピュータ利用可能な媒体であって、
    前記プロセスは、
    ＣＰＵとグラフィックプロセッサとの間の共有化のためメモリ領域を配分するステップと、
    前記共有化されたメモリ領域にキャッシュ属性を割り当てるステップと、
    前記ＣＰＵが前記メモリ領域を使用している第１モードから、前記グラフィックプロセッサが前記メモリ領域を使用している第２モードへの移行を実行するステップと、
    前記第２モードにおいて、前記グラフィックプロセッサに前記共有化されたメモリ領域をあたかもアンキャッシュであるかのように扱わせるステップとからなることを特徴とするコンピュータ利用可能な媒体。
37. 請求項３６記載のコンピュータ利用可能な媒体であって、前記第１モードから前記第２モードへの移行中、前記共有化されたメモリ領域は一貫性を有するようにされることを特徴とする媒体。
38. プロセスを実現するプロセッサによる実行時にコンピュータ実行可能な指示を格納するコンピュータ利用可能な媒体であって、
    前記プロセスは、
    ＣＰＵとグラフィックプロセッサとの間の共有化のためメモリ領域を配分するステップと、
    前記メモリ領域にキャッシュ属性を割り当てるステップと、
    前記ＣＰＵ上で前記共有化されたメモリ領域のデータの読み出し、変更あるいは書き込みを行うアプリケーションを実行するステップと、
    前記共有化されたメモリ領域を一貫性を有するようにするステップと、
    前記データのレンダリングのため前記グラフィックプロセッサに対して前記共有化されたメモリ領域をハンドオフするステップと、
    前記グラフィックプロセッサに前記共有化されたメモリ領域をあたかもアンキャッシュであるかのように扱わせるステップとからなることを特徴とする媒体。
39. 請求項３８記載のコンピュータ利用可能な媒体であって、前記プロセスはさらに、
    前記グラフィックプロセッサによる前記データに対するレンダリング処理を実行するステップと、
    さらなる処理のため前記ＣＰＵに対して前記共有化されたメモリ領域をハンドオフするステップとを有することを特徴とする媒体。
40. 請求項３８記載のコンピュータ利用可能な媒体であって、前記メモリ領域はグラフィックサーファスであることを特徴とする媒体。

Images