ERI Developer's BBS
  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
15 / 57 ツリー ←次へ | 前へ→

GLS3 の 3D 処理能力 L.Entis 02/11/11(月) 22:32
┗ Re:GLS3 の 3D 処理能力 L.Entis 02/11/11(月) 23:07
 ┗ Re:GLS3 の 3D 処理能力 /|/ |/ 02/11/12(火) 19:42
  ┗ Re:GLS3 の 3D 処理能力 L.Entis 02/11/13(水) 0:25

GLS3 の 3D 処理能力
 L.Entis  - 02/11/11(月) 22:32 -

引用なし
パスワード
   現在、GLS3 の 3D グラフィック処理のデバッグを行っているのですが、とりあえず動作するレベルまでたどり着いたため、レンダリング能力の性能を、実走での調査を簡単なものですが行ってみました。
結果、(SSE専用命令使用時)論理的メモリ転送速度の限界速度を超える結果が得られました。
RGB32+Zバッファ32ビットの、1ピクセルあたり8バイトの少なくともライトが必要なわけですが、これの論理的転送速度は、4バイト/FSBクロックです。
ですが、実際のレンダリング処理能力としては、8バイト/FSBクロックに近い数値が得られました(実際にはzバッファのリードも必要であるにもかかわらず)。
半透明処理を行っても、1〜2割程度の処理時間の増加に留まりました。

実験に使用したマシンの FSB は 100MHz ですのが、レンダリング能力として 5000万ピクセル/秒という結果が得られたと言うことです。
Pentium4 以降のより FSB の速いマシンでは、メモリ転送速度がそのままレンダリング能力として簡単に求められそうです。

因みに、ここで言うレンダリング能力というのは、(色・チャネル毎の透明度付のグーロー)シェーディング、Z バッファの計算、および比較、出力先への合成を含めた能力です。
因みに、テクスチャーマッピングを行うと、演算量が増える以上に、メモリ転送量が増大するため、当然、上記速度より遅くなると考えたほうがよいでしょう。

なお、PentiumIII においては、486 互換コードは SSE 専用コードより3倍少々遅かったです(PentiumII での速度に相当すると思われます)。
586 アーキテクチャではさらに 4 倍ほど遅そうです(と言うより、こちらは CPU 自体のクロックに強く影響されると思います)。
<Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0@tokyo-fa2-106.kcom.ne.jp>

Re:GLS3 の 3D 処理能力
 L.Entis  - 02/11/11(月) 23:07 -

引用なし
パスワード
   補足というか、修正

>ですが、実際のレンダリング処理能力としては、8バイト/FSBクロックに近い数値が得られました(実際にはzバッファのリードも必要であるにもかかわらず)。
>半透明処理を行っても、1〜2割程度の処理時間の増加に留まりました。

ウソ。
脳みそが死に掛かってます(汗)。
丁度、4バイト/FSBクロック程度の性能です(しかし、Z バッファのリードも含まれていますので、論理的限界を超えていることには間違いは無いか…(汗))。
サンプルに使用しているモデルの、延べ塗りつぶし面積からレンダリング性能を計測しています。
FSB 100MHz で、5000 万ピクセル/秒ですから、4 バイト(0.5 ピクセル)/FSB クロックですね。

>なお、PentiumIII においては、486 互換コードは SSE 専用コードより3倍少々遅ったです(PentiumII での速度に相当すると思われます)。

486 互換コードでは、基本的に、CPU クロックに依存する実際の処理時間+メモリ転送時間が、トータルのレンダリング時間となります。
SSE 専用コードでは、メモリ転送をバックグラウンドで行うことができるため、計算をメモリの転送とオーバーラップして行うことができるので、ほとんどメモリ転送速度に依存しますね。

>586 アーキテクチャではさらに 4 倍ほど遅そうです(と言うより、こちらは CPU 自体のクロックに強く影響されると思います)。

さらに 4 倍と言うか、同じ CPU クロックで SSE 専用命令より 4 倍以上って感じでしょうか?(わかりにくい説明だ)
普通、Pentium は、200MHz 以下なので、だいぶ遅いですね。(^^;
<Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0@tokyo-fa2-106.kcom.ne.jp>

Re:GLS3 の 3D 処理能力
 /|/ |/  - 02/11/12(火) 19:42 -

引用なし
パスワード
   ▼L.Entisさん:

SSEはトータルのレジスタサイズが大きいので、
うまく組めば、計算の間メモリアクセス無しの、
オンレジスタで処理できますよね。
そうすると、メモリアクセスを
計算処理にかかる時間で隠蔽しやすくなるので、
メモリアクセスがボトルネックになりますよね。
計算が複雑であれば複雑であるほど、そうなりますね。
#複雑というか、同じデータに対する演算回数が多い=計算式が長い場合かな。

Itaniumなんかだと、あれだけレジスタがあれば、
本当にほとんどのルーチンを
オンレジスタでやれちゃいそうですね。
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)@m173150.ap.plala.or.jp>

Re:GLS3 の 3D 処理能力
 L.Entis  - 02/11/13(水) 0:25 -

引用なし
パスワード
   >SSEはトータルのレジスタサイズが大きいので、
>うまく組めば、計算の間メモリアクセス無しの、
>オンレジスタで処理できますよね。
>そうすると、メモリアクセスを
>計算処理にかかる時間で隠蔽しやすくなるので、
>メモリアクセスがボトルネックになりますよね。
>計算が複雑であれば複雑であるほど、そうなりますね。
>#複雑というか、同じデータに対する演算回数が多い=計算式が長い場合かな。

 3x3の行列計算なんかはかなり典型的な例なので SSE で書きやすいですが、非一時ストア命令とプリフェッチ命令を組み合わせて上手く書けば、memmove より高速に、ベクトルの配列を変換しつつ転送できますネ。
 メモリ転送関数と、座標変換関数を以前にテストしたのですが、通常の memmove だと、2 Byte Read+Write / FSB clock であるのに対し(理屈通り;586 では 1.5 程度になると思います)、SSE 専用命令による転送では、3 Byte Read+Write / FSB clock です(1 FSB clock で 48 bit 転送できている計算です)。
 一方、SSE 命令による座標変換を伴う転送では、まったく同じ、3 Byte Read+Write / FSB clock に相当する処理能力となりました。
 因みに、FPU 命令では、1.17 Byte Read+Write / FSB clock に相当する処理能力でしたが、Pentium4 で実行したところ、memmove とまったく同じ 2 Byte Read+Write / FSB clock の結果が出てきました。

>Itaniumなんかだと、あれだけレジスタがあれば、
>本当にほとんどのルーチンを
>オンレジスタでやれちゃいそうですね。

 私の知識では、Itanium のアーキテクチャでは、汎用レジスタは 31 本で(32本あって、1つはゼロ固定だった気が)、それ以降の 127 番目までのレジスタはスタックレジスタで、実際のメモリ上のスタックを投影したようなノリの使い方になっていた気がします。
 しかし、Itanium のアセンブリは結構アツイので、いつかは実際に触ってみたいところです。
 今現在は、SSE2 の方が興味を引いておりますが。
<Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0@tokyo-fa1-164.kcom.ne.jp>

  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
15 / 57 ツリー ←次へ | 前へ→
ページ:  ┃  記事番号:
7920 C-BOARD v3.02 is not Free?