2013/10/10

AMD Mantle と OpenGL

今日も駄文を書こうかと……。ValveのSteamOS(Steam Machines)は、現在の情報では「NVIDIA」がパートナーとなって、OpenGLドライバーの改良を行なっているらしいですね。じゃあ、もう一つの雄である「AMD」はどうなのでしょう？

今の所、NVIDIAのように公式ウェブサイトでSteamOSについて言及しているアナウンスは無い（多分）ですが、代わりに「Mantle」という低レベルAPIを発表しました。これはWindowsOSで汎用グラフィックAPIとして使われている「Direct3D」と、ある意味で競合するAPIで、一応「クロスプラットフォーム」なAPIであるとアナウンスされています。と言っても、基本的にはAMDのGPU、それも最新の「GCN」アーキテクチャのみに対応しているという、極めて効果範囲が狭いAPIなので汎用性が売りであるDirect3DやOpenGLとは毛並みが違う訳ですけど。

似たようなAPIとして、90年台後半に3DfxのGPU「Voodoo」向けに開発した「Glide」というものが有り、実際性能も当時のDirect3Dと比べると良かったので一時期はかなり勢力があったAPIだったみたいですね。当時はあまり覚えていませんが、確かにGlideというのは聞いた事あります。その後は紆余曲折があって、結局はGlideどころか3DfxがNVIDIAに吸収される形で消滅してしまったみたいですが……。

今回のMantleも技術的にはGlideと似たようなモノですが、AMDに言わせると政治的？　背景が全く違うので勝機アリと判断したのかもしれませんね。確かに3Dfxと違い、現在のAMDは主要据え置きゲーム機（PS4、XBone、Wii U）全てのGPUを供給していますし、PCに置いても永遠のライバル、NVIDIAと二分する主要GPUメーカーですしね。

特に据え置きゲーム機（と言っても、WiiUはGPUがGCN世代ではないですが）のPS4とXBoneをAPUで制したのは大きいですね。PC(Windows)のみなら、ゲームデベロッパーは手間の掛かるAMD専用API、しかも最新のGCNにしか対応していない低レベルAPIなんて、手間が掛かる割にはリターンが少ないので対応する事に二の足を踏むでしょうが、今回は主要ゲーム機2つに採用されているので、作業効率としては格段に上がる可能性がありますし。まぁMantleがベースにしている技術がPS4由来なのかXBone由来なのか判りませんけど。PS4はGNMという低レベルAPIが確認されていますが、XBoneはDirect3D以外に低レベルAPIが用意されているのか一般には漏れてきてませんしね。一説にはMantleはXBoneの低レベルAPIがベースだという噂もありますけど……。

もし、このMantleが次世代据え置きゲーム機の低レベルAPIと何らかの互換性があるAPIだったら、Windowsはもとより、LinuxというかSteamOSにAAAタイトルの移植が今まで以上に簡単になる「可能性」はあります。まぁAMDのGCNに対応している「Steam Machine」限定ですけど……。

特にAMDの次世代APU「Kaveri」は、汎用PC向けでありながら（性能は別として）PS4と技術共有している（hUMAやGDDR5？対応）ので、個人的には最も「Steam Machines」に相応しいアーキテクチャかなと思っているんですよね。NVIDIAとしては、据え置きゲーム機をAMDに全てとられてしまい、一応の保険としてSteamOSに協力的なのもあるでしょうし。今はPCゲーム技術のリファレンス的な立場にあるNVIDIAですが、今回のAMDの躍進で一気に立場を逆転されかねないですからね。隙を見せると、このMantleみたいに攻められますし。

そんな感じで、AMDとしてはMantleで歩みが止まりがちな「DirectX」の揺さぶりを掛けている訳ですが、SteamOS（Linux）に対してはどうなんでしょうか？　今の所、明確な答えは出していませんが、技術的には可能でしょう。少なくともMacよりは遥かに導入しやすいでしょうし。問題は「需要」があるかって事なんですけど……。

毎度の事ながら、カーマック先生がMantleのパフォーマンスについてツイートしてくれているので引用します。

確かにDirect3Dに比べるとパフォーマンスは上がるけど、NVIDIAのOpenGL拡張を上手く使えば、似たようなパフォーマンスが得られるみたいですね。OpenGLは各ベンダーが独自に拡張する事が許されているらしいですね。まぁあまり多用すると、汎用性が失われるので本末転倒な気がしますけど。

面白いのは、AMDもMantleベースの技術をOpenGL拡張でOpenGL上に持ち込もうとしているらしい事なんですよね。しかも、この移植作業の為にOpenGLの専門家を招いているようですし。まぁこの為というか、もしかしたらPS4絡みなのかもしれませんが……。





勉強不足で知りませんでしたが、Graham Sellers氏は「OpenGL SuperBible」というOpenGLの赤本の著者という専門家で、今はAMDでRADEONのOpenGLの最適化を担当しているらしいです。氏のツイートで気になるモノをもう一つ引用。



どうやらAMDのOpenGL？ドライバーはWindowsとLinux版で90%くらいは共通化されてるみたいですね。Mantleドライバーがどうなるのか判りませんが、おそらくAMD推奨のゲーム開発環境はMantleからフィードバックされたOpenGL拡張がGCN世代は主流になると思う（Direct3Dの独自拡張が認められていなければ）ので、そのドライバーがWindowsとLinuxで共通化されているというのはLinux(SteamOS)には朗報ですね:-)

Mantleが軌道に乗れば、いずれはLinux版ドライバーも出てきそうですが、その前段階としてMantleベースのOpenGL拡張が追加されたLinux版ドライバーが確実にLinux(SteamOS)にも導入されると思います。

#Amazon
OpenGL SuperBible: Comprehensive Tutorial and Reference (6th Edition)
OpenGL SuperBible: Comprehensive Tutorial and Reference (6th Edition)
Graham Sellers, Richard S Wright, Nicholas Haemel
Addison-Wesley Professional ( 2013-07-31 )
ISBN: 9780321902948

#外部リンク
AMD Aims To Give OpenGL A Big Boost, “API Won’t Be The Bottleneck” | DSOGaming | The Dark Side Of Gaming
http://www.dsogaming.com/news/amd-aims-to-give-opengl-a-big-boost-api-wont-be-the-bottleneck/

Graham Sellers | LinkedIn
http://www.linkedin.com/in/grahamsellers

3dfx - Wikipedia
http://ja.wikipedia.org/wiki/3dfx#Glide
Posted by on 2 件のコメント:

2013/10/07

2K Games が SteamOS に参入？

10月だと云うのに、この暑さ。まるで夏みたいな気温ですね。さて、今日もSteamOSについての話題を書こうかと。まぁ既にタイトルに書いてあるんですけど。まだ正式な発表という訳ではないのですが有名なゲーム会社である「2K Games」が、LinuxというかSteamOSにいくつかの既存タイトルを対応させるのではないかという噂が、まことしやかに囁かれ始めています。いくつか例を挙げると、以下のようなタイトルらしいです。
NBA 2K14
NBA 2K13
Sid Meier's Civilization V
XCOM: Enemy Within
Borderlands 2
まさかのCivilization V:-)　Borderlands 2も人気タイトルですしね。まぁあくまで噂ですが、何故か米国のAmazon.comのゲーム・カテゴリーで「Linux」という項目があり、そこにこれらのゲームがカテゴライズされている状態だそうです。何かの間違いかもしれませんが、Civilization VやBorderlands 2は、Windows専用ではなく、Macにも対応しているゲームなので、他のWindows専用タイトルよりは、信憑性が高いと思います。

また関係あるかは判りませんが、つい最近、同じく2K Gamesの「BioShock 2」が「Games for Windows Live」を除外し、代わりにコントローラー対応やSteam実績やBig PictureモードなどSteamworksの各機能を利用できるようしたバージョンをSteamでリリースしたらしいですし、この流れは見逃せないかと個人的には思います。

こうなると、名作ゲームである「BioShock」シリーズもSteamOSに対応して欲しいところですね。最新作である「BioShock Infinite」も、Mac対応ですし、可能性は高いかなと思いたいところです:-)　ここまで書いておいてなんですが、あくまで「噂」です。実際にどうなるのかは全然判らないので、誤解なきようお願いします。

ちなみに、今Steamで2K Gamesのセールやってるんですよね。今日はちょうど「Sid Meier's Civilization V」が75%オフです。ただ、Mac版だと日本語字幕カットされてるんですよねぇ……。もしあるとしたら、Mac版からの移植かなと思うので、そうなるとSteamOS版も日本語字幕無いのかな……。

#外部リンク
Amazon.com: Linux Games: Video Games
http://www.amazon.com/s/ref=nb_sb_noss?url=node%3D290573&field-keywords=&rh=n%3A290573

Steam で 75% オフ:Sid Meier's Civilization® V
http://store.steampowered.com/app/8930/

2K Games - Wikipedia
http://ja.wikipedia.org/wiki/2K_Games

GfWLを除外しSteamworksを導入した『BioShock 2』のリリースが開始、全DLCを収録へ | Game*Spark - 国内・海外ゲーム情報サイト
http://www.gamespark.jp/article/2013/10/04/43869.html
Posted by on 0 件のコメント:

Steam Machines のスペック公開

先週、怒涛のように発表されたValveの3つのアナウンスですが、結局3つ目の話題は「Steam Controller」でしたね。Valveが何らかのコントローラーを開発していたのは既に漏れ伝わっていたので、特に驚きはしなかったのですが、まさかあのようなキテレツなコントローラーだとは思いませんでしたね:-)

冷静に考えれば、Steamで既にデフォルトのコントローラーとなっている「XBOX360コントローラー」が比較点安価で入手出来ますし、今更Valveが似たような安価な代替品を用意するまでもなく、ロジクール（ロジテック）がXbox360コントローラー互換の製品を発売していますからね。どうしてもというなら、このコントローラー「F710 Wireless Gamepad」「F310 Gamepad」を推奨品に認定すれば済む話ですし。コントローラーについては、また後日妄想を書こうかなと思っているので、今回は省略しときます。

今日の話題は、Steam Machines のスペックについてです。あくまで「プロトタイプ」ですが、ValveのSteam Machinesのスペックが公開されたようです。一応以下のような感じみたいですね。
CPU：Core i7-4770、或いはCore i5-4570、Core i3の何れかを搭載
GPU：Nvidia Titan、或いはGTX780、GTX760、GTX660の何れかを搭載
メモリ：16GB DDR3-1600（CPU）、3GB DDR5 (GPU)
ストレージ：1TB / 8GBのハイブリッドSSHD
電源：450W/80Plus Goldの電源を内部に搭載
サイズ：およそ12インチx12.4インチx2.9インチ（約30.5cm x 31.5cm x 7.4cm）
うーん、事前の予想と合ってるような合ってないような:-(　この前のリーク？　であった「AMD」製CPUというのはガセだったみたいですね。まぁ流石にアレはどうかなって思ってましたけど。ただ、インテル製のCPUになるにしても上位クラスのi7、i5、i3ってのは少々驚きましたね。もしあるとしたら、比較的安価な「Pentium Dual-Core」辺りがギリギリかなって思っていたので……。

それより驚いたのがGPUですね。まさか「Titan」まで載せてくるとは……。ご存じない方も多いと思いますが、ある意味NVIDIAの最上位機種で小売価格が「999ドル」という驚きのお値段です。他のGPUもGTX780、GTX760、GTX660とハイからミドルと言った感じで「リビングルーム」向けにしては、比較的重量級なGPUですね……。

まぁ例の「ホームストリーミング」機能がNVIDIAの技術「NVENC」を使用したモノならば、対応GPUもそれなり（650以上？）のクラスが必要らしいので、GTX660辺りというのは現実的なのかなとは思いますが……。それでも、小売価格で2万円はしますし、そう安価なGPUじゃないと思いますけど……。メモリ16GBと1TB / 8GBのハイブリッドSSHDも小売価格なら結構しますしね。電源が450Wというのも、80PlusのGoldとはいえ、TitanやGTX780クラスでは厳しい気がしますし。

比較対象として合っているのか判りませんが、一説によるとPS4のAPUのコストは「60-100ドル」らしいです。まぁ本当に噂レベルではありますが……。ちなみに「PS3はCellが89ドルでRSXが129ドル、360がXCPUが105ドルでXGPUが140ドル」なんて話もありますが、こちらも真偽は不明です。とはいえ、同じ「x86」アーキテクチャでも、AMD一社でCPUとGPUをワンチップ化で用意出来る「APU」と、ただの汎用品の寄せ集め？　であるSteam Machinesでは製造コストに雲泥の差があるのは間違い無いと思います。

何となくNVIDIAは積極的な印象を受けますが、インテルに関してはあんまり積極的でも無さそう？　これがARMと競合しているモバイル向けのCPUなら、もう少し愛想も良いのでしょうが、普通に売れているデスクトップ向けだと、ちょっと厳しそうですしね……。あくまで私見ではありますが。

何か本当に汎用品で作ったValve印の「ゲーミングPC」って感じですが、一応ケースは独自仕様らしい？　後でケースのデザインをCADファイルで公開するって書いてありますね。というか、ここまでValveのアナウンスを読まないで適当に書いてきたのですが、流し読みしてみた感じ、今回は「ハイエンドユーザー」向けに「汎用品」を使って「リビングルーム」に置いても違和感の無いような「小型のデザイン」を模索する為のプロトタイプらしいです。

なので、敢えて一般人が入手し易い汎用品のPCパーツを使っているみたいですね。後で自分でパーツ（マザーボードさえ）を変更出来る事を想定しているらしいです。今回の目的は、そういった汎用品で作った「ゴツい」PCを、如何にリビングルームに置いても問題の無いレベルでコンパクトに出来るかというのを念頭に置いた筐体作りが課題みたい？　だから敢えて450Wの電源にしたんですかね？　まぁそれでもTitanは厳しい気がしますが:-(

私の予想では、今回のような「上限」を決める事より、最低限の「下限」を決めるのが「Steam Machines」の役割だと思っていたので、今回のプロトタイプは少し残念な感じですね……。まぁ今回のプロトタイプは、あくまでSteam Machinesの一部に過ぎないらしいので、私が予想したような目的のSteam Machinesも、いずれは公開されるのかもしれませんが……。とにかく詳細を待ちたいと思います。

#外部リンク
Steam コミュニティ :: グループ :: Steam Universe
http://steamcommunity.com/groups/steamuniverse#announcements/detail/2145128928746175450

[Phoronix] Steam Machines Prototypes: Intel CPU, NVIDIA GPU
http://www.phoronix.com/scan.php?page=news_item&px=MTQ3NzQ

Valveがベータ配布を予定している「Steam Machine」プロトタイプのスペックを発表 « doope! 国内外のゲーム情報総合サイト
http://doope.jp/2013/1029982.html

Steam Controller
http://store.steampowered.com/livingroom/SteamController/

Valveが斬新なデザインのコントローラ「Steam Controller」を発表。2つのトラックパッドとタッチスクリーンで，あらゆるジャンルのゲーム操作を実現 - 4Gamer.net
http://www.4gamer.net/games/038/G003821/20130928002/

F310 Gamepad
http://gaming.logicool.co.jp/ja-jp/product/f310-gamepad

The AMD's Cafe:PS4とXbox One向けSoCは$60～100，Xbox Oneだけで30億ドル以上に値？ - livedoor Blog（ブログ）
http://blog.livedoor.jp/amd646464/archives/52357736.html

■■速報＠保管庫(Alt)■■ : [PS4/Xone]次世代機のAPU一個あたりのコストは60-100ドルで、PS3/360立ち上げ時よりは大幅に安く上がる？
http://blog.hokanko-alt.com/archives/28723681.html
Posted by on 0 件のコメント:

2013/09/28

SteamOS のおさらい

さて今日もValveの発表がある訳ですが、こちらも負けずに妄想全開でその時を待ちたいと思います。と言っても、もう大した話題もないんですけど。取り敢えず今までの妄想を纏めてみますかね。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定？)
推奨ライブラリー = Valve Runtime（Valveが推奨するオープンソースなゲーム開発ライブラリー群？）
ウィンドウシステム = X.Org Server(Valve Runtimeに含まれているSDLをフロントエンドとして使用？　バックエンド「MirかWaylandかX.Orgか」は開発者が意識する必要性は無い？)
これがこの前までの妄想です。で、今出ている妄想を足すとこんな感じですかね。
ホームストリーミング = NVIDIAのストリーミング技術がベース？　将来的にはNVIDIA GRIDによるクラウドゲームサービスも導入？　もしかしたら、「LittleFoot」ととして「NVIDIA SHEILD」や「Tegra Note」とのストリーミングもあり？
音楽、テレビ、映画 = デフォルトで「Spotify」に対応？　もしかしたら「Netflix」も？
「Steam Machines」はこんな感じでしょうか？
Steam Machines = x86アーキテクチャかつ汎用のPCパーツで構成されるゲーム機？
リファレンス機 = Valve自らが制作する試作機で、パーツ構成はAMDのCPUにNVIDIAのGPU？　WiFiも必須？　もしかしたら「認証制度」が設けられるかもしれない？　性能的にはそれ程でも無さそう？
取り敢えず、こんなところですかね？　OSのベースが「Ubuntu 12.04」なのは、かなり信憑性が高いと思います。何故かというと、Valve公式サイトに、Steam Machines向けっぽいリポジトリが公開されているからです:-)　まぁこれがSteam Machines用なのかは確認された訳ではないのですけど……。

それによると、ベースのOSは「Ubuntu 12.04.2」らしいです。既に12.04.3が出てますが、こちらはまだ「.2」みたいですね。それとNVIDIAのプロプライエタリドライバーとツール群ですね。あと「bcmwl-kernel-source」というパッケージも追加されていますが、これの説明を読むと以下のようなパッケージらしいです。
This package contains Broadcom 802.11 Linux STA wireless driver for use with Broadcom's BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based hardware.
どうやら「Broadcom」製のWiFiが導入されるみたい？　やっぱり、WiFi必須ってのは本当なのかもしれませんね。面白い所では「valve-wallpapers」のもありますね。まぁ普通に壁紙でしたが:-)

上記の情報で少し臭いかなって思うのはCPUがAMD製って所なんですが、リークによると単にコストの関係らしいので、有り得るって言えばありうるのかも……。本当ならNVIDIAがCPUも含めたワンストップ・ソリューションを提供出来ればベストだったのでしょうが、残念ながらNVIDIAは単独でのx86コアを手配出来ませんからね。その為にも「Project Denver」という高性能64bit ARMコアをGPUと統合する計画を急ピッチで進めている最中なんでしょうが、噂では2015年に実戦投入されるらしいので、あと2年は掛かるますし……。

自分の妄想では、NVIDIAとしては、このARM機でSteam Machinesを展開して欲しいという狙いもあって参加しているのでしょうね。x86からARMという流れは最近のトレンドですし、ValveもSDL2.0やその他のオープンソースなクロスプラットフォームライブラリーを多用している所を見ると、実性能より抽象度を優先して移植しやすい環境を推奨してきそうですし。それに将来的にはNVIDIA GRIDのようなクラウドゲームサービスでヘビィなゲームは互換性を取りそうな気もしますし。そうなると最悪、Steam Machinesは「ビューワー」のようなスペックでも良い訳ですし。まぁ実際にストリーミングでゲームをするとなると、各家庭にそこそこの回線が無いといけない訳でまだまだ時間は掛かりそうですが……。

それとNVIDIAのOpenGL対応ですが、カーマック先生が面白いリンクをリツイートしていました。任天堂のGCとWiiのエミュレーターである「Dolphin」の開発チームが現状の各社OpenGL3.0対応のドライバーをエミュレーターを用いてテストしたらしいのですが、数ある中でNVIDIAのLinux用プロプライエタリドライバーが最高評価の「Excellent」らしいです:-)　

次いで「Mesa」が「Good」。MesaというのはOpenGLのオープンソースな実装で、基本的にIntelの公式ドライバー、AMDとNVIDIAのコミュニティによるドライバーの事だと思います。唯一Intelは公式でオープンソース実装なので、コミュニティと分化してないのです。少し意外でしたが「Nouveau」（NVIDIAのGPUドライバーのオープンソース実装）の評価が高いですね。Nouveauは、今まで完全なリバースエンジニアリングで実装するという、ある意味、修行僧の荒行状態で困難が予想されているのですけど……。この前NVIDIAが方針を改めて一部のドキュメントを公開するらしいので、今後は多少、楽になりそうですが……。

そして「Mediocre（平凡、二流……）」の評価なのがAMDのLinux向けプロプライエタリ・ドライバーですね。まぁ何となく世間の評価通りですが……。ここで話が終わればまだ良かったのですが、世の中には更に悲惨な事があるんですね。二流以下の「Bad」がARM自らのGPU「Mali」向けのプロプライエタリ・ドライバーで、更に低い「Horrible」がQualcommの「Adreno」のプロプライエタリ・ドライバーらしいです……。もうひとつ「PowerVR」というメジャーなGPUがあるのですが、こちらは「Unknown」らしいです。OpenGL ES 3.0向けのドライバーがまだ無いのがその理由らしいですが。

こうやってみると、如何に現状のARM向けGPUドライバーが悲惨なのかがよく分かりますね:-(　恐ろしい事に各モバイルOS（FirefoxOS、Sailfish OS等々）がAndroid向けのドライバーを流用するらしいですね……。そして「Ubuntu」も「Mir」でその輪の中に加わろうとしているようです:-(　私の知識が中途半端なので、もしかしたら間違っているのかもしれませんけど。

なんて余計な事を書いてたら、あと20分でValveの3つ目の発表です。まぁイイ暇つぶしにはなったかな:-)　一体何の発表なんですかねぇ。噂じゃSource2エンジンの「Left4Dead3」じゃないかって話ですが、もしかしたら独自コントローラーかも。それともLittleFoot？

#外部リンク
http://repo.steampowered.com/hometest/dists/stable/steam/binary-amd64/Packages
http://repo.steampowered.com/hometest/dists/stable/steam/binary-amd64/Packages

Official Dolphin Emulator Website - Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame
https://ja.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/?cr=ja
Posted by on 0 件のコメント:

2013/09/27

Steam Machines のパートナーは、やっぱりNVIDIA？

昨日のValveの発表が、思ったより大人しい内容だったので少し残念でしたね。もう少し突っ込んだ発表があるのかと思っていたのですが……。一応、NVIDIAからもSteamOSに関する発表があったので、NVIDIAがValveに協力しているのは間違いないみたいですね。

あと昨日書いたAMDがLinuxに関して何か発表するかもって話ですが、GCN向けのDirectXにもOpenGLにも依らないPC向けの低レベルAPIの発表でしたね。多分ですが、PS4の開発からフィードバックされたAPIですかね？　スライドによると、一応は「クロスプラットフォーム」なAPIらしいですが、何処にもLinux対応とは書いてませんでした……。11月に詳細を発表するとか何とか書いてあったきがしますが……。

カーマック先生のツイートによると、もしもAMDがこの新しいAPI「Mantle」をSteamOSにも移植したら、より多くのAAAタイトルがSteamOS向けに移植されるかもしれないって書いていましたが、このMantleをAMDと共同開発したバトルフィールド・シリーズで有名なDICEは、ある意味Steamのライバルである「Origine」を運営しているエレクトロニック・アーツの関連会社ですからねぇ……。それにエレクトロニック・アーツ系のゲームはLinuxにほとんど？　移植された事が無いですし……。

それに、個人的にはSteamOS向けのゲームは、SDLのように抽象化の度合いが強いライブラリーが推奨されるでしょうし、ある意味、逆路線の低レベルAPIであるMantleは、今後の展開（例えばARM機への移植等）を考えると、Valveとしては、あまり推奨したく無いのかなって思いますし。

私個人としては、PS4のやり方がある意味理想的だと思っているので、もし据え置きゲーム機として考えるなら、やはりAMDのAPU一機種に限定して、汎用APIのOpenGLと低レベルAPIのMantleの二本立てにするのがベストかなとは思うのですけどね……。

完全にネタレベルの話ですが、某所に投稿された匿名のValve社員を名乗る書き込みが話題になっていました。それによると、やはりパートナーはNVIDIAらしいです。勿論、AMDが排除されているという訳ではないですが、一緒になって開発しているのはNVIDIA一社だけみたい？

その人によると、Linuxは単純にWindowsより速いらしいです。平均して約25%くらい速いらしいです。次にLinuxは自分達でチューニング出来るのが良いらしいです。GPU関連だけじゃなくて、カーネル部分にまで手を入れる事が出来るのが素晴らしいそうです。しかもMSやアップルにお伺いを立てなくてもいいいので、1日で劇的にゲームを改善させる事が可能なのが特に気に入っているそうです。最後にWindowsはMSがゲームに対して、あんまりヤル気が無いのが嫌だそうです（えっ！

またSteamOSについてですが、NVIDIAのGPUは3世代前まで、AMDは2世代前までがサポート対象らしいです。ただし、Valve自らが制作する「リファレンス機」は、NVIDIAのGPUとAMDの「CPU」を載せたモノになるだろうとの事です。GPUは解るけど、なんでCPUがAMD？　って思いましたが、単純に「お金」の問題らしいです。というか、INTELはSteamOSにあんまり興味が無いらしいです……。それに何かにつけてお金を請求されるので諦めたっぽいです:-(

AMDは特にコメントされていませんでしたが、これといって協力的という訳でもなさそうですね。コスト面では問題無さそうですが、ドライバーの作り込みとかの意味で……。それに比べると、NVIDIAは凄い協力的だったそうです。Valveのチームと一緒になってOpenGLドライバーの改善に取り組んでくれたし（残念ながらプロプライエタリなモノですが）、逆に例のNVIDIAのストリーミング技術を使ってみないかと売り込んできたみたいです:-)　もしかしたら、NVIDIA SHIELD自体がValveの為のデモ機だったのかもしれませんね。その売り込みのお陰かSteamOSに「ホームストリーミング」がデフォルトで搭載されているのかもしれませんし。「このホームストリーミングは、AMDのビデオカードでも使わなくちゃいけないんだけど、それでもいいの？」とまで聞いたらしいです:-)

今の所、ホームストリーミングがどのような原理なのか判りませんが、NVIDIAのGPUはKepler世代から「NVENC」というハードウェアによるエンコードが可能になっているらしいので、多分ですがこれを使ってストリーミングするのだと思います。それ以前の世代やAMDのGPUの場合、同様なハードウェア機能がついているのか調べていませんが、もし無かったらソフトウェアで実装しないといけないので、正直快適なホームストリーミングは出来ないかもしれませんね……。もしこの情報が本当なら、リファレンス機に搭載されるGPUはKepler世代以降って事になりそうですね。

またSteam Machinesですが、基本的には汎用のPCパーツを使ったモノですが、おそらく何らかの「認証制度」が設けられるのではないかと……。これはValveがゲーム開発者に対して、最低限のスペック保証をしなければならないかららしいです。またリビングルームに置く製品なので、安いからと言って、あまりに粗悪品な電源を積んで燃えましたとかじゃ話になりませんし……。

勿論、OS自体は自由にダウンロード出来るので、自分で組み立てた超スペックなタワー型PCにSteamOSをインストールしても、おそらく問題もなく動作してゲームも遊ぶ事が出来ますが、それはValveが想定している「Steam Machines」の役割ではないそうです。ここまでの話を総合すると、やはりSteam Machinesはリビングルーム向けのセットトップボックスに近い位置づけなのかもしれませんね。少し違うかもしれませんが、「PS4」というよりも「PS Vita TV」的な位置づけなのかも。PS4相当はメインPCのWindows版クライアントって感じで……。

3つあるうちの最後の発表ですが、Valveが開発しているコントローラーか「Source 2」エンジンなんじゃないかってのが大方の見方みたいですね。コントローラーは確実に開発中みたいですけど、今回発表までするかは微妙な感じ？

ここまで長々と書いてきましたが、情報元が「4Chan」の匿名情報なので信ぴょう性はかなり怪しいところです:-(　まぁ暇つぶしって事で、あんまり本気にしないで発表を待ちたいと思います。でも、実際にSteamOSについて、公式に祝福してるのってNVIDIAだけなんですよね……。もしかしたら他の企業も何らかのメッセージを公表しているのかもしれませんが……。

#追記
書き忘れましたが、Steam Machinesの条件？　には、低レイテンシなワイヤレスネットワークも必要らしいです。「Wi-Fi Direct」の事なのかな？

#外部リンク
Steam Rolling Into Your Living Room
http://blogs.nvidia.com/blog/2013/09/25/steam-rolling-into-your-living-room/

米AMD、次世代GPU「Radeon R9」&「Radeon R7」シリーズを発表 | マイナビニュース
http://news.mynavi.jp/news/2013/09/26/171/

4Gamer.net ― NVIDIAの新機軸を理解する（1）：GeForce GRIDが描く「ゲームスタジオが独自のゲームプラットフォームを描く時代」
http://www.4gamer.net/games/076/G007660/20120911008/

第504回：Wi-Fi Direct とは - ケータイ Watch
http://k-tai.impress.co.jp/docs/column/keyword/20110223_428718.html

#内部リンク
BLOG.MINAWA.NET: Steam Box の謎 その5
http://blog.minawa.net/2012/04/steam-box-5.html
Posted by on 0 件のコメント:

2013/09/26

SteamBox のサイズって？

発表まで、まだ時間があるので暇つぶし。SteamBoxってどのくらいの大きさになるのですかね？　一応「リビングルーム」向けを謳っているので、まさ普通のPCケースって訳でもないでしょうし……。有り得るとしたら「Mini-ITX」くらいですかねぇ。完全に据え置きゲーム機って感じなら、汎用性なんか気にせず一品モノで見栄え良くしてくるかもですが、どうせなら、ある程度汎用性がある規格に拘って欲しいですね。せっかくPC的な自由さがあるOSなんですし。

3年前くらいに妄想していた時はAMDって事で、まさかの「Mini-DTX」かもって思ったりもしたのですが、これだけモバイル機器が謳歌している時代、もう少し小さいサイズが妥当なのかもしれませんね。てか、AMDが推奨してたDTX規格自体、完全に忘れさられてますけど……。

今の時代だと、Intelが推奨している「NUC」レベルも考えられなくもないかなぁ。まぁある程度のGPUを積まないといけないから、そこまで小さいのは難しいかもですが……。値段との折り合いもありますしねぇ。PS4が4万円で出すっていうのが、Valveとしてはかなり厳しい条件ですよね。個人的には3万円、出来れば2万五千円くらいで、そこそこの性能のPCモドキみたいなのがギリギリのラインかなって気がするんですけどね。ゲーム機としてしか使えなければですけど……。

以前の話じゃ、SteamBoxはオープンなハードになるだろうって噂でしたし。この場合の「オープン」というのは、既存のPCのような意味ですかね。自分で他のOS、例えばWindowsを入れても構わないとか、そういう感じです。まぁぶっちゃけ、ただのPCな気がしてるんで、当たり前っちゃ、当たり前ですけど。

ただ、個人的には通常のBIOSの代わりに「CoreBoot」を採用した機器を見てみたいんですよね。以前も書いた事あるのですが……。APUならCoreBootに対応している可能性も高いんすけどね。Intelもですが……。実際、「ChromeBook」にはCoreBootが採用されてますし。ただCoreBootは「SeaBios」っていうペイロードで、デフォルトのOSイメージ？　以外も起動させる事が可能らしいんですが、残念ながらWindowsはACPIの制限が厳しくて、他のOSみたいに簡単に起動させるってレベルじゃないらしいんですよね。一応Windows7まではテストさてるらしいですが……。

そうなると普段はゲーム機として「SteamOS」を立ち上げてて、Windowsでしか遊べないゲームや、普段使いにWindowsOSを立ちあげたい時は、そちらを起動させるってのが、CoreBootだと、ちょっと不安な感じなんですよね。かといって、普通のBIOSのデュアルブートってのもどうかなって……。個人的にはUbuntuとかのLinuxを使えばいい気もしますが、それじゃ駄目な人も居ますしね……。とか無駄話書いてたら、あと1時間ですか。

#追記
やっぱりAMDのAPUだったら面白いんだけどなぁ。現行世代はまだまだ力不足だけど、次世代の「Kaveri」からはDDR3だけじゃなくてPS4と同じGDDR5もデフォルトで対応するらしいし。まぁ汎用品だとPS4みたいにGPUの能力を大幅にスペックアップさせてるって訳じゃないから、性能はかなり差があるだろうけど、その分値段的には有利だろうし……。

個人的には、SteamBoxはAndroidと似たような進化を遂げていくのかなって思うんですよね。既存の据え置き機みたいに最初でガツンとハードウェアの性能を上げるんじゃなくって、毎年あるいは3年毎くらいに、値段据え置きで徐々に性能が良くなっていくみたいな。SDLみたいに抽象化の強いライブラリーで互換とるんだから、そっちの方が良さそうな気がしますし……。まぁ今更妄想書いてもどうなるもんでもないんですが……。あと20分ですし。

#外部リンク
DTX - Wikipedia
http://ja.wikipedia.org/wiki/DTX

AMDが小型PC用フォームファクタDTXを提案
http://pc.watch.impress.co.jp/docs/2007/0115/ces15.htm

AMDの省電力APU「Kabini」搭載のMini-ITXマザーが発売、PS4と同系統の「Jaguar」コア採用 - AKIBA PC Hotline!
http://akiba-pc.watch.impress.co.jp/docs/news/news/20130822_612116.html

インテル® ネクスト・ユニット・オブ・コンピューティング
http://www.intel.co.jp/content/www/jp/ja/motherboards/desktop-motherboards/nuc.html

coreboot - Wikipedia
http://ja.wikipedia.org/wiki/Coreboot

Chromebooks - coreboot
http://www.coreboot.org/Chromebooks

#内部リンク
BLOG.MINAWA.NET: LinuxBIOS
http://blog.minawa.net/2007/03/linuxbios.html

BLOG.MINAWA.NET: LinuxBIOS with X11 server
http://blog.minawa.net/2007/03/linuxbios-with-x11-server.html

BLOG.MINAWA.NET: SteamとFusion APUの可能性
http://blog.minawa.net/2011/05/steamfusion-apu.html

BLOG.MINAWA.NET: Steam Box の謎 その6
http://blog.minawa.net/2012/04/steam-box-6.html
Posted by on 0 件のコメント:

SteamBox って結局？

さてさて、今日も妄想全開で頑張ろうと思います。何と言っても、後3時間くらい（現在、25日の夜11時）で、Valveの「2つ目」の発表が控えてますからね。一体何なのでしょうか:-)　大方の予想では、やはり「SteamBox」なのではないかと……。自分もそう思いますし。という事で、勝手にSteamBoxについて妄想したいと思います……。

ぶっちゃけ、「何で作るの？」って事ですよね……。えぇ、「NVIDIA」か「AMD」か……。大穴で「INTEL」？　この前も書きましたが、ハードウェア「だけ」を見れば、AMD、というか「APU」一択だと思います。PS4もXBONEもAPUですしね。ただ、ドライバーの出来や政治的？　な理由でNVIDIAなのかもなぁと漠然と思っていました。まぁNVIDIAだけでは「GPU」はともかく、「x86」の「CPU」を用意出来ないので、INTELのCPUもって事になるのでしょうけど……。

実際、ツイッターでこんな発言が話題になっています。

代表的なゲームエンジンである「Unreal Engine」の偉い人が、「NVIDIAが作ったトンデモナイもの見せてもらったよ。GPUじゃないけどゲーマーが喜びそうなヤツ（意訳）」。うーん、確かに気になる情報です……。ただ何となくお茶を濁されているような、いないような……。と思っていたら、今度はこんなツイートが……。

これは……。「AMDが今日、Linuxユーザーとゲーム開発者をハッピーにさせる発表をするよ！（意訳）」。正直、Chris Pirillo氏の事は全く知らなかったのですが、かなり有名なジャーナリスト？　みたいですね。そんな人がこんな事言ったら……。もう確定してるようなモノじゃないですかね……。

まぁ別にAMD一社からSteamBoxが出るとは誰も言ってないので、NVIDIAもINTELも、もしかしたらVIA!からも……。いや、流石にそれはないかな:-(　でも、NVIDIAは以前、ValveがSource EngineをどうLinuxへ移植したのかっていう発表をValveとNVIDIA共同で行った事があるくらいなんで、絶対に一枚絡んでるとは思うのですけどね。例の「togl」の解説です。

何だかんだ言って、AMDとNVIDIAの協力は絶対に欠かせない部分なので、両者とも協力を取り付けているのならば、SteamOSとしては、ひとまず成功と言えるのかもしれませんね:-)　まぁあと2時間ちょいで判明する事ではありますけど……。とか言って、SteamBoxの発表じゃなかったらズッコケそうですが。

あぁ、そうだ。何故か今日になって、NVIDIAが「Nouveau」（NVIDIAのGPUドライバーのオープンソース実装）に、GPUのドキュメントの一部を開示しても良いと通達してきたみたいですね。この件で以前、リーナスさん（Linuxの偉い人）に「ファ○ク・ユー！」されちゃった事もあったもんですが……。一体何故このタイミングで？

#YouTube
▶ Linus Torvalds - Nvidia F_ck You! - YouTube
http://youtu.be/IVpOyKCNZYw



#外部リンク
2014年、Steam の世界が広がります
http://store.steampowered.com/livingroom/?l=japanese

4Gamer.net ― ValveはなぜSource EngineをLinux＋OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
http://www.4gamer.net/games/107/G010729/20130322107/

Porting Source to Linux - Porting Source to Linux.pdf　PDFの為、閲覧注意
https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf

Nvidia seeks peace with Linux, pledges help on open source driver (Updated) | Ars Technica
http://arstechnica.com/information-technology/2013/09/nvidia-seeks-peace-with-linux-pledges-help-on-open-source-driver/

#内部リンク
BLOG.MINAWA.NET: リーナス氏がNVIDIAに宣戦布告？
http://blog.minawa.net/2012/06/nvidia.html
Posted by on 0 件のコメント:

2013/09/25

SteamOS 発表！

いやぁ、昨日は怒涛の妄想ラッシュで自分でも呆れるくらい毒電波を垂れ流してしまいましたが、やっぱり発表されましたね！　その名も「SteamOS」。具体的な内容はまだ判りませんが「Linux」ベースである事だけははっきりしました:-)

現在、明らかにされている内容から判る事は明確に「リビングルーム」向けって言う事ですね。普通に考えれば、大画面テレビに繋ぐ為に最適化されたUI、つまり「ビッグピクチャーモード」か、それに準ずるような既存のゲーム
機、セットトップボックスに似た操作感のUIって事になりますかね。どうしてもPCスタイルのゲームをやりたいって時にオプションで従来のクライアントのUIも選択出来るかってのが個人的に気になる所ですが……。

他に気になる特徴としては、ゲーム以外のコンテンツ、音楽や映画も取り扱うらしいですね。まぁこれは想定内ではありましたけど。それらを視聴する為のソフトが専用アプリなのか、あるいはChromiumのようなウェブブラウザー内なのかってのが多少気になる所ですかね。

話によると、既に「Spotify」は確定しているそうですが、何と言っても「Netflix」ですね。日本だと、あまり知名度はありませんが、米国だとダントツ一位の人気ですし。Netflixは「Chromebook」でもFlashと同じような待遇で特別なプラグインが用意されているくらい重要度が高いサービスですからね。

変更されていなければ、SteamクライアントもCEFというChrome(Chromium)の亜種？　を使用しているので、ウェブブラウザーとしては似たような事が出来る？　と個人的には思っているのですが、実際はどうなのかわかりません……。もし出来るのなら、様々なウェブアプリにも対応し易いでしょうから、意外と面白くなりそうではあります。例えばウェブアプリのゲームとか……。

一番驚いたのは「ホームストリーミング」ですね。Steam公式のアナウンスでは以下のように書かれています。
お持ちの Windows や Mac ゲームの全てを SteamOS マシーンでプレイできます。今まで通りにコンピュータを起動してSteam を実行すれば、家庭内ネットワークを経由してSteamOS マシーンでストリーム可能になり、これらのゲームをテレビでお楽しみいただけます！
うーん、これって家庭内「GAIKAI」みたいな事なんですかね？　もしくはPS4の「リモートプレイ」的な？　SteamOS側がクライアントになるって事は、既存のWin/MacのSteamクライアントを立ち上げてサーバー的に使うって事なんでしょうかね？ PS4やWii Uのように、元から織り込み済みのハードウェアならともかく、性能もマチマチなPC用Steamクライアントじゃ、ハイスペックなPCじゃないと結構厳しい気がするんですけど……。てか、そこまでハイスペックなPCがあるなら、わざわざ貧弱？　なSteamOS機なんか要らない気もしますが:-(　まぁ出来ないよりは出来た方がいいですけどね。

個人的には、このホームストリーミングってのがキーワードな気がします。うろ覚えですが、元々の「SteamBox」構想って、据え置き型の「Bigfoot」とモバイル型？　の「Littlefoot」の2つだった気がします。Littlefootってのは、情報が錯綜していて、一説には「ウェアラブルコンピュータ」なんじゃないかとも言われていましたしね。個人的には単なる携帯型ゲーム機？　かスマホ、タブレット型なんじゃないかと思いますが……。ちなみにビッグピクチャーモードは「Tenfoot」らしいです。

まぁ簡単に言っちゃえば、PS4におけるPSPみたいな位置づけなんじゃないのかなぁと。実際、前述したリモートプレイとホームストリーミングって被ってそうですし。って、ここまで書いて思ったのですが、やっぱりSteamBoxのパートナーって「NVIDIA」なのかもしれませんねぇ。

昨日書いたNVIDIAのAndroidベースの携帯ゲーム機「SHIELD」や7インチタブレット「Tegra Note」っていうドンピシャなアイテム出してますし、特にSHIELDの方はクラウドゲーミングサービス「GRID」のデモ機でもありましたし。GRIDの真の力はGAIKAIのようなクラウドサービス向けですが、下のリンク先を見るとPCを母艦にしてH.264によるストリーミングプレイもデモしてたらしいですし……。

今はまだホームストリーミングですが、将来的にはPS4のGAIKAIのように、ある程度以上のパワーが必要なゲームや、どうしてもWindows専用しか用意出来ない大作や古いゲームなどの互換性維持にクラウドサービスとして使いたいのかも……。SteamBoxのメインターゲット的には、超弩級なゲーミングPCってのは意識してなさそうですし、昨日書いたようにSDL2.0のような性能よりも移植性を念頭に置いたライブラリーを使う方針なら、将来的にはNVIDIAが目指しているARMベースの高性能SoCに切り替える事も比較点簡単でしょうし……。

以前、Amazonが高性能コンピューティング (HPC)のウェブサービス向けに、NVIDIAのサーバーを大量に導入したらしいって話をどこかのウェブサイトで見た気がするんですが、ソースを失念してしまいました……。確かかなり安く買えたとかなんとか……。Valveも似たような条件で導入出来たらNVIDIA GRIDは結構有効な武器になりそうな気がします。まぁ今直ぐって訳にはいかないでしょうが……。

クラウドからのゲームストリーミングが出来ればリビング向けの機器は、そこそこの性能でネイティブは軽めのクロスプラットフォーム向けゲームが動けば良いって割り切りが出来るかもしれませんしね。超大作や古いWindowsゲーがやりたければ、有料？　で、ストリーミングでって流れで……。

まぁ何にせよ、明日発表されるかもしれないSteamBox次第ってところですかねぇ。特に何処のチップメーカーと組んだのかって事でその後の話が変わってきそうです。てか、全然別の発表だったり？

#追記
しつこいですが、今考えても「SteamOS」って自分が以前妄想してた内容とソックリなんだよなぁ。最初に書いたの「2010年3月」ですよ？　別に何処かみてパクった訳でもないし……。自分でもビックリしますね。

#外部リンク
クラウドゲーミング – Gaming as a Service (GaaS) | NVIDIA GRID | NVIDIA
http://www.nvidia.co.jp/object/cloud-gaming-jp.html

【後藤弘茂のWeekly海外ニュース】 ゲーム機に挑戦するNVIDIAのGPU仮想化
http://pc.watch.impress.co.jp/docs/column/kaigai/20120529_536151.html

E3 2013: Project SHIELDにGRIDサーバ、万全の体制で挑むNVIDIAのゲームソリューションをチェック | Game*Spark - 国内・海外ゲーム情報サイト
http://www.gamespark.jp/article/2013/06/16/41505.html

Netflix - Watch TV Shows Online, Watch Movies Online
https://signup.netflix.com/global

Music for every moment - Spotify
https://www.spotify.com/int/

Netflix の映画を視聴する - Chrome OS ヘルプ
https://support.google.com/chromebook/answer/1401467?hl=ja

#内部リンク
BLOG.MINAWA.NET: Steam & Source on the Linuxの可能性 #05
http://blog.minawa.net/2010/03/steam-source-on-linux-05.html

BLOG.MINAWA.NET: Steam Box の謎 その4
http://blog.minawa.net/2012/03/steam-box-4.html
Posted by on 0 件のコメント:

2013/09/24

ぼくのかんがえたすちーむぼっくす その4

前回までの妄想をまとめると以下のような感じです。一応ですが全て私の妄想の産物です。多分に誤りが含まれている可能性がありますのでご注意下さい。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定？)
ウィンドウシステム = X.Org Server(Valve Runtimeに含まれているSDLをフロントエンドとして使用？　バックエンド「MirかWaylandかX.Orgか」は開発者が意識する必要性は無い？)
推奨ライブラリー = Valve Runtime（Valveが推奨するオープンソースなゲーム開発ライブラリー群？）
取り敢えず、こんな感じでしょうか？　って、自分で書いてますが、本当に適当だなぁ。本職の人からみたら噴飯物かもしれませんが、祭りって事でご容赦下さい:-(

次に肝心のハードウェアについてですが、基本的にはPS4やXBONEと同じPCアーキテクチャ（x86）になると思います。問題はどこのチップメーカーなのかって事ですよね……。私の以前の予想では「AMD」の「APU」こそがSteamBoxの中の人なのではないかと妄想していたのですが、最近になって違うのではないかと思い始めています。では何処なのか？

基本的には「インテル」で、もしかしたらディスクリートなGPUとして「NVIDIA」のGPUが追加されているのではないかなって最近は思い始めています……。いや、ハードウェアだけ見れば、AMDのAPUがベストなのは、マイクロソフトとソニーというゲーム機メーカーが揃って次世代機に採用している時点で間違いはないんですよね。自分もそう思っていますし。

ただAMDというかRADEONのLinuxにおけるプロプライエタリなドライバーサポートがどうしても、他の2社と比べると劣りそうってのが……。以前も書いた気がしますが、もはやゲーム界のご意見番とも言える大御所「John Carmack」氏のツイッターでのコメントが全てを表していると思うので掲載しておきます。

これは必ずしもLinuxにおけるドライバーの出来を指している発言ではないですが、一般的にRADEONのLinuxドライバーはWindowsのソレよりも出来としては劣るとされるのが定説ですし……。それに、APUがPS4とXBONEに採用されて発売前の追い込みに追われているドライバー担当チームがLinux版の開発にまで手が回るのかっていう不安もありますしね。ただでさえ、AMDのドライバー担当チームは人数が少ないという噂ですし……。

それに以前からチラホラ流れてくるSteamBoxの噂によると、Valveのチームが想定しているハードウェアがインテルのCPUとNVIDIAのGPUの組み合わせであるという情報が圧倒的に多いですし。まぁこれはSteamBoxがというより、SteamのLinux版の平均的ユーザーが、この組み合わせのPCをよく使っているというデータに基づいて検証しているに過ぎないのかもしれませんが……。

またインテルはともかく、NVIDIAとしては上客であったソニーのPS4のGPUをAMDに奪われ、なおかつAndroidのリファレンス機とも言うべき「Nexus7」の次世代機でも不採用になるというイメージ的にも悪いめぐり合わせの時期ですしね。まして据え置きゲーム機に関しては、マイクロソフトのXBONEと任天堂のWii UもAMD採用という事で、正直「全敗」といっていい状況ですし……。ここまで追い詰められると、Windowsでのゲーム開発のリファレンスもNVIDIAからRADEONへと流行が移ってしまいかねませんしね……。

NVIDIAも、この状況は相当マズいと思ってか、積極的に自社製品を売り込んでいるように思えます。既に忘却の彼方になりつつありますが、異色のAndroid据え置きゲーム機として一時期話題になった「OUYA」にも相当安価にTegra3チップを供給したという噂もありますし、最近になってNVIDIA自らがAndroidベースの携帯ゲーム機「SHIELD」を売りだしたり、Nexus7対抗なのか7インチタブレット「Tegra Note」を200ドルという採算度外視の値段で計画中だったりしますし……。

また少し前のイベントでCEOジェン・スン・フアン氏自らが高性能ARMコアを開発統合する「Project Denver」のデモをUbuntuを使ってアピールしてたりと、最近Windows以外にも頻繁にアピールしている機会が目立ってきています。また、今まで封印していたKeplerコアのIPライセンス提供ビジネスを開始したのも見逃せないなと個人的には思っています。

これは基本的にARM向けの措置らしいですが、もしもValveがNVIDIAから「安価」でKeplerコアのIPライセンスを購入して、インテルのCPUと組み合わせた製品を作ったのなら、AMDのAPUと迄はいきませんが、初代XBOX的な「ゲーム機」が作れないとも言い切れないなと思っているのですが妄想し過ぎですかね……。

それにSDLのようなライブラリーでゲームの互換性を維持するつもりなら、大幅な最適化が出来ない代わりに、将来的にはNVIDIAが相当力を入れている前述の「Project Denver」、あるいはインテルの内蔵GPUのスペックが十分に上がった時にも、互換性の問題は他企業のプラットフォームよりは起きにくいのではないかなぁと思っているのですが、これも妄想のし過ぎかもしれませんね……。

他にも幾つか書こうかなって思っていたのですが、そろそろ時間がなくなってきたので、このあたりで終わろうかと思います。正直言って時間が無さ過ぎて、いつも以上にグタグタな内容になってしまいましたが、まぁ仕方ないですね。発表まで、あと1時間切ってますし。

さて、実際の「SteamBox」構想が一体どういう内容なのか期待半分不安半分で、その時を待ちたいと思います:-)

#追記
あ、書こうと思ってて忘れてましたが、Linux版のSteamクライアントをビッグピクチャーモードで動かした時に内蔵のウェブブラウザーでウェブ閲覧が出来るのですが、そのウェブブラウザーのUAって「Chrome」のバージョン18.xなんですよね。これってCEF使ってるからだと思うのですが、セキュリティ的には修正されてるのかなぁ？　流石に最低限の修正はされているとは思いますけどね。

ついでに書くと、ビッグピクチャーモードを起動した時にでる動画って、「WebM」なんですよね。こういう所もオープンソース愛好家からすると嬉しいところですね:-)　PS4もせっかくFreeBSD使うなら積極的にオープンソースを活用、支援してくれたらいいんだけどなぁ。

#外部リンク
2014年、Steam の世界が広がります
http://store.steampowered.com/livingroom/?l=japanese

NVIDIA，KeplerコアのIPライセンス提供ビジネスを開始 - 4Gamer.net
http://www.4gamer.net/games/049/G004964/20130619001/

【後藤弘茂のWeekly海外ニュース】64-bit ARMコアをGPUに統合するNVIDIAのDenver計画の全貌
http://pc.watch.impress.co.jp/docs/column/kaigai/20130606_602510.html

NVIDIA，自社設計のTegra 4搭載Androidタブレット「Tegra Note」を発表。価格は199ドルで，2～3か月以内にパートナー企業から出荷 - 4Gamer.net
http://www.4gamer.net/games/049/G004964/20130919005/

NVIDIA SHIELD | Ultimate Gaming and Portable Entertainment
http://shield.nvidia.com/

NVIDIAの「SHIELD」分解レポート。299ドルの「ゲーム機型Android端末」にはけっこうコストがかかっていた - 4Gamer.net
http://www.4gamer.net/games/198/G019883/20130824005/

おまけ　インテルでインタビューに答えるゲイブ氏:-)
Gabe Newell of Valve on Game Development and Perceptual Computing | Intel® Developer Zone
http://software.intel.com/en-us/blogs/2013/06/17/gabe-newell-of-valve-on-game-development-and-perceptual-computing
Posted by on 0 件のコメント:

ぼくのかんがえたすちーむぼっくす その3

前回はSteamBoxのOSについて妄想しました。まとめると以下のような感じですかね。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定？)
まず何故Ubuntu 12.04なのかですが、Linuxディストリビューションの中で最もアクティブなユーザー数が多い事と、12.04は長期サポート (LTS) 版である事が理由だと思います。またUbuntu Coreという組み込み向け（といっても、本来の組み込みというより、Windowsのエンベデッド版に近い感じ）で最小構成で利用可能だからだと思います。

UIは正直まだ判りませんが、Valveの発表を見ると「リビングルーム」を強調しているので、もしかしたら通常のSteamクライアントのUIは封印されてビッグピクチャーモードのみで運用するのかもしれませんね。通常のSteamクライアントが使えるとしても、Ubuntu上でSteamクライアントを立ち上げるような感じではなく、ブートして、そのままSteamクライアントへログインするという感じになるかもしれません。感覚としてはChromeOSに近いかもと思っているのですが、正直全然判りません。

ウィンドウシステムは12.04という事でデフォルトの「X.Org Server」の確率が高いでしょうね。今話題の「Mir」あるいは「Wayland」は、商用のシステムで実戦投入するには時期尚早ですしね。12.04はLTSなので「2017年4月」がサポートの最終期限ですし。恐らく2015年くらいには、MirかWaylandも落ち着いてくるでしょうし（適当ですが）。

ちなみにSteamは、この厄介な次世代ウィンドウシステム戦争をどう考えているのかというと、ValveにいろいろとアドバイスをしているプログラマーのRyan C. Gordon（icculus）氏は以下のようにツイッターでコメントしています。

またicculus氏は、この厄介な問題の解決策として、Valveは「SDL2.0」を積極的に使って対処するだろうともコメントしています。
This isn't strictly true. Most of the current titles are using SDL, which uses GLX behind the scenes. One could swap out the game's included SDL library with a build that targets Wayland or Mir, and the game would run without an X server and not know or care that it's not using X11. This can happen without updating the game binaries directly.

For games that don't ship their own copy of SDL (and thus use the one included in the Valve Runtime by default), you don't even have to touch the game's depot at all. Valve just needs to update their Runtime package and it's good to go.

SDL is smart enough to try to use Wayland or Mir first, and if they aren't available, use X11, so one copy of SDL will work on whatever the current system has.

This is an oversimplication; there are probably games that use SDL but will cheat and try to talk to an X server directly for various reasons--but this is rare--and there's at least one big game on Steam that's talking to GLX directly without using SDL. But by and large, switching the Linux Steam library from X11 to Wayland and/or Mir is not only doable, it's probably relatively easy.

--ryan.
要約すると、WaylandかMirかX.orgかと言った厄介な問題はイチイチ考えず、Valveが配布している「Valve Runtime」に含まれているSDL2.0を開発者が使ってくれれば、後はValve Runtimeが面倒見てくれるよと……。もしかしたら大幅に間違っているかもしれませんが、取り敢えずValve Runtimeを使っておけばOKみたいな感じですかね（適当）。

ちなみにValve Runtimeは今の所、以下のようなパッケージ内容になっているようです。これって、Valveが推奨しているゲーム制作用のライブラリー群って事で良いんですかね？　正直、理解不足なんですけど……。ちなみにValveのGitHubでDL可能みたいです:-)
acl libacl1 libacl1-dev
alsa-lib libasound2 libasound2-dev
alsa-plugins libasound2-plugins
atk1.0 libatk1.0-0 libatk1.0-dev
attr libattr1 libattr1-dev
avahi libavahi-common3 libavahi-common-dev libavahi-client3 libavahi-client-dev
bzip2 libbz2-1.0 libbz2-dev
cairo libcairo2 libcairo2-dev
cups libcups2 libcups2-dev
curl libcurl3 libcurl3-gnutls libcurl4-gnutls-dev
cyrus-sasl2 libsasl2-2 libsasl2-dev
d-conf dconf-gsettings-backend
dbus libdbus-1-3 libdbus-1-dev
dbus-glib libdbus-glib-1-2 libdbus-glib-1-dev
dummygl dummygl-dev
e2fsprogs libcomerr2 comerr-dev
expat libexpat1 libexpat1-dev
flac libflac8 libflac-dev
fltk1.1 libfltk1.1 libfltk1.1-dev
fontconfig libfontconfig1 libfontconfig1-dev
freeglut freeglut3 freeglut3-dev
freetype libfreetype6 libfreetype6-dev
gcc-4.6 libgcc1 libstdc++6 libstdc++6-4.6-dev libstdc++6-4.6-pic libgomp1 gcc-4.6-base
gconf libgconf-2-4 libgconf2-dev
gdk-pixbuf libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-dev
glew libglew1.6 libglew1.6-dev
glib2.0 libglib2.0-0 libglib2.0-dev
gmp libgmp10 libgmp-dev
gnutls26 libgnutls26 libgnutls-dev
gst-plugins-base0.10 libgstreamer-plugins-base0.10-0 libgstreamer-plugins-base0.10-0-dev
gstreamer0.10 libgstreamer0.10-0 libgstreamer0.10-0-dev
gtk+2.0 libgtk2.0-common libgtk2.0-0 libgtk2.0-dev
gtk2-engines gtk2-engines
gtk2-engines-murrine gtk2-engines-murrine
gtk2-engines-pixbuf gtk2-engines-pixbuf
heimdal libasn1-8-heimdal libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libkrb5-26-heimdal libroken18-heimdal libwind0-heimdal
jack-audio-connection-kit libjack0 libjack-dev
jasper libjasper1 libjasper-dev
json-c libjson0 libjson0-dev
keyutils libkeyutils1 libkeyutils-dev
krb5 libkrb5-3 libkrb5-dev libk5crypto3 libkrb5support0 libgssapi-krb5-2 krb5-multidev
lcms2 liblcms2-2 liblcms2-dev
libappindicator libappindicator1 libappindicator-dev
libasyncns libasyncns0 libasyncns-dev
libav libavcodec53 libavcodec-dev libavfilter2 libavfilter-dev libavformat53 libavformat-dev libavutil51 libavutil-dev libswscale2 libswscale-dev
libcanberra libcanberra0 libcanberra-dev libcanberra-gtk0 libcanberra-gtk-dev libcanberra-gtk-module
libcap2 libcap2 libcap-dev
libdbusmenu libdbusmenu-glib4 libdbusmenu-gtk4
libexif libexif12 libexif-dev
libffi libffi6 libffi-dev
libgcrypt11 libgcrypt11 libgcrypt11-dev
libgpg-error libgpg-error0 libgpg-error-dev
libgsm libgsm1 libgsm1-dev
libice libice6 libice-dev
libidn libidn11 libidn11-dev
libindicator libindicator7 libindicator-dev
libjpeg6b libjpeg62 libjpeg62-dev
libjpeg-turbo libjpeg-turbo8
libmad libmad0 libmad0-dev
libmikmod libmikmod2 libmikmod2-dev
libnotify libnotify4 libnotify-dev
libogg libogg0 libogg-dev
#libogre-1.7.4 libogre-1.7.4 libogre-dev
libpng libpng12-0 libpng12-dev
libsamplerate libsamplerate0 libsamplerate0-dev
libsdl1.2 libsdl1.2debian libsdl1.2-dev
libsdl2 libsdl2 libsdl2-dev
libsdl2-image libsdl2-image libsdl2-image-dev
libsdl2-mixer libsdl2-mixer libsdl2-mixer-dev
libsdl2-net libsdl2-net libsdl2-net-dev
libsdl2-ttf libsdl2-ttf libsdl2-ttf-dev
libselinux libselinux1 libselinux1-dev
libsm libsm6 libsm-dev
libsmpeg0 libsmpeg0 libsmpeg-dev
libsndfile libsndfile1 libsndfile1-dev
libtasn1-3 libtasn1-3 libtasn1-3-dev
libtheora libtheora0 libtheora-dev
libtool libltdl7 libltdl-dev
libusb-1.0 libusb-1.0-0 libusb-1.0-0-dev
libva libva1 libva-dev
libvorbis libvorbis0a libvorbisfile3 libvorbisenc2 libvorbis-dev
libvpx libvpx1 libvpx-dev
libx11 libx11-6 libx11-dev libx11-xcb1 libx11-xcb-dev libx11-data
libxau libxau6 libxau-dev
libxaw libxaw7 libxaw7-dev
libxcb libxcb1 libxcb1-dev libxcb-shm0 libxcb-shm0-dev libxcb-render0 libxcb-render0-dev libxcb-glx0 libxcb-glx0-dev
libxcomposite libxcomposite1 libxcomposite-dev
libxcursor libxcursor1 libxcursor-dev
libxdamage libxdamage1 libxdamage-dev
libxdmcp libxdmcp6 libxdmcp-dev
libxext libxext6 libxext-dev
libxfixes libxfixes3 libxfixes-dev
libxi libxi6 libxi-dev
libxinerama libxinerama1 libxinerama-dev
libxml2 libxml2 libxml2-dev
libxmu libxmu6 libxmu-dev
libxpm libxpm4 libxpm-dev
libxrandr libxrandr2 libxrandr-dev
libxrender libxrender1 libxrender-dev
libxss libxss1 libxss-dev
libxt libxt6 libxt-dev
libxtst libxtst6 libxtst-dev
libxxf86vm libxxf86vm1 libxxf86vm-dev
mesa libglu1-mesa libglu1-mesa-dev
ncurses libncursesw5 libncursesw5-dev libtinfo5 libtinfo-dev
network-manager network-manager-dev libnm-util2 libnm-util-dev libnm-glib4 libnm-glib-dev
nspr libnspr4 libnspr4-dev
nss libnss3 libnss3-dev
nvidia-cg-toolkit nvidia-cg-toolkit libcg
openal-soft libopenal1 libopenal-dev
openldap libldap-2.4-2 libldap2-dev
openssl libssl1.0.0 libssl-dev
orc liborc-0.4-0 liborc-0.4-dev
p11-kit libp11-kit0 libp11-kit-dev
pango1.0 libpango1.0-0 libpango1.0-dev
pcre3 libpcre3 libpcrecpp0 libpcre3-dev
pixman libpixman-1-0 libpixman-1-dev
pulseaudio libpulse0 libpulse-dev
rtmpdump librtmp0 librtmp-dev
schroedinger libschroedinger-1.0-0 libschroedinger-dev
sdl-image1.2 libsdl-image1.2 libsdl-image1.2-dev
sdl-mixer1.2 libsdl-mixer1.2 libsdl-mixer1.2-dev
sdl-ttf2.0 libsdl-ttf2.0-0 libsdl-ttf2.0-dev
speex libspeex1 libspeex-dev libspeexdsp1 libspeexdsp-dev
sqlite3 libsqlite3-0 libsqlite3-dev
tbb libtbb2 libtbb-dev
tcp-wrappers libwrap0 libwrap0-dev
tdb libtdb1 libtdb-dev
tiff libtiff4 libtiff4-dev
udev libudev0 libudev-dev libgudev-1.0-0 libgudev-1.0-dev
util-linux libuuid1 uuid-dev
x11proto-composite x11proto-composite-dev
x11proto-core x11proto-core-dev
x11proto-fixes x11proto-fixes-dev
x11proto-input x11proto-input-dev
x11proto-kb x11proto-kb-dev
x11proto-randr x11proto-randr-dev
x11proto-render x11proto-render-dev
x11proto-scrnsaver x11proto-scrnsaver-dev
x11proto-xext x11proto-xext-dev
x11proto-xf86vidmode x11proto-xf86vidmode-dev
xft libxft2 libxft-dev
xtrans xtrans-dev
zenity zenity
zlib zlib1g zlib1g-dev
私の浅い解釈だと、Valveは互換性維持の為にオープンソースなライブラリー、とりわけSDL2.0を強く推奨しているようですね。以前もこのブログで書きましたが、SDLのメイン開発者である「Sam Lantinga(Slouken)」氏がValve入りしていますし。

誤解を恐れずSDLを説明すると、オープンソースかつクロスプラットフォームな「DirectX」って説明が一番近いですかね。Direct3DはOpneGLですが、他の例えばキーボードやコントローラーの出入力や2Dのサウンド、フォントの取り扱いとかですか？　プログラマーじゃないんで適当で申し訳ないんですが:-(

実際、SDL2.0になってから、コントローラーの取り扱いはかなり改善されているようです。以前のバージョンだと、コントローラーの扱いがあんまり良くなかったので、例えば有名なエミュレーターである「Mednafen」なんかは、SDLから他のライブラリーに1年前くらいから変更してしまいましたし……。実際に最近になってValveはWindows版の「Team Fortress 2」でのコントローラーの取り扱いをSDL2.0に変更していますし。

この事から考えられる事は、ValveはSteamBoxに置いて、PS4のように独自APIを追加するのではなく、逆にSDLやOpenGL、その他のオープンソースなクロスプラットフォームを多用して、クロスプラットフォームでの互換性を最大限に優先するのではないかと思われます。

この事はオープンソース愛好者からすると、嬉しい事ではあるのですが、SteamBoxがPS4のような次世代機と「ガチ」な性能競争ではかなり不利になる事にもなりかねないので、ゲーム機ファンとしては、少し残念ではありますけどね:-(　互換性と性能の両立というのは、なかなかに難しいものです……。

またまた長くなったので一旦終わります。次はハードウェアについて書きたいのですが、正直2時までに間に合うかわかりません……。

#外部リンク
[Phoronix] Valve's Steam Box Will Most Likely Use An X.Org Server
http://www.phoronix.com/scan.php?page=news_item&px=MTMxODc

steam-runtime/README.md at master · ValveSoftware/steam-runtime · GitHub
https://github.com/ValveSoftware/steam-runtime/blob/master/README.md

Mednafen Forum: Development => Mednafen 0.9.25-WIP
http://forum.fobby.net/index.php?t=msg&goto=2694&
Posted by on 0 件のコメント:
登録: 投稿 (Atom)