アカウント名:
パスワード:
GPUで処理が早くなるというのは妄想です。1、CPU→GPUの距離が遠い。2、GPUからメモリにアクセスできない。3、GPUで条件分岐など命令が乏しい。3、GPUが使える粒度の小さい並行処理は多いわけではない。4、画像の合成などはCPUで処理したほうが速い。GPUに行って戻すのに時間がかかる。5、GPUはフォント処理ができない。結局、CPUのお世話になる処理が多い。6、HTMLは木構造。GPUに適していない。
うれしいこと1、CPU時間を食わないので、タスクマネージャをずっと見ている人には精神衛生上良い。2、GPUの発熱で暖かくなる。3、新しいパーツを買う理由になる。
普通に画面描画だけさせるだけですって。画面描画が速くならないんなら、何で高級なGPUが存在するのさ?
GPUで効率的に高速化が可能なパターンを考えてみると、 長大な買い物リストを渡して買出しに行ってもらうような感じになるんですかね。 品薄や終息商品になって買えない品があると、いちいち電話で呼び出して対応を 確認しなくてはいけなくなるので、事前の段取りが重要ってことになります。
GPUレンダリングでも、レイアウトで文字がはみ出さずに表示可能かといった 判断は事前の段取りとしてCPUが計算する必要がありそうです。 また、文字のスムージング等も、CPUなら線で処理するアルゴリズムを使えたのが GPUでは面で処理するアルゴリズムになって計算量と発熱が増える可能性があります。 大画面化で面積が増えると2乗のオーダで全体の処理量が増えるものの、 個々のパーツは小さいままなので細かな条件判断の量が増えているともいえます。
ってことで、元コメの発言も一理あるような気がしますが。
CPUをソフトウェアで動かして線のアルゴリズムで処理するより、GPUのハードウェアで動かして面で処理するほうが、圧倒的に早いし省エネです。
「パース」と「レンダリング」はまったく別の処理です。いままで両方CPUでやってましたが、今後は前者をCPUに、後者をGPUに分担しましょうという話ですから、早くならないわけがありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
GPUで速くならない (スコア:1)
GPUで処理が早くなるというのは妄想です。
1、CPU→GPUの距離が遠い。
2、GPUからメモリにアクセスできない。
3、GPUで条件分岐など命令が乏しい。
3、GPUが使える粒度の小さい並行処理は多いわけではない。
4、画像の合成などはCPUで処理したほうが速い。GPUに行って戻すのに時間がかかる。
5、GPUはフォント処理ができない。結局、CPUのお世話になる処理が多い。
6、HTMLは木構造。GPUに適していない。
うれしいこと
1、CPU時間を食わないので、タスクマネージャをずっと見ている人には精神衛生上良い。
2、GPUの発熱で暖かくなる。
3、新しいパーツを買う理由になる。
Re:GPUで速くならない (スコア:0)
普通に画面描画だけさせるだけですって。
画面描画が速くならないんなら、何で高級なGPUが存在するのさ?
Re: (スコア:0)
GPUで効率的に高速化が可能なパターンを考えてみると、
長大な買い物リストを渡して買出しに行ってもらうような感じになるんですかね。
品薄や終息商品になって買えない品があると、いちいち電話で呼び出して対応を
確認しなくてはいけなくなるので、事前の段取りが重要ってことになります。
GPUレンダリングでも、レイアウトで文字がはみ出さずに表示可能かといった
判断は事前の段取りとしてCPUが計算する必要がありそうです。
また、文字のスムージング等も、CPUなら線で処理するアルゴリズムを使えたのが
GPUでは面で処理するアルゴリズムになって計算量と発熱が増える可能性があります。
大画面化で面積が増えると2乗のオーダで全体の処理量が増えるものの、
個々のパーツは小さいままなので細かな条件判断の量が増えているともいえます。
ってことで、元コメの発言も一理あるような気がしますが。
Re: (スコア:0)
CPUをソフトウェアで動かして線のアルゴリズムで処理するより、
GPUのハードウェアで動かして面で処理するほうが、圧倒的に早いし省エネです。
「パース」と「レンダリング」はまったく別の処理です。
いままで両方CPUでやってましたが、
今後は前者をCPUに、後者をGPUに分担しましょうという話ですから、
早くならないわけがありません。