特許 7568675 定期的リセット

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

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

(11)【特許番号】

(24)【登録日】2024-10-07

(45)【発行日】2024-10-16

(54)【発明の名称】定期的リセット

(51)【国際特許分類】

   G09G 5/00 20060101AFI20241008BHJP

【ＦＩ】

G09G5/00 530Z

G09G5/00 510A

G09G5/00 550A

【請求項の数】 20

(21)【出願番号】P 2022085519

(22)【出願日】2022-05-25

(62)【分割の表示】P 2020163934の分割

【原出願日】2020-09-29

(65)【公開番号】P2022126661

(43)【公開日】2022-08-30

【審査請求日】2023-09-28

(31)【優先権主張番号】1914056.5

(32)【優先日】2019-09-30

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】515293676

【氏名又は名称】イマジネーション テクノロジーズ リミテッド

【氏名又は名称原語表記】Ｉｍａｇｉｎａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｌｉｍｉｔｅｄ

【住所又は居所原語表記】Ｉｍａｇｉｎａｔｉｏｎ Ｈｏｕｓｅ， Ｈｏｍｅ Ｐａｒｋ Ｅｓｔａｔｅ， Ｋｉｎｇｓ Ｌａｎｇｌｅｙ， Ｈｅｒｔｆｏｒｄｓｈｉｒｅ ＷＤ４ ８ＬＺ Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ

(74)【代理人】

【識別番号】100120031

【弁理士】

【氏名又は名称】宮嶋 学

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100118843

【弁理士】

【氏名又は名称】赤岡 明

(74)【代理人】

【識別番号】100202429

【弁理士】

【氏名又は名称】石原 信人

(72)【発明者】

【氏名】フィル、モリス

(72)【発明者】

【氏名】マリオ、ソペナ、ノバレス

(72)【発明者】

【氏名】ジェイミー、ブルーム

【審査官】西田 光宏

(56)【参考文献】

【文献】特開２０１８－１７５３３７（ＪＰ，Ａ）

【文献】特開２０１４－１９８１７０（ＪＰ，Ａ）

【文献】特開２０１６－０８３１２０（ＪＰ，Ａ）

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

【文献】中国特許出願公開第１０９８３１５８５（ＣＮ，Ａ）

【文献】中国特許出願公開第１０８７６２６５２（ＣＮ，Ａ）

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

Ａ６３Ｆ ７／０２

Ｇ０６Ｆ ３／００－３／０４８９５

Ｇ０６Ｆ １１／２２－１１／２７７

Ｇ０６Ｔ １／００－１／４０

Ｇ０６Ｔ ３／００－７／９０

Ｇ０６Ｖ １０／００－２０／９０

Ｇ０６Ｖ ３０／４１８

Ｇ０６Ｖ ４０／１６

Ｇ０６Ｖ ４０／２０

Ｈ０４Ｍ １／００－１／８２

Ｈ０４Ｍ ９９／００

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

【請求項1】

グラフィック処理システム内のグラフィック処理ユニットにおいて安全重要レンダリングを実施する方法であって、
前記グラフィック処理システムが、前記グラフィック処理ユニットにおける安全重要レンダリングのためのグラフィカルデータを受信することと、
安全性コントローラが、フォールトが検出されたか否かに関係なく、前記グラフィック処理ユニットの複数のリセットをリセット頻度にしたがってスケジュールすることであって、スケジュールすることは、
前記グラフィック処理ユニットの１つ以上のスケジュールされたリセットを示すコマンドを含む命令を生成することと、
前記命令を前記グラフィック処理ユニットに送信することと、
を含むスケジュールすることと、
前記グラフィック処理ユニットが、前記グラフィカルデータをレンダリングすることと、
前記安全性コントローラが、前記グラフィック処理ユニットの前記複数のリセットを、前記リセット頻度と整合して実施させることと、
を含み、
前記グラフィック処理ユニットにおいて前記コマンドを含む、前記命令を読み取ることに応答して、前記グラフィック処理ユニットのリセットを実行することは、
前記グラフィック処理ユニットで前記命令を読み取る前に処理を開始した任意のタスク、の処理を完了することと、
前記処理の完了の後に、前記グラフィック処理ユニットの少なくとも一部をリセットすることと、
を含む、方法。

【請求項2】

前記リセット頻度は、前記グラフィック処理ユニットの信頼レベルに依存して適合される、
請求項１に記載の方法。

【請求項3】

(a)前記グラフィック処理ユニットが、第１のフレームの断片処理を実行する間に、前記コマンドを含む前記命令を読み取ることと、
(b)前記グラフィック処理ユニットが、前記命令の読み取りに応答して前記第１のフレームの前記断片処理を完了することと、
(c)(b)に続いて、前記グラフィック処理ユニットの少なくとも一部をリセットすることと、
(d)(c)に続いて、第２のフレームの幾何学的形状処理を実行することと、
を含む、請求項１又は請求項２に記載の方法。

【請求項4】

前記グラフィック処理ユニットの前記スケジュールされたリセットを示す前記コマンドが、グラフィック処理命令とともに提供される、
請求項１～３のいずれか１項に記載の方法。

【請求項5】

前記リセット頻度が、フレームの数当たりに実施されるリセットの数を定義する、
請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記リセット頻度が、設計時に設定され、ユーザ構成可能、又は前記グラフィック処理ユニットの外部のデバイス上で実行されるアプリケーションによって決定される、
請求項１～５のいずれか１項に記載の方法。

【請求項7】

前記グラフィック処理ユニットの安全メトリック、電離放射線レベル、電圧スパイクの発生、及び電磁パルスの発生のうちの１つ以上を監視することと、
前記監視に依存して前記リセット頻度を適合させることと、
をさらに含む、請求項１～６のいずれか１項に記載の方法。

【請求項8】

前記グラフィック処理ユニットが、キャッシュ、レジスタ若しくはバッファのうち少なくとも１つ、ファームウェア、及び、１つ以上の処理ユニットを含み、
少なくとも１つのリセットが、
前記１つ以上の処理ユニットを再初期化すること、
前記キャッシュ、レジスタ、又はバッファ内の少なくとも１つのエントリを前記グラフィック処理ユニットにおいて無効化すること、及び、
前記グラフィック処理ユニットの前記ファームウェアを再初期化しないこと、
を含むソフトリセットである、
請求項１～７のいずれか１項に記載の方法。

【請求項9】

前記グラフィック処理ユニットが、キャッシュ、レジスタ若しくはバッファのうち少なくとも１つ、ファームウェア、及び、１つ以上の処理ユニットを含み、
少なくとも１つのリセットが、
前記１つ以上の処理ユニットを再初期化すること、
前記グラフィック処理ユニットの前記ファームウェアを再初期化すること、及び、
前記キャッシュ、レジスタ、又はバッファ内の少なくとも１つのエントリを前記グラフィック処理ユニットにおいて無効化すること、
を含むハードリセットである、
請求項１～８のいずれか１項に記載の方法。

【請求項10】

複数のソフトリセットがソフトリセット頻度に従ってスケジュールされ、複数のハードリセットがハードリセット頻度に従ってスケジュールされる、
請求項８を引用する請求項９に記載の方法。

【請求項11】

前記ソフトリセット頻度が前記ハードリセット頻度より高い、
請求項１０に記載の方法。

【請求項12】

安全重要レンダリングを実施するように構成されたグラフィック処理ユニット、及びグラフィック処理システムのための安全性コントローラを備える、グラフィック処理システムであって、
前記グラフィック処理システムが、前記グラフィック処理ユニットにおける安全重要レンダリングのためのグラフィカルデータを受信するように構成され、
前記安全性コントローラが、フォールトが検出されたか否かに関係なく、前記グラフィック処理ユニットの複数のリセットをリセット頻度にしたがってスケジュールすることであって、スケジュールすることは、
前記グラフィック処理ユニットの１つ以上のスケジュールされたリセットを示すコマンドを含む命令を生成することと、
前記命令を前記グラフィック処理ユニットに送信することと、
を含むスケジュールするように構成され、
前記グラフィック処理ユニットが、前記グラフィカルデータをレンダリングするように構成され、
前記安全性コントローラが、前記グラフィック処理ユニットの前記複数のリセットを、前記リセット頻度と整合して実施させるように構成され、
前記グラフィック処理ユニットが、前記グラフィック処理ユニットにおいて前記コマンドを含む、前記命令を読み取ることに応答して、前記グラフィック処理ユニットの少なくとも一部をリセットする前に、前記命令を読み取る前に処理を開始した任意のタスク、の処理を完了すること、を実行するように構成されている、
グラフィック処理システム。

【請求項13】

前記リセット頻度が、フレームの数当たりに実施されるリセットの数を定義する、請求項１２に記載のグラフィック処理システム。

【請求項14】

前記安全性コントローラが、前記グラフィック処理ユニットの安全メトリック、電離放射線レベル、電圧スパイクの発生、及び電磁パルスの発生のうちの１つ以上を監視するように構成されたモニターを備え、前記安全性コントローラが、前記監視に依存して前記リセット頻度を適合させるように構成される、請求項１２又は１３に記載のグラフィック処理システム。

【請求項15】

前記グラフィック処理ユニットが、キャッシュ、レジスタ若しくはバッファのうち少なくとも１つ、ファームウェア、及び、１つ以上の処理ユニットを含み、
少なくとも１つのリセットが、
前記１つ以上の処理ユニットを再初期化すること、
前記グラフィック処理ユニットにおける前記キャッシュ、レジスタ、又はバッファ内の少なくとも１つのエントリを無効化すること、及び、
前記グラフィック処理ユニットの前記ファームウェアを再初期化しないこと、
を含むソフトリセットである、
請求項１２～１４のいずれか１項に記載のグラフィック処理システム。

【請求項16】

前記グラフィック処理ユニットが、１つ以上の処理ユニット、ファームウェア、及びキャッシュ、レジスタ、又はバッファのうちの少なくとも１つを含み、
少なくとも１つのリセットが、
前記１つ以上の処理ユニットを再初期化すること、
前記グラフィック処理ユニットの前記ファームウェアを再初期化すること、及び、
前記キャッシュ、レジスタ、又はバッファ内の少なくとも１つのエントリを前記グラフィック処理ユニットにおいて無効化すること、
を含むハードリセットである、
請求項１２～１５のいずれか１項に記載のグラフィック処理システム。

【請求項17】

前記安全性コントローラが、ソフトリセット頻度に従って複数のソフトリセットをスケジュールし、ハードリセット頻度に従って複数のハードリセットをスケジュールするように構成される、請求項１５を引用する請求項１６に記載のグラフィック処理システム。

【請求項18】

前記ソフトリセット頻度が前記ハードリセット頻度よりも高い、請求項１７に記載のグラフィック処理システム。

【請求項19】

前記グラフィック処理ユニットが、
(a)第１のフレームの断片処理を実行する間に、前記コマンドを含む前記命令を読み取り、
(b)前記命令の読み取りに応答して前記第１のフレームの前記断片処理を完了し、
(c)(b)に続いて、前記グラフィック処理ユニットの少なくとも一部をリセットし、
(d)(c)に続いて、第２のフレームの幾何学的形状処理を実行する、
ように構成される、請求項１２～１８のいずれか１項に記載のグラフィック処理システム。

【請求項20】

コンピュータに、請求項１～１１のいずれか１項に記載の方法を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、安全重要レンダリングを実施するための方法およびグラフィック処理システムに関連する。

【0002】

安全重要システムでは、システムの構成要素の少なくとも一部は、システム全体がシステムに必要と見なされる安全性のレベルを満たすことができるように十分な安全目標を満たす必要がある。例えば、ほとんどの管轄区域では、車両におけるシートベルトのリトラクタは、こうしたデバイスが提供された車両が安全性試験に合格するために特定の安全規格を満たす必要がある。同様に、車両のタイヤは、こうしたタイヤを装備した車両が、特定の管轄区域に対して適切な安全性試験に合格するために特定の規格を満たす必要がある。安全重要システムは通常、その故障が人々または環境の安全性に対するリスクの大幅な増加を引き起こすことになるシステムである。

【0003】

データ処理デバイスは、専用のハードウェアとして、または安全重要ソフトウェアを実行するためのプロセッサとしてのいずれかで、安全重要システムの一体型部分を形成することが多い。例えば、航空機向けのフライバイワイヤシステム、ドライバ支援システム、鉄道信号システム、および医療用デバイス向けの制御システムはすべて、通常、データ処理デバイス上で実行される安全重要システムである。データ処理デバイスが安全重要システムの一体型部分を形成する場合、データ処理デバイス自体は、システム全体が適切な安全レベルを満たすことができるように、安全目標を満たす必要がある。自動車業界では、安全レベルは通常、機能安全規格ＩＳＯ２６２６２で定義されている自動車安全度水準（ＡＳＩＬ）である。

【0004】

また、安全重要システムのデータ処理デバイスは、ソフトウェアを実行するプロセッサを含む。ハードウェアおよびソフトウェア要素の両方は、特定の安全目標を満たす必要がある。一部のソフトウェア障害は、プログラミングエラーまたは不適切なエラー処理によるシステム障害である可能性がある。これらの問題は、通常、厳密な開発実践、コード監査および試験プロトコルによって対処することができる。システマティックエラーが安全重要システムから完全に除外することが可能である場合でさえも、例えば、一時的なイベント（例えば、電離放射線、電圧スパイク、または電磁パルスによる）により、ランダムエラーがハードウェアの中へと導入される可能性がある。バイナリシステムでは、一時的なイベントは、メモリ内およびプロセッサのデータパスに沿ってランダムなビットフリッピングを引き起こす可能性がある。ハードウェアに永久的フォールトがある場合もある。

【0005】

データ処理デバイスに対する安全目標は、所与の期間内の障害の最大数（多くの場合、時間内障害またはＦＩＴとして表される）、ならびにシングルポイント障害（シングルポイント障害メカニズム、またはＳＰＦＭ）および潜在的な障害（潜在障害メカニズム、またはＬＦＭ）を検出するメカニズムの有効性などの一連のメトリクスとして表される場合がある。例えば、一つの構成要素が故障した場合に、別の構成要素が同じタスクを実施するため利用できるようにハードウェア冗長性を提供することによって、またはチェックデータ（例えば、パリティビットまたはエラー修正コードなど）の使用を通して、ハードウェアが軽微なデータ破損を検出および／または修正できるように、データ処理デバイスに対して設定された安全目標を達成するための様々なアプローチがある。

【0006】

例えば、データプロセッサを、一対の同一の処理コア１０１および１０２が、命令のストリーム１０３を並列に処理するように構成されている、図１に示すようなデュアルロックステップ配列１００で提供することができる。処理コア（１０１）のうちのいずれか一つの出力が、ロックステッププロセッサの出力１０４として使用されてもよい。処理コア１０１および１０２の出力が一致しない場合、安全重要システムに、フォールトが発生する可能性がある。電離放射線および電圧スパイクなどの外因性因子によって誘発されるエラーの検出確率を改善するために、遅延１０５を、コアのうちの一つへの入力に導入することができる（一般に、もう一方のコアの出力に対応する遅延１０６が提供される）。しかしながら、第二の処理コアが必要とされるため、必然的に従来のプロセッサと比較して二倍のチップ面積を消費し、かつおよそ二倍の電力を消費するという点で、デュアルロックステッププロセッサは高価である。

【0007】

高度なドライバ支援システムおよび自律車両は、かなりのグラフィックおよび／またはベクトル処理能力を有するこうした安全重要用途のために適切なデータ処理システムを組み込む場合があるが、デュアルロックステッププロセッサを実装するための面積および消費電力（したがってコスト）の増加は、許容されないか、または望ましくない場合がある。例えば、ドライバ支援システムは多くの場合、危険、車線位置、およびその他の情報をドライバに図示する、コンピュータ生成グラフィックを提供する。典型的には、これは、車両製造業者が、従来の機器クラスタをコンピュータ生成機器クラスタに置き換えることにつながり、これはまた、速度および車両のフォールト情報などの安全重要情報の表示がコンピュータ生成されるようになることも意味する。こうした処理要求は、グラフィック処理ユニット（ＧＰＵ）によって満たすことができる。しかしながら、自動車のコンテクストでは、高度なドライバ支援システムは、典型的にはＩＳＯ２６２６２のＡＳＩＬレベルＢを満たすデータ処理システムを必要とする。

【0008】

例えば、自動車のコンテクストでは、ダッシュボード表示画面における表示用に機器クラスタをレンダリングするために、グラフィック処理システムを使用してもよい。機器クラスタは、車両の速度および任意の車両のフォールトの詳細などの、重要情報をドライバに提供する。こうした重要情報がドライバに確実に提示されることは重要であり、また典型的には車両規則は、ＩＳＯ２６２６２規格のＡＳＩＬ Ｂなどの既定の安全レベルを満たす様式で重要情報がレンダリングされることを必要とする。

【0009】

図２は、機器クラスタ２００を図示する。機器クラスタは、ダイヤルの縁の周りの速度値２０８と、角度方向が車両の現在の速度を示す針２０７とを有する従来のダイヤルの形態の速度計２０２を備える。機器クラスタは、油温ゲージ２０３、情報アイコン２０４（例えば、選択されたラジオ放送局を示す）、非重要警告アイコン２０５（例えば、空調システムでのフォールトを示す）、および重要警告アイコン２０６（例えば、深刻なエンジンの不調を示す）をさらに含む。ＩＳＯ２６２６２規格のＡＳＩＬ Ｂなどの義務付けられた安全レベルを満足するように、機器クラスタ２００をレンダリングすることが必要である場合がある。

【0010】

自律車両は、安全重要な決定を行うために、リアルタイムで（例えば、レーダー、ＬＩＤＡＲ、マップデータおよび車両情報から）非常に大量のデータを追加的に処理する必要がある。グラフィック処理ユニットもまた、こうした処理要求を満たすことを支援できるが、自律車両における安全重要システムは通常、ＩＳＯ２６２６２の最も厳格なＡＳＩＬレベルＤを満たすことが必要とされる。

【発明の概要】

【発明が解決しようとする課題】

【0011】

この概要は、詳細な説明で以下にさらに説明される選択された概念を紹介するために提供されている。この概要は、特許請求される主題の要所特徴または必須特徴を特定することも意図しておらず、特許請求される主題の範囲を限定するために使用されることも意図していない。

【0012】

本発明の第一の態様によれば、グラフィック処理システム内のグラフィック処理ユニットにおいて安全重要レンダリングを実施する方法が提供され、この方法は、グラフィック処理システムにおいてグラフィック処理ユニットにおける安全重要レンダリングのためのグラフィカルデータを受信することと、安全性コントローラにおいてリセット頻度に従ってグラフィック処理ユニットの複数のリセットをスケジュールすることと、グラフィック処理ユニットにおいてグラフィカルデータをレンダリングすることと、安全性コントローラがグラフィック処理ユニットの複数のリセットをリセット頻度と整合して実施されることと、を含む。

【0013】

スケジュールすることは、グラフィック処理ユニットの一つ以上のスケジュールされたリセットを示すコマンドを含む命令を生成すること、および命令がグラフィック処理ユニットに渡されるようにすることとを含んでもよい。

【0014】

方法は、グラフィック処理ユニットにおいてコマンドを含む命令を受信することに応答して、命令を読み取る前にグラフィック処理ユニットで処理を開始した任意のタスクの処理を完了することと、グラフィック処理ユニットの少なくとも一部をリセットすることとをさらに含んでもよい。

【0015】

グラフィック処理ユニットのスケジュールされたリセットを示すコマンドには、グラフィック処理命令が提供されてもよい。

【0016】

リセット頻度は、フレームの数当たりに実施されるリセットの数を定義してもよい。

【0017】

リセット頻度は、設計時に設定されてもよく、ユーザ構成可能であってもよく、またはグラフィック処理ユニットの外部のデバイス上で実行されるアプリケーションによって決定されてもよい。

【0018】

本方法は、グラフィック処理ユニットの安全メトリック、電離放射線レベル、電圧スパイクの発生、および電磁パルスの発生のうちの一つ以上を監視すること、および前述の監視に依存してリセット頻度を適合させることをさらに含んでもよい。

【0019】

グラフィック処理ユニットは、一つ以上の処理ユニット、ファームウェア、およびキャッシュ、レジスタ、またはバッファのうちの少なくとも一つを備えてもよく、また少なくとも一つのリセットは、一つ以上の処理要素を再初期化することと、グラフィック処理ユニットにおけるキャッシュ、レジスタ、またはバッファ内の少なくとも一つのエントリを無効化するが、グラフィック処理ユニットのファームウェアを再初期化しないこととを含むソフトリセットであってもよい。

【0020】

グラフィック処理ユニットは、一つ以上の処理ユニット、ファームウェア、およびキャッシュ、レジスタ、またはバッファのうちの少なくとも一つを備えてもよく、また少なくとも一つのリセットは、一つ以上の処理要素を再初期化することと、グラフィック処理ユニットのファームウェアを再初期化することと、グラフィック処理ユニットにおけるキャッシュ、レジスタ、またはバッファ内の少なくとも一つのエントリを無効化することと、を含むハードリセットであってもよい。

【0021】

複数のソフトリセットは、ソフトリセット頻度に従ってスケジュールされてもよく、また複数のハードリセットは、ハードリセット頻度に従ってスケジュールされてもよい。ソフトリセット頻度は、ハードリセット頻度よりも高くてもよい。

【0022】

本発明の第二の態様によれば、安全重要レンダリングを実施するように構成されたグラフィック処理ユニットを備えるグラフィック処理システムおよびグラフィック処理システム用の安全性コントローラが提供され、グラフィック処理システムは、グラフィック処理ユニットにおける安全重要レンダリングのためのグラフィカルデータを受信するように構成され、安全性コントローラはリセット頻度に従ってグラフィック処理ユニットの複数のリセットをスケジュールするように構成され、グラフィック処理システムはグラフィカルデータをレンダリングするように構成され、かつ安全性コントローラはリセット頻度と整合してグラフィック処理ユニットの複数のリセットを実施させるよう構成される。

【0023】

リセット頻度は、フレームの数当たりに実施されるリセットの数を定義してもよい。

【0024】

安全性コントローラは、グラフィック処理ユニットの安全メトリック、電離放射線レベル、電圧スパイクの発生、および電磁パルスの発生のうちの一つ以上を監視するように構成されたモニターを備えてもよく、また安全性コントローラは、前述の監視に依存してリセット頻度を適合させるように構成されてもよい。

【0025】

グラフィック処理ユニットは、一つ以上の処理ユニット、ファームウェア、およびキャッシュ、レジスタ、またはバッファのうちの少なくとも一つを備えてもよく、また少なくとも一つのリセットは、一つ以上の処理要素を再初期化することと、グラフィック処理ユニットにおけるキャッシュ、レジスタ、またはバッファ内の少なくとも一つのエントリを無効化するが、グラフィック処理ユニットのファームウェアを再初期化しないこととを含むソフトリセットであってもよい。

【0026】

グラフィック処理ユニットは、一つ以上の処理ユニット、ファームウェア、およびキャッシュ、レジスタ、またはバッファのうちの少なくとも一つを備えてもよく、また少なくとも一つのリセットは、一つ以上の処理要素を再初期化することと、グラフィック処理ユニットのファームウェアを再初期化することと、グラフィック処理ユニットにおけるキャッシュ、レジスタ、またはバッファ内の少なくとも一つのエントリを無効化することと、を含むハードリセットであってもよい。

【0027】

安全性コントローラは、ソフトリセット頻度に従って複数のソフトリセットをスケジュールし、かつハードリセット頻度に従って複数のハードリセットをスケジュールするように構成されてもよい。ソフトリセット頻度は、ハードリセット頻度よりも高くてもよい。

【0028】

一部の実施例では、安全重要データを処理するためのグラフィック処理ユニットと、グラフィック処理ユニットのための安全メカニズムを実装するよう構成された安全性コントローラとを備えるグラフィック処理システムが提供され、安全性コントローラは電離放射線のレベルを監視するように構成されたモニターを備え、また安全性コントローラは電離放射線のレベルに依存して安全メカニズムを適合させるように構成される。

【0029】

詳細には、安全メカニズムを実装することは、グラフィック処理ユニットの定期的リセットをスケジュールすることが関与する場合がある。このように、安全重要データを処理するためのグラフィック処理ユニットと、リセット頻度に従ってグラフィック処理ユニットのリセットをスケジュールするように構成された安全性コントローラとを備えるグラフィック処理システムが提供されてもよく、安全性コントローラは電離放射線のレベルを監視するように構成されたモニターを備え、また安全性コントローラは電離放射線のレベルに依存してリセット頻度を適合させるように構成される。

【0030】

グラフィック処理システムは、集積回路上のハードウェア内に具体化されてもよい。集積回路製造システムで、グラフィック処理システムを製造する方法が、提供されてもよい。集積回路製造システムで処理される時に、グラフィック処理システムを製造するシステムを構成する、集積回路定義データセットが提供されてもよい。非一時的コンピュータ可読記憶媒体であって、集積回路製造システム内で処理された時に、集積回路製造システムにグラフィック処理システムを製造させる、集積回路のコンピュータ可読記述がその上に保存された、非一時的コンピュータ可読記憶媒体が提供されてもよい。

【0031】

グラフィック処理システムを記述するコンピュータ可読集積回路記述がその上に保存された、非一時的コンピュータ可読記憶媒体と、グラフィック処理システムを具体化する集積回路の回路レイアウト記述を生成するように、集積回路記述を処理するように構成された、レイアウト処理システムと、回路レイアウト記述に従って、グラフィック処理システムを製造するように構成された、集積回路生成システムと、を備える、集積回路製造システムが提供されてもよい。

【0032】

本明細書に記載の方法を実施するためのコンピュータプログラムコードが提供されてもよい。コンピュータシステムにおいて実行された時に、コンピュータシステムに、本明細書に記載の方法を実施させる、その上に保存されたコンピュータ可読命令を有する、非一時的コンピュータ可読記憶媒体が提供されてもよい。

【0033】

本発明は、添付図面を参照しながら実施例として説明される。

【図面の簡単な説明】

【0034】

【図1】図１は、従来のデュアルロックステッププロセッサの概略図である。

【図2】図２は、車両用のコンピュータ生成機器クラスタを示す。

【図3】図３は、本明細書に記載の原理による動作のためのグラフィック処理システムの概略図である。

【図4】図４は、本明細書に記載の原理によるグラフィック処理ユニットのリセットを示す概略的タイムラインである。

【図5】図５は、本明細書に記載の原理によるグラフィック処理ユニットにおいて安全重要レンダリングを実施する方法のフロー図である。

【図6】図６は、集積回路製造システムの概略図である。

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

【0035】

以下の説明は、当業者が本発明を作製および使用することを可能にするために実施例として提示されている。本発明は、本明細書に記載の実施形態に限定されず、また開示された実施形態に対する様々な修正は、当業者にとって明らかであろう。実施形態は、実施例としてのみ説明される。

【0036】

本開示は、安全重要レンダリングを実施するための方法およびグラフィック処理システムに関連する。

【0037】

グラフィック処理システム３００を図３に示す。グラフィック処理システム３００は、少なくとも一つのグラフィック処理ユニット（ＧＰＵ）３１２を備える。ＧＰＵ３１２は、図２に示す機器クラスタ２００をレンダリングするのに適切である場合がある。ＧＰＵ３１２は、ハードウェアコンポーネント（例えば、ハードウェア処理ユニット）およびソフトウェアコンポーネント（例えば、ファームウェア、ならびにハードウェア処理ユニットにおける実行のための手順およびタスク）を含んでもよい。ＧＰＵユニットの動作および配設は、ＧＰＵの特定のアーキテクチャによって異なることになる。

【0038】

ＧＰＵ３１２は、図中でＰＵ０ ３４０、ＰＵ１ ３４１～ＰＵ（ｎ）３４２として標識された一つ以上の処理ユニット３３９を備えてもよい。任意の数の処理ユニットがあってもよい。ＧＰＵ３１２はメモリ３０９も含んでもよい。メモリ３０９は、例えば、一つ以上の処理ユニット３３９へアクセス可能な一つ以上のキャッシュ、バッファ、および／またはレジスタを含む、任意の種類のデータストアを含んでもよい。ＧＰＵ３１２は、例えば、ＧＰＵの低レベル管理を実施し、かつＧＰＵに向けられた命令のためのインターフェースを提供する場合があるファームウェア３１４を実行するための処理ロジックも含む。一部の配設では、ＧＰＵ３１２は、ＧＰＵ（例えば、その処理ユニット３３９および／またはファームウェア３１４）のユニットでの実行のために配設された関数、ルーチン、およびその他のコードの形態でソフトウェアを実行するように構成されてもよい。ＧＰＵ３１２は、例として、データを処理するため、ホストデータ処理システム３０２などの外部デバイスと通信するため、および一つ以上の処理ユニット３３９において実施される処理をサポートするために、様々なその他の機能要素を備えてもよい。

【0039】

グラフィック処理システム３００はまた、ＧＰＵ３１２のためのドライバ３０４も備えてもよい。例えば、ドライバ３０４は、ＧＰＵ３１２が提供されるデータ処理システムにおいてサポートされるソフトウェアドライバとすることができる。ドライバ３０４は、データ処理システムで実行しているプロセス（例えば、ソフトウェアアプリケーション）のためにＧＰＵにインターフェースを提供してもよい。図３に示す実施例では、グラフィック処理システム３００はホストデータ処理システム３０２を備える。一つ以上のプロセス３０１は、ホストデータ処理システム３０２上で実行されてもよい。これらのプロセスは、図３ではＡ０、Ａ１、Ａ（ｎ）として標識されている。ホストデータ処理システム上で実行する任意の数のプロセス３０１があってもよい。一つ以上のプロセス３０１は、ドライバ３０４によってＧＰＵ３１２と相互作用３３０してもよい。ホストデータ処理システム３０２は、プロセスおよびドライバが実行される一つ以上のプロセッサ（例えば、ＣＰＵ（図示せず））を備えてもよい。グラフィックアプリケーションプログラミングインターフェース（ＡＰＩ）３０３（例えば、ＯｐｅｎＧＬ）は、プロセスがレンダリングコールを送信することができる手段によってドライバに提供されてもよい。ドライバ３０４は、ホストデータ処理システム３０２のソフトウェアコンポーネントであってもよい。

【0040】

図５は、本明細書に記載の原理によるグラフィック処理システムにおいて安全重要レンダリングを実施する方法のフロー図である。安全重要レンダリングのためのグラフィカルデータは、グラフィック処理システムにおいて受信される５０１。ＡＰＩ３０３は、ＧＰＵ３１２がシーンをレンダリンするために、プロセス３０１からドローコールを受信するように配設されてもよい。例えば、ＡＰＩは、ＯｐｅｎＧＬ ＡＰＩであってもよく、またプロセスは、ＧＰＵが図２に示す機器クラスタを車両のダッシュボードにおける表示画面にレンダリングするために、ＯｐｅｎＧＬドローコールを発行するように配設されたアプリケーションであってもよい。ドライバ３０４はまた、安全性コントローラ３１１を備え、本明細書でさらに詳細に考察される。

【0041】

図３に図示さた実施例では、ドライバ３０４は、ＧＰＵ３１２にプロセスによってＡＰＩに送信されたドローコールを発効させるコマンドおよび／または制御命令を生成する。命令は、任意の適切な様式で（例えば、メモリ内のデータへの参照として）ＧＰＵ３１２にレンダリングされるシーンを定義するデータを渡してもよい。図３に示すように、前述の命令は、メモリ３０７内の一つ以上のバッファ３０８に送信３３２されてもよい。ＧＰＵ３１２は、メモリ３０９から命令を読み取って３３３もよい。メモリ３０７は、ホストデータ処理システム３０２に提供されてもよい。メモリ３０７はまた、ＧＰＵ３１２から戻る命令を受信する３３４ためにバッファ３１０も含んでもよい。バッファは円形バッファであってもよい。

【0042】

グラフィック処理ユニット３１２は、例えば、任意の種類のグラフィカルおよび／またはベクトルおよび／またはストリーム処理ユニットであってもよい。グラフィック処理ユニット３１２は、シーンのプリミティブの幾何学的形状処理および／または断片処理を実施するためのレンダリングパイプラインを含んでもよい。各処理ユニット３３９は、ＧＰＵの異なる物理的コアであってもよい。

【0043】

以下の実施例は、タイルベースのレンダリング技法を参照しながら説明されるが、代わりに、または追加的に、グラフィック処理システムは、即時モードレンダリング、またはタイルベースのレンダリングおよび即時モードレンダリングの両方の要素を組み合わせたハイブリッド技法などの、その他のレンダリング技法の能力を有する可能性があることを理解するべきである。

【0044】

本明細書の原理に従って構成されたグラフィック処理システムは、任意のタイルベースのアーキテクチャを有してもよく、例えば、システムはタイルベースの遅延レンダリングを実施するように動作可能であり得る。図３に描かれた各処理ユニット３３９は、任意の他の処理ユニットとは独立して、かつ任意の他のタイルとは独立して、タイルを処理することができる場合がある。

【0045】

タイルベースのレンダリングシステムは、複数のタイルへと分割されたレンダリング空間を使用する。当技術分野で知られているように、タイルは、任意の適切な形状およびサイズ、例えば、長方形（正方形を含む）または六角形とすることができる。レンダリング空間のタイルは、例えば、グラフィック処理システムでレンダリングされるフレームを表すレンダターゲットの一部分に関連する場合がある。フレームは、画像またはビデオフレームのすべてまたは一部であってもよい。一部の実施例では、レンダ出力は、表示される最終画像ではなく、代わりに、何か他のもの、例えば、そのテクスチャを含む画像をレンダリングする時に表面にその後に適用することができるテクスチャ、を表す場合がある。下記の実施例では、レンダ出力は、表示される画像を表すフレームであるが、その他の実施例では、レンダ出力は、テクスチャまたは環境マップなどのその他の表面を表すことができることを理解するべきである。

【0046】

タイルベースのレンダリングシステムは一般に、（ｉ）レンダリング空間の各タイルに対して、幾何学的形状のどのアイテムがそのタイルのレンダリングに関連する場合があるか（例えば、どのプリミティブが少なくとも部分的にタイルとオーバーラップするか）を決定するため幾何学的形状（例えば、プリミティブ）を処理する幾何学的形状処理フェーズ、および（ｉｉ）例えば、タイル内のピクセルの位置に対してピクセル値（例えば、バッファ（フレームバッファなど）内の記憶用および／または表示用のレンダリングシステムからの出力とすることができる）を生成するために、タイルをレンダリングするために特定のタイルをレンダリングすることに関連する幾何学的形状を処理するレンダリングフェーズ（すなわち、「断片処理フェーズ」）という動作の二つの別個のフェーズを実施する。タイルに関連する幾何学的形状を処理することは、例えば、タイルの試料位置でプリミティブをサンプリングすることによってプリミティブ断片を生成し、どの断片が見えるかを判定し、かつ断片がどのようにピクセルの外観に影響を与えるかを決定することを含んでもよい。試料位置とピクセルとの間の関係は１対１である場合がある。別の方法として、二つ以上の試料位置が、各ピクセル位置に関連する場合があり、それにより複数の試料位置に対して決定されたレンダリングされた値を組み合わせることによって最終ピクセル値を生成することができる。これは、アンチエイリアシングの実装のために有用である可能性がある。

【0047】

グラフィック処理ユニット（ＧＰＵ３１２など）は、例えば、タイリング、幾何学的形状処理、テクスチャマッピング、シェーディング、深度処理、頂点処理、タイル加速、クリッピング、カリング、プリミティブアセンブリ、カラー処理、ステンシル処理、アンチエイリアシング、レイトレーシング、ピクセル化、およびテッセレーションなどを含む、幾何学的形状処理フェーズおよびレンダリングフェーズにおけるグラフィック処理の任意の態様の一部またはすべてを実施するように構成されてもよい。

【0048】

幾何学的形状処理ロジックおよび断片処理ロジックは、グラフィック処理ユニット（ＧＰＵ３１２など）のリソースを共有してもよい。例えば、グラフィック処理ユニット（ＧＰＵ３１２の処理ユニット３３９など）の処理ユニットは、例えば、異なるソフトウェア命令を処理ユニットの実行ユニット上で実行することによって、幾何学的形状処理ロジックおよび断片処理ロジックの両方の一部を実装するために使用されてもよい。処理ユニット（処理ユニット３３９など）は、ＳＩＭＤ処理を実施するように構成されてもよい。

【0049】

本明細書に記載の原理によって構成されたグラフィック処理システムは、任意の種類のシーンをレンダリングするように配設されてもよい。

【0050】

幾何学的形状処理
幾何学的形状処理は、グラフィック処理ユニットに送信された幾何学的形状データを処理するために、グラフィック処理ユニット（ＧＰＵ３１２など）で実施されてもよい。幾何学的形状データは、レンダリングされるシーンの要素を表す場合がある。幾何学的形状データは、例えば、レンダリングされるプリミティブ（例えば、シーンにおけるプリミティブの頂点を説明する頂点データによって説明される）、テッセレーションされるパッチ、およびレンダリングされるその他の物体のうちの一つ以上を含むシーンにおいて幾何学的形状の複数のアイテムを表す場合がある。例えば、幾何学的形状データは、図２に示す機器クラスタのそれぞれの表示要素を表す一つ以上のプリミティブのセットを含んでもよい。プリミティブの各セットは、ソフトウェアアプリケーション３０１からの適切なドローコールによって作成されてもよい。プリミティブは、物体またはシーンの他の部分が構築されてもよい基本的幾何学的形状であってもよい。プリミティブは、例えば、三角形、線、または点であってもよい。

【0051】

幾何学的形状処理は、ＧＰＵの任意の適切なユニット、例えば、一つ以上のタイリングエンジン（図３には図示せず）で、および／または処理ユニット（処理ユニット３３９など）上で実行される一つ以上の処理モジュールで実施されてもよい。タイリングエンジンは、固定機能ハードウェア、ソフトウェア、またはそれらの任意の組み合わせに実装されてもよい。

【0052】

（例えば、アプリケーション３０１からのドローコールに応答して生成されるような）幾何学的形状データは、メモリ（メモリ３０７など）内に保持され、そのＧＰＵによって処理するためのＧＰＵのメモリ（ＧＰＵ３１２のメモリ３０９など）の中へと読み込まれてもよい。幾何学的形状フェーズは、レンダリングされるフレームの視点からのシーンを表す処理された幾何学的形状データを形成するため、シーンの要素（例えば、プリミティブ）を説明する幾何学的形状データを変換する。幾何学的形状フェーズ処理は、例えば、頂点処理（例えば、頂点シェーディング）、クリッピング、プロジェクション、カリング、およびタイリングなどを含む、幾何学的形状データ上の任意の適切な処理を実施してもよい。

【0053】

グラフィック処理ユニット（ＧＰＵ３１２など）での処理のために受信した幾何学的形状データは、安全重要である要素（例えば、レンダリングされるシーンの物体、プリミティブまたはその他の部分）を含んでもよい。ＧＰＵへと幾何学的形状を送信するアプリケーション（アプリケーション３０１など）は、レンダリングされる幾何学的形状のバッチを提供し、各バッチは安全重要要素を含む、または含まない。ＧＰＵのファームウェア（ファームウェア３１４など）は、どの幾何学的形状が安全重要であり、またどれがそうでないかを知っていてもよいが、ハードウェアはどの幾何学的形状が安全重要であるかを認識する必要はない。

【0054】

幾何学的形状処理は、典型的には、処理するために送信された幾何学的形状のアイテム（例えば、頂点から形成されたプリミティブ）を画面空間の中へと変換し、かつ変換されたプリミティブが視点からのシーンの中の視錐台内にあるかどうかに基づいて、幾何学的形状上に任意の必要なシェーディング（頂点シェーディング、ならびにクリッピングおよび／またはカリングなど）を実施するために、幾何学的形状データを処理すること（例えば、処理ユニット３３９で実行される命令によって実施されるように）を含む。テッセレーションは、例えば、頂点シェーディング、ハルシェーディング、テッセレーション因子の決定、ドメインシェーディング、および幾何学的形状シェーディングを実施することによって、入力パッチからのテッセレーションされたプリミティブを決定するために、この段階で実施されてもよい。

【0055】

本明細書に記載の実施例では、タイルごとに実施されるのではなく、レンダリングされる完全なフレームに関して幾何学的形状処理は実施される。これは、幾何学的形状が処理されるまで、例えば、シーンの要素が、レンダリングされるフレームのタイルに関連して位置する場合、要素の見かけのサイズ、およびそれらの要素が見えるかどうかが、知られていないためである。

【0056】

タイリングは、各タイルに対してどのプリミティブがタイルのレンダリングに関連するかを決定するように処理された幾何学的形状データ上で実施されてもよく、また各所与のタイルのレンダリングに関連するプリミティブを特定するようにプリミティブとメモリ内のタイルとの間の関連付けを保存してもよい。タイリングは、各タイルに対して、そのタイルに収まる要素（例えば、プリミティブ）のリスト（タイルリスト）を生成することを含んでもよい。こうしたタイルリストは、どの要素がどのタイルに含まれるかを示す任意の適切な形態で整理された任意のデータを含んでもよい。例えば、各タイルは、そのタイルのレンダリングに関連するすべてのプリミティブ（すなわち、そのタイルとオーバーラップするプリミティブ）を示すタイルリストを有してもよい。幾何学的形状処理フェーズの出力（例えば、タイルリストならびに変換されたおよび／または別のやり方で操作された幾何学的形状）は、断片処理フェーズで使用するためにメモリ３０９に保存されてもよい。幾何学的形状処理フェーズの出力は、パラメータデータと呼ばれる場合がある。

【0057】

タイリングは、一つ以上のタイリングエンジン（図示せず）で実施されてもよい。各タイリングエンジンは、処理ユニット（処理ユニット３３９など）で実行されるモジュールから受信された処理された幾何学的形状データ上で動作するように構成されてもよい。一部の実施例では、処理された幾何学的形状データのタイルへのタイリングは、処理ユニットにおいて実施されてもよい。タイリングは、任意の適切なアルゴリズムに従って（例えば、完全なタイリング、境界ボックスアプローチ、または階層タイリングアプローチを使用して）実施されてもよい。多くのこうしたアルゴリズムは既知であり、本明細書でさらに考察されない。タイルは、タイルの面積の任意の部分とオーバーラップするためにタイリングアルゴリズムによってその要素の任意の部分が計算される時（例えば、要素がタイルのピクセルのいずれかのすべてまたは一部とオーバーラップする時に）、シーンの要素を含むと考えられる場合がある。

【0058】

一部の実施例では、シーンのための処理された幾何学的形状データ（例えば、変換された頂点データ）の一部またはすべては、メモリ（例えば、ＧＰＵ３１２がその上に実装されているチップに関して「オフチップ」の状態にあってもよいシステムメモリ）内に保存されてもよい。システムメモリは、図３に示すメモリ３０７であってもよく、または図３に示されていない異なるメモリであってもよい。一部の実施例では、シーンのための処理された幾何学的形状データの一部またはすべては、ＧＰＵ３１２へと（例えば、メモリ３０９内に）局所的に保存されてもよい。レンダリングされるフレームの各タイルについて、そのタイルとオーバーラップする要素（例えば、プリミティブ）のリストがタイルリストとして保存されてもよい。タイルリストは、こうした要素に対する処理された幾何学的形状データの記憶が重複する（例えば、二つ以上のタイルをオーバーラップするシーンの要素に起因して）のを回避して、シーンのための処理された幾何学的形状データ内の変換された要素を参照する場合がある。他の実施例では、各タイルの断片処理を実施するために必要とされる処理された幾何学的形状データの一部またはすべてが、各タイルに対して別個に保存される場合がある。

【0059】

幾何学的形状フェーズからの処理されたデータは、断片処理フェーズでのその後の使用のため任意の適切な場所に保存される場合がある。例えば、図３を参照すると、幾何学的形状処理の出力（変換された頂点データおよびタイルリストなど）は、システムメモリ（例えば、パラメータバッファにおける）内に保存されてもよく、またメモリ３０９内のキャッシュを通して、断片処理を実施するために配設されたＧＰＵ３１２の処理ユニット３３９によってアクセスされてもよい。一部の実施例では、処理されたデータをシステムメモリに保存する代わりに（またはこれに加えて）、幾何学的形状フェーズからの処理されたデータは、処理ユニット３３９および／または記憶装置３０９に含まれるキャッシュで保持されてもよい。

【0060】

断片処理
断片処理は、幾何学的形状処理フェーズの出力（例えば、タイルリストおよび変換された幾何学的形状データ）に対して実施される。断片処理は、ＧＰＵの任意の適切なユニットにおいて（例えば、ラスタライザー、陰面消去（ＨＳＲ）ユニット、テクスチャフィルタリングユニット、および一つ以上のシェーダユニットのうちの一つ以上において）実施されてもよい。これらのユニットは図３には示されていない。ユニットのうちの一つ以上は、処理ユニット上で実行されるソフトウェアとして実装されてもよい。一部の実施例では、ラスタライザー、陰面消去（ＨＳＲ）ユニット、シェーダユニットおよびテクスチャフィルタリングユニットのうちの一つ以上は、固定機能ハードウェア内に実装されてもよい。より一般には、機能ユニットのいずれかは、ハードウェア、ソフトウェア、またはそれらの任意の組み合わせの中に実装することが可能である。ハードウェア（例えば、固定機能回路）内に機能モジュールを実装することは、一般に処理能力および待ち時間の観点では比較的より効率的であるが、比較的柔軟性がなく、これに反してソフトウェア内に機能モジュールを実装することは、処理能力および待ち時間の観点では比較的より効率的が低いが、ハードウェア設計プロセスの後でモジュールの動作を変更できるという観点では比較的柔軟である。

【0061】

一部の実施例では、タイルリストは、レンダリングされる各所与のタイル用にフェッチされ、そしてそのタイルの断片処理に関連するタイルリストによって示される変換されたプリミティブデータがフェッチされる。断片処理は、テクスチャ処理、シェーダ処理、ラスタライゼーション、陰面消去、およびアルファ処理のうちの一つ以上を含んでもよい。断片処理は、断片処理の異なる態様を実施するための一つ以上のユニット（例えば、パイプライン内に配設される）において実施されてもよい。

【0062】

各プリミティブが覆う試料の位置を特定し、かつそれらの試料位置でプリミティブ断片を生成するために、ラスタライゼーション（例えば、スキャン変換）が実施されてもよい。プリミティブ断片は、特定の試料位置におけるプリミティブの値（例えば、深度、テクスチャ座標など）を表す。典型的には、ラスタライゼーションが実施されるまで、プリミティブはその頂点の観点から定義される。

【0063】

陰面消去（ＨＳＲ）は、各試料位置でどのプリミティブ断片が見えるかを決定するために、各試料位置で深度比較がなされる断片処理中に実施されてもよい。

【0064】

断片処理の間にシェーディングおよび／またはテクスチャリングを実施してもよい。明度は、例えば、テクスチャ座標に基づいてテクスチャ試料をフェッチすることが関与する場合があるプリミティブ断片のためのシェーダプログラムを実行することによって、試料位置で見えるものとして特定されたプリミティブ断片の試料位置に対して決定されてもよい。テクスチャフィルタリングを実施してもよい。テクスチャ試料をフェッチすることは、例えば、所望のテクスチャ座標がテクスチャのテクセルの間にある場合などに、フィルタリング（例えば、保存されたテクスチャのテクセルの一群上での、バイリニアフィルタリング、トリリニアフィルタリング、またはアニソトロピックフィルタリング）を実施するテクスチャフィルタリングユニットが関与する場合がある。

【0065】

上記段落は、陰面消去がシェーディング／テクスチャリングの前に実施されるという意味で、「遅延」レンダリングアプローチを説明する。他の実施例では、遅延しないレンダリングが実施されてもよい。

【0066】

断片処理中に実施される計算の出力は、メモリ内の一つ以上のバッファ、例えば、（例えばピクセルの）明度を保存するためのカラーバッファ、（例えば、ピクセルの）深度値を保存するための深度バッファ、およびタイルのどの部分（例えば、ピクセル）がレンダリングされるかについての指示を保存するためのステンシルバッファのうちの一つ以上に書き込まれてもよい。こうしたバッファは、システムメモリおよび／またはメモリ内のＧＰＵキャッシュ（メモリ３０９など）のうちの一つ以上を含む、ＧＰＵアーキテクチャに適切な任意の様式で維持されてもよい。こうしたバッファの使用は当技術分野で周知であり、ここで詳細には考察されない。

【0067】

本開示の原理に従って構成されたグラフィック処理システムは、図２の機器クラスタなどの安全重要表示要素を含むフレームをレンダリングするように動作可能である。

【0068】

定期的リセット
ランダムエラーが、電離放射線、電圧スパイク、および電磁パルスなどの一時的なイベントによってハードウェアへと導入される可能性がある。バイナリシステムでは、一時的なイベントは、メモリ内およびプロセッサのデータパスに沿ってランダムなビットフリッピングを引き起こす可能性がある。一時的なエラーは、安全重要フォールトを引き起こす場合がある。例えば、ビットフリップは、メモリ内のデータを破損し、一つ以上のピクセル値の反転を引き起こす場合がある。図２に示す機器クラスタを参照すると、反転されたピクセル値は、重要警告アイコン（例えば、２０６）を不正確に表示する可能性がある。別の実施例では、一時的なエラーはＧＰＵに対する構成データを破損する場合がある。ＧＰＵ構成データの破損は、そのＧＰＵにその後に提供される任意のまたはすべてのデータのレンダリングに影響を与える場合がある。一時的なエラーは、安全重要グラフィックのレンダリングに影響を与える時（例えば、車両ユーザに対して安全重要警告アイコンに不正確または不完全な情報を提供することによって）、危険な結果をもたらす可能性がある。

【0069】

本明細書に記載の原理によって、安全重要レンダリング上の一時的なフォールトの影響を軽減するために、グラフィック処理システムは、安全重要レンダリングを実施するように構成されたグラフィック処理ユニットを定期的にリセットするように構成される。

【0070】

図３に戻ると、本明細書に記載の原理によるグラフィック処理システム３００は、少なくとも一つのグラフィック処理ユニット（ＧＰＵ）３１２を備える。グラフィック処理システム３００はまた、安全性コントローラ３１１も備える。安全性コントローラ３１１は、ハードウェア（例えば、固定機能ハードウェア）、ソフトウェア、またはそれらの任意の組み合わせ（例えば、汎用ハードウェアにおいて実行するソフトウェアプロセスとして）で具体化されてもよい。安全性コントローラ３１１は、ＧＰＵ３１２と通信していてもよい。安全性コントローラ３１１は、任意の適切な様式でＧＰＵ３１２と通信してもよい。安全性コントローラ３１１は、任意の適切な場所に存在してもよい。一実施例では、安全性コントローラ３１１およびＧＰＵ３１２は、チップアーキテクチャ上の同じシステムの一部であってもよい。図３では、安全性コントローラ３１１は、ホストデータ処理システム３０２内に含まれるものとして示されている。安全性コントローラ３１１は、ホストデータ処理システム３０２において実行されるプロセス（例えば、ソフトウェアアプリケーション）のためのＧＰＵ３１２にインターフェースを提供するドライバ３０４の構成要素であってもよい。安全性コントローラ３１１は、グラフィック処理ユニット３１２に対して定期的リセットをスケジュールするように構成される。

【0071】

図５は、本明細書に記載の原理によるグラフィック処理ユニットにおいて安全重要レンダリングを実施する方法のフロー図である。ＧＰＵ３１２の複数のリセットは、安全性コントローラ３１１によるリセット頻度に従ってスケジュールされる５０２。前述のリセットは本明細書では定期的リセットと呼ばれる。定期的リセットは、いかなる検出されたフォールトとも独立してスケジュールされ、かつ実施される。つまり、定期的リセットは、実施されるべきときに先立ってスケジュールされてもよい。

【0072】

ＧＰＵをリセットすることは、ＧＰＵを既知の安全な状態に戻すことによって、そのＧＰＵ上に存在するある特定のフォールトの持続性を制限しうる。リセットは、ＧＰＵフリップフロップの一部またはすべてを既知の安全な状態に戻すこと、および／またはＧＰＵ内のメモリに保存された一部またはすべてのデータを無効化することを伴いうる。したがって、リセットは、メモリ内のランダムなビットフリッピングからもたらされるものなどの、一時的なエラーを削減しうる（すなわち、一時的なエラーの持続性を制限する）。

【0073】

このアプローチは、フォールトの検出に応答してのみリセットを実施することよりも有利である。一部のフォールトは検出が困難または不可能である場合がある。例えば、一時的なフォールトを検出することは、図１を参照して説明したように、デュアルロックステップタイプの配設を実装することを必要とする場合がある。こうした配設では、一対の同一の処理コア１０１および１０２は、命令１０３のストリームを並列に処理するように構成される。処理コア１０１および１０２の出力を比較することができる。処理コア１０１および１０２の出力が一致しない時、を安全重要システムに上げることができる。しかしながら、第二の処理コアが必要とされるため、必然的に従来のプロセッサと比較して二倍のチップ面積を消費し、かつおよそ二倍の電力を消費するという点で、デュアルロックステッププロセッサは高価である。とは言うものの、本明細書に記載の原理によるグラフィック処理ユニットで安全重要レンダリングを実施する方法は、こうしたアプローチと組み合わせて使用されてもよいことを理解するべきである。これは、非常に厳格な安全要件を有するグラフィック処理システムのために適切である場合がある。例えば、デュアルロックステップ配設の処理コア１０１および１０２の一方または両方に対して、定期的リセットは本明細書に記載の原理によってスケジュールされてもよい。

【0074】

本明細書に記載のように、グラフィック処理ユニット（ＧＰＵ３１２など）の複数のリセットは、リセット頻度に従って、安全性コントローラ（安全性コントローラ３１１など）によってスケジュールされる５０２。一実施例では、リセット頻度は、処理されるフレームの数当たりの実施されるリセットの数、または処理されるタイルの数当たりの実施されるリセットの数によって定義されてもよい。例えば、リセット頻度は２０フレーム当たり一回のリセットであってもよい。リセット頻度は任意の値であり得、また極端な場合には、フレーム毎の後にリセットがスケジュールされてもよい。図３を参照すると、安全性コントローラ３１１は、フレームカウンター（図示せず）を備えてもよい。フレームカウンターは、ドライバ３０４がフレームのレンダリングを命令するたびにインクリメントされてもよい。安全性コントローラは、フレームカウンターが所定のフレームの数に達するたびにリセットをスケジュールしてもよい。次に、フレームカウンターをリセットする（すなわち、ゼロに設定する）ことができる。

【0075】

別の実施例では、リセット頻度は時間的な頻度であってもよい。すなわち、リセット頻度は、単位時間当たりに実施するリセットの数を定義してもよい。例えば、平均的な人間の応答時間は、典型的には２００～２１５ｍｓの領域内であり、そのためリセット頻度は２００ｍｓ当たり一回のリセットであってもよい。すなわち、リセット頻度は、人間のユーザが一時的なエラーに応答して行動を取ることが可能である前に、一時的なエラーを修正することができるように、平均的な人間の応答時間に依存して設定されてもよい。リセット頻度は、平均的な人間の応答時間に依存する必要はなく、実際には任意の値である可能性がある。図３を参照すると、安全性コントローラ３１１は、循環タイマ（図示せず）を備えてもよい。安全性コントローラは、循環タイマが終了するたびにリセットをスケジュールしてもよい。

【0076】

パフォーマンスコストは、ＧＰＵをリセットすることと関連付けられる。すなわち、リセットの持続時間中、ＧＰＵはいかなる処理タスクも実施できない場合がある。リセットの持続時間は、（i）リセットが開始された時間と、（ii）リセットが完了した後に次の処理命令が読み取られる時間との間の時間であってもよい。すなわち、リセット自体が実施される時間である。追加的に、リセットが完了した後、ＧＰＵのローカルメモリ（メモリ３０９など）内に保存されたデータは無効であり、前述のデータがローカルメモリ内へと再度書き込まれるまで、ＧＰＵはメインシステムメモリ（例えば、ホストデータ処理システム３０２のメモリ３０７）から必要とされるいかなるデータにアクセスしなければならないことを意味する。メインシステムメモリ（例えば、メモリ３０７）からデータを読み取ることは、典型的には局所的（例えば、メモリ３０９内）に保存されたデータにアクセスすることより遅い。ＧＰＵをリセットすることによって引き起こされる時間遅延は、ＧＰＵのスループットを減少させる場合があり、および／またはＧＰＵによって処理されるグラフィカルデータによって経験される待ち時間を増加させる場合がある。リセット頻度の設定には、レンダリングされたフレームを観ているユーザによって否定的に知覚されるであろう時間の間一時的なエラーが持続するのを防止するのにリセットが十分頻繁であるという、しかしまたグラフィック処理システムの知覚される性能に悪影響を及ぼす（例えば、ＧＰＵによって実施されるレンダリングの待ち時間の増加によって）ほど、リセットがあまり頻繁ではないというトレードオフがある。このトレードオフは、異なる実装では異なるように評価される場合があり、それに応じて調整することができる。例えば、グラフィック処理システムが自動車のダッシュボード用の画像をレンダリングする場合、エラーの持続性を減少することがレンダリング性能を改善することより重要であるため、リセット頻度が比較的高く設定される場合があるが、これに反して、グラフィック処理システムが、例えば、高速で移動する高解像度のビデオゲーム用の画像をレンダリングする場合、エラーの持続性を減少することよりレンダリング性能が重要であると考えられる場合があるため、リセット頻度は比較的低くなるように設定される場合がある。

【0077】

リセット頻度はあらかじめ定められてもよい。例えば、リセット頻度は設計時に設定されてもよい。リセット頻度は、グラフィック処理システム、またはグラフィック処理システム内に含まれる個々のグラフィック処理ユニットの設計時に設定されてもよい。別の方法として、リセット頻度はユーザ構成可能であってもよい。ユーザは、ホストデータ処理システム３０２上で実行するアプリケーション３０１を設定する時に、所望のリセット頻度を設定してもよい。別の実施例では、所望のリセット頻度は、ホストデータ処理システム３０２上で実行するアプリケーション３０１によって決定されてもよい。アプリケーションは、前述の所望のリセット頻度を安全性コントローラに通信してもよい（例えば、図３に示す実施例では、ドライバ３０４内のＡＰＩ３０３を介して）。

【0078】

図３に戻ると、複数のアプリケーション３０１（例えば、Ａ０、Ａ１～Ａ（ｎ））は、ホストデータ処理システム３０２上で実行されてもよい。各アプリケーション３０１は、所望のリセット頻度（例えば、ユーザによって指定されるか、またはアプリケーション自体によって決定される）を通信してもよい。各アプリケーションによって通信される所望のリセット頻度は、必ずしも同じではなくてもよい。安全性コントローラは、アプリケーション３０１によって通信された所望のリセット頻度のうちの任意の一つ以上に依存して、定期的リセットをスケジュールするためにリセット頻度を決定してもよい。例えば、安全性コントローラ３１１は、アプリケーションによって所望されるリセット頻度のうちの最も高いものに従って、定期的リセットをスケジュールしてもよい。これは、最も高いリセット頻度は一般に一時的なエラーを最も短い時間の間しか持続させることができず、かつ最も厳格な安全要件を有するアプリケーションによって必要とされる場合があるためである。別の実施例では、アプリケーション３０１によって提供される複数のリセット頻度は、組み合わされたリセット頻度に従って安全性コントローラによってスケジュールされる定期的リセットと数学的に組み合わせられてもよい（例えば、平均化によって）。

【0079】

リセット頻度は適合されてもよい。例えば、当初のリセット頻度は、本明細書に記載のように、あらかじめ定められてもよく、またはアプリケーションによって決定されてもよい。当初のリセット頻度は、安全重要レンダリングが実施されるＧＰＵの信頼度に依存して、リアルタイムで適合されてもよい。

【0080】

例えば、データ処理デバイスに対する安全性能は、一組の安全メトリックによって表現されてもよい。ある特定の安全メトリックは、サービスの信頼性の尺度（例えば、使用中のデータ処理デバイスの信頼性）を提供することができる。こうした安全メトリックの一実施例は、システムがエラーを検出する割合の測定値である。こうした安全メトリックを測定する方法は、当業者には周知であり、本明細書にさらに考察されない。安全性コントローラ３１１は、ＧＰＵ３１２の安全メトリックを監視してもよく、かつその安全メトリックに依存してリセット頻度を適合してもよい。例えば、安全性コントローラは、エラーが検出される割合を監視してもよい。一実施例では、安全性コントローラは、検出されたエラーの割合の増加に応答してリセット頻度を増加する場合があり、その逆である場合もある。

【0081】

本明細書に記載のように、ランダムエラーが、一時的なイベント（例えば、電離放射線、電圧スパイク、および電磁パルスによる）によってハードウェアへと導入される可能性がある。一実施例では、安全性コントローラ３１１は、これらの一時的なイベントのうちの一つ以上の発生を測定し、かつその監視に依存してリセット頻度を適合してもよい。例えば、電離放射線のレベルは、より高い高度においてより高くなることが知られており、またガイガー・ミュラー計数管などのデバイスを使用して測定可能である。安全性コントローラは、電離放射線のレベルを監視し、かつそのレベルに依存してリセット頻度を適合させてもよい。例えば、飛行機などのある特定の車両は、異なる高度において規則正しく動作する。飛行機のために機器クラスタ（図２に示すものと同様）をレンダリングするように動作可能なグラフィック処理システムでは、安全性コントローラ３１１は、増加した高度におけるより高いレベルの測定可能な電離放射線に起因してフライト中にＧＰＵ３１２に対するリセット頻度を増加させる場合がある。

【0082】

別の実施例では、検出されたフォールト（例えば、デュアルロックステップタイプの配設を使用して検出されたフォールト）に応答して追加的なＧＰＵリセットが最近実施された場合、安全性コントローラ３１１は次のスケジュールされた定期的リセットを遅延またはキャンセルしてもよい。

【0083】

グラフィック処理ユニット（ＧＰＵ３１２など）は、ハードウェアコンポーネント（例えば、ハードウェア処理ユニット３３９およびメモリ３０９）およびソフトウェアコンポーネント（例えば、ファームウェア３１４ならびにハードウェア処理ユニットにおける実行のための手順およびタスク）を含んでもよい。複数のスケジュールされたリセットは、一つ以上の異なるタイプのリセットを含んでもよい。例えば、リセットはソフトリセットであってもよい。ソフトリセットは、ＧＰＵ３１２のハードウェアコンポーネントをリセットすることをを含み得る。例えば、ソフトリセット中に、処理ユニット３３９は再初期化され、かつ既知の状態に戻される場合があり、またメモリ３０９内に含まれる任意のキャッシュ、レジスタ、またはバッファエントリは無効化される場合がある。ソフトリセット中に、ＧＰＵ３１２のソフトウェアコンポーネント（ファームウェア３１４など）は、実行を継続してもよい。対照的に、リセットはハードリセットであってもよい。ハードリセットは、ＧＰＵ３１２のハードウェアコンポーネントおよびソフトウェアコンポーネントの両方をリセットすることを含む場合がある。例えば、ハードリセット中に、処理ユニット３３９およびファームウェア３１４は再初期化され、かつ既知の状態に戻される場合があり、またメモリ３０９内のすべてのエントリ（任意のキャッシュ、レジスタ、またはバッファ内のエントリを含む）は無効化またはクリアされる場合がある。グラフィック処理ユニット（ＧＰＵ３１２など）のコンポーネントの任意の組み合わせをリセットすることを含む任意の他のタイプのリセットも可能である。

【0084】

一実施例では、複数のリセットは、ソフトリセットとハードリセットとの両方を含んでもよい。この実施例では、ソフトリセットおよびハードリセットは、異なるリセット頻度に従ってスケジュールされてもよい。例えば、ソフトリセットは、ソフトリセット頻度に従ってスケジュールされてもよい。ハードリセットは、ハードリセット頻度に従ってスケジュールされてもよい。ソフトリセット頻度は、ハードリセット頻度よりも高くてもよい。ソフトリセット頻度は、２０フレーム当たりに一回のリセットであってもよい。ハードリセット頻度は１００フレーム当たりに一回のリセットであってもよい。ソフトリセット頻度およびハードリセット頻度は任意の値とすることができる。ホストデータ処理システム３０１で実行されるアプリケーション３０１は、実施されるリセットのタイプおよび頻度を決定してもよい。

【0085】

実施されるリセットのタイプは、あらかじめ定められてもよく（例えば、グラフィック処理システムに対して設計時に、またはアプリケーションでユーザ構成可能に）、決定されてもよく（例えば、アプリケーションによって）、また本明細書に記載のようにリセット頻度と同様の様式で適合可能であってもよい。例えば、ＧＰＵの信頼レベルが低下する場合、そのＧＰＵのハードリセット頻度を増加してもよい。

【0086】

ＧＰＵ上のスケジュールされたリセットをアサートするために、安全性コントローラは、ＧＰＵの一つ以上のスケジュールされたリセットを定義するコマンドを含む命令を生成してもよい。リセットコマンドは、任意の適切な様式で（例えば、一つ以上のコマンドを含む制御ストリーム内の命令として）ＧＰＵに提供されてもよい。リセットコマンドは、ディスクリート命令であってもよい。一部の実施例では、リセットコマンドは、グラフィック処理命令内に埋め込まれてもよい。リセットコマンドは、グラフィック処理命令内にフラグとして埋め込まれてもよい。例えば、フラグは命令ヘッダ内に存在してもよい。前述の命令ヘッダは、命令のキックコマンド内にあってもよい。図３に示す実施例では、ＧＰＵ３１２のスケジュールされたリセットを定義するリセットコマンドを、ドライバ３０４によって命令バッファ３０８へと送信３３２してもよい。前述の命令を、ＧＰＵ３１２へ読み取られ３３３までのバッファ３０８内のキューに入れてもよい。

【0087】

リセットコマンドの受信に応答して、ＧＰＵは、リセットコマンドを受信する前に処理を開始した任意のタスクの処理を完了してもよい。次にスケジュールされたリセットが実行されてもよい。これは、部分的に完了した処理作業が無駄にならない場合があるという利点を有する。すなわち、リセットコマンドの読み取りに対するリセットを直ちに実施するよりも、任意の部分的に完了した処理タスクが完了するまでリセットを遅延することは、より効率的である可能性がある。これは、ＧＰＵが部分的に完了した処理タスクを完了する前にＧＰＵをリセットすることは、前述のタスクの処理全体をリセット後に再開させなければならないことにつながる場合があるためであり、例えば、そのタスクの処理を完了するために必要とされ、かつ処理中にメモリ内（例えば、メモリ３０９内のキャッシュ、レジスタ、またはバッファ）に保存される任意の中間処理結果は、リセットによって無効化される場合があるためである。

【0088】

リセットコマンドを受信すると、ＧＰＵは、リセットコマンドを受信する前に処理を開始していないあらゆる新規タスクの処理の開始を、ＧＰＵのリセットが完了するまで遅延してもよい。

【0089】

フォールトの検出に応答してリセットが実施されるシステムでは、ＧＰＵ内にフォールトがあることが既知であり、ＧＰＵが現在作業している作業の処理は不良である場合があり、そのためこの作業を継続する理由はないため、リセットはフォールトの検出後可能な限り早く実施される。対照的に、本明細書に記載の定期的リセットは、フォールトが検出されているかどうかに関係なく、スケジュールされる。そのため、定期的リセットがスケジュールされている時、ＧＰＵは、リセットを実施することができる好都合な時間まで、現在処理している作業を継続することができる。これは、リセットによって引き起こされるＧＰＵ性能に対する有害な影響を減少または最小化することができることを意味する。

【0090】

図４は、本明細書に記載の原理によるグラフィック処理ユニットのリセットを示す概略的タイムライン４００である。本明細書に記載のように、タイルベースのレンダリングシステムは一般に、（ｉ）レンダリング空間の各タイルに対して、幾何学的形状のどのアイテムがそのタイルのレンダリングに関連する場合があるか（例えば、どのプリミティブが少なくとも部分的にタイルにオーバーラップするか）を決定するため幾何学的形状（例えば、プリミティブ）を処理する幾何学的形状処理フェーズ、および（ｉｉ）タイルをレンダリングするために（例えば、タイル内のピクセルの位置に対してピクセル値を生成し、次にこれをレンダリングシステムからの出力（例えば、バッファ内の記憶用（フレームバッファなど）および／または表示用）とすることができるようにするために）、特定のタイルをレンダリングすることに関連する幾何学的形状が処理される断片処理フェーズ（すなわち、「レンダリングフェーズ））という動作の二つの別個のフェーズを実施する。

【0091】

図４は、タイムライン軸４１２の上方の幾何学的形状処理４１０およびタイムライン軸４１２の下方の断片処理４１１を概略的に表す。t＝０において、第一のフレームの幾何学的形状処理４０１が開始する。第一のフレームの幾何学的形状処理は、本明細書に記載の幾何学的形状処理原理に従って実施されてもよい。第一のフレームの幾何学的形状処理４０１が完了すると、第一のフレームの断片処理４０２が開始されてもよい。第二のフレームの幾何学的形状処理４０３はまた、第一のフレームの断片処理４０２がまだ進行中である間でも開始されてもよい。ＧＰＵは、異なるフレームの幾何学的形状処理および断片処理を同時に実施する能力を有する場合がある。すなわち、第二のフレームの幾何学的形状処理および第一のフレームの断片処理は、オーバーラップ４０９してもよい。一部の実施例では、フレームの幾何学的形状処理および別のフレームの断片処理は、完全にオーバーラップしてもよい。第二のフレームの幾何学的形状処理４０３が完了すると、第二のフレームの断片処理４０４を開始することができる。すなわち、図５に示すように、グラフィック処理ユニットで受信されたデータはレンダリングされる５０３。ＧＰＵのスケジュールされたリセットを示すフラグ４０５を含む第三のフレームの処理のための命令は、第二のフレームの断片処理４０４が実施されている間に読み取られてもよい。リセットコマンドを含む命令の読み取りに応答して、ＧＰＵは、第二のフレームの断片処理４０４を完了し、そしてリセット４０６を実施する前に、第三のフレームの幾何学的形状処理を遅延してもよい（そうでなければ、４０７によって示されるように発生していることになる）。リセット４０６が完了すると、ＧＰＵは、第三のフレームの幾何学的形状処理４０８の処理を開始してもよい。受信した各リセットコマンドは、同じ様式で処理されてもよい。このようにして、図５に示すように、安全性コントローラは、リセット頻度と整合して複数のリセットを実施する５０４。すなわち、安全性コントローラは、リセット頻度に基づいてグラフィック処理ユニットの複数のリセットを実施させるが、グラフィック処理のリセットが実施される頻度は、リセットがこれに従ってスケジュールされるリセット頻度に厳密に一致しなくてもよい（例えば、図４を参照して説明されるように、部分的に処理されたタスクの処理を完了することを可能にする遅延に起因して）。換言すれば、グラフィック処理のリセットが実施される頻度がリセット頻度に基づくように、安全性コントローラはグラフィック処理ユニットの複数のリセットをリセット頻度と整合して実施させる。別の言い方をすれば、リセット頻度がグラフィック処理のリセットが実施される頻度を示すように、安全性コントローラはリセット頻度と整合してグラフィック処理ユニットの複数のリセットを実施させる。

【0092】

ＧＰＵの効率は、幾何学的形状処理および断片処理の両方を同時に実施することによって増加する場合がある。これは、本明細書に記載のように、幾何学的形状処理フェーズおよび断片処理フェーズは、ＧＰＵの異なるユニットによって実施される場合があるためである。したがって、二つの異なるフレームの幾何学的形状処理および断片処理のオーバーラップは、ＧＰＵの処理ユニットのより多くが一度に使用されることを確実にする場合がある。図４に示すように、フレームの幾何学的形状処理をスケジュールされたリセットの後まで遅延することは、こうしたＧＰＵがそのフレームの幾何学的形状処理と別のフレーム（例えば、以前のフレーム）の断片処理とを同時に実施するその能力の長所を利用することができないことを意味する。これは、リセットをこのように実行することに関連付けられたさらなるパフォーマンスコストであると考えることができる。

【0093】

図４は概略的なものにすぎず、その他のタイプの処理（追加的または代替的な幾何学的形状処理および断片処理）は、演算データマスター（ＣＤＭ）によって取り扱われる演算処理、または二次元データマスター（ＴＤＭ）によって取り扱われる二次元シーンにおけるレンダリング幾何学的形状などの、グラフィック処理ユニットによって実施されてもよいことが理解されるべきである。

【0094】

本明細書に記載のように、リセットフラグは命令ヘッダ内に存在してもよい。命令は、フレームの幾何学的形状処理フェーズおよび断片処理フェーズの各々のキックコマンドを含んでもよい。図４に示すように、ＧＰＵ（例えば、ＧＰＵで実行されるファームウェア）は、幾何学的形状処理フェーズを開始する前に、すなわち、幾何学的形状処理フェーズに対するキックコマンドを実行する前に、命令ヘッダ内のリセットフラグをチェックしてもよい。これは、この段階でリセットフラグをチェックすることが、スケジュールされたリセットがフレーム同士の間で実施されることにつながるため、有利である可能性がある。また、断片処理フェーズを開始する前に、ＧＰＵに命令ヘッダ内のリセットフラグを代わりにチェックさせることも可能であることになることを理解するべきである。本明細書に記載のように、幾何学的形状処理フェーズの出力の一部またはすべては、ＧＰＵの外部のメモリに保存されてもよく、そのためこの場合には、前述の出力はリセット中に無効にならない場合がある。一部の事例では、幾何学的形状フェーズの出力は、各フレームに由来する一組の独立したタイルのとして外部メモリ内に保存されてもよい。断片処理は、各タイルに対して独立して実施されてもよい。ＧＰＵは、フレームの断片処理中にこれらのタイルの各々に逐次的にアクセスしてもよい。これらの場合には、二つのタイルの断片処理の間にリセットを実施することが可能である場合がある。これは、リセット頻度が、処理されるタイルの数当たりの実施されるリセットの数によって定義される場合がある、こうした実施例である。

【0095】

図３を再度参照すると、ＧＰＵ３１２は、図中でＰＵ０ ３４０、ＰＵ１ ３４１～ＰＵ（ｎ）３４２として標識された一つ以上の処理ユニット３３９を備える。任意の数の処理ユニットがあってもよい。安全性コントローラ３１１は、ＧＰＵ３１２の個々の処理ユニット３３９に対する定期的リセットを選択的にスケジュールする能力を有してもよい。安全性コントローラ３１１は、安全重要レンダリングを実施する個々の処理ユニット３３９のみに対するリセットを選択的にスケジュールしてもよい。別の実施例では、図３では一つのＧＰＵ３１２のみが示されているが、ホストデータ処理システム３０２と関連付けられた複数のＧＰＵがあってもよい。安全性コントローラ３１１は、前述の複数のＧＰＵの個々のＧＰＵに対する定期的リセットを選択的にスケジュールする能力を有してもよい。安全性コントローラ３１１は、安全重要レンダリングを実施するＧＰＵのみに対するリセットを選択的にスケジュールしてもよい。リセットは、特定の処理ユニット３３９またはＧＰＵへのリセットコマンドを含むグラフィック処理命令の各々に対処することによって、異なる処理ユニット３３９またはＧＰＵに対して選択的にスケジュールされてもよい。

【0096】

例えば、図２に示す機器クラスタ２００は、ダイヤルの縁の周りの速度値２０８と、角度方向が車両の現在の速度を示す針２０７とを有する従来のダイヤルの形態の速度計２０２を備える。機器クラスタは、油温ゲージ２０３、情報アイコン２０４（例えば、選択されたラジオ放送局を示す）、非重要警告アイコン２０５（例えば、空調システムでのフォールトを示す）、および重要警告アイコン２０６（例えば、深刻なエンジンの不調を示す）をさらに備える。表示要素の速度計２０２および重要警告アイコン２０６のみが、車両およびその使用者の安全に重要である。ＩＳＯ２６２６２規格のＡＳＩＬ Ｂなどの義務付けられた安全レベルを満足する様式で、これらの表示要素をレンダリングすることが必要である場合がある。油温ゲージ２０３、情報アイコン２０４、および非重要警告アイコン２０５は、その安全レベルに対してはレンダリングする必要はない。レンダリングされた機器クラスタを表すフレームをレンダリングするために使用されるレンダリング空間は、各々が複数のピクセルを含む複数のタイル２０１へと分割される。ハイライトされたタイル２０９のみが重要表示要素を含み、その中で重要表示要素の少なくとも一部がハイライトされたタイルの各々とオーバーラップする。安全性コントローラ３１１は、ハイライトされたタイルのレンダリングを実施するように構成された処理ユニット３３９またはＧＰＵのみの定期的リセットをスケジュールしてもよい。

【0097】

図３のグラフィック処理システムは、いくつかの機能ブロックを含むものとして示される。これは概略的のみであり、こうしたエンティティの異なるロジック要素間の厳密な区分を定義することを意図していない。各機能ブロックは、任意の適切な様式で提供されてもよい。グラフィック処理システムによって形成される本明細書に記載の中間値は、いずれの点でもグラフィック処理システムによって物理的に生成される必要はなく、またその入力と出力との間でグラフィック処理システムによって実施される処理を好都合に説明する論理値を単に表す場合があることを理解するべきである。

【0098】

本明細書に記載のグラフィック処理システムは、一つ以上の集積回路上のハードウェア内で具体化されてもよい。本明細書に記載のグラフィック処理システムは、本明細書に記載の方法のいずれかを実施するように構成されてもよい。

【0099】

コンピュータプログラムコードおよびコンピュータ可読命令という用語は、本明細書で使用される場合、機械言語、解釈言語、またはスクリプト言語で表現されるコードを含む、プロセッサに対する任意の種類の実行可能なコードを指す。実行可能コードとしては、バイナリコード、マシンコード、バイトコード、集積回路を定義するコード（ハードウェア記述言語またはネットリストなど）、およびＣ、Ｊａｖａ、またはＯｐｅｎＣＬなどのプログラミング言語コードで表現されたコードが挙げられる。実行可能コードは、例えば、仮想マシンまたはその他のソフトウェア環境で適切に実行、処理、解釈、コンパイル、実行される時に、実行可能コードがサポートされているコンピュータシステムのプロセッサに、コードによって指定されたタスクを実施させる、任意の種類のソフトウェア、ファームウェア、スクリプト、モジュール、またはライブラリであってもよい。コンピュータ可読記憶媒体の例としては、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、光ディスク、フラッシュメモリ、ハードディスクメモリ、ならびに磁気、光学、およびその他の技法を使用して、命令またはその他のデータを保存し、マシンによってアクセスすることができるその他のメモリデバイスが挙げられる。

【0100】

プロセッサ、コンピュータ、またはコンピュータシステムは、命令を実行することができるように、処理能力を有する任意の種類のデバイス、マシンもしくは専用回路、またはそれらの収集もしくは部分であってもよい。プロセッサは、例えば、ＣＰＵ、ＧＰＵ、ベクトルプロセッサ、テンソルプロセッサ、システムオンチップ、ステートマシン、メディアプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックアレイ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの任意の種類の汎用プロセッサまたは専用プロセッサであってもよい。コンピュータまたはコンピュータシステムは、一つ以上のプロセッサを備えてもよい。

【0101】

また、所望の機能を実行するために、集積回路を設計する、またはプログラム可能なチップを構成するために使用されるように、ＨＤＬ（ハードウェア記述言語）ソフトウェアなどの、本明細書に記載のハードウェアの構成を定義するソフトウェアを包含することも意図されている。すなわち、集積回路製造システムで処理される時に、本明細書に記載の方法のいずれかを実施するように構成されたグラフィック処理システムを製造するため、または本明細書に記載の任意の装置を備えるグラフィック処理システムを製造するためのシステムを構成する、集積回路定義データセットの形態のコンピュータ可読プログラムコードがその上にコードされたコンピュータ可読記憶媒体が提供されてもよい。集積回路定義データセットは、例えば、集積回路記述であってもよい。

【0102】

集積回路製造システムで、本明細書に記載のグラフィック処理システムを製造する方法が、提供されてもよい。集積回路製造システムで処理される時に、グラフィック処理システムを製造する方法を実施させる、集積回路定義データセットが提供されてもよい。

【0103】

集積回路定義データセットは、例えば、ネットリスト、プログラム可能なチップを構成するためのコード、レジスタ転送レベル（ＲＴＬ）コードとしてのものを含む任意のレベルで集積回路を定義するハードウェア記述言語、ＶｅｒｉｌｏｇまたはＶＨＤＬなどの高レベル回路表現、ならびにＯＡＳＩＳ（ＲＴＭ）およびＧＤＳＩＩなどの低レベル回路表現としてのコンピュータコードの形態であってもよい。集積回路を論理的に定義するより高レベルの表現（ＲＴＬなど）は、表現によってそのように定義された集積回路の製造定義を生成するために、回路要素の定義およびそれらの要素を組み合わせるためのルールを含むソフトウェア環境のコンテクストで、集積回路の製造定義を生成するように構成されたコンピュータシステムで処理されてもよい。マシンを定義するためにコンピュータシステムで実行されるソフトウェアの事例では典型的であるように、集積回路の製造定義を生成するために構成されたコンピュータシステムが、その集積回路の製造定義を生成するために集積回路を定義するコードを実行するために、一つ以上の中間ユーザステップ（例えば、コマンド、変数などの提供）が必要とされる場合がある。

【0104】

ここで、グラフィック処理システムを製造するシステムを構成するために、集積回路製造システムで集積回路定義データセットを処理する実施例を、図６に関して説明する。

【0105】

図６は、本明細書の実施例のいずれかに記載のグラフィック処理システムを製造するように構成された、集積回路（ＩＣ）製造システム１００２の一実施例を示す。詳細には、ＩＣ製造システム１００２は、レイアウト処理システム１００４と、集積回路生成システム１００６と、を備える。ＩＣ製造システム１００２は、ＩＣ定義データセット（例えば、本明細書の実施例のいずれかに記載のようなグラフィック処理システムを定義する）を受信し、ＩＣ定義データセットを処理し、そしてＩＣ定義データセット（例えば、本明細書の実施例のいずれかに記載のようなグラフィック処理システムを具体化する）に従ってＩＣを生成するように構成される。ＩＣ定義データセットの処理は、本明細書の実施例のいずれかに記載のグラフィック処理システムを具体化する集積回路を製造するために、ＩＣ製造システム１００２を構成する。

【0106】

レイアウト処理システム１００４は、ＩＣ定義データセットを受信および処理して、回路レイアウトを決定するように構成されている。ＩＣ定義データセットからの回路レイアウトを決定する方法は、当技術分野で知られており、例えば、ＲＴＬコードを合成して、論理的構成要素（例えば、ＮＡＮＤ、ＮＯＲ、ＡＮＤ、ＯＲ、ＭＵＸ、およびＦＬＩＰ－ＦＬＯＰ構成要素）の観点から生成される回路のゲートレベル表現を決定することが関与してもよい。論理的構成要素に対する位置情報を決定することにより、回路レイアウトを、回路のゲートレベル表現から決定することができる。これは、回路レイアウトを最適化するために、自動的に行われてもよく、またはユーザの関与によって行われてもよい。レイアウト処理システム１００４が回路レイアウトを決定したとき、レイアウト処理システム１００４は、ＩＣ生成システム１００６に、回路レイアウト定義を出力してもよい。回路レイアウト定義は、例えば、回路レイアウト記述であってもよい。

【0107】

ＩＣ生成システム１００６は、当技術分野で知られているように、回路レイアウト定義に従ってＩＣを生成する。例えば、ＩＣ生成システム１００６は、ＩＣを生成するために、半導体デバイス製造プロセスを実装してもよく、これには、その間に半導体材料で作製されたウェハ上に、電子回路が徐々に生成される、フォトリソグラフィーおよび化学処理ステップの複数ステップのシーケンスが関与する場合がある。回路レイアウト定義は、回路定義に従ってＩＣを生成するためのリソグラフィープロセスで使用することができる、マスクの形態であってもよい。別の方法として、ＩＣ生成システム１００６に提供される回路レイアウト定義は、ＩＣ生成システム１００６が、ＩＣの生成で使用するための適切なマスクを形成するために使用することができる、コンピュータ可読コードの形態であってもよい。

【0108】

ＩＣ製造システム１００２によって実施される異なるプロセスは、すべて一つの場所で、例えば、一人の当事者によって実装されてもよい。別の方法として、ＩＣ製造システム１００２は、プロセスの一部が異なる場所で実施されてもよく、かつ異なる当事者によって実行されてもよいような、分散システムであってもよい。例えば、（ｉ）ＩＣ定義データセットを表すＲＴＬコードを合成して、生成される回路のゲートレベル表現を形成する段階、（ｉｉ）ゲートレベルの表現に基づいて、回路レイアウトを生成する段階、（ｉｉｉ）回路レイアウトに従って、マスクを形成する段階、および（ｉｖ）マスクを使用して集積回路を製造する段階のうちの一部は、異なる場所で、かつ／または異なる当事者によって実施されてもよい。

【0109】

他の実施例では、集積回路製造システムでの集積回路定義データセットの処理は、回路レイアウトを決定するようにＩＣ定義データセットを処理されることなく、グラフィック処理システムを製造するためのシステムを構成してもよい。例えば、集積回路定義データセットは、ＦＰＧＡなどの再構成可能プロセッサの構成を定義してもよく、またそのデータセットの処理は、その定義された構成を有する再構成可能なプロセッサを生成する（例えば、構成データをＦＰＧＡにロードすることによって）ためのＩＣ製造システムを構成してもよい。

【0110】

一部の実施形態では、集積回路製造定義データセットは、集積回路製造システムで処理される時に、集積回路製造システムに、本明細書に記載のようにデバイスを生成させてもよい。例えば、集積回路製造定義データセットによって、図６に関して上述した様式での集積回路製造システムの構成は、本明細書に記載のようにデバイスを製造させる場合がある。

【0111】

一部の実施例では、集積回路定義データセットは、データセットで定義されたハードウェア上で、またはデータセットで定義されたハードウェアと組み合わせて実行される、ソフトウェアを含むことができる。図６に示す実施例では、ＩＣ生成システムは、集積回路を製造する際に、集積回路定義データセットで定義されたプログラムコードに従ってその集積回路の上へとファームウェアをロードするために、または別のやり方で、集積回路で使用するためにプログラムコードを集積回路に提供するために、集積回路定義データセットによってさらに構成されてもよい。

【0112】

デバイス、装置、モジュール、および／またはシステム（ならびに本明細書で実装される方法）における本出願で述べられる概念の実装形態は、既知の実装形態と比較した時に性能の改善を生じさせる場合がある。性能の改善は、計算性能の増加、待ち時間の短縮、スループットの向上、および／または消費電力の削減のうちの一つ以上を含んでもよい。こうしたデバイス、装置、モジュール、およびシステム（例えば、集積回路における）の製造中、性能改善は、物理的実装とトレードオフとなる可能性があり、それにより、製造方法を改善することができる。例えば、性能改善は、レイアウト面積に対してトレードされる場合があり、それによって、既知の実装形態の性能と一致するが、使用するシリコンは少なくなる。これは、例えば、機能ブロックをシリアル化した形式で再利用すること、またはデバイス、装置、モジュール、および／もしくはシステムの要素同士の間で機能ブロックを共有することによって行われてもよい。逆に言えば、デバイス、装置、モジュール、およびシステムの物理的実装の改善（シリコン面積の減少など）を生じさせる本出願で述べられた概念は、改善された性能とトレードされる場合がある。これは、例えば、既定の面積予算内でモジュールの複数のインスタンスを製造することによって行われてもよい。

【0113】

出願人は、これによって、こうした特徴または特徴の組み合わせが、本明細書で開示されるいずれかの問題を解決するかどうかに関係なく、こうした特徴または組み合わせを、当業者の共通の一般的な知識に照らして、全体として本明細書に基づいて実行することができる程度まで、本明細書に記載の各個々の特徴および二つ以上のそのような特徴の任意の組み合わせを単独で開示する。前述の説明の観点から、本発明の範囲内で様々な修正を行うことができることは、当業者には明らかであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】