CPUアーキテクチャについて語れ 42
■ このスレッドは過去ログ倉庫に格納されています
cellとAPUって似てるか?
汎用+シンプル沢山
APUは単にCPU+GPUで思想が全然違うと思うが
まあ、どうしてもCellが素晴らしくて引き継がれてると思いたいなら仕方ないけど
正直、反面教師くらいにしかなってないと思うわ GPGPUやAPUをCellの延長線上で捕えようとするのは
PC Watchの後藤氏流の解釈だね
PS3のCellがヘテロジニアス・コンピューティングの先鞭をつけたのは確かだろうけど
シングル重視とマルチ特化のハイブリッドが(計算上は)ベストというのは当然の帰結のように思える GPGPUに関して昔からの疑問がある
8Kでのレンダリングなどの重いグラフィック処理をリアルタイムでこなしながら、
さらに重い物理演算を並列させて動作させつつ、フレームレートを240fpsを維持できるのかと? 2020年には8Kディスプレイ6面構成が当たり前になるし >>756
「当たり前」の日本語の定義を知りたいものですなぁ
GPU側のレンダリング能力も、なにより人間の視覚・知覚能力も追いつかんだろう
スケーリングして使うなら4kだろうが8kだろうが見た目には分からんだろう
GPU処理能力を余分に必要とする分だけ8kのほうが無駄だとしか言えんわ >>753
まぁ本来は逆なんだろうけどな
Cellがそこを目指したんだろう、だから帰結の一つとしては似てるモノも有り得る
ともあれ汎用でないものを載せるほど面積コストが下がる算段があるわけでも無し
異種CPU混合かCPU-GPU連結かのどっちかですな
コスト制約がゆるけりゃ専用回路の山載せりゃ良いんだろうがな >>755
>8Kでのレンダリングなどの重いグラフィック処理をリアルタイムでこなしながら、
>さらに重い物理演算を並列させて動作させつつ、フレームレートを240fpsを維持できるのかと?
それはある意味で「維持できるの?」以上に、それに近いことを実現できるソリューションはGPGPUしかないでしょ もともとCellは
東芝SCEはSPUのみのメニーコア
IBMはPOWER4のみのマルチコア
案があって一旦IBM案で固まるも
クタタンの鶴の一声で
PPU + SPUなヘテロになった
ヘテロなんて妥協の産物 >>755
それするために並列実行関係を強化して来たわけで
nvidiaはvoltaでやっと実装
pascalはできなかった nvがレイトレおしてるのも
何気にtensor core普及させる為だったり レイトレ普及はかなり先だから
当面はラスタライズと一部レイトレになりそうだし、その場合物理演算やAI、音響とレイトレの複合処理になるからクソ重くなってくる
DX12のAsyncを使って効率的に並列処理しないとこれ以上はゲームが進化しないだろうな >>761
それなんか違うと思う
開発の最初期はそうだったのかもしれないけど・・
Cellとしての形がきまってからは、IBMはSPEを5か6か忘れたけどSPEを少なくしてPPUを強化する案を出したけど
SCEの久夛良木社長が2のべき乗である8にするべきって主張して今の形になったと
団子が鬼の首を取ったように話してのを覚えてる >>766
まぁ当初GPUに使おうとしてたようだから、マジだろうな、、、
というかIBMプランなら割とまともなプロセッサだな、bullの逆っぽい 解像度いくらあげても
驚くほどのものはなく
レンダリング自体変えるってのはアリだな 人間の視覚は高性能。8k と4kの違いくらいは余裕
Visual acuity > Other measures
https://en.wikipedia.org/wiki/Visual_acuity CellがAPUの原型ってのは無理がある。
APUの原型はMediaGXだろう。 >>767
IBMはCellの開発を経てPPUのみのXenon、Cellの高クロック化技術を活かしたPOWER6を開発し、eDRAMを取り込みIBM純正Cellとも言える8コア32スレッドのPOWER7へ繋げていった
00年代だけで考えれば高性能でホモジニアスのマルチコアとGPUが台頭した時代だった いやスマホの解像度なら今も2Kだろう。もうちょっと高いのもあるが。
スマホのdpiでと言うべきではないか >>768
非効率なモノを引き継ぐ理由は既得権益の保護以外ないからね NVがレイトレ推してるのはオフライン用の流用で簡単に出来るからで、他に先に囲い込まれない為の保険みたいなもんよ
一部レイトレっていうのすら無茶苦茶非効率で次世代あたりじゃ一部のクソゲーの話題作りの為に使われて終わりかな。はいはいノーティは凄いねパチパチみたいな
もっと負荷が軽くてレイトレを粗く近似できるボクセル・コーン・トレーシングがUnreal Engine 4の標準になるはずだったが、あまりに非現実すぎてそれすら標準化は見送り。同じ負荷時の表現力がラスタライザに遥かに劣るので、クソゲーの話題作り専用
今のハードの進化ペースだと10年後もリアルタイムのレイトレなんか糞すぎて使われないな。
ラスタライザで平均して1ポリゴンの大きさが1ピクセルより小さくなるとやっとレイトレやるメリットが出てくるんだけど、解像度がインフレ状態なのとハードやドライバレベルでラスタライザの延命策が色々出てきて尚更レイトレには厳しくなった そもそもゲームは見た目派手だったらそれでいいんで、別にレイトレーシング必要ないしな
昔の、ろくに技術もない時代ならともかく、今のゲームのグラフィックならレイトレーシングにしても
せいぜい「なんか雰囲気違うな」程度で、特に売りになるとは思えない CellとGPGPUの最大の違いは開発環境
GPGPUは基本ネイティブアクセス不可で、cudaやopenglでプログラミング
Cellは、アセンブラやインラインアセンブラでプログラミング まだ力のあるうちに改革しておかないと衰退するだけだけどな >>778
画面内で支配的な一次レイはラスタライザでも数学的に等価なので雰囲気すら変わらないかな
変わるのは反射の映り込みの正確さ、影の形の正確さ(シャドウレイ飛ばせばね)、あとはカラーセロハンやステンドグラスみたいな色付きの影が正確に出来るくらい。
どれもこれもラスタライザでインチキな疑似テクニックでやっても人間の目に全く差が分からない物ばかり
んで、レイトレをやってもラジオシティみたいな物が勝手に計算される訳でもない 時代はむしろVRとかARとかで人間の視覚に最適化した更なる端折りの技術が求めらてるのであって、糞重いレイトレとかマジ求められてない
レイトレだと1ピクセルに何本もレイを飛ばしてスーパーサンプルしないとジャギジャギ。ただでさえVRはモニターやテレビに比べてジャギーが異常に目立って開発者が神経を使ってる いきなりレイトレ語りだしてどうしたんだろう
本格的なリアルタイムレイトレを4kで対応するのは無茶なのは誰でも知ってる
ただ、ラスタライズでリアルっぽい描写を人工的に作り出していくのも面倒になってきたから、レイトレでやろうって動きになってるんじゃないかな 現行GPUでもまだラスタライザ部は高速な固定機能回路になってるけど、似たような事をレイトレでやろうとすると、レイトレ対応PowerVRみたいにボクセルのデータ構造が決め打ちのゴミみたいのしか絶対作りえないよね
だからCPUかGPGPUでやるしかない。出来ることってメモリアクセスのパターンを解析して最適化するくらいだろう コントローラーの入力を保存しておいて後でレイトレで高画質化してから鑑賞したら面白そう >>783
ラスタライザだろうがレイトレだろうが、1次レイ衝突地点でどんなシェーダーを走らせるかが肝なのであって、レイトレはそれ自体が非効率で重いから物理的により正確なシェーダーが走らせられるゆとりが少ないよねって話
つまり同じ計算リソース使うならレイトレのが物理的により間違った絵を出す訳ですよ。影の形だけは正しいかもしれないけど。 >>787
ONのがいいかもね
でもそこに膨大な計算リソース使わないで他改善した方がもっといいよね とりあえずEAがシムシティ辺りにレイトレ撮影モードを搭載 計算リソース「は」余ってんだから使えや
TexFillとか帯域要求は削りたいけど 力があるうちに改革して成功したdocomo
改革せずに消えた石炭業 レイトレーシングに対応するのは技術的な話より映画業界からの要請が大きいのではないか
最近はゲームエンジンで作成した映像が映画の一部シーンに採用されたりしているから
映像製作用のシステムに組み込む為に標準的な実装が求められているのでは?
ゲームエンジンで作った映像は影が不自然で使えない場合があるとかで
その場合は(ゲームエンジン側で)簡単にレイトレーシングに切り替えができるようにした方が便利だろう 映画業界は独自に構築済みのエコシステムがあるからDXRなんか対応要求する必要はないだろう
同じ3Dモデルを使ってゲームを作る場合はDXRあったほうが映画のイメージに近づけやすいといったことはあるだろうが 独自のエコシステムがあってもUnreal EngineとかCryEngineが映画で使われてるから、需要はあるんだろ
独自のエコシステムがみんなが使えるものではないだろうし 映画業界もここ10年くらいだけどね、レイトレが普通になったの
それ以前は実写映画のCGでもREYESが席巻してたけど、影の形に文句つける業界人や客なんて聞いた事もないな
映画では昔から普通にレイトレが使われてたという誤解はかれこれ四半世紀くらいあるんじゃないのかね。そういう映画も一部はあると思うけどね、2000年代前半だとFF7のCG映画とか たぶん7じゃない普通のファイナル・ファンタジーの名前を冠した映画のほうかと スクエアの屋台骨を傾かせて海の向こう(アメリカ)のレンダリング屋の技術を向上させたって皮肉られてたはず 今のGPUのアーキテクチャでも霊トレーシングは重い処理なのか
実体ないからかな 「ファイナルファンタジーVII アドベントチルドレン」が2005年の作品だから作成時期は2000年代前半にかかるっちゃかかるか
坂口氏が監督されたファイナルファンタジーは2001年公開で制作自体は1996年後半辺りからみたいだね 無駄な交差判定を減らす為に生成する空間分割データからしてボクセルだし軽い要素がない
一次レイの計算結果はラスタライザと等価。精度が違うだけ(サンプル回数が同じならレイトレが劣る) ゲームをプレイする中でプレイアブルキャラに感情移入していくのを
ゲームを作っている側が「俺には演出能力がある」と誤解してしまったのだろうね
映画。 多種多様な処理を並列に実行することになるからAsync機能の実装が必要になる
Pascalはそれが出来ないから非対応にされた >>804
結局対応しろよと二世代前ぐらいからAMDに急かされたのをやっと対応した形だよな RTXのことか?
tensor coreが無いからだよ RealWorldTech 掲示板で Gabriele Svelto 氏が POWER9 のマニュアルを配布してくれているす。
興味のある方はこちら。
https://www.realworldtech.com/forum/?threadid=176010&curpostid=176010 映画業界で使われてるレイトレはGPGPUレイトレであって、
リアルタイムレイトレでは無い MSのゲーム用レイトレAPIであるDXRはDX12上で使えてRTXはDXRからつかえる そういえば何年か前にPowerVRの会社がリアルタイムレイトレチップを作ってたな CrayがEPYC採用って?
だんごさん今何してるかなぁ 団子大先生はどうして消えんだろうかw
脆弱性の件は団子大先生の意見を是非ともお訊きしたかったがw 逆神団子大予言とか最高に面白かったんだけどな
惜しい人を亡くした
ゴミネオも逆神属性持ちだけど… >>817
812だが(ID変わってるかもしれんが)
俺が見たソースはAsciiの方なんで本家の方は見てないわ
http://ascii.jp/elem/000/001/666/1666900/
何このキン肉マンゼブラ 悉く糞コテ予想と逆の結果になってるし
これでA社のPCに、噂通りAPUが使われたら…
それにしても、次から次へと出てくるIntelの脆弱性と対策にはガッカリ
殆ど泣き寝入りなんだね…酷すぎ Meltdown、Spectre関連
>エンタープライズサーバーEP8000
>AIX
>CPU POWER8/POWER7+/POWER7 影響あり
>スーパーテクニカルサーバSR24000/SR16000
>AIX
>CPU POWER8/POWER7 影響あり
>以下の機種は、影響を受けないため、F/Wの対策適用は不要です。
>・日立アドバンストサーバHA8500(F8,F7,E6,D5)
>・エンタープライズサーバAP7000の全モデル
>・エンタープライズサーバAP8000/AP8800シリーズの全モデル
http://www.hitachi-support.com/alert/ss/HWS18-001/server_host.pdf
>HP-UXについては、本脆弱性の影響はありません。
>XenDesktop / XenAppについては、本脆弱性の影響はありません。
http://www.hitachi-support.com/alert/us/HWS18-001/soft.pdf
HA8500 : Itanium/HP-UX
AP7000 : POWER系/メインフレームOS
AP8000/AP8800 : IBM z系?/メインフレームOS >UNIXサーバ
>いずれの製品もMeltdown(CVE-2017-5754)およびSpectre Variant 2(CVE-2017-5715)の影響はありません。
>Spectre Variant 1(CVE-2017-5753)の対処方法は以下のとおりです。
>・各製品のファームウェアは以下の表に従い、適用してください。
>・Oracle Solaris 11については、対応版SRUを適用してください。
>メインフレーム
>GS21シリーズ(MSP/XSP/AVM)、およびGS周辺装置は、本脆弱性による影響を受けないため、対処は不要です。
>オフコンにおける「投機的実行機能を持つ CPU に対するサイドチャネル攻撃」について
>オフコンでは投機的実行機能を持つ CPU を使用しておりますが、CPUキャッシュ、
>分岐命令、および投機実行処理を用いたサイドチャネル攻撃をするプログラムを
>オフコンOS上では実行できないため、不当にデータを参照されることはありません。
http://www.fujitsu.com/jp/products/software/resources/condition/security/vulnerabilities/2018/jvn-93823979.html >ACOS-2システムへの影響
>ACOS-2 OSではメモリ範囲を越えたアクセスなどの例外を常にチェックしており、
>例外を検出した時点でメモリアクセスの発行を中止し、データキャッシュへは登録しません。
>したがって、悪意のあるプログラムがメモリ内のより高い特権を必要とする領域への
>アクセスを許すような問題は生じませんので、対処は不要です。
>なお、ACOS-2システムでは、I/O制御用の部品としてWindows OSを利用しているため
>今回指摘された脆弱性によりWindows OSが攻撃を受ける可能性はあります。
>ただし、ACOS-2システムでは、Windows OSに対しても独自のセキュリティ対策を実施しており、
>悪意のあるプログラムがシステム上で実行される可能性は非常に低くなっています。
https://jpn.nec.com/security-info/av18-001.html AppleのA12チップはTSMCの7nm採用?
4/24(火) 11:59配信 ITmedia NEWS IA64は死んだんだ
いくら呼んでも帰っては来ないんだ.
もうあの時間は終わって、君も人生と向き合う時なんだ そもそもItaniumはアウトオブオーダーなのか?
Itaniumは正統的なVLIWではないが、アウトオブオーダーはVLIWの考え方と真っ向から反するような気がするが。 >>828
投機的実行というとOoOのイメージだったわ
なるほどやるのか
でも他サイトでも2013年以前にItanium/Atomは除くってなってるから問題ないと思うんだがね。
そっちのソースもどうなのかわからんのでたぶん、としか言えないか。 確か投機もコンパイラである程度組み込んであるんじゃなかったか
あまりにクソ過ぎたので覚えてないけど ただの書き込みで、裏を取ったわけじゃないが
>While Integrity servers have branch prediction and speculation, I've never heard about problems like this.
>Also, HP-UX has separation of user and kernel address spaces.
https://community.hpe.com/t5/System-Administration/Spectre-and-Meltdown-for-Integrity-rx-and-rp-systems/td-p/6993893 teslaをクビになった内部接続屋がintelに行くってさ 散々天才、天才って言ってきたAMDerはホントどうするのか。
もちろんJim Kellerもシリコンバレーの天才の一人ではあるだろうが、それ以上でも以下でもない。
そういう人材を奪い合い、製品開発してビジネスやっていくのは何ら特別な事じゃないし、
今度はこういう風に商売敵に回る事もあるわけだ。 Jim Kellerの名前って一人歩きしてるよな
K8のリードアーキテクトだったのは初期の頃で、アーキテクトが代わった後はK8のプランも変わってるし、
Zenマイクロアーキテクチャを開発したわけでもない
K7でもEV6を手掛けた根っからのバス屋なんだけどねぇ しかしIntelの次世代製品がクソコテの叩きまくったバス構成になったらそっちも笑える。 >>845
今のIntelはそのバスにも課題を抱えてそうなので期待したい ジムやラジャを雇うとかAMD憎しにもほどがあるだろ
彼等が力を発揮できたのは、自由に設計させてくれたAMDだからこそだと思うが
これでIntelがZenモドキやEPYCモドキを出してきたら指差して笑ってやるんだけど Intelも変わったなと言うのが感想だな。
Intel全盛の頃なら、内部生え抜きの層が厚くて
Jim Kellerのような傭兵的な戦力が入る余地などないというイメージだった。 InfinityFabricみたいな内バスが欲しいんだろ
いい加減リングバスとメッシュが電力/面積共にバカにならなくなったんだろ >>849
ちょっと違うかもしれんが、StrongARMは部門ごと買ってるんじゃないかね ■ このスレッドは過去ログ倉庫に格納されています