(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022141586
(43)【公開日】2022-09-29
(54)【発明の名称】低遅延のために統合NICと共有フレームバッファアクセスとを有するクラウドゲーミングGPU
(51)【国際特許分類】
A63F 13/95 20140101AFI20220921BHJP
A63F 13/30 20140101ALI20220921BHJP
【FI】
A63F13/95 Z
A63F13/30
【審査請求】未請求
【請求項の数】20
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022019573
(22)【出願日】2022-02-10
(31)【優先権主張番号】17/202,065
(32)【優先日】2021-03-15
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.HDMI
(71)【出願人】
【識別番号】593096712
【氏名又は名称】インテル コーポレイション
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ダニエル ポール
(57)【要約】 (修正有)
【課題】統合ネットワークインターフェースコントローラ(NIC)と共有フレームバッファアクセスとを有するクラウドゲーミンググラフィックス処理ユニット(GPU)のための方法及び装置を提供する。
【解決手段】GPUは、統合されたエンコーダ/デコーダへの共有アクセスを提供する1つ以上のフレームバッファを含む。GPUはさらに、統合されたエンコーダ/デコーダに結合されている統合NICと、1つ以上のフレームバッファに結合されている1つ以上のビデオ出力とを含む。GPUは、ビデオコーデックを使用して、又はゲームタイルエンコーダ及びデコーダを使用して、エンコード及びデコードされる、アウトバウンド及びインバウンドのゲーム画像コンテンツを処理するように構成されている。
【選択図】
図1
【特許請求の範囲】
【請求項1】
グラフィックス処理ユニット(GPU)を備えている装置であって、前記グラフィックス処理ユニット(GPU)は、
複数のフレームバッファと、
少なくとも1つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも1つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ/デコーダと、
統合された前記エンコーダ/デコーダに結合されている統合ネットワークインターフェースコントローラ(NIC)とを含む、装置。
【請求項2】
装置は、入出力(I/O)インターフェースを有するグラフィックスカードを備え、前記統合NICは、前記グラフィックスカード上の前記I/Oインターフェースに結合されているインターフェースを含み、
前記統合NICは、ネットワークを介して前記I/Oインターフェースから送信されるデータを受信し、ネットワークから前記I/Oインターフェースに受信されたデータを転送するように構成されている、請求項1記載の装置。
【請求項3】
前記統合NICは、開放型システム間相互接続(OSI)モデルの少なくとも層3及び4を実施する埋め込みロジックを含む、請求項1又は2記載の装置。
【請求項4】
前記統合NICは、開放型システム間相互接続(OSI)モデルの層3ないし7を実施する埋め込みロジックを含む、請求項1ないし3のいずれか1項に記載の装置。
【請求項5】
統合された前記エンコーダ/デコーダは、ビデオコーデックを含む、請求項1ないし4のいずれか1項に記載の装置。
【請求項6】
前記GPUは、
ビデオゲームフレームコンテンツを生成し、1つ以上の前記フレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
前記ビデオコーデックを使用して、前記ビデオゲームフレームコンテンツをエンコードし、エンコードされたビデオゲームコンテンツを生成し、
前記統合NICを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、ネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項5記載の装置。
【請求項7】
前記GPUはビデオ出力を含み、装置はさらにグラフィックスカードを備え、前記グラフィックスカードは、
前記GPUに結合されているか、又は前記GPUに統合されているグラフィックスメモリと、
前記統合NICに結合されているネットワークポートと、
前記GPUに結合されている入出力(I/O)インターフェースと、
前記GPUで前記ビデオ出力に結合されているビデオポートとを含み、
前記グラフィックスカードは、
ストリーミングメディアコンテンツを含むパケットのストリームを、前記ネットワークポートに結合されたネットワークから受信し、
前記統合NICを使用して、パケットの前記ストリームをデパケット化し、エンコードされたビデオコンテンツを抽出するように構成され、
a)デパケット化されたエンコードされたビデオコンテンツを、前記ビデオコーデックにアクセス可能なバッファに書き込むこと、又は、
b)前記統合NIC上にバッファリングされた、デパケット化されたエンコードされたビデオコンテンツを、前記ビデオコーデックを介して読み取ること
のうちの1つをするように構成され、
前記グラフィックスカードは、
前記ビデオコーデックを使用して、エンコードされた前記ビデオコンテンツをデコードし、ビデオゲームフレームコンテンツを再生し、
少なくとも1つのフレームバッファに、再生された前記ビデオゲームフレームコンテンツをバッファリングし、
前記ビデオポートを介してビデオゲームフレームを含むディスプレイコンテンツを出力するように構成されている、請求項5又は6記載の装置。
【請求項8】
統合された前記エンコーダ/デコーダは、画像タイルエンコーダ及びデコーダである、請求項1ないし7のいずれか1項に記載の装置。
【請求項9】
前記GPUは、
ビデオゲームフレームコンテンツを生成し、1つ以上の前記フレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
前記画像タイルエンコーダを使用して、ビデオゲームフレームコンテンツのタイルをエンコードし、エンコードされたビデオゲームタイルを生成し、
前記統合NICを使用して、エンコードされた前記ビデオゲームタイルをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のイーサネットポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項8記載の装置。
【請求項10】
前記GPUはビデオ出力を含み、装置はさらにグラフィックスカードを備え、前記グラフィックスカードは、
前記GPUに結合されているか、又は前記GPUに統合されているグラフィックスメモリと、
前記統合NICに結合されているネットワークポートと、
前記GPUに結合されている入出力(I/O)インターフェースと、
前記GPUで前記ビデオ出力に結合されているビデオポートとを含み、
前記グラフィックスカードは、
ストリーミングされたビデオゲームタイルを含むパケットのストリームを、前記グラフィックスカード上のイーサネットポートに結合されたネットワークから受信し、
前記統合NICを使用して、パケットの前記ストリームをデパケット化し、エンコードされたビデオゲームタイルを抽出するように構成され、
a)デパケット化されたエンコードされたビデオゲームタイルを、画像タイルデコーダにアクセス可能なバッファに書き込むこと、又は、
b)前記統合NIC上にバッファリングされた、デパケット化されたエンコードされた画像タイルを、前記画像タイルデコーダを介して読み取ること
のうちの1つをするように構成され、
前記グラフィックスカードは、
前記画像タイルデコーダを使用して、エンコードされた前記画像タイルをデコードし、ゲーム画像タイルを再生し、
再生された前記ゲーム画像タイルをフレームバッファにアレイ配置し、ビデオゲームフレームを生成し、
前記ビデオポートを介してビデオゲームフレームを含むディスプレイコンテンツを出力するように構成されている、請求項8又は9記載の装置。
【請求項11】
統合ネットワークインターフェースコントローラ(NIC)を有するグラフィックス処理ユニットGPUを含むグラフィックスカードに実施される方法であって、
ビデオフレームコンテンツを生成し、前記GPU上の1つ以上のフレームバッファに前記ビデオフレームコンテンツをバッファリングするステップを備え、
前記GPUに統合されたビデオコーデックを使用して、前記ビデオフレームコンテンツをエンコードし、エンコードされたビデオコンテンツを生成するステップと、
前記統合NICを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、前記統合NIC上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するステップと、
又は、
前記GPUに統合された画像タイルエンコーダを使用して、ビデオフレームコンテンツのタイルをエンコードし、エンコードされたビデオタイルを生成するステップと、
前記統合NICを使用して、エンコードされた前記ビデオタイルをパケット化し、パケットのストリームを生成し、前記統合NIC上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するステップと
のうちの一方を備えている、方法。
【請求項12】
さらに、
前記グラフィックスカードの入出力(I/O)インターフェースで、エンコードされたオーディオコンテンツを受信するステップと、
前記I/Oインターフェースと前記統合NICとを結合する前記GPU上の相互接続を介して、エンコードされた前記オーディオコンテンツを転送するステップと、
前記統合NICを使用して、エンコードされた前記オーディオコンテンツをパケット化して、オーディオパケットのストリームを生成し、前記統合NICの出力ポートを介して前記ネットワークにアウトバウンドでオーディオパケットの前記ストリームを送信するステップとを備えている、請求項11記載の方法。
【請求項13】
さらに、
前記グラフィックスカードとクライアントデバイスとの間で、ストリーミングメディアセッションを確立するステップと、
前記ストリーミングメディアセッションを使用して、前記ストリーミングメディアセッションに関連付けられた少なくとも1つのプロトコルの使用により、パケットの前記ストリームを前記クライアントデバイスに転送するステップとを備えている、請求項11又は12記載の方法。
【請求項14】
前記グラフィックスカードはホストにインストールされ、前記グラフィックスカード上の入出力(I/O)インターフェースを介して、前記ホストと通信され、前記ビデオフレームコンテンツはビデオゲームフレームコンテンツであり、さらに、
前記ネットワークから、ビデオ制御入力データを受信するステップと、
前記統合NICを介して、前記ビデオ制御入力データが前記ホストに転送されることを検出するステップと、
前記グラフィックスカードの前記統合NICと前記入出力(I/O)インターフェースとの間に結合された相互接続を介して、ゲーム制御入力データを前記ホストに転送するステップとを備えている、請求項11ないし13のいずれか1項に記載の方法。
【請求項15】
前記ビデオフレームコンテンツはビデオゲームフレームコンテンツであり、さらに、
前記グラフィックスカードの入出力(I/O)インターフェースで、ゲーム制御データを受信するステップと、
前記I/Oインターフェースと前記統合NICとを結合する前記GPU上の相互接続を介して前記ゲーム制御データを転送し、信頼性のあるトランスポートプロトコルを使用して、前記ゲーム制御データをゲームクライアントデバイスに転送するステップとを備えている、請求項11ないし14のいずれか1項に記載の方法。
【請求項16】
複数の拡張スロット又はコネクタを有する第1ボードと、
前記第1ボード又は第2ボードに搭載されている中央処理ユニット(CPU)であり、前記第2ボードは、拡張スロットにインストールされているか、又は前記第1ボード上の嵌合コネクタに結合されている、中央処理ユニット(CPU)と、
前記CPUに通信接続されている1つ以上のメモリデバイスを含むメインメモリと、
a)それぞれの拡張スロットにインストールされている1つ以上のネットワークアダプタカード、又は、
b)前記第1ボード又は前記第2ボードに搭載されている1つ以上のネットワークインターフェースコントローラ(NIC)チップと、
それぞれの拡張スロットにインストールされている、又は前記第1ボード上の各嵌合コネクタに結合されている複数のグラフィックスカードとを備え、
各グラフィックスカードは、
グラフィックス処理ユニット(GPU)を含み、前記グラフィックス処理ユニット(GPU)は、
1つ以上のフレームバッファと、
少なくとも1つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも1つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ/デコーダと、
統合された前記エンコーダ/デコーダに結合されている統合ネットワークインターフェースコントローラ(NIC)と、
前記GPUに結合されているか、又は前記GPUに統合されているグラフィックスメモリと、
前記統合NICに結合されている少なくとも1つのネットワークポートと、
前記GPUに結合されている入出力(I/O)インターフェースと
を備えている、クラウドゲームサーバ。
【請求項17】
少なくとも1つのグラフィックスカードのための統合された前記エンコーダ/デコーダは、ビデオコーデックを含み、
少なくとも1つの前記グラフィックスカードでの前記GPUは、
ビデオゲームフレームコンテンツを生成し、前記GPUで1つ以上のフレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
前記ビデオコーデックを使用して、前記ビデオゲームフレームコンテンツをエンコードし、エンコードされたビデオゲームコンテンツを生成し、
前記GPUで前記統合NICを使用して、エンコードされた前記ビデオコンテンツをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のネットワークポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項16記載のクラウドゲームサーバ。
【請求項18】
統合された前記エンコーダ/デコーダは、画像タイルエンコーダ及びデコーダであり、
少なくとも1つのグラフィックスカードの前記GPUは、
ビデオゲームフレームコンテンツを生成し、前記GPUで1つ以上のフレームバッファに前記ビデオゲームフレームコンテンツをバッファリングし、
前記画像タイルエンコーダを使用して、ビデオゲームフレームコンテンツのタイルをエンコードし、エンコードされたビデオゲームタイルを生成し、
前記統合NICを使用して、エンコードされた前記ビデオゲームタイルをパケット化し、パケットのストリームを生成し、前記グラフィックスカード上のネットワークポートに結合されているネットワークにアウトバウンドでパケットの前記ストリームを送信するように構成されている、請求項16又は17記載のクラウドゲームサーバ。
【請求項19】
クラウドゲームサーバ内の前記メインメモリと記憶デバイスとのうちの少なくとも1つに存在するゲームソフトウェアをさらに含み、前記ゲームソフトウェアを実行することは、クラウドゲームサーバが下記のステップ、即ち、
少なくとも1つのネットワークアダプタカード又はNICを使用するネットワーク通信を使用して、ネットワークに結合された複数のゲームクライアントデバイスとともにストリーミングメディアセッションを確立するステップと、
複数の前記ストリーミングメディアセッションを使用して、複数のグラフィックスカードの使用によりパケットのストリームを複数の前記ゲームクライアントデバイスに転送するステップとを実行することを可能にする、請求項16ないし18のいずれか1項に記載のクラウドゲームサーバ。
【請求項20】
クラウドゲームサーバはさらに、クラウドゲームサーバ上にホストされるゲームのインスタンスのためのオーディオコンテンツを生成し、前記オーディオコンテンツを複数の前記ゲームクライアントデバイスにストリーミングするように、構成されている、請求項19記載のクラウドゲームサーバ。
【発明の詳細な説明】
【技術分野】
【0001】
クラウドゲーミングはオンラインゲームの一種で、データセンター(別名は「クラウド」)のリモートサーバ上でビデオゲームを実行し、ローカルクライアントソフトウェアを介して、ビデオコンテンツとしてプレーヤーのデバイスにストリーミングする。ローカルクライアントソフトウェアは、ビデオコンテンツをレンダリングし、リモートサーバにプレーヤーの入力を提供するために使用される。これは、ゲームがユーザのビデオゲームコンソール、パーソナルコンピュータ、又はモバイルデバイス上でローカルに実行される既存のゲーム手段とは対照的である。
【背景技術】
【0002】
遅延は、クラウドゲーミングの成功や、インタラクティブな家庭内ストリーミング(例えば、レンダリングにはPC(パソコン)を使用するが、他の部屋のタブレットでプレイする)のために、最も重要な基準の1つである。今日使用されている1つのアプローチは、ビデオコンテンツをレンダリングし、グラフィックス処理ユニット(GPU)を有する別個のグラフィックスカードを使用してストリーミングされるエンコードされた画像データを準備し、次いで、プラットフォームの中央処理ユニット(CPU)及びネットワークカードを使用して、ネットワークを介してプレーヤーのデバイスに画像データをストリーミングすることである。しかし、GPUでレンダリング及び/又はエンコードされたデータは、まずメインPC又はデバイスメモリにコピーされなければならず、次いで、送出される画像データのためにネットワークカードに転送されなければならないので、結果的にボトルネックとなる。
【発明の概要】
【0003】
本発明は、装置であって、
グラフィックス処理ユニット(GPU)を備え、グラフィックス処理ユニット(GPU)は、
複数のフレームバッファと、
少なくとも1つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも1つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ/デコーダと、
統合されたエンコーダ/デコーダに結合されている統合ネットワークインターフェースコントローラ(NIC)とを含む、装置を提供するものである。
【0004】
また本発明は、統合ネットワークインターフェースコントローラ(NIC)を有するグラフィックス処理ユニットGPUを含むグラフィックスカードに実施される方法であって、
ビデオフレームコンテンツを生成し、GPU上の1つ以上のフレームバッファにビデオフレームコンテンツをバッファリングするステップを備え、
GPUに統合されたビデオコーデックを使用して、ビデオフレームコンテンツをエンコードし、エンコードされたビデオコンテンツを生成するステップと、
統合NICを使用して、エンコードされたビデオコンテンツをパケット化し、パケットのストリームを生成し、統合NIC上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットのストリームを送信するステップと、
又は、
GPUに統合された画像タイルエンコーダを使用して、ビデオフレームコンテンツのタイルをエンコードし、エンコードされたビデオタイルを生成するステップと、
統合NICを使用して、エンコードされたビデオタイルをパケット化し、パケットのストリームを生成し、統合NIC上の出力ポートに動作可能に結合されているネットワークにアウトバウンドでパケットのストリームを送信するステップと
のうちの一方を備えている、方法を提供するものである。
【0005】
さらに本発明は、クラウドゲームサーバであって、
複数の拡張スロット又はコネクタを有する第1ボードと、
第1ボード又は第2ボードに搭載されている中央処理ユニット(CPU)であり、第2ボードは、拡張スロットにインストールされているか、又は第1ボード上の嵌合コネクタに結合されている、中央処理ユニット(CPU)と、
CPUに通信接続されている1つ以上のメモリデバイスを含むメインメモリと、
a)それぞれの拡張スロットにインストールされている1つ以上のネットワークアダプタカード、又は、
b)第1ボード又は第2ボードに搭載されている1つ以上のネットワークインターフェースコントローラ(NIC)チップと、
それぞれの拡張スロットにインストールされている、又は第1ボード上の各嵌合コネクタに結合されている複数のグラフィックスカードとを備え、
各グラフィックスカードは、
グラフィックス処理ユニット(GPU)を含み、グラフィックス処理ユニット(GPU)は、
1つ以上のフレームバッファと、
少なくとも1つのフレームバッファに結合され、画像データとビデオコンテンツとのうちの少なくとも1つをエンコード及びデコードする埋め込みロジックを含む、統合されたエンコーダ/デコーダと、
統合されたエンコーダ/デコーダに結合されている統合ネットワークインターフェースコントローラ(NIC)と、
GPUに結合されているか、又はGPUに統合されているグラフィックスメモリと、
統合NICに結合されている少なくとも1つのネットワークポートと、
GPUに結合されている入出力(I/O)インターフェースと
を備えている、クラウドゲームサーバを提供するものである。
【図面の簡単な説明】
【0006】
本発明の上述の態様、及び多くの付随する利点は、以下の詳細な説明を添付図面と併せて参照することによりさらによく解釈され、容易に理解されるものである。図面において特にことわらない限り、同様の符号は種々の図面の全体を通じて、同様の部分を指す。
【0007】
【
図1】一実施形態に係り、統合されたビデオコーデックと統合されたNICとを有するGPUを含む、グラフィックスカードの概略図である。
【
図1a】一実施形態に係り、NICに直接結合されている統合されたビデオコーデックを有するGPUを含む、グラフィックスカードの概略図である。
【
図1b】一実施形態に係り、統合されたビデオコーデックを有するGPUと、マルチチップモジュール上に組み合わされたNICとを含む、グラフィックスカードの概略図である。
【
図1c】一実施形態に係り、統合されたタイルエンコーダ/デコーダと統合されたNICとを有するGPUを含む、グラフィックスカードの概略図である。
【
図2】一実施形態に係り、ゲームサーバとゲームクライアントデバイスとでの
図1のグラフィックスカードの使用を示す概略図である。
【
図2a】一実施形態に係り、ゲームサーバとゲームクライアントデバイスとでの
図1aのグラフィックスカードの使用を示す概略図である。
【
図3】一実施形態に係り、ゲームサーバにおける
図1のグラフィックスカードの使用を図示し、WiFiチップと直接通信するための統合ネットワークインターフェースを備えたGPUを含むゲームラップトップクライアントを図示する概略図である。
【
図4】Iフレームと、Pフレームと、Bフレームとから構成される例示的なフレームエンコード及び表示方式を示す概略図である。
【
図5】一実施形態に係り、ゲームサーバ200とデスクトップゲームクライアント202との間のエンドツーエンドの画像データフローの例を示す概略図である。
【
図6】一実施形態に係り、
図5のエンドツーエンド画像データフロースキームを容易にするために実行される操作を示すフローチャートである。
【
図7a】一実施形態に係り、統合されたタイルエンコーダを有するGPUを使用したゲームタイルの生成、エンコード及びストリーミングを示す図である。
【
図7b】一実施形態に係り、統合されたタイルデコーダを有するGPUを使用したタイルデコード及び再生を含む、ゲームクライアントで受信されたゲームタイルのストリームの扱いを示す図である。
【
図8】一実施形態に係り、複数のグラフィックスカードと、メインボードの拡張スロットにインストールされた1つ以上のネットワークカードとを含む、ゲームサーバの概略図である。
【
図8a】一実施形態に係り、NICチップが搭載されたメインボードの拡張スロットにインストールされた複数のグラフィックスカードを含む、ゲームサーバの概略図である。
【
図8b】一実施形態に係り、複数のグラフィックスカードと、バックプレーン、ミッドプレーン、又はベースプレーンのスロット又は嵌合コネクタにインストールされたブレードサーバとを含む、ゲームサーバの概略図である。
【
図9】一実施形態に係る統合NICを示す概略図である。
【発明を実施するための形態】
【0008】
一層低い遅延のために統合ネットワークインターフェースコントローラ(NIC)と共有フレームバッファアクセスとを有する、クラウドゲーミングGPUのための方法及び装置の実施形態を、ここで説明する。以下の記載では、本発明に係る実施形態の完全な理解をもたらすため、数多くの具体的で明細な詳細が説明される。しかし、当業者であれば、1つ以上の具体的な詳細を使用せずに、又は、他の方法、コンポーネント、材料などを使用して本発明が実施されてよいことを認識することである。本発明の態様を曖昧にすることを避けるため、他の例における、周知の構造、材料又は操作について図示又は詳述しないこととする。
【0009】
本明細書を通じて、「一実施形態」又は「実施形態」へ言及することは、本発明の少なくとも1つの実施形態に、その実施形態に関連して述べられる特別な特徴、構造又は特質が含まれることを意味する。従って、本明細書を通してさまざまな箇所における表現「一実施形態での」又は「実施形態での」の全てが、必ずしも同一の実施形態に言及するわけではない。さらに、特別な特徴、構造又は特質は1つ以上の実施形態で任意の適当な方式で組み合わせられてよい。
【0010】
明瞭にするために、本明細書中の図中の個別のコンポーネントは、特定の参照番号によってではなく、図中のそれらの標識付けによって参照される場合がある。さらに、(特定のコンポーネントとは対照的に)特定のタイプのコンポーネントを参照する参照番号は、参照番号の後に「典型的」を意味する「(typ)」を付けて示す場合がある。これらのコンポーネントの構成は、存在し得るが簡潔さ及び明快さのために図面には示されない類似のコンポーネントのうちで代表的であり、又は別個の参照番号で標識付けされない他に類似のコンポーネントのうちで代表的であることが、理解されるものである。反対に、「(typ)」は、その開示された機能、器具、目的などのために、コンポーネント、要素などが典型的に使用されることを意味するものと解釈されないものとする。
【0011】
本明細書に開示される実施形態の態様によれば、統合されたエンコーダと統合されたNICとを有するGPUが提供される。GPUは、統合されたエンコーダ/デコーダ及び他のGPUコンポーネントへの共有アクセスを提供する1つ以上のフレームバッファを含む。GPUは、ビデオコーデックを使用して、又はゲームタイルエンコーダ及びデコーダを使用してエンコード及びデコードされる、アウトバウンド及びインバウンドのゲーム画像コンテンツを処理するように構成される。例えば、ローカルビデオゲームホストのクラウドゲームサーバに実施されると、GPUによって生成され、フレームバッファにバッファされたビデオゲームフレームは、統合されたエンコーダによってエンコードされ、メディアストリーミングプロトコルを使用してパケット化及びストリーミングされるために直接NICに転送される。インバウンドでストリーミングされたメディアコンテンツは、NICによってデパケット化され、統合されたデコーダによってデコードされ、統合されたデコーダは、デコードされたコンテンツをフレームバッファに書き込み、ゲームクライアントデバイス上でビデオゲームフレームを再生する。次に、ビデオゲームフレームがクライアントデバイスディスプレイに表示される。
【0012】
一般に、GPUは、グラフィックスカードに実施してよく、又はラップトップ又はノートブックコンピュータ又はモバイルデバイスのようなゲームクライアントデバイスのメインボードに実施してよい。処理パスはCPUとの間でエンコードされたデータを転送することを含まないので、グラフィックスカードは、アウトバウンドゲームコンテンツを生成するとき、及びインバウンドゲームコンテンツを処理するときのために、遅延を短縮する。
【0013】
図1は、フレームバッファ104を有するGPU102を含むグラフィックスカード100を示す。フレームバッファ104は、インターフェース108を介してH.264/H.265ビデオコーデック106によってアクセスされる。H.264/H.265ビデオコーデック106は、この実施形態ではGPU102に搭載されているNIC112に結合されたI/Oインターフェース110を含む。GPU102は、図示の実施形態では、GDDR5メモリのようなグラフィックスメモリ114に結合されている。他のタイプのグラフィックメモリも同様に使用することができる。さらに、グラフィックスメモリの全部又は一部は、GPU上に存在してよい。
【0014】
GPU102とグラフィックスカード100とは、GPU102に結合されたPCIe(Peripheral Component Interconnect Express)インターフェース116と、DisplayPort又はHDMIポートなどの1つ以上のグラフィックスポート120に結合されたGPU102上のグラフィックス出力118と、NIC112に結合されたイーサネット(登録商標)ポート122とを含む、追加のインターフェースを有する。データパス123によって示されるように、NIC112はまた、PCIeインターフェース116を介してホストCPU(図示せず)と通信してよい。
【0015】
オンチップNICを有するGPUを有することに加えて、
図1aのグラフィックスカード100aに示されるように、グラフィックスカードは、オフチップNICに結合されたGPUを含んでよい。この構成の下では、GPU102aは、NIC112aに結合されたI/Oインターフェース124を含む。I/Oインターフェース124は、H.264/H.265ビデオコーデック106上のI/Oインターフェース110に結合されている。NIC112aはまた、リンク125によって示されるように、PCIeインターフェース116に結合されている。
【0016】
GPU上にNICを統合すること(例えば、埋め込み回路として、及び/又はGPU回路と同じ基板上の回路ダイとして)に加えて、GPUチップとNICチップとを含むマルチチップモジュール又はパッケージを、さらに使用してよい。この一例が
図1bに示され、グラフィックスカード100bはGPU102bとNIC112bとを含み、これらはマルチチップモジュール126の一部である。
【0017】
別の実施形態(図示せず)では、CPU及びGPU100又は100aは、システムオンチップ(SoC)に統合されてよい。あるいは、CPU、GPU100b、及びNIC112bは、マルチチップモジュール又はパッケージ、又はCPU+GPU SoCで実施されてよく、NICチップは、マルチチップモジュール又はパッケージで実施されてよい。
【0018】
一般に、グラフィックスカード100、100a、及び100bは、サーバなどのPCIeスロットにインストールされ、サーバのメザニンカードなどとして実施され、ブレードサーバ又はサーバモジュールのドーターボードとして実施される。以下に説明及び例示するように、ラップトップ、ノートブック、タブレット、及び携帯電話のような他の形態ファクタを有するデバイスのために、同様のコンポーネントをグラフィックスチップセットなどで実施してよい。
【0019】
フレーム情報は、フレームの画素解像度、フレームバッファフォーマット(例えば、RGBA8ビット又はRGBA32ビットなど)、及びフレームバッファポインタへのアクセスのようなフレームバッファ104から取得してよい。これは、レンダリングのために二重又は三重のバッファリングが使用される場合に経時的に変化する可能性がある。さらに、いくつかの実施に対して、色データ情報に加えて、GPUバッファからの深度データを取得してよい。例えば、立体ゲーミングのようなシナリオでは、色データとともに深度データをクライアントにストリーミングすることが有利である場合がある。
【0020】
図2は、ネットワーク204を介してデスクトップゲームクライアント202に結合されたゲームサーバ200を含む、クラウドゲーミングの実施の一実施形態を示す。ゲームサーバ200とデスクトップゲームクライアント202との各々は、グラフィックスカード100-1及び100-2によって示されるように、
図1のグラフィックスカード100のそれぞれのインスタンスを有する。ゲームサーバ200は、メインメモリ208に結合されたマルチコアプロセッサからなるCPU206を含み、この中で、ゲームサーバソフトウェア210は、CPU206の1つ以上のコア上で実行されるようにロードされる。CPU206は、PCIeインターフェース116を介してグラフィックカード100-1に結合され、イーサネットポート122-1は、インターネットのような複数の相互接続されたネットワークを表すネットワーク204に結合される。
【0021】
実際には、クラウドゲームサーバは、配信ネットワーク(CDN)228を介してコンテンツを配信することができる。
図2に示すように、CDN228は、ゲームサーバ200とネットワーク204との間に位置する。
【0022】
デスクトップゲームクライアント202は、一般に、デスクトップコンピュータなどを使用して実現されてよい種々のタイプのゲームクライアントを示す。図示の実施形態では、グラフィックスカード100-2は、デスクトップコンピュータのPCIeスロットにインストールされたPCIeグラフィックスカードである。場合によっては、デスクトップコンピュータ用の複数の拡張スロットを占有する1つのPCIeスロットを介して、PCIeグラフィックスカードを接続してよい。デスクトップゲームクライアント202は、CPU212を含み、これは、クライアント側のゲームソフトウェア216がロードされたメインメモリ214に結合されたマルチコアプロセッサであり、CPU212上の1つ以上のコアによって実行される。グラフィックスカード100-2のイーサネットポート122-2は、ネットワーク204に結合される。典型的なゲームプレーヤーの場合に、デスクトップゲームクライアント202は、ローカルエリアネットワーク(LAN)に結合される。これはケーブルモデム又は類似のワイドエリアネットワーク(WAN)アクセスデバイスに結合されるスイッチを含む。これはインターネットサービスプロバイダ(ISP)ネットワーク218に結合される。これは次にネットワーク204に結合される。
【0023】
図2aは、ネットワーク204とISPネットワーク218とを介してデスクトップゲームクライアント202aに結合された、ゲームサーバ200aを含むクラウドゲーミング実施の一実施形態を示す。ゲームサーバ200aとデスクトップゲームクライアント202aとの各々は、グラフィックスカード100a-1及び100a-2として示された、
図1aのグラフィックスカード100aのそれぞれのインスタンスを有する。一般に、
図2及び
図2aにおける同様の番号のコンポーネント及びブロックは、類似のものであり、類似の動作を行う。以下にさらに詳細に説明するように、
図2及び
図2aのクラウドゲーミングの実施間の差は、出力の(out)ビデオ制御入力であり、非画像データが処理される。同時に、
図2及び
図2aの実施形態における画像データの処理及び転送は、類似する。
【0024】
図3は、CDN228と、ネットワーク303と、ISPネットワーク318とを介して、ラップトップゲームクライアント301に結合されたゲームサーバ200を含む、クラウドゲーミングの実施を示す。ゲームサーバ200は、上述のものと同じ、
図2に示される構成を有する。任意には、ゲームサーバ200は、
図2のゲームサーバ200aによって置き換えられてよい。
【0025】
ラップトップゲームクライアント301はメインボード300を含み、これは、グラフィックスメモリ314に結合されたGPU302と、メインメモリ328及びGPU302に結合されたCPU326と、WiFi(登録商標)チップ315と、DisplayPort及び/又はHDMIポート320と、USB-Cインターフェース332とを備えている。前と同様に、クライアント側のゲームソフトウェアは、メインメモリ328にロードされ、CPU326上の1つ以上のコア上で実行される。GPU302は、インターフェース308を介してH.264/H.265ビデオコーデック306によってアクセスされるフレームバッファ304を含む。H.264/H.265ビデオコーデック306は、ネットワークインターフェース313に結合されるI/Oインターフェース310を含み、これはハードウェアベースのネットワークスタック317に結合されている。概括的に、ハードウェアベースのネットワークスタック317は、WiFi(登録商標)チップ315上に統合されてよく、又は別のコンポーネントを含んでよい。概括的に、USB-C、USB3.0、USB2.0及びPCIe相互接続などの様々な通信ポートとI/O相互接続とをサポートする、CPU326に結合されたモバイルチップセット(図示せず)を、ラップトップゲームクライアントは含む。
【0026】
ラップトップゲームクライアント301のための例示した構成の下では、無線アクセスポイント324とアンテナ319とによって無線通信が促進される。前述のように、無線アクセスポイントは、ISPネットワーク318に接続されるようにするケーブルモデム又は類似のISPアクセス手段に接続される。任意には、イーサネットアダプタをUSB-Cインターフェース332に接続してよく、ラップトップゲームクライアント301が、(イーサネットスイッチ及びケーブルモデムを介して)ISPネットワーク318へのイーサネットリンクを使用することを可能にする。
【0027】
メインボード300は、ディスプレイ334が結合されるラップトップハウジング内に収容される。概括的に、GPU302に内蔵されているか、又はLCDドライバ336によって示されるように、GPU302に結合された個別のコンポーネント上に実施されている適用可能な回路によって、ディスプレイは駆動される。
【0028】
本明細書の実施形態では、CPU上で動作するソフトウェア(オペレーティングシステム及び/又はNICドライバなど)、プラットフォーム/サーバファームウェア、及び/又はCPU上で動作するソフトウェア又はプラットフォーム/サーバファームウェアから構成情報を受信するGPUを介して、NICは構成されてよい。例えば、いくつかの実施形態では、NICは、PCIeエンドポイントとして実施され、CPUによって管理されるPCIe相互接続構造のPCIe階層の一部である。他の実施形態では、GPU上のソフトウェアは、NICを構成する方法についての命令をGPUに提供する。
【0029】
ビデオエンコード及びストリーミングの手引書
【0030】
本明細書に開示される実施形態の態様の下では、プレーヤー(別名はプレーヤーデバイス)によって操作されるエンドユーザデバイスに、遅延を減少させる方式でビデオゲーム画像データをストリーミングするための技術が提供される。フレームエンコード及びデコードを使用する場合のビデオゲーム画像データのストリーミングの態様は、ビデオストリーミングに使用されるのと同じコーデック(コーダ/デコーダ)を使用してよい。従って、実施形態がどのように実施されてよいかを一層よく理解するために、ビデオ圧縮及び解凍技術の基本的態様の説明が最初に提供される。本明細書の詳細に加えて、ビデオ圧縮及び解凍がどのように実施されるかに関するさらなる詳細は、多くのオンラインソースから入手可能である。これは、後述する説明の多くの情報源である、
http://www.eetimes.com/document.asp?doc_id=1275437
で入手可能な「ビデオ圧縮はどのように作用するか」と題するEE Times.comの記事を含む。
【0031】
基本的なレベルでは、ストリーミングビデオコンテンツは、「フレーム」又は「ピクチャー」のシーケンスとしてディスプレイ上でプレイバックされる。各フレームは、レンダリングされると、プレイバック解像度に対応する寸法を有する画素のアレイから構成される。例えば、フルHD(ハイビジョン)ビデオは、1920水平画素×1080垂直画素の解像度を有し、これは一般に1080p(プログレッシブ)又は1080i(インターレース)として知られている。次に、フレームはフレームレートで表示され、フレームのデータがフレームレートでリフレッシュ(該当する場合は、再レンダリング)される。長年にわたり、標準精細度(SD)テレビは、30i(毎秒30フレーム(fps)インターレース)のリフレッシュレートを使用した。これは、1/30秒毎に交互に、インターレースビデオコンテンツの2つのフィールドを更新することに相当する。これは、フレーム速度が毎秒60フレームであるという錯覚を生じさせた。また、SDコンテンツは歴史的にアナログビデオであり、画素ではなくラスタ走査をディスプレイに使用していたことにも留意するものとする。デジタルディスプレイ上のSDビデオの解像度は480ラインであり、数十年間使用されてきたアナログ信号は、実際には約525走査ラインを有していた。その結果、DVDコンテンツは歴史的に、米国などのNTSC(全米テレビジョンシステム委員会)市場では、480i又は480pでエンコードされてきた。
【0032】
ケーブルテレビや衛星テレビのプロバイダは、ビデオコンテンツを光ケーブルや有線ケーブル、あるいは大気(長距離無線)を介してストリーミングする。地上波の放送も同様に、空気中で送信され、従来はアナログ信号として放送されていたが、2010年頃からは全ての大電力テレビ放送局がデジタル信号のみを使用して放送することが必要とされている。米国におけるデジタルテレビ放送信号は、一般的に480i、480p、720p(1280×720画素解像度)、1080iを含む。
【0033】
ブルーレイ(登録商標)ディスク(BD)ビデオコンテンツは、2003年に日本で導入され、2006年に正式にリリースされた。ブルーレイディスクは、最大1080pでビデオプレイバックをサポートする。これは、60(59.94)fpsで1920×1080に相当する。BDは60fpsまでサポートするが、BDコンテンツの多く(特に最近のBDコンテンツ)は、実際には24fpsプログレッシブ(1080/24pとしても知られる)でエンコードされる。これは、フィルム(映画)に歴史的に使用されてきたフレームレートである。24fpsから60fpsへの変換は、典型的には、3:2の「プルダウン」技術を使用して行われ、その下で、フレームコンテンツが3:2のパターンで繰り返され、これは、特に、多くの動きのあるコンテンツをプレイバックするときに、様々なタイプのビデオアーチファクトを生じる可能性がある。さらに新しい「スマート」テレビは、120Hz又は240Hzのリフレッシュレートを有し、それぞれが24の偶数倍の数である。その結果、これらのテレビは、HDMI(High Definition Multimedia Interface)デジタルビデオ信号を使用して24fps「ムービー」又は「シネマ」モードをサポートし、抽出されたフレームコンテンツを5:5又は10:10プルダウンで繰り返して、24fpsコンテンツを120fps又は240fpsで表示し、テレビのリフレッシュレートにマッチングさせる。さらに最近では、ソニーやサムスンなどのメーカーが出しているスマートテレビは、スムージング効果を作り出すために、実際の24fpsフレームの間に複数の補間フレームを作るプレイバックモードをサポートしている。
【0034】
H.262/MPEG-2 Part2,H.264/MPEG-4 AVC,及びVC-1の3種類のビデオエンコード規格をサポートする対応したブルーレイディスクプレイバックデバイスが必要である。これらのビデオエンコード規格の各々は、これらの規格の間にいくつかの相違点があることに注意して、以下に記載される同様の方式で動作する。
【0035】
DVDやBlu-ray(登録商標)Discでエンコードされたビデオコンテンツに加えて、ビデオストリーミング技術を使用して大量のビデオコンテンツが配信される。映画及びテレビ番組のようなストリーミングメディアに使用されるエンコード技術は、一般に、BDコンテンツに使用されるものと同一であってよく、又は類似してよい。例えば、Netflix(登録商標)とAmazon(登録商標)Instant Videoとは、それぞれ(プレイバックデバイスの機能に依存する他のストリーミング形式に加えて)VC-1を使用している。VC-1は、当初、Microsoftが開発したプロプライエタリのビデオ形式で、2006年にSMPTE(Society of Motion Picture and Television Engineers)ビデオコーデック規格としてリリースされた。一方、YouTube(登録商標)では、一般的にアップロードされたビデオコンテンツの記録に使用されるのと同じビデオエンコード規格の混合物を使用し、その大部分は、オリジナルのテレビコンテンツやいくつかの最近の(再送の)映画を記録するのに使用されるプロレベルの機器ではなく、消費者レベルのビデオ録画機器(例えば、ビデオカメラ、携帯電話やデジタルカメラ)を使用して記録される。
【0036】
ビデオコンテンツがどれだけストリーミングされているかの一例を示すと、最近の測定では、ピークの消費期間の間では、Netflixストリーミングがコムキャストのケーブルインターネットサービスの帯域幅の3分の1以上を使用していたことが示されている。2011年以降のフルHD(1080p)ストリーミングに加えて、Netflix,Amazon,Hulu(登録商標),また、Ultra-High Definition又はUHDとも呼ばれる4Kビデオ(3840×2160)での絶えず増え続けるビデオコンテンツのストリーミングが行われている。
【0037】
さらに高度なスマートテレビは、IEEE802.11ベースの無線ネットワーク(一般にWiFi(登録商標)と称する)を介して配信されるストリーミングメディアのプレイバックを世界的にサポートする。さらに、新しいBDプレーヤーのほとんどは、全てのスマートフォンと同様に、ビデオコンテンツのWiFi(登録商標)ストリーミングをサポートしている。これに加えて、最近の多くのスマートフォンやタブレットでは、WiFi(登録商標)ダイレクトや無線MHL(Mobile High-Direction Link)や類似の規格を使用して、スマートフォンやタブレットによってプレイバックを行ってスマートテレビでビデオを見ることができる、無線ビデオストリーミング方式をサポートしている。さらに、LTE(ロングタームエボリューション)と第5世代(5G)モバイルネットワーク上で利用可能なデータサービス帯域幅は、IPTV(Internet Protocol Television)のようなサービスを、モバイルネットワークを介してテレビやその他のビデオコンテンツを見るための実行可能な手段にしている。
【0038】
解像度1080では、各フレームは約210万画素を備えている。8ビット画素エンコードのみを使用することは、仮にビデオコンテンツが生画素データとして配信される場合に、たった1フレーム/秒であるフレームレートをサポートするために、ほぼ1,700万ビット/秒(mbps)のデータストリーミングレートが必要となる。これは非現実的となるため、ビデオコンテンツは高度に圧縮されたフォーマットでエンコードされる。
【0039】
インターネットブラウザを使用して表示されるような静止画像は、典型的には、JPEG(Joint Photographic Experts Group)又はPNG(Portable Network Graphics)エンコードを使用してエンコードされる。元のJPEG規格は、デコードされた画像中の画素が元の画像と異なることがある「非可逆」圧縮方式を定義する。対照的に、PNGは「可逆」圧縮方式を使用している。可逆ビデオは多くのレベルでは非現実的であったので、最初のMPEG-1圧縮標準(1993)を定義したMotion Photographic Expert Group(MPEG)のような様々なビデオ圧縮標準化団体は、予測フレーム(「Pフレーム」)や双方向フレーム(「Bフレーム」)のような他のタイプのフレームを生成するために使用される動き予測技術と組み合わせて、イントラフレーム(「Iフレーム」)(「キー」フレームとしても知られる)の静止画像エンコードを含む非可逆圧縮技法を使用している。
【0040】
デジタル化されたビデオコンテンツはフレームのシーケンスから構成されるので、ビデオ圧縮アルゴリズムは、静止画像圧縮に使用される概念及び技術を使用する。静止画像圧縮は、ブロックエンコードと高度な数学の組み合わせを使用して、画像をエンコードするために使用されるビットの数を実質的に減少させる。例えば、JPEGは画像を8×8画素ブロックに分割し、離散コサイン変換(DCT)を使用して各ブロックを周波数領域表現に変換する。一般に、8×8以外の他のブロックサイズと、DCT以外のアルゴリズムとを、規格に基づくプロプライエタリの、他の圧縮方式のブロック変換演算に使用してよい。
【0041】
DCT変換は、周波数ベースの圧縮技術を容易にするために使用される。人の視覚は、高周波に含まれる情報(小さな特徴に対応する)よりも、低周波に含まれる情報(画像の大きな特徴に対応する)の方に敏感である。DCTは、知覚的に重要度の高い情報を、知覚的に重要度の低い情報と区別するのに役立つ。
【0042】
ブロック変換の後、各ブロックの変換係数は、量子化と符号化とを使用して圧縮される。量子化は、バイアスされた方式で変換係数の精度を低下させる。即ち、一層多くのビットが低周波係数に使用され、一層少ないビットが高周波係数に使用される。これは、前述したように、人間の視覚は低周波情報の方に一層敏感であるという事実を利用しているため、高周波情報はより近似的である。
【0043】
次に、量子化されたDCT係数を表現するために使用されるビット数は、係数の統計的性質のいくつかを利用する「符号化」によって低減される。量子化後、DCT係数の多く(多くの場合に、高周波係数の大多数)はゼロである。「ランレングス符号化」(RLC)と呼ばれる技術は、個別のゼロ値の係数をエンコードする代わりに、連続するゼロ値の係数(「ラン」)をグループ化し、係数の数(「レングス」)をエンコードすることによって、この事実を利用する。
【0044】
ランレングス符号化は、典型的には、可変長符号化(VLC)が後続する。可変長符号化において、一般的に発生するシンボル(量子化DCT係数、又はゼロ値の量子化係数のランを表す)は、数ビットのみを含むコードワードを使用して表現されるが、一層一般的でないシンボルは、一層長いコードワードで表現される。最も一般的なシンボルに対して一層少ないビットを使用して、VLCは、シンボルをエンコードするために必要とされる平均ビット数を減少させ、それによって、画像の全体をエンコードするために必要とされるビット数を減少させる。
【0045】
この段階では、前述の技術は全て、他のブロックとは独立して、各8×8ブロック上で動作する。画像は、典型的には、8×8ブロックよりもはるかに大きい特徴を含むので、画像内の隣接するブロック間の類似性を考慮することによって、より効率的な圧縮を達成することができる。このようなブロック間の類似性を利用するために、変換係数の量子化の前に予測ステップがしばしば追加される。このステップでは、コーデックは、周囲のブロックからの情報を使用してブロック内の画像情報を予測しようと試みる。いくつかのコーデック(MPEG-4など)は、DCT係数を予測することによって、周波数領域でこのステップを実行する。他のコーデック(H.264/AVCなど)は、空間領域でこのステップを実行し、画素を直接予測する。後者のアプローチは「イントラ予測」と呼ばれる。
【0046】
この演算では、エンコーダは、周囲のブロックの係数又は画素に基づいて、各ブロックのDCT係数(周波数領域で行われる場合)又は画素値(空間領域で行われる場合)のいくつかの値を予測しようと試みる。次に、エンコーダは、実際の値と予測値との差を計算し、実際の値ではなく差をエンコードする。デコーダにおいて、係数は、同じ予測を実行し、次いで、エンコーダによって伝送される差を加算することによって再構成される。この差は実際の係数値と比較して小さい傾向があるので、この技術はDCT係数を表すのに必要なビット数を減らす。
【0047】
特定のブロックのDCT係数又は画素値を予測する際に、デコーダは、既にデコードされている周囲のブロックの値のみにアクセスする。従って、エンコーダは、以前にエンコードされた周囲のブロックからの値のみに基づいて、各ブロックのDCT係数又は画素値を予測しなければならない。JPEGは、最も低い周波数係数(「DC係数」)のみが単純な微分符号化を使用して予測される、非常に基本的なDCT係数予測方式を使用する。MPEG-4ビデオは、8×8ブロックの各行及び各列の第1のDCT係数の予測を試行するために、一層精密にされた方式を使用する。
【0048】
MPEG-4とは対照的に、H.264/AVCでは、予測は画素上で直接行われ、DCTのような整数変換は常に、動き推定又はイントラ予測のいずれかから、残差を処理する。H.264/AVCでは、画素値は、JPEG又はMPEG-4のIフレームのように、直接変換されることはない。その結果、デコーダは、予測画素に追加される残差を取得するために、変換係数をデコードして逆変換を実行しなければならない。
【0049】
別の広く使用されているビデオコーデックは、H.265(本明細書で使用)及びMPEG-H Part 2としても知られている高効率ビデオ符号化(HEVC)である。H.264/AVCと比較して、HEVCは、同じレベルのビデオ品質で、25%から50%だけ一層よいデータ圧縮を提供し、又は同じビットレートで、実質的に向上したビデオ品質を提供する。8K UHDを含む8192×4320までの解像度をサポートし、主に8ビットAVCとは異なり、HEVCの高忠実度Main10プロファイルはほぼ全てのサポートハードウェアに組み込まれている。HEVCは4×4ないし32×32のブロックサイズの整数DCT及びDST変換を使用する。
【0050】
カラー画像は、典型的には、いくつかの「色平面」を使用して表現される。例えば、RGBカラー画像は、赤色平面、緑色平面、及び青色平面を含む。重ね合わせて混合すると、3つの平面がフルカラー画像を構成する。カラー画像を圧縮するために、前述の静止画像圧縮技術を各色平面に順に適用してよい。
【0051】
イメージングとビデオアプリケーションとは、しばしば、色平面が特定の色に対応しないカラースキームを使用する。その代わりに、1つの色平面はルミナンス情報(カラー画像の各画素の全体的な輝度)を含み、2つ以上の色平面は、ルミナンスと組み合わせたときに、各画像画素の赤、緑及び青の成分の特定のレベルを導出するために使用されてよい色(クロミナンス)情報を含む。このようなカラースキームは、人間の目がカラーよりもルミナンスに対して敏感であるので便利であり、そのため、クロミナンス平面は、ルミナンス情報よりも低い画像解像度で記憶及び/又はエンコードできる。多くのビデオ圧縮アルゴリズムにおいて、クロミナンス平面は、ルミナンス平面の水平解像度の半分と垂直解像度の半分とでエンコードされる。従って、ルミナンス平面内の16画素×16画素領域毎に、各クロミナンス平面は、1つの8画素×8画素ブロックを含む。典型的なビデオ圧縮アルゴリズムでは、「マクロブロック」は、4つの8×8のルミナンスブロックと2つの対応する8×8のクロミナンスブロックとを含むビデオフレーム内の16×16の領域である。
【0052】
ビデオ圧縮アルゴリズムと静止画像圧縮アルゴリズムとは、多くの圧縮技術を共有するが、重要な相違点は、どのように動きを処理するかである。1つの極端なアプローチは、JPEG又は類似の静止画像圧縮アルゴリズムを使用して各フレームをエンコードし、次にプレーヤーで生成するJPEGフレームをデコードすることである。JPEG及び類似の静止画像圧縮アルゴリズムは、約10:1の圧縮比で良好な品質の画像が生成できるが、高度な圧縮アルゴリズムは、30:1の高い圧縮比で同様の品質が生成できる。10:1及び30:1は相当に大きな圧縮比であるが、ビデオ圧縮アルゴリズムは約200:1までの圧縮比で良好な品質のビデオが提供できる。これは、静止画像圧縮技術と組み合わせて、動き推定及び動き補正のようなビデオ特有の圧縮技術を使用して達成される。
【0053】
現在のフレーム内の各マクロブロックに対して、モーション推定は、すでにエンコードされたフレーム(「参照フレーム」と呼ばれる)内の、密接にマッチングする領域を見つけることを試みる。現在のブロックと参照フレームから選択されたブロックとの間の空間的オフセットを「動きベクトル」と称する。エンコーダは、参照フレームから選択されたブロックと現在のブロックとの間の画素毎の差を計算し、動きベクトルとともにこの「予測誤差」を送信する。ほとんどのビデオ圧縮規格では、エンコーダがマクロブロックについて良好なマッチングを見出さない場合に、モーションベースの予測をバイパスしてよい。この場合に、マクロブロック自体は予測誤差の代わりにエンコードされる。
【0054】
参照フレームは、表示されたビデオフレームのシーケンスの中で必ずしも直前のフレームでないことに注意するものとする。むしろ、ビデオ圧縮アルゴリズムは、通常、それらが表示される順序とは異なる順序でフレームをエンコードする。エンコーダは、前方のいくつかのフレームをスキップし、将来のビデオフレームをエンコードし、その後、後方にスキップし、表示シーケンス内の次のフレームをエンコードしてよい。これは、エンコードされた将来のフレームを参照フレームとして使用して、動き推定を時間的に後方に実行できるように行われる。また、ビデオ圧縮アルゴリズムは、一般に、2つの参照フレーム、即ち、以前に表示されたフレームと、以前にエンコードされた将来のフレームの使用を可能にする。
【0055】
ビデオ圧縮アルゴリズムは、以前にエンコードされたフレームに依存することなく、静止画像符号化技術のみを使用して周期的にイントラフレームをエンコードする。圧縮ビットストリーム内のフレームが誤差(例えば、ドロップされたパケット又は他の転送誤差)によって破壊された場合に、ビデオデコーダは、再構成のための参照フレームを必要としない次のIフレームで「再始動」してよい。
【0056】
図4は、Iフレーム400と、Pフレーム402と、Bフレーム404とから構成される例示的なフレームエンコード及び表示方式を示す。上述のように、Iフレームは、静止画像と同様の方法で周期的にエンコードされ、他のフレームに依存しない。Pフレーム(予測フレーム)は、前のフレーム406によって示されるように、前に表示された参照フレームのみを使用してエンコードされる。一方、Bフレーム(双方向フレーム)は、前のフレーム408と将来のフレーム410とによって示されるように、将来及び前に表示された参照フレームの両方を使用してエンコードされる。
【0057】
図4の下部は、例示的なフレームエンコードシーケンス(下向きに進行する)及び対応する表示プレイバック順序(右向きに進行する)を示す。この例では、Pフレームのそれぞれの後に、エンコード順序で3つのBフレームが続く。一方、表示順序では、3つのBフレームの後に各Pフレームが表示され、エンコード順序と表示順序が同じでないことが示される。さらに、Pフレーム及びBフレームの発生は、一般に、取り込まれたビデオ中に存在する動きの量に依存して変化することに留意するものとする。ここで1つのPフレームと続く3つのBフレームとを使用することは、Iフレーム、Pフレーム及びBフレームがどのように実施されるかを単純化し、かつ容易に理解するためである。
【0058】
動き推定を複雑にする1つの要因は、参照フレームから現在のフレームへの物体の変位が非整数の画素である場合があることである。このような状況を取り扱うために、現代のビデオ圧縮規格は、動きベクトルが非整数値を有することを可能にし、例えば、1画素の2分の1又は4分の1の動きベクトル解像度をもたらす。部分画素変位におけるブロックマッチングの探索をサポートするために、エンコーダは、整数でない位置における参照フレームの画素値を推定するために補間を採用する。
【0059】
部分的にはプロセッサの限界のために、動き推定アルゴリズムは、限定された数の有望な候補の動きベクトル(ほとんどの場合に、約10~100ベクトル)を選択し、これらの候補ベクトルに対応する16×16領域のみ(又はH.265の場合に、32×32領域まで)を評価するために、種々の方法を使用する。1つのアプローチは、いくつかの段階で候補の動きベクトルを選択し、後に、結果的に最良の動きベクトルを選択することである。別のアプローチは、現在のマクロブロック内の動きを予測しようとするために、現在及び以前のフレーム内の周囲のマクロブロックに対して以前に選択された動きベクトルを解析する。この解析に基づいて少数の候補動きベクトルを選択し、これらのベクトルのみを評価する。
【0060】
探索領域を徹底的に走査する代わりに、少数の候補ベクトルを選択することによって、動き推定の計算上の要求を、ときには2桁以上の大きさだけ、かなり低減できる。しかし、処理負荷と画像品質又は圧縮効率との間にはトレードオフが存在する。一般に、一層多くの候補動きベクトルを探索することにより、エンコーダは、現在のフレーム内の各ブロックに一層よくマッチするブロックを参照フレーム内で見つけることができ、それにより予測誤差を低減する。予測誤差が小さいほど、画像をエンコードするのに必要なビット数は少なくなる。従って、候補ベクトルの数を増やすことは、一層多くの計算を実行するのと引き換えに、圧縮ビットレートの低減を可能にする。あるいは、圧縮されたビットレート定数を保持しながら候補ベクトルの数を増加させることにより、予測誤差を一層高い精度でエンコードすることができ、画像品質を向上させる。
【0061】
いくつかのコーデック(H.264とH.265を含む)は、16×16マクロブロックをより小さなブロック(例えば、8×8、4×8、8×4、4×4ブロックの様々な組み合わせ)に細分化し、予測誤差を低くすることを可能にする。これらの小さなブロックのそれぞれは、それ自身の動きベクトルを有してよい。このような方式について動き推定探索は、16×16ブロック全体(又は32×32ブロック)の良好な位置を見つけることから始まる。マッチングが十分に近ければ、それ以上細分化する必要はない。しかし、マッチングが不十分な場合に、アルゴリズムは、これまでに見出された最良の位置から開始し、さらに、元のブロックを8×8ブロックに分割する。各8×8ブロックに対して、アルゴリズムは、16×16サーチによって選択された位置近傍の最良の位置をサーチする。よいマッチングがどれだけ速く見つかるかに依存して、アルゴリズムは8×4、4×8などの小さいブロックを使用してプロセスを続けてよい。
【0062】
プレイバック中、ビデオデコーダは、各マクロブロックの画素を予測するために、圧縮ビットストリームにエンコードされた動きベクトルを使用してモーション補償を実行する。動きベクトルの水平成分及び垂直成分が両方とも整数値である場合に、予測されるマクロブロックは、単に、参照フレームの16画素×16画素領域のコピーである。動きベクトルのいずれかの成分が整数値でない場合に、補間が、非整数画素位置での画像を推定するために使用される。次に、実際のマクロブロック画素を再構成するために、予測誤差をデコードし、予測マクロブロックに加える。前述のように、H.264やH.265のようなコーデックの場合に、16×16(又は32×32まで)のマクロブロックは、独立した動きベクトルを持つ一層小さなセクションに分割されてよい。
【0063】
理想的には、非可逆画像及びビデオ圧縮アルゴリズムは、知覚的に重要でない情報のみを捨て、その結果、再構成された画像又はビデオシーケンスは、人間の眼にとって、元の非圧縮画像又はビデオと同一であるように見える。しかしながら、実際には、いくつかのアーチファクトは、特に、シーンがパンされるときのように、一層大きな動きを有するシーンにおいて、可視的である可能性がある。これは、エンコーダの実施が不十分であること、エンコードが特に困難なビデオコンテンツ、又はビデオシーケンス、解像度、及びフレームレートに対して低すぎる選択されたビットレートに起因して、生じる可能性がある。後者の場合は、多くのアプリケーションがビデオ品質をストレージ及び/又は帯域幅の要求の低減と相殺するので、特に一般的である。
【0064】
2種類のアーチファクト「ブロッキング」と「リンギング」が、ビデオ圧縮アプリケーションで一般的に生じる。ブロッキングアーチファクトは、圧縮アルゴリズムが各フレームを8×8ブロックに分割するという事実に起因する。各ブロックは、いくつかの小さな誤差で再構成され、ブロックのエッジにおける誤差は、しばしば、隣接するブロックのエッジにおける誤差と対照的であり、ブロック境界を可視化する。対照的に、リンギングアーチファクトは、画像特徴のエッジの周りに歪みとして現れる。リンギングアーチファクトは、高周波DCT係数を量子化する際に、エンコーダが過度に多い情報を捨てることに起因する。
【0065】
ブロッキングアーチファクト及びリンギングアーチファクトを低減するために、ビデオ圧縮アプリケーションは、しばしば、解凍後にフィルタを使用する。これらのフィルタリングステップは、それぞれ「デブロッキング」及び「デリンギング」として知られている。代わりに、デブロッキング及び/又はデリンギングを、ビデオ解凍アルゴリズムに統合してよい。このアプローチは、ときには「ループフィルタリング」と呼ばれ、将来のビデオフレームをデコードするための参照フレームとして、フィルタリングされた再構成フレームを使用する。例えば、H.264は、ときに「ループフィルタ」と称する、「ループ内」デブロッキングフィルタを含む。
【0066】
エンドツーエンドの画像データフローの例
【0067】
図5は、一実施形態による、ゲームサーバ200とデスクトップゲームクライアント202との間のエンドツーエンドの画像データフローの例を示す。さらに、関連する動作を
図6に示すフローチャート600に示す。
図5の例では、ゲームサーバ200内のサーバグラフィックスカード100-1と、デスクトップゲームクライアント202内のクライアントグラフィックスカード100-2との通信を示す。一般に、
図5に示す通信は、ゲーム画像コンテンツを生成する任意のタイプのデバイスと、クラウドゲームサーバとプレーヤーによって操作されるゲームデバイスとのような、ゲーム画像コンテンツを受信及び処理するクライアントを有する任意のタイプのデバイスとの間の通信であってよい。この例では、オーディオコンテンツは、サーバグラフィックスカード100-1とクライアントグラフィックスカード100-2との間で転送されるように描かれている。いくつかの実施では、オーディオコンテンツは、サーバ及び/又はクライアント(図示せず)上の別個のネットワークインターフェース(例えば、別個のNIC又はネットワークカード)を介して転送される。別個のネットワークインターフェースを使用するいくつかの実施では、ストリーミングセッション通信と制御通信とは、
図5に示されていない別個の通信パスを介して送信される。
【0068】
フローチャート600のブロック602に示すように、プロセスは、サーバとクライアントとの間のストリーミングセッションを確立することによって開始する。一般に、既存及び将来のストリーミングセッションの任意のタイプが使用されてよく、本明細書に開示される教示及び原理は、一般に、ストリーミングセッションの特定のタイプにアグノスティック(agnostic,非依存的)である。使用可能なストリーミングプロトコルのタイプは、限定はされないが、既存のストリーミングプロトコル、例えば、RTMP(リアルタイムメッセージングプロトコル),RTSP(リアルタイムストリーミングプロトコル)/RTP(リアルタイムトランスポートプロトコル)など、及びHTTPベースの適応プロトコル、例えば、Apple HLS(HTTPライブストリーミング),Low-Latency HLS,MPEG-DASH(Moving Picture Expert Group Dynamic Adaptive Streaming over HTTP),Low-Latency CMAF for DASH(Common Media Application Format for DASH),マイクロソフトスムーズストリーミング,Adobe HDS(HTTP Dynamic Streaming)などを含む。さらに、SRT(Secure Reliable Transport)やwebRTC(Web Real-Time Communications)などの新しい技術も使用してよい。一実施形態では、HTTPベースの適応プロトコルの1つをサポートするために、HTTP又はHTTPSストリーミングセッションが確立される。
【0069】
図5は、NIC112-1とNIC112-2との間の2つのネットワーク通信を示す。TCP/IP(Transmission Control Protocol over Internet Protocol)接続500、及びUDP/IP(Universal Datagram Protocol over IP)ストリーム502である。簡単にするために、これらは一般にTCP及びUDPと呼ばれる。TCPは信頼できる接続プロトコルであり、TCPパケット504は送信機から受信機に送信される。受信機は、受信に成功したフレームシーケンスを示すACKnowledgments(ACKs)506を送信することによって、パケットの受信を確認する。ときには、TCPパケット/フレームはドロップされるか、又はTCPパケット508によって示されるように、他の方法でエラーを伴って受信される。欠落又は誤りのパケットの検出に応答して、受信機は、欠落又は誤りのパケットを識別する情報を含むネガティブACK(NACK)510を送信する。次いで、再送されたパケット508Rによって示されるように、欠落又は誤りのパケットが再送される。さらに示されるように、TCP/IP接続500は、デスクトップゲームクライアント202からのゲーム制御入力512を受信するために使用されてよい。
【0070】
HTTPストリーミングセッションは、TCPを使用してセットアップされる。しかし、ストリーミングプロトコルによっては、ビデオ及び/又はオーディオコンテンツがUDPを使用してよい。UDPは、ライブストリーミングに広く使用され、コネクションレスであり、信頼性の低いプロトコルである。UDPは「ベストエフォート」トランスポートを使用する。これは、パケットがドロップされたり、誤りパケットが受信されたりする可能性があることを意味する。どちらの場合も、欠落又は誤りのパケットは受信機によって無視される。
図5に示すUDPパケット514のストリームは、ビデオ及び(任意に)オーディオコンテンツのパケットを図示するために使用されている。いくつかのハイブリッド媒体トランスポート方式は、TCP及びUDPトランスポートの組み合わせを採用している。
【0071】
フローチャート600に戻ると、ブロック604では、生のビデオフレームのシーケンスが、フレーム605によって示されるように、ゲームサーバ200上でのゲームソフトウェアの実行を介して、サーバグラフィックスカード100-1内のGPU102-1によって生成される。生のビデオフレームのシーケンスが生成されると、個別のフレームのコンテンツがフレームバッファ104にコピーされ、複数の個別のフレームが所定時点でフレームバッファ104に記憶される。ブロック606では、フレームは、適用可能なビデオコーデック、例えばH.264又はH.265コーデックを使用してエンコードされ、ビデオストリームを生成する。これは、H.264/H.265コーデック106-1によって実行され、このコーデックは、生のビデオフレームコンテンツをフレームバッファ104から読み込み、ビデオストリーム516によって図示されるように、エンコードされたビデオストリームを生成する。当業者には認識されるように、上述の手引書に記載されているように、生成されたビデオストリームは、デスクトップゲームクライアント202における生のビデオフレームコンテンツのデコード及びプレイバックを可能にするように順序付けられたI、P及びBフレームのシーケンスに対応する圧縮及びエンコードされたコンテンツを含む。
【0072】
図5のブロック607とオーディオストリーム生成ブロック518とで示されるように、ゲーム画像フレームの生成及びエンコードと並行して、ゲームオーディオコンテンツが、ストリーミング形式にエンコードされる。一般に、オーディオコンテンツは、ゲームサーバCPU上で実行されるゲームソフトウェアによって生成され、オーディオコンテンツのエンコードは、ソフトウェア又はハードウェアのいずれかを使用して実行されてよい。この例では、エンコードは、サーバグラフィックスカード100-1の外部で実行される。いくつかの実施形態では、サーバグラフィックスカード100-1(図示せず)上のGPU102-1又は他の回路のいずれかが、オーディオコンテンツをエンコードするために使用されてよい。
【0073】
ブロック608では、ビデオストリームコンテンツはNIC112-1によってパケット化される。任意には、オーディオストリームはさらに、NIC112-1によってパケット化されてよい。1つのアプローチでは、ビデオストリームとオーディオストリームとが別々のストリームとして(並列に)送信される。ゲームクライアントでのプレイバック機能を介してオーディオ及びビデオコンテンツを同期させるために使用されるストリームの1つの中に、情報が存在する。他のアプローチでは、ビデオコンテンツとオーディオコンテンツとが組み合わされ、単一のパケットストリームとして送信される。一般に、任意の既存又は将来のビデオ及びオーディオストリーミングパケット化方式が、使用されてよい。
【0074】
ブロック610に示されるように、AV(オーディオ及びビデオ)コンテンツは、サーバグラフィックスカード100-1からクライアントグラフィックスカード100-2へ、ネットワークを介してストリーミングされる。
図5に示すように、対応するコンテンツは、AVコンテンツを送信するために使用される1つ以上のUDPストリームを表すUDPパケット514を介して、ストリーミングされる。
【0075】
受信側の動作は、クライアントグラフィックスカード100-2によって実行される。1つ以上のUDPストリームが受信されると、オーディオ及びビデオのコンテンツは、NIC112-2内の1つ以上のUDPバッファ520内でバッファリングされ、その後、フローチャート600内のブロック612によって示されるように、デパケット化される。フローチャート600のブロック618、及び
図5のオーディオデコード及び同期ブロック522によって示されるように、オーディオ処理がGPU又はクライアントのグラフィックスカードによって処理されない実施形態では、デパケット化されたオーディオコンテンツは、分離されてホストCPUに転送され、オーディオコンテンツの処理及び出力を実行する。任意には、オーディオ処理は、クライアントグラフィックスカード100-2上の適用可能な機能(図示せず)によって実行されてよい。
【0076】
ブロック614では、ビデオ(ゲーム画像)フレームは、適用可能なビデオコーデックを使用してデコードされる。
図5の例では、これはH.264/H.265コーデック106-2によって実行される。種々のメカニズムを使用して、NIC112-2からH.264/H.265コーデック106-2上のI/Oインターフェース110(111)に、デパケット化されたエンコードされたビデオコンテンツを転送してよい。例えば、作業記述子の方式を使用してよい。これは、NICがGPU102-2上のメモリロケーションに作業記述子を書き込み、次に対応する「作業」(例えば、エンコードされたビデオデータセグメント)をGPU102-2上のロケーション、又はクライアントグラフィックスカード102-2上のグラフィックスメモリ(図示せず)に書き込む。別の実施形態では、NIC112-2が利用可能なエンコードされたビデオセグメントをデパケット化し、H.264/H.265コーデック106-2がNIC112-2からエンコードされたビデオセグメントを読み取った場合に、ドアベルをポストするか否かを問わず、「ドアベル」方式が使用されてよい。さらに、他のタイプのキューイングメカニズムも、使用されてよい。いくつかの実施形態で、円形の先入れ先出し(FIFO)バッファ又はキュー、例えば、円形のFIFOが、使用される。
【0077】
図5に示すように、H.264/H.265コーデック106-2は、ビデオストリームデコード処理524及びフレーム生成(再生)526を、デコード及び再組み立てブロック527内で実行する。
図6のブロック616及びビデオフレーム605によって示されるように、再生フレームは、GPUフレームバッファ104-2に書き込まれ、次いで、デスクトップゲームクライアント202のディスプレイに出力されてよい。例えば、GPU102-2は、ゲーム画像フレームを生成し、モニタ又は他のタイプのディスプレイ上で見るための適用可能なビデオインターフェース(例えば、HDMI,DisplayPort,USB-C)を介して、対応するビデオ信号を出力してよい。オーディオ/ビデオ出力ブロック528によって示されるように、オーディオ及びビデオのコンテンツはそれぞれ、デスクトップゲームクライアント202のためのスピーカとディスプレイとに出力される。
【0078】
一般に、GPU上に統合された、又はクライアントグラフィックスカード上のGPUに結合されたNICがTCPトラフィックを処理するために使用される場合に、受信されたTCPパケットは、1つ以上のTCPバッファ530内でバッファリングされる。以下に説明及び例示するように、NIC112-1及びNIC112-2の各々は、ハードウェアにおいて完全なネットワークスタックを実施するための機能を有する。一般に、受信したTCPパケットはパケット化され、さらに処理するためにホストCPUに転送される。転送は、PCIe書き込みトランザクションを使用して、DMA(Direct Memory Access)のような現行の手段によって行ってよい。
【0079】
タイルベースのゲーム
【0080】
多くの人気ゲームはタイルと関連タイルマップを採用している。これは、ビデオエンコード/デコード技術を使用する場合と比較すると、性能利得をもたらす可能性がある。
【0081】
図7a及び
図7bの図表700a及び700bは、それぞれ、一実施形態による、タイルベースのゲームのためのゲームサーバとゲームクライアントとで実行される操作を示す。
図7aに示すように、タイル702、フルフレーム画像は、X-Yグリッドに配置された複数のタイル702で構成される。ゲームプレイ中、ゲームサーバ上で実行されるゲームソフトウェアは、タイル生成ブロック704によって示されるように、タイルを生成する。タイルは、1つ以上のタイルバッファ705に書き込まれる。タイルエンコーダ706は、画像圧縮アルゴリズムを使用してタイルをエンコードし、エンコードされたタイル708を生成し、その後、エンコードされたタイル内の画像データは、NIC710上のパケット化ロジック712によってパケット化される。次いで、NIC710は、エンコードされたタイル714のストリームを、ゲームクライアントに配信されるネットワークに送信する。
【0082】
次に、
図7bの図表700bを参照すると、ゲームクライアントは、NIC716において、エンコードされたタイル714のストリームを受信する。NIC716は、エンコードされたタイル708を出力するためにデパケット化718を実行する。次いで、エンコードされたタイルは、タイルバッファ720(又は、そうでなければ、GPU上にあるいくらかのメモリ空間、又は、GPUにアクセス可能ないくらかのメモリ空間)に書き込まれる。タイルブロック722のデコード及び再生は、タイルバッファ720からエンコードされたタイルコンテンツを読み出し、エンコードされたタイルコンテンツをデコードして元のタイルを再生するために使用され、再生タイル702Rとして示される。
【0083】
図1cは、図表700a及び図表700bに示すサーバ側及びクライアント側の動作をサポートするように構成された、GPU102cを含むグラフィックスカード100cの一実施形態を示す。
図1及び1cの同じ番号のコンポーネント及びブロックによって示されるように、グラフィックスカード100及び100cの構成は類似する。相違点は、GPU102cが、I/Oインターフェース111を有するタイルエンコーダ及びデコーダ706を含むことである。タイルエンコーダ及びデコーダは、
図7aのタイルエンコーダ706のエンコード動作、及び
図7bのタイルブロック722をデコード及び再生するための少なくともデコード動作を実行するように構成される。一実施形態では、タイルブロック722をデコード及び再生するための完全なロジックは、タイルエンコーダ及びデコーダ706内に実施される。任意には、タイル再生ロジックの一部と、ゲームタイルの再組み立てに関連する他のロジックとは、別個のブロック(図示せず)で実施されてよい。
【0084】
複数のグラフィックスカードを搭載したクラウド型ゲームサーバ
【0085】
1つのアプローチでは、クラウドゲームサーバは、
図8のクラウドゲームサーバ800に示されるような複数のグラフィックスカードを含む。クラウドゲームサーバ800は、m個のグラフィックスカード100(グラフィックスカード100-1、100-2、100-3、100-4、100-mで示される)を含み、各々がサーバのメインボード上の各PCIeスロット(別名は拡張スロット)を占有している。サーバのメインボードは、ゲームソフトウェア810がロードされるメインメモリ808に結合された1つ以上のCPU806をさらに含む。クラウドゲームサーバ800は、さらに、それぞれのPCIeスロットにインストールされた1つ以上のネットワークアダプタカード812を含み、その各々は、NICチップ814と、PCIeインターフェース816と、イーサネットポート818及び820によって示されるような1つ以上のイーサネットポートとを含む。
【0086】
図8aのクラウドゲームサーバ800aの実施形態では、PCIeインターフェース817を含むNICチップ815がサーバのメインボードに搭載され、適用可能な相互接続構造を介してCPU806に結合される。例えば、CPU806は、PCIeインターフェース817がPCIeリンク823を介して結合されたPCIeルートポート(RP)821を含んでよい。
【0087】
図8bのクラウドゲームサーバ800bの実施形態では、CPU806と、メインメモリ808と、NICチップ815とは、PCIeインターフェース826を含むブレードサーバ824内のメインボードに搭載されている。クラウドゲームサーバ800bは、スロット/コネクタ830及び832によって示されるように、複数の拡張スロット又はコネクタを有するバックプレーン、ミッドプレーン又はベースプレーン828を含む。ブレードサーバ824及びm個のグラフィックスカード100-1、100-2、100-3、100-4、100-mの各々は、対応する拡張スロットにインストールされるか、又はバックプレーン、ミッドプレーン又はベースプレーン828上の嵌合コネクタに結合するコネクタを含む。
【0088】
クラウドゲームサーバは、ゲーム制御入力を処理し、ストリーミング接続を設定及び管理するために、1つ以上のネットワークアダプタカード812又はNIC815を使用しながら、ゲーム画像データを生成及びストリーミングするためにグラフィックスカード100を使用して、ゲームホスティング容量をスケーリングするように構成される。従って、グラフィックスカード100上の統合NICは、リアルタイム制御入力と、ストリーミング設定と、管理トラフィックとに関するI/Oトラフィックを処理する負荷を負わず、むしろ統合NICは、アウトバウンド画像データトラフィックを処理する必要があるだけである。さらに、データパスは、画像データエンコーダ(この例では、H.264/H.265コーデックであるが、他の実施形態では、タイルエンコーダ/デコーダであってよい)から直接流れるので、遅延は低減される。さらに、ゲームのオーディオコンテンツは、NIC815又はネットワークアダプタカード812を使用してストリーミングしてよい。他の実施形態では、上述のように、オーディオコンテンツはグラフィックスカード100を使用してストリーミングされる。
【0089】
図9は、一実施形態による、統合NIC900内に実施されたブロックレベルのコンポーネントを示す。NIC900は、メモリ904に結合されたNICプロセッサ902と、受信(RX)ポート908及び送信(TX)ポート910を含む1つ以上のネットワークポート906(例えば、イーサネットポート)と、ホストI/Oインターフェース912と、コーデックI/Oインターフェース914と、ネットワークスタック916を実施するための埋め込みロジックとを含む。ネットワークポート906は、開放型システム間相互接続(OSI)モデルの物理層(PHY層1)と、メディアアクセスチャネル(MAC)(層2)とを実施するための回路及びロジックを含む。
【0090】
RXポート908及びTXポート910は、受信パケット(例えば、パケットA,B,C,D)及び送信されるべきパケット(例えば、パケットQ,R,S,T)がバッファされるそれぞれのRX及びTXバッファを含む。受信されたパケットは、インバウンドパケット処理ブロック918によって処理され、上流パケットキュー920内でバッファリングされる。アウトバウンドパケットは、下流パケットキュー922内でキューイングされ、アウトバウンドパケット処理ブロック924を使用して処理される。
【0091】
フロー規則926はメモリ904に記憶され、受信パケットがどこで転送されるべきかを決定するために使用される。例えば、インバウンドビデオパケットはビデオコーデック又はタイルデコーダに転送され、一方、ゲーム制御及びセッション管理パケットはホストCPUに転送されてよい。NIC900は、NICがパケットデータをメインメモリに(ホストI/Oインターフェース912を介して)、及び/又はグラフィックスメモリに直接書き込むことを可能にする、任意であるDMAロジック928を含んでよい。
【0092】
ホストI/Oインターフェースは、入力FIFOキュー930と出力FIFOキュー932とを含む。同様に、コーデックI/Oインターフェース914は、入力FIFOキュー934と出力FIFOキュー936とを含む。GPU又はグラフィックスカード上の相手のホストI/Oと、ビデオコーデック中の相手のコーデックI/Oインターフェースとは、類似の入力及び出力FIFOキュー(図示せず)を含む。
【0093】
一実施形態では、NIC900は、OSIモデルのネットワーク層3とトランスポート層4とを実施するための埋め込みロジックを含む。例えば、ネットワーク層3は、一般に、インターネットプロトコル(IP)に使用され、トランスポート層4は、TCP及びUDPプロトコルの両方に使用される。一実施形態では、セッション層5と、プレゼンテーション層6と、アプリケーション層7とを実施するために、NIC900は、さらに埋め込まれたロジックを含む。これにより、HTTP及びHTTPSストリーミングセッションの確立、及び/又は上述の様々なメディアストリーミングプロトコルの実施など、これらの層に関連する機能を、NICは容易にすることが可能になる。これらの操作がホストCPUによって処理される実施では、セッション層5と、プレゼンテーション層6と、アプリケーション層7とを含める必要はない。
【0094】
NICプロセッサ902は、
図9の様々なブロックによって示される機能を実行するためにファームウェア命令938を実行する。ファームウェア命令は、NIC900上の任意のファームウェア記憶ユニット940に記憶されてよく、又はNICの外部のどこかに記憶されてよい。例えば、NIC900が、グラフィックスカードに使用されるGPU上の統合NICである場合に、グラフィックスカードは、ファームウェアがインストールされた記憶ユニット又はデバイスを含んでよい。他の構成、例えば、ゲームサーバにインストールされた場合に、ファームウェア命令の全部又は一部は、ブート操作中にホストからロードされてよい。
【0095】
一般に、NIC900用に示されたブロックの機能性は、何らかの形式の埋め込みロジックを使用して実現してよい。埋め込みロジックは、一般に、FPGA(Field Programmable Gate Array)を使用、又はプリプログラミング又は固定のハードウェアロジック(又は、プリプログラミング/ハードコード/プログラマブルであるロジックの組み合わせ)を使用するなどの、回路内で実施されるロジックと、1つ以上の埋め込みプロセッサ、プロセッサ要素、エンジン、マイクロコントローラなどで実行されるファームウェアとを含む。説明のために、NICプロセッサ902上でのファームウェア実行の例を
図9に示すが、これは限定的なものではない。NICプロセッサ902は、コア又はマイクロエンジンなどの複数の処理要素を含んでよい埋め込みプロセッサの形態である。
【0096】
また、NIC900は、フロー制御、暗号化、復号化などのパケット処理操作を実行するために使用される、埋め込まれた「アクセラレータ」ハードウェアなどを含んでよい。例えば、NIC900は、HTTPSトラフィックに関連して暗号化及び復号化を実行するように構成された1つ以上の暗号ブロックを含んでよい。また、NIC900は、パケットフロールックアップに関連して、ハッシュキーのマッチングを加速するためのハッシュユニットを含んでよい。
【0097】
本明細書に示される実施形態では、H.264/H.265コーデックは、例示のために示され、非限定的である。一般に、既存及び将来のビデオコーデックは、GPU上に統合され、図示されたものと同様に使用されてよい。H.264及びH.265に加えて、このようなビデオコーデックには、Versatile Video Coding(VVC)/H.266、AOMedia Video(AV1)、VP8及びVP9が含まれるが、これらに限定されない。
【0098】
クラウドゲーミング環境での使用に加えて、本明細書に記載及び図示されたGPUとグラフィックスカードとは、他のユースケースで使用されてよい。非限定的なユースケースとしては、以下が挙げられる。
-Twitch(登録商標)によるライブゲームのストリーミング。ゲームの画像はグラフィックスカードから直接送出できるので、ゲームストリームの遅延は一層短い。
-さまざまなYouTubeのライブストリームなど、他のビデオストリーミングタスクを高速化することができる。今日では、ビデオストリームはCPU又はGPUのいずれかの上にエンコードされている。これは、特定のユースケースでは、どちらにより意味があるかに依存する。GPU上でエンコードが行われる場合に、リードバック手順及びPCメモリを経由せずに、直接NICを介してエンコードされたフレームが送出できる。
-Skype(登録商標)やZoom(登録商標)などのビデオテレフォニーアプリケーション。
-GPUは、通常、CPUと比較して浮動小数点演算に対してはるかに速く、よりよいスケーラビリティを有するため、汎用アクセラレータとして使用されることが多い。科学の世界や株式市場解析の分野では、GPUで計算が行われることが多い。例えば、株式市場ソフトウェアの売買の意思決定のために、他の場所で必要とされる場合に、データは、統合されたNICを使用して、より速くネットワークに送出できる。
-GPUをアクセラレータとして使用するプラットフォームのための暗号化コインマイニング。
【0099】
本明細書に記載及び図示したPCIインターフェース、相互接続、及びプロトコルの使用に加えて、他の相互接続構造とプロトコルとを使用してよい。これらは、Compute Express Link (CXL),Cache Coherent Interconnect for Accelerators (CCIX),Open Coherent Accelerator Processor Interface (OpenCAPI),及びGen-Z相互接続を含むが、これらに限定されない。
【0100】
特定の実施を参照していくつかの実施形態を説明したが、いくつかの実施形態によれば、他の実施も可能である。さらに、図面に図示され、及び/又は本明細書に説明される要素又は他の特徴の配置及び/又は順序は、図示及び説明される特定の方法で配置する必要はない。いくつかの実施形態によれば、多くの他の構成が可能である。
【0101】
図中に示された各システムにおいて、要素はある場合に、表現された要素が異なる及び/又は類似していることを示唆するために、同一の参照番号又は異なる参照番号を有する場合がある。しかしながら、要素は、異なる実施を有し、ここに図示又は記載されたシステムのいくつか又は全てとともに動作するのに十分に柔軟であってよい。図中に示されている種々の要素は、同一であってよく、又は異なるものであってよい。いずれの1つが第1要素と呼ばれるか、いずれの1つが第2要素と呼ばれるは、任意である。
【0102】
明細書及び請求項では、用語「結合された」及び「接続された」は、それらの派生物とともに使用されてよい。これらの用語は、互いに同義語として意図されたものではないことを理解するものとする。むしろ、特定の実施形態で、「接続された」は、2つ以上の要素が互いに直接的に物理的又は電気的に接触していることを示すために使用されてよい。「結合された」は、2つ以上の要素が直接的な物理的又は電気的接触の状態にあることを意味してよい。しかし、「結合された」はまた、2つ以上の要素が互いに直接接触していないが、やはり、互いに協働又は相互作用していることを意味してよい。さらに、「通信接続された」とは、互いに直接接触してよく、又は接触しなくてよい、2つ以上の要素が互いに通信することが可能にされることを意味する。例えば、コンポーネントAがコンポーネントBに接続され、これがコンポーネントCに接続される場合に、コンポーネントAは、コンポーネントBを中間コンポーネントとして使用して、コンポーネントCに通信接続される場合がある。
【0103】
一実施形態は、本発明の実施又は例である。明細書中の「実施形態」、「一実施形態」、「ある実施形態」又は「他の実施形態」への言及は、実施形態に関連して記載された特定の特徴、構造、又は特性が、必ずしも全ての実施形態ではないが、本発明の少なくともいくつかの実施形態に含まれることを意味する。様々な外観の「一実施形態」、「1つの実施形態」、又は「ある実施形態」は、必ずしも全てが同じ実施形態を意味しているわけではない。
【0104】
本明細書に記載及び図示された全てのコンポーネント、特徴、構造、特性などが、特定の実施形態又は複数の実施形態に含まれる必要はない。明細書で1つのコンポーネント、特徴、構造又は特性が「含まれてよい」、「含まれるかもしれない」、「含むことができる」、「含み得る」と記載されている場合に、例えば、その特定のコンポーネント、特徴、構造又は特性を含めることは必須でない。明細書又は請求項が「1つの(a)」又は「1つの(an)」要素に言及する場合に、それは、要素の1つのみが存在することを意味しない。本明細書又は請求項が「追加の」要素に言及する場合に、それは、追加の要素のうちの2つ以上が存在することを排除しない。
【0105】
アルゴリズムは、ここにあり、そして一般的に、所望の結果を導く行為又は操作の矛盾のないシーケンスであると考えられる。これには物理量の物理的操作が含まれる。必須ではないが、通常、これらの量は、記憶され、移送され、組み合わされ、比較され、またそれ以外に処理されてよい電気信号又は磁気信号の形を取る。これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことは、主として一般的な用法の理由から、ときには便利であることが判明している。しかしながら、これらの用語及び類似の用語の全ては、適切な物理量に関連付けられるべきであり、これらの量に適用される単なる便利な標識付けであることを理解するものとする。
【0106】
前述の詳細な説明における「m」、「n」などの(イタリック体の)アルファベットは整数を表すために使用され、特定の文字の使用は特定の実施形態に限定されない。さらに、別々の請求項では、別々の整数を表すために同一の文字を使用することもできるし、異なる文字を使用してよい。さらに、詳細な説明における特定の文字の使用は、詳細な説明における同一の主題事項に関連する請求項では使用される文字とマッチングしてよく、又はマッチングしなくてよい。
【0107】
上述のように、本明細書における実施形態の様々な態様は、埋め込みプロセッサなどによって実行されるソフトウェア及び/又はファームウェアなどの、対応するソフトウェア及び/又はファームウェアのコンポーネントとアプリケーションとによって促進されてよい。従って、本発明の実施形態は、プロセッサ又はコア上で実行される仮想マシン内、又は、非一時的なコンピュータ可読又はマシン可読な記憶媒体の上又は中で実施又は実現される仮想マシン内で、何らかの形態のプロセッサ、プロセッサコア、又は埋め込みロジック上で実行されるソフトウェアプログラム、ソフトウェアモジュール、ファームウェア、及び/又は分散ソフトウェアとして、使用されてよく、又はこれらをサポートするために使用されてよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体は、マシン(例えば、コンピュータ)によって可読な形態で情報を記憶又は送信するための任意のメカニズムを含む。例えば、非一時的なコンピュータ可読又はマシン可読な記憶媒体は、コンピュータ又は計算機(例えば、コンピュータデバイス、電子システムなど)によってアクセス可能な形態で情報を提供する(即ち、記憶及び/又は送信する)任意のメカニズム、例えば、記録可能/非記録可能な媒体(例えば、リードオンリーメモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイスなど)などを含む。コンテンツは直接実行可能(「オブジェクト」又は「実行可能」形式)、ソースコード、又は差分コード(「デルタ」又は「パッチ」コード)であってよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体はまた、コンテンツがダウンロードできる記憶又はデータベースを含んでよい。非一時的なコンピュータ可読又はマシン可読な記憶媒体はまた、販売又は配信時に記憶されたコンテンツを有するデバイス又は製品を含んでよい。従って、記憶されたコンテンツを有するデバイスを配信すること、又は通信媒体を介してダウンロードするためのコンテンツを提供することは、ここに記載されたそのようなコンテンツを有する非一時的なコンピュータ可読又はマシン可読な記憶媒体を含む製造物品を提供することとして理解されてよい。
【0108】
本明細書に記載された種々のコンポーネントによって実行される操作及び機能は、処理要素上で実行されるソフトウェアによって、埋め込みハードウェアなど、又はハードウェアとソフトウェアとの任意の組み合わせによって実行されてよい。このようなコンポーネントは、ソフトウェアモジュール、ハードウェアモジュール、特殊目的のハードウェア(例えば、特定用途のハードウェア、ASIC、DSPなど)、埋め込みコントローラ、ハードウェア実現された回路、ハードウェアロジックなどとして実施してよい。ソフトウェアコンテンツ(例えば、データ、命令、構成情報など)は、非一時的なコンピュータ可読又はマシン可読な記憶媒体を含む製品を介して提供してよい。これは実行可能な命令を表すコンテンツを提供する。コンテンツは、結果として、本明細書に記載された種々の機能/操作を実行するコンピュータとなってよい。
【0109】
本明細書中で使用される場合に、用語「の少なくとも1つ」によって結合される項目のリストは、リストされた用語の任意の組み合わせを意味してよい。例えば、語句「A、B又はCの少なくとも1つ」は、A、又はB、又はC、又はA及びB、又はA及びC、又はB及びC、又はA、B及びCを意味してよい。
【0110】
本発明の例示的な実施形態についての上記記載は、要約書の記載も含めて、網羅的であることは意図せず、また、本発明を開示された通りの形態に限定することを意図しない。説明の目的のため、本発明の具体的な実施形態と例とがここに記載されているが、当業者が認識するように、本発明の範囲内で様々な同等の変形が可能である。
【0111】
本発明へのこれらの変更は、上述の詳細な説明を踏まえてなされてよい。以下の請求項で使用される用語は、本明細書及び図面で開示される特定の実施形態に本発明を限定すると解釈されないものとする。正しくは、本発明の範囲は全体的に、請求項の解釈についての確立された原則に従って解釈されるべき後述の請求項により、定められるものである。
【外国語明細書】