特許 6633614 フレームペーシング方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6633614

(24)【登録日】2019年12月20日

(45)【発行日】2020年1月22日

(54)【発明の名称】フレームペーシング方法及びシステム

(51)【国際特許分類】

   G06T 15/00 20110101AFI20200109BHJP

   G06T 1/20 20060101ALI20200109BHJP

   G09G 5/00 20060101ALI20200109BHJP

   G09G 5/36 20060101ALI20200109BHJP

【ＦＩ】

   G06T15/00 501

   G06T1/20 B

   G09G5/00 550H

   G09G5/36 530C

【請求項の数】15

【全頁数】15

(21)【出願番号】特願2017-506881(P2017-506881)

(86)(22)【出願日】2015年8月7日

(65)【公表番号】特表2017-531232(P2017-531232A)

(43)【公表日】2017年10月19日

(86)【国際出願番号】US2015044128

(87)【国際公開番号】WO2016022874

(87)【国際公開日】20160211

【審査請求日】2018年7月5日

(31)【優先権主張番号】62/035,124

(32)【優先日】2014年8月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】591016172

【氏名又は名称】アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド

【氏名又は名称原語表記】ＡＤＶＡＮＣＥＤ ＭＩＣＲＯ ＤＥＶＩＣＥＳ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川 裕司

(74)【代理人】

【識別番号】100111615

【弁理士】

【氏名又は名称】佐野 良太

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨 圭介

(72)【発明者】

【氏名】ジョナサン ローレンス キャンベル

(72)【発明者】

【氏名】ミッチェル エイチ． シンガー

(72)【発明者】

【氏名】ユピン シェン

(72)【発明者】

【氏名】ユエ ジオ

【審査官】 真木 健彦

(56)【参考文献】

【文献】 米国特許出願公開第２０１２／０２６２４６３（ＵＳ，Ａ１）

【文献】 特開平０９−２５９２９７（ＪＰ，Ａ）

【文献】 特開２００５−０９２８６３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０１５７１９３（ＵＳ，Ａ１）

【文献】 米国特許第０７５４５３８０（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｔ １５／００ − １５／８７

Ｇ０６Ｔ １／２０

Ｇ０９Ｇ ５／００ − ５／４２

(57)【特許請求の範囲】

【請求項1】

レンダリングプロセスにおけるフレームペーシングの方法であって、
複数のグラフィックスプロセッシングユニット（ＧＰＵ）の各々のフレームレンダリング時間を推定するステップであって、前記フレームレンダリング時間は、各ＧＰＵがフレームをレンダリングするのにかかる時間の推定値である、ステップと、
ＧＰＵ毎に、ＧＰＵについて決定された少なくとも１つの推定されたフレームレンダリング時間に基づいて遅延を決定するステップと、
前記遅延を前記レンダリングプロセスに挿入して、フレームを時間的な等間隔でレンダリングするステップと、を含む、
方法。

【請求項2】

ＧＰＵ毎の前記遅延は、前記複数のＧＰＵの各々のアプリケーションワークロードに基づいて動的に調整される、請求項１の方法。

【請求項3】

ＧＰＵ毎の前記推定されたフレームレンダリング時間は、所定数のフレームにわたって取られた平均値である、請求項１の方法。

【請求項4】

前記レンダリングプロセス及びフレーム表示を制御するために、ＧＰＵ毎の少なくとも１つの前記遅延に基づいてハートビートが確立され、前記ハートビートは、フレームが表示されるときの一定のティッキングである、請求項１の方法。

【請求項5】

前記遅延を可能にするために、少なくとも１つのタイマが用いられる、請求項１の方法。

【請求項6】

ＧＰＵ毎の前記推定されたフレームレンダリング時間を決定するために、タイムスタンプクエリが用いられる、請求項１の方法。

【請求項7】

前記遅延は、カーネルモードドライバ（ＫＭＤ）に実装される、請求項１の方法。

【請求項8】

前記遅延を実装するために、ダミースケジューラブルエンジンが前記ＫＭＤ内で生成され、前記ダミースケジューラブルエンジンは、要求に応じて、前記遅延を前記レンダリングプロセスに挿入するように構成されたスケジューリングを行う、請求項７の方法。

【請求項9】

表示は、前記遅延の満了又は前記レンダリングプロセスの完了の後に生じ、前記表示は、フレームが表示され得ることを意味する、請求項１の方法。

【請求項10】

複数のグラフィックスプロセッシングユニット（ＧＰＵ）の各々のフレームレンダリング時間を推定するように構成された第１処理モジュールであって、ＧＰＵ毎に、ＧＰＵの少なくとも１つの推定されたフレームレンダリング時間に基づいて遅延を決定するように構成された第１処理モジュールと、
前記遅延をレンダリングプロセスに挿入して、フレームを等間隔でレンダリングするように構成された第２処理モジュールと、を備え、
前記フレームレンダリング時間は、各ＧＰＵがフレームをレンダリングするのにかかる時間の推定値である、
レンダリングプロセスにおけるフレームペーシングシステム。

【請求項11】

ＧＰＵ毎の前記遅延は、前記複数のＧＰＵの各々のアプリケーションワークロードに基づいて動的に調整される、請求項１０のシステム。

【請求項12】

ＧＰＵ毎の前記推定されたフレームレンダリング時間は、所定数のフレームにわたって取られた平均値である、請求項１０のシステム。

【請求項13】

前記レンダリングプロセス及びフレーム表示を制御するために、ＧＰＵ毎の少なくとも１つの前記遅延に基づいてハートビートが確立され、前記ハートビートは、フレームが表示されるときの一定のティッキングであり、前記表示は、フレームが表示され得ることを意味する、請求項１０のシステム。

【請求項14】

ＧＰＵ毎の前記推定されたフレームレンダリング時間を決定するために、タイムスタンプクエリが用いられる、請求項１０のシステム。

【請求項15】

前記第２処理モジュールは、カーネルモードドライバ（ＫＭＤ）であり、
前記遅延を実装するために、ダミースケジューラブルエンジンが前記ＫＭＤで生成され、前記ダミースケジューラブルエンジンは、要求に応じて、前記遅延を前記レンダリングプロセスに挿入するように構成されたスケジューリングを行う、請求項１０のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本願は、２０１４年８月８日に出願された米国仮特許出願第６２／０３５，１２４号の利益を主張し、当該仮特許出願の内容は、言及することにより、本明細書に完全に記載されているように編入される。

【0002】

本発明は、概してグラフィックス処理に関する。

【背景技術】

【0003】

グラフィックス処理は、一般的に、中央処理装置（ＣＰＵ）及び複数のグラフィックスプロセッシングユニット（ＧＰＵ）の組み合わせを用いて実行される。複数のＧＰＵを用いるレンダリングシステムでは、各ＧＰＵは、フレームを完成させる場合に、完成したフレームをレンダリングして、このフレームを表示のために提示する。他のＧＰＵがレンダリングを完了する間近に各ＧＰＵのフレームのレンダリングが完了する場合に、レンダリングされた第１フレームが、（既に完成した）後続のフレームよりも短い時間で画面上に表示される。フレームを表示する時間の長さが等間隔でない場合に、ユーザは、より低いフレームレート（効果的にスタッタを引き起こす）を視覚的に見て知覚することができる。これは、名目上、フレームスタッタリング（frame stuttering）又はマイクロスタッタリング（micro-stuttering）と呼ばれる。複数のＧＰＵによってレンダリングされたアプリケーション（例えば、３Ｄアプリケーション等）の視覚的な及び／若しくは知覚されたフレームスタッタリング並びに／又はマイクロスタッタリングを克服する方法及びシステムが必要とされている。

【発明の概要】

【課題を解決するための手段】

【0004】

本明細書では、フレームペーシングのための方法及びシステムが記載されている。概して、フレームペーシングは、後続のフレームの表示から等間隔に離隔する遅延と、アプリケーションワークロードが変わる場合に当該遅延を計測及び調整する計測メカニズムと、を加える。

【0005】

添付の図面と併せて実施例により与えられた以下の説明から、より詳細な理解を得ることができる。

【図面の簡単な説明】

【0006】

【図1】１つ以上の開示された実施形態を実装し得る例示的なデバイスのブロック図である。

【図2】いくつかの実施形態による例示的なグラフィックスレンダリングパイプラインである。

【図3】デュアルグラフィックスプロセッシングユニット（ＧＰＵ）におけるレンダリングの実施例である。

【図4】いくつかの実施形態による、フレームペーシングについての例示的なハイレベルブロック図である。

【図5】いくつかの実施形態による、フレームペーシングについての例示的なフローチャートである。

【図6】いくつかの実施形態による、フレームペーシングについての他の例示的なフローチャートである。

【図7】いくつかの実施形態による、フレームペーシングについてのシーケンス図の一例である。

【図8】いくつかの実施形態による、デュアルＧＰＵアーキテクチャにおけるフレームペーシングについてのシーケンス図の一例である。

【図9】いくつかの実施形態による、１つのタイマを用いたフレームペーシングについてのシーケンス図の一例である。

【図10】いくつかの実施形態による、フレームペーシングについてのシーケンス図における動作の一例である。

【図11】対称アーキテクチャにおけるスタッタリングの例示的な図である。

【図12】いくつかの実施形態による、対称アーキテクチャにおけるフレームペーシング又はアンチスタッタリングの例示的な図である。

【図13】Ｔ_ＳＤＭＡ＞Ｔ_ＧＦＸ／２である対称アーキテクチャにおけるスタッタリングの例示的な図である。

【図14】Ｔ_ＳＤＭＡ＞Ｔ_ＧＦＸである対称アーキテクチャにおけるスタッタリングの例示的な図である。

【図15】スロースレーブシナリオ（slow slave scenario）におけるスタッタリングの例示的な図である。

【図16】いくつかの実施形態による、スロースレーブシナリオにおけるアンチスタッタリングの例示的な図である。

【図17】いくつかの実施形態による、非対称クロスファイア（ＡＣＦ）が１：２であり、「１」がボトルネックであるスロースレーブシナリオにおけるアンチスタッタリングの例示的な図である。

【図18】いくつかの実施形態による、ＡＣＦが１：２であり、「２」がボトルネックであるスロースレーブシナリオにおけるアンチスタッタリングの例示的な図である。

【発明を実施するための形態】

【0007】

本明細書には、フレームペーシングのための方法及びシステムが記載されている。概して、フレームをレンダリングするのにかかる時間について推定を行う。これは、グラフィックスプロセッシングユニット（ＧＰＵ）がフレームをレンダリングするのにかかる時間を測定することによって行うことができる。複数の最近のフレームに亘る平均値を用いて、フレーム間のワークロードの差を平滑化し、ＧＰＵの速度をレンダリングする。ＧＰＵの進行を制御し、ＧＰＵの表示を平滑化するハートビートが生成される。測定された適切な時間の長さだけドライバ（例えば、カーネルモードドライバ（ＫＭＤ））にて待機することで、フレームが等間隔に配置される。フレームペーシングは、実質的に、他のＧＰＵに対して早すぎるかもしれない１つのＧＰＵにおけるフレームのフリッピングを延期する。

【0008】

図１は、１つ以上の開示された実施形態を実装し得る例示的なデバイス１００のブロック図である。デバイス１００は、例えば、コンピュータ、ゲーム機、ハンドヘルドデバイス、セットトップボックス、テレビ、携帯電話、又は、タブレットコンピュータを含むことができる。デバイス１００は、プロセッサ１０２と、メモリ１０４と、ストレージ１０６と、１つ以上の入力デバイス１０８と、１つ以上の出力デバイス１１０と、を含む。また、デバイス１００は、入力ドライバ１１２と、出力ドライバ１１４と、を任意に含んでもよい。デバイス１００は、図１に示されていない追加の構成要素を含み得ることを理解されたい。

【0009】

プロセッサ１０２は、中央処理装置（ＣＰＵ）、グラフィックスプロセッシングユニット（ＧＰＵ）、同じダイ上に配置されたＣＰＵ及びＧＰＵ、又は、１つ以上のプロセッサコアを含むことができ、各プロセッサコアは、ＣＰＵ又はＧＰＵであってもよい。メモリ１０４は、プロセッサ１０２と同じダイ上に配置されてもよいし、プロセッサ１０２とは別に配置されてもよい。メモリ１０４は、揮発性又は不揮発性メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ又はキャッシュ）を含むことができる。ＧＰＵは、同じタイプのＧＰＵ（対称クロスファイア）又は異なるタイプのＧＰＵ（非対称クロスファイア（ＡＣＦ））であってもよい。例えば、プロセッサ又はシステム内のＧＰＵは、アクセラレーテッドプロセッシングユニット（ＡＰＵ）、ディスクリートＧＰＵ（ｄＧＰＵ）及び／又はこれらの組み合わせを含み得るが、これらに限定されない。

【0010】

ストレージ１０６は、固定又はリムーバブルストレージ（例えば、ハードディスクドライブ、ソリッドステートドライブ、光ディスク又はフラッシュドライブ）を含むことができる。入力デバイス１０８は、キーボード、キーパッド、タッチスクリーン、タッチパッド、検出器、マイクロフォン、加速度計、ジャイロスコープ、生体認証スキャナ、又は、ネットワーク接続（例えば、無線ＩＥＥＥ８０２信号の送信及び／若しくは受信用の無線ローカルエリアネットワークカード）を含むことができる。出力デバイス１１０は、ディスプレイ、スピーカ、プリンタ、触覚フィードバックデバイス、１つ以上のライト、アンテナ、又は、ネットワーク接続（例えば、無線ＩＥＥＥ８０２信号の送信及び／若しくは受信用の無線ローカルエリアネットワークカード）を含むことができる。

【0011】

入力ドライバ１１２は、プロセッサ１０２及び入力デバイス１０８と通信し、プロセッサ１０２が入力デバイス１０８から入力を受信するのを可能にする。出力ドライバ１１４は、プロセッサ１０２及び出力デバイス１１０と通信し、プロセッサ１０２が出力デバイス１１０に対して出力を送信するのを可能にする。入力ドライバ１１２及び出力ドライバ１１４は、任意の構成要素であって、入力ドライバ１１２及び出力ドライバ１１４が存在しない場合には、デバイス１００が同様に機能することに留意されたい。

【0012】

図２は、例示的なグラフィックスレンダリングパイプライン２００を示す図である。説明の目的のため及びコンテキストを提供するために、グラフィックスレンダリングパイプライン２００は、Ｗｉｎｄｏｗｓ（登録商標）ベースのＯ／Ｓを用いて示されているが、任意のオペレーティングシステム（Ｏ／Ｓ）が用いられてもよい。一般に、グラフィックスレンダリングパイプライン２００は、アプリケーションモジュール／レイヤ／エンティティ２０５と、Ｗｉｎｄｏｗｓ（登録商標）Ｏ／Ｓモジュール／レイヤ／エンティティ２１０と、ドライバモジュール／レイヤ／エンティティ２２０と、ハードウェア２３０と、を含む。モジュール／レイヤ／エンティティという用語は、本明細書ではエンティティと総称される。

【0013】

アプリケーションエンティティ２０５は、他の機能の中でもユーザ入力を処理する。アプリケーションエンティティ２０５は、例えば、ゲーム世界に関する例えばオブジェクトの位置、物理的特性等を更新するシミュレータ２０７を含む。シミュレータ２０７は、フレームを生成するために、例えば、Ｄｉｒｅｃｔ３Ｄ ＡＰＩを介して描画呼び出しを生成するレンダラ２０９に結合又は接続（本明細書では、接続と呼ぶ）されている。レンダラ２０９は、Ｄｉｒｅｃｔ３Ｄランタイムエンティティ２１１に接続されており、Ｄｉｒｅｃｔ３Ｄランタイムエンティティ２１１は、コマンドを解析して、ＤＤＩインタフェースを介してユーザモードドライバ（ＵＭＤ）２２２を呼び出す。ＵＭＤ２２２は、ＧＰＵコマンドバッファを生成し、ＧＰＵコマンドバッファをＷｉｎｄｏｗｓ（登録商標）Ｏ／Ｓ２１０、特にＤｉｒｅｃｔ３Ｄランタイムエンティティ２１１に送る。次に、ＧＰＵコマンドバッファは、Ｗｉｎｄｏｗｓ（登録商標）Ｏ／Ｓ２１０のカーネルスケジューラ２１５がＧＰＵコマンドバッファを受け入れる準備ができるまで、コンテキストキュー２１３内に配置される。ＧＰＵコマンドバッファは、カーネルモードドライバ（ＫＭＤ）２２４に送られ、ＫＭＤ２２４は、ＧＰＵコマンドバッファを処理してＧＰＵ２３２に送信する。アプリケーションエンティティ２０５は、フレームがレンダリングを終了して表示可能な場合に、表示呼び出しを送信する。表示呼び出しは、描画呼び出しと同じ論理パスに従う。

【0014】

図３は、グラフィックス処理のために複数のＧＰＵアーキテクチャを用いる場合のマイクロスタッタリング問題を視覚的に説明する図である。一般に、複数のＧＰＵ間での作業割り当て又は割り振りでは、代替フレームレンダリング（ＡＦＲ）と呼ばれるプロセスが用いられ、各ＧＰＵは、同じフレームの一部で機能する複数のＧＰＵの各々とは対照的に、自身のフレームを得る。ＡＦＲは、各ＧＰＵが、レンダリングされたフレームをできる限り等間隔のレートで送出しているように、各ＧＰＵの出力がペーシングされるときに好適に機能する。例えば、図３に示すように、単一のＧＰＵ（ＳＧＰＵ）フロー３００において、フレームが順次レンダリングされ、提示される。理想的なデュアルＧＰＵフロー３０５では、ＧＰＵ１の出力は、ＧＰＵ０が自身のフレームをほぼ半分完了したときに完了する。しかしながら、実際に何が起こるかは、実際のデュアルＧＰＵフロー３１０に示される。ＧＰＵ０がレンダリングを完了する間近にＧＰＵ１のフレームが完了する場合には、その後にレンダリングされた第１フレームは、第２フレーム又はこれ以降のフレームよりも短い時間で画面に表示される。フレームを表示する時間の長さが等間隔でない場合には、ユーザは、より低いフレームレート（すなわち、マイクロスタッタリング）を視覚的に見て知覚し得る。

【0015】

本明細書には、フレームペーシングのための方法及びシステムが記載されている。

【0016】

図４は、２つのＧＰＵのアーキテクチャ４００の一例を示す図であり、図５は、ハイレベルなフローチャート５００を示す図であり、図６は、２つのＧＰＵのアーキテクチャ４００の例示的なフローチャートを示す図であり、図７は、２つのＧＰＵのアーキテクチャ４００のＵＭＤ視点からのフレームペーシングフロー又はシーケンス６００のハイレベルな例を示す図である。これらの図は、本明細書に記載されるフレームペーシングを集合的に示している。システムアーキテクチャは、本明細書に記載される本発明の範囲から逸脱することなく、任意の数のＣＰＵ、ＧＰＵ、プロセッサ等を含むことができる。特に、２つのＧＰＵのアーキテクチャ４００は、ＧＰＵ４１０及びＧＰＵ４１５に接続されたＣＰＵ４０５を含み、ＧＰＵ４１０，４１５はディスプレイ４２０に順に接続される。各ＧＰＵ４１０，４１５は、本明細書において以下に記載されるように、遅延の開始及び完了を知らせるためのタイマ４１２，４１７を有し得る。

【0017】

ここで図４及び図５を参照すると、フレームをレンダリングするのにかかる時間についての推定が行われる（５０５）。これは、ＧＰＵ４１０，４１５がフレームをレンダリングするのにかかる時間を測定することによって行うことができる。例えば、ＧＰＵがフレームをレンダリングするのにかかる時間を、タイプスタンプクエリを用いて測定することができる。最近のいくつかのフレームにわたる平均値は、フレーム毎のワークロードの差を平滑化し、ＧＰＵのレンダリング速度を向上させる（５１０）。ＧＰＵの進行を制御して、ＧＰＵの表示を平滑化するハートビートが生成される（５１５）。ハートビートは、フレームが提示されるときのパルス又は一定のティッキングである。測定された適切な時間の長さだけカーネルモードドライバ（ＫＭＤ）で待機して、フレームを等間隔に配置する（５２０）。例えば、ダミースケジューラブルエンジンは、ＫＭＤで生成される。ユーザモードドライバ（ＵＭＤ）は、ダミーコマンドバッファをこのダミーエンジンに送信して、遅延を要求する（所期のフレーム時間の９０〜９５％であってもよい）。ＫＭＤは、要求された遅延が経過すると、コマンドバッファを完了として報告する（５２５）。レンダリングプロセスが遅延よりも長くかかる場合には、レンダリングプロセスが完了すると直ぐに表示が行われる。事実上、遅延は、ＧＰＵがフレームを表示するための最小待ち時間である。ＵＭＤは、Ｍｉｃｒｏｓｏｆｔ（登録商標）（ＭＳ）同期オブジェクトの信号をダミーエンジンに送信する。ＵＭＤは、この同期オブジェクトを通常の３Ｄエンジン上で待機する。

【0018】

ここで図６及び図７を参照すると、２つのＧＰＵのアーキテクチャ４００において、レンダリングコマンドがＧＰＵ０に送信される（６０５）。ＵＭＤ（ＵＭＤは図２に示される）は、遅延要求を、ＫＭＤ（ＫＭＤは図２に示される）内のダミーエンジンに送信する（６１０）。これは、図７のダミーエンジンフローの「遅延」として示されている。本明細書において以下に記載され示されるように、遅延は、その後にＧＰＵが表示可能な事実上の最小時間を提供する。すなわち、レンダリングプロセスが遅延の実行前に完了する場合には、ＧＰＵは、遅延の実行後に表示を行う。ダミーエンジンは、信号をＧＰＵ０に送信する（６１５）。これは、図７において「Ｓ」として示されている。ＧＰＵ０は、必要な遅延時間だけ待機する（６２０）。これは、図７において「Ｗ」として示されている。ＧＰＵ０は、必要な遅延時間後に表示を行う（６２５）。これは、図７において「Ｐ」によって示されている。次に、ＧＰＵ１に対してシーケンスが繰り返される。特に、レンダリングコマンドがＧＰＵ１に送信される（６３０）。ＵＭＤは、遅延要求を、ＫＭＤ内のダミーエンジンに送信する（６３５）。信号は、ダミーエンジンによってＧＰＵ１に送信される（６４０）。ＧＰＵ１は、必要な遅延時間だけ待機する（６４５）。ＧＰＵ１は、必要な遅延時間（６５０）が経過し、レンダリングプロセスが完了した後に表示を行う。すなわち、表示は、遅延期間よりも早くなく、レンダリングプロセスが完了した場合のみに行われ得る。そして、ＧＰＵ０及びＧＰＵ１に対するシーケンスが繰り返される。

【0019】

図８は、フレームペーシングフロー又はシーケンス８００の他のハイレベルな例を示す図である。レンダリングコマンド８０５がＧＰＵ０に送られ、レンダリングコマンド８１０がＧＰＵ１に送られる。ＧＰＵ０は、表示（Ｐ）８１５を行うとともに、ＧＰＵ０のタイマに（図２に示すＵＭＤを介して）信号（Ｓ）８２０を送る。この信号は、ＧＰＵ１が表示を行う前に一定の時間（遅延）８３０だけ待機（Ｗ）８２５するためのものである。遅延８３０（図中のバブルで示される）を待機した後に、ＧＰＵ０のタイマは、待機（Ｗ）８４０が経過してＧＰＵ１が表示（Ｐ）８４５を行うことができる信号（Ｓ）８３５をＧＰＵ１に送信する。次に、ＧＰＵ１は、ＧＰＵ０が表示を行う前に一定の時間（遅延）８６０だけ待機（Ｗ）８５５するために、ＧＰＵ１のタイマに（図２に示すＵＭＤを介して）信号（Ｓ）８５０を送る。この場合、遅延８６０は、ＧＰＵ０がレンダリングプロセスを完了するのに必要な時間と一致する。これは、後のシーケンスにおいてバブルが示されていないという事実によって示されている。実質的に、ＧＰＵ０及びＧＰＵ１間のレンダリング処理をオフセットし、ＧＰＵ０及びＧＰＵ１間の処理を並べるために遅延が導入されると、当該オフセットが常に存在し、当該遅延はスループット又はフレームレートに対して殆ど影響を与えない。何等かの理由で１つのＧＰＵがアライメントから外れると、オフセットはアライメントを修正する。

【0020】

一実施形態では、フレームペーシングは、存在するデバイスドライバインタフェース（ＤＤＩ）に影響を及ぼし、非存在のＤＤＩには影響を与えない。

【0021】

本明細書で説明する実施形態では、フレーム時間の計算及び管理は、ＵＭＤで行われる。他の実施形態では、フレーム時間の計算及び管理は、ＫＭＤで行われる。

【0022】

一実施形態では、遅延量を調整することができる。

【0023】

一実施形態では、１つのタイマを用いて、複数のＧＰＵアーキテクチャにおいてフレームペーシングを実装することができる。これは図９に示されており、１つのタイマが用いられている点を除いて図８と同様に機能する。

【0024】

一実施形態では、本明細書で説明するフレームペーシングは、ハードウェア合成アーキテクチャ、ハードウェアフリッピングアーキテクチャ及び／又はソフトウェア合成アーキテクチャで利用することができる。

【0025】

図１０を参照すると、本明細書で上述したタイムスタンプクエリの一例が示されている。特に、図１０は、デュアルＧＰＵでの動作を示している。２つのクエリオブジェクトは、全てのフレームで使用される。１つのクエリオブジェクトは、フレームの先頭で用いられ、（Ｑ）と示されている。もう１つのクエリオブジェクトは、フレームの末尾で用いられ、（Ｑ’）と示されている。クエリオブジェクトのＧｅｔＤａｔａ（Ｑに対するＧ、Ｑ’に対するＧ’）は、ＧＰＵがクエリオブジェクトを処理するときの時間を取得する。ＱとＱ’との間隔は、フレーム時間である。ＢｅｇｉｎＦｒａｍｅ（）は、フレームの先頭で呼び出され、ＱをＧＰＵに挿入する。ＥｎｄＦｒａｍｅ（）は、フレームの末尾で呼び出され、Ｑ’をＧＰＵに挿入する（図１０の番号は、この呼び出しが例示的なドライバで発生したときを示している）。

【0026】

マルチＧＰＵシステムでは、マスタＧＰＵ（ＧＰＵ０）が画面出力を駆動するのに対し、他のＧＰＵは駆動しない。このシナリオでは、全てのスレーブフレームをマスタＧＰＵにコピーして表示するソフトウェア合成が用いられる。ソフトウェア合成は、ハードウェア合成と同様にマイクロスタッタリングを被る。図１１は、対称クロスファイア（１：１）スタッタリングの一例を示しており、対称クロスファイアは、同じタイプのＧＰＵがプロセッサ又はシステムで用いられていることを意味する。余分なサーフェス（０）がＧＰＵ０に生成され、ティアリングを除去する。図中の厚太な縦線は、マスタの３Ｄエンジンのフリップ（flip）であり、破線は、マスタのＳＤＭＡエンジンのフリップである。薄太の陰影のあるボックスは、ソフトウェア合成ＳＤＭＡ転送と、そのターゲットとを表している。他のボックスは、３Ｄ ｃｍｄｂｕｆである。ボックス内の数字はフレーム番号を示しており、文字はレンダターゲットを示している。各スレーブフレームについて、３つの動作をシリアル化する必要がある。ＧＰＵ１は、３Ｄエンジン上でフレームのレンダリングを終了する。ＧＰＵ１は、このフレームを、ＳＤＭＡエンジンを介してＧＰＵ０に転送し、ＧＰＵ０は、当該フレームを、ＳＤＭＡエンジンを介してオンスクリーンに表示する。フレーム０，２，４は、フレーム１，３，５よりもさらに短く画面上に留まることがわかる。

【0027】

デュアルＧＰＵアーキテクチャの例では、図１２に示すように、遅延を伴うＧＰＵ０上のタイマを用いて、全ての表示が等しい長さのフレームペーシングを実装する。遅延は、式（１）に示すように計算することができる。

【数1】

ここで、ＧｆｘＴｉｍｅ_Ｇｐｕ０は、ＧＰＵ０がフレームをレンダリングするのにかかる時間であり、ＧｆｘＴｉｍｅ_Ｇｐｕ１は、ＧＰＵ１がフレームをレンダリングするのにかかる時間であり、ＳｄｍａＴｉｍｅは、ＳＤＭＡエンジンがＧＰＵ１からＧＰＵ０にフレームを転送するのにかかる時間である。

【0028】

低速転送の例では、ＧＰＵ０及びＧＰＵ１がフレームをレンダリングするのに同じ時間がかかること、すなわちＴ_ＧＦＸ＝ＧｆｘＴｉｍｅ_Ｇｐｕ０＝ＧｆｘＴｉｍｅ_Ｇｐｕ１と仮定する。Ｔ_ＳＤＭＡ＞Ｔ_ＧＦＸ／２の場合には、ＧＰＵ１上のフレームＮ＋１は、ＧＰＵ０上のフレームＮよりも早く完了する。図１３に示すように、フレーム５はフレーム４の前に、フレーム７はフレーム６の前に、というように続く。このレイアウトは、ＧＰＵ間のリソース転送に対して脆弱である。図１４は、転送がボトルネックであり、Ｔ_ＳＤＭＡ＞Ｔ_ＧＦＸである場合の例を示している。上記の低速転送の問題は理論上可能であるが、低速転送の例では、実際のアプリケーションで実用的な効果がない。

【0029】

図１５〜図１８は、ＧＰＵが同じレートでレンダリングしない非対称クロスファイア（ＡＣＦ）アーキテクチャがなければ、図１１〜図１４と同様である。図１７及び図１８は、ＡＦＲ比が１：２で不均衡である場合、すなわち１つのＧＰＵが３つのフレームのうち２つをレンダリングする場合のＡＣＦを示している。

【0030】

図１５は、ＡＣＦ１：１に関するスロースレーブ問題の例を示す図であり、図１６は、スロースレーブ問題に対処するためのフレームペーシング実装を示す図である。

【0031】

ＡＣＦ１：２アーキテクチャでは、３Ｄ又はＳＤＭＡ上でマスタのフレームをフリップするかどうかは、重要ではない。その理由は、フレーム５が、Ｂが画面から外れるのを待たなければならないからである。

【0032】

図１７は、「１」がボトルネックであり、ＧｆｘＴｉｍｅ_Ｇｐｕ１がＧＰＵ１上の２つの連続したフレームの合計である、ＡＣＦ１：２の解決法を示す図である。

【0033】

図１８は、「２」がボトルネックである、ＡＣＦ１：２の解決法を示す図である。

【0034】

概して、レンダリングプロセスにおけるフレームペーシングの方法は、複数のグラフィックスプロセッシングユニット（ＧＰＵ）の各々のフレームレンダリング時間を推定するステップと、少なくとも１つの推定されたフレームレンダリング時間に基づいて遅延を測定するステップと、当該遅延をレンダリングプロセスに挿入して、フレームを等間隔でレンダリングするステップと、を含む。一実施形態では、遅延は、ＧＰＵ上のアプリケーションワークロードに基づいて動的に調整されてもよい。一例では、推定されたフレームレンダリング時間は、所定数のフレームにわたって取られた平均値である。一例では、レンダリングプロセス及びフレーム表示を制御するために、少なくとも１つの遅延に基づいてハートビートが確立される。一例では、遅延を可能にするために、少なくとも１つのタイマが用いられる。一例では、推定されたフレームレンダリング時間を測定するために、タイムスタンプクエリが用いられる。一例では、遅延は、カーネルモードドライバ（ＫＭＤ）に実装される。遅延を実装するために、ダミースケジューラブルエンジンがＫＭＤで生成される。表示は、遅延の満了又はレンダリングプロセスの完了の後に生じる。

【0035】

レンダリングプロセスにおけるフレームペーシングシステムは、複数のグラフィックスプロセッシングユニット（ＧＰＵ）の各々のフレームレンダリング時間を推定するように構成された第１処理モジュールを含む。第１処理モジュールは、少なくとも１つの推定されたフレームレンダリング時間に基づいて遅延を測定するように構成されている。第２処理モジュールは、この遅延をレンダリングプロセスに挿入して、フレームを等間隔でレンダリングするように構成されている。一実施形態では、遅延は、ＧＰＵ上のアプリケーションワークロードに基づいて動的に調整されてもよい。一例では、推定されたフレームレンダリング時間は、所定数のフレームにわたって取られた平均値である。一例では、レンダリングプロセス及びフレーム表示を制御するために、少なくとも１つの遅延に基づいてハートビートが確立される。一例では、遅延を可能にするために、少なくとも１つのタイマが用いられる。一例では、推定されたフレームレンダリング時間を測定するために、タイムスタンプクエリが用いられる。一例では、第２処理モジュールは、カーネルモードドライバ（ＫＭＤ）である。遅延を実装するために、ダミースケジューラブルエンジンがＫＭＤで生成される。表示は、遅延の満了又はレンダリングプロセスの完了の後に生じる。一例では、第１処理モジュールはＵＭＤであってもよく、第２処理モジュールはＫＭＤであってもよい。

【0036】

本明細書の開示に基づいて多くの変形が可能であることを理解されたい。特徴及び要素は、特定の組み合わせで上記のように説明されているが、各特徴又は要素は、他の特徴及び要素なしに単独で用いられてもよいし、他の特徴及び要素を伴う又は伴わない様々な組み合わせで用いられてもよい。

【0037】

提供された方法は、汎用コンピュータ、プロセッサ又はプロセッサコアに実装されてもよい。適切なプロセッサには、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他のタイプの集積回路（ＩＣ）、及び／又は、状態機械が含まれる。かかるプロセッサは、処理されたハードウェア記述言語（ＨＤＬ）命令の結果と、ネットリスト（コンピュータ可読媒体に記憶可能なかかる命令）を含む他の中間データと、を用いて製造プロセスを構成することによって、製造可能である。かかる処理の結果は、本発明の態様を実施するプロセッサを製造するために半導体製造プロセスで用いられるマスクワークであってもよい。

【0038】

本明細書で提供された方法又はフローチャートは、汎用コンピュータ又はプロセッサによる実行のためにコンピュータ可読記憶媒体に組み込まれたコンピュータプログラム、ソフトウェア又はファームウェアに実装され得る。コンピュータ可読記憶媒体の例としては、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスク等の磁気媒体、光磁気媒体、光媒体（例えば、ＣＤ―ＲＯＭディスク及びデジタル多用途ディスク（ＤＶＤ等）を含む。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】