(57)【要約】複数のディスプレイ・チャネルの間で共用されることが可能なグラフィックス・システムが、フレーム・バッファと、２つのアービタと、ピクセル・バッファと、いくつかの表示出力待ち行列とを含む。第１のアービタは、フレーム・バッファから表示情報を求めるディスプレイ・チャネルの要求の間で仲裁を行い、選択された要求をフレーム・バッファに転送する。フレーム・バッファは、転送された要求を受け取ったことに応答して表示情報を出力し、この表示情報に対応するピクセルが、ピクセル・バッファの中に記憶される。各ディスプレイ・チャネルは、ディスプレイにデータを提供し、ピクセル・バッファからピクセルを求める要求を生成する対応する表示出力待ち行列を有する。ピクセル要求アービタが、表示出力待ち行列によって生成されたピクセル要求を受け取り、そのピクセル要求の１つを選択し、選択された要求をピクセル・バッファに転送する。これに応答して、ピクセル・バッファは、選択されたピクセル要求を生成した表示出力待ち行列にピクセルを出力する。
2004536388.tif 000002
【特許請求の範囲】
【請求項１】
選択された第１の要求を受け取ったことに応答して表示情報を出力するように構成されたフレーム・バッファと、
複数のディスプレイ・チャネルに対応する複数の第１の要求の間で仲裁を行い、前記第１の要求のなかの選択された１つを前記フレーム・バッファに転送するように構成された第１のアービタと、
ピクセルを記憶し、前記フレーム・バッファによって出力された前記表示情報に対応するピクセルを受け取り、選択されたピクセル要求を受け取ったことに応答して１つまたは複数のピクセルを出力するように構成されたピクセル・バッファと、
複数のピクセル要求を受け取り、前記ピクセル要求のなかの選択された１つを前記ピクセル・バッファに転送するように構成されたピクセル要求アービタと、
表示データをディスプレイに提供し、ピクセル要求を生成するようにそれぞれが構成され、前記ピクセル・バッファによって出力されたピクセルを受け取るように構成された複数の表示出力待ち行列とを含むグラフィックス・システム。
【請求項２】
前記フレーム・バッファから前記表示情報を受け取り、前記表示情報をスクランブル解除するように構成されたスクランブル解除器をさらに含む請求項１に記載のグラフィックス・システム。
【請求項３】
前記スクランブル解除器が、複数のピクセルをラスタ順に配列し、前記ピクセルを前記ピクセル・バッファに出力するようにさらに構成された請求項２に記載のグラフィックス・システム。
【請求項４】
ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、１つまたは複数の索引付き色マップ（ＣＬＵＴＳ）、および現在のカーソル位置のうち少なくとも１つを使用して、前記ピクセル・バッファによって出力された前記１つまたは複数のピクセルを処理するように構成されたピクセル処理パイプラインをさらに含む請求項１に記載のグラフィックス・システム。
【請求項５】
前記表示情報が、ピクセルまたはサンプルを含む請求項１に記載のグラフィックス・システム。
【請求項６】
前記ピクセル・バッファが各チャネルに関するピクセル待ち行列を含み、前記第１のアービタが、前記ピクセル・バッファ内の各チャネルのピクセル待ち行列内のピクセルのレベルを比較することによって前記第１の要求のうち前記選択された１つを選択するようにさらに構成され、第１のチャネルのピクセル待ち行列レベルがしきい値を下回っており、かつ第２のチャネルのピクセル待ち行列レベルが前記しきい値を上回っている場合、前記第１のチャネルの要求が前記選択される第１の要求である請求項１に記載のグラフィックス・システム。
【請求項７】
前記第１のチャネルのピクセル待ち行列レベルも、前記第２のチャネルのピクセル待ち行列レベルも前記しきい値を下回っていない場合、いずれのチャネルの要求も選択されない請求項６に記載のグラフィックス・システム。
【請求項８】
（ａ）前記第１のチャネルのピクセル待ち行列レベルと前記第２のチャネルのピクセル待ち行列レベルがともに前記しきい値を下回っており、かつ（ｂ）前記第１のチャネルの不足分が前記第２のチャネルの不足分より大きい場合、前記第１のチャネルの要求が前記選択される要求である請求項６に記載のグラフィックス・システム。
【請求項９】
前記第１のアービタは、どのディスプレイ・チャネルが前記選択された第１の要求に対応するかについて前記フレーム・バッファに指示するようにさらに構成された請求項１に記載のグラフィックス・システム。
【請求項１０】
前記ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに関する第１の要求をアサートするようにそれぞれが構成された複数の第１のリクエスタをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１１】
それぞれの第１のリクエスタが、対応するディスプレイ・チャネルに関する第１の垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に第１の要求をアサートするように構成された請求項１０に記載のグラフィックス・システム。
【請求項１２】
前記ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに関してピクセル要求をアサートするようにそれぞれが構成された複数のピクセル・リクエスタをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１３】
各ピクセル・リクエスタが、対応するディスプレイ・チャネルに関する表示出力待ち行列のレベルがあるしきい値を下回って低下したときにピクセル要求をアサートするように構成された請求項１２に記載のグラフィックス・システム。
【請求項１４】
前記ピクセル要求アービタが、どのチャネルが最も長い間サービスを受けていないかを判定し、そのチャネルに対するデータが前記ピクセル・バッファ内に用意されている場合、そのチャネルのピクセル要求を選択することによって前記ピクセル要求の前記選択された１つを選択するようにさらに構成されている請求項１に記載のグラフィックス・システム。
【請求項１５】
前記ピクセル要求アービタが、前記最も長い間サービスを受けていないチャネルに対するデータが前記ピクセル・バッファ内に用意されておらず、次に長い間サービスを受けていないチャネルに対するデータが前記ピクセル・バッファ内に用意されている場合、前記次に長い間サービスを受けていないチャネルに対応するピクセル要求の１つを選択するようにさらに構成された請求項１４に記載のグラフィックス・システム。
【請求項１６】
第１の表示出力待ち行列からピクセルを受け取り、アナログ表示データをＣＲＴモニタを含む第１のディスプレイに出力するように構成されたＤＡＣをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１７】
第１のディスプレイ・チャネルが、表示データをデジタル・ディスプレイに出力する請求項１に記載のグラフィックス・システム。
【請求項１８】
第１のディスプレイ・チャネルが、表示データをガスプラズマ・ディスプレイに出力する請求項１に記載のグラフィックス・システム。
【請求項１９】
複数のディスプレイ・チャネルの間でグラフィックス・システム・リソースを共用する方法であって、
前記ディスプレイ・チャネルの１つにそれぞれが対応する表示情報を求める複数の第１の要求をアサートすること、
前記第１の要求のうち１つを選択し、前記選択された第１の要求を転送することによって前記第１の要求の間で仲裁を行うこと、
前記選択された第１の要求を前記転送することに応答して表示情報を出力すること、
前記ディスプレイ・チャネルの１つにそれぞれが対応するピクセルを求める複数の第２の要求をアサートすること、
前記第２の要求のうち１つを選択し、前記選択された第２の要求を転送することによって前記第２の要求の間で仲裁を行うこと、および
前記選択された第２の要求を前記転送することに応答して１つまたは複数のピクセルを出力することを含む方法。
【請求項２０】
複数の第１の要求をアサートすることが、対応するディスプレイ・チャネルが表示情報を必要とするかどうかを判定し、必要とする場合、そのディスプレイ・チャネルを求める第１の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２１】
複数の第１の要求を前記アサートすることが、対応するディスプレイ・チャネルに関する第１の垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に前記対応するディスプレイ・チャネルに関する第１の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２２】
複数の第２の要求を前記アサートすることが、対応するディスプレイ・チャネルの表示出力待ち行列内のピクセルのレベルが第１のしきい値を下回って低下したことに応答して前記対応するディスプレイ・チャネルに関する１つまたは複数の第２の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２３】
前記表示情報を前記出力することの後に前記表示情報をスクランブル解除することをさらに含む請求項１９に記載の方法。
【請求項２４】
前記ピクセルを前記出力することの後に前記ピクセルを処理することをさらに含み、前記処理することが、ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、１つまたは複数の索引付き色マップ（ＣＬＵＴＳ）、および現在のカーソル位置のうち１つまたは複数を使用することを含む請求項１９に記載の方法。
【請求項２５】
表示データをディスプレイに出力することをさらに含み、前記表示データが前記ディスプレイ向けにフォーマットされ、前記出力することによって出力された１つまたは複数のピクセルに対応する請求項１９に記載の方法。
【請求項２６】
ＤＡＣを使用して前記１つまたは複数のピクセルをアナログ信号に変換することをさらに含み、前記ディスプレイがＣＲＴを含む請求項２５に記載の方法。
【請求項２７】
前記第１の要求のうち１つを前記選択することが、
１つだけの第１の要求がアサートされた場合、ピクセル・バッファ内でその第１の要求の対応するディスプレイ・チャネルのブロック待ち行列内のデータのレベルがしきい値を下回っている場合、前記第１の要求を選択すること、および
複数の第１の要求がアサートされた場合、前記第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルの複数が前記しきい値を下回っているかどうかを判定し、１つだけの第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルが前記しきい値を下回っている場合、その第１の要求を選択し、あるいは、複数の第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルが前記しきい値を下回っている場合、そのチャネルのブロック待ち行列のデータ・レベルと前記しきい値の間の不足分が最大であるディスプレイ・チャネルに対応する第１の要求を選択することを含む請求項１９に記載の方法。
【請求項２８】
前記第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルのいずれも前記しきい値を下回っていない場合、前記選択することが前記第１の要求のいずれも選択しないことを含む請求項２７に記載の方法。
【請求項２９】
前記第２の要求のうち１つを前記選択することが、
１つだけの第２の要求がアサートされた場合、その第２の要求の対応するディスプレイ・チャネルに対してピクセル・バッファ内にピクセルが用意されている場合、その要求を選択すること、および
複数の第２の要求がアサートされた場合、最も長い間サービスを受けていないディスプレイ・チャネルに対して前記ピクセル・バッファ内にピクセルが用意されている場合、前記最も長い間サービスを受けていないディスプレイ・チャネルに対応する第２の要求を選択することを含む請求項１９に記載の方法。
【請求項３０】
前記最も長い間サービスを受けていないディスプレイ・チャネルに対してピクセルが用意されていない場合、前記第２の要求のうち１つを前記選択することが、前記ピクセル・バッファ内に用意されているピクセルを有する次に長い間サービスを受けていないディスプレイ・チャネルに対応する第２の要求を選択することを含む請求項２９に記載の方法。
【請求項３１】
複数のディスプレイ・チャネルのそれぞれ１つにそれぞれが対応し、前記対応するディスプレイ・チャネルの実際の表示情報のニーズの指示に応答して要求を出力するようにそれぞれが構成された複数の表示情報リクエスタと、
表示情報を記憶し、ディスプレイ・チャネルの１つに対応する選択された要求を受け取ったことに応答して前記複数のディスプレイ・チャネルの前記１つに前記表示情報の一部分を出力するように構成された表示情報バッファと、
前記表示情報リクエスタから要求を受け取り、前記要求の１つを選択し、前記要求のうち前記選択された１つを前記表示情報バッファに転送するように構成された仲裁論理とを含むグラフィックス・システム。
【請求項３２】
前記表示情報バッファが、フレーム・バッファを含み、前記表示情報バッファが、前記選択された要求を受け取ったことに応答して表示情報のバーストを出力するようにさらに構成された請求項３１に記載のグラフィックス・システム。
【請求項３３】
前記表示情報バッファが、ピクセル・バッファを含み、前記表示情報バッファが、前記選択された要求を受け取ったことに応答してピクセルのペアを出力するようにさらに構成された請求項３１に記載のグラフィックス・システム。
【請求項３４】
前記仲裁論理が、各チャネルの表示情報待ち行列内の表示情報のレベルに基づいて前記要求のうち１つを選択するように構成され、第１のチャネルの表示情報待ち行列のレベルがしきい値を下回り、かつ第２のチャネルの表示情報待ち行列のレベルが前記しきい値を上回っている場合、前記仲裁論理が、前記第１のチャネルの要求を選択するように構成された請求項３１に記載のグラフィックス・システム。
【請求項３５】
各表示情報リクエスタが、前記対応するディスプレイ・チャネルの表示情報待ち行列内のデータのレベルがあるしきい値を下回って低下した場合、前記要求を出力するようにさらに構成された請求項３１に記載のグラフィックス・システム。
【請求項３６】
各表示情報リクエスタが、垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に前記要求を出力するように構成された請求項３１に記載のグラフィックス・システム。
【請求項３７】
複数のディスプレイ・チャネルのそれぞれ１つにそれぞれが対応し、それぞれのディスプレイ・チャネルの垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に少なくとも１つの要求を出力するようにそれぞれが構成された複数の表示情報リクエスタと、
表示情報を記憶し、ディスプレイ・チャネルの１つに対応する選択された要求を受け取ったことに応答して前記複数のディスプレイ・チャネルの前記１つに前記表示情報の一部分を出力するように構成された表示情報バッファと、
前記表示情報リクエスタから要求を受け取り、前記要求のうち１つを選択し、前記要求のうち前記選択された１つを前記表示情報バッファに転送するように構成された仲裁論理とを含むグラフィックス・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グラフィックス・システムに関し、より詳細には、複数のディスプレイ・ストリームまたはディスプレイ・チャネルをサポートすることができるグラフィックス・システムに関する。
【背景技術】
【０００２】
コンピュータ・システムは、通常、コンピュータ・スクリーン上または表示デバイス上にビジュアル出力を生成するためにグラフィックス・システムを利用する。初期のグラフィックス・システムは、プロセッサが出力として生成したものだけを取り込み、それをスクリーン上で表示することだけを担っていた。要するに、初期のグラフィックス・システムは、単純な変換機構またはインターフェースとして作用した。しかし、最新のグラフィックス・システムは、多大な処理能力を備えたグラフィックス・プロセッサを組み込んでいる。最新のグラフィックス・システムは、現在では、単純な変換機構というよりもコプロセッサとして作用する。この変化は、表示デバイスに送られるデータの複雑さと量がともに最近、増大していることに起因する。たとえば、最新のコンピュータ・ディスプレイは、より多くのピクセル、より多数の色を有し、より早期のモデルよりも高いリフレッシュ・レートでより複雑なイメージを表示することができる。同様に、表示されるイメージは、現在では、より複雑であり、アンチエイリアシングやテクスチャ・マッピングなどの進んだ技術がかかわっている。
【０００３】
この結果、グラフィックス・システムにおいて相当な処理能力がなければ、ＣＰＵは、グラフィックス計算を行うのに多大な時間を費やすことになる。これにより、プログラム実行に関連するその他のタスクを行うのに必要とされる処理能力がコンピュータ・システムから奪われて、全体的なシステム・パフォーマンスが劇的に低下する可能性がある。しかし、高性能のグラフィックス・システムを使用すると、ＣＰＵは、スクリーン上にボックスを描くように命令されたとき、各ピクセルの位置および色を計算しなければならないことから解放される。代わりに、ＣＰＵは、「これらの座標でボックスを描け」と述べる要求をビデオ・カードに送ることができる。すると、グラフィックス・システムがボックスを描き、その他のタスクを行うためにプロセッサを解放する。
【０００４】
一般に、コンピュータ内部のグラフィックス・システムは、パフォーマンス・レベルを上げるように独自のプロセッサを含むあるタイプのビデオ・アダプタである。これらのプロセッサは、グラフィックス変換を計算するために特殊化されており、したがって、コンピュータ・システムによって使用される汎用ＣＰＵよりも良好な結果を実現する傾向がある。さらに、これらのプロセッサは、グラフィックス・システムがグラフィックス計算を扱っている間、その他のコマンドを実行するためにコンピュータのＣＰＵを解放する。グラフィックス・アプリケーション、特にマルチメディア・アプリケーションの人気の高さにより、高いパフォーマンスのグラフィックス・システムが多くの新しいコンピュータ・システムに一般的に装備されるようになってきている。ほとんどのコンピュータ製造業者は、現在では、高いパフォーマンスのグラフィックス・システムをコンピューティング・システムとバンドルしている。
【０００５】
多くのアプリケーションでは、２つのモニタ、または２つのディスプレイを同一のコンピュータ・システムに接続していることが有用である可能性がある。たとえば、一部のグラフィックス編集アプリケーションでは、編集されている領域のクローズアップを示すのに１つのモニタを使用し、編集されているオブジェクトまたはピクチャーのより広い視野を示すのに別のモニタを使用することが望ましい。代替として、一部のユーザは、編集されているオブジェクトを表示するように一方のモニタを構成し、編集中に使用することができる様々なパレットまたは編集オプションを表示するように他方のモニタを構成することが可能である。複数のディスプレイが有用である別の状況は、数名のユーザが単一のコンピュータに接続されている場合に生じる。そのような状況では、各ユーザは独自のディスプレイを有することが望ましいであろう。別の状況では、それ以外で可能なよりも大きいディスプレイを提供するために、イメージの異なる部分をそれぞれが表示する複数のディスプレイを有することが望ましい。別の例は、立体視効果を生じさせるために装着者の左目と右目に異なるイメージを提示する立体ゴーグルである。以上の例は、複数のディスプレイが同一のコンピュータ・システムに接続されていることが有用である多くの状況のいくつかだけを示している。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
多くのグラフィックス・システムが複雑であり、高価であることから、グラフィックス・システム全体を重複させることなく、２つのディスプレイをサポートすることができるグラフィックス・システムを提供することが望ましい。したがって、複数のディスプレイ・チャネル間でグラフィックス・システムの部分を共用することができる必要性が存在する。
【課題を解決するための手段】
【０００７】
複数のディスプレイ・チャネルをサポートするグラフィックス・システム、および複数のディスプレイ・チャネル間でグラフィックス・システムを共用するのに使用することができる方法の様々な実施態様を開示する。一実施態様では、フレーム・バッファと、第１のアービタと、ピクセル・バッファと、ピクセル要求アービタと、いくつかの表示出力待ち行列とを含むグラフィックス・システムが開示される。第１のアービタは、フレーム・バッファから表示情報（たとえば、ピクセルまたはサンプル）を求めるディスプレイ・チャネルの要求の間で仲裁を行い、フレーム・バッファに転送すべき要求を選択する。フレーム・バッファは、表示情報を求める選択された要求を受け取ったことに応答して表示情報を出力するように構成されている。ピクセル・バッファは、フレーム・バッファによって出力された表示情報に対応するピクセルを受け取るように構成されている。各ディスプレイ・チャネルは、ディスプレイにデータを提供し、ピクセル・バッファからピクセルを求める要求を生成するように構成された対応する表示出力待ち行列を有する。ピクセル要求アービタは、表示出力待ち行列によって生成されたピクセル要求を受け取り、そのピクセル要求の１つを選択し、選択された要求をピクセル・バッファに転送するように構成されている。選択された要求を受け取ったことに応答して、ピクセル・バッファは、その選択されたピクセル要求を生成した表示出力待ち行列に１つまたは複数のピクセルを出力することが可能である。
【０００８】
一部の実施態様では、グラフィックス・システムは、フレーム・バッファによって出力された表示情報をスクランブル解除するように構成されたスクランブル解除器を含むことが望ましい。たとえば、スクランブル解除器は、フレーム・バッファによって出力されたピクセルをラスタ順に配列して、配列されたピクセルをピクセル・バッファに出力する。また、グラフィックス・システムは、ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、１つまたは複数の索引付き色マップ（ＣＬＵＴＳ）、および現在のカーソル位置のうち少なくとも１つを使用して、ピクセル・バッファによって出力されたピクセルを処理するように構成されたピクセル処理パイプラインをも含む。
【０００９】
ピクセル・バッファは各ディスプレイ・チャネルに関するピクセル待ち行列を含む。第１のアービタは、ピクセル・バッファの中で各チャネルのピクセル待ち行列内のピクセルのレベルを比較することにより、最初の要求の１つを選択するように構成されている。たとえば、第１のチャネルのピクセル待ち行列レベルがしきい値を下回っており、第２のチャネルのピクセル待ち行列レベルがしきい値を上回っている場合、第１のアービタは、第１のチャネルの要求を選択することができる。代替として、チャネルのピクセル待ち行列レベルのどれもしきい値を下回っていない場合、チャネルの要求のどれも選択されないことがある。（ａ）第１のチャネルのピクセル待ち行列レベルと第２のチャネルのピクセル待ち行列レベルがともにしきい値を下回っており、かつ（ｂ）第１のチャネルの不足分（たとえば、しきい値ピクセル待ち行列レベルと実際の待ち行列レベルの差）が、第２のチャネルの不足分より大きい場合、第１のチャネルの要求が選択される。また、第１のアービタは、どのディスプレイ・チャネルが選択された要求に対応するかについてフレーム・バッファに指示するように構成されていることが望ましい。
【００１０】
グラフィックス・システムは、ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに第１の要求をアサートするようにそれぞれが構成された複数の第１のリクエスタを有する。たとえば、それぞれの第１のリクエスタは、対応するディスプレイ・チャネルに関して第１の垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に第１の要求をアサートするように構成されている。
【００１１】
本グラフィックス・システムは、ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに対してピクセル要求をアサートするようにそれぞれ構成された複数のピクセル・リクエスタをも含むことが望ましい。たとえば、各ピクセル・リクエスタは、対応するディスプレイ・チャネルに関する表示出力待ち行列のレベルがあるしきい値を下回って低下したときにピクセル要求をアサートするように構成されることが望ましい。
【００１２】
一部の実施態様では、ピクセル要求アービタは、どのチャネルが最も長い間サービスを受けていないかを判定し、そのチャネルに対するデータがピクセル・バッファの中に用意されている場合、そのチャネルのピクセル要求を選択することによってピクセル要求の１つを選択するように構成されている。最も長い間サービスを受けていないチャネルに対するデータがピクセル・バッファの中で用意されておらず、次に長い間サービスを受けていないチャネルに対するデータがピクセル・バッファの中で用意されている場合、ピクセル要求アービタは、次に長い間サービスを受けていないチャネルに対応するピクセル要求を選択することができる。
【００１３】
一部の実施態様では、グラフィックス・システムは、複数のＣＲＴモニタ、デジタルディスプレイ、ガスプラズマ・ディスプレイ、テレビジョン・モニタ、または以上のディスプレイまたはその他のディスプレイの組合せをサポートすることができる。
【００１４】
一実施態様では、複数のディスプレイ・チャネルの間でグラフィックス・システム・リソースを共用する方法が開示される。この方法は、ディスプレイ・チャネルの１つにそれぞれが対応する表示情報（たとえば、ピクセルまたはサンプル）を求める複数の第１の要求をアサートし、第１の要求の１つを選択して転送することによって第１の要求の間で仲裁を行い、その選択された要求が転送されたことに応答して表示情報を出力し、ディスプレイ・チャネルの１つにそれぞれが対応するピクセルを求める複数の第２の要求をアサートし、第２の要求の１つを選択して転送することによって第２の要求の間で仲裁を行い、および選択された第２の要求が転送されたことに応答して１つまたは複数のピクセルを出力することを含む。
【００１５】
別の実施態様では、グラフィックス・システムが開示される。グラフィックス・システムは、複数のディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルの実際の表示情報ニーズの指示に応答して要求を出力するようにそれぞれ構成された複数の表示情報リクエスタを含む。一部の実施態様では、対応するディスプレイ・チャネルのニーズの指示は、ディスプレイ・チャネルに関するバッファ内または待ち行列内のデータの現在のレベル、またはディスプレイ・チャネルのステータス（たとえば、そのチャネルで垂直帰線消去期間が始まる、または終わる間近であるかどうか）である。また、グラフィックス・システムは、表示情報を記憶し、ディスプレイ・チャネルの１つに対応する選択された要求を受け取ったことに応答してその表示情報の一部分をディスプレイ・チャネルの１つに出力するように構成された表示情報バッファをも含む。本システムは、表示情報リクエスタから要求を受け取り、要求の１つを選択し、選択された要求を表示情報バッファに転送するように構成された仲裁論理を含む。
【発明を実施するための最良の形態】
【００１６】
本発明は、様々な変更形態および代替形態が可能であるが、特定の実施形態を例として図面に示し、本明細書で詳細に説明する。ただし、図面、および図面の詳細な説明は、本発明を開示する特定の形態に限定するものではなく、反対に、本発明は、頭記の特許請求の範囲によって規定される本発明の趣旨および範囲に含まれるすべての変更形態、等価形態、および代替形態を範囲に含むものとする。
【００１７】
コンピュータ・システム−図１
ここで、図１を参照すると、グラフィックス・システムを含むコンピュータ・システム８０の一実施形態が示されている。グラフィックス・システムは、とりわけ、コンピュータ・システム、ネットワークＰＣ、インターネット機器、ＨＤＴＶシステムおよび対話型テレビジョン・システムを含むテレビジョン、パーソナル・デジタル・アシスタント（ＰＤＡ）、バーチャル・リアリティ・システム、ならびに２Ｄグラフィックスまたは３Ｄグラフィックスを表示するその他のデバイスを含め、様々なシステムのいずれの内部に含まれることも可能である。
【００１８】
図示するとおり、コンピュータ・システム８０は、システム・ユニット８２とそのシステム・ユニット８２に結合されたビデオ・モニタまたは表示デバイス８４を含む。表示デバイス８４は、様々なタイプの表示モニタまたは表示デバイス（たとえば、ＣＲＴ、ＬＣＤ、またはガスプラズマ・ディスプレイ）のいずれでもよい。キーボード８６および／またはマウス８８、またはその他の入力デバイス（たとえば、トラックボール、デジタイザ、タブレット、６自由度入力デバイス、ヘッド・トラッカ、アイ・トラッカ、データ・グローブ、またはボディー・センサ）を含め、様々な入力デバイスをコンピュータ・システムに接続することができる。アプリケーション・ソフトウェアがコンピュータ・システム８０によって実行されて、表示デバイス８４上にグラフィックス・オブジェクトが表示される。
【００１９】
コンピュータ・システム・ブロック図−図２
次に、図２を参照すると、図１のコンピュータ・システムを示す単純化されたブロック図が示されている。本発明の理解に必要のないコンピュータ・システムの要素は、便宜上示していない。図示するとおり、コンピュータ・システム８０は、ホスト・バス１０４とも呼ばれる高速のメモリ・バスまたはシステム・バス１０４に結合された中央処理装置（ＣＰＵ）１０２を含む。また、システム・メモリ１０６も高速バス１０４に結合されている。
【００２０】
ホスト・プロセッサ１０２は、様々なタイプの１つまたは複数のプロセッサ、たとえば、マイクロプロセッサ、マルチプロセッサ、およびＣＰＵを含む。システム・メモリ１０６は、ランダム・アクセス・メモリ（たとえば、とりわけ、スタティック・ランダム・アクセス・メモリまたは「ＳＲＡＭ」、シンクロナス・ダイナミック・ランダム・アクセス・メモリまたは「ＳＤＲＡＭ」、およびラムバス（Ｒａｍｂｕｓ）ダイナミック・アクセス・メモリまたは「ＲＤＲＡＭ」）および大容量記憶デバイスを含め、異なるタイプのメモリ・サブシステムの任意の組合せを含むことが可能である。システム・バスまたはホスト・バス１０４は、１つまたは複数の通信バスまたはホスト・コンピュータ・バス（ホスト・プロセッサ、ＣＰＵ、およびメモリ・サブシステムの間の通信のために）、ならびに特殊化されたサブシステム・バスを含むことが可能である。
【００２１】
図２で、グラフィックス・システム１１２は高速メモリ・バス１０４に結合されている。３Ｄグラフィックス・システム１１２は、たとえば、クロスバー・スイッチ、またはその他のバス接続論理によってバス１０４に結合される。様々な他の周辺デバイス、またはその他のバスが、高速メモリ・バス１０４に接続されるということを想定している。グラフィックス・システムは、コンピュータ・システム８０内部のバスの１つまたは複数に結合されること、および／または様々なタイプのバスに結合されることが可能であることに留意されたい。さらに、グラフィックス・システムは、通信ポートに結合されて、外部ソース、たとえば、インターネットまたはネットワークからグラフィックス・データを直接に受け取ることが可能である。図で示すとおり、１つまたは複数の表示デバイス８４が、コンピュータ・システム８０内部に含まれるグラフィックス・システム１１２に接続されている。
【００２２】
ホストＣＰＵ１０２は、ホスト・バス１０４を介して、プログラミングされた入力／出力（Ｉ／Ｏ）プロトコルに従ってグラフィックス・システム１１２との間で情報の転送を行う。別法として、グラフィックス・システム１１２は、直接メモリ・アクセス（ＤＭＡ）プロトコルに従って、またはインテリジェント・バス・マスタリングを介してメモリ・サブシステム１０６にアクセスすることができる。
【００２３】
ＯｐｅｎＧＬまたはＪａｖａ（登録商標）  ３Ｄなどのアプリケーション・プログラミング・インターフェース（ＡＰＩ）に適合するグラフィックス・アプリケーションプログラムが、ホストＣＰＵ１０２で実行され、表示デバイス８４上に出力するためのポリゴンなどの形状プリミティブ（グラフィックス・データ）を定義するコマンドおよびデータを生成する。使用される特定のグラフィックス・インターフェースによる定義に応じて、これらのプリミティブは前面と背面に関して別々の色の特性を有することが可能である。ホスト・プロセッサ１０２はこのグラフィックス・データをメモリ・サブシステム１０６に転送する。その後、ホスト・プロセッサ１０２は、ホスト・バス１０４を介してグラフィックス・システム１１２にそのグラフィックス・データを転送するように動作する。別の実施形態では、グラフィックス・システム１１２は、ＤＭＡアクセス・サイクルを使用してホスト・バス１０４を介して形状データ・アレイを読み込むことが可能である。さらに別の実施形態では、グラフィックス・システム１１２は、インテル・コーポレーションによって広められているアドバンスト・グラフィックス・ポート（Ａｄｖａｎｃｅｄ  Ｇｒａｈｐｉｃｓ  Ｐｏｒｔ）（ＡＧＰ）などの直接ポートを介してシステム・メモリ１０６に結合されることが可能である。
【００２４】
グラフィックス・システムは、ホストＣＰＵ１０２および／またはシステム・メモリ１０６、他のメモリを含む様々なソースのいずれからも、またはネットワーク、たとえば、インターネットなどの外部ソースから、または放送メディアから、たとえば、テレビジョンから、あるいはその他のソースからグラフィックス・データを受け取ることができる。
【００２５】
グラフィックス・システム１１２をコンピュータ・システム８０の一部として描いているが、グラフィックス・システム１１２は、独立型のデバイス（たとえば、独自の組込み式ディスプレイを備えた）として構成させることも可能である。また、グラフィックス・システム１１２は、単一チップ・デバイスとして、あるいはチップ上システムまたはマルチチップ・モジュールの一部として構成させることも可能である。さらに、一部の実施形態では、例示したグラフィックス・システム１１２のいくつかの要素はソフトウェアで実現することができる。
【００２６】
グラフィックス・システム−図３
次に、図３を参照すると、グラフィックス・システム１１２の一実施形態を示す機能ブロック図が示されている。グラフィックス・システム１１２の多くの他の実施形態が可能であり、企図されていることに留意されたい。このグラフィックス・システム１１２は、１つまたは複数のメディア・プロセッサ１４と、１つまたは複数のハードウェア・アクセラレータ１８と、１つまたは複数のテクスチャ・バッファ２０と、１つまたは複数のフレーム・バッファ２２と、１つまたは複数のビデオ出力プロセッサ２４を含んでいる。また、グラフィックス・システム１１２は、１つまたは複数のデジタル−アナログ変換器（ＤＡＣ）２６、および／または１つまたは複数のビデオ符号器２８をも含む。メディア・プロセッサ１４およびハードウェア・アクセラレータ１８は、任意の適切なタイプの高性能プロセッサ（たとえば、特殊化されたグラフィックス・プロセッサまたは計算ユニット、マルチメディア・プロセッサ、ＤＳＰ、または汎用プロセッサ）でよい。
【００２７】
一部の実施形態では、メディア・プロセッサ１４およびハードウェア・アクセラレータ１８は、同一の集積回路内部に含まれる。その他の実施形態では、メディア・プロセッサ１４の部分および／またはハードウェア・アクセラレータ１８が別々の集積回路内部に含まれる。
【００２８】
図に示すように、グラフィックス・システム１１２はホスト・バス（たとえば、図２のホスト・バス１０４）とのインターフェースを含み、グラフィックス・システム１１２がホスト・システム（たとえば、コンピュータ・システム８０）と通信することを可能にする。より具体的には、ホスト・バス１０４は、ホスト・プロセッサがコマンドをグラフィックス・システム１１２に送るようにさせることを可能にする。一実施形態では、ホスト・バス１０４は双方向バスであることが可能である。
【００２９】
グラフィックス・システム１１２の各機能ブロックを以下により詳細に説明する。
【００３０】
メディア・プロセッサ−図４
図４は、メディア・プロセッサ１４の一実施形態を示している。図示するとおり、メディア・プロセッサ１４は、グラフィックス・システム１１２とコンピュータ・システム８０の間でデータの転送を制御することにより、グラフィックス・システム１１２とコンピュータ・システム８０の間のインターフェースとして動作する。一部の実施形態では、メディア・プロセッサ１４は、グラフィックス・データに対する変換、ライティング、および／またはその他の多目的処理を行うように構成させることもできる。
【００３１】
変換とは、オブジェクトを操作することを指し、オブジェクトを並進させること（すなわち、オブジェクトを異なる位置に動かすこと）、オブジェクトのスケール変更を行うこと（すなわち、伸張すること、または縮小すること）、およびオブジェクトを回転させること（たとえば、３次元空間内、つまり「３空間」内で）が含まれる。
【００３２】
ライティングとは、表示されたイメージ内のオブジェクトの証明を計算して、それぞれの個別のオブジェクトがどのような色および／または明るさを有することになるかを特定することを指す。使用されているシェーディング・アルゴリズム（たとえば、コンスタント、グロー、またはフォン）によって、ライティングがいくつかの異なる位置で評価される。たとえば、コンスタント・シェーディングが使用される場合（すなわち、ポリゴンの各ピクセルが同一のライティングを有する場合）、ライティングは、ポリゴン当たり１回計算されるだけでよい。グロー・シェーディングが使用される場合、ライティングは、頂点当たり１回計算される。フォン・シェーディングは、ピクセル当たりでライティングを計算する。
【００３３】
図示するとおり、メディア・プロセッサ１４は、ホスト・インターフェース１１を介してグラフィックス・データを受け取るように構成されている。グラフィックス待ち行列１４８がメディア・プロセッサ１４内部に含まれていて、ホスト・インターフェース１１のアクセラレーテッド・ポートを介して受け取られたデータのストリームをバッファに入れる。受け取られたグラフィックス・データは、１つまたは複数のグラフィックス・プリミティブを含む。本明細書で使用するグラフィックス・プリミティブという用語には、ポリゴン、パラメトリック表面、スプライン、ＮＵＲＢＳ（一様でない有理Ｂスプライン）、細分表面、フラクタル、ボリューム・プリミティブ、ボクセル（すなわち、３次元ピクセル）、およびパーティクル・システムなどが含まれる。一実施形態では、メディア・プロセッサ１４は、形状データ・プリプロセッサ１５０、および１つまたは複数のマイクロプロセッサ・ユニット（ＭＰＵ）１５２も含む。ＭＰＵ１５２は、頂点変換、ライティング計算、およびプログラマブル・ファンクションを行い、結果をハードウェア・アクセラレータ１８に送るように構成されている。また、ＭＰＵ１５２は、ハードウェア・アクセラレータ１８内でテクセル（すなわち、３次元物体に「壁紙をはる（ｗａｌｌｐａｐｅｒ）」のに使用されるテクスチャ・マップの最小のアドレス指定可能な単位）およびピクセルに読取り／書込みアクセスを有することも可能である。形状データ・プリプロセッサ１５０は、形状を伸張し、頂点データを変換してフォーマットし、頂点および命令をＭＰＵ１５２にディスパッチし、頂点タグおよび属性タグ、またはレジスタ・データをハードウェア・アクセラレータ１８に送るように構成されている。
【００３４】
図示するとおり、メディア・プロセッサ１４は、メモリに対するインターフェースを含に、その他の可能なインターフェースを有する。たとえば、図示するとおり、メディア・プロセッサ１４は、直接ラムバスＤＲＡＭ（ＤＲＤＲＡＭ）１６に対する直接ラムバス・インターフェース１５６を含む。ＤＲＤＲＡＭ１６のようなメモリをＭＰＵ１５２のためのプログラムおよびデータの記憶に使用することができる。また、ＤＲＤＲＡＭ１６を使用して表示リストおよび／または頂点テクスチャ・マップを記憶することも可能である。
【００３５】
また、メディア・プロセッサ１４は、グラフィックス・システム１１２のその他の機能構成要素に対するインターフェースをも含む。たとえば、メディア・プロセッサ１４は、ハードウェア・アクセラレータ１８などの別の特殊化されたプロセッサに対するインターフェースを有することもある。例示した実施形態では、コントローラ１６０が、メディア・プロセッサ１４がハードウェア・アクセラレータ１８を制御するアクセラレーテッド・ポート・パスを含む。また、メディア・プロセッサ１４は、コントローラ１６０を介してメモリ１６、ハードウェア・アクセラレータ１８、およびビデオ出力プロセッサ２４に対する直接ポート・パスを提供するバス・インターフェース・ユニット（ＢＩＵ）１５４などの直接インターフェースも含む。
【００３６】
ハードウェア・アクセラレータ−図５
１つまたは複数のハードウェア・アクセラレータ１８は、メディア・プロセッサ１４からグラフィックス命令およびグラフィックス・データを受け取り、受け取った命令に従って、受け取ったデータに対していくつかの機能を行うように構成されている。たとえば、ハードウェア・アクセラレータ１８は、グラフィックス・データ内で出現する様々なグラフィックス・プリミティブのラスタ化、２Ｄまたは３Ｄのテクスチャリング、ピクセル移動、イメージング、フラグメント処理、クリッピング、深度キューイング、透明度処理、セットアップ、および／またはスクリーン空間レンダリングを行う。以上の特徴のそれぞれを以下に別々に説明する。
【００３７】
クリッピングとは、ワールド・スペース内の３Ｄビュー・ボリュームの外側にあるグラフィックス・プリミティブ、またはグラフィックス・プリミティブの一部を除去することを指す。３Ｄビュー・ボリュームは、ワールド・スペース内に位置する仮想の観察者（または仮想カメラ）に見えるワールド・スペースの部分を表わしている。たとえば、ビュー・ボリュームは、２Ｄビュー・ウインドウとワールド・スペース内に位置する視点とによって生成された中実の切頭角錐である。中実の切頭角錐は、視点から放出され、ビュー・ウインドウを通過するすべての光線の結合として想像することができる。視点は、仮想観察者のワールド・スペースの位置である。ほとんどのケースで、３Ｄビュー・ボリュームの外側にあるプリミティブ、またはプリミティブの部分は、現在、見えておらず、さらなる処理から除外することができる。３Ｄビュー・ボリュームの内側にあるプリミティブ、またはプリミティブの部分は、２Ｄビュー・ウインドウ上に投射するための候補である。
【００３８】
セットアップとは、３次元ビューポートにプリミティブをマップすることを指す。これは、元の「ワールド座標」系から確立されたビューポートの座標に物体を並進させて、変換することに関わる。これにより、スクリーン上に表示された３次元物体に対して正しい遠近感がもたらされる。
【００３９】
スクリーン空間レンダリングとは、表示される各ピクセルを形成するのに使用されるデータを生成するように行われる計算を指す。たとえば、ハードウェア・アクセラレータ１８が「サンプル」を計算する。サンプルは、色情報を有するが、現実の面積を有さないポイントである。サンプルにより、ハードウェア・アクセラレータ１８は「スーパーサンプリング」を行うこと、つまりピクセル当たり複数のサンプルを計算することができる。スーパーサンプリングにより、より高い品質のイメージがもたらされる可能性がある。
【００４０】
ハードウェア・アクセラレータ１８は、いくつかのインターフェースを含むこともできる。たとえば、例示した実施形態では、ハードウェア・アクセラレータ１８は、４つのインターフェースを有する。ハードウェア・アクセラレータ１８は、メディア・プロセッサ１４と通信するインターフェース１６１（「ノース・インターフェース」と呼ばれる）を有する。ハードウェア・アクセラレータ１８は、このインターフェースを介してメディア・プロセッサ１４からコマンドを受け取る。さらに、ハードウェア・アクセラレータ１８は、バス３２に対するインターフェース１７６も含む。バス３２は、ハードウェア・アクセラレータ１８をブートＰＲＯＭ３０および／またはビデオ出力プロセッサ２４に接続する。ブートＰＲＯＭ３０は、システム初期設定データ、および／またはフレーム・バッファ２２に関する制御コードを記憶する。ハードウェア・アクセラレータ１８は、テクスチャ・バッファ２０に対するインターフェースも含む。たとえば、ハードウェア・アクセラレータ１８は、ハードウェア・アクセラレータ１８がテクスチャ・バッファ２０に対して読取りおよび書込みを行うことを可能にする８方向インターリーブ・テクセル・バス（eight-way interleaved texel bus）を使用して、テクスチャ・バッファ２０とインターフェースをとることができる。また、ハードウェア・アクセラレータ１８は、フレーム・バッファ２２とインターフェースをとることも可能である。たとえば、ハードウェア・アクセラレータ１８は、４方向インタリーブ・ピクセル・バスを使用してフレーム・バッファ２２に対して読取りおよび／または書込みを行うことができる。
【００４１】
頂点プロセッサ１６２は、メディア・プロセッサ１４から受け取った頂点タグを使用して、ＭＰＵ１５２からの頂点データの順序付けられた組立てを行うことができる。頂点は、メッシュ・バッファ１６４の中に保存されており、および／またはメッシュ・バッファ１６４から取り出される。
【００４２】
レンダ・パイプライン１６６は、頂点を受け取り、フラグメントに変換する。レンダ・パイプライン１６６は、２Ｄウインドウ・システム・プリミティブ（たとえば、ドット、フォント、ブレゼンハム線、ポリゴン、長方形、高速塗りつぶし（fast-fill）、およびＢＬＩＴ（スクリーン上で動く物体の表示を早めることが可能なメイン・メモリから表示メモリの中にビットの長方形ブロックを動かすビット・ブロック移動））、および３Ｄプリミティブ（たとえば、平滑で大きいドット、平滑で幅広いＤＤＡ（デジタル微分解析器）線、三角形、ポリゴン、および高速クリア）をラスタ化してピクセル・フラグメントにするように構成されている。レンダ・パイプライン１６６は、フルスクリーン・サイズのプリミティブを扱い、平面およびエッジの傾きを計算し、ｒ、ｇ、ｂ（すなわち、レッド、グリーン、ブルーの頂点の色）、ｒ２、ｇ２、ｂ２（すなわち、ライティングが当てられたテクスチャからのレッド、グリーン、およびブルーの反射色（specular color））、ａ（アルファ）、ならびにｚ、ｓ、ｔ、ｒ、ｗ（テクスチャ座標成分）などのインターポラント（interpolant）または成分を使用して、ピクセル・タイル解像度までデータを補間するように構成されている。
【００４３】
スーパーサンプリングを使用する実施形態では、サンプル生成器１７４は、レンダ・パイプライン１６６によって出力されたフラグメントからサンプルを生成し、どのサンプルがラスタ化エッジの内側にあるかを判定するように構成されている。サンプル位置は、ロード可能なテーブルの中で規定されて、確率的サンプリング・パターンが使用できる。
【００４４】
ハードウェア・アクセラレータ１８は、３Ｄプリミティブからのテクスチャを有するフラグメントをフレーム・バッファ２２に書き込むように構成されている。レンダ・パイプライン１６６が、ｒ、ｓ、ｔ、およびｗを規定するピクセル・タイルをテクスチャ・アドレス・ユニット１６８に送る。テクスチャ・アドレス・ユニット１６８は、フラグメントによってアドレス指定された隣接するテクセルのセット、ならびにテクスチャ・フィルタに関する補間係数を特定し、テクセルをテクスチャ・バッファ２０に書き込む。テクスチャ・バッファ２０は、各クロックにおいて可能な限り多くの隣接するテクセルを獲得するようにインターリーブされる。テクスチャ・フィルタ１７０は、バイリニア（bilinear）補間、トライリニア（trilinear）補間、クォドリニア（quadliner）補間を行うことができる。ピクセル移動ユニット１８２は、テクセルにスケール変更を行うこと、バイアスをかけること、および／またはテクセルをルックアップすることができる。テクスチャ環境１８０は、サンプル生成器１７４によって生成されたサンプルにテクセルを適用することができる。また、テクスチャ環境１８０を使用して、イメージに対する形状変換を行う（たとえば、バイリニア・スケール変更を行う、回転させる、反転する）こと、ならびにテクスチャ・バッファ・イメージデータに対してイメージ濾過オペレーション（たとえば、双３次スケール変更（bicubic scale）および畳み込み）を行うこともできる。
【００４５】
例示した実施形態では、ピクセル移動ＭＵＸ１７８が、ピクセル移動ユニット１８２に対する入力を制御する。ピクセル移動ユニット１８２は、ノース・インターフェース１６１を介して受け取られたピクセル・データを選択的にアンパックすること、フレーム・バッファ２２またはテクスチャ・バッファ２０からチャネルを選択すること、あるいはテクスチャ・フィルタ１７０またはサンプル・フィルタ１７２から受け取られたデータを選択することができる。
【００４６】
ピクセル移動ユニット１８２を使用して、スケール変更オペレーション、バイアス・オペレーション、および／または色マトリックス・オペレーション、色ルックアップ・オペレーション、色ヒストグラム・オペレーション、蓄積オペレーション、正規化オペレーション、および／または最小／最大ファンクションを行うことができる。処理されるデータのソース、およびそのデータに対して行われるオペレーションに依存して、ピクセル移動ユニット１８２は、データをテクスチャ・バッファ２０に（テクスチャ・バッファＭＵＸ１８６を介して）、フレーム・バッファ２２に（テクスチャ環境ユニット１８０およびフラグメント・プロセッサ１８４を介して）、またはホストに（ノース・インターフェース１６１を介して）出力することができる。たとえば、一実施形態では、ピクセル移動ユニット１８２は、ピクセル移動ＭＵＸ１７８を介してホストからピクセル・データを受け取った場合、スケール変更オペレーション、バイアス・オペレーション、または色マトリックス・オペレーションを行い、次に、色ルックアップ・オペレーションまたは色ヒストグラム・オペレーションを行い、次に、最小／最大ファンクションを行うために使用される。次に、ピクセル移動ユニット１８２は、データをテクスチャ・バッファ２０またはフレーム・バッファ２２に出力する。
【００４７】
フラグメント・プロセッサ１８４を使用して、ＯｐｅｎＧＬフラグメント処理オペレーションなどの標準のフラグメント処理オペレーションを行うことができる。たとえば、フラグメント・プロセッサ１８４は、次のオペレーション、すなわち、フォギング（fog）、領域パターン形成、シザリング（scissor）、アルファ／色試験、所有者試験（ＷＩＤ）、ステンシル試験、深度試験、アルファ混合、または論理演算（ＲＯＰ）、平面マスキング、バッファ選択、ピック・ヒット／閉塞（pick hit/occlusion）検出、および／または重なり合ったウインドウを加速するための補助クリッピングを行うことができる。
【００４８】
テクスチャ・バッファ２０
テクスチャ・バッファ２０はいくつかのＳＤＲＡＭを含む。テクスチャ・バッファ２０は、ハードウェア・アクセラレータ１８のためにテクスチャ・マップ、イメージ処理バッファ、および蓄積バッファを記憶するように構成されている。テクスチャ・バッファ２０は、多数の異なる能力を有する（たとえば、テクスチャ・バッファ２０内に含まれるＳＤＲＡＭのタイプに応じて）。一部の実施形態では、ＳＤＲＡＭの各ペアは、独立に行と列のアドレス指定が可能である。
【００４９】
フレーム・バッファ２２
グラフィックス・システム１１２はフレーム・バッファ２２を含む。一実施形態では、フレーム・バッファ２２は、複数のメモリ・デバイス（三菱によって開発されたＭ５Ｍ４１００９２Ｂ  ３Ｄ−ＲＡＭなどの）を含む。フレーム・バッファ２２は、ディスプレイ・ピクセル・バッファ、オフスクリーン・ピクセル・バッファ、および／またはスーパーサンプル・バッファとして構成されている。さらに、一実施形態では、フレーム・バッファ２２のある部分は、ディスプレイ・ピクセル・バッファとして使用することができ、その他の部分は、オフスクリーン・ピクセル・バッファおよびスーパーサンプル・バッファとして使用することができる。一部の実施形態では（たとえば、フレーム・バッファ２２が３Ｄ−ＲＡＭデバイスを含む場合）、フレーム・バッファは、表示情報（たとえば、透明度、ＷＬＵＴ等）に対してあるオペレーションを行うことができる。
【００５０】
出力プロセッサ−図６
グラフィックス・システム１１２内に出力プロセッサ２４も含まれる。出力プロセッサ２４は、フレーム・バッファ２２から出力された表示情報をバッファに入れ、処理することができる。たとえば、出力プロセッサ２４は、フレーム・バッファ２２からのピクセルのバーストを読み取るように構成されている。また、出力プロセッサ２４は、フレーム・バッファ２２が２重バッファ式になっている場合、２重バッファ選択（ｄｂｓｅｌ）を行い、透明度の重ね合わせ（overlay transparency）を行い（透明度／重ね合わせユニット１９０を使用して）、平面グループ抽出を行い、ガンマ補正を行い、擬似色または色のルックアップまたはバイパスを行い、かつ／またはカーソル生成を行うことができる。たとえば、例示した実施形態では、出力プロセッサ２４は、ＷＩＤ（ウインドウＩＤ）ルックアップ・テーブル（ＷＬＵＴ）１９２、ならびにガンマ・ルックアップ・テーブルおよび色マップ・ルックアップ・テーブル（ＧＬＵＴ、ＣＬＵＴ）１９４を含む。また、出力プロセッサ２４は、２つの独立したラスタ・タイミング生成器１９６を使用して、２つのディスプレイに対する２つの出力ストリームをサポートするように構成させることも可能である。たとえば、１つのラスタ（たとえば、１９６Ａ）が１２８０×１０２４のＣＲＴを駆動し、他方のラスタ（たとえば、１９６Ｂ）が符号化されたテレビジョン・ビデオを備えたＮＴＳＣデバイスまたはＰＡＬデバイスを駆動することが可能である。
【００５１】
ＤＡＣ２０２はグラフィックス・システム１１２の最終出力ステージとして動作する。ＤＡＣ２０２は、ＧＬＵＴ／ＣＬＵＴ／カーソル・ユニット１９４から受け取られたデジタル・ピクセル・データを表示デバイスに送られるアナログ・ビデオ信号に変換する。一実施形態では、アナログ・ビデオ信号の代わりにデジタル・ピクセル・データを出力するために、ＤＡＣ２０２をバイパスし、または完全に省くことが可能である。これは、表示デバイスがデジタル技術（たとえば、ＬＣＤタイプのディスプレイ、またはデジタル・マイクロミラー・ディスプレイ）に基づく場合に有用であろう。
【００５２】
ＤＡＣ２０２は、陰極線管（ＣＲＴ）モニタなどの表示デバイスにアナログ・ビデオ出力を提供するように構成されたレッド−グリーン−ブルーのデジタル−アナログ変換器である。一実施形態では、ＲＧＢ  ＤＡＣ２０２は、２４０ＭＨｚのドット・レートで高解像度のＲＧＢアナログ・ビデオ出力を提供するようになっている。同様に、符号器２００は、ディスプレイに符号化されたビデオ信号を供給するように構成されている。たとえば、符号器２００は、符号化されたＮＴＳＣビデオまたはＰＡＬビデオをＳ−ビデオまたは合成ビデオのテレビジョン・モニタまたは記録デバイスに提供する。
【００５３】
その他の実施形態では、出力プロセッサ２４は、ピクセル・データをディスプレイの他の組合せに出力することができる。たとえば、ピクセル・データを２つのＤＡＣ２０２に（ＤＡＣ２０２および符号器２００のそれぞれの１つにではなく）出力することにより、ビデオ出力プロセッサ２４は、２つのＣＲＴを駆動することができる。別法として、２つの符号器２００を使用することにより、ビデオ出力プロセッサ２４は、適切なビデオ入力を２つのテレビジョン・モニタに供給することができる。一般に、表示デバイスの多数の異なる組合せを、その表示デバイス向けの適切な出力デバイスおよび／または変換器を用意することによってサポートすることができる。
【００５４】
デュアル・チャネル・デマンド駆動型出力プロセッサ
多くの適用例では、グラフィックス・システム１１２のような単一のグラフィックス・システムを複数のディスプレイ・チャネル間で共用することが望ましい。さらに、同期された帰線消去期間を有さない２つまたはそれより多くの独立したディスプレイ・チャネル間で単一のグラフィックス・システムを共用することが望ましい。
【００５５】
複数の独立したディスプレイ・チャネルにサービスを提供するため、各チャネルに対して、そのチャネルの理論上のデマンドではなく、実際のデマンドに基づいてデータを提供することが有益であることがある。特定のチャネルの理論上のデマンドは、通常、そのチャネルがサイクル当たり、平均でどれだけのピクセルを必要とするかのあらかじめ計算された比である。理論上のデマンドは、特定のディスプレイ・チャネルが、ある時点でより多くのピクセルを必要とし、他の時点でそれほどのピクセルを必要としない可能性があることを無視する。たとえば、チャネルは、垂直帰線消去および／または水平帰線消去の期間中または間隔中（すなわち、表示データの各フレームおよび／または各線の間の期間）に生じるサイクル中に、ピクセルを必要としない。したがって、帰線消去期間ではない期間（すなわち、表示データが表示されている期間）中のそのチャネルの実際のデマンドは、あらかじめ計算された比が反映する平均のデマンドよりも高い可能性がある。同様に、帰線消去期間中のそのチャネルの実際のデマンドは、そのチャネルの理論上のデマンドよりも低い可能性がある。
【００５６】
実際のデマンドと理論上のデマンドの間の差は、複数のディスプレイ・チャネルが同一のフレーム・バッファからサービスを受けている場合に重大になる。同期された帰線消去期間を有するディスプレイ・チャネルが、理論上のデマンドに基づいてサービスを受けている場合、１つのチャネルが帰線消去期間のために停止すると、その他のチャネルも停止し、したがって、両方のチャネルが帰線消去期間中に出力データの余剰を蓄積し、両方のチャネルは、この余剰をより高いデマンドの帰線消去期間でない期間中に使用することが可能である。ただし、同期された帰線消去期間を持たないチャネルは、理論上のデマンドに基づいてサービスを受けている場合、データのこの有益な蓄積がチャネルの１つまたは複数に生じない。たとえば、あるチャネルは、表示データが必要なときに全く表示データが用意されていないことになるが、同時に、別のチャネルは、帰線消去期間中に表示データの余剰が用意されていることになる。
【００５７】
したがって、独立したディスプレイに十分にサービスを提供するため、ディスプレイの理論上のではなく、実際のデマンドに基づき、ディスプレイにサービスを提供することが有益である。図７は、２つの独立したディスプレイ・チャネルに、そのチャネルの実際のデマンドに基づいてサービスを提供するように構成されたグラフィックス・システムの一実施形態の例を示している。図７に示したシステムは、独立した帰線消去期間を有するディスプレイが同一のフレーム・バッファを共用することを可能にするものとして説明するが、このシステムは、同期された帰線消去期間を有するディスプレイにも適合することが可能であることに留意されたい。
【００５８】
図７に示すとおり、表示情報バッファ７０１が、ＡとＢの両方のチャネルのためにデータを記憶する。表示情報バッファ７０１は、チャネルの１つから要求を受け取ったことに応答してチャネルの１つにデータを出力する。たとえば、一実施形態では、表示情報バッファ７０１は、表示情報のバーストを出力するように構成されたフレーム・バッファである。別の実施形態では、表示情報バッファ７０１は、ピクセルのペアを出力するように構成されたピクセル・バッファである。
【００５９】
２つのリクエスタ７０９が、表示情報を求める対応するチャネルの実際のデマンドに基づいて要求をアサートするように構成されている。アービタ７０５が、チャネルの要求を代行受信し、チャネルの要求の１つを選択して表示情報バッファ７０１に転送する。一実施形態では、アービタ７０５は、どのチャネルが最もニーズが高いか、すなわち、どのチャネルが最も急に表示データを必要とするかを特定することにより、どの要求を転送するかを決める。たとえば、チャネルがそれぞれ表示データ出力待ち行列を有する場合、ニーズが最も高いチャネルは、待ち行列の中でデータのレベルが最も低いチャネルである。
【００６０】
各チャネルのリクエスタ７０９は、ある条件が生じた場合に要求をアサートするように構成されている。たとえば、チャネルのリクエスタ７０９は、垂直帰線消去期間が終わった後に要求をアサートを開始し、次の垂直帰線消去期間の始まりまで要求をアサートすることを継続する。ただし、多くの実施形態（たとえば、表示情報バッファ７０１がグラフィックス・データのバーストを出力するように構成された実施形態）では、各チャネルは要求を構造化し、チャネルがデータをプリフェッチできるようにすることが好ましい。データをプリフェッチすることにより、各チャネルは、要求プロセスの待ち時間、および別のチャネルの要求がサービスを受けるのを待たなければならないことによる遅延を考慮に入れ、自らのデータのニーズが確実に満たされるようにできる。したがって、以上の実施形態では、リクエスタ７０９は、垂直帰線消去期間の終りより前の何らかの時点で要求をアサートすることを始め、次の垂直帰線消去期間の始まりより前の何らかの時点で要求をアサートすることを止めるように構成されている。
【００６１】
別の実施形態では、リクエスタ７０９は、対応するチャネルの表示出力待ち行列８２１内の表示情報のレベルがあるしきい値を下回った場合、要求をアサートするように構成されている。たとえば、リクエスタ７０９Ａは、表示出力待ち行列８２１Ａのレベルが満杯の半分を下回ったとき、要求をアサートするように構成されている。
【００６２】
図８は、共用される出力パイプラインの別の実施形態を示している。図８は、図６で示したのと同様の出力プロセッサを示しており、いくつかのリクエスタ８０９、およびアービタ８０５、８１７が追加され、ピクセル・バッファ８１５が含まれている。この実施形態では、２つのディスプレイ・ストリームが、グラフィックス・システム・リソースを共用している。「卸売り」ループおよび「小売り」ループと呼ばれる共用リソースの２つのステージが存在する。これらのループは、図８で示されており、各ディスプレイ・チャネルの最終の「消費者」ループも示されている。卸売りループは、要求に応答して比較的大量の表示情報（たとえば、バースト）を出力するように構成されており、他方、小売りループは、より少量の転送（たとえば、ピクセルのペア）を使用して動作する。したがって、卸売りループからのデータを要求することにより、チャネルは、実際のデマンドを見越して表示情報をプリフェッチすることができる。卸売りループの粒度（たとえば、データのバースト）がかなり粗いことにより、プリフェッチが促される可能性がある。というのは、卸売りループから十分に早くデータを要求することを怠ったチャネルは、後の時点で表示するために十分な表示情報が用意されていないことになる可能性があるからである。小売りループの要求システムの粒度がより細かいことにより、各チャネルの現在のデマンドに基づくより微細な調整が可能になる。
【００６３】
卸売りループでは、２つのストリームはそれぞれ、フレーム・バッファ２２に対して、ピクセルまたはサンプルなどのある量の表示情報を出力するように要求をアサートする。各ストリームのリクエスタ８０９は、それぞれの特定のストリームのデータ要件を示すある条件に応答して要求をアサートするように構成されている。たとえば、各チャネルのリクエスタ８０９は、十分に前もって表示情報を要求するように構成され、卸売りループの可能な最大待ち時間を想定して、ピクセルが必要とされるときにチャネルが十分なピクセルを受け取るようにすることが可能である。たとえば、一実施形態では、各チャネルのリクエスタ８０９は、データを正確にプリフェッチするため、そのチャネルに関する垂直帰線消去期間の終りよりわずかに前に要求をアサートすることを始めるように構成されている。同様に、データがプリフェッチされているので、各チャネルのリクエスタは、垂直帰線消去期間の始まりよりわずかに前に要求を発行するのを止めるように構成されている。以上の要求時間中、各チャネルのリクエスタは、卸売りループの粒度に応じて、水平帰線消去期間の終りの直前の時点と次の水平帰線消去期間の始まりの直前の時点の間に要求を集中させることも可能である。フレーム・バッファ２２から完全なフレームを取り出すため、各チャネルに対して複数の要求が発行されることも可能である。帰線消去期間中に要求を止めることにより、出力処理パイプラインの中でさらなるリソースが、マルチバッファ同期やＷＬＵＴ更新ポスティングなどの帰線消去期間中に通常、行われるオペレーションを行うのに利用できるようになる。
【００６４】
したがって、各チャネルのリクエスタ８０９が、要求をフレーム・バッファ２２に出力する。アービタ８０５が、その要求のどれかがフレーム・バッファ２２に実際に転送されるとすれば、どれが転送されるかを制御する。アービタ８０５は、どのチャネルで最も早期にピクセルが無くなるかを推定し、そのチャネルの要求をフレーム・バッファ２２に転送することができる。たとえば、一実施形態では、アービタは、ピクセル・バッファ８１５の中のそのチャネルのブロック待ち行列（ＢＱ１およびＢＱ２）内の有効なブロックの数のカウントを受け取ることができる。ブロックの数があるしきい値を上回っている場合、アービタ８０５は、そのチャネルが「ニーズが高い」ことはないと判定し、したがって、そのチャネルの要求を転送することはしない。しかし、有効なブロックの数がしきい値を下回っている場合、チャネルは、ニーズが高く、そのチャネルの要求が転送される。両方のチャネルが同時に要求をアサートした場合、アービタ８０５はまず、どちらかのチャネルのブロック・カウントがしきい値を下回っているかどうかを判定する。どちらのチャネルもニーズが高くない場合、アービタ８０５は、どちらの要求も転送されるべきでないと判定することができる。そうではなく、１つのチャネルだけがニーズが高いものとして資格を満たす場合、そのチャネルの要求が転送される。しかし、両方のチャネルのブロック・カウントがしきい値を下回っている場合、アービタ８０５は、各チャネルに関する有効なブロックのカウントを比較することができる。ブロックの不足分（しきい値を下回る）がより大きいチャネルがよりニーズが高いチャネルであり、そのチャネルの要求が転送される。しきい値レベルは、出力パイプラインにおけるより後のステージの待ち時間に基づいて選択される。たとえば、しきい値レベルは、小売りループおよび消費者ループにおける待ち時間にも関わらず、表示情報が必要とされるときに十分な表示情報を対応するチャネルが受け取るように、ブロック待ち行列の中に十分な表示情報を保つレベルである。
【００６５】
一部の実施形態では、アービタ８０５は、いくつかの信号をフレーム・バッファ２２にアサートすることによってチャネルの要求を転送することができる。たとえば、一実施形態では、アービタ８０５は、バースト要求と、そのバースト要求がチャネルのどれに対応するかを示す信号とをともにアサートすることができる。さらに、アービタ８０５は、どのタイプのバースト要求がアサートされているのかを示す信号もアサートすることができる。バースト要求のタイプの例には、新しいフレームの開始、フレーム内の追加のフィールドの開始、ストリームの中の次のバースト、走査における最後のバースト、走査線の終り、およびフィールドの終りが含まれる。
【００６６】
フレーム・バッファ２２は、アービタ８０５によって転送された要求を受け取ったことに応答して表示情報を出力するように構成されている。一部の実施形態では、フレーム・バッファ２２は、表示情報をピクセル、またはピクセルの部分として記憶することができる。他の実施形態では、フレーム・バッファ２２は、表示情報をサンプルとして記憶することができる。実施形態に応じて、フレーム・バッファ２２は、受け取られた要求に応答して、ある量およびあるタイプの表示情報を出力する。たとえば、一実施形態では、フレーム・バッファはバーストで表示情報を出力することができる。
【００６７】
一実施形態では、表示アドレス生成器およびフレーム・バッファ・インターフェース（図示せず）が、表示情報要求を処理することができる。表示アドレス生成器は、各チャネルのグラフィックス・データの現在のアドレスを追跡し、そのチャネルからの要求が受け取られたとき、適切なデータがフレーム・バッファ２２から出力されるようにすることができる。したがって、要求がサービスを受けた後、表示アドレス生成器は、そのチャネルのデータに関するアドレスを更新することができる。フレーム・バッファ・インターフェースは、実際のグラフィックス・データ転送オペレーションを制御することができる。また、フレーム・バッファ・インターフェースは、一実施形態では、要求を受け取ったことに応答して確認応答を送ることもできる。表示アドレス生成器および／またはフレーム・バッファ・インターフェースは、ハードウェア・アクセラレータ１８のようなデバイス内部に含まれてもよい。
【００６８】
例示した実施形態では、フレーム・バッファ２２の中に記憶されたデータは、ディスプレイに実際に出力される前にさらに処理されることがある。たとえば、一実施形態では、ピクセル・データはラスタ順でフレーム・バッファ２２の中に記憶されない。この結果、順序の乱れたピクセル・データは、フレーム・バッファ２２から出力されると、以下により詳細に説明するとおり、スクランブル解除器８１１を通る。スクランブル解除器８１１は、データのあるグループ化の中でピクセルを正しく並べる（たとえば、各ブロック内でピクセルを正しく並べる）ように構成されている。
【００６９】
スクランブル解除されたグラフィックス・データは、次に、ピクセル・バッファ８１５に送られる。ピクセル・バッファ８１５は、共用バッファ（区分化されたバッファではなく）として実装されることが可能であり、したがって、チャネルのデータ・ストリームが、バッファ８１５内部で物理的に混合される。たとえば、各チャネルのデータ・ストリームは、連結リストとして実現される。この構成は、バッファ８１５内部のストレージの最適な使用を提供するが、実施するのが困難である。したがって、別の実施形態では、ピクセル・バッファ８１５は、各データ・ストリームが独自の専用記憶スペースを有するように区分化されている。この実施形態は、ピクセル・バッファ８１５内部で利用可能なスペースの使用を最適化しない共用バッファよりも実施するのが容易である。一般に、ピクセル・バッファ８１５の中に記憶されたピクセル・データは、ピクセル・バッファ８１５がチャネル間でどのように実際に共用されるかに関わらず、各チャネルに関するブロック待ち行列（ＢＱ１およびＢＱ２）の中に記憶されているものとして説明することができる。
【００７０】
小売りループの一環として、各チャネルは、ピクセル・バッファ８１５からデータを要求することができる。両方のチャネルにサービスを提供するため、ピクセル要求アービタ８１７は、チャネルのピクセル要求を監視し、要求の１つを選択してピクセル・バッファ８１５に転送することができる。卸売りループのアービタ８０５と同様に、一実施形態では、ピクセル要求アービタ８１７も、最もニーズの高いのチャネルの要求を選択することによって２つのチャネル間で仲裁を行うことができる。最もニーズの高いチャネルは、最も短い期間中に最も多くのピクセルを必要とするチャネルである。一実施形態では、ピクセル要求アービタ８１７は、どのチャネルが最もニーズが高いかを、そのチャネルの表示出力待ち行列８２１内のデータのレベルに基づいて判定することができる。また、ピクセル要求アービタ８１７は、チャネルのどれにピクセル・バッファ８１５からのピクセル・データが用意されているかに基づき、どのピクセル要求がピクセル・バッファ８１５に転送されるかを制御することもできる。たとえば、両方のチャネルにデータが用意されており、両方が同時にピクセルを要求した場合、アービタ８１７は、チャネルの要求の間で交替を行うことができる。
【００７１】
表１は、ピクセル要求アービタが、別の実施形態に従ってどのように動作するかの例を示している。
【００７２】
【表１】
2004536388.tif 000003
【００７３】
表１に示すとおり、２つのチャネルはそれぞれ、ピクセル要求アービタ８１７に対してピクセル要求（それぞれＰＲ１およびＰＲ２）をアサートすることができる。１つのチャネルだけが要求をアサートし、そのチャネルのブロック待ち行列がレディーである（たとえば、データを含む）場合、そのチャネルの要求がサービスを受けることができる。両方のチャネルが同時にデータを要求するが、１つのチャネルだけにピクセル・バッファ（すなわち、そのチャネルのブロック待ち行列）の中でデータが用意されている場合、そのチャネルの要求がサービスを受けることが可能である。両方のチャネルがデータを要求し、両方のチャネルにデータが用意されている場合、どちらであれ、より長い間サービスを受けていない方のチャネルの要求がサービスを受ける。
【００７４】
例示した実施形態では、表示出力待ち行列８２１が、各チャネルのピクセル要求をアサートすることを担う。たとえば、一実施形態では、各表示出力待ち行列８２１は、待ち行列８２１が満杯の半分を下回ったときにピクセル要求をアサートする。別の実施形態では、各表示出力待ち行列８２１は、完全な満杯を下回ったときにデータを要求することを開始する。他の多くのしきい値レベルが可能である。多くの実施形態では、データが必要とされるときに十分なデータがチャネルに用意されていることを確実にするポイントでピクセル要求がアサートされるように、しきい値レベルを設定することが望ましい。したがって、しきい値レベルは、小売りループの最大待ち時間を考慮に入れることができる。この待ち時間は、次のすべて、またはいくつかを含む。すなわち、出力待ち行列８２１がピクセル要求アービタ８１７に対して要求をアサートするのにかかる時間、ピクセル要求アービタ８１７が要求を選択して転送するのにかかる時間、両方のチャネルが同時にピクセルを要求し、他方のチャネルの要求が先にサービスを受ける場合を見越した追加の時間、ピクセル・データがピクセル・バッファ８１５内のチャネルのブロック待ち行列から読み取られるのにかかる時間、ピクセル・データがピクセル処理パイプライン１９４を通過するのにかかる時間、および／または表示出力待ち行列８２１をロードするのにかかる時間である。
【００７５】
ピクセル・バッファ８１５に要求が転送されると、ピクセル・バッファ８１５は、その要求を受け取ったことに応答して１つまたは複数のピクセルを出力することができる。たとえば、一実施形態では、ピクセル・バッファ８１５は、それぞれの受け取られた要求に応答してペアのピクセルを出力することができる。一部の実施形態では、ピクセル・バッファ８１５を離れると、ピクセルはさらなる処理を受ける。たとえば、ピクセルは、ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、および／または索引付き色マップ（ＣＬＵＴＳ）１９４を使用して処理される。多くの実施形態では、ピクセルは、現在のカーソル位置に従って処理される（たとえば、ピクセル・アドレスが現在のカーソル位置と一致する場合、そのピクセルが、カーソル・ビットマップの一部分で置き換えられることが可能である）。一般に、この追加の処理は、ピクセル処理パイプライン１９４として説明される。
【００７６】
追加の処理が実施された後、ピクセルは、要求側のチャネルの表示出力待ち行列（ＤＯＱ）８２１に書き込まれる。各チャネルは、独自の表示出力待ち行列８２１を持ち、したがって、出力パイプラインにおけるこのポイントで、チャネルは、もはやリソースを共用していない。次に、ピクセルが、表示出力待ち行列８２１から読み出され、各チャネルに関する消費者ループを使用して対応するディスプレイに送られる。たとえば、一実施形態では、ピクセルは、２ピクセル・クロック・サイクル当たり１ペアのピクセルの速度で各表示出力待ち行列８２１から読み取られ、したがって、ディスプレイは、１サイクル当たり１つのピクセルを受け取り、他方、表示出力待ち行列８２１が、そのピクセル速度の半分で動作する。ディスプレイがＣＲＴである場合、表示出力待ち行列８２１から読み出されたピクセルは、図３に示したようなＤＡＣによって処理されてからディスプレイに出力される。同様に、ディスプレイがＮＴＳＣディスプレイ・デバイスである場合、ピクセルは、ビデオ符号器を通されてからディスプレイに出力される。一般に、多くの異なるタイプのディスプレイが図８で示したシステムとともに使用される。たとえば、ディスプレイは、ＣＲＴ、ＬＣＤ、ガスプラズマ・ディスプレイ、符号化されたテレビジョン・ビデオを備えたＮＴＳＣデバイスまたはＰＡＬデバイス、デジタル・マイクロミラー・ディスプレイ、投影ディスプレイ、または任意の他の適切な表示デバイスまたは一群の表示デバイスである。
【００７７】
図９は、複数の表示データ・ストリーム間で表示情報出力パイプラインを共用する方法の一実施形態を示している。９０１で、表示情報を求める要求が、要求側のチャネルの実際のニーズに基づいて１つまたは複数のチャネルによってアサートされる。この要求は、フレーム・バッファの中、またはピクセル・バッファの中の表示情報を求めるものである。したがって、一実施形態では、チャネルは、そのチャネルが垂直帰線消去期間を終える間近になったときに要求をアサートすることを始め、そのチャネルの次の垂直帰線消去期間が始まる間近になるまで要求をアサートすることを続ける。別の実施形態では、チャネルは、そのチャネルに関する表示情報待ち行列のレベルがあるしきい値を下回って低下したときに要求をアサートすることを始める。たとえば、チャネルは、表示出力待ち行列のレベルが満杯の半分を下回って低下した場合に要求をアサートする。
【００７８】
９０３で、転送されるべき要求が存在するとすれば、どれが転送されるべきかについての判定が行われる。たとえば、一実施形態では、要求は、各チャネルの表示情報待ち行列内のデータのレベルに基づいて仲裁される（図１０Ａ参照）。別法として、チャネルの要求は、どのチャネルの要求が最新でサービスを受けており、どのチャネルに表示情報が用意されているかに基づいて仲裁される（図１０Ｂ参照）。
【００７９】
次に、選択された要求が、９０５で示すとおり、デバイス（たとえば、フレーム・バッファまたはピクセル・バッファ）に転送され、これに応答して、デバイスは、９０７で示すとおり、表示情報を要求側のディスプレイ・チャネルに出力する。
【００８０】
図１０Ａは、複数の表示データ・ストリーム間で表示情報出力パイプラインを共用する方法の別の実施形態を示している。この方法は、図８のアービタ８０５のようなアービタによって使用される方法に対応する。この実施形態では、１００１で、ディスプレイ・チャネルの１つまたは複数が、そのチャネルの実際のデマンドに基づいて要求をアサートする。１つの要求だけが発行された場合、要求側のチャネルの表示情報待ち行列（たとえば、ピクセル・ブロック待ち行列または表示出力待ち行列）のレベルがしきい値レベルと比較され、そのレベルがしきい値を下回っている場合、その要求が転送される。このしきい値レベルは、出力パイプラインにおける待ち時間にも関わらず、各チャネルが表示情報を必要に応じて確実に受け取るように選択される。レベルがしきい値を下回っていない場合、要求は転送されない。
【００８１】
１００３および１００９で示されるように複数の要求がアサートされた場合、要求側チャネルの表示情報待ち行列（たとえば、ブロック待ち行列またはピクセル待ち行列、または表示出力待ち行列）のレベルが、しきい値レベルと比較される（ただし、一部の実施形態では、異なるチャネルは、異なるしきい値レベルを有する）。要求側チャネルの表示情報待ち行列のレベルのどれもしきい値を下回っていない場合、１００９で、要求のどれも転送されない。１つだけの要求側チャネルのレベルがしきい値を下回っている場合、１０１１で示されるとおり、そのチャネルの要求が転送される。いくつかの要求側チャネルのレベルがしきい値を下回っている場合、１０１５で示すとおり、それらのチャネルの不足分（各チャネルの表示情報待ち行列の実際のレベルとしきい値レベルの差の大きさ）が比較され、最大の不足分を有するチャネルからの要求が転送される。要求が転送されたことに応答して、表示情報を要求されたデバイス（たとえば、フレーム・バッファまたはピクセル・バッファ）が、情報を要求側チャネルに出力する。
【００８２】
図１０Ｂは、複数のチャネル間で表示情報出力パイプラインを共用する方法の代替の実施形態を示している。この方法は、図８のアービタ８１７のようなアービタによって使用される方法に対応する。この実施形態では、ディスプレイ・チャネルの１つまたは複数が、１０５１で表示情報の要求をアサートする。１つの要求だけがアサートされた場合、１０５５で示すとおり、要求側チャネルに対して用意された表示情報が存在するかどうかについての判定が行われる。１０５７で、表示情報が用意されている場合、要求側チャネルの要求が転送される。
【００８３】
複数のチャネルが要求をアサートした場合、１０６３で、最も長い間サービスを受けていないチャネルが特定され、そのチャネルに対して表示情報が用意されている場合、１０６７で、その最も長い間サービスを受けていないチャネルの要求が転送される。最も長い間サービスを受けていないチャネルに対して情報が用意されていない場合、１０６９で示すとおり、次に長い間サービスを受けていないチャネルの要求が代わりに転送される。
【００８４】
要求がデバイス（たとえば、フレーム・バッファまたはピクセル・バッファ）に転送されると、１０７１で、受取り側デバイスは、表示情報を要求側チャネルに出力することができる。
【００８５】
ビデオ・コントローラ帯域幅
図８を再び参照すると、フレーム・バッファ２２を共用している場合に生じる１つの問題は、ある状況では、各チャネルの表示情報要求間で切替えを行う際に多大な帯域幅が犠牲にされることである。たとえば、帯域幅のこの損失は、フレーム・バッファ２２内部の表示情報にアクセスする際にチャネル間で切替えを行うのに使用される様々なセットアップ手続きに起因して生じる。
【００８６】
一部の実施形態では、フレーム・バッファは、三菱によって製造されているようないくつかの３Ｄ−ＲＡＭを含む。図１１Ａは、フレーム・バッファ２２のそのような実施形態の一例を示している。この実施形態では、フレーム・バッファ２２は、４つの３Ｄ−ＲＡＭ９１２を含む。他の実施形態は、４つより多い、または４つより少ない３Ｄ−ＲＡＭを含むことが可能であることに留意されたい。
【００８７】
図１１Ｂは、個体の３Ｄ−ＲＡＭ９１２の一実施形態を示している。３Ｄ−ＲＡＭ９１２は、４つの独立したＤＲＡＭバンク９１４を含む。表示情報が、ＤＲＡＭバンク９１４から内部ピクセル・バッファ９３０に読み込まれる（ピクセル・バッファ９３０は、３Ｄ−ＲＡＭ９１２の内部にあり、図８のピクセル・バッファ８１５と混同してはならない）。内部ＡＬＵ（算術論理ユニット）９２４が、ピクセル・バッファの中に記憶されたデータを変更する。データに変更が行われている間、追加のデータがピクセル・バッファ９３０に書き込まれる。３Ｄ−ＲＡＭにより、ピクセル・データが、ピクセル・バッファから読み取られながら変更されるので（すなわち、チップ外にデータを出力する必要なく）、Ｚバッファ・オペレーションやピクセル混合オペレーションなどのオペレーションをより効率的に行うことができる。たとえば、そのようなオペレーションが、「読取り−変更−書込み」として行われる代わりに、「大部分は書込み」としてより効率的に行われることが可能である。
【００８８】
表示情報のバーストをビデオ出力コントローラに提供する際、ＤＲＡＭの奇数バンクが、表示情報を第１のＳＡＭビデオ・バッファ９１６Ａに出力し、偶数バンクは、表示情報を第２のＳＡＭビデオ・バッファ９１６Ｂに出力する。各ビデオ・バッファ９１６は、単一回のオペレーションでロードされる。この構成のため、表示情報は、第２のＳＡＭ９１６Ｂに書き込まれながら、第１のＳＡＭ９１６Ａから読み取られ、その逆も可能である。一方のＳＡＭにロードが行われることが、他方のＳＡＭが表示情報を出力しながら可能であるので、３Ｄ−ＲＡＭ９１２は、引き続く表示情報要求が３Ｄ−ＲＡＭ９１２内の偶数バンクと奇数バンクを交互に目標とする場合、表示情報の比較的連続したバーストを出力することができる。
【００８９】
偶数（ＳＡＭＩＩ９１６Ｂ）ＳＡＭおよび奇数（ＳＡＭＩ９１６Ａ）ＳＡＭは、偶数ＤＲＡＭバンク９１４および奇数ＤＲＡＭバンク９１４に対応する。通常、フレーム・バッファ２２は、表示情報が偶数バンクと奇数バンクの間で交替することによって読み出される場合、最適な出力帯域幅を実現することができる。たとえば、バンク１、バンク２、バンク３、そしてバンク４の順に表示情報が要求された場合、バンク１からの表示情報は、バンク１および３からのデータをバッファに入れる「奇数」ＳＡＭにロードされる。次に、バンク１からの要求されたデータが奇数ＳＡＭから読み出されることが、バンク２からのデータが「偶数」ＳＡＭに書き込まれながら行われる。奇数ＳＡＭからの読取りの後、バンク３内の要求されたデータが奇数ＳＡＭに書き込まれながら、バンク２からのデータが偶数ＳＡＭから読み出される。偶数バンクと奇数バンクの間で交替することにより、フレーム・バッファは、最大の帯域幅を維持することができる。というのは、他方のＳＡＭがデータのバーストを提供している間に、それぞれのＳＡＭが再充填されることが可能だからである。一方のＳＡＭにデータが充填されることが、他方のＳＡＭからデータが排出されながら間に合うように要求が受信された場合、ほぼ連続したバーストが提供される。たとえば、ＳＡＭを充填するのに８フレーム・バッファ・サイクルを要し、ＳＡＭからビデオ出力コントローラにデータのバーストを提供するのに４０フレーム・バッファ・サイクルを要する場合、一方のＳＡＭに関する８充填サイクルを他方のＳＡＭの４０出力サイクル内に「隠す」ことができる。
【００９０】
フレーム・バッファ内の３Ｄ−ＲＡＭはインターリーブされるため、バースト要求を満たすことには、各３Ｄ−ＲＡＭからバーストを受け取ることが関与する可能性がある。たとえば、図１１Ａに戻ると、３Ｄ−ＲＡＭのそれぞれの中のＳＡＭの１つが２０ピクセルを記憶することができる場合、４＊２０ピクセル（各３Ｄ−ＲＡＭ９１６から２０ピクセル）のバーストが、フレーム・バッファ２２によって提供される。要求側ディスプレイが１２８０×１０２４のＣＲＴである場合、８０ピクセルの１６のバーストがそれぞれ、各走査線に必要とされる１２８０ピクセルを提供する。
【００９１】
各３Ｄ−ＲＡＭが一方のＳＡＭの充填サイクルを他方のＳＡＭの読取りサイクル内に隠すことができる能力の恩恵を受けるため、フレーム・バッファ内の表示情報は、ディスプレイ・チャネルにおけるデータの連続するバースト要求が、各３Ｄ−ＲＡＭの中の偶数バンクと奇数バンクを目標とすることを交替で行われるように記憶される。たとえば、表示情報のバーストの第１の要求が、３Ｄ−ＲＡＭ９１２のそれぞれの中のバンク１を目標とする。次の要求は、各３Ｄ−ＲＡＭ９１２の中のバンク２を目標とする。表示情報がフレーム・バッファ内でこのように配列されてない場合、２回の連続する偶数（奇数）要求が生じる。その結果、充填サイクルを隠すことがもはやできない。たとえば、２つの連続する要求が同一のペアのバンクを目標とした場合、ビデオ・バッファは、自らが第１のバーストを出力しているサイクル中、第２のバーストを提供するように再充填されない。代わりに、ビデオ・バッファは、第２のバーストで再充填が開始される前に第１のバーストを完全に出力する。その結果、表示情報のこの第２のバーストを提供するのにさらなるサイクルを要する。以上が示すとおり、偶数バンクまたは奇数バンクに対する引続きの要求により、有効帯域幅が低下する。というのは、ＳＡＭが再充填されているフレーム・バッファ・サイクル中、そのフレーム・バッファから表示情報を全く提供することができないからである。
【００９２】
単一でないより多くのディスプレイ・チャネルに関してデータがフレーム・バッファの中に記憶される場合、様々なチャネルに関する結合された要求ストリームにより、３Ｄ−ＲＡＭの中の偶数（または奇数）バンクに対する引続きの要求がもたらされる状況が生じる。たとえば、各チャネルは、フレーム・バッファ内の各３Ｄ−ＲＡＭの偶数バンクと奇数バンクからデータを交互に要求することにより、データを要求するものと想定する。この結果、各チャネルは、個別に考慮した場合、フレーム・バッファからのデータを効率的に要求する。表記「Ｅ」または「ｅ」が、偶数バンクからのデータの要求を表わし、「Ｏ」または「ｏ」が、奇数バンクからのデータの要求を表わす。チャネルＡの要求ストリームが大文字で表わされ、チャネルＢの要求ストリームが小文字で表わされる。チャネルＡの要求ストリームは、ＥＯＥＯＥＯＥＯＥＯである。同様に、チャネルＢの要求ストリームは、ｅｏｅｏｅｏｅｏｅｏである。チャネルＡがチャネルＢより３倍速い場合、ニーズ・ベースのアービタ（図８に示した）が、両チャネルの要求をＥＯＥｅＯＥＯｏＥＯＥｅＯＥＯｏの順で転送することができる。前述したとおり、２つの偶数（または２つの奇数）要求が続いて生じる場合はいつでも、フレーム・バッファは、交互する偶数−奇数の要求を処理できるのと同じぐらい迅速にはその要求を処理できない。代わりに、フレーム・バッファは、一方のＳＡＭが完全に排出されてからでないと、繰り返される偶数（または奇数）要求を満足させることにとりかかれない。したがって、非効率なアクセスが生じるポイントを表わすのに「Ｘ」を使用すると、要求ストリームＥＯＥｅＯＥＯｏＥＯＥｅＯＥＯｏに対するフレーム・バッファの応答は、ＥＯＥ  Ｘ  ｅＯＥＯ  Ｘ  ｏＥＯＥ  Ｘ  ｅＯＥＯ  Ｘ  ｏである。
【００９３】
この例は、アービタが、チャネルＢからのＮ個の要求ごとにチャネルＡからの１つの要求を転送する（たとえば、チャネルＢが、チャネルＡよりＮ倍速いために）状況に対して一般化される。Ｎ＋１個の要求ごとに１回、帯域幅の低下が生じるため、Ｎが増加するにつれ、チャネルの要求間で切替えを行う際に損失される帯域幅がより少なくなる。反対に、Ｎが減少するにつれ、帯域幅損失はより大きくなる。たとえば、２つのチャネルがほぼ同じレートでデータを要求している場合、ニーズ・ベースのアービタによって転送される結果の要求ストリームは、ＥｅＯｏＥｅＯｏＥｅＯｏである。この状況では、２つの要求ごとに１回といったほど頻繁に帯域幅の低下が生じる。
【００９４】
チャネルを切り換える際に帯域幅の損失を最小限に抑えるため、アービタ８０５は、アービタがフレーム・バッファ２２に送る要求がより着実に偶数要求と奇数要求の間で交替するよう、要求ストリーム間で仲裁を行うことができる。個々の要求ストリームがそれぞれ、偶数要求と奇数要求の間で交替する場合、帯域幅を増大させる１つのやり方は、１つのチャネルからいくつかの数の連続する要求を転送してから、別のチャネルの要求に進むことである。たとえば、一実施形態では、アービタ８０５は、アービタが１つのチャネルから少なくとも２つの連続する要求（偶数に続いて奇数、または奇数に続いて偶数）を転送してから、別のチャネルの要求を転送する「ロックステップ」モードを有する。たとえば、アービタ８０５が、チャネルのブロック待ち行列内の有効なブロックの数に基づいてどのチャネルが最も高いニーズを有するかを判定するように構成されている場合、次の「ニーズの高さ」の比較は、２つの連続する要求が現在の最も高いニーズを有するチャネルから転送されるまで、行われない。
【００９５】
ロックステップ・モードを使用することにより、アービタは、Ｎの小さい値に関して生じる可能性がある極端な帯域幅損失を防止することができる。たとえば、Ｎ＝１である場合、ロックステップ・アービタは、要求ストリームＥＯｅｏＥＯｅｏＥＯｅｏを（ロックステップではないアービタによって転送される要求ストリームＥｅＯｏＥｅＯｏＥｅＯｏの代わりに）転送する。したがって、偶数要求と奇数要求の間で交替するように転送される要求ストリームを構成することにより、ロックステップ・アービタは、２つの要求ストリームに関する損失帯域幅を低減することができる。この結果、ロックステップ・モードにより、複数のディスプレイ・チャネル間でフレーム・バッファを共用することによって生じさせられる非効率が抑えられる。
【００９６】
チャネルはプリフェッチを行うので、チャネルのリクエスタが、ロックステップ機構によってもたらされる追加の遅延を考慮に入れる限り、ロックステップ・モードを使用することにより、いずれのチャネルもデータに「貧窮する」ことが生じない。したがって、卸売りループ内の要求が、サービスを受ける別のチャネルからの連続する２つの要求を待たなければならないときに発生する遅延を考慮するために、はるか前にデータをプリフェッチするように、各要求を構成する。
【００９７】
したがって、チャネルＡがチャネルＢより３倍速かった前述の例に戻ると、要求アービタが、前述した要求ストリームＥＯＥｅＯＥＯｏＥＯＥｅＯＥＯｏを受け取る。アービタは、ロックステップ・モードになっている場合、要求ストリームＥＯＥＯｅｏＥＯＥＯＥＯｅｏＥＯをフレーム・バッファに転送する。要求をこのように構造化しなおすことにより、フレーム・バッファからデータを読み取る際の非効率を抑えることができる。
【００９８】
一部の実施形態では、アービタは、チャネルのデータ速度が非常に似通っており、フレーム・バッファからデータが出力される速度がかなり影響を受ける場合にだけロックステップ・モードに入るように構成されている。したがって、チャネルが比較的多様なデータ速度を有する場合、フレーム・バッファのパフォーマンスに対する時々の競合の効果は些細である可能性があり、アービタはロックステップ・モードに入らない可能性がある。データ速度がより似通っており、したがって、競合がより頻繁に生じ、帯域幅に対してより顕著な影響を与える可能性がある場合、アービタは、ロックステップ・モードに入る。
【００９９】
一実施形態では、ロックステップ・モードで動作するように構成されたアービタは、チャネルのディスプレイが同一の解像度を有し、かつ／またはチャネルが同一のピクセル・クロック速度、および線当たりのバーストの数を有する場合、より良好なパフォーマンスを見せることが可能である。そのような実施形態では、チャネルのタイミング生成器が同時に開始する場合も、パフォーマンスが向上する。
【０１００】
前述の例は、３Ｄ−ＲＡＭデバイスを含む実施形態に関連するが、多くの他の状況でも帯域幅の低下に関する同様の懸念が生じる可能性がある。一般に、同一のメモリ・デバイス、またはメモリ・デバイスの同一の部分（たとえば、バンク、インターリーブ等）に対する繰り返しのアクセスによってパフォーマンスの低下が生じさせられる場合、ロックステップ・モードを実施すること、または別の仕方で同一のデバイス、またはデバイスの同一の部分に対する連続するアクセスの回数を制限することが望ましい。
【０１０１】
図１２Ａは、複数のメモリ・デバイス（たとえば、メモリ、メモリ・バンク、シリアル・アクセス・メモリ、バッファ）の中のデータにアクセスする複数のソースの要求の間で仲裁を行う方法の一実施形態を示している。一般に、この方法は、連続する要求が同一のメモリ・デバイスにアクセスする場合にはいつでも生じる非効率を抑えることができる。仲裁は、複数のメモリ・デバイスに転送される連続する要求が、データに関する各ソースの相対ニーズに基づいて仲裁が行われた場合、または仲裁が全く行われない場合よりも頻繁に異なるメモリ・デバイスにアクセスする傾向になるように行われる。
【０１０２】
ステップ１２０１で、要求１をソースＡで受け取る。要求１は、複数のメモリ・デバイスの第１のグループからのデータを要求する。第１のグループは単一のメモリ・デバイスである。たとえば、複数のメモリ・デバイスは、フレーム・バッファ内部に含まれるシリアル・アクセス・メモリであり、また要求１は、第１のシリアル・アクセス・メモリから出力される表示情報を要求する。最新の転送された要求が第１のグループ以外のグループを目標としていた場合、１２０３〜１２０５に示すとおり、要求１が転送される。そうではなく、複数のメモリ・デバイスに転送された最新の要求もメモリ・デバイスの第１のグループを目標としていた場合、１２０３〜１２０７に示すとおり、第１のグループ以外のグループを目標とする別のソースの要求が、要求１が転送される前に転送される。このようにすると、連続する要求は、同一グループのメモリ・デバイスにアクセスしないようになり、同一グループのデバイスに対する連続するアクセスに起因して生じるあらゆるパフォーマンスの低下を回避することができる。
【０１０３】
最新の転送された要求が第１のグループのメモリ・デバイスを目標としており、待ち状態の要求のすべてが第１のグループを目標としている場合、図１２に示した仲裁方法に対する１つの例外が生じることがある。この場合、要求のすべてが第１のグループに対する連続するアクセスを生じさせるため、要求のいずれか１つを転送することができる（たとえば、ニーズ・ベースの仲裁に基づいて）。
【０１０４】
図１２Ｂは、フレーム・バッファからの表示情報を求める複数のディスプレイ・チャネルの要求間で仲裁を行う方法の別の実施形態を示している。フレーム・バッファは、フレーム・バッファに送られる連続する要求が、第１のグループのメモリ・バンク（たとえば、第１のシリアル・アクセス・メモリ（ＳＡＭ）にデータを出力するペアのバンク）からのデータの要求と、第２のグループのメモリ・バンク（たとえば、第２のＳＡＭにデータを出力するペアのバンク）からのデータの要求を交互に行う場合、より効率的にデータを出力することができる。交替する要求を受けた場合にフレーム・バッファの効率がより高いことを活用するため、この方法には、複数のディスプレイ・チャネルの要求ストリーム間で仲裁を行うことが関与する。仲裁は、フレーム・バッファによって受け取られる要求が、第１のグループからの表示情報を求める要求と、第２のグループからの表示情報を求める要求の間で交替するように行われる。好ましくは、要求は、各ディスプレイ・チャネルの相対的なニーズの高さだけに基づいて仲裁が行われた場合よりも頻繁に交替する。
【０１０５】
簡明にするため、この方法を第１のディスプレイ・チャネル、チャネルＡ、および１つまたは複数の他のチャネルに関連して説明する。ステップ１２２１で、グループ１を目標とする第１の要求をチャネルＡから受け取る。フレーム・バッファに転送された最新の要求がグループ２を目標としていた場合、１２２５で示すとおり、第１の要求がフレーム・バッファに転送される。これに対して、最新の要求がグループ１を目標としていた場合、１２２７で示すとおり、要求１は、グループ２を目標とする異なるチャネルにおける要求が転送されるまで、転送されない。ディスプレイ・チャネルの要求のすべてがグループ１を目標としている場合、１つの例外が生じる。この場合、要求のすべてが非効率であり（すなわち、同一のグループのメモリ・バンクに対する連続するアクセスが関与する）、したがって、要求のいずれか１つを転送することができる。たとえば、アービタは、待ち状態の要求のすべてがグループ１を目標としている場合、最も高いニーズの要求（たとえば、最も長い間サービスを受けていないチャネル、または待ち行列内のデータのレベルが最も低いチャネル）を選択するように構成されている。
【０１０６】
一部の実施形態では、アービタに提示される要求自体は、どのグループのメモリ・バンクを目標としているかを示さない。代わりに、この情報が、各ディスプレイ・チャネルのアドレス生成器によって保持され、アドレス生成器が、ディスプレイ・チャネルに表示情報の次のバーストがそこから提供されるべきフレーム・バッファのアドレスを把握している。一部の実施形態では、このアドレス情報をアービタは利用できない。代わりに、アービタは、どのチャネルに特定の要求が対応するかを知ることができる（たとえば、要求の中のタグに基づいて、またはアービタの入力部のどれが要求を受け取ったかに基づいて）。各チャネルにおける要求が特定の順序に準拠している場合（たとえば、要求がそれぞれ、同一グループ（偶数または奇数）のバンクから要求を開始して、同一パターンでグループ間で交替する）、アービタは、要求がどのチャネルに属するかに基づいて要求間で仲裁を行うことができる。
【０１０７】
図１２Ｃは、どのチャネルが各要求をアサートしたか、およびアサートを行うチャネルの相対的なニーズの高さに基づいて表示情報の要求間で仲裁を行う方法の別の実施形態を示している。各チャネルは、各チャネルの要求がサービスを受けることができる効率を高めるため、あるグループのメモリ・バンクからの表示情報を求める要求と、別のグループのメモリ・バンクからの表示情報を求める要求を交互に行う要求をアサートすることができる（たとえば、３Ｄ−ＲＡＭが使用されている場合、表示情報を提供するＳＡＭを交替して）。この実施形態では、表示情報の要求は、表示情報に対する各ディスプレイ・チャネルのデマンドに基づいて各チャネルに関してアサートされる。たとえば、表示情報を求めるチャネルの要求は、チャネルが帰線消去期間ではない期間中にある間にアサートされる。
【０１０８】
アサートされる要求のどれをフレーム・バッファに転送するかを判定するため、２つの連続する要求が既に同一チャネルから転送されたかどうかについての判定を行う（１２５３で）。２つの連続する要求が転送されている場合、要求をアサートしたディスプレイ・チャネルの相対的なニーズの高さが判定される。たとえば、それぞれの要求側チャネルの表示情報待ち行列内の表示情報のレベルがしきい値レベルと比較される。ニーズの高さの判定の結果に基づき、図１０Ａに関して述べたとおり、要求をフレーム・バッファに転送することができる。
【０１０９】
これに対して、２つの連続する要求がフレーム・バッファにまだ転送されていない場合、ニーズの高さの判定は行われない。代わりに、１２６７に示すとおり、要求が最新で転送されたチャネルからの第２の要求がフレーム・バッファに転送される。このようにして、フレーム・バッファに転送される要求が、２つのグループのメモリ・バンクのそれぞれからの表示情報を求める要求の間で交替して、ディスプレイ・チャネルに表示情報が提供される効率が高まる。この実施形態では、ディスプレイ・チャネルがそれぞれ、各線で同じ数のバーストを要求した場合、より高いパフォーマンスを実現できることに留意されたい。
【０１１０】
フレーム・バッファ編成およびピクセルの並べ替え
一般に、フレーム・バッファは、データをフレーム・バッファにより高い効率で書き込む仕方で編成することができる。したがって、図３を再び参照すると、フレーム・バッファ２２は、ハードウェア・アクセラレータ１８がレンダリングするデータをより高い効率で読取り、かつ／またはフレーム・バッファ２２に書き込むことができるように構成されている。
【０１１１】
レンダリング構成要素のアクセスを益するためにフレーム・バッファを編成することの１つの帰結は、この編成により、表示情報が出力プロセッサに提供される仕方が複雑になることである。たとえば、出力プロセッサは、表示のために表示情報が表示デバイスに提供されるべき順序に照らして順序が乱れている表示情報を受け取る。その結果、出力プロセッサは、フレーム・バッファから自らが受け取る表示情報を並べ替えてから、そのデータを表示デバイスに転送するように構成されている。
【０１１２】
一部の実施形態では、出力プロセッサは、フレーム・バッファから出力された表示情報を表示デバイスに出力するための適切な順序に並べ替える論理を含む。一実施形態では、並べ替え論理は、フレーム・バッファとピクセル・バッファの間に配置される。
【０１１３】
並べ替え論理を使用していくつかの異なる並べ替え方法を実施することができる。たとえば、フレーム・バッファからデータがバーストで提供される場合、ピクセル・バッファは、完全なバーストを記憶するだけ十分に大きい少なくとも１つのブロックが各ディスプレイ・チャネルに割り振られるように区分化する。バーストが受け取られると、そのバースト内のピクセルが並べ替えられ、そのバーストを要求したディスプレイ・チャネルに専用のブロック内に表示順で入れられる。次に、ピクセルが、記憶されている順序で要求側ディスプレイ・チャネルに対応するブロックから読み出される。ブロックは順序が整い、各ブロック内のピクセルも順序が整っているので、ピクセルを表示順に読み出すことができる。
【０１１４】
一実施形態では、フレーム・バッファは複数の３Ｄ−ＲＡＭを含む。各インターリーブが各バーストで２０ピクセルを提供する。したがって、フレーム・バッファが８つの３Ｄ−ＲＡＭを含む場合、バースト内に１６０のピクセルが存在する。ピクセルがインターリーブ当たりで、トランザクション当たり１ピクセルの速度で提供された場合、フレーム・バッファから完全なバーストを受け取るのに２０トランザクションを要する。各トランザクションにおいて、８ピクセルが受け取られる。
【０１１５】
ピクセルの表示順は、ハードウェア・アクセラレータがデータをどのようにレンダリングしてフレーム・バッファに書き込むかに基づいて決まる。各フレーム・バッファおよび／またはハードウェア・アクセラレータの構成は、異なる順序でピクセルを記憶するが、多くの実施形態では、適切な表示順は、フレーム・バッファからピクセルが受け取られた順序、およびピクセルを記憶していたフレーム・バッファ内の位置に関する公式として表現することができる。これらのパラメータは出力プロセッサが利用できるので、出力プロセッサは、フレーム・バッファによって出力されたピクセルを適切な表示順に並べ替えるように構成されている。
【０１１６】
たとえば、一実施形態では、ピクセルの表示順は、表２に示すとおり、各ピクセルが受け取られたトランザクション、各ピクセルが記憶されるアドレス、および各ピクセルが記憶されているインターリーブに基づき、各ピクセルが受け取られるにつれて判定される。Ｎは、トランザクション番号（２０のトランザクションが完全なバーストを提供するものと想定して、０ないし１９）に等しい。所与のピクセルの表示順Ｚは、以下の公式によって判定される。
（１）    Ｚ（Ｎ）＝（１６＊（Ｎ／４））＋（２＊（Ｎ％４））
ただし、「／」は、整数除算を示し、「％」は、整数の法を示す。
【０１１７】
【表２】
2004536388.tif 000004
【０１１８】
したがって、４つのインターリーブの構成における偶数アドレスの付いた線に関して、バースト内の８０ピクセルがフレーム・バッファから順序０、１、４０、４１（トランザクション０）、２、３、４２、４３（トランザクション１）、４、５、４４、４５（トランザクション２）、．．．３８、３９、７８、７９（トランザクション１９）で提供される。奇数線の場合、インターリーブ０および１（または、８つのインターリーブが存在する場合、０、１、２、３）が、インターリーブ４および５（または、８つのインターリーブが存在する場合、４、５、６、７）とスワップされ、したがって、ピクセルは、順序４０、４１、０、１といった具合に４つのインターリーブを有するフレーム・バッファから提供される。したがって、どのトランザクションでピクセルを受け取ったか、どのインターリーブからピクセルが受け取られたか、またピクセルがフレーム・バッファ内の偶数アドレスに記憶されていたか、または奇数アドレスに記憶されていたかに基づき、ピクセルの表示順を判定することができる。以上の公式は、単に例示的であり、他のフレーム・バッファ／ハードウェア・アクセラレータの構成は、異なる公式によって記述することができる順序でピクセルを記憶できることに留意されたい。
【０１１９】
図１３は、ピクセル書込みコントローラ９５４の一実施形態を示している。ピクセル書込みコントローラ９５４は、フレーム・バッファ２２から出力された１６０ピクセルを逆多重化して８０のピクセルのペアにするように構成されている。次に、これらのピクセルのペアは、ピクセル・バッファ８１５の現在のバーストを要求したディスプレイ・チャネルに対応する部分の中に記憶することができる。ピクセル・バッファ８１５内のブロックの中に適切な表示順でピクセルを記憶するため、各ディスプレイ・チャネルは、関連する書込みアドレス生成器９６０を有する。
【０１２０】
図１４は、書込みアドレス生成器９６０の一実施形態を示している。書込みアドレス生成器９６０は、各ピクセルがフレーム・バッファ２２から受け取られるにつれ、各ピクセルに関してピクセル・バッファ８１５内のアドレスを計算することができる。この実施形態では、ピクセル・バッファ８１５は、１６０ピクセルのブロックに分割することができる（８つのインターリーブのフレーム・バッファ構成の場合）。したがって、一実施形態では、ピクセルの完全なバーストが、単一のブロック内に入り、単一のブロックは、２０のトランザクションの後にいっぱいになる。各ブロックは、ピクセルをピクセルのペアとして記憶するように構成されており、したがって、１６０ピクセルのブロックが８０のピクセル・ペアを記憶する。各ピクセルが４０ビットである場合、各ピクセル・ペアは、単一の８０ビット線の一部として一緒にピクセル・バッファの中に記憶される。
【０１２１】
書込みアドレス生成器９６０は、各ピクセル・ペアに関して現在、埋められているブロック内のアドレスを生成する。したがって、書込みアドレス生成器９６０の出力はピクセル・バッファ書込みアドレスである。ピクセル・バッファ書込みアドレスは、現在のブロックの基底アドレスをそのブロック内のオフセットに加算することによって生成される。
【０１２２】
現在のブロックの基底アドレスは基底アドレス状態マシン９６４によって生成される。基底アドレス状態マシン９６４は、ピクセル・バッファ８１５内の可用な基底アドレスを巡回するように構成されている。たとえば、第１のディスプレイ・チャネルに専用のピクセル・バッファの部分が４８０のピクセル・ペア（９６０ピクセル）を記憶するように構成されている場合、基底アドレス状態マシン９６４は、表３に示した順序で基底アドレスを巡回するように構成されている。表３は、４つのインターリーブの実施形態と８つのインターリーブの実施形態の両方に関する値を示していることに留意されたい。
【０１２３】
【表３】
2004536388.tif 000005
【０１２４】
表３が示すとおり、この実施形態では、４つの３Ｄ−ＲＡＭが存在する場合、４０ずつ（各ブロック内の４０のピクセル・ペアに対応して）、また８つの３Ｄ−ＲＡＭが存在する場合、８０ずつ連続する基底アドレスが増分される。状態マシンは、ピクセル・バッファの中に完全なバーストが記憶されるたびに毎回、次の基底アドレスに巡回する。たとえば、基底アドレス状態マシン９６４は、フレーム・バッファがバースト要求の受領を確認したときはいつでも、状態を変更するように構成されている。ピクセル・バッファ内の最終ブロック（それぞれ、４つのインターリーブの構成の場合、４４０〜４７９から、または８つのインターリーブの構成の場合、４００〜４７９からの）が充填されると、基底アドレス状態マシンは、巡回してアドレス０に戻り、したがって、次のバーストがピクセル・バッファ内の最初のブロックを埋める。
【０１２５】
オフセット（オフセット生成器状態マシン９６２によって生成された）をトランザクション・カウンタ９６６からの出力と連結することにより、オフセット・アドレスを計算することができる。トランザクション・カウンタ９６６は、トランザクションを完了するのに要するサイクル数をカウントする。たとえば、各トランザクションを完了するのに４サイクルを要する場合、トランザクション・カウンタ９６６は、０から３までをカウントすることができる。トランザクション・カウンタ９６６は、最終トランザクションがまだ完了していないと想定すると、３に達した後、リセットされ、再び０からカウントすることを続けるように構成されている。
【０１２６】
オフセット生成器状態マシン９６２は、オフセット状態マシン９６２の現在の状態に基づいてオフセット・アドレスのビット６：３を生成することができる。オフセット状態マシン９６２は、毎トランザクション後（たとえば、トランザクション・カウンタ９６６が３に達したとき）、状態を変更するように構成されている。各状態で、オフセット生成器状態マシン９６２は、表４に示すとおり、２つのオフセットを出力することができる。現在のピクセル・ペアがフレーム・バッファ２２内の偶数のアドレスのラインから受け取られたか、または奇数のアドレスのラインから受け取られたかに基づき、マルチプレクサ９６８が現在のピクセル・ペアに関する正しいオフセットを選択する。オフセットは、４つのインターリーブのケースでは７ビットであることが可能であるが、８つのインターリーブが存在する場合、６ビットだけであることに留意されたい。この第７番のビットは、制御ビット「Ｘ」と呼ぶことができる。
【０１２７】
【表４】
2004536388.tif 000006
【０１２８】
したがって、各トランザクションに関して、２つ（または、４つではなく８つのインターリーブが存在する場合、４つ）の連続するピクセル・ペアに関するアドレスが計算される。表５は、第１のトランザクションにおけるピクセル・ペアに関するアドレスを計算するのに使用することができるオフセットおよびＸ値を示しており、これは、この実施形態では、フレーム・バッファで偶数でアドレスされた線を含む。奇数アドレスの場合、サイクル２中およびサイクル３中に行われるオペレーションは、サイクル０および１と交換されることに留意されたい。
【０１２９】
【表５】
2004536388.tif 000007
【０１３０】
前述の例は、特定の実施形態に関連しているが、多くの他の実施形態も可能であることに留意されたい。たとえば、別の実施形態では、各チャネルのバーストが、統合されたピクセル・バッファ（様々なディスプレイ・チャネルの間で区分化されたピクセル・バッファでなく）の中にランダムに入れられたいくつかのブロックに細分される。これらのブロックのサイズは、フレーム・バッファのインターリーブ構成に応じて様々である。たとえば、フレーム・バッファが４つのインターリーブを含む場合、各ブロックは、８ピクセル（または４つのピクセル・ペア）を保持する。フレーム・バッファが８つのインターリーブを含む場合、各ブロックは、１６ピクセル（または８つのピクセル・ペア）を保持する。いずれの構成でも、フレーム・バッファからの完全なバーストを記憶するのに１０ブロックを要する。
【０１３１】
ピクセルは、前述したのと同様の書込みアドレス生成器を使用して各ブロック内に表示順に記憶される。一実施形態では、ブロックの２つが同時に充填される。たとえば、フレーム・バッファ内に４つのインターリーブが存在する場合、４ピクセルが第１のトランザクションにおいて受け取られる（たとえば、表示順０、１、４０、４１を有するピクセル）。この第１のトランザクション中に１つのピクセル・ペア（たとえば、０、１）が１つのブロックの中に記憶され、別のピクセル・ペア（たとえば、４０、４１）が他のブロックの中に記憶される。この実施形態では、ブロックがそれぞれ、４つのピクセル・ペアを保持する場合、両方のブロックが、４つのトランザクションの後にいっぱいになる。したがって、第１のトランザクションの後、第１のブロックは、表示順０〜３を有するピクセルを記憶し、他方、第２のブロックは、表示順４０〜４３を有するピクセルを記憶する。同様に、フレーム・バッファが８つのインターリーブを有し、ブロックがそれぞれ、８つのピクセル・ペアを保持する場合、それぞれ８つのピクセル・ペアで２つのブロックを埋めるのにやはり４つのトランザクションを要する。この実施形態では、同じ書込みアドレス生成器状態マシンを４つのインターリーブのフレーム・バッファ構成と８つのインターリーブのフレーム・バッファ構成の両方に関して使用する。この構成は、拡張すること、または縮小することに留意されたい（たとえば、１６のインターリーブのフレーム・バッファと１６のピクセル・ペアのブロックをサポートするように、または２つのインターリーブのフレーム・バッファと２つのピクセル・ペアのブロックをサポートするように）。
【０１３２】
一実施形態では、ブロックを含む統合されたピクセル・バッファは、１０２４ピクセルを記憶することができる。ピクセル・バッファがピクセル・ペアを記憶するように設計されている場合、ピクセル・バッファはそれぞれ２ピクセル幅の５１２のエントリを含む。したがって、各ブロックが４つのピクセル・ペアを記憶する場合（たとえば、フレーム・バッファが４つのインターリーブを有する）、１２８のブロックが存在し、また各ブロックが８つのピクセル・ペアを記憶する場合（たとえば、フレーム・バッファが８つのインターリーブを有する）、６４のブロックが存在する。１２８のブロックが存在する場合、各ブロックは、７ビット・アドレスによって一意的に特定され、また６４のブロックが存在する場合、各ブロックは、６ビット・アドレスによって一意的に特定される。各ブロック内のピクセルは、どのトランザクションにおいてそのピクセルが受け取られたかに基づいて特定される。したがって、図１４の書込みアドレス生成器を参照すると、基底アドレス生成器は、各トランザクション中に充填されるべき２つのブロックの基底アドレスを生成することができ、トランザクション番号を使用して、各ブロック内でピクセルを記憶する場所を特定するオフセットを生成することができる。オフセットを基底アドレスと連結して書込みアドレスを生成することができる。
【０１３３】
ブロックは、充填されると、待ち行列の中に表示順で入れられることが可能である。各トランザクション中、あるブロックは、比較的早期の表示順を有するピクセル（たとえば、８０ピクセルのバーストが受け取られる場合、表示順０〜３９を有するピクセル）で埋められ、別のブロックは、比較的後期の表示順を有するピクセル（たとえば、表示順４０〜７９を有するピクセル）で埋められる。４つのトランザクションごとに、２つのブロックが充填される。したがって、１０のブロックが完全なバーストを記憶する場合、ブロック０および５が（表示順に）、最初の４つのトランザクションの後に充填され、ブロック１および６が、次の４つのトランザクションの後に充填されているといった具合である。各セットのブロックが埋められるにつれ、比較的早期の表示順を有するブロック（たとえば、ブロック０〜４）に対するポインタがプッシュされて待ち行列に入れられる。比較的後期の表示順を有するブロック（たとえば、ブロック５〜１０）に対するポインタは、早期の表示順を有するブロックのすべてがプッシュされて待ち行列に入れられるまで、１組のレジスタの中に表示順で一時的に記憶される。
【０１３４】
データは、各ブロック内で順序が整っており、ブロックは、各待ち行列内で順序が整っているので、ピクセルを適切な表示順で読み出すことができる。たとえば、読取りアドレス生成器が、待ち行列から順にブロック・アドレスを読み取ってブロックにアクセスが行われるべき順序を特定することができる。ブロック・アドレスをカウンタ値（たとえば、カウンタは、各ブロックが４つのピクセル・ペアを記憶する場合、０〜３をカウントし、あるいは各ブロックが８つのピクセル・ペアを記憶する場合、０〜７をカウントする）と連結して各ピクセル・ペアにアクセスすることができる。これらの読取りアドレスを使用して、ピクセルを適切な表示順で読み出すことができる。この実施形態は、異なるディスプレイ・チャネルからのブロックをピクセル・バッファ内で混合させることができるので（ピクセル・バッファが様々なディスプレイ・チャネルの間で区分化されたままにするのではなく）、ピクセル・バッファ・メモリのより効率的な使用を提供することができる。詳細には、この実施形態は、区分化されたピクセル・バッファの実施形態で使用することが可能なよりも小さいピクセル・バッファを使用して実施することができる。
【０１３５】
別の実施形態では、並べ替えは、ピクセル・バッファの出力側で行うことができる。出力側が並べ替えを扱うので、ピクセルのバーストは、フレーム・バッファから受け取られる順序でピクセル・バッファに書き込まれる。読取りアドレス生成器が読取りアドレスを生成するように構成することにより、ピクセルまたはピクセル・ペアをピクセル・バッファから適切な順序で読み出すことができる。読取りアドレスは、上記で書込みアドレスを生成するのに使用したものと同様の公式を使用して（たとえば、違いには、書込みトランザクションに読取りトランザクションを置き換えること等が含まれる）、ピクセルがフレーム・バッファから受け取られた順序に基づいて生成される。
【０１３６】
一部の実施形態では、同じグラフィックス・システムの異なるバージョンが、より大きいフレーム・バッファまたはより小さいフレーム・バッファを提供する。これらの異なるフレーム・バッファ容量は、個々のインターリーブに対してより大きいメモリ・デバイスを選択すること、またはより小さいメモリ・デバイスを選択すること、インターリーブの数を変更すること、あるいはその両方によって提供することができる。フレーム・バッファは、一部の実施形態では、３Ｄ−ＲＡＭ以外のメモリ・デバイスを含む。表示情報がフレーム・バッファから提供される順序は、インターリーブの数、およびハードウェア・アクセラレータおよび／またはフレーム・バッファの構成（たとえば、ハードウェア・アクセラレータがどのようにデータをレンダリングしてフレーム・バッファに書き込むか）を含む多くの要因に依存して、様々である。したがって、各読取りおよび／または書込みアドレス生成器を構成するのに使用される特定の公式は各実施形態に関して異なる。
【０１３７】
図１５は、フレーム・バッファから出力されたピクセルを並べ替える方法の一実施形態を示す流れ図である。この実施形態では、１５０１で示すとおり、ピクセルがフレーム・バッファから受け取られる。ピクセルは、適切な表示順になっていない可能性があるので、１５０３で示すとおり、ピクセルの表示順に対応する書込みアドレスを生成し、１５０５で示すとおり、次に各ピクセルをそのピクセルのために生成された書込みアドレスでピクセル・バッファに記憶することによって並べ替えることができる。このようにすると、１５０７で示すとおり、ピクセルは、ピクセル・バッファ内で表示順になり、アドレスの順序で読み出すことができる。したがって、いくつかのピクセルがフレーム・バッファによって連続的に出力されても、それらのピクセルがその相対的な表示順に関して連続的でない場合、連続するアドレスで記憶されない。
【０１３８】
一部の実施形態では、ピクセル・バッファは、ディスプレイ・チャネルの間で区分化することが可能であり、したがって、各ディスプレイ・チャネルが、独自のピクセル・バッファ空間内で独自の書込みアドレスを生成する。他の実施形態では、各ディスプレイ・チャネルに関するピクセルが、ピクセル・バッファ内で混合される（たとえば、各ブロック内で、ピクセルは単一のディスプレイ・チャネルに対応するが、ブロックは、ピクセル・バッファ内で混合される）。以上の実施形態では、書込みアドレスを生成することには、ピクセル・バッファのどの部分がどのディスプレイ・チャネルに割り振られているかを記録にとる情報を生成すること、および／または各ディスプレイ・チャネルのブロックの適切な表示順を記録にとる情報を生成することも関与する。
【０１３９】
図１６は、ピクセルを並べ替える方法の別の実施形態を示している。この実施形態では、ピクセルを、フレーム・バッファから順序が乱れた状態で受け取る。図１５に示すとおり、ピクセルがピクセル・バッファに記憶される際にピクセルを並べ替える代わりに、ピクセルがフレーム・バッファから受け取られた順序でピクセルをピクセル・バッファの中に記憶する。ピクセルをピクセル・バッファから適切な表示順で読み出すため、読取りアドレス生成器が、正しい表示順でピクセルにアクセスする読取りアドレスを生成する。したがって、読取りは、連続してアドレスが付けられたピクセルにアドレス順にアクセスするのではなく、ピクセル・バッファの中を行き来する。
【０１４０】
複数のディスプレイ・チャネルを同期させること
多くの状況では、複数のディスプレイ・チャネルの垂直帰線消去期間を同期させることが有用である。たとえば、立体表示（たとえば、左イメージと右イメージが、立体ゴーグルによってユーザの左目と右目に提供される）、バーチャル・リアリティ、およびビデオ記録では、様々な表示ストリームが同期されていない限り、目障りな視覚的効果が生じる。たとえば、立体表示システムにおける表示が同期されていない場合、左イメージと右イメージは、同一のイメージの左目ビューと右目ビューを同時に表示しなくなり、これにより、見る人が惑わされる。
【０１４１】
各表示ストリームは、独自の表示タイミング生成器（ＤＴＧ）を有する。同期されるべき表示ストリームに関するＤＴＧのそれぞれは、同一のタイミングを使用するように設定されるが、各表示ストリームによって使用される基準周波数の変動により、それぞれのビデオ・タイミングが互いとの関係でドリフトすることが最終的に生じる。この問題を解決するため、一方のディスプレイ・チャネルを「マスタ」チャネルとして設定し、他方のディスプレイ・チャネルを「スレーブ」チャネルとして設定することに関わる複数のディスプレイ・チャネルを同期させる方法が考案されている。スレーブ・チャネルは、マスタの垂直帰線消去期間の開始を検出したときはいつでも垂直帰線消去期間にジャンプすることにより、自らの垂直帰線消去期間をマスタの垂直帰線消去期間に同期させるように構成されている。
【０１４２】
図８に示すとおり、いくつかのディスプレイ・チャネルが、共用されるフレーム・バッファから表示情報をプリフェッチする。さらに、ディスプレイ・チャネルがフレーム・バッファを共用しない場合でも、表示情報をプリフェッチすることが望ましい。複数のディスプレイ・チャネルを同期させる既存の方法が抱える１つの問題は、それらの方法が、各ディスプレイ・チャネルが表示データをプリフェッチするシステムにおいては機能しないことである。たとえば、スレーブ・ディスプレイ・チャネルがデータのプリフェッチを行っている場合、マスタの垂直帰線消去期間が始まった時点でスレーブのパイプラインの中に依然としてプリフェッチされたデータが存在する。その結果、現在のフレームに関する残りのデータのすべて、または一部を既にプリフェッチしているために、スレーブは、垂直帰線消去期間にジャンプして、次のフレームの表示を始めることができない。したがって、データのプリフェッチを行っている表示ストリームを同期させるため、スレーブの表示ストリーム内のプリフェッチされたデータに対処しなければならない。
【０１４３】
図１７は、表示ストリームを同期させるように構成されたシステムの一実施形態を示している。この実施形態は、表示情報をプリフェッチするディスプレイ・チャネルとともにも、また表示情報をプリフェッチしないディスプレイ・チャネルとともにも使用することができる。各チャネルのＤＴＧ９７１は、ＶＳ信号を自らのチャネルのバースト・リクエスタ８０９に出力して、バースト・リクエスタがデータをプリフェッチすることを始めるように（たとえば、バースト・リクエスタが、垂直帰線消去期間の終りの直前の時点から、次の垂直帰線消去期間の始まりの直前の時点までデータのプリフェッチを行うように）構成されている。さらに、各ＤＴＧ９７１は、ＳＹＮＣ信号をディスプレイに出力する。
【０１４４】
また、各ディスプレイ・チャネルのＤＴＧは、マスタまたはスレーブとして動作するように構成させてもよい。デフォルトの動作モードになっている場合、各チャネルは、マスタである（したがって、複数のチャネルが動作している場合、チャネルは同期されない可能性がある）。１つまたは複数のチャネルがスレーブに設定されている場合、チャネルの表示タイミング生成器９７１Ｂは、マスタＤＴＧ９７１Ａからフレーム信号を入力として取り込む。一部の実施形態では、各チャネルは、同一の出力コントローラ内の別のＤＴＧ９７１Ａから、または外部デバイスからマスタの信号を受け取るように構成されている（すなわち、マスタは、フレーム・バッファおよび出力コントローラをスレーブと共用しない）。
【０１４５】
図１８に示すとおり、ＤＴＧ９７１の一実施形態は、一連のネストされたカウンタとして実現することができる。この実施形態では、ＤＴＧ９７１は、各水平線のタイミングを制御することができる水平カウンタ９７５を含む。たとえば、水平カウンタ９７５は、ゼロで開始し、線の終り（図１９に示したＨＢＡＰ）に達するまで各ピクセル・クロックで増分される。カウンタ９７５は、線の終りに達すると、ゼロにリセットされ、次の線をカウントすることを始める。
【０１４６】
ＤＴＧ９７１は、各フィールド内の走査線をカウントする垂直カウンタ９７７も含む。垂直カウンタ９７７は、水平カウンタ９７５が線の終り（すなわち、ＨＢＡＰ）に達するたびに毎回、増分される。垂直カウンタ９７７は、フィールドの始まりで０からカウントを始めて、フィールドの終り（図１９に示したＶＢＡＰ）までカウントを続ける。フィールドの終りに達した後、カウンタ９７７は、次のフィールドのカウントを始めることができるように、次のＨＳＡＰでゼロにリセットされる。
【０１４７】
また、ＤＴＢ９７１は、各フレーム内のフィールドをカウントするように構成されているＶＳＥ／フィールド・カウンタ９７９も含む。たとえば、インターレース方式でないフレームの場合、１フレーム当たり１フィールドが存在することができ、他方、インターレース方式のフィールド順次カラー・フレームの場合、１フレーム当たり６つのフィールドが存在する。カウンタ９７９がＶＳＥ（Vertical Sync Elongated）カウンタとして構成されている場合、各フレーム内の最初の垂直同期期間（たとえば、カウンタがゼロに等しいときの）は、延長されている（たとえば、このモードをフィールド順次カラー・モードで使用して、レッドのフィールドが書き込まれるときはいつでも垂直同期期間を延長する）。ＶＳＥ／フィールド・カウンタ９７９は、各フレームの始まりにゼロでカウントを始め、垂直カウンタ９７７がＶＢＡＰに等しくなり、水平カウンタ９７５がＨＳＡＰに等しくなるたびに毎回、増分される。カウンタ９７９は、フレーム内の最後のフィールドに達すると、ＶＢＡＰとＨＳＡＰの次の出現時にゼロにリセットされる。
【０１４８】
ＤＴＧ出力は、１組の制御レジスタ内部の値を設定することによってプログラミングすることができる。これらの制御レジスタは、ある同期パルスを生成するためにカウンタのそれぞれにおける値と比較することができる。ＤＴＧ９７１は、ディスプレイに同期パルス（たとえば、ＨＳＹＮＣ、ＶＳＹＮＣ、ＣＳＹＮＣ）および／または帰線消去信号を出力することができる。図１９は、提供される同期パルスおよび帰線消去信号の一例、およびそれらがどのように表示されたピクセルに対応するかを示している。垂直フロント・ポーチは、線０とＶＳＡＰ（垂直同期アサーション・ポイント）の間の時間として定義される。垂直同期期間は、ＶＳＡＰとＶＳＮＰ（垂直同期ネゲーション・ポイント）の間に生じる。したがって、ＤＴＧは、垂直同期期間中に垂直同期信号をディスプレイにアサートすることができる。垂直バック・ポーチは、ＶＳＮＰとＶＢＮＰ（垂直帰線消去ネゲーション・ポイント）の間に生じる。垂直アクティブ表示期間はＶＢＮＰとＶＢＡＰ（垂直帰線消去アサーション・ポイント）の間に生じる。垂直帰線消去期間はＶＢＡＰとＶＢＮＰの間に生じる。
【０１４９】
水平フロント・ポーチは、列０とＨＳＡＰ（水平同期アサーション・ポイント）の間に生じる。水平同期期間はＨＳＡＰとＨＳＮＰ（水平同期ネゲーション・ポイント）の間に生じる。したがって、ＤＴＧは水平同期期間中に水平同期信号をアサートすることができる。水平バック・ポーチはＨＳＮＰとＮＢＮＰ（水平帰線消去ネゲーション・ポイント）の間に生じる。水平アクティブ表示期間はＨＢＮＰとＨＢＡＰ（水平帰線消去アサーション・ポイント）の間に生じる。水平帰線消去期間はＨＢＡＰとＨＢＮＰの間に生じる。
【０１５０】
したがって、同期信号を生成するため、ＤＴＧ制御レジスタは、ＨＳＡＰ、ＨＳＮＰ、ＶＳＡＰ、ＶＳＮＰ等を表わす値を含む。これらの値は、水平カウンタおよび垂直カウンタの現在の値と比較することができ、等しい場合、適切な信号がアサートされること、またはネゲートされる。
【０１５１】
図１９は、ＶＦＴＰ（垂直フレーム切替えポイント）も示している。各ＶＦＴＰは、それぞれのディスプレイ・チャネルの垂直帰線消去期間中に生じる。ＶＦＴＰは、連続するフレームとフレームを区別するのに使用されるＦＲＡＭＥ信号が切り替わって新しいフレームが始まることを示すポイントである。各チャネルのＦＲＡＭＥ信号は、ＤＴＧカウンタの１つまたは複数がある値に達したことに応答して切り替わる。ＶＦＴＰは、異なるフレームを画するので、ディスプレイ・チャネルがＶＦＴＰに達する時点を「フレーム・イベント」と呼ぶことができる。以下の実施形態では、各ディスプレイ・チャネルに関するＶＦＴＰは線０とＶＳＡＰの間に（すなわち、垂直フロント・ポーチ中に）生じる。ディスプレイ・チャネルを互いに同期させるため、スレーブ・ディスプレイ・チャネルは、マスタ・ディスプレイ・チャネルがＶＦＴＰに達したという指示に応答して自らのＶＦＴＰにジャンプするように（それぞれの連続するフレームを通常どおり漸進するのではなく）構成されている。
【０１５２】
したがって、マスタ・ディスプレイ・チャネルのフレーム・イベントに（すなわち、マスタのＦＲＡＭＥ信号の切り替わりによって示されるとおり、マスタ・ディスプレイ・チャネルがＶＦＴＰに到達したことに）応答して、スレーブ・ディスプレイ・チャネルは、現在のフレームのアクティブな表示を表示することを終えてから、ＶＦＴＰにジャンプし、ＶＢＡＰとＶＦＴＰの間の線をスキップするように構成されている。スレーブのＤＴＧが垂直フロント・ポーチ内にある間にマスタ・フレーム・イベントがスレーブによって受け取られた場合、スレーブのＤＴＧは、現在の水平線の終りまで待ってからＶＦＴＰにジャンプする。スレーブが垂直フロント・ポーチの外にある間にフレーム・イベントが受け取られた場合、スレーブのＤＴＧは、垂直フロント・ポーチに入るまで（すなわち、ＶＢＡＰおよびＨＢＡＰまで）待ってからＶＦＴＰにジャンプする。
【０１５３】
図１８に示したＤＴＧ９７１の実施形態では、ＶＦＴＰにジャンプすることは、水平カウンタ９７５をＨＳＡＰ＋１の値に設定することを含む。同様に、垂直カウンタをＶＦＴＰ＋１に設定し、ＶＳＥ／フィールド・カウンタを次のフィールドに設定することができる（または、新しいフレームが始まる場合、ＶＳＥ／フィールド・カウンタは、ゼロに設定される）。
【０１５４】
この実施形態では、スレーブは、アクティブな表示の終りまで（たとえば、ＶＢＡＰおよびＨＢＡＰまで）待ってから切替えポイントにジャンプするため、各帰線消去期間中にピクセル・バッファ内および／または出力待ち行列内に残っているピクセル・データが全く存在しない。さらに、ジャンプは、帰線消去期間中に行われるので、表示されたフレームのどれも、ジャンク・データ（たとえば、前のフレームからのプリフェッチされたデータ）を含むことがない。しかし、ジャンプは、帰線消去期間中に行われるので、ジャンプのサイズは制限される（たとえば、最大ジャンプはＶＢＡＰとＶＦＴＰの差に等しい）。その結果、ディスプレイ・チャネルがマスタに同期されるまで数回のジャンプを要する可能性がある。マスタとスレーブの間の差が大きい場合、これには、数秒間を要する可能性がある。したがって、この実施形態は、「追い上げ」同期と呼ぶことができる。ジャンプは小さいので、ディスプレイが不連続を検出し、同期を一時的に失う可能性は低い。この結果、見る人は、おそらく、同期中に全く異常に気付かない（ディスプレイを同期させるのに要する時間中にディスプレイの同期がずれていることでもたらされる異常を除き）。
【０１５５】
データをプリフェッチするディスプレイ・チャネルを同期させるためのいくつかの他の技術も利用可能である。たとえば、別の実施形態では、スレーブのＤＴＧは、現在の走査線の終り（アクティブな表示の終りではなく）まで待ってからＶＦＴＰにジャンプする。この実施形態では、同期イベントが帰線消去期間の外で生じた場合、同期イベントより前に２つのディスプレイ・チャネルの同期がどれだけずれていたかに関わらず、任意の２つのディスプレイ・チャネルを３つのフレーム以内で同期させることができる。この実施形態は「垂直即時」同期と考えることができる。
【０１５６】
垂直即時同期では、同期イベントが帰線消去期間の外で生じた場合、ＤＴＧをＶＦＴＰにジャンプさせることにより、現在のフレームを放棄することができる。ただし、スレーブ・ディスプレイ・チャネルに関するバースト・リクエスタが、中断されたフィールドまたはフレームに関して依然としてデータを要求している可能性があり、かつ／または中断されたフィールドまたはフレームに関する表示情報が、スレーブのパイプライン（たとえば、表示出力待ち行列またはピクセル・バッファ）の中に依然として存在する可能性がある。スレーブのＤＴＧがジャンプの後にアクティブな表示ポイントに達した場合、残っているピクセル（リセットの時点でパイプラインの中に既に存在した、またはリセットされないバースト・リクエスタによって要求された）が、スクリーンに出力される。このデータは前のフレームの一部であったので、この出力は、ディスプレイ上で「ジャンク」として現れる。このジャンク・フレームが終わる前に、スレーブの表示出力待ち行列（ＤＯＱ）でピクセルが尽きる（というのは、中断されたフレームが、現時点で、混ぜ合わされた順序ではあっても、ディスプレイに完全に出力されているため）。ＤＯＱのアンダーフローの結果、このフィールドの残りの部分に関してガーベッジ・ピクセルが出力される。ＤＴＧが次の帰線消去期間に入ると、アンダーフローの生じたＤＯＱは、次のフレームを受け取り始めるように、空の状態にリセットされる。
【０１５７】
さらに、スレーブＤＴＧの出力信号の１つまたは複数（たとえば、ＶＳ信号）を使用してスレーブのバースト・リクエスタをリセットすることができる。たとえば、一実施形態では、各バースト・リクエスタは、表示情報の完全なフレームを要求してしまうまで、要求をアサートすることを続けるように構成されている。その結果、スレーブ・ディスプレイ・チャネルにおけるバースト・リクエスタは、スレーブのＤＴＧがＶＦＴＰにジャンプした後でも、中断されたフレームの要求をアサートすることを続ける。ただし、バースト・リクエスタは、次のアクティブな表示期間（前のフレームに関する残りのピクセルを含むジャンク・フレーム、ならびにアンダーフローの生じたＤＯＱからのガーベッジ出力を表示している）中に中断されたフレームに関する表示情報を要求することを終える。バースト・リクエスタは、中断されたフレームからのデータを要求することを終えると、次のＶＳ信号を待つように構成されている。ＶＳ信号を受け取ったことに応答して、バースト・リクエスタは、ＶＳ信号の中で指定されたフレームに関する表示情報をプリフェッチすることを始める。したがって、スレーブＤＴＧが、ジャンク・フレームの後で次のＶＳ信号を生成したとき、バースト・リクエスタは、指定されたフレームの要求をアサートすることを始める。マスタ・ディスプレイ・チャネルとスレーブＤＴＧから見ると、この新しいフレームは、マスタが、後続のアクティブな表示期間中にガーベッジ・フレームでないフレームを出力しており、スレーブＤＴＧが、その期間中にジャンク・フレームに関するタイミング信号を生成していたので、中断されたフレームの後の第２のフレームであることに留意されたい。したがって、スレーブＤＴＧからバースト・リクエスタに提供されるＶＳ信号は、中断されたフレーム（フレームＦ）の後、バースト・リクエスタが表示情報の第２のフレーム（フレームＦ＋２）の要求をアサートすることを始め、フレーム・バッファ内の中間のフレーム（フレームＦ＋１）がスキップされるようにすべきことを示す。
【０１５８】
したがって、ジャンク・フレームの終りまでに、ＤＴＧ、バースト・リクエスタ、およびＤＯＱはすべて、表示情報の適切なフィールドまたはフレームを表示することを始める準備ができている。同様に、次のフィールドまたは次のフレームもマスタに同期される。スレーブの垂直フロント・ポーチ中にマスタのフレーム・イベントが生じた場合、パイプラインの中にプリフェッチされたデータが全く存在しない。したがって、スレーブは、ジャンク・フレームを出力する必要なく、マスタと同期をとることができることに留意されたい。
【０１５９】
ガーベッジ・データのフレームが存在するので、ユーザは、この垂直即時同期の実施形態において同期に気付く可能性がある。さらに、ＶＦＴＰへのジャンプにより、垂直同期が中断されるので、ディスプレイが一時的に同期を失い、ディスプレイの目立った帰線消去がもたらされる。ただし、水平同期は中断されないので（現在の線の終りを待ってからＶＦＴＰにジャンプするため）、その可能性は小さく、稀にしか生じない。
【０１６０】
水平および垂直即時同期と呼ばれるさらに別の実施形態では、ＤＴＧは、現在の走査線の終りが表示されるのを待つことなく、同期イベントを検出するとすぐにＶＦＴＰにジャンプする。これにより、前述した方法より迅速な同期が提供されるが、水平同期と垂直同期がともに中断される可能性があるので、ディスプレイが一時的に同期を失うことになる可能性もより高くなる可能性がある。さらに、前の実施形態と同様に、この実施形態も、中断されたフレーム内の残りの表示情報の一部が既にプリフェッチされている場合、ガーベッジ・データのフレームを生成する。
【０１６１】
一実施形態では、グラフィックス・システムは、複数の表示ストリームを同期させるいくつかの異なる技術を実施するように構成されている。たとえば、システムは、追い上げ法、垂直即時法、ならびに水平および垂直即時法を含む。使用される特定の技術は、制御レジスタの現在の値によって示される。そのような実施形態では、ユーザは、いずれの同期方法を使用するかを選択することができる。
【０１６２】
図２０Ａ〜２０Ｃは、複数の表示ストリームを同期させるいくつかの異なる方法を示している。図２０Ａに示した実施形態では、マスタ・フレーム・イベントが検出された場合、スレーブ・ディスプレイ・チャネルは、アクティブな表示期間の終りまで（すなわち、ＶＢＡＰおよびＨＢＡＰまで）待ってからＶＦＴＰにジャンプする。スレーブが垂直フロント・ポーチ期間内にある間にマスタ・フレーム・イベントが検出された場合、スレーブは、現在の線の終り（すなわち、ＨＢＡＰ）まで待ってから、ＶＦＴＰにジャンプする。このプロセスは、スレーブ・ディスプレイがマスタに同期されるまで繰り返される。複数のスレーブ・ディスプレイ・チャネルが存在するので、スレーブ・ディスプレイ・チャネルの１つまたは複数は、データのプリフェッチを行わないことに留意されたい。
【０１６３】
図２０Ｂは、スレーブ・チャネルがデータのプリフェッチを行う場合に使用される異なる実施形態を示している。この場合、２０３３および２０３５で示すとおり、マスタのフレーム・イベントを検出したことに応答して、スレーブのＤＴＧは、現在の線の終り（すなわち、ＨＢＡＰ）まで待ってから、ＶＦＴＰにジャンプする。スレーブは、ジャンプする直前にアクティブな表示期間にあった場合、放棄されたフレームに関するプリフェッチされたデータをパイプラインの中に依然として持っている。パイプラインをクリアするため、スレーブ・ディスプレイ・チャネルは、２０３７で示すとおり、残っているデータを次のアクティブなビデオ期間中に出力する。アクティブなビデオ期間が終わる前にプリフェッチされたデータが尽きた場合、そのアクティブなビデオ期間の残りの期間中、ガーベッジ・ピクセルを出力する。この「ジャンク」フレームの後、パイプラインは、クリアになっている。したがって、スレーブは次のフレームを適切に表示する準備ができている。マスタ・フレーム・イベントが検出されたときにスレーブが垂直フロント・ポーチ期間中にあった場合、パイプラインの中に前のフレームに関するプリフェッチされたデータが全く存在しない。したがって、スレーブ・ディスプレイ・チャネルは、ジャンク・フレームを出力しない。
【０１６４】
図２０Ｃの実施形態では、スレーブ・ディスプレイ・チャネルは、マスタのフレーム・イベントを検出したとき、アクティブな表示の終り、または現在の線の終りを待つのではなく、ＶＦＴＰに即時にジャンプする。スレーブのパイプラインの中にプリフェッチされたデータが依然として存在しているので、スレーブ・ディスプレイ・チャネルは、前のフレームに関して残っているデータがあれば、それを次のアクティブな表示期間中にジャンク・フレームとして出力する。図２０Ｂの実施形態の場合と同様に、スレーブが垂直フロント・ポーチ中にある間にマスタのフレーム・イベントが検出された場合、ジャンク・フレームを出力する必要ない。
【０１６５】
フレーム・バッファ・イメージの一部分を表示しながらパンすること
しばしば、フレーム・バッファ内のイメージの一部分だけが、ディスプレイ上で表示される。たとえば、フレーム・バッファ・イメージが、特定のディスプレイが表示することができるよりも大きい（すなわち、より多くのピクセルを含む）。あるいは、一方のディスプレイが完全なイメージを表示し、他方のディスプレイは、そのイメージの１つまたは複数の部分を表示するように２つまたはそれより多くのディスプレイが構成されている。この機能は、完全なイメージが一方のディスプレイ上で表示され、イメージの一部分（たとえば、１つの特定のウインドウ）が別のディスプレイに出力されてビデオテープに保存されるプレゼンテーションにおいて使用される。さらに別の構成では、各ディスプレイがフレーム・バッファ・イメージの異なる部分を表示するようにいくつかの個々のディスプレイが構成されている。
【０１６６】
フレーム・バッファ・イメージの一部分を見ているとき、ユーザは、フレーム・バッファ・イメージの他の部分を見ることができるようにパンすることを所望することがある。たとえば、ユーザは、マウスを動かして所望するパンの方向および／または速度を示すことにより、矢印キーを押す、またはスクロール・バーを調整する。
【０１６７】
フレーム・バッファ・イメージのある部分から別の部分にパンする際、パンが行われる各フレーム中にぎざぎざのエッジやその他のアーチファクトのない平滑なイメージを表示することが望ましい。フレーム・バッファ・イメージのある部分を表示することから、別の部分を表示することに移行するため、あるラスタ関連パラメータ（たとえば、フレーム・バッファ・イメージのズームされた部分の左上隅の座標）を調整する。ただし、これらのパラメータがアクティブな表示期間中に調整される場合、各フレームの部分が、異なるラスタ・パラメータを使用して処理され、パン期間中に目障りな視覚的アーチファクトがもたらされる。
【０１６８】
望ましくない視覚的アーチファクトを回避するため、グラフィックス・システムは、ラスタ・パラメータが更新される時間を制約する。図２１は、フレーム・バッファ・イメージを平滑にパンするように構成されているグラフィックス・システムの一実施形態を示している。このグラフィックス・システムは、パン・オペレーションに関わるラスタ・パラメータをそれぞれ保持する２組のレジスタを維持する。レジスタの一方のセット９９１は、表示情報にアクセスし、表示情報を処理するのに使用されるアクティブなセットである。レジスタの他方の「シャドー」セット９９３は、ソフトウェアによって更新される（たとえば、ユーザがパン・オペレーションを開始したことに応答して）セットである。出力コントローラによって実際に使用されるレジスタを更新するため、シャドー・レジスタ値をアクティブなレジスタ値にコピーする。フレーム・バッファ内のイメージを平滑にパンするため、シャドー・レジスタ値がアクティブなレジスタ値に転記される時間をパンを行うディスプレイの帰線消去期間中の時間に制約することができる。
【０１６９】
スクリーン・アドレス・レジスタは、シャドーイングされる１つのラスタ・パラメータである。スクリーン・アドレス・レジスタは、特定のディスプレイ・チャネルに関する表示情報の次のフレームが偶数線で開始するか、または奇数線で開始するかを決める値を記憶することができる。
【０１７０】
シャドーイングされるその他のラスタ・パラメータは、表示アドレス生成器レジスタ９９１Ａである。これらのレジスタのそれぞれは、フレーム・バッファ・メモリ内の特定のディスプレイ・チャネルのイメージの開始アドレスを表わす値、および／またはフレーム・バッファの構成を表わす値を記憶することができる。
【０１７１】
また、要求されたバースト内でスクリーンがどこで始まり、どこで終わるかを示す値を記憶することができるマージン・トリミング・レジスタ９９１Ｂもシャドーイングされる。マージン・トリミング・レジスタは、ディスプレイのサイズがバーストの境界と完全に揃わない場合に使用することができる。
【０１７２】
さらなるラスタ値もシャドーイングすることができる。たとえば、各ディスプレイ・チャネルに関する水平バースト・カウント・レジスタ９９１Ｃ／９９１Ｄをシャドーイングすることができる。水平バースト・カウントは、特定のディスプレイ・チャネルに単一の走査線を提供するのに必要とされるフレーム・バッファからの表示情報のバーストの数を記述する。たとえば、各バーストが８０ピクセルをディスプレイ・チャネルに提供し、ディスプレイが１２８０×１０２４のＣＲＴである場合、そのディスプレイ・チャネルに関する水平バースト・カウント・レジスタは、１本の線当たり１６のバーストが存在することを示す。
【０１７３】
レジスタのアクティブなセットを更新するため、ソフトウェアはまず、更新された値をシャドー・レジスタに書き込む。シャドー・レジスタが更新されると、ソフトウェアは、シャドー・レジスタ値がアクティブなレジスタに転記されるべきという要求をアサートすることができる。この要求はいつ転記が行われるべきかを示す。たとえば、パンを行うディスプレイ・チャネルがフレーム当たり１つまたは複数のフィールドのデータを有する場合、要求は、転記が現在のフレームが完了した後に行われるべきことを指定する。別法では、フレーム当たり複数のフィールドが存在する場合、要求は、更新が現在のフィールドが終了した後に行われるべきことを示すようにすることもできる。そのような要求を受け取ったことに応答して、シャドー・レジスタを有する様々な構成要素（たとえば、ピクセル処理ユニット１９４、フレーム・バッファ・インターフェース９８９、および表示出力待ち行列８２１）は、シャドー・レジスタ内の値をアクティブなレジスタに転記する。
【０１７４】
アクティブなレジスタが更新されると、データの次のフレームがフレーム・バッファから出力され、新しい値に基づいて処理される。たとえば、表示アドレス生成器レジスタ内の値が更新されて、パンを行うディスプレイ上で表示されるべきイメージの部分の左上隅が右に４ピクセル移動されていることを示す場合、パンを行うディスプレイ・チャネルに対するフレーム・バッファからの次のフレーム出力は、前のフレームのイメージから４ピクセル右で開始する。
【０１７５】
パンを行うディスプレイ・チャネルがフレーム・バッファからデータのプリフェッチを行っている場合、どのようにフレーム・バッファ内でデータにアクセスが行われるかを施行するパラメータ・レジスタ（たとえば、スクリーン・アドレス・レジスタおよびビデオ・アドレス生成器レジスタ）が、現在のフィールドまたはフレーム（更新要求の中で指定された）に関する最終バーストがフレーム・バッファによって提供されるとすぐに更新される。同様に、ピクセル処理ユニットにおいてピクセルがどのように処理されるかを施行するレジスタも、フレーム内の最後のピクセルがパイプラインの中のそのポイントを超えて流れるとすぐに更新される。
【０１７６】
各ラスタ・パラメータ・レジスタを適切な時点（たとえば、現在のフィールドまたはフレームに関するデータがグラフィックス・システムのそのセクションを既に通過した後）で更新するため、トークンを使用して各フィールドまたは各フレームの終りを示す。たとえば、図２１を参照すると、パン・オペレーションを開始し、どのようなタイプのパン・オペレーションが行われるべきかを記述する指示をソフトウェアがユーザから受け取る。ユーザの指示に基づき、ソフトウェアは、ラスタ・パラメータに関する新しい値を計算し、その値をシャドー・レジスタ９９３に書き込む。また、ソフトウェアは、シャドー・レジスタ９９３が次の可能な機会（たとえば、次の帰線消去期間中）にアクティブなレジスタ９９１に転記されるべきことを示す値をラスタ転記要求レジスタ（図示せず）に書き込むこともできる。ラスタ転記要求レジスタ内の新しい値に応答して、パンを行うチャネルに関するバースト・リクエスタ８０９が、ラスタ転記要求をフレーム・バッファ・インターフェース９８９に送る。
【０１７７】
フレーム・バッファ・インターフェース９８９は、ラスタ転記要求を受け取ったとき、自らが保持しているシャドー・レジスタ９９３Ａがあれば、それをアクティブなレジスタ９９１Ａに転記し、確認応答を出力プロセッサに送る（ただし、表示情報は送らない）。この確認応答は、前のフレームが完了している（パイプラインのそのポイントで）ことを出力プロセッサに通知する。その他のラスタ・レジスタ９９１を適切な時点（すなわち、現在のフレームに関するピクセルがパイプラインのそのポイントを通過したとき）で更新するため、出力プロセッサは、フレーム・バッファ・インターフェースの確認応答に応答して、ラスタ転記トークンをそのパンを行うチャネルの表示ストリームの中に挿入する。ラスタ転記トークンがパイプラインの各部分を通って流れると、ピクセル処理パイプラインの各部分でピクセルがどのように処理されるかを施行するレジスタが更新される。このトークンがパンを行うディスプレイの表示出力待ち行列８２１に入ったとき、表示出力待ち行列８２１は、自らが空になるまで待ってから、ラスタ・パラメータ・レジスタ９９１を更新する。
【０１７８】
したがって、パンを行うディスプレイのパイプライン上のそれぞれのポイントにおいて最後のピクセルが処理された後の帰線消去期間中にラスタ・パラメータを更新することにより、出力表示における望ましくない効果を回避することができる。フィールドの終りのトークン、またはフレームの終りのトークンを使用することにより、パイプラインにおける各構成要素が、前のフレームからの表示情報に対する処理をいつ終えたかを明らかにする。したがって、各構成要素は、トークンを使用して、自らがいつシャドー・レジスタ値をアクティブなレジスタに転記することができるかを認識する。
【０１７９】
一部の実施形態では、ラスタ・パラメータ・レジスタ（たとえば、ピクセル処理ユニット内のレジスタ）のいくつかが、複数のディスプレイ・チャネル間で共用される。それらのディスプレイ・チャネルは同期されていないことがあるため、共用されるシャドー・レジスタ値を共用されるアクティブなレジスタにいつ転記するかを決めるために１つのディスプレイ・チャネルを制御チャネルとして指定することが有用である。たとえば、制御ディスプレイ・チャネルにおけるトークンを使用して、ラスタ・パラメータ・レジスタをいつ更新するかを決めることができる。パンを行うディスプレイ・チャネルが制御ディスプレイ・チャネルではない場合、共用されるラスタ・パラメータ・レジスタは、パンを行うディスプレイ・チャネルのアクティブな表示期間中に更新されることに留意されたい。そのような実施形態では、パンを行うディスプレイ・チャネルを制御ディスプレイ・チャネルに同期させることが有用である。
【０１８０】
図２２は、フレーム・バッファ内のイメージをパンするための方法の一実施形態を示している。ステップ２２０１ないし２２０３で、ユーザ指示がパン・オペレーションを開始した場合、パン・オペレーションに必要とされる更新されたラスタ・パラメータ値が、シャドー・レジスタに書き込まれる。２２０５で、シャドー・レジスタ値がアクティブなレジスタに転記されるように要求が発行される。現在のフレームが処理されている最中にラスタ・パラメータ・レジスタを更新することを回避するため、１つまたは複数のシャドー・レジスタを有するグラフィックス・システムの各構成要素は、２２０７ないし２２０９で示されるとおり、次の帰線消去期間に入るまで待ってからシャドー・レジスタをアクティブなレジスタに転記する。たとえば、各構成要素は、フィールドの終りのトークンを受け取るまで待ってから、自らのラスタ・パラメータ・レジスタをシャドー・レジスタからの値で更新することができる。一部の実施形態では、ラスタ・パラメータ更新を行うようにいくつかのレジスタに通知するトークンは、パンを行うディスプレイ・チャネルとは異なるディスプレイ・チャネルに対応することに留意されたい。シャドー・レジスタ値がアクティブなレジスタに転記された後、更新されたラスタ・パラメータ値を使用して次のフレームが処理される。
【０１８１】
シグネーチャ解析
シグネーチャ解析は、ハードウェア試験の方法である。シグネーチャ解析は、既知の１組のデータのシグネーチャを、通常、そのデータが試験を受ける何らかのハードウェアを通過した後に計算することを含む。計算されたシグネーチャを同じ１組のデータに関する既知の正しいシグネーチャと比較することにより、試験を受けるハードウェアの合格／不合格判定を行う。グラフィックス・システムでは、有用な１組の試験データは、表示情報のフレーム（または１組のフレーム）である。
【０１８２】
試験機能を提供するため、グラフィックス・システムの一部の実施形態は、シグネーチャ解析ハードウェアを含む。シグネーチャ解析ハードウェアは、表示情報がビデオ出力コントローラを通って流れる際に表示情報をキャプチャする１つまたは複数のシグネーチャ解析レジスタ（ＳＡＲ）を含む。各ＳＡＲは、ある「シード」値、つまりあるシグネーチャに初期設定することができ、表示情報がキャプチャされるにつれ、表示情報をそのシグネーチャに追加することができる。
【０１８３】
図２３は、複数のＳＡＲ９９５を含むグラフィックス・システムの一実施形態を示している。ＳＡＲは、各ＳＡＲ内のシグネーチャを使用してグラフィックス・システムのあるセクションを検証することができるように構成されている。たとえば、ＳＡＲ  Ａを使用してフレーム・バッファ２２からのインターフェースを試験するＳＡＲ  Ｂを使用してピクセル・スクランブル解除器８１１およびピクセル・バッファ８１５の出力を試験する。ＳＡＲ  Ｃでキャプチャされたシグネーチャを使用して、ピクセル処理ユニット１９４およびＤＴＧ９７１を試験する。ＳＡＲ  Ｃは、表示情報と制御信号をともにキャプチャする。また、さらなるＳＡＲも、グラフィックス・システム内部の他の場所に（たとえば、表示情報がレンダリングされてフレーム・バッファに書き込まれる際に表示情報をキャプチャするためにフレーム・バッファとハードウェア・アクセラレータの間のインターフェースにおいて）含んでもよい。また、複数のディスプレイ・チャネルが存在するため、各ディスプレイ・チャネルに関して別個のＳＡＲが含まれる（たとえば、図２３は、ディスプレイ・チャネル１とディスプレイ・チャネル２の両方に関するＳＡＲを示している）。前述したとおり、表示情報は、グラフィックス・システムを通って流れるにつれて並べ替えられ、かつ／またはさらに処理され、したがって、各ＳＡＲの中に記憶される最終的なシグネーチャは、その他のシグネーチャのそれぞれとは異なる。
【０１８４】
各ディスプレイ・チャネルのＳＡＲは、シグネーチャ解析制御レジスタ（ＳＡＣＲ）９９７によって制御される。各ＳＡＣＲは、シグネーチャキャプチャを可能にし、かつ／または各ＳＡＲがどれだけの数のフレームをキャプチャするかを制御する信号を自らのディスプレイ・チャネルのＳＡＲのそれぞれに提供する。ＳＡＣＲは、シグネーチャ解析信号バス（図示せず）によってＳＡＲに結合されている。他の実施形態では、個々のＳＡＲがＳＡＣＲの機能を含むことに留意されたい。
【０１８５】
したがって、様々なＳＡＲを使用して適切に機能していないグラフィックス・システムのセクションの位置を正確に特定することができる。さらに正確な位置の特定が所望される場合（たとえば、フレーム・バッファ内の動作不良が生じているインターリーブの位置を正確に特定すること）、特定のハードウェアにそれぞれが重点をおくいくつかの異なる試験イメージを設計することができる。それらの試験のどれに合格し、どれに不合格となるかに応じて、欠陥のあるハードウェアを検出することができる。
【０１８６】
シグネーチャキャプチャは、試験ソフトウェアによって制御される。試験ソフトウェアは、シグネーチャキャプチャをイネーブルにし、キャプチャされたシグネーチャを機能しているシステムが生成するものと予期されるシグネーチャと比較することができる。制御シグネーチャは、既知の機能しているシステムによって、またはシミュレーションによって生成される。キャプチャをイネーブルにする前に、試験ソフトウェアは、シグネーチャフィールドの値を「シード」値に設定することができる。特定の試験に関して選択されたシード値は、その試験で使用される試験イメージに対応する。異なるシード値を各ＳＡＲ９９５の中に記憶することに留意されたい。
【０１８７】
試験ソフトウェアは、適切なＳＡＣＲ９９７内の制御フィールドをキャプチャを開始する値に設定することにより、シグネーチャキャプチャをイネーブルする。たとえば、既知のイメージをフレーム・バッファの中にとり込み、各ＳＡＲ９９５内のシグネーチャをシード値に設定した後、試験ソフトウェアは、適切なＳＡＣＲ９９７内でシグネーチャキャプチャ要求フィールドをアサートする。ＳＡＣＲ９９７は、ＳＡＲがそれぞれイメージに関するシグネーチャを生成するようにさせる信号をＳＡＲに提供する。
【０１８８】
図２４は、一実施形態において、どのようにＳＡＲ９９５が３２ビットのシグネーチャを記憶するかを示している。ＳＡＲは、表示情報と制御信号をともにキャプチャするように構成されている。たとえば、図２３を再び参照すると、表示情報がそれぞれの表示出力待ち行列（ＤＯＱ）８２１から出力されるにつれて、表示情報をキャプチャするように構成されたＳＡＲ９９５Ｃが、それぞれの表示タイミング生成器（ＤＴＧ）９７１によって生成された制御信号（たとえば、同期信号および帰線消去信号）もキャプチャする。複数のフレームがキャプチャされる場合、ＳＡＲは、水平帰線消去期間中、および垂直帰線消去期間中に制御信号（たとえば、同期信号）をキャプチャすることを続ける。
【０１８９】
図２４もＳＡＣＲ９９７の一実施形態を示している。ＳＡＣＲ９９７は複数のフィールドを含む。１つのフィールドはシグネーチャキャプチャ要求フィールド（たとえば、図２４のビット４）である。シグネーチャキャプチャ要求フィールドは、ＳＡＣＲが、シグネーチャキャプチャをイネーブルにする信号をＳＡＲのそれぞれに提供するために、ある値に設定する。たとえば、試験を開始するため、ビット４を設定することができる。これに応答して、ＳＡＣＲ９９７は、ＳＡＲのそれぞれに信号を提供して、ＳＡＲが、表示情報の次のフレームから始めてデータをキャプチャすることを開始して、自らのシグネーチャに追加するようにさせることができる。表示情報がキャプチャされた後、ＳＡＣＲは、シグネーチャ解析ビジー・フィールド（たとえば、図２４のビット５）をある値に設定し、キャプチャが完了したことを試験ソフトウェアに通知する。別の実施形態では、ＳＡＣＲは、シグネーチャ解析ハードウェアが現時点でアイドルであることを示す値にシグネーチャ解析要求フィールドを設定するように構成されている。このようにして、単一のフィールドを使用して、シグネーチャキャプチャの要求とシグネーチャキャプチャの完了をともに示すことができる。
【０１９０】
各ＳＡＣＲ９９７は、データのどれだけの数のフィールドまたはフレームがキャプチャされるべきかを指定するフィールドも含む。複数のフレームがキャプチャされる場合、各ＳＡＣＲは、各フレーム内にどれだけの数のフィールドが存在するかを特定するフィールドを有する。したがって、シグネーチャキャプチャ要求フィールドをキャプチャをイネーブルにする値に設定する前に、試験ソフトウェアは、キャプチャされるべきフレームの数をフレーム数フィールドに書き込む。各フレームがキャプチャされるにつれ、ＳＡＣＲは、フレーム数フィールド内に記憶された数を減分する。ＳＡＣＲは、最終フレームの最終走査線の中の表示情報がキャプチャされた後、ＳＡＲがデータをキャプチャすることを停止させる信号をＳＡＲに提供する。
【０１９１】
ＳＡＲは、シグネーチャフィールドがクリアされるまで、または新しいシード値がシグネーチャフィールドに書き込まれるまで、キャプチャされたシグネーチャを記憶しつづける。一実施形態では、以前のキャプチャにおいて要求されたよりも多くのフィールドをキャプチャするため、以前にキャプチャされたシグネーチャを開始値として使用して（ＳＡＲのそれぞれの中に新しいシード値を記憶するのではなく）、別のキャプチャが要求される。一部の実施形態では、別々のＳＡＣＲを有する代わりに、各ＳＡＲが、ＳＡＣＲ内に示された制御フィールドも含むことに留意されたい。
【０１９２】
ＳＡＲは、インターレース方式のフレームとインターレース方式でないフレームをともにキャプチャすることができ、また複数のフィールド（たとえば、フィールド順次カラー）を含むその他のフレームもキャプチャできることが可能である。インターレース方式でないフレームは、すべて同一のフィールド内に存在する連続する走査線（たとえば、１０２４×１２８０のＣＲＴの場合、それぞれ１２８０ピクセルの１０２４の連続する線）を含む。これに対して、インターレース方式のフレームは２つの異なるフィールドを含む。一方のフィールドは偶数線（たとえば、線２、４、６、．．．１０２４）を含み、他方のフィールドは奇数線（たとえば、線１、３、５、．．．１０２３）を含む。フィールド順次カラー・モードでは、各色（レッド、グリーン、ブルー）が、別個のフィールドに送られる。したがって、ＳＡＲは、各フレーム内で複数のフィールドをキャプチャするように構成されている。通常、１つのフィールドのすべてをディスプレイ・ラスタに送ってから、別のフィールドの部分を送る。
【０１９３】
ＳＡＲがインターレース方式のフレームとインターレース方式でないフレームをともにキャプチャできるようにするため、ＳＡＲをいくつかの異なる仕方で構成することもできる。一実施形態では、各ＳＡＲは、そのＳＡＲがキャプチャするように設定されている各フレームに関して、表示情報の１つまたは複数の連続するフィールド（たとえば、インターレース方式でない場合、２つのフレーム、インターレース方式の場合、１つのフレーム）をキャプチャすることができる。インターレース方式のフレームに関して繰り返し可能な結果を得るため、各ＳＡＲは、偶数フィールド、または奇数フィールドでキャプチャを始めるように構成されている（したがって、インターレース方式でないモードで、異なるフレームが、偶数または奇数に指定される）。別の実施形態では、ＳＡＲは、フレームがインターレース方式である場合、フレーム当たり２つのフィールドをキャプチャし、フレームがインターレース方式でない場合、フレーム当たり１つのフィールドをキャプチャするように構成されている。
【０１９４】
各ＳＡＲは、ＳＡＲが配置されているビデオ出力コントローラの部分に関連する様々なフロー制御信号を使用して、フレーム／フィールドがいつ始まり、いつ終わるかを判定することができる。一実施形態では、ＳＡＲ  Ａが、データがフレーム・バッファから出力されるのにつれてデータをキャプチャしている場合、ＳＡＲ  Ａは、特定のバーストがフレームのどの部分（始まり、途中、または終り）に対応するかを、そのバーストに関連する信号に基づいて判定する。たとえば、フレーム・バッファ２２に対する出力プロセッサのアクセスが、フレーム・バッファ・インターフェース（ハードウェア・アクセラレータ１８内部に含まれることが可能な）によって制御される。フレーム・バッファ・インターフェースは、出力プロセッサにおいてディスプレイ・チャネルの１つからバースト要求を受け取ったことに応答してデータのバーストを出力するようにフレーム・バッファ２２に指示すると、その要求を確認する信号をアサートする、または切り替えることができる。したがって、各バースト・リクエスタによってどのようなタイプのバーストが要求されたか（たとえば、新しいフィールド内の第１のバースト対現在のフィールド内の次のバースト）、および／またはフレーム・バッファ・インターフェースからの確認信号に基づき、ＳＡＲ  Ａは、各フィールドの始まりと終りを特定することができる。同様に、ＳＡＲ  Ｃは、表示出力待ち行列の出力において、ＤＴＧ９７１によって生成された同期信号に基づいてフレームの異なる部分を特定することができる。さらに、ＳＡＲ  Ｃは、それらの同期信号をキャプチャしてシグネーチャに追加することができる。そうすることにより、ＤＴＧ９７１のオペレーションを検証することができる。
【０１９５】
一部の実施形態では、各フィールド後（たとえば、フィールド内の最終バースト要求のフレーム・バッファ・インターフェースによる確認応答に応答して）、各ディスプレイ・チャネルのパイプラインにトークンを送ることができる。このトークンは、いつキャプチャを始め、いつキャプチャを終えるかをＳＡＲに告げ、ＳＡＲが、いくつのフィールドをキャプチャしたかを把握できるようにする。このトークンは、帰線消去期間中にラスタ・パラメータ・レジスタを更新するのに使用されるトークンと同様であること、または同じであることさえ可能性がある。別法として、各ピクセルが、そのピクセルがフィールド内の最初の（または最後の）ピクセルであるかどうかを特定するタグを含む。
【０１９６】
同様に、一部の実施形態では、各ＳＡＲが、１つの特定のディスプレイ・チャネルに関する表示情報をキャプチャするように構成されている。ＳＡＲは、表示情報の各アイテムに付随するタグに基づいて様々なディスプレイ・チャネルのデータ・ストリームを区別するように構成されている。たとえば、各ピクセルが、そのピクセルがどのディスプレイ・チャネルに属するかを特定するタグを含む。したがって、ピクセルがグラフィックス・システムを通って流れるにつれ、各ＳＡＲは、各ピクセルのタグを、各ＳＡＲがどのディスプレイ・チャネルに対応するかを明らかにする内部ｉｄタグと比較することができる。タグがマッチしない場合、ＳＡＲはそのピクセルをキャプチャしない。
【０１９７】
様々なアルゴリズムを使用して、キャプチャされているフレーム内のそれぞれの新しいピクセルをシグネーチャに追加することができる。たとえば、１つのアルゴリズムは、キャプチャされたピクセルを既存のシグネーチャのすべて、または一部とＸＯＲ演算することに関わることが可能である。別の実施形態では、ＳＡＲは、ＬＨＣＡ（線形混成セルラー・オートマトン）として実施することができる。一般に、セルラー・オートマトンは、各レジスタ内のシグネーチャがローカル規則に従って更新される別個の動的システムである。レジスタは、離散した時間間隔で更新することができる。各レジスタの値は、前回のステップにおいてそのレジスタの値が何であったかに依存する。さらに、各レジスタの状態も、前回のステップにおける隣接するレジスタ内のシグネーチャに依存する。
【０１９８】
一般に、シグネーチャアルゴリズムは、それぞれの異なる既知の試験イメージが（ほぼ）固有のシグネーチャを有するように選択することができる。このようにすると、欠陥のあるシステムが正しいシグネーチャを生成することはほとんどない。この理由で、繰り返しのシグネーチャを生成せずに大量のデータ（たとえば、複数のフレーム）をキャプチャすることができるアルゴリズムを選択することが有用である。より多くのデータがキャプチャされるにつれ、誤り検出の量も増加する。というのは、シグネーチャ・アルゴリズムは、しばしば、データのいくつかのフレームの範囲内で単一のピクセルにおける単一のビット誤りを検出する可能性があるからである。
【０１９９】
図２５は、ＳＡＲを使用してグラフィックス・システムの様々な部分を試験する方法の一実施形態を示している。この実施形態では、２５０１で示すとおり、シード値がシグネーチャ解析レジスタに書き込まれる。たとえば、試験ソフトウェアがシード値を書き込むことができる。シグネーチャ解析が要求されたとき（２５０３）、シグネーチャ解析レジスタは、２５０５および２５０７で示すとおり、現在のフレームが終わるまで待ってから、次のフレームの開始でキャプチャすることを始める。たとえば、各ＳＡＲは、フレームの終り（またはフィールドの終り）のトークンを待ってから、表示情報および制御信号をキャプチャすることを始める。表示情報および／または制御信号がキャプチャされるにつれ、シグネーチャアルゴリズムを使用して、キャプチャされた表示情報および制御信号をシグネーチャに追加することができる。ＳＡＲがどれだけの数のフレームをキャプチャするように命令されているかに応じて、ＳＡＲは、それぞれ、要求されたフレームのすべてをキャプチャしてしまうまで、キャプチャすることを続けることができる。各ＳＡＲは、それぞれのディスプレイ・チャネルに関するフロー制御情報（たとえば、フィールド／フレームの始まりおよび／または終りのトークン）に基づいてキャプチャを開始し、終了することができる。ＳＡＲが要求されたシグネーチャをキャプチャすると、キャプチャされたシグネーチャは、２５１１で示すとおり、既知の機能しているシステムによって、またはシミュレーションによって生成された既知のシグネーチャと比較される。
【０２００】
以上の開示が十分に理解されると、多数の変形形態および変更形態が、当分野の技術者には明白となろう。頭記の特許請求の範囲は、すべてのそのような変形形態および変更形態を包含していると解釈されるものとする。
【図面の簡単な説明】
【０２０１】
【図１】通常のコンピュータ・システムおよびディスプレイを示す図である。
【図２】コンピュータ・システムの一実施形態を示す図である。
【図３】グラフィックス・システムの一実施形態を示す図である。
【図４】グラフィックス・システムに含まれることが可能なメディア・プロセッサの一実施形態を示す図である。
【図５】グラフィックス・システムに含まれることが可能なハードウェア・アクセラレータの一実施形態を示す図である。
【図６】グラフィックス・システムに含まれることが可能なビデオ出力プロセッサの一実施形態を示す図である。
【図７】デュアル・チャネル・デマンド駆動型ビデオ出力プロセッサの一実施形態を示す図である。
【図８】デュアル・チャネル・デマンド駆動型ビデオ出力プロセッサの別の実施形態を示す図である。
【図９】２つのディスプレイ・チャネル間で出力パイプラインを共用する方法の一実施形態を示す図である。
【図１０Ａ】２つのディスプレイ・チャネル間で出力パイプラインを共用する方法の別の実施形態を示す図である。
【図１０Ｂ】２つのディスプレイ・チャネル間で出力パイプラインを共用する方法の別の実施形態を示す図である。
【図１１Ａ】フレーム・バッファの一実施形態を示す図である。
【図１１Ｂ】３Ｄ−ＲＡＭの一実施形態を示す図である。
【図１２Ａ】非効率を減らす仕方で２つの要求ストリームの間で仲裁を行う方法の一実施形態を示す図である。
【図１２Ｂ】フレーム・バッファの非効率を減らす仕方で２つの要求ストリームの間で仲裁を行う方法の一実施形態を示す図である。
【図１２Ｃ】フレーム・バッファの非効率を減らす仕方で２つの要求ストリームの間で仲裁を行う方法の別の実施形態を示す図である。
【図１３】ピクセル書込みコントローラの一実施形態を示す図である。
【図１４】書込みアドレス生成器の一実施形態を示す図である。
【図１５】ピクセルを並べ替える方法の一実施形態を示す流れ図である。
【図１６】ピクセルを並べ替える方法の別の実施形態を示す流れ図である。
【図１７】複数のディスプレイ・チャネルを同期させるように構成されたグラフィックス・システムの一実施形態を示す図である。
【図１８】表示タイミング生成器の一実施形態を示す図である。
【図１９】一実施形態による同期信号および帰線消去期間を示す図である。
【図２０】複数のディスプレイ・チャネルを同期させる方法のそれぞれ異なる実施形態を示す図である。
【図２１】フレーム・バッファ・イメージの一部分をパンするように構成されたグラフィックス・システムの一実施形態を示す図である。
【図２２】フレーム・バッファ・イメージをパンする方法の一実施形態を示す図である。
【図２３】複数のシグネーチャ解析レジスタを含むグラフィックス・システムの一実施形態を示す図である。
【図２４】シグネーチャ解析レジスタの一実施形態を示す図である。
【図２５】表示情報のフレームからシグネーチャをキャプチャする方法の一実施形態を示す図である。
【図１】
2004536388.tif 000008
【図２】
2004536388.tif 000009
【図３】
2004536388.tif 000010
【図４】
2004536388.tif 000011
【図５】
2004536388.tif 000012
【図６】
2004536388.tif 000013
【図７】
2004536388.tif 000014
【図８】
2004536388.tif 000015
【図９】
2004536388.tif 000016
【図１０Ａ】
2004536388.tif 000017
【図１０Ｂ】
2004536388.tif 000018
【図１１Ａ】
2004536388.tif 000019
【図１１Ｂ】
2004536388.tif 000020
【図１２Ａ】
2004536388.tif 000021
【図１２Ｂ】
2004536388.tif 000022
【図１２Ｃ】
2004536388.tif 000023
【図１３】
2004536388.tif 000024
【図１４】
2004536388.tif 000025
【図１５】
2004536388.tif 000026
【図１６】
2004536388.tif 000027
【図１７】
2004536388.tif 000028
【図１８】
2004536388.tif 000029
【図１９】
2004536388.tif 000030
【図２０】
2004536388.tif 000031
【図２１】
2004536388.tif 000032
【図２２】
2004536388.tif 000033
【図２３】
2004536388.tif 000034
【図２４】
2004536388.tif 000035
【図２５】
2004536388.tif 000036
【国際公開パンフレット】
2004536388.tif 000037
2004536388.tif 000038
2004536388.tif 000039
2004536388.tif 000040
2004536388.tif 000041
2004536388.tif 000042
2004536388.tif 000043
2004536388.tif 000044
2004536388.tif 000045
2004536388.tif 000046
2004536388.tif 000047
2004536388.tif 000048
2004536388.tif 000049
2004536388.tif 000050
2004536388.tif 000051
2004536388.tif 000052
2004536388.tif 000053
2004536388.tif 000054
2004536388.tif 000055
2004536388.tif 000056
2004536388.tif 000057
2004536388.tif 000058
2004536388.tif 000059
2004536388.tif 000060
2004536388.tif 000061
2004536388.tif 000062
2004536388.tif 000063
2004536388.tif 000064
2004536388.tif 000065
2004536388.tif 000066
2004536388.tif 000067
2004536388.tif 000068
2004536388.tif 000069
2004536388.tif 000070
2004536388.tif 000071
2004536388.tif 000072
2004536388.tif 000073
2004536388.tif 000074
2004536388.tif 000075
2004536388.tif 000076
2004536388.tif 000077
2004536388.tif 000078
2004536388.tif 000079
2004536388.tif 000080
2004536388.tif 000081
2004536388.tif 000082
2004536388.tif 000083
2004536388.tif 000084
2004536388.tif 000085
2004536388.tif 000086
2004536388.tif 000087
2004536388.tif 000088
2004536388.tif 000089
2004536388.tif 000090
2004536388.tif 000091
2004536388.tif 000092
2004536388.tif 000093
2004536388.tif 000094
2004536388.tif 000095
2004536388.tif 000096
2004536388.tif 000097
2004536388.tif 000098
2004536388.tif 000099
2004536388.tif 000100
2004536388.tif 000101
2004536388.tif 000102
2004536388.tif 000103
2004536388.tif 000104
2004536388.tif 000105
2004536388.tif 000106
2004536388.tif 000107
2004536388.tif 000108
2004536388.tif 000109
【国際公開パンフレット（コレクトバージョン）】
2004536388.tif 000110
2004536388.tif 000111
【手続補正書】
【提出日】平成15年8月4日(2003.8.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
選択された第１の要求を受け取ったことに応答して表示情報を出力するように構成されたフレーム・バッファと、
複数のディスプレイ・チャネルに対応する複数の第１の要求の間で仲裁を行い、前記第１の要求のなかの選択された１つを前記フレーム・バッファに転送するように構成された第１のアービタと、
ピクセルを記憶し、前記フレーム・バッファによって出力された前記表示情報に対応するピクセルを受け取り、選択されたピクセル要求を受け取ったことに応答して１つまたは複数のピクセルを出力するように構成されたピクセル・バッファと、
複数のピクセル要求を受け取り、前記ピクセル要求のなかの選択された１つを前記ピクセル・バッファに転送するように構成されたピクセル要求アービタと、
表示データをディスプレイに提供し、ピクセル要求を生成するようにそれぞれが構成され、前記ピクセル・バッファによって出力されたピクセルを受け取るように構成された複数の表示出力待ち行列とを含むグラフィックス・システム。
【請求項２】
前記フレーム・バッファから前記表示情報を受け取り、前記表示情報をスクランブル解除するように構成されたスクランブル解除器をさらに含む請求項１に記載のグラフィックス・システム。
【請求項３】
前記スクランブル解除器が、複数のピクセルをラスタ順に配列し、前記ピクセルを前記ピクセル・バッファに出力するようにさらに構成された請求項２に記載のグラフィックス・システム。
【請求項４】
ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、１つまたは複数の索引付き色マップ（ＣＬＵＴＳ）、および現在のカーソル位置のうち少なくとも１つを使用して、前記ピクセル・バッファによって出力された前記１つまたは複数のピクセルを処理するように構成されたピクセル処理パイプラインをさらに含む請求項１に記載のグラフィックス・システム。
【請求項５】
前記表示情報が、ピクセルまたはサンプルを含む請求項１に記載のグラフィックス・システム。
【請求項６】
前記ピクセル・バッファが各チャネルに関するピクセル待ち行列を含み、前記第１のアービタが、前記ピクセル・バッファ内の各チャネルのピクセル待ち行列内のピクセルのレベルを比較することによって前記第１の要求のうち前記選択された１つを選択するようにさらに構成され、第１のチャネルのピクセル待ち行列レベルがしきい値を下回っており、かつ第２のチャネルのピクセル待ち行列レベルが前記しきい値を上回っている場合、前記第１のチャネルの要求が前記選択される第１の要求である請求項１に記載のグラフィックス・システム。
【請求項７】
前記第１のチャネルのピクセル待ち行列レベルも、前記第２のチャネルのピクセル待ち行列レベルも前記しきい値を下回っていない場合、いずれのチャネルの要求も選択されない請求項６に記載のグラフィックス・システム。
【請求項８】
（ａ）前記第１のチャネルのピクセル待ち行列レベルと前記第２のチャネルのピクセル待ち行列レベルがともに前記しきい値を下回っており、かつ（ｂ）前記第１のチャネルの不足分が前記第２のチャネルの不足分より大きい場合、前記第１のチャネルの要求が前記選択される要求である請求項６に記載のグラフィックス・システム。
【請求項９】
前記第１のアービタは、どのディスプレイ・チャネルが前記選択された第１の要求に対応するかについて前記フレーム・バッファに指示するようにさらに構成された請求項１に記載のグラフィックス・システム。
【請求項１０】
前記ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに関する第１の要求をアサートするようにそれぞれが構成された複数の第１のリクエスタをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１１】
それぞれの第１のリクエスタが、対応するディスプレイ・チャネルに関する第１の垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に第１の要求をアサートするように構成された請求項１０に記載のグラフィックス・システム。
【請求項１２】
前記ディスプレイ・チャネルの１つにそれぞれが対応し、対応するディスプレイ・チャネルに関してピクセル要求をアサートするようにそれぞれが構成された複数のピクセル・リクエスタをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１３】
各ピクセル・リクエスタが、対応するディスプレイ・チャネルに関する表示出力待ち行列のレベルがあるしきい値を下回って低下したときにピクセル要求をアサートするように構成された請求項１２に記載のグラフィックス・システム。
【請求項１４】
前記ピクセル要求アービタが、どのチャネルが最も長い間サービスを受けていないかを判定し、そのチャネルに対するデータが前記ピクセル・バッファ内に用意されている場合、そのチャネルのピクセル要求を選択することによって前記ピクセル要求の前記選択された１つを選択するようにさらに構成されている請求項１に記載のグラフィックス・システム。
【請求項１５】
前記ピクセル要求アービタが、前記最も長い間サービスを受けていないチャネルに対するデータが前記ピクセル・バッファ内に用意されておらず、次に長い間サービスを受けていないチャネルに対するデータが前記ピクセル・バッファ内に用意されている場合、前記次に長い間サービスを受けていないチャネルに対応するピクセル要求の１つを選択するようにさらに構成された請求項１４に記載のグラフィックス・システム。
【請求項１６】
第１の表示出力待ち行列からピクセルを受け取り、アナログ表示データをＣＲＴモニタを含む第１のディスプレイに出力するように構成されたＤＡＣをさらに含む請求項１に記載のグラフィックス・システム。
【請求項１７】
第１のディスプレイ・チャネルが、表示データをデジタル・ディスプレイに出力する請求項１に記載のグラフィックス・システム。
【請求項１８】
第１のディスプレイ・チャネルが、表示データをガスプラズマ・ディスプレイに出力する請求項１に記載のグラフィックス・システム。
【請求項１９】
複数のディスプレイ・チャネルの間でグラフィックス・システム・リソースを共用する方法であって、
前記ディスプレイ・チャネルの１つにそれぞれが対応する表示情報を求める複数の第１の要求をアサートすること、
前記第１の要求のうち１つを選択し、前記選択された第１の要求を転送することによって前記第１の要求の間で仲裁を行うこと、
前記選択された第１の要求を前記転送することに応答して表示情報を出力すること、
前記ディスプレイ・チャネルの１つにそれぞれが対応するピクセルを求める複数の第２の要求をアサートすること、
前記第２の要求のうち１つを選択し、前記選択された第２の要求を転送することによって前記第２の要求の間で仲裁を行うこと、および
前記選択された第２の要求を前記転送することに応答して、出力された表示情報に対応する１つまたは複数のピクセルを出力することを含む方法。
【請求項２０】
複数の第１の要求をアサートすることが、対応するディスプレイ・チャネルが表示情報を必要とするかどうかを判定し、必要とする場合、そのディスプレイ・チャネルを求める第１の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２１】
複数の第１の要求を前記アサートすることが、対応するディスプレイ・チャネルに関する第１の垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に前記対応するディスプレイ・チャネルに関する第１の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２２】
複数の第２の要求を前記アサートすることが、対応するディスプレイ・チャネルの表示出力待ち行列内のピクセルのレベルが第１のしきい値を下回って低下したことに応答して前記対応するディスプレイ・チャネルに関する１つまたは複数の第２の要求をアサートすることを含む請求項１９に記載の方法。
【請求項２３】
前記表示情報を前記出力することの後に前記表示情報をスクランブル解除することをさらに含む請求項１９に記載の方法。
【請求項２４】
前記ピクセルを前記出力することの後に前記ピクセルを処理することをさらに含み、前記処理することが、ウインドウ・ルックアップ・テーブル（ＷＬＵＴ）、ガンマ補正ルックアップ・テーブル（ＧＬＵＴ）、１つまたは複数の索引付き色マップ（ＣＬＵＴＳ）、および現在のカーソル位置のうち１つまたは複数を使用することを含む請求項１９に記載の方法。
【請求項２５】
表示データをディスプレイに出力することをさらに含み、前記表示データが前記ディスプレイ向けにフォーマットされ、前記出力することによって出力された１つまたは複数のピクセルに対応する請求項１９に記載の方法。
【請求項２６】
ＤＡＣを使用して前記１つまたは複数のピクセルをアナログ信号に変換することをさらに含み、前記ディスプレイがＣＲＴを含む請求項２５に記載の方法。
【請求項２７】
前記第１の要求のうち１つを前記選択することが、
１つだけの第１の要求がアサートされた場合、ピクセル・バッファ内でその第１の要求の対応するディスプレイ・チャネルのブロック待ち行列内のデータのレベルがしきい値を下回っている場合、前記第１の要求を選択すること、および
複数の第１の要求がアサートされた場合、前記第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルの複数が前記しきい値を下回っているかどうかを判定し、１つだけの第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルが前記しきい値を下回っている場合、その第１の要求を選択し、あるいは、複数の第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルが前記しきい値を下回っている場合、そのチャネルのブロック待ち行列のデータ・レベルと前記しきい値の間の不足分が最大であるディスプレイ・チャネルに対応する第１の要求を選択することを含む請求項１９に記載の方法。
【請求項２８】
前記第１の要求の対応するディスプレイ・チャネルのブロック待ち行列のデータ・レベルのいずれも前記しきい値を下回っていない場合、前記選択することが前記第１の要求のいずれも選択しないことを含む請求項２７に記載の方法。
【請求項２９】
前記第２の要求のうち１つを前記選択することが、
１つだけの第２の要求がアサートされた場合、その第２の要求の対応するディスプレイ・チャネルに対してピクセル・バッファ内にピクセルが用意されている場合、その要求を選択すること、および
複数の第２の要求がアサートされた場合、最も長い間サービスを受けていないディスプレイ・チャネルに対して前記ピクセル・バッファ内にピクセルが用意されている場合、前記最も長い間サービスを受けていないディスプレイ・チャネルに対応する第２の要求を選択することを含む請求項１９に記載の方法。
【請求項３０】
前記最も長い間サービスを受けていないディスプレイ・チャネルに対してピクセルが用意されていない場合、前記第２の要求のうち１つを前記選択することが、前記ピクセル・バッファ内に用意されているピクセルを有する次に長い間サービスを受けていないディスプレイ・チャネルに対応する第２の要求を選択することを含む請求項２９に記載の方法。
【請求項３１】
複数のディスプレイ・チャネルのそれぞれ１つにそれぞれが対応し、それぞれのディスプレイ・チャネルの垂直帰線消去期間の終りの直前に始まり、次の垂直帰線消去期間の始まりの直前に終わる期間中に少なくとも１つの要求を出力するようにそれぞれが構成された複数の表示情報リクエスタと、
表示情報を記憶し、ディスプレイ・チャネルの１つに対応する選択された要求を受け取ったことに応答して前記複数のディスプレイ・チャネルの前記１つに前記表示情報の一部分を出力するように構成された表示情報バッファと、
前記表示情報リクエスタから要求を受け取り、前記要求のうち１つを選択し、前記要求のうち前記選択された１つを前記表示情報バッファに転送するように構成された仲裁論理とを含むグラフィックス・システム。
【請求項３２】
前記表示情報バッファが、フレーム・バッファを含み、前記表示情報バッファが、前記選択された要求を受け取ったことに応答して表示情報のバーストを出力するようにさらに構成された請求項３１に記載のグラフィックス・システム。
【請求項３３】
前記表示情報バッファが、ピクセル・バッファを含み、前記表示情報バッファが、前記選択された要求を受け取ったことに応答してピクセルのペアを出力するようにさらに構成された請求項３１に記載のグラフィックス・システム。
【国際調査報告】
2004536388.tif 000112
2004536388.tif 000113
2004536388.tif 000114