http://www.4gamer.net/games/032/G003263/20091217105/
グラフィックスの最先端「SIGGRAPH Asia 2009」開幕，開発者が語る日本のゲーム開発の課題とは
話を聞いてみると，Intel製のドライバではコアの性能がまったく発揮できていないという。
ドライバ関係の最適化で「数十倍は速くなる」とのこと。PineView搭載のAtom PCでは，動画を再生するとWindowsごと落ちるといったこともあったようだが，実際にはPowerVRコアの中にはビデオ用のデコーダハードウェアが入っていてH.264などを10ストリームくらい同時に再生できるようにはなっているらしい。
Intel好像總有人在講什麼SIMD沒用、泛用CPU才是王道的事情….異構運算本來就是要因地制宜啊。
PineView放的應該還是GMA950吧….放的如果是PowerVR的話，Driver才有機會點石成金啊。_A_
如果32nm放PowerVR的話大概就真的會不錯了。Intel有打算把PowerVR買下嗎？
http://www.4gamer.net/games/103/G010304/20091218032/
Khronos Group代表者とDavid Kirk氏への記者会見レポート，Tegraの新情報が明らかに
Tegra主打Flash加速。這對web的確很有幫助….
「GPUから固定機能（※プログラマブルでない機能）はなくなることはないだろう」
「シミュレーションとグラフィックスに，もはや区別はないのだ」（Kirk氏）
說得好啊Kirk船長。GPU主要的kill application還是繪圖、以及透過圖學來展現simulation的內容、結果把模擬過程本身就當成圖學的一部分來看待的話就更合理了。
的確Fermi一路改善到現在，連64bit都支援了，又增加不少overhead(所謂罪惡的肥肉)，但是即使泛用性改善，Fermi以後的GPU的fix-function pipe部分(ROP不知道但至少texture)顯然不會拿掉才對。
http://www.4gamer.net/games/076/G007660/20091217103/
SIGGRAPH Asia 2009，David Kirk氏基調講演レポート。「グラフィックスは並列化されていく」
GPU廠商當然替GPU說話：
可以平行化的運算量繼續不斷地朝GPU放才有辦法解決系統的瓶頸。
所以到底是「CPU吃掉GPU」，還是先前WaffenSS兄提到的「GPU把CPU吃掉」呢？
至少NVIDIA短期內做不出x86來讓GPU吃是一個商業模式上的瓶頸就是了。_A_
—-
http://pc.watch.impress.co.jp/docs/news/event/20091218_336837.html
【SIGGRAPH Asia 2009レポート】
NVIDIAがGPUによるグラフィックスワークスタイルの変革をアピール
http://pc.watch.impress.co.jp/img/pcw/docs/336/837/html/ph05.jpg.html
緑色のバーがGPUによるパラレル処理となるが、アムダールの法則に当てはめ、GPUのパラレル性能向上がグラフィックレンダリング全体の大幅な向上につながることを示した図となる
http://pc.watch.impress.co.jp/img/pcw/docs/336/837/html/ph19.jpg.html
Image Space Photon Mappingのプロセス。現在の論文では中間の反射部分をCPU処理させているがデータ転送の無駄があるので、ここをGPUに置き換えることで何百倍もの性能を出せるとする
http://graphics.cs.williams.edu/papers/PhotonHPG09/
Hardware-Accelerated Global Illumination
by Image Space Photon Mapping
http://pc.watch.impress.co.jp/img/pcw/docs/336/837/html/ph24.jpg.html
カーク氏の講演における最後のスライド。「CPUは年間20～30%の性能向上、GPUは現状でもCPUより性能が高いだけでなく成長率も高い。2015年(6年後)にそのギャップはさらに広がっている」とアピールした
——
http://pc.watch.impress.co.jp/docs/news/event/20091221_338290.html
【SIGGRAPH Asia 2009レポート】
東工大、スクウェアエニックスがCUDA実装事例を紹介
http://pc.watch.impress.co.jp/img/pcw/docs/338/290/html/ph23.jpg.html
計算時間をより詳細に見た結果。GPUの数が増えるごとに計算時間は減るが、データ通信の時間はほぼ一定。そのため、GPUの数が増えたとき、どこかのタイミングで通信がボトルネックとなって、それ以上は性能が向上しないという転換点がある
NVIDIA RealityServer應用
http://pc.watch.impress.co.jp/…/336/837/ph09.jpg
NVIDIA RealityServer最下面兩個應用就是
for雲端遊戲了,可見得NV未來考慮的不只是HPC應用.
不過…..雲端遊戲需要的頻寬短時間內還解決不了.
OnLive應該會是最早投入雲端遊戲的商業運作
http://www.onlive.com/service.html
不知道它們用什麼硬體平台當雲端Server.
設備只有搖桿和Client端簡單硬體倒是完全符合
雲端Console的理想,幾乎不需要升級.
but不看好以現在頻寬能玩HD規格的動作遊戲.
要能穩定4.5MB頻寬,起碼要8M ADSL.
這就已經排除大多數ADSL用戶了.
更慘的是4.5MB的頻寬需求,60fps每Frame只有75KB
可用,還要扣掉音訊(HD?),壓縮品質恐怕糟透了.
雲端遊戲要取代Local Computing大概頻寬還要翻幾倍
看不出OnLive有成功獲利的機會,大概想先燒錢卡位吧.
除了OnLive之外還有一個GAIKAI：
http://www.gaikai.com/
OnLive先前在GDC09的時候發表的東西
http://www.4gamer.net/…/027/G002744/20090326065/
一個是server latency，這個當然最後得用data center的數量去cover。
距離限制是一千英哩，這個OnLive在申請的時候會去辨識、GAIKAI則好像透過增設去cover。
頻寬需求的部分，OnLive是1.5Mbps前後420p、5Mbps前後720p，不是4.5MB/s。
壓縮品質部分，GDC2009會場上的感覺是「不要湊上前看大概就不會太糟」，所以還蠻有趣的。
>>5Mbps前後720p，不是4.5MB/s。
>>不要湊上前看大概就不會太糟
單位看錯…….那比我想的還慘.
畢竟Realtime不能有太大Latency.
應該是每個frame獨立壓縮然後就趕快送出去.
不像影片可以參考前後frame,
靠Keyframe來省資料,以提高壓縮率.
低Latency即時壓縮的演算,大概類似M-JPG.
但720P的JPG調到品質最Low也常接近100KB.
Onlive的5Mbps等於625KB/s,
60FPS時等於每Frame約10KB(還要扣掉音效),
資料量只有JPG的1/10…..
720P不壓縮的24bit color要2636KB.
要變成不到10KB….那壓縮率是近300:1.
真不知那OnLive該怎麼弄出還能看的畫面?
> 真不知那OnLive該怎麼弄出還能看的畫面?
看來人們的動態視覺沒有他們想像中的好_A_
用每個frame的資料量來和JPEG畫質比的話，就是等於當成MotionJPEG….實際上從微軟那個720p webcam來說M-JPEG畫質已經不錯了並不會很糟，如果是MPEG的話可能會壓掉更多東西。
卡位歸卡位啦，能達到多少性能和品質是真的讓人很有興趣，數字上是覺得很糟沒錯，不過如果很糟的話會場上應該看得出來。
>>Intel有打算把PowerVR買下嗎？
Intel本年已經買入約15%Imagination Technologies的股份
蘋果買了約10%
Imagination Technologies半年業績
晶片授權量增4成
每核心權利金增加了33%
淨利增加4倍
本年度股價升了快9倍…