  |
はてなキーワード: レイテンシとは
Apple M1の高性能の理由について、ネットはクソみたいな解説記事に溢れている。
技術に明るいはずのはてなーですら某AVライターの間違いだらけの記事に釣られて、300ブクマ超が集まっていて嘆かわしい。
それもこれも後藤センセーがいつまでたっても解説記事を書いてくれないせいではあるが、公開情報が少なすぎるせいでまともなライターほど記事を書けないのも理解できる。
違います。
そもそもM1はDRAMをSoC化／ワンチップ化していません。M1がやっているのはSiP(System in Package、複数チップをワンパッケージに組み込む）であって、eDRAMによるSoCとは全く異なるものです。
SiPとSoCはJavaとJavascriptくらいには違います。
違います。
HBM系のメモリを採用していたらメモリ帯域は大幅に向上しますが、M1は標準DDR系メモリをワンパッケージ化しているだけなので、帯域もレイテンシも変わりません。
帯域はM1 MBPとIntel MBP(Ice Lake)でチャネル数同じ、前者はLPDDR4X-4266、後者はLPDDR4X-3733なのでメモリ帯域は14%しか向上していません。また、x86／x64最新世代のTiger Lake／ReniorはLPDDR4X-4266に対応しています。レイテンシはM1が96.8ns、Tiger Lakeが98.4nsでほぼ同等です。
Apple M1の実力を最新世代のIntel/AMD CPUと比較。M1が両者を大きく上回る結果ににあるように、SiP化によって消費電力の削減は期待できます。
違います。
SoC-DRAM間がマザーボード上で30cmあったとしても、電気信号の伝送にかかる時間は片道1nsです。仮にSiP化で物理的距離が1/100になったとしてもレイテンシ100usが98.02usになるだけで、CPUにとってDRAMが絶望的に遠いことに変わりありません。
違います。
まず、同一チップ上のCPUとGPUが同一のメモリーコントローラ／DRAMを共有するという意味では、Intelは2011年のSandy Bridge、AMDも2011年のLlanoからUMAです。一歩進んだメモリ空間の共有、コヒーレンシの確保という意味でも、AMDは2014年のKaveriから対応していて、この点においてM1に革新性はありません。
違います。
上記のSandy Bridge、Llanoの世代からかつてのノースブリッジがCPUに取り込まれたため、2011年以降のモバイルPC向け”CPU”のほぼ全てにはGPU／メモリーコントローラが含まれています。
かつてのサウスブリッジはIntelは今でもワンチップ化こそしていませんが、2013年のHaswellからMCMでワンパッケージ内には収められています。AMDは2014年のCarrizoからサウスブリッジ機能もCPUに取り込まれています。
この意味で、x86／x64のモバイルPC向け”CPU”は、かなり以前からSoCです。
違います。
NPUを活かせるアプリケーションは2020年現在では未だ限定的です。もしNPUの有無によってUXが決定的に改善されるなら、NPUありのSnapdargon 8cxを積むSurface Pro Xは同世代のSurface Pro 7よりずっと快適でなければなりませんが、そのような事実はありません。
違います。
CISC／RISCの論争は20年以上前に終わった話です。その後CISCはRISCの美点、RISCはCISCの美点を取り入れたので、現代のCPUはISAがCISCか／RISCかだけで性能が決定されることはありません。
歴史的経緯からx86／x64のデコーダが複雑になりがちなのは事実ですが、5W以下のローパワープロセッサの開発へ向かうIntelにあるように、ISAの差による消費電力増は10～20%のレンジで、さらに性能増によって相殺される分、電力効率の差としてはわずかです。
頑張って最適化してIPC上げたのと、スマホ由来の積極的なDVFS・クロックゲーティング・パワーゲーティングで浮いた消費電力を回しているからです。
気が向いたら書きます。
考えてみたらLANの有線無線の違いについては漠然としかわかっていなかったので今回を機に一度無線LANについて情報を集めてみた。５つサイトから新しい情報を得た
項目3 自分では気づかないけどP2P接続だと他人に迷惑をかけている
項目4 Switchの回線自動切替機能が機能していない。手動で操作しないと低回線に設定される
項目5 有線や無線LANはともかくポケットWiFiやテザリングは悪い
https://weekly.ascii.jp/elem/000/002/636/2636140/
ジサトラカクッチ：ゲームのプレイ中は問題なかったかもしれませんが、ゲームのログインなど、ゲームに入っていく過程でも問題は感じなかったですか。
StanSmithさん：感じなかったですね。ただひとつ気になったのは、ゲーム外でブラウザーを使ってWebサイトを見るときなどに、パパパッとサイトを切り替えて表示しようとすると、たまに止まることがありましたね。たぶん、通信が詰まった感じでしょうね。 ただ、その時には自分のiPadやスマホとかも無線LANに繋いで、負荷をかけながらだったので、そういった問題が出たのかもしれません。
StanSmithさん：ゲーム中に違和感はなかったです。これがFPSゲームなどで、一瞬を競う大会などではまだ（無線LANの利用は）ちょっと恐いかもしれませんが、カジュアルに遊ぶなら全然問題ないと思います。デスクトップPCに無線LANを拡張してゲームをプレイするというのは始めてでしたが、案外いけるんだな、という感じでした。
ジサトラカクッチ：USB接続の無線LAN子機だと、感覚的に得体のしれないボトルネックがあるように感じるんです。拡張ボードタイプなら、PCI Expressに直接通信の信号が伝達されるので、有利に感じるんですよね（笑）。今回StanSmithさんに体験してもらった結果を聞いて、僕も今後は、もしLANケーブルの引き回しが難しかったりする場合には無線LAN化しちゃうかもしれません。
StanSmithさん：今回は、同じ部屋にルーターとPCを置いた、かなり近い距離で試したので、ラグを感じることがなかったのかもしれません。ルーターとPCの間に壁などの遮蔽物があったり、1階と2階といった状況だと、また変わってくるかもしれませんね。
https://www.4gamer.net/games/032/G003289/20120328097/
千葉市内にある筆者の自宅で，クライアントPCとURoad-Home (筆増田注釈: 一体型WiMAX Wi-Fiルータの事らしい) とを有線LANでつなぎ，都内の事務所内に設置したETQWサーバーへログインし，実際にプレイしているときのものである。
千葉市内からURoad-Home(一体型WiMAX Wi-Fiルータ)を使ってETQWをプレイしているところ
https://www.youtube.com/watch?v=GY-28oVP8Bw:embed]
これといって不自然なところはないように見えるかもしれないが，pingはほぼ3桁台で推移する。つまり，10分の1秒以上の遅れが生じるわけで，プレイヤーからすると，若干のラグを感じつつプレイしている状況にある。
具体的にいうと，「引き戻され感」というか，ググッと体が引き後ろに引っ張られる感じがまれにあるほか，ビークルに乗り込むときのラグや，撃ち合いにおける不利を感じることもある。
また，まれに，操作が一時的にできなくなることもあった。 ムービー中，21～26秒くらいのところで，銃を持たない状態に切り替えたままビークルに乗っているが、このときに実は銃を持つ状態に切り替える操作を行えなかったのだ（※筆者の「プレイ中にマウスをクリックするクセ」が出ているため，武器を振る動作が繰り返されている）。これは自宅で検証したときだけに生じた問題なので，回線状況があまりよくないときには，一部のパケットがサーバーまで正常に送られなくなるのかもしれない。
ちなみに，ネットワーク回線をFTTHへ変更したのを除くと同条件でプレイした結果が下のムービーとなるが，ラグをまったく感じられないのがムービーからも分かると思う。普通にプレイできており，敵とも対等に撃ち合えている。
千葉市内からFTTH回線を使ってETQWをプレイしているところ
https://www.youtube.com/watch?v=iVVYlriRZNk:embed]
今回は都合3週間ほど試用したが，千葉市内でURoad-Homeを使ったときには， 期間中，ゲームプレイが不可能なレベルにまでpingが悪化したことが1回だけあった。また，日時による変動も大きな印象で，「プレイできなくはないが相当厳しい」ということも週に1回程度の頻度で生じている。
https://ch.nicovideo.jp/takakage/blomaga/ar372836
一見すると、pingは9msで安定しているように見えますが、下の方で突然pingの値が跳ね上がって302msを記録しています。そう、このpingの極端な跳ね上がりこそがラグの原因となるのです。
このような状況だと、もはや無線LANを諦めて有線LANを使用するという選択肢しかありません。
しかし、先ほども申し上げましたとおり、あなたがFPSなどの"遅延に対して厳しいゲーム"を、"それに適していない環境"でプレイしたいがために、周囲の人に迷惑をかけているという意識は最低限しっかりと持っていてください。
本記事は、BF3以前の旧世代のゲームタイトルでプレイする場合を想定しております。BF3では、サーバ内に通信の不安定なプレイヤーがいた場合は、巻き戻りや引っかかりなどの現象が発生していましたが、BF4などの最新世代のゲームタイトルでは、サーバ内に通信の不安定なプレイヤーがいても影響を受けることはほとんどなくなりました。
https://akiba-pc.watch.impress.co.jp/docs/sp/1169846.html
【有線】
Ping値は大体10～15前後を常にキープしており、実際のプレイでもラグなどの気になる挙動は特に感じられずにプレイできた。
【無線1】
無線LANに切り替えると、Ping値はちょっと大きめになるが、それでも10～20程度のところを行ったり来たりで、実際のゲームへの支障はやはり感じられない。
【無線3】
Ping値はさらに低下するものの、値は15～30前後を維持しており、ここまで離れてもゲームに支障がないのは予想外だった。
Nintendo Switch：「ファンタシースターオンライン2 クラウド（PSO2 クラウド）」
【有線】
Nintendo Switchはデフォルトで無線LANを使用する作りのハードウェアで、有線LANを使う場合には、サードパーティ製のLANアダプターを別途購入する必要があるため、有線LANの導入は敷居も高い。
【無線3】
何が起きたかというと、この検証をしている際、今回の一連の検証で、初めて「通信の乱れ」に遭遇したのだ。プレイしているうちに画質が乱れ、ゲーム中に「通信状態が悪いため、低画質モードに移行します」というメッセージが表示、モザイクのような画面になっていった。
その状態でしばらくプレイしていると、今度はかなり大規模のラグが発生する。ラグは1度発生すると何度も発生、具体的には、こちらの操作を受け付けない状態になったかと思ったら、その遅れを取り戻すべく、一気に時が加速するようなおかしな挙動になる…………
………これはいよいよ端末の優先順位を上げる「トラフィックコントロール」の機能が役に立つ時がきたか!? と思い、ルータの管理画面から接続されたNintendo Switchの状態を見ていると、1点おかしなことに気が付いた。周波数帯域が2.4GHzなのだ。つまりIEEE 802.11nでの接続になってしまっていたのである。
Nintendo Switchだけが悪いわけではないと思うが、何度再接続などを試みても周波数帯が切り替えられないため、仕方ないので、周波数帯毎にSSIDを明確に分けて設定することで、無事、Nintendo Switchでも5GHz帯に接続することができた。
1度5GHz帯に繋がりさえすれば、あとは先述のようなスムースな通信状態が実現する。ゲーム機にかかわらず「通信がおかしい？」と思ったら、こうした対策をしてみることをおススメする。
https://xn--pc-mh4aj6msdqgtc.com/guide/internet-connection
◇有線LAN フレッツの光回線。プロバイダはオープンサーキット。最大100Mbps。「モデム – ケーブル – ルーター – ケーブル – ゲーミングPC」というネットワーク構成。
◇無線LAN 有線LANとほぼ同じ。無線子機をゲーミングPCのUSB端子に挿して、無線LANルーターと接続。IEEE802.11ac、5GHz帯。ルーターとゲーミングPCの距離は約3m。障害物は机の足（木製の壁で約3cmの厚さ）。
◇ポケットWiFi 何年も前に契約したE-Mobile（現ワイモバイル）のデータ端末。最大速度はおそらく40Mbps。ゲーミングPCのUSB端子に接続して使用。
有線LAN
パケットロス 0
コマンドプロンプトでは「www.google.co.jp」に対し、pingを10回送信しました。ping6で綺麗に揃いました。
パケットロス 0
パケットロス 0
あくまでも一例でしかありませんが、今回のテスト結果を見るとポケットWiFiやテザリングはやめておいたほうが良さそうです。平均ping28という数値だけ見ると低いものの、実際のオンラインゲームでは有線LANでping50くらいになります。となるとポケットWiFiならping70以上になると予測できます。MMORPGならまだしもFPSをプレイするなら、私はポケットWiFiだと不安です。
以上
というか、
ＡＳＩＣやＬＳＩを作ったことある人なら、当たり前すぎることなんだけど、
語弊があるどころかニュアンスが逆なんだよね。
開発者にとって楽になるどころか難しい方向に行くんだよね。
「フロントエンドのみArm命令に置き換えた形」という文言は、
「中身は前のまんまw」「命令セット入れ替えただけなんすわw」「命令デコーダをarm化したSparc64です。」という意味ではなくむしろ逆で、マイクロアーキテクチャが共通になるように、DDRとHBMの差分を見えなくしたりレイテンシを調整したりetc...して、ほとんど全部Verilogを書き直したってことなんだよね。
で、なぜそこまでしてマイクロアーキテクチャを共通化するかっていうと
LSIチップの検証って組み合わせパターンが天文学的数字すぎて分岐網羅とか全然できないんだよね。
ソフトウェア的な分岐網羅に換算したら0.1%となんじゃないかな。
そこでマイクロアーキテクチャを共通化してると、過去チップのLSIテストケースを流用できるわけなんだな。
エッジコンピューティングを使って低遅延を提供、って説明されてるけど、
エッジコンピューティングって事は結局のところ基地局から物理的に近い距離にサーバ配置するって事なわけで
逆にデータセンターなんかを利用しようとするなら基地局によっては近場に無い場合も多いわけで
低遅延が基地局によって使えなくなったりするよね。
どの基地局からも最低限のレイテンシを保証するところにDC建てまくるわけにもいかんだろうし。
MNOがakamaiやfastlyのようなCDNの真似事する感じになるのかな？
まさにレイテンシが短くなることのメリットとして挙げられているわけだが＞リモートディスプレイ
ただ、現状googleのstadiaでも成功しているとは言いづらいって部分はある。
何が原因なのかはようわからんけど。
「アプリケーションに合わせてプロバイダを選ぶ」というのが5G世界からのパラダイムになるはず（自動車用の5Gネットワークはナビ情報以外のパケットを扱わない）だから、想定レイテンシは1msのまま、バックボーンも無限想定で別に問題ないぞ。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 45 | 7236 | 160.8 | 46 |
| 01 | 32 | 8704 | 272.0 | 46.5 |
| 02 | 30 | 13023 | 434.1 | 61.5 |
| 03 | 29 | 1729 | 59.6 | 37 |
| 04 | 37 | 2721 | 73.5 | 41 |
| 05 | 10 | 1748 | 174.8 | 41 |
| 06 | 24 | 2113 | 88.0 | 44.5 |
| 07 | 35 | 3886 | 111.0 | 63 |
| 08 | 45 | 3247 | 72.2 | 42 |
| 09 | 118 | 8626 | 73.1 | 31 |
| 10 | 158 | 11439 | 72.4 | 34 |
| 11 | 190 | 13959 | 73.5 | 28.5 |
| 12 | 246 | 16915 | 68.8 | 33 |
| 13 | 120 | 7219 | 60.2 | 33 |
| 14 | 122 | 8955 | 73.4 | 35 |
| 15 | 213 | 18786 | 88.2 | 38 |
| 16 | 110 | 8361 | 76.0 | 36 |
| 17 | 162 | 16078 | 99.2 | 37.5 |
| 18 | 177 | 9532 | 53.9 | 31 |
| 19 | 134 | 12927 | 96.5 | 33 |
| 20 | 112 | 6029 | 53.8 | 27.5 |
| 21 | 141 | 12771 | 90.6 | 43 |
| 22 | 134 | 14711 | 109.8 | 39.5 |
| 23 | 132 | 11043 | 83.7 | 35 |
| 1日 | 2556 | 221758 | 86.8 | 35 |
コクピット(8), メンディー(4), 大阪芸大(4), 自罰(12), 猛虎(3), Vive(4), 芸大(8), 加速度(12), 安楽椅子(3), 遠心力(3), ぽよ(7), 日本大学(4), 週刊ポスト(3), レイテンシ(3), キッズ(9), 回転(14), G(22), ペイ(7), 学級(6), 飢え(6), 散らす(6), VR(15), エゴ(6), 田舎者(5), 居酒屋(10), 加速(9), チーズ(8), 会計(7), 女子高生(11), 夏休み(9), バイク(6), 強要(14), 指(15), エンジニア(20), お気持ち(22), IT(17), ワイ(83), アウト(14), 聞け(13), 増税(11), ウソ(9)
■結局のところ、みんなは何Pay使ってるの？ /20190902065447(14), ■ /20190901193143(14), ■ /20190902140814(14), ■ガンダムのコックピットで /20190831165412(13), ■京都造形芸術大学が京都芸術大学と改称する気だそう /20190902125312(12), ■ /20190901124112(12), ■もうダメだよバーチャルyoutuber /20190902115544(8), ■女性漫画家の描く漫画 /20190902152349(8), ■デレステのアイドルに恋愛感情を抱かれるのが苦手(一部のアイドルを /20190604160036(8), ■バカを見て度し難いって言いたいよな /20190902090947(8), ■エンジニアって結局英語どれくらいできればいいの？ /20190901010633(7), ■小説や漫画の、期限が決まってるときの台詞を教えてくれ /20190902101647(6), ■お前ら金玉どうやって洗ってる？ /20190901214348(6), ■LINE、やってないんだよね /20190902013444(6), ■男の娘風俗で掘られて射精して来ました。 /20190902021340(6), ■ /20190902145804(6), ■ /20190902113047(5), ■料理研究家とDQN居酒屋の件 /20190902114014(5), ■10000時間で何でもプロになれる、っていうけど。 /20190902092534(5), ■anond：20190901222614 /20190902084643(5), ■チーズおかきを高校球児にたとえると /20190902010604(5), ■あなたにとって信頼できるメディアとは？ /20190902142155(5), ■ /20190902234509(5), ■増税まで1ヵ月切っちゃったぞ！💸 /20190902150940(5), ■はてブだけ時間が止まってるよな /20190901144715(5), ■モビルスーツで何が好きだい？ /20190902162547(5), ■ウイグル弾圧の告発漫画 /20190902171758(5), ■ /20190902182152(5), ■ディストピア飯屋って儲かるかな /20190902104255(5)
6568963(2208)
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
