JP2017516207A - グラフィックス処理におけるレンダーターゲットに基づいたフレックスレンダリング - Google Patents

グラフィックス処理におけるレンダーターゲットに基づいたフレックスレンダリング Download PDF

Info

Publication number
JP2017516207A
JP2017516207A JP2016562910A JP2016562910A JP2017516207A JP 2017516207 A JP2017516207 A JP 2017516207A JP 2016562910 A JP2016562910 A JP 2016562910A JP 2016562910 A JP2016562910 A JP 2016562910A JP 2017516207 A JP2017516207 A JP 2017516207A
Authority
JP
Japan
Prior art keywords
gpu
rendering mode
frame
binning
rendering
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016562910A
Other languages
English (en)
Other versions
JP2017516207A5 (ja
JP6541685B2 (ja
Inventor
ムラット・バルチ
アヴィナシュ・セータラマイア
クリストファー・ポール・フラスカティ
ジョナラ・ガッダ・ナゲンドラ・クマール
コリン・クリストファー・シャープ
デイヴィッド・リゲール・ガルシア・ガルシア
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2017516207A publication Critical patent/JP2017516207A/ja
Publication of JP2017516207A5 publication Critical patent/JP2017516207A5/ja
Application granted granted Critical
Publication of JP6541685B2 publication Critical patent/JP6541685B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T11/00—2D [Two Dimensional] image generation
    • G06T11/40—Filling a planar surface by adding surface attributes, e.g. colour or texture
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2330/00—Aspects of power supply; Aspects of display protection and defect management
    • G09G2330/02—Details of power systems and of start or stop of display operation
    • G09G2330/021—Power management, e.g. power saving

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Graphics (AREA)
  • Image Generation (AREA)
  • Controls And Circuits For Display Device (AREA)

Abstract

グラフィックス処理ユニット(GPU)を備えるデバイスは、メモリと、少なくとも1つのプロセッサとを含む。少なくとも1つのプロセッサは、GPUがGPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信し、受信されたコマンドパケット内の情報またはGPUの状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定し、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングするように構成されてもよい。

Description

本出願は、その内容全体が参照により本明細書に組み込まれる、2014年4月21日に出願された米国仮出願第61/982,147号の優先権を主張する。
本開示は、グラフィックス処理のための技法に関する。
グラフィカルユーザインターフェースおよびビデオゲーム用のコンテンツなど、ディスプレイ用の視覚コンテンツは、グラフィックス処理ユニット(GPU)によって生成される場合がある。GPUは、2次元または3次元(3D)オブジェクトを、表示される場合がある2次元(2D)ピクセル表現に変換する場合がある。3Dオブジェクトについての情報を表示できるビットマップに変換することは、ピクセルレンダリングとして知られており、相当なメモリおよび処理能力を必要とする。これまでは、3Dグラフィックス能力は高性能のワークステーションでのみ利用可能であった。しかしながら、今では、3Dグラフィックスアクセラレータは、パーソナルコンピュータ(PC)において、ならびにスマートフォン、タブレットコンピュータ、ポータブルメディアプレーヤ、ポータブルビデオゲームコンソールなどの組込みデバイスにおいてよく見られる。典型的には、組込みデバイスは、従来のPCと比較して、より少ない計算能力およびメモリ容量を有する。したがって、3Dグラフィックスレンダリング技法における複雑さの増大は、そのような技法を組込みシステム上で実装するときの問題点を提示する。
一般に、本開示は、GPUがグラフィックス処理において直接レンダリングとビニングレンダリングとの間で切り替えることを可能にする技法、GPUがレンダリングモードを決定することを可能にするための技法、およびGPUでレンダリングループを実行するための技法について説明する。
本開示の一例では、グラフィックス処理の方法は、グラフィックス処理ユニット(GPU)によって、GPUがGPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信するステップと、GPUによって、受信されたコマンドパケット内の情報またはGPUの状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定するステップと、GPUによって、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングするステップとを含む。
本開示の技法による別の例は、グラフィックス処理ユニット(GPU)を備えるデバイスについて説明する。GPUは、メモリと、少なくとも1つのプロセッサとを含む。少なくとも1つのプロセッサは、GPUがGPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信し、受信されたコマンドパケット内の情報またはGPUの状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定し、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングするように構成されてもよい。
本開示の技法による別の例は、デバイスについて説明する。デバイスは、GPUがGPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信するための手段と、受信されたコマンドパケット内の情報またはGPUの状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定するための手段と、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングするための手段とを備える。
本開示の技法による別の例は、その上に記憶された命令を含む非一時的コンピュータ可読記憶媒体について説明する。命令は、実行されると、少なくとも1つのプロセッサに、GPUがGPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信させ、受信されたコマンドパケット内の情報またはGPUの状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定させ、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングさせてもよい。
本開示の技法による、特定のレンダリングモードを使用するかどうかを決定するために使用されてもよい例示的なコンピューティングデバイスを示すブロック図である。 図1のCPU6、GPU12、およびシステムメモリ10の例示的な実装形態をさらに詳細に示すブロック図である。 ビニングレンダリングモードで使用される場合のフレームのビンを示す概念図である。 ビニングレンダリングモードで使用される場合のフレームのビンをより詳細に示す概念図である。 「ソフトウェア」ビニングを使用するビニングレンダリングモードのコマンドバッファを示す概念図である。 「ハードウェア」ビニングを使用するビニングレンダリングモードのコマンドバッファを示す概念図である。 直接レンダリングモードのコマンドバッファを示す概念図である。 異なるレンダリングモードのコマンドバッファを示す概念図である。 本開示の技法による、直接レンダリングモードまたはビニングレンダリングモードを使用してシーンをレンダリングするための例示的なコマンド構造を示す概念図である。 本開示の一例による方法を示すフローチャートである。
本開示は、グラフィックス処理のための技法に関し、より詳細には、グラフィックス処理システムにおいてGPUがレンダリングモードを決定し、レンダリングモード間で切り替えることを可能にする技法に関する。
現在のグラフィックスレンダリングシステムは、典型的には、シーンをレンダリングするためにビニングレンダリングモード(タイルベースのレンダリングと呼ばれることがある)または直接レンダリングモードを利用する。ビニングレンダリングでは、2Dまたは3Dシーンの1つのフレームは、フレームをより小さい部分(たとえば、矩形のビンまたはタイル)に分け、これらのビンの各々を別々にレンダリングすることによって、レンダリングされる。ビニングレンダリングは、モバイルアプリケーションなど、専用の高速グラフィックスメモリ(GMEM)がほとんど利用できないアプリケーションに有用であり、ならびにメモリ帯域幅が制限されている事例において有用である。タイルのサイズは、GMEMにおいて利用可能なデータの量を表すように構成することが可能である。たとえば、GMEMが512kBを記憶することができる場合、タイルのサイズは、そのタイルに含まれるそのピクセルデータが512kB以下になるように構成されてもよい。
一方、直接レンダリングモードにおけるグラフィックス処理は、フレームをより小さいビンに分けない。代わりに、フレームの全体が一度にレンダリングされる。いくつかのグラフィックス処理システム(たとえば、モバイルデバイス上のグラフィックス処理システム)では、ピクセルデータのフレーム全体を保持するのに十分なGMEMがない。代わりに、直接レンダリングモードでは、ダイナミックランダムアクセスメモリ(DRAM)などのより遅いシステムメモリが、フレームをレンダリングするために使用されてもよい。
以前のGPUコマンドパケットはそれぞれ、単一の間接バッファ(IB)のみを含んでいた。シーンをレンダリングするために、GPUドライバは複数のコマンドパケットを生成し、シーンをレンダリングするために間接バッファごとに1つのコマンドパケットを必要とした。「スモールバッチ」問題と呼ばれる、レンダリングされるべき少数の三角形を各々が含む複数のコマンドパケットを生成するCPUおよびメモリのオーバーヘッドは、非常に高くなる可能性がある。一例として、アプリケーションがドローコール間で最小量の状態しか変更していないとき、GPUドライバは不相応に大量の作業を行う場合がある。本開示の技法は、シーンをレンダリングするために必要なすべてのIBを多数の小さいパケットにではなく単一のコマンドパケットに含めることによって、また、レンダリング負荷の一部をCPU上で実行されるGPUドライバからGPU自体に移行することによって、CPUおよびメモリのオーバーヘッドを低減する場合がある。
加えて、CPUベースのGPUドライバは、CPUおよびGPUに、シーンをレンダリングするために必要なすべてのコマンドパケットを生成するためにレンダリングループを何度もループさせ、そのシーンをレンダリングさせる場合がある。レンダリングループは、レンダリングされるべきフレームのための各個々のビンをレンダリングするためにGPUドライバが実行するループである。本開示の技法は、追加のレンダリング情報、たとえば、コマンドパケットに組み込まれるビンにより、また、レンダリング論理をGPUドライバからGPUに移行することによって、レンダリングループを低減または削減する場合がある。
本開示の技法はまた、GPUがシーンのためのレンダリングモードを決定するために使用する場合がある、よりきめ細かいリアルタイムのGPU状態情報(たとえば、ヒューリスティック)を考慮する。CPUベースのGPUドライバは、GPUからのGPU処理負荷などのGPU状態を要求することができるが、CPU上で実行されるドライバは、ポーリング要求および/またはGPUからの統計値の蓄積を使用してしか、そうすることができない。したがって、CPUドライバがアクセスすることができる任意のGPU状態は正確ではない場合があり、最新ではない場合がある。したがって、GPU状態を決定することに関する本開示の技法は、より正確で最新のGPU状態に基づいたレンダリングモードのより正確な決定を考慮する。
加えて、本開示の技法は、コマンドパケットに、レンダーターゲット情報、および/またはレンダリングされるべきシーンの解像度などのCPUが蓄積したヒューリスティックを含む。GPUがレンダーターゲット情報にアクセスできるので、GPU状態を考慮することなしにGPUが使用するためのレンダリングモードをCPUに決定させるのではなく、GPU自体が、コマンドパケット、ならびにGPU負荷および電力消費量などの他のGPU状態ヒューリスティックに少なくとも部分的に基づいて、直接モードまたはビニングモードを使用してシーンをレンダリングするかどうかを決定してもよい。直接レンダリングモードを使用することは、レンダリングされるべきジオメトリの量が少ないときにレンダリング性能を改善する場合がある一方で、ビニングレンダリングモードは、直接レンダリングモードと比べて電力を節約する場合がある。したがって、GPUが直接レンダリングおよび間接レンダリングから選択することを可能にすることは、電力、性能、および他の制約に基づいてGPUがレンダリングを最適化するための柔軟性をもたらす。
一般に、直接レンダリングモードは、ビニングレンダリングモードよりも遅い場合がある。しかしながら、ビニングレンダリングモードは、いくらかの固有のオーバーヘッドを有する。しかしながら、直接レンダリングモードの負荷が十分に軽い場合、直接レンダリングモードを使用することはビニングレンダリングモードよりも好ましい場合がある。オーバードローの量が少ない、したがって、オーバーヘッドがより少ないとき、ビニングレンダリングモードが好ましい場合がある。オーバードローは、たとえば、重複する三角形により、単一のピクセルがフレームごとにレンダリングされる/更新される回数に対応する。
高いオーバードローは、高い帯域幅利用率および直接レンダリングモード用の(比較的遅い)システムメモリとの対話を引き起こす場合がある。本明細書で説明するヒューリスティックは、非限定的な例として、レンダリングされるピクセル数、オーバードロー、クロック速度、GPUアーキテクチャなどの要因に基づいて、直接レンダリングモードがビニングレンダリングモードよりも速いポイントをGPUが決定することを可能にする場合がある。
本開示の一例では、グラフィックス処理の方法は、GPUによって、GPUがGPUによってレンダリングされるべきフレームの一部分をレンダリングするために直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すコマンドパケットを受信するステップを含む。GPUは、受信されたコマンドパケットまたはGPU状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定してもよい。GPUは、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングしてもよい。
図1は、本開示の技法による、特定のレンダリングモードを使用するかどうかを決定するために使用されてもよい例示的なコンピューティングデバイスを示すブロック図である。コンピューティングデバイス2は、たとえば、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、コンピュータワークステーション、ビデオゲームプラットフォームもしくはコンソール、たとえば、セルラー電話もしくは衛星電話などの携帯電話、固定電話、スマートフォン、ポータブルビデオゲームデバイスもしくは携帯情報端末(PDA)などのハンドヘルドデバイス、パーソナル音楽プレーヤ、ビデオプレーヤ、ディスプレイデバイス、テレビジョン、テレビジョンセットトップボックス、サーバ、中間ネットワークデバイス、メインフレームコンピュータ、任意のモバイルデバイス、またはグラフィカルデータを処理および/もしくは表示する任意の他のタイプのデバイスを含んでもよい。
図1の例に示すように、コンピューティングデバイス2は、ユーザ入力インターフェース4、中央処理ユニット(CPU)6、メモリコントローラ8、システムメモリ10、グラフィックス処理ユニット(GPU)12、グラフィックスメモリ14、ディスプレイインターフェース16、ディスプレイ18、ならびにバス20および22を含んでもよい。いくつかの例では、グラフィックスメモリ14はGPU12に「オンチップ」であってもよいことに留意されたい。場合によっては、図1に示すすべてのハードウェア要素は、たとえば、システムオンチップ(SoC)設計において、オンチップであってもよい。ユーザ入力インターフェース4、CPU6、メモリコントローラ8、GPU12およびディスプレイインターフェース16は、バス20を使用して互いに通信してもよい。メモリコントローラ8およびシステムメモリ10はまた、バス22を使用して互いに通信してもよい。バス20、22は、第3世代バス(たとえば、HyperTransportバスまたはInfiniBandバス)、第2世代バス(たとえば、アドバンストグラフィックスポートバス、 Peripheral Component Interconnect(PCI) Expressバス、または Advanced eXentisible Interface(AXI)バス)または別のタイプのバスもしくはデバイス相互接続などの様々なバス構造のいずれかであってもよい。図1に示す異なる構成要素間のバスおよび通信インターフェースの特定の構成は例にすぎず、同じまたは異なる構成要素を有するコンピューティングデバイスおよび/または他のグラフィックス処理システムの他の構成が本開示の技法を実装するために使用されてもよいことに留意されたい。
CPU6は、コンピューティングデバイス2の動作を制御する汎用または専用プロセッサを備えてもよい。ユーザは、CPU6に1つまたは複数のソフトウェアアプリケーションを実行させるために、入力をコンピューティングデバイス2に与える場合がある。CPU6上で実行されるソフトウェアアプリケーションは、たとえば、オペレーティングシステム、ワードプロセッサアプリケーション、電子メールアプリケーション、スプレッドシートアプリケーション、メディアプレーヤアプリケーション、ビデオゲームアプリケーション、グラフィカルユーザインターフェースアプリケーションまたは別のプログラムを含んでもよい。加えて、CPU6は、GPU12の動作を制御するためのGPUドライバ7を実行する場合がある。ユーザは、ユーザ入力インターフェース4を介してコンピューティングデバイス2に結合されたキーボード、マウス、マイクロフォン、タッチパッドまたは別の入力デバイスなどの1つまたは複数の入力デバイス(図示せず)を介して、入力をコンピューティングデバイス2に与える場合がある。
CPU6上で実行されるソフトウェアアプリケーションは、ディスプレイ18へのグラフィックスデータのレンダリングを行わせるようCPU6に命令する1つまたは複数のグラフィックスレンダリング命令を含んでもよい。いくつかの例では、ソフトウェア命令は、たとえば、オープングラフィックスライブラリ(OpenGL(登録商標))API、オープングラフィックスライブラリ組込みシステム(OpenGL ES)API、Direct3D API、X3D API、RenderMan API、WebGL API、または任意の他の公的もしくは独占的な(proprietary)規格グラフィックスAPIなどのグラフィックスアプリケーションプログラミングインターフェース(API)に準拠する場合がある。命令はまた、様々な例では、OpenCLなどのいわゆるヘテロジニアスコンピューティングライブラリおよび/またはDirectComputeに準拠する場合がある。グラフィックスレンダリング命令を処理するために、CPU6は、GPU12にグラフィックスデータのレンダリングの一部またはすべてを実行させるために、1つまたは複数のグラフィックスレンダリングコマンドをGPU12に(たとえば、GPUドライバ7を通じて)発行する場合がある。いくつかの例では、レンダリングされるべきグラフィックスデータは、グラフィックスプリミティブ、たとえば、点、線、三角形、四角形、三角形ストリップなどのリストを含んでもよい。
メモリコントローラ8は、システムメモリ10を出入りするデータの転送を容易にする。たとえば、メモリコントローラ8は、メモリ読取りコマンドおよびメモリ書込みコマンドを受信し、メモリサービスをコンピューティングデバイス2内の構成要素に提供するためにメモリシステム10に対してそのようなコマンドをサービスする場合がある。メモリコントローラ8は、メモリバス22を介してシステムメモリ10に通信可能に結合される。メモリコントローラ8は、CPU6とシステムメモリ10の両方とは別の処理モジュールであるものとして図1に示されているが、他の例では、メモリコントローラ8の機能の一部またはすべては、CPU6およびシステムメモリ10の一方または両方で実装される場合がある。
システムメモリ10は、CPU6が実行するためにアクセス可能なプログラムモジュールおよび/もしくは命令ならびに/またはCPU6上で実行されるプログラムが使用するためのデータを記憶してもよい。たとえば、システムメモリ10は、ディスプレイ18上にグラフィカルユーザインターフェース(GUI)を提示するためにCPU6によって使用されるウィンドウマネージャアプリケーションを記憶してもよい。加えて、システムメモリ10は、ユーザアプリケーションと、アプリケーションに関連付けられたアプリケーションサーフェスデータとを記憶してもよい。システムメモリ10は加えて、コンピューティングデバイス2の他の構成要素が使用するためのおよび/またはそれらの構成要素によって生成される情報を記憶してもよい。たとえば、システムメモリ10は、GPU12用のデバイスメモリとして働いてもよく、GPU12による操作を受けるべきデータならびにGPU12によって実行された動作から生じたデータを記憶してもよい。たとえば、システムメモリ10は、テクスチャバッファ、深度バッファ、ステンシルバッファ、頂点バッファ、フレームバッファなどの任意の組合せを記憶してもよい。システムメモリ10は、たとえば、ランダムアクセスメモリ(RAM)、スタティックRAM(SRAM)、ダイナミックRAM(DRAM)、読取り専用メモリ(ROM)、消去可能プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、フラッシュメモリ、磁気データ媒体または光学記憶媒体など、1つまたは複数の揮発性もしくは不揮発性メモリまたはストレージデバイスを含んでもよい。
GPU12は、1つまたは複数のグラフィックスプリミティブをディスプレイ18にレンダリングするためのグラフィックス演算を実行するように構成されてもよい。したがって、CPU6上で実行されるソフトウェアアプリケーションのうちの1つがグラフィックス処理を必要とするとき、CPU6はディスプレイ18にレンダリングするためにグラフィックスコマンドおよびグラフィックスデータをGPU12に与えてもよい。グラフィックスデータは、たとえば、描画コマンド、状態情報、プリミティブ情報、テクスチャ情報などを含んでもよい。GPU12は、ある事例では、CPU6よりも効率的な、複雑なグラフィック関連動作の処理を実現する高度並列構造で構築されてもよい。たとえば、GPU12は、複数の頂点またはピクセル上で並行して動作するように構成される複数の処理要素を含んでもよい。GPU12の高度並列の性質は、ある事例では、CPU6を使用してシーンを直接ディスプレイ18に描画するよりも速く、GPU12がグラフィックス画像(たとえば、GUIならびに2次元(2D)および/または3次元(3D)グラフィックスシーン)をディスプレイ18上で描画することを可能にする場合がある。
GPU12は、ある事例では、コンピューティングデバイス2のマザーボードに統合される場合がある。他の事例では、GPU12は、コンピューティングデバイス2のマザーボード中のポートにインストールされたグラフィックスカード上に存在する場合があるか、そうでなければコンピューティングデバイス2と相互動作するように構成される周辺デバイス内に組み込まれる場合がある。GPU12は、1つまたは複数のマイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、デジタル信号プロセッサ(DSP)、または他の等価の集積論理回路もしくはディスクリート論理回路などの1つまたは複数のプロセッサを含んでもよい。
GPU12は、グラフィックスメモリ14に直接結合されてもよい。したがって、GPU12は、バス20を使用することなしに、グラフィックスメモリ14からデータを読み取り、グラフィックスメモリ14にデータを書き込んでもよい。言い換えれば、GPU12は、オフチップメモリの代わりにローカルストレージを使用して、データをローカルに処理してもよい。これは、重いバストラフィックを経験する場合がある、GPU12がバス20を介してデータの読取りおよび書込みを行う必要をなくすことによって、GPU12がより効率的に動作することを可能にする。しかしながら、ある事例では、GPU12は別個のメモリを含まないが、代わりにバス20を介してシステムメモリ10を利用する場合がある。グラフィックスメモリ14は、たとえば、ランダムアクセスメモリ(RAM)、スタティックRAM(SRAM)、ダイナミックRAM(DRAM)、消去可能プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、フラッシュメモリ、磁気データ媒体または光学記憶媒体など、1つまたは複数の揮発性もしくは不揮発性メモリまたはストレージデバイスを含んでもよい。
CPU6および/またはGPU12は、レンダリングされた画像データをフレームバッファ15に記憶してもよい。フレームバッファ15は、独立したメモリであってもよく、またはシステムメモリ10内で割り振られてもよい。ディスプレイインターフェース16は、フレームバッファ15からデータを取り出し、レンダリングされた画像データによって表される画像を表示するようにディスプレイ18を構成してもよい。いくつかの例では、ディスプレイインターフェース16は、フレームバッファから取り出されたデジタル値をディスプレイ18が消費できるアナログ信号にコンバートするように構成されるデジタルアナログコンバータ(DAC)を含んでもよい。他の例では、ディスプレイインターフェース16は、処理のためにデジタル値を直接ディスプレイ18に渡してもよい。ディスプレイ18は、モニタ、テレビジョン、投影デバイス、液晶ディスプレイ(LCD)、プラズマディスプレイパネル、有機LED(OLED)ディスプレイなどの発光ダイオード(LED)アレイ、陰極線管(CRT)ディスプレイ、電子ペーパー、表面伝導電子放出ディスプレイ(SED)、レーザーテレビジョンディスプレイ、ナノ結晶ディスプレイまたは別のタイプのディスプレイユニットを含んでもよい。ディスプレイ18は、コンピューティングデバイス2内に統合されてもよい。たとえば、ディスプレイ18は、携帯電話のスクリーンであってもよい。代替的に、ディスプレイ18は、ワイヤードまたはワイヤレス通信リンクを介してコンピューティングデバイス2に結合されたスタンドアロンデバイスであってもよい。たとえば、ディスプレイ18は、ケーブルまたはワイヤレスリンクを介してパーソナルコンピュータに接続されたコンピュータモニタまたはフラットパネルディスプレイであってもよい。
本開示の一例によれば、CPU6および/またはGPUドライバ7は、GPU12が直接レンダリングモードおよびビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを生成するように構成されてもよい。GPUコマンドパケットは、本明細書でより詳細に説明するように、様々な例ではPM4(「プログラミングモデル4」)フォーマットを有するGPUコマンドパケットを含んでもよい。
コマンドパケットは、レンダリングシーン記述子、間接バッファ情報などのフレームをレンダリングするためのコマンド、ならびに構成データ(たとえば、構成ペア)、およびレンダリングされるべきシーンの解像度(たとえば、ピクセル単位の高さおよび幅)などのレンダリングされるべきシーンについての情報を含んでもよい。GPU12は、受信されたコマンドパケットに含まれる情報に少なくとも部分的に基づいて、グラフィカルシーンをレンダリングするために直接モードレンダリングを使用するかまたはビニングモードレンダリングを使用するかを決定してもよい。しかしながら、コマンドパケットは好ましいレンダリングモードを直接的に示さない場合がある。
レンダーターゲット記述子は、GPU12が実行する場合があるレンダリングモードごとの構成情報、プリアンブル、レンダリング、ビニングおよびコマンドバッファポインタを含む。いくつかの例では、レンダーターゲット記述子はまた、GPU12が現在のシーンのためのレンダリングモードを決定するために使用する場合がある情報を含んでもよい。たとえば、レンダーターゲット記述子はまた、ビニングレンダリングモードを使用してレンダリングするために使用されるべきビンの高さおよび幅を示す場合がある。GPU12は、構成情報を調べ、レンダーターゲット記述子の情報に基づいて、現在のシーンのためのレンダリングモードを決定してもよい。決定されたレンダリングモードに基づいて、GPU12は、必要に応じて、ターゲットレンダリングモードに対応するコマンドバッファにおいて命令を実行する。
コマンドパケットに含まれる間接バッファ情報に関して、コマンドパケットは、1つまたは複数の間接バッファ、色アンリゾルブ(unresolve)バッファ、および深度ステンシルアンリゾルブバッファへのポインタを含んでもよい。コマンドパケットはまた、最上位ビットと、これらの間接バッファの長さとを含んでもよい。PM4コマンドのタイプは、MSBに含まれる。GPU12はアンリゾルブバッファを使用してもよく、GPU12はシステムメモリ10などの外部メモリからGPUメモリに値を読み込んでもよい。GPU12は、たとえば、2つ以上のシーンにわたって変化しないピクセルデータを保持するために、シーンの一部分のみが新しいデータで更新されているとき、アンリゾルブプロセスを実行してもよい。
コマンドパケットはまた、様々な「クリア」(「破棄」とも呼ばれる)矩形を含んでもよい。クリア矩形は、あるフレームから次のフレームに保持されない、フレームバッファ、たとえばUIの領域を示す場合がある。GPU12は、クリア矩形によって指定された領域からピクセルまたはジオメトリデータをロードしない場合がある。
GPU12はまた、GPU状態ヒューリスティックに基づいて、直接レンダリングを使用するかまたはビニングレンダリングを使用するかを決定してもよい。GPUヒューリスティックの例は、GPU処理負荷、GPU電力消費量、および/またはGPUメモリ使用量もしくはGPU12の任意の他の状態パラメータを含んでもよい。直接レンダリングを使用するかまたはビニングレンダリングを使用するかを決定することの一例として、GPU12は、GPU電力消費量がしきい値電力消費量を超えるときに電力を節約するために、直接レンダリングモードから切り替えてもよい。GPU12は、同様に、電力消費量またはGPU負荷が低いとき、ビニングレンダリングモードから直接レンダリングモードに切り替えてもよい。
本開示の技法によれば、GPU12は、GPUがフレームの一部分をレンダリングするために直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すレンダーターゲット記述子を受信し、受信されたコマンドパケットまたはGPU状態のうちの少なくとも1つに基づいて、GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定し、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングするように構成されてもよい。
図2は、図1のCPU6、GPU12、およびシステムメモリ10の例示的な実装形態をさらに詳細に示すブロック図である。CPU6は、少なくとも1つのソフトウェアアプリケーション24、グラフィックスAPI26、およびGPUドライバ7を含んでもよく、これらの各々は、CPU6上で実行される1つまたは複数のソフトウェアアプリケーションまたはサービスであってもよい。GPU12は、グラフィックス処理コマンドを実行するために一緒に動作する複数のグラフィックス処理ステージを含むグラフィックス処理パイプライン30を含んでもよい。GPU12は、ビニングレンダリングモードおよび直接レンダリングモードを含む様々なレンダリングモードでグラフィックス処理パイプライン30を実行するように構成されてもよい。図2に示すように、グラフィックス処理パイプライン30は、コマンドエンジン32、ジオメトリ処理ステージ34、ラスタ化ステージ36、およびピクセル処理パイプライン38を含んでもよい。グラフィックス処理パイプライン30中の構成要素の各々は、固定機能構成要素、(たとえば、プログラマブルシェーダユニット上で実行されるシェーダプログラムの一部としての)プログラマブル構成要素として、または固定機能構成要素とプログラマブル構成要素の組合せとして実装されてもよい。CPU6およびGPU12が利用可能なメモリは、システムメモリ10およびフレームバッファ15を含んでもよい。フレームバッファ15は、システムメモリ10の一部であってもよく、またはシステムメモリ10とは別であってもよい。フレームバッファ15は、レンダリングされた画像データを記憶してもよい。
ソフトウェアアプリケーション24は、GPU12の機能を利用する任意のアプリケーションであってもよい。たとえば、ソフトウェアアプリケーション24は、GUIアプリケーション、オペレーティングシステム、ポータブルマッピングアプリケーション、エンジニアリングもしくは美術アプリケーション用のコンピュータ支援設計プログラム、ビデオゲームアプリケーション、または2Dもしくは3Dグラフィックスを使用する別のタイプのソフトウェアアプリケーションであってもよい。
ソフトウェアアプリケーション24は、グラフィカルユーザインターフェース(GUI)および/またはグラフィックスシーンをレンダリングするようGPU12に命令する1つまたは複数の描画命令を含んでもよい。たとえば、描画命令は、GPU12によってレンダリングされるべき1つまたは複数のグラフィックスプリミティブのセットを定義する命令を含んでもよい。いくつかの例では、描画命令は、GUIで使用される複数のウィンドウ処理サーフェスのすべてまたは一部をまとめて定義してもよい。追加の例では、描画命令は、アプリケーションによって定義されたモデルスペースまたはワールドスペース内の1つまたは複数のグラフィックスオブジェクトを含むグラフィックスシーンのすべてまたは一部をまとめて定義してもよい。
ソフトウェアアプリケーション24は、1つまたは複数のグラフィックスプリミティブを表示可能なグラフィックス画像にレンダリングするための1つまたは複数のコマンドをGPU12に発行するために、グラフィックスAPI26を介してGPUドライバ7を呼び出す場合がある。様々な例では、コマンドは、コマンドならびにシーン(すなわち、1つまたは複数のフレーム)をレンダリングすることに関する他の情報を含んでもよいデータのいわゆる「パケット」を含んでもよい。たとえば、ソフトウェアアプリケーション24は、プリミティブ定義をGPU12に与えるために、グラフィックスAPI26を介してGPUドライバ7を呼び出す場合がある。ある事例では、プリミティブ定義は、描画プリミティブ、たとえば、三角形、矩形、三角形ファン、三角形ストリップなどのリストの形でGPU12に与えられる場合がある。プリミティブ定義は、レンダリングされるべきプリミティブに関連付けられた1つまたは複数の頂点を指定する頂点仕様を含んでもよい。頂点仕様は、頂点ごとの位置座標と、ある事例では、たとえば、色座標、法線ベクトル、およびテクスチャ座標など、頂点に関連付けられた他の属性とを含んでもよい。プリミティブ定義はまた、プリミティブタイプ情報(たとえば、三角形、矩形、三角形ファン、三角形ストリップなど)、スケーリング情報、回転情報などを含んでもよい。ソフトウェアアプリケーション24によってGPUドライバ7に発行された命令に基づいて、GPUドライバ7は、プリミティブをレンダリングするためにGPU12が実行する1つまたは複数の動作を指定する1つまたは複数のコマンドを公式化する場合がある。GPU12がCPU6からコマンドを受信すると、グラフィックス処理パイプライン30はコマンドを復号し、コマンドにおいて指定された動作を実行するようにグラフィックス処理パイプライン30内の1つまたは複数の処理要素を構成する。指定された動作を実行した後、グラフィックス処理パイプライン30は、レンダリングされたデータをディスプレイデバイスに関連付けられたフレームバッファ15に出力する。グラフィックス処理パイプライン30は、ビニングレンダリングモードおよび直接レンダリングモードを含む複数の異なるレンダリングモードのうちの1つで実行するように構成されてもよい。ビニングレンダリングモードおよび直接レンダリングモードの動作について、以下でより詳細に説明する。
GPUドライバ7は、1つまたは複数のシェーダプログラムをコンパイルし、コンパイルされたシェーダプログラムをGPU12内に含まれる1つまたは複数のプログラマブルシェーダユニットにダウンロードするようにさらに構成されてもよい。シェーダプログラムは、たとえば、OpenGL Shading Language(GLSL)、High Level Shading Language(HLSL)、C for Graphics(Cg)シェーディング言語などの高レベルシェーディング言語で書かれる場合がある。コンパイルされたシェーダプログラムは、GPU12内のプログラマブルシェーダユニットの動作を制御する1つまたは複数の命令を含んでもよい。たとえば、シェーダプログラムは、頂点シェーダプログラムおよび/またはピクセルシェーダプログラムを含んでもよい。頂点シェーダプログラムは、プログラマブル頂点シェーダユニットまたはユニファイドシェーダユニットの実行を制御し、1つまたは複数の頂点ごとの動作を指定する命令を含んでもよい。ピクセルシェーダプログラムは、プログラマブルピクセルシェーダユニットまたはユニファイドシェーダユニットの実行を制御するピクセルシェーダプログラムを含み、1つまたは複数のピクセルごとの動作を指定する命令を含んでもよい。
GPUドライバ7はまた、フレームまたはフレームの一部分をレンダリングするときにGPU12が使用すべきレンダリングモードを定義するコマンド、たとえば、1つまたは複数のコマンド、ヘッダ、レンダーシーン記述子、バッファなどからなるコマンドパケットをGPU12に送信してもよい。たとえば、GPUドライバ7は、特定のフレームが直接モードレンダリングを使用してレンダリングされるべきであり、別のフレームがビニングモードレンダリングを使用してレンダリングされるべきであることを決定する場合がある。GPUドライバ7はまた、GPUコマンドパケットをGPU12に送信することによって、フレームの一部分をレンダリングするときにどのレンダリングモードを使用するかを決定するようGPU12に命令する場合がある。
本開示の技法は、CPU6上で実行されるGPUドライバ7などの別の処理ユニットの介入なしに、GPU12が直接モードレンダリングおよびビニングモードレンダリングから選択することを可能にする。直接レンダリングモードおよびビニングレンダリングモードから選択するための以前の技法は、特定のフレームまたはフレームの部分をレンダリングするときにどのレンダリングモードを使用するかを決定し、それをGPU12に命令するために、GPUドライバ7および/またはCPU6がヒューリスティックに関連付けられた多数の計算を実行することを必要とする可能性がある。ドライバが実行したヒューリスティックベースの計算は大量のCPU使用率を引き起こす可能性があり、このことは、アプリケーション性能、および場合によっては、コンピューティングデバイス2の全体的な応答性に影響を及ぼす可能性がある。
上記で示したように、GPU12は、受信されたコマンドパケットからの情報に基づいておよび/またはGPU状態に基づいて決定されたモードのための待ち行列に入れられたレンダリングコマンドの実行シーケンスおよび順序を制御する。GPU状態は、たとえば、電力消費量、メモリ消費量、作業負荷情報、および/または他の状態もしくはプロファイリング情報に関する、GPU12が維持するリアルタイム状態および統計値を含んでもよい。
GPU12が直接レンダリングモードおよびビニングレンダリングモードから選択することを可能にするために、CPU6はGPUコマンドパケット(たとえば、レンダーシーン記述子)を生成し、GPUコマンドパケットをGPU12に送信する場合がある。様々な例では、コマンドパケットはPM4パケットを含んでもよい。上記で説明したように、PM4パケットは、1つまたは複数のIBへのポインタと、スクリーン解像度、(たとえば、16ピクセル倍数での)ビン幅、リゾルブバッファ、クリア領域、および他の情報を含むレンダーターゲット情報とを含んでもよい。
グラフィックス処理パイプライン30は、GPUドライバ7を介してCPU6から1つまたは複数のグラフィックス処理コマンドを受信し、グラフィックス処理コマンドを実行して表示可能なグラフィックス画像を生成するように構成されてもよい。上記で説明したように、グラフィックス処理パイプライン30は、グラフィックス処理コマンドを実行するために一緒に動作する複数のステージを含む。しかしながら、そのようなステージは必ずしも別個のハードウェアブロックで実施される必要はないことに留意されたい。たとえば、ジオメトリ処理ステージ34およびピクセル処理パイプライン38の部分は、ユニファイドシェーダユニットの一部として実施されてもよい。さらにまた、グラフィックス処理パイプライン30は、CPU6が実行するように構成される記述子パケットをGPUドライバ7から受信したことに応答して、ビニングレンダリングモードおよび直接レンダリングモードを含む複数の異なるレンダリングモードのうちの1つで実行するように構成されてもよい。
コマンドエンジン32は、グラフィックス処理コマンドを受信し、グラフィックス処理コマンドを実施するための様々な動作を実行するようにグラフィックス処理パイプライン30内の残りの処理ステージを構成してもよい。コマンドエンジン32は、GPUドライバ7からコマンドパケットを受信してもよい。グラフィックス処理コマンドは、たとえば、描画コマンドおよびグラフィックス状態コマンドを含んでもよい。描画コマンドは、1つまたは複数の頂点の位置座標、および、ある事例では、たとえば、色座標、法線ベクトル、テクスチャ座標およびかぶり座標など、頂点の各々に関連付けられた他の属性値を指定する頂点仕様コマンドを含んでもよい。グラフィックス状態コマンドは、プリミティブタイプコマンド、変換コマンド、照明コマンドなどを含んでもよい。プリミティブタイプコマンドは、レンダリングされるべきプリミティブのタイプおよび/またはプリミティブを形成するために頂点がどのように組み合わされるかを指定してもよい。変換コマンドは、頂点に対して実行すべき変換のタイプを指定してもよい。照明コマンドは、グラフィックスシーン内の異なる照明のタイプ、方向および/または配置を指定してもよい。コマンドエンジン32は、ジオメトリ処理ステージ34に、1つまたは複数の受信されたコマンドに関連付けられた頂点および/またはプリミティブに対してジオメトリ処理を実行させる場合がある。
GPU12はコマンドパケットを受信し、GPUコマンドパケットを受信したことに応答して、CPU6からのさらなる介入を必要とせずに直接モードレンダリングおよびビニングモードレンダリングから選択してもよい。GPU12は、GPU状態ヒューリスティックおよびコマンドパケットのデータのうちの少なくとも1つに基づいて、直接モードレンダリングを使用するかまたはビニングモードレンダリングを使用するかを決定してもよい。別の例として、GPU12は、直接レンダリングモードがビニングレンダリングモードよりも速くシーンをレンダリングするのはいつかを決定するために、GPU状態を使用してもよい。
一例として、GPU12は、直接レンダリングモードおよびビニングレンダリングモードから選択するために、GPU状態、たとえば、GPU処理負荷、電力消費量、メモリ使用量、またはGPU12の1つもしくは複数の他の性能プロファイリング特性を使用してもよい。ヒューリスティックに基づいて直接レンダリングとビニングレンダリングとの間で切り替えることの一例として、GPU12は、GPU電力消費量がしきい値電力消費量を超えるときに電力を節約するために、直接レンダリングモードから切り替えてもよい。GPU12は、同様に、電力消費量またはGPU負荷が低いとき、ビニングレンダリングモードから直接レンダリングモードに切り替えてもよい。
一例として、高いGPU利用率(たとえば、80%超)は、GPUがビジーである時間が多いこと、およびGPUのバスがデータ転送で飽和していることを示すことができる。GPU12は、測定された転送スループットをGPU12の理論上の最大スループットと比較することによって、発生しているデータ転送の量を測定する場合がある。GPU12はまた、GPU12の「常時オン」カウンタと比較して、個々のGPUハードウェアブロックのビジーカウンタの値を読み取る場合がある(たとえば、測定期間の間、GPU12によって使用された1000サイクルのうちの900サイクルでシェーダプロセッサがビジーであった場合)。
ジオメトリ処理ステージ34は、ラスタ化ステージ36のためのプリミティブデータを生成するために、1つまたは複数の頂点に対して頂点ごとの動作および/またはプリミティブセットアップ動作を実行してもよい。各頂点は、たとえば、位置座標、色値、法線ベクトル、およびテクスチャ座標などの属性のセットに関連付けられてもよい。ジオメトリ処理ステージ34は、様々な頂点ごとの動作に従って、これらの属性のうちの1つまたは複数を修正する。たとえば、ジオメトリ処理ステージ34は、修正された頂点位置座標を生成するために、頂点位置座標に対して1つまたは複数の変換を実行してもよい。ジオメトリ処理ステージ34は、修正された頂点位置座標を生成するために、たとえば、モデリング変換、ビューイング変換、投影変換、モデルビュー(ModelView)変換、モデルビュー投影(ModelViewProjection)変換、ビューポート変換および深度範囲スケーリング変換のうちの1つまたは複数を頂点位置座標に適用してもよい。ある事例では、頂点位置座標はモデル空間座標であってもよく、修正された頂点位置座標はスクリーン空間座標であってもよい。スクリーン空間座標は、モデリング変換、ビューイング変換、投影変換およびビューポート変換の適用の後で取得されてもよい。ある事例では、ジオメトリ処理ステージ34はまた、頂点の修正された色座標を生成するために、頂点に対して頂点ごとの照明動作を実行してもよい。ジオメトリ処理ステージ34はまた、たとえば、正規変換、ノーマル正規化動作(normal normalization operations)、ビューボリュームクリッピング、同次除算動作および/またはバックフェースカリング(culling)動作を含む他の動作を実行してもよい。
ジオメトリ処理ステージ34は、ラスタ化されるべきプリミティブを定義する1つまたは複数の修正された頂点のセットを含むプリミティブデータ、ならびにプリミティブを形成するために頂点がどのように組み合わされるかを指定するデータを生成してもよい。修正された頂点の各々は、たとえば、修正された頂点位置座標と、頂点に関連付けられた処理された頂点属性値とを含んでもよい。プリミティブデータはまとめて、グラフィックス処理パイプライン30のさらなるステージによってラスタ化されるべきプリミティブに対応する場合がある。概念的には、各頂点は、プリミティブの2つの辺がぶつかるプリミティブの角に対応する場合がある。ジオメトリ処理ステージ34は、さらなる処理のためにプリミティブデータをラスタ化ステージ36に与えてもよい。
いくつかの例では、ジオメトリ処理ステージ34のすべてまたは一部は、1つまたは複数のシェーダユニット上で実行される1つまたは複数のシェーダプログラムによって実施される場合がある。たとえば、ジオメトリ処理ステージ34は、そのような例では、頂点シェーダ、ジオメトリシェーダまたはそれらの任意の組合せによって実施される場合がある。他の例では、ジオメトリ処理ステージ34は、固定機能ハードウェア処理パイプラインとして、または固定機能ハードウェアと1つもしくは複数のシェーダユニット上で実行される1つもしくは複数のシェーダプログラムの組合せとして実施される場合がある。
ラスタ化ステージ36は、ジオメトリ処理ステージ34から、ラスタ化されるべきプリミティブを表すプリミティブデータを受信し、プリミティブをラスタ化して、ラスタ化されたプリミティブに対応する複数のソースピクセルを生成するように構成される。いくつかの例では、ラスタ化ステージ36は、どのスクリーンピクセルロケーションがラスタ化されるべきプリミティブによってカバーされるかを決定し、プリミティブによってカバーされると決定されたスクリーンピクセルロケーションごとのソースピクセルを生成してもよい。ラスタ化ステージ36は、たとえば、エッジウォーキング(edge-walking)技法、エッジ方程式評価(evaluating edge equations)などの、当業者に知られている技法を使用することによって、どのスクリーンピクセルロケーションがプリミティブによってカバーされるかを決定してもよい。ラスタ化ステージ36は、さらなる処理のために得られたソースピクセルをピクセル処理パイプライン38に与えてもよい。
ラスタ化ステージ36によって生成されたソースピクセルは、スクリーンピクセルロケーション、たとえば、宛先ピクセルに対応し、1つまたは複数の色属性に関連付けられる場合がある。特定のラスタ化されたプリミティブのために生成されたソースピクセルのすべては、ラスタ化されたプリミティブに関連付けられていると言える。プリミティブによってカバーされるべき、ラスタ化ステージ36によって決定されたピクセルは、概念的には、プリミティブの頂点を表すピクセル、プリミティブの辺を表すピクセル、およびプリミティブの内部を表すピクセルを含んでもよい。
ピクセル処理パイプライン38は、ラスタ化されたプリミティブに関連付けられたソースピクセルを受信し、ソースピクセルに対して1つまたは複数のピクセルごとの動作を実行するように構成される。ピクセル処理パイプライン38によって実行される場合があるピクセルごとの動作は、たとえば、アルファテスト、テクスチャマッピング、色計算、ピクセルシェーディング、ピクセルごとの照明、かぶり処理、ブレンディング、ピクセルオーナーシップテスト、ソースアルファテスト、ステンシルテスト、深度テスト、シザーテストおよび/またはスティップリング動作を含む。加えて、ピクセル処理パイプライン38は、1つまたは複数のピクセルごとの動作を実行するための1つまたは複数のピクセルシェーダプログラムを実行してもよい。ピクセル処理パイプライン38によって生成された得られたデータは、本明細書では宛先ピクセルデータと呼ばれ、フレームバッファ15に記憶される場合がある。宛先ピクセルデータは、処理されたソースピクセルと同じ表示ロケーションを有する、フレームバッファ15内の宛先ピクセルに関連付けられる場合がある。宛先ピクセルデータは、たとえば、色値、宛先アルファ値、深度値などのデータを含んでもよい。
フレームバッファ15は、GPU12のための宛先ピクセルを記憶する。各宛先ピクセルは、一意のスクリーンピクセルロケーションに関連付けられる場合がある。いくつかの例では、フレームバッファ15は、宛先ピクセルごとの色成分および宛先アルファ値を記憶してもよい。たとえば、フレームバッファ15はピクセルごとの赤(Red)、緑(Green)、青(Blue)、アルファ(Alpha)(RGBA)成分を記憶してもよく、"RGB"成分は色値に対応し、"A"成分は宛先アルファ値に対応する。フレームバッファ15およびシステムメモリ10は別個のメモリユニットであるものとして示されているが、他の例では、フレームバッファ15はシステムメモリ10の一部であってもよい。
上記で説明したように、グラフィックス処理パイプライン30は、ビニングレンダリングモードおよび直接レンダリングモードを含む特定のレンダリングモードに従って、グラフィックス画像をレンダリングしてもよい。ビニングレンダリングモードに従ってレンダリングするとき、グラフィックス処理パイプライン30は、プリミティブのバッチ(すなわち、1つまたは複数のプリミティブ)を受信して、得られるグラフィックス画像にレンダリングしてもよい。プリミティブのバッチをレンダリングするために、得られるグラフィックス画像は、複数のより小さい部分(たとえば、ピクセルのタイルまたはビン)に再分割されてもよく、グラフィックス処理パイプライン30は、グラフィックス画像の各部分を別個のレンダリングパスとしてレンダリングしてもよい。
図3は、ビニングレンダリングモード用のビンに分割されたフレームを示す概念図である。フレーム40は、ビン42などの複数のビンに分割されてもよい。典型的には、グラフィックスハードウェアは、データの少なくとも1つのビンを保持するのに十分なサイズである高速メモリ(たとえば、図2のグラフィックスメモリ14)を含む。フレームの特定の部分のための単一のレンダリングパスの一部として、グラフィックス処理パイプライン30は、フレームの宛先ピクセルの特定のサブセット(たとえば、宛先ピクセルの特定のビン)に対して、プリミティブのバッチのすべてまたはサブセットをレンダリングしてもよい。第1のビンに対して第1のレンダリングパスを実行した後、グラフィックス処理パイプライン30は第2のビンに対して第2のレンダリングパスを実行してもよく、以下同様である。グラフィックス処理パイプライン30は、あらゆるビンに関連付けられたプリミティブがレンダリングされるまで、徐々にビンを横断してもよい。
図4は、ビニングレンダリングモードで使用されるビンをより詳細に示す概念図である。ビン44、46、48および50は、複数のピクセル52を含むようにレンダリング/ラスタ化される。1つまたは複数のグラフィックスプリミティブは、各ビンにおいて可視であってもよい。たとえば、三角形A(Tri A)の部分は、ビン44とビン48の両方において可視である。三角形B(Tri B)の部分は、ビン44、ビン46、ビン48、およびビン50の各々において可視である。三角形C(Tri C)はビン46のみにおいて可視である。レンダリングパスの間、ビニングレンダリングモードの一例では、シーンはビンに分割され、ビン内にあるすべての三角形はレンダリングされる(これはソフトウェアビニングと呼ばれることがある)。ビニングレンダリングモードの別の例では、最終的なレンダリングされたシーンにおいてビン内のどの三角形が実際に可視であるかを決定するために、レンダリングする前に追加のステップがとられる(これはハードウェアビニングと呼ばれることがある)。たとえば、いくつかの三角形は1つまたは複数の他の三角形の後ろにあってもよく、最終的なレンダリングされたシーンにおいて可視ではなくなる。このようにして、可視ではない三角形は、そのビンについてレンダリングされる必要がない。
特定のレンダリングパスを実行している間、その特定のレンダリングパスに関連付けられたビンのピクセルデータは、グラフィックスメモリ14(ビンバッファと呼ばれることがある)に記憶されてもよい。レンダリングパスを実行した後、グラフィックス処理パイプライン30は、グラフィックスメモリ14のコンテンツをフレームバッファ15に転送してもよい。場合によっては、グラフィックス処理パイプライン30は、フレームバッファ15内のデータの一部分をグラフィックスメモリ14に記憶されたデータで上書きしてもよい。他の場合には、グラフィックス処理パイプライン30は、フレームバッファ15内のデータをグラフィックスメモリ14に記憶されたデータと合成するかまたは組み合わせてもよい。グラフィックスメモリ14のコンテンツをフレームバッファ15に転送した後、グラフィックス処理パイプライン30は、グラフィックスメモリ14をデフォルト値に初期化し、異なるビンに対して後続のレンダリングパスを開始してもよい。
図5は、「ソフトウェア」ビニングを使用するビニングレンダリングモードを使用してシーンをレンダリングするための例示的なコマンド構造を示す概念図である。レベル1間接バッファ(IB1)60は、グラフィックス処理パイプライン30の様々なステップを実行するようGPU12に命令するための一連の実行コマンドを含む。GPU12が受信するPM4コマンドパケットは、IB1 60へのポインタである。IB1 60内の各実行コマンドは、本質的には、レンダリングパイプラインの様々な態様のためのコマンドを含む1つまたは複数のレベル2間接バッファ(IB2)へのポインタである。このようにして、グラフィックスレンダリングパイプラインを実行するための2つ以上のレベル構造が確立される。GPU12は、IB1 60内の各実行コマンドを順次1ステップずつ実行してもよく、IB1 60内の各実行コマンドは、IB2に記憶されたコマンドの特定のスタックを指す。IB1およびIB2は、GPU12に搭載のメモリであってもよく、またはシステムメモリ10などのGPU12の外部にあるメモリであってもよい。
IB1 60内のプリアンブル実行コマンドは、GPU12によって実行可能であるプリアンブルコマンドを含むプリアンブルIB2 62を指す。たとえば、プリアンブルIB2 62は、GPU12のその静的状態を初期化し、GPU12の初期レンダリング状態を設定するコマンドを含んでもよい。GPUの静的状態は、特定のアプリケーションに基づいて変化しない設定を含む。一方、レンダリング状態は、特定のアプリケーション(たとえば、OpenGLアプリケーション対Direct Xアプリケーション)に基づいて変化する場合があるGPU設定を含む。プリアンブルIB2内のコマンドが完了した後、制御は次の実行コマンドを実行するためにIB1 60に戻る。
IB1 60内の次の実行コマンドは、利用されているレンダリングモードのためのレンダーパスを構成する。やはり、図5の例では、レンダリングモードはソフトウェアビニングを使用するビニングレンダリングモードである。次に、IB1内のロードビン実行コマンドは、BLT(ブロック転送(Block Transfer)、すなわち、データコピー)IB2 64内の非同期ブリッティングコマンドを指す。ブリッティングコマンドは、いくつかの例では、ラスタ演算子を使用して、いくつかのビットマップを1つに組み合わせてもよい。図5の例では、ブリッティングは、プリアンブルにおいて生成されたグラフィックスコマンドまたは状態を組み合わせるかまたは修正してもよい。次に、IB1 60内のロードビン実行コマンドは、ロードIB2 66内のコマンドを指す。ソフトウェアビニングの場合、特定のビンのためのデータはGMEM14にロードされる(Load 2 GMEM)。次いで、制御はIB1 60に戻され、レンダリングビン実行コマンドはレンダリングIB2内のコマンドを指す。レンダリングIB2 68は、一連の状態コマンドおよびロードされたビンにおいて三角形を描画するための描画コマンドからなる。各描画コマンドは、コマンドおよび/またはGPUハードウェアによって確立された(たとえば、ジオメトリ処理ステージ34、ラスタ化ステージ36、および/またはピクセル処理パイプライン38を含む)グラフィックス処理パイプライン30に従って三角形を描画するようGPU12に命令する。レンダリングIB2 68に示すように、描画コマンドの各々は、特定の三角形がビンにおいて実際に可視であるかどうかを決定するために可視性ストリームが使用されないことを示す。可視性ストリームは、「ハードウェア」ビニングを使用するビニングレンダリングモードで生成され、これについては図6を参照しながらより詳細に説明する。レンダリングIB2 68内の状態コマンドは、GPU12によって実行されるグラフィックス処理パイプラインの挙動に影響を及ぼす。たとえば、状態コマンドは、色、ポリゴンモード(たとえば、立体または線ではなく点)、ブレンディング(オン/オフ)、深度テスト(オン/オフ)、テクスチャリング(オン/オフ)、カリング、クリッピング、および他の論理演算を変更する場合がある。レンダリングIB2 68に示すように、状態コマンドは三角形ごと(またはプリミティブごと)に発行される場合がある。すなわち、コマンド"State Tri A"は三角形Aを描画するときにGPU12の挙動に影響を及ぼす場合があり、一方、"State Tri B1"コマンドおよび"State Tri B2"コマンドは三角形Bを描画するときにGPU12の挙動に影響を及ぼす場合がある。"State Tri B1"コマンドおよび"State Tri B2"コマンドは、複数の状態コマンドが三角形ごとに実行される場合があることを示すにすぎない。
すべてのコマンドがレンダリングIB2 68において実行された後(たとえば、すべての三角形が描画された後)、制御はIB1 60に戻る。記憶ビン実行コマンドは、GMEM14からのレンダリングされたビンをメモリ(たとえば、フレームバッファ15)に記憶するためのコマンドを含む記憶IB2 70へのポインタを含んでもよい。次いで、レンダーパス(たとえば、IB1 60に示すようなレンダーパスの構成からビンの記憶までの実行コマンド)が1つまたは複数のフレームについてビン72ごとに繰り返される。
図6は、「ハードウェア」ビニングを使用するビニングレンダリングモードを使用してシーンをレンダリングするための例示的なコマンド構造を示す概念図である。IB1 61内の実行コマンドは、「ビニング」パスに関するコマンドを除いて、図6のIB1 60の実行コマンドと類似している。「ビニング」パスは、ビン内の特定の三角形が最終的なレンダリングされたシーンにおいて実際に可視であるかどうかを示す可視性ストリームを生成するために使用される。たとえば、いくつかの三角形はシーン内の別の三角形の後ろにあってもよく、いくつかのシナリオでは可視ではなくなる(たとえば、前方の三角形が不透明であるときまたはブレンディングが使用されないとき)。ビン72をレンダリングする前に、IB1 61は、ビニングIB2 74内のコマンドを指すビニングパス実行コマンドを含んでもよい。ビニングIB2 74は、GPU12にグラフィックスパイプラインの簡略化されたバージョン(たとえば、レンダリングIB2 69の簡略化されたバージョン)を実行させるコマンドを含むが、三角形が最終的なレンダリングされたシーンにおいて可視であるかどうかを決定する深度テスト(Zテスト)に基づいてビン内の三角形ごとに可視性ストリームを更新するステップを追加する。
ビニングパスの目標は、現在のビンと交わる三角形を識別することである。したがって、三角形が特定のビンと交わるかどうかを識別するために、三角形の頂点の位置のみを決定する必要がある。ビニングパスは、頂点の位置に影響を及ぼす命令のみを含む簡略化された頂点シェーダを利用する。たとえば、三角形の頂点の位置に影響を及ぼさない色の命令、テクスチャ座標および他の命令は、ビニングパスに使用するための簡略化された頂点シェーダから除去されてもよい。ビニングパスはまた、各三角形のおおよその深度を決定するために、細かいラスタ化ではなく粗いラスタ化を使用する。粗いラスタ化は、細かいラスタ化よりも低い精度で(たとえば、より少ないビット数を使用して)深度値を計算する。三角形がビンにおいて可視であるかどうかを決定するためには、おおよその深度値のみが必要である。ピクセルシェーダはビニングパスにおいて使用されない。
次いで、ビニングパスは、三角形がビン内の他の三角形に対してビンにおいて可視であるかどうかを決定するために、粗い深度値に対して深度テストを利用する。この深度テストに基づいて、可視性ストリームが更新される。可視性ストリームは、レンダリングされたビン内の特定の三角形が可視であるかどうかを示すビットのストリングであってもよい(たとえば、1は三角形が可視であることを示し、0は三角形が可視ではないことを示す)。
レンダリングIB2 69内のコマンドは、図5のレンダリングIB 68のコマンドと類似しているが、可視性ストリーム用である。レンダリングIB2 69内の描画コマンド(たとえば、Draw Tri A、Draw Tri B、Draw Tri Cなど)は、特定の三角形を描画する必要があるかどうかを決定するために、ビニングパスによって生成された可視性ストリームを使用してもよい。たとえば、可視性ストリームによって可視ではないものとして示された三角形については描画がスキップされる場合がある。
ビニングレンダリングモードの場合のように、ビンごとにフレームをレンダリングすることとは対照的に、直接レンダリングは、グラフィックスパイプラインを通じた1つのパスにおいてフレーム全体をレンダリングする。直接レンダリングは、典型的には、グラフィックスメモリの量が制限されたビニングベースのアーキテクチャで実行されるとき、より遅いシステムメモリを利用する。
図7は、直接レンダリングモードを使用してシーンをレンダリングするための例示的なコマンド構造を示す概念図である。直接レンダリングモードのためのコマンドは、図5のソフトウェアビニングのためのコマンドと類似しているが、ビンごとにレンダリングする代わりに、フレーム全体が1つのパスにおいてレンダリングされる。たとえば、IB1 80内の実行コマンドはIB1 60内の実行コマンドと類似しているが、ビンをロードし、レンダリングし、記憶するのではなく、IB1 80内の実行コマンドは記憶フレームをレンダリングするそれぞれのIB2内のコマンドを指す。IB1 80の非同期ブリッティングコマンドは、BLT IB2 84内の非同期ブリッティングコマンドを指す。より詳細には、IB1 80内のコマンドは、プリアンブル、プリアンブル/復元、レンダーパスの構成、およびフレームのレンダリングを含んでもよい。IB1 80内のレンダリングフレーム実行コマンドは、GPU12にフレームにおいてプリミティブを描画させる命令を含むレンダリングIB2 88を指す。ソフトウェアビニングのように、直接レンダリングモードにおけるレンダリングは、ハードウェアビニングパスまたは可視性ストリームを利用しない。レンダリングIB2 88内の任意の描画コマンド(たとえば、Draw Tri A、Draw Tri B、Draw Tri C)は、レンダリングされた三角形を記憶するためにGMEMメモリを利用するであろう。
IB1 80内のプリアンブル実行コマンドは、GPU12の静的状態および初期レンダリング状態を確立するための命令を含むプリアンブルIB2 82を指す。これらのコマンドは、図6のプリアンブルIB2 62内のコマンドと同様に働くが、ビニングレンダリングモードではなく直接レンダリングモードのためのレンダリング状態をセットアップする。
図5〜図7に示すように、直接モードレンダリングとビニングモードレンダリングの両方はIB2を利用する。レンダリングパスまたはレンダリングループの間、GPU12は、レンダリングされるべきシーンについての情報に基づいて、ビニングおよび動的パント(punting)論理のためにレンダリングIB2にわたってループする。以前の技法では、GPU12以外のプロセッサ上で実行されるドライバ(たとえば、CPU6上で実行されるGPUドライバ7)は、フレームの一部分をレンダリングするときに直接レンダリングモードを利用するかまたはビニングレンダリングモードを利用するかを決定することを受け持っていた。シーンをレンダリングするために直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定するためにCPU6を利用するとき、このプロセスは非常にCPUバウンドである場合がある(すなわち、CPU6の比較的高い利用率を有する場合がある)。GPU12が直接モードレンダリングを利用するかまたはビニングモードレンダリングを利用するかを決定するとき、その結果は直接モードレンダリングとビニングモードレンダリングとの間の能力格差にも依存する場合がある。
本開示の技法によれば、GPU12は、たとえば、CPU6上で実行されるGPUドライバ7から、GPUコマンドパケットを受信してもよい。コマンドパケットは、GPU12がGPU12によってレンダリングされるべきフレームの一部分をレンダリングするために直接モードレンダリングまたはビニングモードレンダリングのいずれかを利用してもよいことを示す場合がある。加えて、コマンドパケットは、構成情報をカプセル化する場合がある。コマンドパケットはまた、直接モードレンダリングならびに/またはハードウェアおよび/もしくはビニングレンダリングのための、いくつかの例としてIB2 82、84、86、88、および90などの1つまたは複数のIB2を参照する(または指す)場合がある。
アプリケーション(たとえば、図2のソフトウェアアプリケーション24)がシーンのレンダリングを開始する前に、GPU12は、コマンドパケットに含まれるシーン情報に基づいて、レンダリングモードを決定してもよい(たとえば、ビニングレンダリングおよび直接レンダリングの間での決定)。GPU12はまた、GPU状態ヒューリスティックに基づいて、直接レンダリングを使用するかまたはビニングレンダリングを使用するかを決定してもよい。いくつかの技法では、GPU12はまた、以前のレンダリングパスからのデータに基づいて、レンダリングモードを決定してもよい。しかしながら、アプリケーションが新しいシーンをレンダリングする前にレンダリング技法を切り替える場合があるので、この技法は必ずしもレンダリングモードを決定するための最適な方法であるとは限らないことがある。したがって、この技法は、適切なレンダリングモードに切り替えるのに十分な新しいデータが蓄積されるまで、非効率的なレンダリングをもたらす場合がある。
加えて、過去のレンダリングに関するヒューリスティックデータは、現在のシーンが以前のシーンとは異なる場合、必ずしも最も最適なレンダリングモードを現在のシーンに提供するとは限らないことがある。たとえば、急速に変化するレンダリングモードを最適に使用するアプリケーションは、多くの誤った予測をもたらす場合がある。本開示の技法によれば、GPU12はGPU12の電力使用量を決定することができ、電力使用量に基づいてレンダリングモードを決定してもよい。本開示の技法による別の例では、GPU12は、GPU12の現在または将来の利用率を決定してもよく、GPU12の現在または将来の利用率に基づいて、フレームの少なくとも一部分をレンダリングするために使用すべきレンダリングモードを決定してもよい。本開示の技法によれば、GPU12は、本明細書では詳細に説明しない他のヒューリスティックを使用してもよく、GPU12は、CPU6からの介入または干渉なしに、本明細書で説明する任意のヒューリスティックを実行してもよい。
以下の技法は、任意のグラフィックスアプリケーションプログラムインターフェース(API)を使用するグラフィックス処理システムに適用可能であり、特に、ビニングレンダリングを利用するグラフィックスAPIに適している。そのようなAPIの例として、MicrosoftのDirectX9(DX9)、DX10、およびDX11、DX12、ならびにOpenGLおよびOpenGL ESなどのオープンソースグラフィックスAPI、OpenCLおよびDirectComputeなどのコンピューティングAPIが含まれる。
図8は、異なるレンダリングモードのコマンドバッファを示す概念図である。図8は、IB1 100、IB1 102、およびIB1 104を含む。IB1 100、102、および104の各々は、特定のレンダリングモードに対応するIB1バッファを含んでもよい。各IB1は、ハードウェアビニングのためのコマンドバッファに対応する場合がある。IB1 102はソフトウェアビニングのためのバッファに対応する場合があり、IB1は直接モードレンダリングのためのバッファに対応する場合がある。図8に示す技法によれば、異なるレンダリングモードを利用するために、GPU12は異なるIB1から読み取らなければならず、このことは、GPUドライバ7が複数のIB1をGPU12に転送することを必要とする場合がある。加えて、GPU12は複数のIB1を記憶することが必要とされる場合があり、このことは、GPU12の追加のメモリを消費する。本開示の技法は、図8に関して示す技法とは異なり、複数のIB1がGPU12に転送されることを必要としない。
図9は、本開示の技法による、直接レンダリングモードまたはビニングレンダリングモードを使用してシーンをレンダリングするための例示的なコマンド構造を示す概念図である。図9の例では、GPUドライバ7またはGPU12はIB1 120を生成または受信してもよい。IB1 120は、図5〜図7に関して説明する他のIB1と類似している。しかしながら、本開示の技法によれば、IB1 120は、PM4シーン記述子を含んでもよいコマンドパケットを含む。
図9の例では、IB1 120はコールビニングIB2 132、ならびにプリアンブルIB2 122、BLT IB2 124、およびレンダリングIB2 128を参照し(または指し)、IB2 130を記憶する。GPUコマンドパケット、たとえば、IB1 120のPM4シーン記述子は、GPU12が様々なヒューリスティックに基づいてハードウェアビニング、ソフトウェアビニング、または直接モードレンダリングを実行することができるように、上述のIB2をカプセル化する場合がある。IB1 120のPM4シーン記述子は、IB2 122、124、126、128、130、および132のメモリアドレスを参照することによって、これらのIB2を参照する。しかしながら、PM4シーン記述子は、必ずしもIB2 122、124、126、128、130、および132を含むとは限らない。GPU12は、実行順序、たとえば、図5〜図7に示すレンダリングモードの実行順序に類似した実行順序を生成するためにPM4シーン記述子が参照するIB2を使用してもよい。
コマンドパケットにシーン記述子を含め、GPU12がフレームの部分のためのレンダリングモードを決定することを可能にすることによって、本開示の技法は複数の利点を提供する。直接モードレンダリングとビニングモードレンダリングとの間で切り替えるための以前の技術は、複数のIB2の生成を必要とし、ドライバベースのヒューリスティックに基づいたビニングおよび動的パント論理のためのレンダリングIB2にわたるルーピングを必要とした(たとえば、「フック」ベースの関数呼出しではなく、グラフィックスAPIが提供する関数呼出しに依拠する)。生成、反復、およびドライバベースのヒューリスティック、ならびにフック論理はすべて、非常にCPUバウンドである(すなわち、かなりのCPUリソースを消費する)。
図9に示すPM4シーン記述子は、GPU12が異なるレンダリングモードを条件付きでトリガすることを可能にし、GPU12が余分のGPU状態固有のヒューリスティックをレンダリングモード決定機構に統合することを可能にする。一例では、CPU6は、PM4記述子にシーン記述子ヒューリスティックを含んでもよい。GPU12は、レンダリングモードを決定するために、PM4記述子に含まれるヒューリスティックを評価してもよい。別の例では、GPU12はGPUハードウェア状態分析に基づいてレンダリングモードを決定してもよく、GPUハードウェア状態分析は、いくつかの例では、電力状態、メモリ使用量、および/またはレンダリング負荷を含んでもよい。別の例では、ヒューリスティックは、GPU12のハードウェア能力を決定することを含んでもよく、その結果、異なるハードウェア能力を有するGPUは、シーンを異なるようにレンダリングしてもよい。加えて、決定されたヒューリスティックは、他のGPU性能クエリ、ならびに本明細書では明示的に開示しない実行時の状態決定を含んでもよい。本開示の技法はまた、パント(すなわち、いつビニングレンダリングモードから直接レンダリングモードに切り替えるかを決定すること)およびレンダリング論理をCPU6および/またはGPUドライバ7からGPU12に移動する。
加えて、GPUレンダリングモード決定をGPU12に移動することは、CPU6からのオーバーヘッドをなくし、メモリフットプリントを低減し、待ち行列に入れられたグラフィックスコマンドをサブミットするために使用されるIB1コマンド空間を節約する。加えて、GPUベースまたはGPU支援のヒューリスティックは、動的パントプロセスを用いて、CPU6および/またはGPUドライバ7からの対話なしに、GPU12上で実行されるかまたは埋め込まれることが可能である。本開示の技法はまた、CPU集約的である場合がある、多くの小さいレンダリングコールを一括処理することによって引き起こされる、いわゆる「スモールバッチ」問題に関連付けられた性能ペナルティを低減する。
図10は、本開示の一例による方法を示すフローチャートである。図10の方法は、コンピューティングデバイス2上に存在する、GPU12、および/もしくは任意の他のハードウェア、ファームウェア、ソフトウェア要素、またはそれらの組合せによって実行されてもよい。CPU6は、IB1などの、フレームをレンダリングするためのレンダリングコマンドを生成するように構成されてもよい。CPU6は、GPUコマンドパケットをGPU12に送信してもよい。様々な例では、コマンドパケットはPM4フォーマットのコマンドパケットを含んでもよい。
GPU12は、CPU6からコマンドパケットを受信してもよい。コマンドパケットは、GPU12がGPU12によってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示す場合がある(160)。GPU12は、受信されたコマンドパケット内の情報またはGPU12の状態のうちの少なくとも1つに基づいて、レンダリングされるべきフレームの一部分について直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定し(162)、決定された直接レンダリングモードまたはビニングレンダリングモードを使用してフレームの一部分をレンダリングしてもよい(164)。様々な例では、フレームの一部分をレンダリングするために、GPU12はレンダリングループを反復する、および/または動的パントを実行する場合がある。
様々な例では、直接レンダリングモードを利用するかまたはビニングレンダリングモードを利用するかを決定するために、GPU12は、レンダリングされるべきフレームの一部分について直接レンダリングモードを利用するかまたはビニングレンダリングモードを利用するかを決定するヒューリスティックを実行してもよい。いくつかの例では、GPU12は、GPU12の電力消費量に基づいて、直接レンダリングモードを利用するかまたはビニングレンダリングモードを利用するかを決定してもよい。GPU12はまた、GPU12のいくらかのリソース利用率に基づいて、直接レンダリングモードを利用するかまたはビニングレンダリングモードを利用するかを決定してもよい。
様々な例では、コマンドパケットは、間接バッファ(IB2)情報および/または構成ペアなどの、レンダリングされるべきフレームをレンダリングするために必要とされる情報をカプセル化するシーン記述子パケットを含んでもよい。シーン記述子のカプセル化された情報は、フレームが属するシーンについての解像度情報をさらに含んでもよい。
いくつかの例では、GPU状態は、GPUの電力消費量を含んでもよく、GPU12は、GPUの電力消費量がしきい値電力消費値を超えるときに、フレームの一部分をレンダリングするためにビニングレンダリングモードを使用するとさらに決定してもよい。GPU状態はまた、GPUの利用負荷を含んでもよく、GPU12は、GPUの利用負荷が利用値を超えるときに、ビニングレンダリングモードを使用すると決定してもよい。GPU状態はまた、GPUのメモリ使用量を含んでもよい。
様々な例では、受信されたコマンドパケットは、レンダリングされるべきフレームをレンダリングするために必要とされる情報をカプセル化するシーン記述子パケットを含んでもよい。シーン記述子のカプセル化された情報は、いくつかの例では、間接バッファ情報および構成ペアを含んでもよい。シーン記述子のカプセル化された情報はまた、レンダリングされるべきフレームについての解像度情報を含んでもよい。
様々な例では、受信されたコマンドパケット内の情報は、レンダリングされるべきフレームの一部分におけるジオメトリの量を含んでもよい。受信されたコマンドパケットはまた、GPUによってレンダリングされるべきフレームをレンダリングするために必要とされるすべてのビンを含んでもよい。いくつかの例では、GPU12は、GPUによって以前にレンダリングされたフレームからのレンダリング情報に基づいて、直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定してもよい。
いくつかの例では、GPU12は、フレームをレンダリングするときに生じるオーバードローの量を決定するようにさらに構成されてもよい。GPU12は、生じるオーバードローの量に基づいて、直接レンダリングモードを使用するかまたはビニングレンダリングモードを使用するかを決定してもよい。
1つまたは複数の例では、上記で説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装されてもよい。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読媒体を備える製造品上の1つまたは複数の命令またはコードとして記憶されてもよい。コンピュータ可読媒体は、コンピュータデータ記憶媒体を含んでもよい。データ記憶媒体は、本開示で説明する技法を実装するための命令、コードおよび/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスすることができる任意の利用可能な媒体であってもよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用することができ、コンピュータによってアクセスすることができる、任意の他の媒体を備えることができる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生するが、ディスク(disc)はレーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
コードは、1つまたは複数のDSP、汎用マイクロプロセッサ、ASIC、FPGA、または他の等価の集積論理回路もしくはディスクリート論理回路などの、1つまたは複数のプロセッサによって実行されてもよい。加えて、いくつかの態様では、本明細書で説明する機能は、専用のハードウェアモジュールおよび/またはソフトウェアモジュール内で提供されてもよい。また、本技法は、1つまたは複数の回路または論理要素において完全に実装することができる。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装されてもよい。開示する技法を実行するように構成されるデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットについて本開示で説明したが、これらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニットにおいて組み合わされてもよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、上記で説明したような1つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてもよい。
様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
2 コンピューティングデバイス
4 ユーザ入力インターフェース
6 中央処理ユニット、CPU
7 GPUドライバ
8 メモリコントローラ
10 システムメモリ
12 グラフィックス処理ユニット、GPU
14 グラフィックスメモリ
15 フレームバッファ
16 ディスプレイインターフェース
18 ディスプレイ
20 バス
22 バス
24 ソフトウェアアプリケーション
26 グラフィックスAPI
30 グラフィックス処理パイプライン
32 コマンドエンジン
34 ジオメトリ処理ステージ
36 ラスタ化ステージ
38 ピクセル処理パイプライン
40 フレーム
42 ビン
44 ビン
46 ビン
48 ビン
50 ビン
52 ピクセル
60 レベル1間接バッファ、IB1
62 プリアンブルIB2
64 BLT IB2
66 ロードIB2
68 レンダリングIB2
69 レンダリングIB2
70 記憶IB2
72 ビン
74 ビニングIB2
80 IB1
82 プリアンブルIB2
84 BLT IB2、IB2
86 IB2
88 レンダリングIB2、IB2
90 IB2
100 IB1
102 IB1
104 IB1
120 IB1
122 プリアンブルIB2、IB2
124 IB2
126 IB2
128 IB2
130 IB2
132 IB2

Claims (30)

  1. グラフィックス処理の方法であって、
    グラフィックス処理ユニット(GPU)によって、前記GPUが前記GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信するステップと、
    前記GPUによって、前記受信されたコマンドパケット内の情報または前記GPUの状態のうちの少なくとも1つに基づいて、前記GPUによってレンダリングされるべき前記フレームの前記一部分について前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定するステップと、
    前記GPUによって、前記決定された直接レンダリングモードまたは前記ビニングレンダリングモードを使用して前記フレームの前記一部分をレンダリングするステップと
    を含む、方法。
  2. 前記GPU状態が、前記GPUの電力消費量を含む、請求項1に記載の方法。
  3. 前記GPUの前記電力消費量がしきい値電力消費値を超えるときに、前記フレームの前記一部分をレンダリングするために前記ビニングレンダリングモードを使用すると決定するステップ
    をさらに含む、請求項2に記載の方法。
  4. 前記GPU状態が、前記GPUの利用負荷を含む、請求項1に記載の方法。
  5. 前記GPUの前記利用負荷が利用値を超えるときに、前記ビニングレンダリングモードを使用すると決定するステップをさらに含む、請求項4に記載の方法。
  6. 前記GPU状態が、前記GPUのメモリ使用量を含む、請求項1に記載の方法。
  7. 前記受信されたコマンドパケットが、レンダリングされるべき前記フレームをレンダリングするために必要とされる情報をカプセル化するシーン記述子パケットを含む、請求項1に記載の方法。
  8. 前記シーン記述子の前記カプセル化された情報が、間接バッファ情報および構成ペアを含む、請求項7に記載の方法。
  9. 前記シーン記述子の前記カプセル化された情報が、レンダリングされるべき前記フレームについての解像度情報を含む、請求項7に記載の方法。
  10. 前記受信されたコマンドパケット内の前記情報が、レンダリングされるべき前記フレームの前記一部分におけるジオメトリの量を含む、請求項1に記載の方法。
  11. 前記受信されたコマンドパケットが、前記GPUによってレンダリングされるべき前記フレームをレンダリングするために必要とされるすべてのビンを含む、請求項1に記載の方法。
  12. 前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定するステップが、前記GPUによって以前にレンダリングされたフレームからのレンダリング情報に基づく、請求項1に記載の方法。
  13. 前記方法が、
    前記フレームをレンダリングするときに生じるオーバードローの量を決定するステップ
    をさらに含み、
    前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定するステップが、生じる前記オーバードローの量に基づく、
    請求項1に記載の方法。
  14. グラフィックス処理ユニット(GPU)を備えるデバイスであって、前記GPUが、
    メモリと、
    少なくとも1つのプロセッサであって、
    前記GPUが前記GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信し、
    前記受信されたコマンドパケット内の情報または前記GPUの状態のうちの少なくとも1つに基づいて、前記GPUによってレンダリングされるべき前記フレームの前記一部分について前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定し、
    前記決定された直接レンダリングモードまたは前記ビニングレンダリングモードを使用して前記フレームの前記一部分をレンダリングする
    ように構成される少なくとも1つのプロセッサと
    をさらに備える、デバイス。
  15. 前記GPU状態が、前記GPUの電力消費量を含む、請求項14に記載のデバイス。
  16. 前記少なくとも1つのプロセッサが、
    前記GPUの前記電力消費量がしきい値電力消費値を超えるときに、前記フレームの前記一部分をレンダリングするために前記ビニングレンダリングモードを使用すると決定する
    ようにさらに構成される、請求項15に記載のデバイス。
  17. 前記GPU状態が、前記GPUの利用負荷を含む、請求項14に記載のデバイス。
  18. 前記少なくとも1つのプロセッサが、
    前記GPUの前記利用負荷が利用値を超えるときに、前記ビニングレンダリングモードを使用すると決定する
    ようにさらに構成される、請求項17に記載のデバイス。
  19. 前記GPU状態が、前記GPUのメモリ使用量を含む、請求項14に記載のデバイス。
  20. 前記受信されたコマンドパケットが、レンダリングされるべき前記フレームをレンダリングするために必要とされる情報をカプセル化するシーン記述子パケットを含む、請求項14に記載のデバイス。
  21. 前記シーン記述子の前記カプセル化された情報が、間接バッファ情報および構成ペアを含む、請求項20に記載のデバイス。
  22. 前記シーン記述子の前記カプセル化された情報が、レンダリングされるべき前記フレームについての解像度情報を含む、請求項20に記載のデバイス。
  23. 前記受信されたコマンドパケット内の前記情報が、レンダリングされるべき前記フレームの前記一部分におけるジオメトリの量を含む、請求項14に記載のデバイス。
  24. 前記受信されたコマンドパケットが、前記GPUによってレンダリングされるべき前記フレームをレンダリングするために必要とされるすべてのビンを含む、請求項14に記載のデバイス。
  25. 前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定することが、前記GPUによって以前にレンダリングされたフレームからのレンダリング情報に基づく、請求項14に記載のデバイス。
  26. 前記少なくとも1つのプロセッサが、
    前記フレームをレンダリングするときに生じるオーバードローの量を決定するようにさらに構成され、前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定することが、生じる前記オーバードローの量に基づく、
    請求項14に記載のデバイス。
  27. グラフィックス処理ユニット(GPU)を備えるデバイスであって、前記GPUが、
    前記GPUが前記GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信するための手段と、
    前記受信されたコマンドパケット内の情報または前記GPUの状態のうちの少なくとも1つに基づいて、前記GPUによってレンダリングされるべき前記フレームの前記一部分について前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定するための手段と、
    前記決定された直接レンダリングモードまたは前記ビニングレンダリングモードを使用して前記フレームの前記一部分をレンダリングするための手段と
    をさらに備える、デバイス。
  28. 前記GPU状態が、前記GPUの電力消費量を含み、前記レンダリングモードを前記決定するための手段が、
    前記GPUの前記電力消費量がしきい値電力消費値を超えるときに、前記フレームの前記一部分をレンダリングするために前記ビニングレンダリングモードを使用すると決定するための手段
    をさらに備える、請求項27に記載のデバイス。
  29. 前記GPU状態が、前記GPUの利用負荷を含み、前記レンダリングモードを前記決定するための手段が、
    前記GPUの前記利用負荷が利用値を超えるときに、前記ビニングレンダリングモードを使用すると決定するための手段
    をさらに備える、請求項27に記載のデバイス。
  30. 実行されると、少なくとも1つのプロセッサに、
    GPUが前記GPUによってレンダリングされるべきフレームの一部分について直接レンダリングモードまたはビニングレンダリングモードから選択してもよいことを示すGPUコマンドパケットを受信させ、
    前記受信されたコマンドパケット内の情報または前記GPUの状態のうちの少なくとも1つに基づいて、前記GPUによってレンダリングされるべき前記フレームの前記一部分について前記直接レンダリングモードを使用するかまたは前記ビニングレンダリングモードを使用するかを決定させ、
    前記決定された直接レンダリングモードまたは前記ビニングレンダリングモードを使用して前記フレームの前記一部分をレンダリングさせる
    命令を記憶する、非一時的コンピュータ可読記憶媒体。
JP2016562910A 2014-04-21 2015-04-21 グラフィックス処理におけるレンダーターゲットに基づいたフレックスレンダリング Active JP6541685B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461982147P 2014-04-21 2014-04-21
US61/982,147 2014-04-21
US14/691,358 2015-04-20
US14/691,358 US9928565B2 (en) 2014-04-21 2015-04-20 Flex rendering based on a render target in graphics processing
PCT/US2015/026910 WO2015164397A1 (en) 2014-04-21 2015-04-21 Flex rendering based on a render target in graphics processing

Publications (3)

Publication Number Publication Date
JP2017516207A true JP2017516207A (ja) 2017-06-15
JP2017516207A5 JP2017516207A5 (ja) 2018-05-31
JP6541685B2 JP6541685B2 (ja) 2019-07-10

Family

ID=54322423

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016562910A Active JP6541685B2 (ja) 2014-04-21 2015-04-21 グラフィックス処理におけるレンダーターゲットに基づいたフレックスレンダリング

Country Status (7)

Country Link
US (2) US9928565B2 (ja)
EP (1) EP3134864B1 (ja)
JP (1) JP6541685B2 (ja)
KR (1) KR20160148594A (ja)
CN (1) CN106233326B (ja)
BR (1) BR112016024424A2 (ja)
WO (1) WO2015164397A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021517997A (ja) * 2018-04-10 2021-07-29 グーグル エルエルシーＧｏｏｇｌｅ ＬＬＣ ゲームレンダリングにおけるメモリ管理

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9928565B2 (en) 2014-04-21 2018-03-27 Qualcomm Incorporated Flex rendering based on a render target in graphics processing
US9842428B2 (en) * 2014-06-27 2017-12-12 Samsung Electronics Co., Ltd. Dynamically optimized deferred rendering pipeline
DE102015115605A1 (de) * 2014-09-16 2016-03-17 Jeffrey A. Bolz Techniken zur Weiterleitung von Abhängigkeiten in einer API
US10535114B2 (en) * 2015-08-18 2020-01-14 Nvidia Corporation Controlling multi-pass rendering sequences in a cache tiling architecture
US10456672B2 (en) 2016-05-19 2019-10-29 Google Llc Methods and systems for facilitating participation in a game session
JP6880174B2 (ja) * 2016-08-22 2021-06-02 マジック リープ， インコーポレイテッドＭａｇｉｃ Ｌｅａｐ，Ｉｎｃ． 仮想現実、拡張現実、および複合現実システムおよび方法
KR20180038793A (ko) * 2016-10-07 2018-04-17 삼성전자주식회사 영상 데이터 처리 방법 및 장치
CN106528303A (zh) * 2016-10-20 2017-03-22 武汉斗鱼网络科技有限公司 一种基于gpu纹理共享来获取d3d12游戏源图像的方法及系统
US10482648B2 (en) 2016-12-13 2019-11-19 Qualcomm Incorporated Scene-based foveated rendering of graphics content
EP4336800A3 (en) 2017-10-10 2024-05-29 Google LLC Distributed sample-based game profiling with game metadata and metrics and gaming api platform supporting third-party content
CN110058926B (zh) * 2018-01-18 2023-03-14 伊姆西Ip控股有限责任公司 用于处理gpu任务的方法、设备和计算机可读介质
EP3700640B1 (en) 2018-03-22 2021-05-26 Google LLC Methods and systems for rendering and encoding content for online interactive gaming sessions
US11077364B2 (en) 2018-04-02 2021-08-03 Google Llc Resolution-based scaling of real-time interactive graphics
KR102694451B1 (ko) 2018-04-02 2024-08-13 구글 엘엘씨 대화형 클라우드 게임용 방법, 디바이스 및 시스템
CA3091602C (en) 2018-05-31 2024-05-28 Huawei Technologies Co., Ltd. Apparatus and method for command stream optimization and enhancement
US11037271B2 (en) * 2018-08-07 2021-06-15 Qualcomm Incorporated Dynamic rendering for foveated rendering
CN109242756B (zh) 2018-09-07 2023-04-04 格兰菲智能科技有限公司 计算机系统、图形处理单元及其图形处理方法
CN109325899B (zh) * 2018-09-07 2023-04-04 格兰菲智能科技有限公司 计算机系统、图形处理单元及其图形处理方法
CN111124656B (zh) * 2018-10-31 2023-09-15 伊姆西Ip控股有限责任公司 用于向专用计算资源分配任务的方法、设备和计算机可读存储介质
EP3807766B1 (en) 2018-11-16 2021-10-27 Google LLC Shadow tracking of real-time interactive simulations for complex system analysis
CN109636709B (zh) * 2018-11-28 2020-12-08 华中科技大学 一种适用于异构平台的图计算方法
CN111105477B (zh) * 2019-11-25 2023-04-28 航天科技控股集团股份有限公司 全液晶仪表2d虚拟指针绘制方法
CN111145074B (zh) * 2019-11-30 2023-11-28 航天科技控股集团股份有限公司 全液晶仪表图像渲染方法
US11972518B2 (en) * 2020-01-20 2024-04-30 Advanced Micro Devices, Inc. Hybrid binning
US12112394B2 (en) * 2020-02-03 2024-10-08 Sony Interactive Entertainment Inc. System and method for efficient multi-GPU rendering of geometry by pretesting against screen regions using configurable shaders
US20210287418A1 (en) * 2020-03-10 2021-09-16 Advanced Micro Devices, Inc. Graphics processing unit render mode selection system
US12086899B2 (en) 2020-08-07 2024-09-10 Advanced Micro Devices, Inc. Graphics processing unit with selective two-level binning
US20220156874A1 (en) * 2020-11-13 2022-05-19 Advanced Micro Devices, Inc. Processing system with selective priority-based two-level binning
WO2022104583A1 (en) * 2020-11-18 2022-05-27 Qualcomm Incorporated Methods and apparatus for selection of rendering modes
US12008675B2 (en) * 2021-03-18 2024-06-11 Samsung Electronics Co., Ltd. Method and apparatus for isolating 3D draw calls for selective upscaling
EP4354399A4 (en) * 2021-06-22 2024-08-21 Huawei Tech Co Ltd METHOD AND DEVICE FOR GRAPHIC DISPLAY
US11983809B2 (en) * 2022-05-23 2024-05-14 Rockwell Collins, Inc. A-Buffer dynamic allocation
CN118429173A (zh) * 2023-02-01 2024-08-02 华为技术有限公司 渲染方法、装置、电子设备以及计算机可读存储介质
CN116894906A (zh) * 2023-09-11 2023-10-17 瀚博半导体(上海)有限公司 图形渲染方法和处理器硬件架构

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5777621A (en) * 1994-12-22 1998-07-07 Apple Computer, Inc. Quality control mechanism for three-dimensional graphics rendering
US6075546A (en) 1997-11-10 2000-06-13 Silicon Grahphics, Inc. Packetized command interface to graphics processor
US6466217B1 (en) 1999-12-22 2002-10-15 Intel Corporation Method and apparatus for ensuring backward compatibility in a bucket rendering system
EP1407349A4 (en) * 2001-07-06 2004-10-13 Genie Australia Pty Ltd E SOFTWARE APPLICATION EXECUTION METHOD AND SYSTEM
US7289119B2 (en) 2005-05-10 2007-10-30 Sony Computer Entertainment Inc. Statistical rendering acceleration
US8786628B2 (en) * 2007-09-14 2014-07-22 Microsoft Corporation Rendering electronic chart objects
US8675002B1 (en) * 2010-06-09 2014-03-18 Ati Technologies, Ulc Efficient approach for a unified command buffer
US8988441B2 (en) * 2011-02-10 2015-03-24 Edward A. Hutchins Reconfigurable 3D graphics processor
US8982136B2 (en) * 2011-05-16 2015-03-17 Qualcomm Incorporated Rendering mode selection in graphics processing units
US8830246B2 (en) 2011-11-30 2014-09-09 Qualcomm Incorporated Switching between direct rendering and binning in graphics processing
US9928565B2 (en) 2014-04-21 2018-03-27 Qualcomm Incorporated Flex rendering based on a render target in graphics processing

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021517997A (ja) * 2018-04-10 2021-07-29 グーグル エルエルシーＧｏｏｇｌｅ ＬＬＣ ゲームレンダリングにおけるメモリ管理
JP7073494B2 (ja) 2018-04-10 2022-05-23 グーグル エルエルシー ゲームレンダリングにおけるメモリ管理

Also Published As

Publication number Publication date
CN106233326B (zh) 2019-11-12
US10282813B2 (en) 2019-05-07
EP3134864B1 (en) 2021-01-06
BR112016024424A2 (pt) 2017-08-15
US20180165788A1 (en) 2018-06-14
EP3134864A1 (en) 2017-03-01
JP6541685B2 (ja) 2019-07-10
US9928565B2 (en) 2018-03-27
WO2015164397A1 (en) 2015-10-29
CN106233326A (zh) 2016-12-14
US20150302546A1 (en) 2015-10-22
KR20160148594A (ko) 2016-12-26

Similar Documents

Publication Publication Date Title
US10282813B2 (en) Flex rendering based on a render target in graphics processing
JP5847960B2 (ja) グラフィックス処理における直接レンダリングとビニングとの間の切り換え
US9836810B2 (en) Optimized multi-pass rendering on tiled base architectures
JP6294565B2 (ja) グラフィックス処理において使用するためのシェーダプログラム実行技法
US9489710B2 (en) Hybrid rendering in graphics processing
JP6042584B2 (ja) 加えられたインライン動作とともに、ビン毎の可視情報に基づくレンダリングコマンドの条件付き実行
US10694197B2 (en) Composition based dynamic panel mode switch
US10416808B2 (en) Input event based dynamic panel mode switch

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180405

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180405

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190423

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190513

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190611

R150 Certificate of patent or registration of utility model

Ref document number: 6541685

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250