アカウント名:
パスワード:
CPU購入するならマイクロアーキ更新時?プロセス縮小時?って一時盛り上がったよねー
チク-タク-トー(三拍子)になって旧タク派が2つに分裂するだけかとw
昨日までのプロセス テクノロジは "Tick-Tock" だったが、今日では "Process-Architecture-Optimization" だ
チックタックはプロセスとマイクロアーキテクチャを同時に更新するとリスクが大きいから、という話だったんだけど、GPUが内蔵されるようになってからは、プロセスの更新とGPUの更新がかぶるようになって、本来の意味では崩壊していたんだと思うんだ。
Optimizationが実はGPUの更新だったら、三分割されるんだけど、ここのところGPUの更新は毎世代やっているような印象があるので、どうなることやら。最近はProcessを更新しても性能は上がっていない印象があるので、買うならArchitectureかOptimizationかなあ。特に次のProcessが遅延した場合、Optimizationは最新でいられる期間が長くなるのでいいかも。Optimizationが単にHaswell Refreshみたいにクロックが100MHz上がるだけなら残念だけど。
プロセスの更新とGPUの更新がかぶるようになって、本来の意味では崩壊していたんだと思うんだ。
GPU側はドライバー経由のアクセスなのでそこで対応すればいいっていう割り切りをしていた可能性もありそうとか思う。根拠レス。
QPI経由じゃなくて?
いえ、そういうハードウェア的な接続の話ではなくてソフトウェア的な使用方法の話です。GPU側を使用するためにはアプリケーションからいったんドライバーを経由するので問題があればそこで修正をかけることができるということでおおよそのリスクは吸収できるという発想です。
そう、ある程度ですよね。できないと機能を無効にするしかないわけで(HaswellとBroadwell一部のTSXのように)。しかしGPUはアプリケーションに対してむき出しではなくてドライバー(というプログラム)を経由してのアクセスです。ここで吸収する余地があるわけです。
しかし、GPUだけ電源再投入できるわけでもないでしょう。
すみません。何を言っているのか全く分かりません。
ドライバーで吸収するというのは、GPUで何かあったときに、CPUを動かしたままGPUを止めてCPUだけを動かし続けるということですよね。でも、CPUとGPU間は独立GPUのようにノースブリッジ越しにPCIeで繋がっているわけじゃなくて、CPUの"uncore"とか言われる部分にあってオンダイバスで繋がっていて、メモリコントローラも共有しています(#2986867 [srad.jp])。だからBIOSやドライバで命令を落とすとか対策できるものならCPUと何も変わらないし、できなければCPUごと落ちるしかないでしょう(#2987124 [srad.jp])。GPUはCPUの外にルーズに繋がっているのだから問題が起きる状況をドライバで弾けばいい、というわけにはいかないでしょう。内蔵GPUはルーズに繋がっていないので、ということです。
QPIとかDMIはオンダイグラフィックスじゃ関係ないだろ
じゃあ、Intel CPUのcore-uncore間はどういう方法で繋がってるの?
少しは自分で調べたら?http://www.technic3d.com/article/pics/1826/intel_skylake_optimizations.jpg [technic3d.com]http://cdn.wccftech.com/wp-content/uploads/2015/08/Intel-Core-Processo... [wccftech.com]
私のもともとの書き込みはGPUに不具合が見つかった場合にドライバーでその機能を使わないでAPIの整合性を保つようにするということを思い浮かべていました。microcodeでいじれるCPU以上に柔軟性のある修正ができますよね。若干の不具合はドライバーで吸収できるわけです。
常時上から目線のくせにいざソースを出されたらだんまりを決め込むかこういうのを老害っていうんだよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
チク派 vs. タク派の抗争ついに終結か (スコア:0)
CPU購入するならマイクロアーキ更新時?プロセス縮小時?って一時盛り上がったよねー
Re: (スコア:0)
チク-タク-トー(三拍子)になって旧タク派が2つに分裂するだけかとw
Re: (スコア:1)
昨日までのプロセス テクノロジは "Tick-Tock" だったが、今日では "Process-Architecture-Optimization" だ
Re: (スコア:0)
チックタックはプロセスとマイクロアーキテクチャを同時に更新するとリスクが大きいから、という話だったんだけど、GPUが内蔵されるようになってからは、プロセスの更新とGPUの更新がかぶるようになって、本来の意味では崩壊していたんだと思うんだ。
Optimizationが実はGPUの更新だったら、三分割されるんだけど、ここのところGPUの更新は毎世代やっているような印象があるので、どうなることやら。
最近はProcessを更新しても性能は上がっていない印象があるので、買うならArchitectureかOptimizationかなあ。特に次のProcessが遅延した場合、Optimizationは最新でいられる期間が長くなるのでいいかも。
Optimizationが単にHaswell Refreshみたいにクロックが100MHz上がるだけなら残念だけど。
Re: (スコア:0)
GPU側はドライバー経由のアクセスなのでそこで対応すればいいっていう割り切りをしていた可能性もありそうとか思う。根拠レス。
Re: (スコア:2)
QPI経由じゃなくて?
Re: (スコア:0)
いえ、そういうハードウェア的な接続の話ではなくてソフトウェア的な使用方法の話です。
GPU側を使用するためにはアプリケーションからいったんドライバーを経由するので問題があればそこで修正をかけることができるということでおおよそのリスクは吸収できるという発想です。
Re: (スコア:1)
Re:チク派 vs. タク派の抗争ついに終結か (スコア:0)
そう、ある程度ですよね。
できないと機能を無効にするしかないわけで(HaswellとBroadwell一部のTSXのように)。
しかしGPUはアプリケーションに対してむき出しではなくてドライバー(というプログラム)を経由してのアクセスです。
ここで吸収する余地があるわけです。
Re:チク派 vs. タク派の抗争ついに終結か (スコア:2)
しかし、GPUだけ電源再投入できるわけでもないでしょう。
Re:チク派 vs. タク派の抗争ついに終結か (スコア:1)
Re: (スコア:0)
すみません。
何を言っているのか全く分かりません。
Re:チク派 vs. タク派の抗争ついに終結か (スコア:2)
ドライバーで吸収するというのは、GPUで何かあったときに、CPUを動かしたままGPUを止めてCPUだけを動かし続けるということですよね。
でも、CPUとGPU間は独立GPUのようにノースブリッジ越しにPCIeで繋がっているわけじゃなくて、CPUの"uncore"とか言われる部分にあってオンダイバスで繋がっていて、メモリコントローラも共有しています(#2986867 [srad.jp])。
だからBIOSやドライバで命令を落とすとか対策できるものならCPUと何も変わらないし、できなければCPUごと落ちるしかないでしょう(#2987124 [srad.jp])。
GPUはCPUの外にルーズに繋がっているのだから問題が起きる状況をドライバで弾けばいい、というわけにはいかないでしょう。内蔵GPUはルーズに繋がっていないので、ということです。
Re: (スコア:0)
QPIとかDMIはオンダイグラフィックスじゃ関係ないだろ
Re:チク派 vs. タク派の抗争ついに終結か (スコア:2)
じゃあ、Intel CPUのcore-uncore間はどういう方法で繋がってるの?
Re: (スコア:0)
少しは自分で調べたら?
http://www.technic3d.com/article/pics/1826/intel_skylake_optimizations.jpg [technic3d.com]
http://cdn.wccftech.com/wp-content/uploads/2015/08/Intel-Core-Processo... [wccftech.com]
Re: (スコア:0)
私のもともとの書き込みはGPUに不具合が見つかった場合にドライバーでその機能を使わないでAPIの整合性を保つようにするということを思い浮かべていました。
microcodeでいじれるCPU以上に柔軟性のある修正ができますよね。
若干の不具合はドライバーで吸収できるわけです。
Re: (スコア:0)
常時上から目線のくせにいざソースを出されたらだんまりを決め込むか
こういうのを老害っていうんだよ