JP2009514124A - マルチユーザ端末サービス促進装置 - Google Patents

Abstract

マルチユーザ・ホスト・コンピュータ・システムは、アプリケーション及び多数のリモート端末のためのデスクトップ環境を処理するホスト・コンピュータを備えている。ホスト・コンピュータは、ホストＣＰＵの処理を補う端末サービス・オフロード・プロセッサを含む。リモート端末毎に、端末サービス・オフロード・プロセッサは、ビデオ及びグラフィクス性能を向上させることができ、マルチユーザ・ホスト・コンピュータ・システムが一層効率的に多数のユーザをサポートすることを可能にする。ホスト・コンピュータは、リモート端末毎に仮想表示を管理し、サブ・フレーム・データの選択的更新を行うグラフィクス・プロセッサを含むこともできる。該当する場合には、サブ・フレーム・データをエンコードし、ネットワークを通じてリモート端末に送信する。ビデオ・データ・ストリームも、端末サービス・オフロード・プロセッサによって最適化し、更に意図するリモート端末及びそれらそれぞれのネットワーク接続に合わせて最適化する。端末サービス・オフロード・プロセッサは、プログラム可能なハードウェアで実施することができ、別個のサブシステムとしてもよく、あるいは他のオフロード・タスクを実行するために用いてもよい。

Description

本発明は、一般的には、マルチユーザ・ホスト・コンピュータ・システムに関し、更に特定すれば、リモート・クライアントのための効果的な端末サービスのサポートに関する。

効率的なマルチユーザ・コンピュータ・システムを開発することは、現在のシステム設計者及び製造業者にとって重要な目的である。
従来のコンピュータ・システムは、ローカル・ディスプレイ・デバイスを利用して、出力を直接一人のユーザに表示することがあった。ローカル・ディスプレイ・デバイスは、該ディスプレイ・デバイスをコンピュータ・システムの出力に電気的に結合する種々の物理的接続によって強制される制約のために、通例、コンピュータ・システムに近接して位置付けられている。コンピュータ・システムの中には、第２ディスプレイ・デバイスをサポートする場合もあるが、物理的接続のために同様の近接の制約がある。

リモート・ユーザは、しかるべき目視場所及びホスト・システムへのネットワーク接続を選択する柔軟性が必要となる。例えば、会社環境においては、ある業務では、物理的セキュリティと、空調及び電源バックアップ・システムのような環境管理との双方を有する、安全を確保した拠点である「コンピュータ室」にホスト・コンピュータを全て保持することが望まれる場合がある。しかしながら、ユーザは、「コンピュータ室」の外側に位置する彼らの事務所や机からホスト・コンピュータ・システムを利用する必要がある。

今日、典型的な事務所環境では、パーソナル・コンピュータや、機能がますます少ないのクライアントを含み、これらはユーザの場所に物理的に配置されている。これらのパーソナル・コンピュータや少機能クライアントは、集中記憶システム、ファイル提供、ファイル共有、ネットワーク管理、及び種々の管理運営サービスを有するネットワーク上で動作する。初期の頃では、システムは、コンピュータ・システムと関連のあるディスク・ストレージの全てを集中させ、一方ユーザは彼らのローカル・デスクトップ上でアプリケーションをランさせていた。最近になって、セキュリティの便益、動作コスト削減、及び総合的な集中制御に対する要望が認識され、パーソナル・コンピュータ及び少機能クライアントは、サーバ上でアプリケーションをランさせるサーバ・ベースの計算（ＳＢＣ）ソリューションにおけるリモート端末（ＲＴ）として動作することができるようになった。

ＳＢＣ環境におけるＲＴに対する従前からの手法は、殆どのシステムにとって、Microsoft社のRemote Display Protocol（ＲＤＰ）のような、ある形態のクライアント通信交換に対するサーバを用いることである。ＲＤＰは、それ自体のビデオ・ドライバをサーバ上で用い、更にＲＤＰプロトコルを用いて、レンダリング情報をネットワーク・パケットに組み立て、ネットワークを通じてクライアントにこれらを送る。クライアントは、レンダリング・データを受信し、パケットを解釈して、対応するMicrosoft Win32 Graphics Device Interface（ＧＤＩ）API コールを得る。クライアント・キーボード及びマウス・コマンドをサーバに再送出すること、ローカル・オーディオ及びローカル・クライアント・ドライブを管理することに対するサポートも含まれる。

ホスト・システムとクライアントとの間の通信を強化するために、他のシステムはホスト・コンピュータの主ＣＰＵを用いてＲＴの性能を向上させている。これは、少機能クライアント及び従前からのＰＣ双方に対して、リモート・クライアントとして行われている。このような手法は、一度に一人のユーザのみをサポートするホスト・システムには有効であった。しかしながら、マルチユーザ・システムでは、ホストにおいて主ＣＰＵを用いてあらゆるユーザに対する性能を向上させるという手法には、厳しい限界がある。主メモリやＣＰＵサイクルのような計算資源が、一人のユーザの最適化のために用いられ、追加のユーザのために作業負荷をサポートする能力が低下する虞れがある。

１台のホスト・コンピュータから多数のユーザを効率的にサポートすれば、コストを削減することができる。典型的な事務所環境では、誰もが同時に彼らのコンピュータを用いていることは殆どなく、いずれか一人のユーザが彼らのコンピュータの計算資源全てを用いていることも殆どない。例えば、事務所が１００室ある会社の場合、いずれの時点でも６０人のユーザをサポートするシステムがあれば十分な場合もある。とは言っても、このようなシステムを設計するとすれば、１００人のユーザ全てをサポートするように設計し、彼らが各々自分自身のホスト・コンピュータを有するような外観を与えるように、彼らに十分な計算スループットを与える可能性がある。

多数のＣＰＵを含むことによってホスト・コンピュータの性能が増々向上し、ＣＰＵは多数のプロセッサ・コアを有するため、一人のユーザを１台のコンピュータに制限することは、経済的な意味が薄れつつある。一部のＲＴをローカル・エリア・ネットワーク（ＬＡＮ）を通じてマルチユーザ・ホスト・システムにローカルに接続することができるが、他のＲＴはワイド・エリア・ネットワーク（ＷＡＮ）を通じて接続され、これらはホスト・システムに対するネットワーク接続性能が低下する。
世界の異なる地域の場所にＲＴを配した分散型事務所環境では、集中マルチユーザ・システムが、それぞれの時間帯に対して異なる作業時間中に、世界の異なる地域をサポートすることができる。

サーバ・ベースの計算は、ユーザ用アプリケーションがサーバ上でランし、ＲＴサービスのみをユーザ端末においてサポートするが、これは多数のユーザに計算資源を一層効率的に割り振る別のやり方である。ＳＢＣにより、ホスト・システムは、メモリやＣＰＵサイクルのような共有資源を、最も優先順位が高いユーザに動的に割り振ることが可能になる。ＳＢＣシステムは、仮想機械（ＶＭ）の技法、負荷均衡、及びその他の手段を採用し、多数の判断基準に基づいて、異なるレベルの性能及び資源に、異なるユーザのアクセスを付与することができる。ＳＢＣ資源を割り振るために、異なる優先順方式を用いることができる。ＳＢＣは、データ・セキュリティを一層高め、組織のサポート、災害復旧の強化及び業務の継続を集中し、組織全体にわたるデータ記憶の必要性を低減する手段として用いることができる。

しかしながら、組織が有すると考えられる種々のＲＴデバイスに合わせて豊富な用途の遂行を効果的に管理し、制御し、届けるためには、マルチユーザ・ホスト・コンピュータを更に複雑にする必要がある場合もある。マルチユーザ・ホスト・システムが、傑出した計算及び表示性能によって、多数のリモート・ユーザを一層効率的にサポートすることを可能にする解決策が求められている。

本発明は、インタラクティブ・グラフィクス及びビデオが可能な１つ以上のリモート・端末を含むマルチユーザ・コンピュータ・システムにおいて、ホスト又はサーバ・システムのために効率的なアーキテクチャを提供する。ホスト・システムは、総合的に、アプリケーションを管理し、サーバに基づく計算を実行する。各ＲＴはそれ自体のキーボード、マウス、及びディスプレイを有し、ならびにその他の周辺デバイスも有することもある。ＲＴは、個々のユーザに、サーバ上のアプリケーションへのアクセス、及び豊富なグラフィカル・ユーザ・インターフェースを提供する。

第１の好適な実施形態では、ホスト・システムは、端末サービス促進装置（ＴＳＡ）と呼ばれる補助プロセッサを含み、端末サービス促進装置は、ＲＴ毎にリモート・グラフィクス・プロトコルを管理する計算タスクをオフロードさせる。ＴＳＡによって、マルチユーザ・ホスト・コンピュータは、種々の異なる帯域幅の提案(solution)を跨いでネットワークすることができる多種多様のＲＴを適応的にサポートするために経済的に調整することが可能となる。ＴＳＡは、構成変更可能なプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）又はハードウェア・ブロックの形態をなす処理エレメントを含み、ホストからのオフロードを最良に実行し、更に種々の端末をサポートするジョブを改良して実行することができる。オフロードは、グラフィクス・コマンドのネットワーク・パケットへのカプセル化、通信チャネルを更に効率的に用いることができるような異なるデータ・ブロックのエンコード、及びＲＴ毎のキャッシュ・データの追跡を含むことができる。ローカル端末をサポートするために、ホスト・システム内にローカル・グラフィクス・プロセッサがある可能性が高いが、これはＲＴ用サポート・システムの一部ではない。ＴＳＡは、ローカル・グラフィクスを処理し、遠隔ＫＶＭ管理能力を設けることができる。

第２の好適な実施形態では、ホスト・コンピュータがソフトウェア、グラフィクス・プロセッサ、及びデータ・エンコードを利用して、ＲＴ毎に仮想表示環境を作成し、そのために最小限のコマンド又はデータだけを伝達すればよいようにすることによって、多数のＲＴをサポートする。ＲＴとの通信のための最もありふれた方法では、カプセル化したグラフィクス・コマンドを送るか、又はエンコードしたサブ・フレーム・データを送ることを含む。ＲＴを管理するソフトウェアは、第１実施形態におけるように、ホストＣＰＵ上又はＴＳＡ上のいずれかでランすることができ、あるいはこれら２つの組み合わせにおいてランすることもできる。ＲＴ毎の選択的更新を、ソフトウェアで又はグラフィクス・プロセッサにおけるハードウェアの補助によって調整することができる。グラフィクス・プロセッサは、提案されているＶＥＳＡディジタル・パケット・ビデオ・リンク（ＤＰＶＬ）規格、又はサブ・フレームにステータス・ビット又は署名を用いる改良した方法に従うことができる。別の強化方法では、ＰＣＩエクスプレス又は別のバスを、出力データ用ＤＶＩの代わりに用いて、グラフィクス・プロセッサ内において又はグラフィクス・プロセッサに取り付けたエンコーダによって、追加のデータ・エンコードを実行し、ソフトウェアは、マルチユーザ・サポートのために、１つの仮想グラフィクス・プロセッサを利用する。

各実施形態は、更に、追跡ソフトウェアをＴＳＡと共に用いることによってホストＣＰＵからオフロードさせ、ビデオ再生のような機能を傍受(intercept)することができる。ホストＣＰＵにビデオ・デコードをローカルに実行させ、ＲＴに伝送するためにビットマップを供給させる代わりに、ＴＳＡは、ＣＰＵによるデコードの前に、ビデオ・データ・ストリームを傍受することができ、ネイティブなビデオ・ストリーム、あるいはトランスコード又はレート変更したバージョンのような、修正バージョンを、目標のＲＴに伝達することができる。ＲＴへの通信には、標準的なＲＤＰチャネルに加えて、その他の私的チャネルを採用することができるが、その場合でもＲＤＰプロトコルの中で管理する。

各実施形態のホスト・システムにおいて、データをカプセル化又はエンコードした後、ネットワーク・プロセッサ、又は更に単純なネットワーク・コントローラと共に動作するＣＰＵは、有線及び／又はワイヤレス・ネットワークを通じて、グラフィクス・パケットをＲＴに送信する。各ＲＴシステムは、その表示を意図するグラフィクス・パケットをデコードし、フレーム更新を管理し、表示画面に必要な処理を実行する。ネットワーク送信中に失われたパケットを隠蔽するというようなその他の機構は、リモート・ディスプレイ・システムによって管理する。新しいフレーム更新がない場合、リモート・ディスプレイ・コントローラは、直前のフレームからのデータによって、表示画面をリフレッシュする。

本システムは、種々の有線及び無線ネットワーク接続からホスト・システムＣＰＵ、ＴＳＡ、及びデータ・エンコード・システムに、ネットワーク情報をフィードバックすることができる。ホスト・システムは、ＲＴ更新を生成する種々の処理ステップに影響を及ぼすためにネットワーク情報を用い、ネットワーク・フィードバックに基づいて、異なるＲＴに合わせてフレーム・レート及びデータ・エンコードを様々に変更することができる。加えて、ノイズが多い送信チャネルを有するネットワークを含むシステムでは、エンコード・ステップを前進誤り訂正保護と組み合わせて、送信チャネルの特性に合わせて送信データを用意することができる。これらのステップの組み合わせによって、ＲＴの各々について、低いレイテンシで最適なフレーム・レートを維持する。ＴＳＡは、別個のサブシステムとして実施することができ、あるいは、ネットワーク・プロセッサ、セキュリティ・プロセッサ、ＸＭＬアクセレレータ（促進装置）、ｉＳＣＳＩプロセッサ、又はこれらの任意の組み合わせ等の、他のオフロード及び促進処理と組み合わせることもできる。

したがって、少なくとも上記した理由により、本発明は、システムの相互動作性及び機能性を容易に得るために種々の異質なコンポーネントを利用する、柔軟性の高いマルチユーザ・コンピュータ・システムを効果的に実現する。つまり、本発明は、強化したマルチユーザ・サーバを実現する。

本発明は、マルチユーザ・リモート端末（ＲＴ）コンピュータ・システムにおける改良に関する。記載する実施形態はマルチユーザＲＴコンピュータ・システムに関するが、同じ原理及び特徴は、他の形式の単一ユーザ・システム及び他の形式の少機能クライアントにも等しく適用することができる。

図１を参照すると、本発明は、マルチユーザ・コンピュータ・システム１００の効率的なアーキテクチャを提供する。マルチユーザ・サーバに基づくコンピュータ１２０を「ホスト１２０」と称し、これは、各々が何らかの形態のリモート端末を利用する多数のユーザのためにアプリケーションを処理する。ローカル端末１１０は、主に、ユーザ毎に、又は管理運営タスク用として備えられており、ホスト１２０は、表示更新ネットワーク・ストリームを、ＲＴ３００、３０２、３０４等に向かう優先ネットワーク２９０上、又はディスプレイ３０６に向かうワイヤレス・ネットワーク２９０上において生成する。ＲＴにおけるユーザは、ホスト・コンピュータ１２０があたかもそれ自体のローカル・コンピュータであるかのように時間共有し、グラフィクス、テキスト、及びビデオ・コンテンツのあらゆる形式に対して完全なサポートを有し、同じ形式のユーザ操作(user experience)をローカル・コンピュータ上で行うことができる。追加の接続部２９２は、ＷＡＮ、記憶サブシステム、他のホストへのネットワーク接続部、又は種々のその他のデータ中央接続部とすることができ、GigE、１０Ｇイーサネット、iSCSI、Fiber Channel（ＦＣ）、Fiber Channel IP（ＦＣＩＰ）、あるいはその他の電気的又は光学的接続の形態を取ることができる。接続部２４２は、他のデータ又はビデオ・ソースをホスト・システム１２０に接続することができる。

本明細書全体を通じて、「ホスト」とは、マルチユーザ・サーバに基づく演算をサポートする種々のやり方で構成することができる、ホスト１２０、ホスト２００、又はホスト４００を指す。多数のホスト１２０を纏めてクラスタ化し、動的に共有することができる演算資源を形成することもできる。各ホスト１２０の内部では、多数のコンピュータ・ホスト２００を纏めてブレードの形態で一団とし、バックプレーンを通じて接続されているラックに入れるか、又はその他のマルチプロセッサ構成にすることもできる。種々のマルチユーザ・オペレーティング・システム（ＯＳ）又は単一ユーザＯＳを仮想化するソフトウェアを、１つ以上のプロセッサ・ブレード又はマザーボード上に展開することができる。Citrix又はWindows Serverのようなオペレーティング・システムは、マルチユーザＯＳとして設計されている。Windows XPは、特定的に多数のユーザに向けて設計されているのではないが、VMWARE又はXen Sourceのような下位仮想化ソフトウェア、あるいはマルチユーザＯＳのように思われる程に素早くユーザの切換を行う他の手段の補助により、このような構成において用いることができる。異なる管理制御により、ＲＴ及びプログラムを統計的又は動的にプロセッサ間で移動させることが可能になる。プロセッサ毎にＯＳによって負荷均衡を実行することができ、あるいはシステムが多数のプロセッサに跨る負荷均衡を実行することもできる。

図２は、サーバ・システムの１つのブレード２００のブロック図であり、各ブレードがそれ自体でホスト・コンピュータ１２０となることができ、あるいは多数のブレードを纏めて収容し更に能力を高めたホスト・コンピュータ１２０を作成することもできる。本発明の一実施形態によれば、単一ブレード（マザーボード）システム２００又は多数のブレード２００のいずれかを、マルチユーザ・システム１００に用いることができる。ホスト・システム１２０が有するブレード及びＣＰＵが多い程、多くのユーザを同時にサポートすることができる。ホスト・コンピュータ２００の基本コンポーネントは、好ましくは、ＣＰＵサブシステム２０２、バス・ブリッジ・コントローラ２０４、ＰＣＩエクスプレスのような主システム・バス２０６、ローカルＩ／Ｏ２０８、主ＲＡＭ２１０、ならびにグラフィクス及び表示コントローラ２１２を含み、それ自体のメモリ２１８も含むことができる。グラフィクス及び表示コントローラ２１２は、ローカル端末１１０へのローカル接続２２２を可能にするインターフェース２２０を有することができる。プログラム・ソース及びマルチメディア・ビットストリームが、ホスト・コンピュータ２００に、ネットワーク・インターフェース２９０の１つを通じて、又はＩ／Ｏパス２４６を備えたプログラム・ソース２４０の１つを通じて入力することができる。また、ネットワーク・コントローラ２２８は、表示更新ストリームを処理し、種々のＲＴ３００〜３０６等に１つ以上のネットワーク接続部２９０を通じてネットワーク通信を提供する。これらのネットワーク接続部は、有線でも無線でもよい。

他の構成では、１つ以上のＣＰＵサブシステム２０２が、グラフィクス及びビデオ表示コントローラ２１２ならびに端末サービス促進装置２２４のようなデバイスを１つ以上共有することもできる。その他のシステムを区分することもでき、その場合、ネットワーク・コントローラ２２８を多数のホスト・システム２００によって共有することができる。システム・バス２０６は、システム内にある多数のブレード間で接続するためにバックプレーン・バス２０６に接続することができる。パス２２６は、バックプレーン・バス２０６を共有することができ、あるいはシステム間で追加のバスを有してもよい。１つ以上のネットワーク・コントローラ２２８をシステムに含めることもでき、その場合、１つを多数のリモート端末への接続部２９８０に用い、他のネットワーク・コントローラ（図示せず）が他のブレード、他のサーバ・システム、又は記憶システムのようなその他のデータ集中機器(data center equipment)へのインフラストラクチャ・ネットワーク接続を行う。各ＣＰＵサブシステム２０２は、多数のプロセッサ・コアを含むことができ、各コアは同時に１つよりも多いスレッドを実行することもできる。

ホスト・コンピュータは、端末サービス促進装置（ＴＳＡ）２２４も含むことが好ましい。端末サービス促進装置２２４は、主システム・バス２０６に接続され、ネットワーク・コントローラ２２８への出力パス２２６を有することができる。ＴＳＡ２２４は、専用ＲＡＭ２３０を含むことができ、主システムＲＡＭ２１０、グラフィクス及び表示コントローラＲＡＭ２１８、又はネットワーク・コントローラＲＡＭ２３２を共有することができる。主ＲＡＭ２１０は、ＲＡＭ２３４において示すように、ＣＰＵサブシステム２０２と一層緊密に関連付けることができる。あるいは、ホスト・システム２００が主ＲＡＭ２１０を共有することができるので、グラフィクス及び表示コントローラ２１２と関連のあるＲＡＭ２１８が不要となる場合もある。

ＴＳＡ２２４の機能は、ＲＴの各々についての管理の一部から主ＣＰＵ２０２の負担を軽減すること、そして各ＲＴが受ける表示サポートが改善するように、オフロードした処理の一部を促進することである。オフロード及び促進サポートの形式には、グラフィクス動作をリモート・グラフィクス・コマンドにカプセル化すること、どのグラフィクス・コマンドが最も適しているか判断するために、各ＲＴにおいてどの能力及びビットマップをキャッシュするか決定する際に補助すること、ＲＴに転送する必要があるビットマップをエンコード及びカプセル化すること、ならびにマルチメディア・ビットストリームを最良に管理することが含まれる。

eXtensible Markup言語（ＸＭＬ）トラフィック、Simple Object Access Protocol（ＳＯＡＰ）、ＨＴＴＰトラフィック、Java Virtual Machime（ＪＶＭ）、及びインターネット系通信と関連のあるその他のトラフィックの調査及びカプセル化のような、追加の機能もサポートすることができる。ホスト・システムは、ＴＳＡ２２４と共に、あらゆる所望のスパム防止、ウィルス防止、コンテンツ・フィルタリング、アクセス制限行使、又はその他のパケット・フィルタリングに基づくアルゴリズムを実行しつつ、ＲＴに完全なインターネットに効果的にリモート・アクセスを行わせることができる。このような追加の機能は、ホストがインターネット・アクセスのプロキシとなる、ＲＴインターネット閲覧をサポートするには特に有用であると考えられる。システムには多少の冗長性があるが、この方法は、ホスト・システムとＷＡＮとの間で利用されるインターネット・セキュリティ・アプライアンスよりも特定したユーザ制御を行うことができる。

ＲＴ上において、特殊なブラウザがインターネット系トラフィックのために別の強化を用いることもでき、その中には、ＲＴディスプレイ・デバイス及びＲＴ内部の実行能力に基づいて、インターネット系コンテンツをフォーマットし直す又はコード化し直すことを含むとよい。例えば、ＲＴデバイスがセルラ・フォン又はパーソナル・ディジタル・アシスタント（ＰＤＡ）であって、画面の解像度が限られている場合、ＴＳＡ２２４は、高解像度のコンテンツにフィルタをかけてそれよりも低い解像度の画像に落として、高速化し一層適した画像にすることができる。ＴＳＢ２２４は、その他の更にインテリジェントなコンテンツ・フィルタリング及びウェブ・ページ解釈アルゴリズムをランさせて、バナー広告及びその他の外部情報の除去というような機能を実行し、中核情報をセル・フォンに送るようにすることができる。Active-X制御、Macromedia Flash、又はその他のラン・タイム・プログラムを利用するウェブ・コンテンツのような、他の種類のウェブ・コンテンツは、電話機又はＰＤＡのようなデバイスと互換性がない場合もある。ＴＳＢ２２４は、仲介プロキシ・サーバとして作用し、表示データpost-Active-X制御を、待機中のＰＤＡに転送することができる。アプリケーション・レイヤ正規表現（RegEx）コンテンツ処理も実行することができる。再符号化も、クライアントのセキュリティを高めるために実行することができる。ＸＭＬ及びＳＯＡＰはハイジャッキング(hijacking)及びその他の形態のウィルスの受け渡しを受ける虞れがあるが、ＴＳＢ２２４はＸＭＬ及びＳＯＡＰを安全なディスプレイ・フォーマットに記録することができるので、ＲＴクライアントにはこのような危険性が及ぶことはない。

マルチメディア・ビットストリームは、ビデオ・ストリームを含むことができる。ビデオ・ストリームは既に圧縮フォーマットになっており、ホスト・システム２００に対してローカルに格納されているか、又はシステム・ネットワーク・インターフェース２９０又はプログラム・ソース・インターフェース２４６の一方を通じて受信されている。構成の中には、マルチメディア・ビットストリームが既に対象のＲＴと互換性のあるフォーマットになっている場合もある。このような場合、ＴＳＡ２２４は、ＲＴに送信するために、ビットストリームをしかるべきパケット・フォーマットにカプセル化する。カプセル化は、ビデオ表示ウィンドウの原点のような、ヘッダ情報を追加すること、又はトランスポート・ストリームを異なるパケット・サイズのプログラム・ストリームに変換することのような、パケット編成を修正することを含む場合がある。

多くの場合、マルチメディア・ビットストリームは、目標ＲＴによって容易に処理されるフォーマットになっておらず、あるいはネットワーク接続に適したフォーマットになっていない場合もある。このような場合、ＴＳＢ２２４は、マルチメディア・ビットストリームをデコードし、再度エンコードし、トランスコードし、又はレートを変更するという一層複雑なステップを実行する。例えば、着信マルチメディア・ビットストリームが、エンコードしたＨＤＴＶ ＭＰＥＧ−２ストリームである場合がある。ＲＴにおけるウィンドウ・サイズが、小さな３２０×２３０ウィンドウに合わせて設定されている場合、ネットワーク帯域幅を保存し、ＴＳＢ２２４にマルチメディア・ビットストリームをトランスコード及びレート変更させて、所望の表示ウィンドウ・サイズを表す、低いビット・レートにすることには意味があると考えられる。同様に、着信ビデオのフォーマットが、ＲＴによってデコードすることができない場合、ＴＳＢ２２４はビデオを互換性のあるフォーマットにコード変換することができる。フォーマットに互換性があっても、ディジタル権利管理（ＤＲＭ）又は暗号化方式のような、その他の非互換性が存在する場合もある。ＴＳＢ２２４は、１つのＤＲＭ又は暗号化方式を、目標ＲＴに相応しい方式に変換することもできる。

Microsoft社のRemote Desktop Protocol（ＲＤＰ）では、圧縮ビデオ・ストリームに対する処理効率が低下している。ＲＤＰによって、ホスト・システムの内部にあるドライバがビットストリームを検出し、デバイス独立ビットマップ（ＤＩＢ）にデコードする。次いで、ＤＩＢをＲＤＰ転送コマンドに変換し、ＤＩＢフォーマット・データをネットワークを通じてＲＴに転送しようとする。殆どの場合、１組のＤＩＢデータのフレームのみが表示のためにＲＴに達する。つまり、デコードを行うホストＣＰＵに非効率性があり、更にデコードしたデータを効率の低いフォーマットでネットワークを通じて送ることに非効率性がある。他のＲＤＰに基づくグラフィックス動作も同様にＤＩＢを利用する。

ウェブサイトからのグラフィックス・ビットマップのような、従来からのグラフィクス・ビットマップも、ホスト・システム２００からＲＴに転送する必要がある。ＴＳＢ２２４は、ＤＩＢのような従来のグラフィクス・ビットマップに対して種々のレベルのエンコードを実行することができる。グラフィクス・ビットマップのエンコードは、損失がない場合も、損失がある場合もあるが、元のグラフィクス品質の目視的に区別できる表現を提供することを目標とする。ＴＳＢ２２４のための簡素化したソフトウェア・インターフェースでは、単にＲＤＰ ＡＰＩを通じてホストＣＰＵとインターフェースすることだけを含む場合があり、一方、それよりも意欲的な実施態様では、ＴＳＢ２２４が基礎のDirectX ドライバ・フレームワークにアクセスすることを可能にする。エンコードしたＤＩＢの転送、及び特殊な圧縮ビデオ・ドメインの転送は、標準的なＲＤＰ実施態様の一部ではない。したがって、これらの転送は、既存のＲＤＰ転送フォーマットと抱き合わせ、ある種のプライベートＲＤＰ拡張として動作するか、又はＲＤＰフレームワークの外側で動作すればよい。

ホスト・オペレーティング・システム及びＲＤＰのバージョンの中には、ＲＤＰプロトコルに対する追加のセキュリティ要件を満たす必要がある場合もある。ＲＤＰクライアントは、ホストと鍵（キー）を交換し、暗号化パケットを利用しなければならない場合もある。ＴＳＢ２２４はＲＤＰクライアント・パケットを傍受しているので、ＴＳＢ２２４は、ホスト・プロセッサと通信するために、しかるべき促進及びオフロードを鍵交換及び解読のために含むとよい。加えて、システムのセキュリティを維持するために、ＴＳＢ２２４及びネットワーク・コントローラ２２８は、ＲＴとの全ての通信がしかるべく暗号化されていることを確認する。

図３は、本発明の一実施形態によるリモート端末３００のブロック図であり、好ましくは、表示画面３１０、ローカルＲＡＭ３１２、及びリモート端末システム・コントローラ（ＲＴＳＣ）３１４を含むが、これらに限定されるのではない。ＲＴＳＣ３１４は、キーボード、マウス、及びＩ／Ｏ制御サブシステム３１６を含む。Ｉ／Ｏ制御サブシステム３１６は、マウス３１８、キーボード３２０、及びオーディオを再生するスピーカ又は種々のデバイスをサポートすることができるユニバーサル・シリアル・バス（ＵＳＢ）接続部のような、その他の雑多のデバイスに対応する接続部を有する。バイオメトリックス又はセキュリティ・カードを含む安全確保手段によるユーザ認証をサポートするためのその他の一体又は周辺接続部も、含むことができる。接続部は、ＰＳ／２様式のキーボード又はマウス接続部のような単一目的専用とすることも、あるいはＵＳＢのように汎用性を高めることもできる。別の実施形態では、Ｉ／Ｏはゲーム・コントローラ、ローカル・ワイヤレス接続部、ＩＲ接続部を含むことができ、あるいは接続部を全く含まないことも可能である。また、リモート端末システム３００は、ＤＶＤドライブのようなその他の周辺デバイスも含むことができる。

本発明の実施形態の中には、リモート端末システム３００において外部入力を全く必要としない場合もある。このようなシステムの一例は、小売店又は電子ビルボードであり、異なる表示が異なる場所で利用可能であり、種々の情報及び娯楽情報を示すことができる。各ディスプレイは独立して動作することができ、種々の要因に基づいて更新することができる。また、同様の安全確保システムが、銀行における情報キオスクや現金自動預け払い機（ＡＴＭ）のような、タッチ・スクリーン入力を受け入れる数個のディスプレイを含むこともできる。カジノ用ゲーム機械のような、その他の安全確保システムも、この種のＲＴに基づくことができる。

ネットワーク・コントローラ３３６は、ネットワーク・パス２９０上で安全確保プロトコルをサポートし、サポートされるネットワークは、有線又はワイヤレスとすることができ、ネットワーク上を移動するデータは、鍵交換によって暗号化することができる。リモート・ディスプレイ・システム３００毎にサポートされるネットワークは、図２のネットワーク・コントローラ２２８によって、直接又は何らかの形式のネットワーク・ブリッジによってサポートされる必要がある。共通ネットワークの一例に、ある種のイーサネット、好ましくは、ギガビット・イーサネットをランさせるＣＡＴ５ワイヤリングのような、イーサネットがあり、Ｉ／Ｏ制御パスは、標準的なトランスポート制御プロトコル及びインターネット・プロトコル（ＴＣＰ／ＩＰ）又はＵＤＰ送信と組み合わせた軽量ハンドシェーキングの形態のような、イーサネットをサポートするプロトコルを用いることができる。リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）及びリアル・タイム転送プロトコル（ＲＴＰ）のような業界の成果を、リアル・タイム制御プロトコル（ＲＴＣＰ）と共に用いてパケットの転送を強化することができ、更に再送信プロトコルを追加することによって一層強化することができる。layer 3 DiffServ Code Points （ＤＳＣＰ）、Digital Living Network Alliance（ＤＬＮＡ）の一部としてのＷＭＭプロトコル、Microsoft Qwave、uPnP、QoS、及び802.1Pのような、サービス品質（ＱｏＳ）成果を用いることに関するその他の最新成果も、既存のネットワーク規格を用いる強化方法である。

Ｉ／Ｏデバイスをサポートするためのパケットに加えて、ネットワークは表示に必要な、カプセル化及びエンコードした表示コマンド及びデータも搬送する。ＣＰＵ３２４は、ネットワーク・コントローラ３３６、２Ｄ描画エンジン３３２、３Ｄ描画エンジン３３４、データ・デコーダ３２６、ビデオ・デコーダ３２８、及びディスプレイ・コントローラ３３０と調整して、表示画面３１０上にローカルにレンダリング及び表示される可能性があるあらゆる形式の仮想データ表現をサポートする。ＲＴが表示処理ブロックの任意特定の組み合わせも含む必要はない。特別に少機能のＲＴであれば、表示処理を行うＣＰＵを有するディスプレイ・コントローラ３３０だけしか含まないこともあるが、少なくとも１種類のデコーダ又は描画エンジンを有する可能性の方が高い。

最初に、ローカル・フラッシュ・メモリ（不図示）からブートし、追加情報をホスト・コンピュータ２００によってネットワークを通じて提供することにより、ＲＴを初期化することができる。ＲＴの初期化シーケンスの間、ＲＴシステム・コントローラ３１４と表示画面３１０との間の接続は、Display Data Channel（ＤＤＣ：表示データ・チャネル）インターフェース、Extended Display Identification Data （ＥＤＩＤ：拡張表示識別データ）、及び表示モニタの能力を特定するその他の拡張子のような規格を利用して、逆方向又は双方向モードで用いることができる。キーボード、マウス、及びＩ／Ｏコントローラ３１６を通じたＵＳＢ接続も、表示画面３１０への接続において用いることができる。次いで、利用可能な解像度及び制御のような情報をＣＰＵ３２４によって処理する。システム３００は、ホスト２００と通信することができるuPnPのようなプロトコル又はその他の発見メカニズムを実装することができる。その初期化通信の間、ＣＰＵ３２４は、表示モニタ情報を含むＲＴ情報をホスト２００に提供することができるので、各ＲＴをホスト側でインスタンス化することができる。

初期表示画面は、フラッシュ・メモリ又はホスト・コンピュータ２００のいずれから来てもよい。第１フレーム全体の表示データに続いて、ホスト・コンピュータ２００は、表示更新ネットワーク・ストリームの一部として、ネットワーク２９０を通じて、部分的なフレーム情報だけを送ればよい。表示の画素が直前のフレームから全く変化しない場合、ディスプレイ・コントローラ３３０は、ローカルＲＡＭストレージ３１２からの直前のフレーム内容によって表示画面３１０をリフレッシュすることができる。

表示の更新は、ネットワーク・ストリームを通じて送られ、カプセル化２Ｄ描画コマンド、３Ｄ描画コマンド、エンコード表示データ、又はエンコード・ビデオ・データで構成することができる。ネットワーク・コントローラ３２６は、ネットワーク表示ストリームを受信し、ＣＰＵ３２４は、暗号化ヘッダから、機能ユニット３３２、３３４、３２６及び３２８の内どれが、そのパケットに必要とされるか判断する。機能ユニットは、画像データをデコードし、ＲＡＭ３１２の該当するエリアを新しい画像で更新するために必要な処理ステップを実行する。次のリフレッシュ・サイクルの間、ディスプレイ・コントローラ３３０はこの更新フレームを表示画面３１０に用いる。

ディスプレイ・コントローラ３３０は、現在の画像フレームの表現をＲＡＭ３１２からディスプレイ３１０に転送する。通例、画像は、表示の準備ができたフォーマットでＲＡＭ３１２に格納されているが、ＲＡＭのコストが問題となるシステムでは、画像又は画像の一部をエンコードしたフォーマットで格納することもできる。外部ＲＡＭ３１２を、リモート端末のシステム・コントローラ３１４の内部にある大型バッファによって置き換えてもよい。また、ディスプレイ・コントローラ３３０はＲＡＭ３１２に格納されている２つ以上の表示面を組み合わせて、出力画像を合成し画面３１０に表示することもできる。異なる配合動作を、合成と共に実行することもできる。

ＣＰＵ３２４は、ＴＳＢ２２４と通信して、ＲＴに対する表示動作全体を最良に設定し管理する。初期設定には、ＲＴシステム・コントローラ３１４においてサポートされている機能の種類、表示画面３１０の仕様、データをバッファ及びキャッシュするために利用可能なＲＡＭ３１２の量、３Ｄ描画エンジン３３２がサポートするコマンド集合、３Ｄ描画エンジン３３４がサポートするコマンド集合、データ・デコーダ３２６がサポートするフォーマット、ビデオ・デコーダ３２８がサポートするフォーマット、及びディスプレイ・コントローラ３３０の能力を列挙することを含む。実行時におけるその他の管理最適化には、ＲＡＭ３１２において表示ビットマップを管理及びキャッシュし、これらをリセットしなくてもよいようにすることが含まれる。

図４は、ホスト・システム２００からの変更を含む、マルチユーザ・ホスト・システム４００の第２の好適な実施形態である。まず、グラフィクス及びビデオ・ディスプレイ・コントローラ２１２が、更に能力が高いグラフィクス・プロセッサ・ユニット（ＧＰＵ−Ｐ）４１２と置き換えられている。グラフィクス・プロセッサ・ユニット４１２は、パケットを通じた選択的表示更新に対するサポートを含み、提案したVESA Digital Packet Video Link（ＤＰＶＬ）規格の一部又は全てに準拠することができる。第２に、ＴＳＡ２２４がＴＳＡ−Ｇ４２４と置き換えられており、ＴＳＡ−Ｇ４２４は、システム・バス２０６を通じてＧＰＵ−Ｐ４１２からのパケット表示更新をサポートするか、好ましくは入力パス４１４及び４１６をサポートする。これらの入力は、シリアル・ディジタル・ビデオ出力ＳＶＤ０１及びＳＤＶ０２、又は異なるバス幅、シグナリング・プロトコル、及び周波数を有する汎用ポートとすればよい。その例には、ディジタル・ビデオ出力（ＤＶＯ）、ディジタル・ビジュアル・インターフェース（ＤＶＩ）、高品位マルチメディア・インターフェース（ＨＤＭＩ）、ディスプレイ・ポート又はその他の低電圧差動シグナリング（ＬＶＤＳ）、推移最小化差動シグナリング（ＴＭＤＳ）、ＰＣＩエクスプレス、又はその他の方式が含まれる。表示出力パスは、高いリフレッシュ・レートで多数のフレームを出力するのに十分な速度でランすることができればよく、フレームは、１つよりも多いＲＴに対応する選択的更新矩形とすることができる。ＴＳＡ２２４と同様、ＴＳＡ−Ｇ４２４は、ネットワーク・コントローラに、専用リンク４２６を通じて、主システム・バス２０６を経由して接続することができ、あるいはシステム・オン・チップ（ＳＯＣ）実施態様によって一層密接に一体化することができる。

従前のグラフィクス処理を実行することに加えて、ＧＰＵ−Ｐ４１２は、選択的更新を生成し、表示の内変化した部分を示す。選択的更新は、矩形すなわちタイルの形態をなすことができ、ビデオ出力パス４１４又は４１６を通じて、又は主システム・バス２０６を通じてのいずれかで出力される。矩形更新は、ウィンドウの原点、サイズ、及びフォーマットを示すパケット・ヘッダを含む。原点は、どのＲＴが宛先であるかを示すために用いることができる。タイルも用いることができ、ヘッダがタイルを記述する情報が少なくて済むように、１つ以上の固定サイズに標準化することができる。矩形又はタイルをＲＴにおいて倍率調整すべきか、そしてどのようにして倍率調整するかというような、他の情報もヘッダに含むこともできる。選択的更新の他の形態には、BitBlt、Area Fill及びPattern Fillに対するサポートを含み、大きなブロックのデータを送る代わりに、ＲＴにおいて実行する動作のコマンド・パラメータと共に、最少量のデータを送る。他のヘッダは、ビデオ・ストリーム、ゲンロック、倍率調整ビデオ・ストリーム、ガンマ・テーブル、フレーム・バッファ制御の形態で更新をサポートする。他の強化したコマンド及び複雑なコマンドも、ＲＴに対する選択的更新の様式に入れることができる。提案したＤＰＶＬ仕様は、選択的更新について可能な一実施態様を、それらのヘッダと共に、詳細に示す。

１つのＧＰＵ−Ｐ４１２は、多数のＲＴに対する表示データを各々が収容する種々の表示面にＲＡＭ４１８を編成することにより、ＲＴ３００の全てに対してシステムによって事実上仮想化することができる。ＰＧＵ−Ｐ４１２の２Ｄ、３Ｄ及びビデオ・グラフィクス・プロセッサ（図示せず）を利用して高いグラフィクス及びビデオ性能を達成することが好ましい。グラフィクス処理ユニットは、２Ｄグラフィクス、３Ｄグラフィクス、ビデオ・エンコード、ビデオ・デコード、スケーリング、ビデオ処理、及びその他の高度画素処理を含むことができる。また、ＧＰＵ−Ｐ４１２のディスプレイ・コントローラは、ビデオ及びグラフィクス・データの配合及びキーイング(keying)、ならびに画面リフレッシュ動作全体というような機能も実行することができる。主及び副表示面に用いられるＲＡＭ４１８に加えて、種々の３Ｄ及びビデオ動作をサポートするのみ十分な、画面外メモリ(off-screen memory)がある。選択的更新を管理するＤＰＶＬ方法の代わりに、ＲＡＭ４１８内部に選択的更新バッファ・メモリ（Ｓ−バッファ）４０４があってもよい。一実施形態では、Ｓ−バッファ４０４は、ステータス・ビット、署名、又はステータス・ビット及び署名双方を格納する。これらは仮想表示毎に各タイルに対応する。他の実施形態では、Ｓ−バッファ４０４はヘッダと共に又はヘッダ無しのタイル自体、ステータス・ビット及び署名情報を格納し、この場合、タイルは選択的更新に合わせて出力されるように配列されている。

グラフィクス・エンジン及びディスプレイ・コントローラは、通例、ＲＴディスプレイ毎に主面に対応する完全な表示画像を合成する。ＲＡＭ４１８は、ＲＴの全てに付いての表示フレームのアレイを効果的に収容する。ＤＰＶＬは、６４Ｋ×６４Ｋの仮想表示に対処し、その場合主要な用途は多重モニタ・サポートに当てられる。この用途では、ＲＴディスプレイを６４Ｋ×６４Ｋのアレイにマッピングすることができる。この用途には多数の独立したＲＴを伴うので、ＧＰＵ−Ｐ４１２は異なるセキュリティ機構を追加して、異なる表示エリアの安全性を確保し、一人のユーザが他のユーザのフレーム・バッファへのアクセスを得ることを防止するとよい。本システムは、好ましくは、ハードウェア・ロックを含み、セキュリティ及び信頼性双方の懸念に対して、表示メモリの保護部分に対する不正アクセスを防止する。

図５は、図４のメモリ４１８の構成例を示し、仮想表示空間が横３２００画素及び縦４８００画素に設定されている。メモリ４１８は、８つの１６００×１２００表示エリアに分割されており、５２０、５２２、５２４、５２６、５２８、５３０、５３２、及び５３４で示されている。典型的な高品質表示モードは、画素毎に２４ビットのビット深さに合わせて構成されるが、多くの場合、ＲＡＭ４１８において編成されている、ビット当たり３２ビットの構成を利用し、グラフィクス及びビデオ・プロセッサがディスプレイにアクセスするときに、位置合わせがし易くし、更に余分な８ビットを潜在的に他の目的で用いることができるようにする。タイル状メモリの図示は、性質上概念的であり、ＧＰＵ−Ｐ４１２から見た場合である。実際のＲＡＭアドレシングは、メモリ・ページ・サイズ及びその他の考慮点にも関係する。

図５は、表示エリア５２８において、更に、表示更新矩形５５０を示す。１６００×１２００表示の破線５４０は、指定範囲(precinct)と呼ばれる、２５６×２５６画素の更に粗いブロックの境界に対応する。表示ウィンドウ５５０から明白なように、表示ウィンドウの境界の位置合わせは、必ずしも指定範囲の境界と合っていない。ユーザは表示画面上にウィンドウのサイズ及び位置を任意に決めるので、これは典型的な状況である。全フレーム全体を更新する必要がない隔画面更新をサポートするためには、表示ウィンドウ５５０の影響を受ける指定範囲の各々を更新する必要がある。更に、表示ウィンドウ５５０内におけるデータ形式及び周囲の表示画素は完全に異なる形式であり、相関がない場合もある。したがって、指定範囲に基づくエンコード・アルゴリズムは、損失を伴う場合、指定範囲の縁及び表示ウィンドウ５５０の境界いずれにも、視覚的アーチファクトが伴わないことを確保する必要がある。実際のエンコード・プロセスは、８×８又は１６×１６のような、指定範囲よりも小さいブロック単位で行うことができる。したがって、好適な実施形態は決定論的エンコード・アルゴリズムを用い、周囲の画素には関係なく、画素の１集合に対して同じ結果が得られ、ウィンドウの任意の位置合わせによってアーチファクトが生ずることはない。

エンコード方式に対するブロック境界も、タイルに関する考慮点の１つである。例えば、ブロック境界が８画素の倍数でなければならないエンコード方式がある。ソース・ファイルが８画素の倍数でない場合、周囲のデータで埋め合わせする必要がある。別の場合には、ブロックの境界を、特定のユーザが配置した矩形すなわちタイルではなく、画面に向けてブロック境界を方位付けることが好ましいことが多い。ユーザが８０×８０画素のウィンドウを操作する場合、水平及び垂直方向の各々において最低１０個の８×８ブロックを用いるように配置することが理論上可能であっても（合計１００ブロック）、各方向に１１ブロック（１２１ブロック）に及ぶ可能性の方が高い。したがって、矩形更新及び矩形のいずれの続行中のエンコードも、８８×８８画素（１２１ブロック）をエンコードすることになり、周囲の画素の一部が埋め合わせのために必要となる。ＤＶＰＬ仕様は矩形エンコードを選択的更新方式の一部とは見なさないが、ＤＶＰＬには別の粒度（細分）の限界がある場合もあり、その結果、ＤＶＰＬ ＣＲＴＣ出力メカニズムを用いると、８画素を法とする(modulo 8 pixels)適したサイズの矩形境界が得られる。

また、異なるサイズのディスプレイを有するＲＴもサポートすることができる。一例では、ＭＵ−ＧＰＵ４１２は任意のサイズの任意のサイズのディスプレイをサポートすることができる。別の例では、それよりも小さいディスプレイをサブ・ウィンドウとしてサポートする、又は、それよりも大きなディスプレイを１つの表示エリアよりも広いオーバーレイ・ウィンドウとしてサポートする方が簡単な場合もある。矩形５３６によって線引きされているように、１９２０×１０８０ウィンドウの場合、５３２及び５３４エリア双方を用いる必要がある。これはエリアを無駄にするが、ディスプレイ毎にカスタム・サイズを作成するよりも、実施が簡単である。ＰＧＵ−Ｐ４１２の選択的矩形更新メカニズムのために、画面の関連するエリアだけが常に送信される。ＤＶＰＬは動的にＣＲＴＣ制御レジスタを制御して選択的更新を管理するが、Ｓ−バッファのような、これよりも柔軟性のあるその他のメカニズムを実施することもでき、プロセッサの介入が少なくて済み、システムの効率も向上する。

また、更に柔軟性の高いシステムでは、ＤＶＰＬ矩形の概念を、タイルのように、一層規則的にサイズにした実体に分解することもできる。任意の矩形サイズを有するヘッダ情報の効率と、柔軟性の低いタイル・サイズを用いるが画面データが多く単純化する潜在性のあるヘッダとの間には、ヘッダ情報の効率にトレードオフがある。好適な一実施形態では、タイルをブロック・サイズのいずれの倍数にでも動的に設定することができ、ブロック・サイズは、データ・エンコード・アルゴリズムに対して最小の実体となっている。ブロックは、ソース画像又は画面の固定ブロック位置のいずれに対して方位付けることもできる。タイルのサイズは、ヘッダ情報に含まれる。

５３０のようなメモリのエリアを、選択的更新を管理するためのＳ−バッファに指定することができる。一実施形態では、Ｓ−バッファは、表示フレーム５２０、５２２、５２４及び５２６のタイルに対応するステータス・ビットを含み、ステータス・ビットは、タイルが選択的更新を必要とするか否かを示す。Ｓ−バッファ４０４は、タイル毎に署名も格納することができ、この場合、選択的更新の必要性を判断する際に用いられる。別の実施形態では、選択的更新が必要なフレーム５２０、５２２、５２４及び５２６からのタイルを、メモリ・エリア５３０にコピーし、選択的更新出力に合わせて整列させる。整列したタイルは、種々のヘッダ、ステータス、及び署名情報を含むことができる。

図６Ａは、図５の表示マップ５３６を更に詳細にした図である。これは、１９２０×１０８０の高品位テレビジョン（ＨＤＴＶ）の解像度を有し、１０８０Ｐと呼ぶ。図６Ａにおいて、固定サイズの矩形６１４が、画面位置の境界によって方位付けられている。各矩形は、横１６０画素、縦１２０画素である。行毎に１２個の矩形（１２×１６＝１９２０）、そして列毎に９個の矩形（９×１２０＝１０８０）がある。システムは、これらの矩形を選択的更新の基準を形成するタイルとして用いることができる。別のシステムでは、図６６Ｂに示すように、さらに矩形を８０×４０画素を収容するタイルに分割し、システムはこれらの小さくしたタイルを選択的更新の基準として選択することもできる。更に柔軟性が高いシステムでは、６つのタイル６２０から成る大きな矩形６１４、及びタイル自体の双方を利用することができ、ヘッダ情報を用いて、任意所定の時点で、どちらの種類が出力されているのか正確に叙述することができる。

双方の場合において、エンコード・アルゴリズムの基準を形成するブロックは、タイルすなわち矩形の中に納まる。８×８ブロックを仮定すると、各タイルは、１０×５のブロック構成を有し、各矩形は２０×１５のブロック構成を有する。大きい方の矩形及び小さい方の矩形双方を利用するシステムでは、選択的更新の必要性を判断する際に、各々に異なるメカニズムを用いることができる。好適な一実施形態では、大きい矩形にはステータス・ビットを関連付け、これらが変化したか否かを示すことができ、小さい方のタイルは、このような判断を行うために署名を利用することができる。ステータス・ビット及び署名は、以下で説明するが、Ｓ−バッファによって管理することができる。

ＰＧＵ−Ｐ４１２は、タイルの選択的エンコードを直接的に実行する処理を統合することができ、あるいは選択的更新プロセス及びＴＳＡ−Ｇ４２４への出力を用いて各タイルをチェックすることもでき、その場合、タイルはしかるべきヘッダを含むことになる。ヘッダは、ＴＳＡ−Ｇ４２４によって処理され、ヘッダ内部にあるフィールドに基づいて、ＴＳＡ−Ｇ４２４は、どのＲＴそして表示画面のどこにタイルが意図されているのか把握する。該当する場合、ＴＳＡ−Ｇ４２４は、タイルを圧縮フォーマットにエンコードし、いずれの必要なヘッダ情報も調節し、更にネットワーク処理を行うためにタイル及びヘッダを供給する。

ＰＧＵ−Ｐ４１２及びＴＳＡ−Ｇ４２４は、選択的更新プロセスを別々に区分することもできる。場合によっては、ＰＧＵ−Ｐ４１２は、完全な管理を行うことができ、更新を必要とするタイルだけをＴＳＡ−Ｇ４２４に送る。別の場合、ＴＳＡ−Ｇ４２４は、更にスライスのフィルタリングも実行し、どのスライスが本当に更新を必要としているのか判断しなければならない。ＰＧＵ−Ｐ４１２内部において、選択的更新メカニズムは、ハードワイヤにすることも、ＣＰＵの介入を必要とすることも可能であり、ハードウェアは、描画エンジン及び選択的更新リフレッシュ・エンジン双方に跨って実施することもできる。また、タイルのエンコードは、ＰＧＵ−Ｐ４１２又はＴＳＡ−Ｇ４２４のいずれで実行してもよい。また、ＰＧＵ−Ｐ４１２は、ディジタル・ビデオ・バスを通じて、ＲＴに対するグラフィクス描画コマンドをＴＳＡ−Ｇ４２４に出力することもでき、あるいはソフトウェア・ドライバがコマンドを直接ＴＳＡ−Ｇ４２４に供給することもできる。

選択的タイル更新のために、第１実施形態では、Ｓ−バッファを用いる場合、ＰＧＵ−Ｐ４１２がタイル毎にステータス・ビットを管理する描画エンジンと、タイル毎に選択的表示更新を管理する際にステータス・ビットを監視する選択的更新リフレッシュ・エンジンとを有する。３Ｄグラフィクスで用いられるＺ−バッファと同様、Ｓ−バッファは、別個のデータ・メモリ・プレーンとして実施することができる。Ｚ−バッファの場合と同様、強化ＰＧＵ−Ｐ４１２のハードウェア描画動作がＳ−バッファのステータス・ビットを更新し、追加コマンドは不要である。次いで、選択的更新ハードウェアがステータス・ビットを用いて、どのタイルがＲＴにおいて更新する必要があるか判断する。ディスプレイ・コントローラのリフレッシュ・サイクルと同様、選択的更新ハードウェアは周期的にＳ−バッファを詳しく調べて、ステータス・ビットを読み出す。ステータス・ビットの状態に基づいて、選択的更新ハードウェアは、更新する必要のないタイルをやり過ごすか、又は選択的更新のためにタイルを読み取り、このタイルをヘッダ情報と共に出力し、それに応じてステータス・ビットを更新する。効率が低くてもよい実施態様では、ＰＧＵ−Ｐ４１２は従前の古いグラフィクス描画動作を用いてＳ−バッファを発生することができる。

特定のＳ−バッファ・ハードウェアを必要としない別の好適な実施形態では、ＰＧＵ−Ｐ４１２は、更新が必要なタイルを連結し、選択的更新バッファを管理することができる。選択的更新バッファは、別個のメモリ・エリアに組み入れてもよい。ＰＧＵ−Ｐが動作を実行しタイルが変化する毎に、そのタイルを選択的更新バッファにコピーする。各タイルの先頭に、ヘッダ情報を格納することができ、タイル同士を一緒に詰め込むことができる。ディスプレイ・コントローラは、選択的更新バッファを用い、標準的なディスプレイ・コントローラの出力動作を用いてそれをリフレッシュ・ポートに出力するように設定されている。ＰＧＵ−Ｐ４１２は、１つ以上のバッファをリング・バッファ、又は連結したタイルのリンク・バッファ・リストとして管理し、連続出力をＳＤＶＯ出力に供給し、ＴＳＡ−Ｇ４２４はそれをタイル・リストとして扱う。ＰＧＵ−Ｐ４１２がリストにおける配置の優先順位を調停するためには、種々の方式を用いることができる。この方法は、多数のＲＴをサポートするには特定のハードウェアが少なく、特殊な選択的更新ハードウェアを殆ど又は全く有していないＰＧＵ−Ｐを利用するためには、最も効率的であると言える。

別の好適な実施形態では、ＴＳＡ−Ｇ４２４がＰＧＵ−Ｐ４１２と共に動作して、ＲＴ３００においてどのタイルが更新を必要としているか判断する。ＰＧＵ−Ｐ４１２がタイル毎にステータス・ビットを管理する能力は、難しすぎる場合があり、タイルを大きなタイル又は仮想ＲＴディスプレイ全体に集合化し、ステータス・ビットに対する粒度を制限することもできる。大きなタイルをそれよりも小さなタイルの更新に縮小することは、タイル毎の署名追跡に基づいて行うことができる。署名は、タイルが最初に処理されるときに発生され、後続の署名と突き合わせてチェックするのが通例である。署名は、ＴＳＡ−Ｇ４２４によって発生し処理することができ、ＴＳＡ−Ｇ４２４は、着信データから、又はＰＧＵ−Ｐ４１２の選択的更新ハードウェアと共に動作する。ＴＳＡ−Ｇ４２４がタイル毎に署名チェックを行う場合、各ＲＴ４００に対するネットワーク帯域幅を保存することができる。ＰＧＵ−Ｐ４１２が署名チェックを行う場合、ビデオ・パスを通じてＴＳＡ−Ｇ４２４までの帯域幅も保存する。ＰＧＵ−Ｐ４１２はタイルに対応する署名のメモリ・プレーンを発生し管理することができ、ステータス・ビットは、署名プレーン又は別個のプレーンの一部とすることができる。あるいは、ステータス・ビット及び署名ビットをＲＡＭキャッシュにおいて管理し、ＧＰＵ−Ｐ４１２によってリンク・リストと共に管理してもよい。

ホスト４００上におけるグラフィクス動作によって発生するグラフィクス・コマンドの種類、及びＲＴ３００の能力に応じて、コマンドをカプセル化してＲＴにおける実行のために送ることができ、あるいはＰＧＵ−Ｐ４１２によってローカルにコマンドを実行することもできる。多くの場合、コマンドはＲＴにおける実行のために送られるが、仮想表示のローカル・コピーを保持するために、コマンドはＰＧＵ−Ｐ４１２によってもローカルに実行される。理想的なのは、冗長なローカル・グラフィクス・コマンドの結果変化したいずれのタイルをも、ステータス・ビットによって取り除き、不要なタイル更新パケットがＲＴに送られるのを防止することである。通例、エンコードしたタイルの代わりにコマンドを送るには、帯域幅は少なくてよいが、常にこれが可能とは限らない。選択的更新バッファを手動で管理するシステムでは、ＲＴに送られているコマンドも考慮する。ＲＴにおいて実行するコマンドによって更新されるタイルは、ＰＧＵ−Ｐ４１２によって選択的更新バッファに入れないことが理想的である。

別の例では、ＲＴを目的とするグラフィクス・コマンドをＴＳＡ−Ｇ４２４によって処理し、エンコード・データ転送及び修正グラフィクス・コマンドに分解する。例えば、ホスト・システムが画面外メモリから又はパターンから画面上メモリにBitBlt動作を実行したい場合がある。これは、ＰＧＵ−Ｐ４１２サブシステムにおいて容易に実行することができる。しかしながら、ＲＴにおいて、BitBltに必要なソース・データがキャッシュされていない。したがって、グラフィクス・コマンドを送ることができるようにするには、最初に、ソース・データ又はパターンをエンコードし、カプセル化し、ＲＴに送り、次いで修正グラフィクス・コマンドをカプセル化しＲＴに送る必要がある。この手順は、ＴＳＡ−Ｇ４２４によってオフロードすることができる。DirectXドライバがＰＧＵ−Ｐ４１２を通じてコマンドをつぎ込み、ついでＰＧＵ−Ｐ４１２がこれらをＴＳＡ−Ｇ４２４に出力することは可能であるが、DirectXドライバがこれらを直接ＴＳＡ４２４に伝達することの方が効率的なことも多い。

図７は、ＴＳＡ２２４又はＴＳＡ−Ｇ４２４の好適な実施形態についてのサブシステム７００及びＴＳＡ７２４の機能ブロックを示す。サブシステムは、ホスト２００又はホスト４００上でランする追跡ソフトウェアと通信し、ホスト・システム・バス２０６への接続部を含み、パス２２６を通じたネットワーク・サブシステムへの直接接続部も含むことができる。ＴＳＡ−Ｇ４２４の場合、ＴＳＡ７２４は、パスＳＤＶＯ１ ４１４及びＳＤＶＯ２ ４１６を通じて、グラフィクス・コントローラＧＰＵ−Ｐ４１２への直接接続部も含むことができる。パス４１６は、第２ＳＤＶＯ２ ４１６又は別のサブシステムへの接続部であってもよい。サブシステムにはメモリ７３０が含まれ、メモリ７３０はＴＳＡ７２４又は外部メモリ・サブシステムに埋め込むことができる。また、各機能ブロックは、それ自体の内部メモリも含むことができる。

システム・コントローラ７０８は、ホスト・システム及びその他のサブシステムへのインターフェースを管理し、ＴＳＡ７２４の設定及び管理の一部を実行する。DirectXインタープリタ７０４は、ホスト・システム上でランするDirectXソフトウェア・ドライバの負担を軽減する。２Ｄグラフィクス・コマンド、３Ｄグラフィクス・コマンド、ビデオ・ストリーム、及びその他のウィンドウ形成(windowing)機能を管理する。ＲＤＰインタープリタ７０２ならびにデータ／ビデオ・エンコーダ及びトランスコーダ７０６と組み合わせて、ＴＳＡ７２４は、ホスト・コンピュータから、ＲＴを管理する計算集約的な面の多くを実行する負担を軽減し、更にホスト・システムから種々のＲＴに送られるコマンド、データ、及びビデオ・ストリームを最適化することもできる。

システム２００の場合、ホストに基づくＧＰＵ２１２はＲＴディスプレイのサポートには利用されておらず、ＴＳＡサブシステム７００は、種々のグラフィックに基づく最適化を実行することができる。ＲＤＰインタープリタ７０２によって、種々のパターンBitBlt、ソースから画面宛先BitBlt、及び他のビットマップ転送を強化することができる。ＲＤＰインタープリタ７０２は、ホストからのコールを傍受し、データ／ビデオ・エンコーダ及びトランスコーダによってソース・データ、パターン、又はビットマップをエンコードして、効率を高めたフォーマットとし、エンコードしたデータ、パターン、又はビットマップを、システム・コントローラ７０８を通じて転送し、最後に修正したグラフィクス・コマンドをＲＴ３００に発行することができる。宛先ＲＴは、エンコードしたソース・データ、パターン、又はビットマップを受信し、必要であればそれをデコードし、修正グラフィクス・コマンドの受信時に、意図された動作を実行する。エンコードしたデータ及び修正コマンドの転送は、ＲＤＰ転送又はＲＤＰ状転送のいずれを用いてもよく、これらはＴＳＡサブシステム７００及びＲＴ３００によってサポートされている。

システム２００におけるビデオ・ストリームに対して、DirectXインタープリタ７０４は、ビデオ・ストリーム処理を傍受してオフロードさせ、最適なストリームを目標ＲＴに供給することができる。負担軽減における最初のステップは、ホスト・プロセッサがホストＣＰＵ上でビデオ・デコードを実行していないことを確かめることである。ホストに基づくデコードには数個のマイナス面があり、その内最も重要な２つは、最初に、実際のデコードを行うのに多数のＣＰＵサイクルを要することである。第２に、ホストにおいてビデオ・フレームをデコードしておくことは、必ずしも、目標ＲＴにおいて表示するフレームを得る最良のやり方ではないということである。代わりに、DirectXインタープリタ７０４はDirectXコールを傍受し、Microsoft Windows（登録商標）の中には、圧縮形態のままである間にビデオ・ストリームに対するアクセスを得るためには、DirectShowの使用を伴うバージョンもある。DirectXインタープリタ７０４は、ＲＤＰが通常の動作を続けるためには、模造フレームをＲＤＰインターフェースに提供する必要がある場合もある。

一方、システム・コントローラ７０８は、ＲＴがデコードすることができるビデオ・ストリーム・フォーマットはどれか、ホスト・システムからＲＴまでのネットワーク・スループットが通常はどれくらいか、そしてビデオ・ストリームで意図する解像度及び表示特性は何か把握している。この情報を知って、システム・コントローラ７０８は、着信ビデオ・ストリームを処理しネットワーク、ＲＴ及び表示出力要件に対して理想的なストリームを生成するように、データ／ビデオ・エンコーダ及びトランスコーダ７０６を設定する。これには、一方のエンコード・フォーマットから他方にトランスコードすること、一方のビット・レートから他方にレート変更すること、フレーム・レートを変更すること、表示フォーマットを変更すること、解像度又はこれらのいずれかの組み合わせを変更することを伴う場合もある。次いで、コントローラ７０８は処理したビットストリームをカプセル化し、ネットワーク処理のために主システム・バス２０６又は直接接続部２０６を通じてそれを送る。

システム４００の場合、ＴＳＡサブシステム７００は、システム２００に関して説明した機能を含むことができるが、更に、ＧＰＵ−Ｐ４１２と共に動作するための追加のサポートも含む。ＲＤＰ７０２及びＧＰＵ−Ｐ４１２が双方向処理する手法にはいくつかあり、ＴＳＡサブシステム７００の動作は、それに応じて様々に変化する。ここでは、２つの実施形態について詳細に検討する。第１の実施形態は「終了及び再生」(terminate and regenerate)であり、第２の実施形態は「オフロード及び強化」である。これらの実施形態の変形も可能であり、各実施形態の態様を利用することができる。

「終了及び再生」の場合、ホスト・システム上でＲＤＰクライアントをランさせる。ホストに関する限り、ＲＤＰ動作はＴＳＢ４００によって終了させられ、ＲＤＰクライアントはＧＰＵ−Ｐ４１２を利用して仮想表示を作成する。先に説明したように、ＧＰＵ−Ｐ４１２は、多数の仮想ＲＴをサポートするために仮想表示空間を用い際に、１つの大きな表示マップを作成し、この大きな表示空間の内部において、各ユーザをオフセットするか、又は各仮想表示を、それ自体のマッピングによって、別個の表示として見る。ＲＤＰクライアント・ソフトウェアは、安全を確保したクライアント通信を要求するＲＤＰホストのために、ＴＳＡサブシステム７００内部において鍵交換及びセキュリティ処理を利用しなければならない場合もある。ＲＤＰクライアントがＲＤＰホストからコマンドを受信すると、クライアントは、ＧＰＵ−Ｐ４１２を利用して、表示フレームをディスプレイ・サブシステムに納める。次いで、ＧＰＵ−Ｐ４１２は、しかるべき選択的更新を発生し、パス４１４を通じて送る。

次いで、矩形タイルを含む選択的更新パケットをエンコードし、カプセル化し、ネットワーク送信のために転送する。単に描画コマンドをＲＴ３００に受け渡す代わりに「終了及び再生」を用いる主な理由は、要求コマンドがＲＴにおいてサポートされていないときである。また、帯域幅、コマンドの種類又はシーケンス、及びＲＴの相対的性能に基づく、その他の更に微妙な理由も要因に含む場合もある。

「オフロード及び強化」は、追跡ソフトウェア・レイヤのDirectXビデオ及びデータ・ストリームの再送出を続けることができる。DirectXインタープリタ７０４は、ホストDirectXコールを傍受する。傍受されたコールは、データ／ビデオ・エンコーダ及びトランスコーダ７０６にオフロードされ、データ／ビデオ・エンコーダ及びトランスコーダ７０６がDirectXコールの機能を完成させる。機能をオフロードさせることによって、ホストＣＰＵ２０２をマルチユーザ・システムの他のユーザも利用できるようにする。表示環境及び最適な処理を可能にするネットワーキング帯域幅を把握することによって、エンコード及びトランスコードを完成させることができる。

また、ＲＤＰインタープリタ７０２は、グラフィクス・コマンドをローカルに実行し、かつＲＴに転送して送るときに、ステータス・ビットを管理するために用いることができる。ホスト・グラフィクスがグラフィクス・コマンドを実行する理由は、フレーム・バッファの現行のコピーを今後の使用のために管理することができるようにするためである。グラフィクス・コマンドはＲＴにおいて実行されているので、ホスト上でローカル・グラフィクス・コマンドの結果として変化するタイルは、選択的更新ハードウェアにエンコードしたタイルを送らせる必要はない。これを防止するために、ＲＤＰインタープリタ７０２は、どのタイルがグラフィクス・コマンドによって影響を受けるか計算する必要がある。これらのタイルに対応するＳ−バッファにおけるステータス・ビットを管理すれば、タイルに基づく選択的更新を実行しないようにすることができる。

また、追跡ソフトウェア・レイヤは、変化し表示更新ストリームを発生することを必要とする表示フレームの選択をエンコードする際に、補助するために用いることができる。尚、エンコードは、ホスト・コンピュータのグラフィクス及びディスプレイ・コントローラ４１２が発生する表示データを再生するためにリモート・ディスプレイ・システム３００が必要とするデータを減少させるために行われる。追跡ソフトウェア・レイヤは、フレーム又はタイル内にあるデータの形式を識別し、最適な種類のエンコードを実行できるようにするのに役立つ。一部のＲＴは、グラフィクス・コマンドを実行するための十分なグラフィクス処理能力を有していない場合もあり、ＧＰＵ−Ｐ４１２が処理したエンコード・データが送られることもある。

例えば、追跡ソフトウェアが、タイルの表面がリアル・タイム・ビデオであることを識別した場合、ビデオには一層効果的であり、スムーズな空間遷移及び時間ロカリティ(temporal locality)を有するエンコード方式を、これらのタイルに用いることができる。追跡ソフトウェア・レイヤが、タイルの表面が殆どテキストであることを識別した場合、鋭い縁及びテキストの広い白色空間に一層効果的なエンコード方式を用いることができる。どの形式のデータがどの領域にあるか識別することは、複雑な問題である。しかしながら、追跡ソフトウェア・レイヤのこの実施形態では、ホスト・ディスプレイ・システム及びこの識別において補助するホスト・オペレーティング・システムのグラフィクス・ドライバ・アーキテクチャにインターフェースを組み込むことを可能にする。例えば、Microsoft Windows（登録商標）では、ある種のDirectShowコマンドを利用する表面はビデオ・データである可能性が高く、一方通常テキストと関連のある、色拡張ビット・ブロック転送（ビット・ブリッツ(Bit Blits)）を用いる表面はテキストである可能性が高い。各オペレーティング・システム及びグラフィクス・ドライバ・アーキテクチャは、それ自体の特性指標を有する。他の実施態様が並行して多数の形式のデータ・エンコードを実行し、次いでエンコーダのフィードバックに基づいて最良の結果を出したエンコード方式を用いることを選択することができる。

種々のデータ形式に対して、ある種のエンコード方式は特定の形式のデータには特に有用であり、一部のエンコード方式はデータ依存性が低い。例えば、ＲＬＥはテキストには非常に良いが、ビデオには非常に劣っており、ＤＣＴに基づく方式はビデオには非常に良いが、テキストには非常に劣っており、ウェーブレット変換に基づく方式は、ビデオ及びテキスト双方にとって満足することができる。このシステムでは、無損失のエンコード又は損失があるエンコードのいずれの種類でも用いることができるが、ウェーブレット変換エンコードは、無損失又は損失型のいずれでも可能であり、特に、周囲のタイルに対する懸念なく各タイルをエンコードすることができる決定論的算術的コーダを用いた前進ウェーブレット変換は、この用途には特に適している。ＪＰＥＧ２０００ウェーブレット・エンコーダの派生物は、リアル・タイムでの実行を改善するために特別な処理を行っており、可能な実施態様の１つである。

図８は、ネットワーキング、セキュリティ、端末サービス、記憶、及びホスト・プロセッサからのインターネット・アクセスのようなその他のタスクをオフロード及び促進するための好適な実施形態のサブシステム８００（図２からの８２０及び図からの８４０）のブロック図である。オフロード・サブシステム８００は、主に、ホスト・システム２００又は４００とシステム・バス２０６を通じて通信する。接続部ＳＤＶＯ１ ４１４及びＳＤＶＯ２ ４１６は任意であり、ＲＴのためのグラフィクス処理を含むホスト・システム、又はネットワークを通じてシステム運営管理のための単一リモート・キーボード、ビデオ、及びマウス（ＫＶＭ）に再指令(redirection)を与えるより単純なグラフィクス・システムのいずれかのために含まれる。接続部は、直接でも、又はインターフェース・チップ８５０を介してでもよい。インターフェース制御部８１０は、種々のＩ／Ｏ接続を管理する。ネットワーク・インターフェースは、ＷＡＮへのアクセス及びＲＴへのアクセスを含むことができる。ギガビット・イーサネットのような高速ネットワークが好ましいが、常に実用的という訳ではない。１０／１００イーサネット、電力線イーサネット、同軸ケーブル系イーサネット、電話回線系イーサネット、又はワイヤレス・イーサネット規格８０２．１１ａ、ｂ、ｇ、ｎ、ｓのような低速ネットワーク、ならびに今後の派生物及び超広帯域（ＵＷＢ）バージョンもサポートすることができる。

ＫＶＭは、主ネットワーク接続及びホストＣＰＵ上でランするソフトウェアを用いて「帯域内」で沿革的にホストを制御するのに便利なように実施し用いることができる。あるいは、ＫＶＭは、主システムの資源をできるだけ使わずに、「帯域外」で動作することもできる。「帯域外」で用いる場合、ビデオ監視は、主要な「帯域内」ネットワーク接続以外のネットワーク・インターフェースを用いて行うとよい。加えて、主プロセッサ上でランするリモートＫＶＭ機能のためのソフトウェアの代わりに、特殊な別個のベースボード管理コントローラ（ＢＭＣ）が含まれるのが通例である。ＢＭＣは、インテリジェント・プラットフォーム管理インターフェース（ＩＰＭＩ）のようなプロトコルをランさせることができる。ＢＭＣは、それ自体のネットワーク・インターフェースを設けることができ、あるいは主ネットワーク・コントローラへのサイド・ポート接続をサポートすることもできる。

異なるオフロード・タスクに合わせて動的処理をサポートするために、オフロード・サブシステム８００は処理ブロックを用いる。処理ブロックは、プログラム可能かつコンフィギュレーション（環境設定）可能(configurable)であり、作業負荷が変化すると素早くタスクを切り換えてコンフィギュレーションを変更することができる。種々のメモリ・ブロックが処理ブロックの各々に含まれ、更に大きなメモリ８３０も含むことができる。ＣＰＵ８０８は、一般に、それ自体のキャッシュ・メモリを含むプログラマブル・プロセッサであり、オフロードについてのハウスキーピング及び管理を実行することができ、更に高いレベルのプロトコル及びインターフェースの処理も実行することができる。ネットワーク・プロセッサ及びＭＡＣコントローラ８０６は、オフロード・サブシステムのネットワーク・インターフェース制御（ＮＩＣ）機能を管理し、同時通信の多数のパイプを管理することができる。コンテンツ・アドレス・メモリ（ＣＡＭ）のような特殊な内部メモリ、及び従前のメモリもＮＩＣ８０６の中に含めてもよい。完全なＮＩＣ８０６の機能には、セキュリティ・プロセッサ（ＳＰ）８０４及びコンフィギュレーション可能なデータ・プロセッサ（ＣＤＰ）８０２からの追加処理が必要となる場合がある。

コンフィギュレーション可能なデータ・プロセッサ８０２は、専用ハードウェア・ブロックに通常伴うスループットで異なる処理を実行するように、再コンフィギュレーションできる設計となっている。ＣＤＰ８０２を専用ハードウェアの代わりに利用することにより、同じハードウェアによって異なるオフロード・タスクを実行することができる。再コンフィギュレーション可能なデータ・パス、動的命令集合、非常に長い命令語（ＶＬＩＷ）、単一命令多重データ（ＳＩＭＤ）、多重命令多重データ（ＭＩＭＤ）、ディジタル信号処理（ＤＳＰ）及びその他の形態の再コンフィギュレーション可能な演算のような、ＣＤＰを設計する先行技術の方法を組み合わせると、非常に高い性能の計算を実行することができる。セキュリティ・プロセッサ８０４は、ＣＤＰ８０２の形態によって、更に特殊化したハードウェアによって、又は暗号及び鍵関連機能のための専用追加ハードウェアをＣＤＰ８０２と組み合わせることによって実施することができる。

端末サービスの促進のために、ＣＤＰ８０２は、タイル及び矩形のデータ・エンコード、ビデオ又はデータに対する種々の形態のトランスコード及びレート変更、タイル署名の発生及び比較、ならびにＴＳＡ２２４又は４２４部に関して以下で説明するその他のタスクを実行するように構成することができる。記憶促進のためには、ＣＤＰ８０２はｉＳＣＣＩ、ファイバ・チャネル（ＦＣ）、ファイバ・チャネル・インターネット・プロトコル（ＦＣＩＰ）、及びインターネット・プロトコルに関するタスクの異なる態様に合わせて構成することができる。接続部４１６は、ＳＤＶＯ２の代わりにＦＣに接続するように構成することができる。インターネット・コンテンツの促進のためには、ＣＤＰは、eXtensible Markup Language（ＸＭＬ）トラフィック、単純オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、ＨＴＴＰトラフィック、Java仮想機械（ＪＶＭ）、及びインターネット系通信と関連のあるその他のトラフィックを処理するように構成することができる。

ＳＤＶＯ１ ２１４及びＳＤＶＯ２ ２１６パス上の着信データを管理するために、特殊バッファ機能及び処理を設けるとよく、あるいはＣＤＰ８０２を、特殊タスクを実行するように構成してもよい。特殊タスクには、大きな矩形をタイルに分解すること、署名の発生及び比較を含むタイルの処理、ならびに目標ＲＴに関係する種々のパケットの管理が含まれる可能性がある。従来のタイル署名は、新しいタイルを受信したときに署名を比較することができるように、サブシステム８００内部に格納するとよい。

ＧＰＵは、ＶＧＡ、ＤＶＯ、ＤＶＩ、ＳＤＶＯ、表示ポート、あるいは任意数のこれらよりも高速又は低速のポートを含む表示出力ポートのために、任意数の物理的及び論理的接続でも有することができる。したがって、インターフェース・チップ８５０は、ＧＰＵ表示出力ポートとオフロード・サブシステム８００との間にあることが望ましい場合もある。オフロード・サブシステムからの接続部８１６は、いずれの幅のＰＣＩエクスプレス・ポートとして実施することもできる。好適な一実施形態では、オフロード・サブシステムは、ＰＣＩエクスプレス・ルート・コントローラとして機能し、インターフェース制御部８１０はＰＣＩエクスプレス・ポートを管理する。インターフェース・チップは、バッファ機能の一部、及び必要な前処理の一部を実行することができる。例えば、インターフェース・チップは、表示データの多数のラインをバッファし、データ・パッキング、フォーマット変換、色空間変換、サブバンド分解(subband decomposition)、又はいずれの数のその他の機能でも実行することができる。好適な一実施形態では、グラフィクス・チップからの出力は、ＤＶＯ接続部４１６上の２４ビットＲＧＢデータとなる。インターフェース・チップ８５０は、ＲＧＢデータをバッファし、それをＹＵＶ４：４：４データに変換し、画素を分解(unpack)して別個のＹ、Ｕ及びＶデータ・パケットにする。オフロード・サブシステム８００は、インターフェース制御部８１０を利用して、ＰＣＩエクスプレス・ルート制御を行い、Ｙ、Ｕ及びＶデータ・パケットは、パス８１６を経由してメモリ８３０の異なるエリアに送信される。

オフロード・サブシステム８００は、数個の無関係な動作に対する一般的なオフロード・タスクも解決するプログラム可能な解決策によって実施することができる。オフロード・プロセッサは、種々のオフロード・タスクを静的又は動的に均衡させ、任意の作業負荷に対するシステム全体のスループットを促進するように設計することができる。例えば、サーバは、日中薄いクライアントのためにサーバに基づく計算を実行しており、夜間は大きなデータベース動作をランさせている場合もある。日中、オフロード・エンジンは、ＴＳＡのために記述された動作をランさせる。夜間では、オフロード・エンジンは、ディスク記憶システムから大きなデータベースにアクセスするためにｉＳＣＳＩ促進をランさせる。種々の作業負荷を追跡する内部又はシステム全体の管理手順によって、柔軟性を管理することができる。オフロード・タスク間の切換の粒度は、非常に小さくすることができる。オフロード・エンジンは、非常に速いコンテクスト切換を実行するように設計することができるので、１回のセッションの間に、ネットワーク、端末サービス、格納、セキュリティ、及び同じセッションについてのその他のオフロード・タスクを実行することもできる。

図９は、本発明の一実施形態にしたがって端末サービス促進手順を実行する方法のフローチャートである。明確化のために、ビデオを含むデータの表示を参照して、この手順を論ずることにする。しかしながら、オーディオ、キーボード、マウス、及びその他のデータに関する手順も、等しく本発明と共に用いることを想定している。最初に、ステップ９１０において、マルチユーザ・サーバに基づくコンピュータ２００又は４００及びリモート端末システム３００は、種々の手順にしたがって、種々のサブシステムが各ＲＴをイネーブルするために、ホスト側及び端末側を初期化する。ステップ９１２において、追跡ソフトウェア・レイヤが、ホスト２００又はホスト４００上において、ＴＳＡ２２４又はＴＳＡ−Ｇ４２４と共に動作して、種々のグラフィクス及びビデオ・コールを処理し、どの動作をどこで実行する必要があるか判断する。尚、ホスト・システム２００は、ＲＴグラフィクス動作を実行するために、常駐ホストＧＰＵも仮想フレーム・バッファも利用しない。

グラフィクス動作が２Ｄ描画を含む場合、ステップ９２４において、２Ｄ描画エンジンＰＧＵ−Ｐ４１２が動作を処理し、しかるべき仮想表示をＲＡＭ４３０内に生成することが好ましい。同様に、ステップ９２６において、３Ｄ描画をＧＰＵ４１２によって実行して、しかるべき仮想表示をＲＡＭ内に生成する。ステップ９２８において、ＴＳＡ２２４又はＴＳＡ−Ｇ４２４は、ビデオ又はグラフィクス・コマンドをしかるべきＲＴに転送することを決定することができる。ステップ９４０までのフローは、迂回ステップ９２８による影響を受けずに済む。ステップ９４０において、ＰＧＵ−Ｐ４１２は各仮想表示を合成して、表示に適したフレームを形成する。この合成は、ＣＰＵサブシステム２０２、２Ｄエンジン、３Ｄエンジン、及びＧＰＵ４１２内部にあるいずれのビデオ処理エレメントによる動作のいずれの組み合わせでも実行することができる。合成ステップの一部として、Ｓ−バッファの管理をグラフィクス処理ハードウェアに含むＰＧＵ−Ｐ４１２のために、描画エンジンは、それぞれのタイル毎にＳ−バッファを更新する。

リターン・パス９４４によって示されるように、ＧＰＵ−Ｐ４１２は、必要に応じて、同じＲＴ又は異なるＲＴのために次のフレームを処理することができる。一旦合成動作を行ったなら、ステップ９４６において、タイル及び関連するＳ−バッファ・ステータス・ビット、ならびに該当する場合には署名ビットを管理する。ステップ９４６では、Ｓ−バッファ・ステータス・ビットに影響を及ぼす可能性があるビデオ及びグラフィクス迂回ステップ９２８によって処理された任意のグラフィクス及びビデオ動作を考慮する。例えば、描画動作がステップ９２４において実行され、ステップ９２８を通じてリモート端末に迂回された場合、描画動作による影響を受けるタイルに対して選択的更新を行う必要なない。何故なら、この動作はＲＴにおいて行われるからである。

ＰＧＵ−Ｐ４１２内部で又はＴＳＡ−Ｇ４２４との組み合わせで行うことができる、タイルに対するステータス・ビット及び署名の処理がステップ９４６において行われた場合、ステップ９５０では、ファイルの選択的更新を行うことができる。タイルは、固定又は可変サイズとすることができる。タイルと共に含まれるヘッダ情報は、フォーマット、及び意図するＲＴ宛先を示す。ステップ９５４において、ＴＳＡ−Ｇ４２４は、ステップ９５０から受けたタイルの必要なエンコードを実行する。このエンコードは、決定論的方式として、タイル内部にあるデータの方位及び周囲のタイルを、エンコード・ステップにおいて考慮する必要をなくすことが好ましい。また、ステップ９５４において、ステップ９２８に続くビデオ・データ及びグラフィックス・コマンドを処理する。ビデオ・データのレートを変更することができるが、この場合、ビット・レート又はフレーム・レートを変更し、周波数又は空間のいずれかのドメインにおいてスケーリングし、必要な場合、異なるエンコード規格にトランスコードする。リターン・パス９６８を通じたネットワーク・フィードバックは、ＲＴ情報と共に、エンコード・ステップ９５４を判断するのに役立つ。

また、ステップ９５４では、グラフィクス・データのエンコードを伴う可能性がある、追加の処理を必要とするいずれのグラフィクス動作をも実行する。ステップ９５８において、ＴＳＡ−Ｇ４２４は、以前のステップにおいて処理したグラフィクス・コマンド、データ転送、又はビデオ転送の更なるカプセル化を実行する。また、このステップにおいて、帯域幅及びレイテンシのようなネットワーク特性、ならびに特定のパケット・サイズ及び送信の問題に関して、ネットワーク・フィードバックを考慮する。ステップ９６２において、カプセル化したパケットを、しかるべきネットワーク・コントローラによって処理し、パケットをネットワークに沿ってしかるべきＲＴ３００に転送する。

ステップ９６２におけるネットワーク・プロセスでは、システム制御部からの情報を用いる。この情報は、どのリモート・ディスプレイがどのフレーム更新ストリームを要求しているか、フレーム更新ストリーム毎にどの種類のネットワーク送信プロトコルを用いるのか、そして各フレーム更新ストリームの各部分について、優先度及び再指向特性はどのようになっているかに関する情報を含むことができる。ネットワーク・プロセス・ステップ９６２は、ネットワーク・コントローラ２２８を利用して、任意数のネットワーク接続を管理する。種々のネットワークには、ギガビット・イーサネット、１０／１００イーサネット、電力線イーサネット、同軸ケーブルを用いたイーサネット、電話線を用いたイーサネット、あるいは８０２．１１ａ、ｂ、ｇ、ｎ、ｓのようなワイヤレス・イーサネット規格、及び今後の派生物を含むことができる。その他のイーサネット以外の接続も可能であり、ＵＳＢ、１３９４ａ、１３９４ｂ、１３９４ｃ、あるいは超広帯域（ＵＷＢ）又はＷｉＭＡＸのようなその他のワイヤレス・プロトコルを含むことができる。

図１０は、本発明の一実施形態にしたがってネットワーク受信及び表示手順を実行する方法におけるステップのフローチャートである。明確化のために、ビデオを含む表示データを参照して、この手順を論ずることにする。しかしながら、オーディオ及びその他のデータに関する手順も、等しく本発明と共に用いることを想定している。

図１０の実施形態では、最初に、ステップ１０１２において、リモート端末３００がパス２９０を通じて、ホスト・コンピュータ２００からネットワーク送信を受信することが好ましい。次いで、ステップ１０１４において、ネットワーク・コントローラ３３６はネットワーク処理手順を行ってネットワーク・プロトコルを実行し、有線か又は無線かで送信された送信データを受信することが好ましい。

ステップ１０２０において、ＣＰＵ３２４は着信する送信を解釈して、送信が意図するのはどの機能ユニットかを判断する。着信する送信が２Ｄグラフィクス・コマンドである場合、ＣＰＵ３２４は２Ｄ描画エンジン３３２を通じて動作を初期化し、３Ｄコマンドの場合、３Ｄ描画エンジン３３４を初期化し、ビデオ・データ・ストリームの場合、ビデオ・デコーダ３２８を初期化し、データのエンコードしたタイルである場合、データ・デコーダ３２６を初期化する。描画コマンドの中には、描画エンジン及びデータ・デコーダ３２６双方を利用する場合もある。

色々な数のコマンド及びデータ転送が行われ、種々の機能ユニットが動作し、好ましくはデータ情報を操作して、しかるべき表示可能なフォーマットにする。ステップ１０３０において、機能的ユニットの各々からの操作後のデータを、フレーム・マネージャ３３０によって組み立てて、ＲＡＭ３１２の中に更新表示フレームを生成することができる。更新表示フレームは、以前のフレームからの表示フレーム・データ、操作及びデコードした新しいフレーム・データ、ならびに新しいフレーム・データの送信中に発生した表示データの誤りを隠蔽するために必要なあらゆる処理を含むことができる。

最後に、ステップ１０４０において、ディスプレイ・コントローラ３３０は、最後に完成した表示フレーム・データを、リモート端末システム３００のユーザが見るために、リモート端末表示画面３１０に供給する。表示のリフレッシュは、フリッカを回避するために、リモート端末コントローラ３１４とディスプレイ３１０との間において通例毎秒６０から７２回行われる非同期動作である。ステップ１０３０において新しい表示フレームを生成することは殆ど行われないのが通例であるが、必要なときには、毎秒３０フレーム以上で行うとよい。スクリーン・セーバもパワー・ダウン・モードもない場合、ディスプレイ・プロセッサは、表示リフレッシュのプロセスにおいて、フィードバック・パス１０５０で示すように、最後に完成した表示フレームを用いて、リモート表示画面３１０を更新し続ける。

したがって、本発明は、ユーザが多種多様なアプリケーションにおいて効果的に利用することができるリモート端末をサポートする、マルチユーザ・サーバに基づくコンピュータ・システムを実施する。例えば、ある会社(business)が１つの場所において多数の棚にコンピュータ・システムを展開し、遠隔地にいるユーザに非常に単純で低コストのリモート端末システム３００を彼らのデスクトップ上に提供する。異なる遠隔地は、ＬＡＮ、ＷＡＮ、又はその他の接続を通じてサポートすることができる。ＲＴは、デスクトップ・パーソナル・コンピュータ又はノートブック・パーソナル・コンピュータとすればよく、別のシステムでは、セル・フォン、パーソナル・ディジタル・アシスタントのような特殊デバイス(specialty device)であっても、携帯用ビデオ・プレーヤ、ゲーム機、又は遠隔制御システムのようなその他の消費者向け製品と組み合わせてもよい。ユーザは、マルチユーザ・システム１００のホスト・コンピュータを柔軟に利用して、ホスト・システムがローカル・ユーザに提供することができるのと同じレベルのソフトウェア互換性及び同様のレベルの性能を達成することができる。したがって、本発明は、種々の異質なコンポーネントを利用してシステム相互動作性及び機能性の最適化を促進する、柔軟性のあるマルチユーザ・システムを効果的に実施する。

以上、好適な実施形態を参照しながら、本発明について説明した。この開示を参考にすれば、他の実施形態も当業者には明白であろう。例えば、本発明は、前述の好適な実施形態において説明した構成以外の構成を用いても容易に実施することができる。加えて、本発明は、好適な実施形態として先に説明したシステム以外のシステムと共にでも効果的に用いることができる。したがって、好適な実施形態に対するこれら及びその他の変形は、本発明の範囲に該当することを意図しており、本発明は、添付した特許請求の範囲によってのみ限定されることとする。

１つ以上のホスト・コンピュータ、ネットワーク、及び多数のリモート端末を含むマルチユーザ・コンピュータ・システムのブロック図である。 本発明の一実施形態による端末サービス促進装置を有するマルチユーザＲＴシステム・ホスト・コンピュータのブロック図である。 図２のホスト・コンピュータと協同するＲＴを示す図である。 本発明の第２実施形態による、グラフィカル・プロセッサ・ユニットを備えた端末サービス促進装置を有するマルチユーザＲＴシステム・ホスト・コンピュータのブロック図である。 ８つの表示エリアに編成し、その内の１つが表示ウィンドウを含み、２つが１つの大きなディスプレイをサポートするために用いられるメモリを表す図である。 図５の表示マップ５３６を更に詳細にした図である。 タイルに細分割した図６Ａの矩形を示す図である。 図２の端末サービス促進装置２２４又は図４の４２４の一例の詳細を示すブロック図である。 端末サービス、ネットワーキング、及びその他のタスクを促進するためのオフロード・サブシステムのブロック図である。 本発明の一実施形態にしたがって、端末サービス促進を実行する方法を示すフローチャートである。 本発明の一実施形態にしたがって、リモート端末のためにネットワーク受信及び表示手順を実行する方法を示すフローチャートである。

Claims (20)

1. 多数のリモート端末をサポートすることができるホスト・コンピュータ・システムであって、該システムは、
   グラフィクス及びディスプレイ・サブシステムであって、
   多数の端末のために表示フレームを格納することができる表示メモリと、
   各々がリモート端末における表示フレームに対応することができる表示フレームを発生する１つ以上の描画エンジンと、
   表示フレームの修正されたサブ・フレームを追跡し、この追跡に基づいて前記表示メモリから選択的更新を実行する手段と、
   を有するグラフィクス及びディスプレイ・サブシステムと、
   前記グラフィクス及びディスプレイ・サブシステムを前記ホスト・コンピュータ・システムにおけるホストＣＰＵに接続する手段と、
   前記選択的更新のみを、ネットワーク・サブシステムを通じて、前記リモート端末の対応するものに転送するように、前記表示メモリからの選択的更新を管理する手段と
   を備えていることを特徴とするホスト・コンピュータ・システム。
2. 請求項１記載のシステムにおいて、前記グラフィクス及びディスプレイ・サブシステムは、ステータス・ビットを管理するために表示メモリを利用し、前記選択的更新出力を転送する前に、どのサブ・フレームが修正されたのか、そしてどこで前記選択的更新がこれらのステータス・ビットを更新するのかを追跡するよう構成されていることを特徴とするシステム。
3. 請求項１記載のシステムにおいて、選択的更新が必要な前記追跡サブ・フレームは、前記ネットワーク・サブシステムを通じて転送する前に、帯域幅要求を削減するために、最初にエンコードされることを特徴とするシステム。
4. 請求項１記載のシステムにおいて、前記グラフィクス及びディスプレイ・サブシステムは、プライベート接続を通じて前記選択的更新をエンコード・サブシステムに出力し、該エンコード・サブシステムが、前記ネットワーク・サブシステムへの転送の前に、前記選択的更新をエンコードするよう構成されていることを特徴とするシステム。
5. 請求項４記載のシステムにおいて、前記グラフィクス及びディスプレイ・サブシステムが実行する追跡以外に、前記エンコード・サブシステムは、前記選択的更新を前記リモート端末に転送する必要があるか否か判断するために、追加の追跡を実行するよう構成されていることを特徴とするシステム。
6. 請求項４記載のシステムにおいて、前記エンコード・サブシステムは、グラフィクス・コマンドを前記グラフィクス及びディスプレイ・サブシステム又は前記ホストＣＰＵから受信し、前記ネットワーク・サブシステムを通じた前記対応するリモート端末への転送のために前記グラフィクス・コマンドを処理するよう構成されていることを特徴とするシステム。
7. 請求項１記載のシステムにおいて、前記サブ・フレームは、固定サイズのタイルであり、前記追跡は前記固定サイズのファイルに対して行われることを特徴とするシステム。
8. 請求項７記載のシステムにおいて、前記グラフィクス及びディスプレイ・サブシステムは、前記タイル上で署名を発生し、前記タイルを選択的に更新し前記エンコード・サブシステムに送るべきか否か判断するために、後続のタイルの前記署名を管理するよう構成されていることを特徴とするシステム。
9. 多数のリモート端末をサポートすることができるホスト・コンピュータ・システムであって、該システムは、
   前記ホスト・コンピュータ・システム内部においてシステム・バスを通じて他のサブシステムに接続されているホストＣＰＵと、
   前記リモート端末を管理するオフロード・サブシステムであって、
   前記バス上において、前記ホストＣＰＵが処理するグラフィクス・コマンド又はビデオ・データを傍受する手段と、
   前記傍受したグラフィクス・コマンド又はビデオ・データをエンコード、トランスコード、又はそれ以外で処理する手段と
   を備えているオフロード・サブシステムと、
   前記リモート端末の対応するものへのネットワーク・サブシステムを通じた転送のために、前記傍受し処理したグラフィクス・コマンドを管理する手段と
   を備えていることを特徴とするホスト・コンピュータ・システム。
10. 請求項９記載のシステムにおいて、前記オフロード・サブシステムは、前記ネットワーク転送に必要な帯域幅を削減するために、前記グラフィクス・コマンドを傍受し、該グラフィクス・コマンドと関連のあるデータ・ブロックをエンコードするよう構成されていることを特徴とするシステム。
11. 請求項９記載のシステムにおいて、前記オフロード・サブシステムは、前記ビデオ・データを傍受し、前記ネットワーク性能を一致させ前記リモート端末の個々の能力をデコードするために、前記ビデオ・データを、ビット・レート（レート変更）、フレーム・レート、解像度、又は符号化アルゴリズム（トランスコード）を変更することを含む処理を実行することを特徴とするシステム。
12. 請求項９記載のシステムにおいて、前記傍受する手段は、前記ホストＣＰＵ上でランする追跡ソフトウェア・レイヤを含むことを特徴とするシステム。
13. 請求項９記載のシステムにおいて、前記オフロード・サブシステムは、グラフィクス及びディスプレイ・コントローラからの１本以上の表示出力パスに接続する手段を含むことを特徴とするシステム。
14. 請求項１３記載のシステムにおいて、前記グラフィクス及びディスプレイ・コントローラは、１つのローカル・ディスプレイに対する出力を生成し、前記リモート端末を通じて遠隔管理を実行可能であることを特徴とするシステム。
15. 請求項１３記載のシステムにおいて、前記オフロード・サブシステムは、前記リモート端末の１つへのネットワーク送信の前に、前記ホスト・システムのグラフィクス及び表示出力のエンコードを実行することを特徴とするシステム。
16. 請求項１３記載のシステムにおいて、前記グラフィクス及びディスプレイ・コントローラは、多数のＲＴをサポートし、前記接続部は、前記オフロード・システムに、多数のリモート端末における異なるサブ・フレームに対応する選択的サブ・フレーム更新を供給することを特徴とするシステム。
17. 多数のリモート端末を有するマルチユーザ・ホスト・システムの動作方法であって、
    ソフトウェアと、主ＣＰＵと、オフロード・エンジンとを含むホスト・コンピュータを用いて、グラフィクス・コマンド又はビデオ・データを処理する際に前記ＣＰＵを補助するステップと、
    ビット・レートを変更し、解像度を変更し、フレーム・レートを変更し、又はエンコード・アルゴリズムを変更することによって、前記ビデオ・データを処理するステップと、
    前記グラフィクス・コマンドと関連のあるデータをカプセル化しエンコードすることによって、前記グラフィクス・コマンドを処理するステップと、
    前記リモート端末の内どれが、前記処理したグラフィクス・コマンド又は前記処理したビデオ・データの宛先となるのか判定を行うステップと、
    前記処理したグラフィクス・コマンド又は処理したビデオ・データを、ネットワーク・プロトコル技法にしたがって、ネットワーク・インターフェースを通じて伝搬させるステップと
    を備えていることを特徴とする方法。
18. 請求項１７記載の方法において、前記マルチユーザ・ホスト・システムは、フレーム・メモリが前記リモート端末の１つ以上に対応するローカル・グラフィクス・プロセッサを含み、前記ローカル・グラフィクス・プロセッサが、
    前記グラフィクス・コマンドを表示フレームにレンダリングするステップと、
    サブ・フレーム毎に、前記リモート端末の各々においてどのサブ・フレームを選択的に更新する必要があるか判定を行うステップと、
    前記選択的更新を前記オフロード・エンジンに送信するステップと
    を実行することを特徴とする方法。
19. 請求項１８記載の方法において、前記オフロード・エンジンは、前記選択的更新サブ・フレームのエンコードを実行するよう構成されていることを特徴とする方法。
20. 請求項１７記載の方法において、前記オフロード・エンジンは、前記主ＣＰＵから１つ以上の他の処理タスクもオフロードさせるために用いられることを特徴とする方法。

Images