x86 の SSE/AVX 命令に対応しました。
ARM CPU と同じように SSE/AVX の命令速度を計測することができます。
・VFP Benchmark v1.1
・VFP Benchmark Android (Google play)
・VFP Benchmark iOS (AppStore)
上記は Android ですが iOS 版では ARMv8A (arm64) に対応しています。(2014/02/05 iOS 版追加)
下記は手持ちのデバイスでの結果。
ピーク値の測定なので実アプリケーションの速度とは異なります。
詳しくはこちらを参照してください。
下記のページのほぼ理論値通りの傾向が出ています。
・CPU FLOPS 理論値
倍精度のテストはまだ改良の余地があります。
スカラーで mul+add のペアリングを測定していないので、
一部の CPU でもう少しスコアが伸びると考えられます。
Core i5 Ivy Bridge は想定より高い数値が出ていますが、TurboBoost の効果で
より高いクロックで走っているようです。single-thread 時は 3.0GHz、
mult-thread 時は 2.85GHz 相当の結果となっています。
実際の測定結果は命令単位の数値を出すので、より細かく CPU の動作を
調べることができます。
SSE2/AVX1 には積和命令がありませんが、Intel CPU は加算と乗算命令が
並列に実行できるようです。
↓ 実際に addps/mulps の Interleave は半分の時間で実行しています。
↓ Atom (Bonnell) は場合少々特殊です。
SSE 命令の乗算は加算よりも 2倍時間がかかっています。
動作クロックを考えると SSE の add が 128bit で mul が 64bit 幅で
演算していると考えられます。
ARM NEON の場合は、同じ SIMD でも 64bit 命令があります。
例えば「 vadd.f32 d0,d1,d2 」は単精度 32bit x2 の 64bit 加算を行うので、
Cortex-A8/A9 のように 64bit 幅でも 1cycle で実行します。
128bit 命令「 vadd.f32 q0,q1,q1 」の場合は 2cycle かかります。
SSE は常に 4要素 = 128bit 単位なので Pentium 3 等 64bit 幅の
SIMD Unit では最小でも 2cycle かかることになります。
同様に Atom の乗算も最小値は 2cycle です。
ただし mulps + addps の Interleave でも、addps のみの場合と同じ時間で
完了するため、加算と乗算は非対称ながら Overlap できるようです。
Atom には HT があるので、Multi-thread 時は無駄な隙間を埋められます。
メインスレッドで mulps + addps のペアを実行し、サブスレッドで addps のみ
走らせるとおそらく 128bit + 64bit の非対称なパイプラインが埋まります。
mulps + addps + addps 組み合わせを 2スレッド走らせたのが下記の結果で、
スコアが伸びていることがわかります。
これらの測定結果から、CPU の個別の演算能力をまとめたのが下記の表です。
倍精度の値はもう少し変動する可能性があります。
・スカラー
ARM11 の mul は 0.5演算/cycle となっています。
つまり単精度の加算や乗算は 2cycle かかります。
mad/fma は命令あたり 2 演算なので、この欄が 2 の場合に 1 cycle で
実行できることを意味しています。
Cortex-A8 のピーク FLOPS は NEON のおかげで ARM11 より高いですが、
上記のように VFP のスカラー演算では ARM11 に負けています。
A7 Cyclone (ARMv8A) は AArch32 (32bit mode) と AArch64 (64bit mode) で
かなり違いがあります。
単精度演算は 64bit mode の方が数倍速く実行できるようです。
おそらく VFP が要求する仕様が NEON と異なっているためだと考えられます。
AArch64 は NEON と統一されたので、NEON と同等の速度で動作できるようです。
VFP が足を引っ張る似たような傾向は、Cortex-A15 など他の ARMv7A CPU にも
見られます。
・SIMD 単精度
Cortex-A8/A9 は 64bit 幅なので、SIMD2 では Scorpion/Krait/Swift と
差がありません。
SIMD4 では 128bit の Scorpion/Krait/Swift の半分であることがわかります。
ユニークなのは Cortex-A15 で、SIMD4 では同じ 128bit の
Scorpion/Krait/Swift と同等ですが SIMD2 では 2倍の数値となっています。
Cortex-A15 は 64bit 幅 2 pipe なので、2命令同時実行できるためです。
スカラーでは単精度でも 1命令/cycle だったので、半分しか使わなくても
NEON の方が速いことになります。
Ivy Bridge は AVX に対応しているので、上の表では省略していますが SIMD8
があります。下記のページに SIMD8 や倍精度 SIMD 含めて表にまとめています。
・CPU FLOPS : FPU
一番最初の GFLOPS のリストでは、Quad core かつ動作クロックの高い
Snapdragon 800 (MSM8974) が上位でした。
CPU の cycle 単位の命令数を出してみると、唯一の ARMv8 CPU でもある
A7 Cyclone が群を抜いて高性能であることがわかります。
計測結果から、mul, mad/fma で 2命令、add では 3命令を同時に実行できるようです。
NEON の場合は AArch32 と AArch64 特に違いはありませんでした。
A7 Cyclone の設計は DEC Alpha や StrongARM に由来するエンジニアが
関わっているとのこと。(Wikipedia P.A.Semi)
Benchmark はあくまで浮動小数点演算能力のピーク値を実測することが目的なので、
必ずしも総合的な優劣には一致しないことを予めご了承ください。
関連エントリ
・ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
・iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
・Nexus 10 CPU Cortex-A15 の速度
・Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
・Qualcomm APQ8064 GPU Adreno 320 の速度
・Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・benchmark 関連
ARM CPU と同じように SSE/AVX の命令速度を計測することができます。
・VFP Benchmark v1.1
・VFP Benchmark Android (Google play)
・VFP Benchmark iOS (AppStore)
下記は手持ちのデバイスでの結果。
Device CPU sp GFLOPS dp GFLOPS --------------------------------------------------------------------- MacBookRetina13 Core i5-3210M Ivy 2.5GHz x2 90.2 45.2 Kindle HDX 7 MSN8974 Krait 400 2.2GHz x4 67.5 16.9 Tegra Note 7 Tegra4 Cortex-A15 1.8GHz x4 51.3 9.8 Nexus 7 (2013) AQP8064 Krait 1.5GHz x4 47.8 11.8 iPhone 5s A7 arm64 Cyclone 1.3GHz x2 40.9 20.5 iPhone 5s A7 arm7s Cyclone 1.3GHz x2 40.9 8.0 Mac mini 2009 Core2 Duo P7350 2.0GHz x2 31.7 12.7 Nexus 10 Exynos5D Cortex-A15 1.7GHz x2 26.7 5.3 iPad 4 A6X Swift 1.4GHz x2 21.5 3.6 iPhone 5 A6 Swift 1.3GHz x2 20.1 3.4 Nexus 7 (2012) Tegra3 Cortex-A9 1.3GHz x4 18.9 4.7 EVO 3D ISW12HT MSM8660 Scorpion 1.2GHz x2 16.6 1.3 VAIO Type P Atom Z540 Bonnell 1.8GHz x1 10.9 1.9 Desire X06HT QSD8250 Scorpion 1.0GHz x1 7.1 0.9 iPad 2 A5 Cortex-A9 1.0GHz x2 7.8 2.0 iPod touch 4 A4 Cortex-A8 0.8GHz x1 3.1 0.1 Raspberry Pi BCM2835 ARM1176JZFS 0.7GHz x1 0.7 0.7 * 数値が大きい方が速い。 * sp= 単精度, dp= 倍精度
ピーク値の測定なので実アプリケーションの速度とは異なります。
詳しくはこちらを参照してください。
下記のページのほぼ理論値通りの傾向が出ています。
・CPU FLOPS 理論値
倍精度のテストはまだ改良の余地があります。
スカラーで mul+add のペアリングを測定していないので、
一部の CPU でもう少しスコアが伸びると考えられます。
Core i5 Ivy Bridge は想定より高い数値が出ていますが、TurboBoost の効果で
より高いクロックで走っているようです。single-thread 時は 3.0GHz、
mult-thread 時は 2.85GHz 相当の結果となっています。
実際の測定結果は命令単位の数値を出すので、より細かく CPU の動作を
調べることができます。
SSE2/AVX1 には積和命令がありませんが、Intel CPU は加算と乗算命令が
並列に実行できるようです。
↓ 実際に addps/mulps の Interleave は半分の時間で実行しています。
Ivy Bridge Core i5-3210M * SSE/AVX (single fp) sec MFLOPS MFLOPS AVX vmulps (32bit x8) n8 : 1.322 24205.7 24205.7 AVX vaddps (32bit x8) n8 : 1.319 24256.0 24256.0 AVX vmul+addps (32bit x8) n8 : 0.658 48604.4 48604.4
↓ Atom (Bonnell) は場合少々特殊です。
SSE 命令の乗算は加算よりも 2倍時間がかかっています。
動作クロックを考えると SSE の add が 128bit で mul が 64bit 幅で
演算していると考えられます。
Atom Z540 (Bonnell) * SSE/AVX (single fp) sec MFLOPS MFLOPS SSE mulps (32bit x4) n8 : 4.307 3715.2 3715.2 SSE addps (32bit x4) n8 : 2.207 7248.1 7248.1 SSE mul+addps (32bit x4) n8 : 2.155 7424.2 7424.2
ARM NEON の場合は、同じ SIMD でも 64bit 命令があります。
例えば「 vadd.f32 d0,d1,d2 」は単精度 32bit x2 の 64bit 加算を行うので、
Cortex-A8/A9 のように 64bit 幅でも 1cycle で実行します。
128bit 命令「 vadd.f32 q0,q1,q1 」の場合は 2cycle かかります。
SSE は常に 4要素 = 128bit 単位なので Pentium 3 等 64bit 幅の
SIMD Unit では最小でも 2cycle かかることになります。
同様に Atom の乗算も最小値は 2cycle です。
ただし mulps + addps の Interleave でも、addps のみの場合と同じ時間で
完了するため、加算と乗算は非対称ながら Overlap できるようです。
Atom には HT があるので、Multi-thread 時は無駄な隙間を埋められます。
メインスレッドで mulps + addps のペアを実行し、サブスレッドで addps のみ
走らせるとおそらく 128bit + 64bit の非対称なパイプラインが埋まります。
mulps + addps + addps 組み合わせを 2スレッド走らせたのが下記の結果で、
スコアが伸びていることがわかります。
Atom Z540 (Bonnell) * SSE/AVX (single fp) multi-thread sec MFLOPS MFLOPS SSE ml+ad+addps (32bit x4) n6 : 3.075 10926.6 10926.6
これらの測定結果から、CPU の個別の演算能力をまとめたのが下記の表です。
倍精度の値はもう少し変動する可能性があります。
・スカラー
単精度 倍精度
CPU mul add mad fma mul add mad fma
----------------------------------------- -------------------------
ARM1176JZF-S 0.5 0.5 1 -- 0.5 0.5 1 --
Cortex-A8 0.14 0.14 0.18 -- 0.1 0.1 0.1 --
Cortex-A9 1 1 2 -- 0.5 1 1 --
Cortex-A15 1 1 1.4 2 1 1 1.4 1.4
Scorpion 1 1 2 -- 0.5 1 1 --
Krait 400 1 1 2 2 1 1 1.6 2
A6 Swift 1 1 1 1 1 1 1 1
A7 Cyclone arm7s 1 1 2 2 2 3 3 3
A7 Cyclone arm64 2 3 -- 4 2 3 -- 1.6
Atom Bonnell 1 1 -- -- 0.5 1 -- --
Core2 Penryn 1 1 -- -- 1 1 -- --
Core i5 Ivy Bridge 1 1 -- -- 1 1 -- --
* 数値は 1 cycle に実行可能な演算数
* 値が大きい方が高速
ARM11 の mul は 0.5演算/cycle となっています。
つまり単精度の加算や乗算は 2cycle かかります。
mad/fma は命令あたり 2 演算なので、この欄が 2 の場合に 1 cycle で
実行できることを意味しています。
Cortex-A8 のピーク FLOPS は NEON のおかげで ARM11 より高いですが、
上記のように VFP のスカラー演算では ARM11 に負けています。
A7 Cyclone (ARMv8A) は AArch32 (32bit mode) と AArch64 (64bit mode) で
かなり違いがあります。
単精度演算は 64bit mode の方が数倍速く実行できるようです。
おそらく VFP が要求する仕様が NEON と異なっているためだと考えられます。
AArch64 は NEON と統一されたので、NEON と同等の速度で動作できるようです。
VFP が足を引っ張る似たような傾向は、Cortex-A15 など他の ARMv7A CPU にも
見られます。
・SIMD 単精度
SIMD2 (32bit x 2) SIMD4 (32bit x4)
CPU mul add mad fma mul add mad fma
---------------------------------------- ----------------------
ARM1176JZF-S -- -- -- -- -- -- -- --
Cortex-A8 2 2 4 -- 2 2 4 --
Cortex-A9 2 2 4 -- 2 2 4 --
Cortex-A15 4 4 8 8 4 4 8 8
Scorpion 2 2 4 -- 4 4 8 --
Krait 400 2 2 4 4 4 4 8 8
A6 Swift 2 2 4 4 4 4 8 8
A7 Cyclone arm7s 4 6 8 8 8 12 16 16
A7 Cyclone arm64 4 6 -- 8 8 12 -- 16
Atom Bonnell -- -- -- -- 2 4 (6) --
Core2 Penryn -- -- -- -- 4 4 (8) --
Core i5 Ivy Bridge -- -- -- -- 4 4 (8) --
Cortex-A8/A9 は 64bit 幅なので、SIMD2 では Scorpion/Krait/Swift と
差がありません。
SIMD4 では 128bit の Scorpion/Krait/Swift の半分であることがわかります。
ユニークなのは Cortex-A15 で、SIMD4 では同じ 128bit の
Scorpion/Krait/Swift と同等ですが SIMD2 では 2倍の数値となっています。
Cortex-A15 は 64bit 幅 2 pipe なので、2命令同時実行できるためです。
スカラーでは単精度でも 1命令/cycle だったので、半分しか使わなくても
NEON の方が速いことになります。
Ivy Bridge は AVX に対応しているので、上の表では省略していますが SIMD8
があります。下記のページに SIMD8 や倍精度 SIMD 含めて表にまとめています。
・CPU FLOPS : FPU
一番最初の GFLOPS のリストでは、Quad core かつ動作クロックの高い
Snapdragon 800 (MSM8974) が上位でした。
CPU の cycle 単位の命令数を出してみると、唯一の ARMv8 CPU でもある
A7 Cyclone が群を抜いて高性能であることがわかります。
計測結果から、mul, mad/fma で 2命令、add では 3命令を同時に実行できるようです。
NEON の場合は AArch32 と AArch64 特に違いはありませんでした。
A7 Cyclone の設計は DEC Alpha や StrongARM に由来するエンジニアが
関わっているとのこと。(Wikipedia P.A.Semi)
Benchmark はあくまで浮動小数点演算能力のピーク値を実測することが目的なので、
必ずしも総合的な優劣には一致しないことを予めご了承ください。
関連エントリ
・ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
・iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
・Nexus 10 CPU Cortex-A15 の速度
・Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
・Qualcomm APQ8064 GPU Adreno 320 の速度
・Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・benchmark 関連
2014/01/19
ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測
今まで ARM CPU の浮動小数点演算速度について調べてきましたが、
その計測プログラムをアプリにしてみました。
・VFP Benchmark (Android)
今までの測定結果のまとめは下記の通り。
・ARM CPU core 毎の浮動小数点演算速度の比較 (VFP/NEON)
VFP Benchmark アプリの表示結果は上記の表と互換性があります。
さらに FLOPS 表示、倍精度浮動小数点演算の計測、マルチスレッド実行に
対応しました。
下記は幾つかの端末の結果(一部)です。
比較的理論値に近い数値が出ています。
各 CPU の理論値は下記にまとめました。
・CPU FLOPS
この出力結果はあくまでピーク値による比較なので、
実際のアプリケーションの実行速度とは異なります。
例えばスカラ VFP 演算で n8 と n1 の結果を比べると、
Cortex-A9 では命令の並び順によって 5倍も速度が落ちるケースがあります。
同じ条件でも Krait / Cortex-A15 はほとんど速度が落ちていないので、
パイプラインの実行効率が向上していることがわかります。
よって実際のアプリケーションでは、Cortex-A9 と Krait/Cortex-A15 では
ピーク値よりもさらに差が開くことが予想されます。
multi-thread は同じテストを CPU core の数だけ走らせています。
Tegra 3 のように single thread 時に動作クロックが上がるものがあるので、
single-thread の値を core 数倍しても正しい値にならないためです。
アプリの出力結果を見ると、Cortex-A15 は VFP のスカラ演算よりも
NEON の 64bit (float x2) の方が 2倍速く実行できることがわかります。
以前予想したようにおそらく NEON の演算 unit は 64bit の 2 pipe ですが、
VFP は 1命令しか実行できない可能性があります。
Cortex-A8 で行ったように、VFP 命令を NEON 演算に置換する
Cortex-A15 最適化ができるかもしれません。
関連エントリ
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
・iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
・Nexus 10 CPU Cortex-A15 の速度
・Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
・Qualcomm APQ8064 GPU Adreno 320 の速度
・Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
・iPad 4/iPad mini A6X/A5 の CPU/GPU 速度
・iPhone 5 / A6 の CPU 速度 その 3
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・benchmark 関連
その計測プログラムをアプリにしてみました。
・VFP Benchmark (Android)
今までの測定結果のまとめは下記の通り。
・ARM CPU core 毎の浮動小数点演算速度の比較 (VFP/NEON)
VFP Benchmark アプリの表示結果は上記の表と互換性があります。
さらに FLOPS 表示、倍精度浮動小数点演算の計測、マルチスレッド実行に
対応しました。
下記は幾つかの端末の結果(一部)です。
MSN8974 Krait 400 2.2GHz x4 quad
---------------------------------------
SingleT SP max : 16.619 GFLOPS
MultiT SP max : 67.185 GFLOPS (理論値: 70.4 GFLOPS)
= 2(mad) x 4(simd) x 4(core) x 2.2(clock)
Tegra4 Cortex-A15 1.8GHz x4 quad
---------------------------------------
SingleT SP max: 13.371 GFLOPS
MultiT SP max: 51.345 GFLOPS (理論値: 57.6 GFLOPS)
= 2(mad) x 2(simd) x 2(unit) x 4(core) x 1.8(clock)
APQ8064 Krait 1.5GHz x4 quad
---------------------------------------
SingleT SP max: 11.947 GFLOPS
MultiT SP max: 47.808 GFLOPS (理論値: 48.0 GFLOPS)
= 2(mad) x 4(simd) x 4(core) x 1.5(clock)
Exynos5D Cortex-A15 1.7GHz x2 dual
---------------------------------------
SingleT SP max: 13.483 GFLOPS
MultiT SP max: 26.724 GFLOPS (理論値: 27.2 GFLOPS)
= 2(mad) x 2(simd) x 2(unit) x 2(core) x 1.7(clock)
Tegra3 Cortex-A9 1.2GHz x4 quad (TB1.3GHz)
---------------------------------------
SingleT SP max: 4.783 GFLOPS (理論値: 5.2 GFLOPS
MultiT SP max: 18.905 GFLOPS (理論値: 19.2 GFLOPS)
= 2(mad) x 2(simd) x 4(core) x 1.2(clock)
K3V2 Cortex-A9 1.2GHz x4 quad
---------------------------------------
SingleT SP max: 4.694 GFLOPS
MultiT SP max: 18.662 GFLOPS (理論値: 19.2 GFLOPS)
= 2(mad) x 2(simd) x 4(core) x 1.2(clock)
MSN8260 Scorpion 1.2GHz x2 dual
---------------------------------------
SingleT SP max: 8.898 GFLOPS
MultiT SP max: 16.560 GFLOPS (理論値: 19.2 GFLOPS)
= 2(mad) x 4(simd) x 2(core) x 1.2(clock)
QSD8250 Scorpion 1.0GHz x1
---------------------------------------
SingleT SP max: 7.098 GFLOPS (理論値: 8.0 GFLOPS)
= 2(mad) x 4(simd) x 1.0(clock)
Tegra 2 Cortex-A9 1.0GHz x2 dual
---------------------------------------
SingleT SP max: 1.973 GFLOPS
MultiT SP max: 3.913 GFLOPS (理論値: 4.0 GFLOPS)
= 2(mad) x 2(core) x 1.0(clock)
比較的理論値に近い数値が出ています。
各 CPU の理論値は下記にまとめました。
・CPU FLOPS
この出力結果はあくまでピーク値による比較なので、
実際のアプリケーションの実行速度とは異なります。
例えばスカラ VFP 演算で n8 と n1 の結果を比べると、
Cortex-A9 では命令の並び順によって 5倍も速度が落ちるケースがあります。
同じ条件でも Krait / Cortex-A15 はほとんど速度が落ちていないので、
パイプラインの実行効率が向上していることがわかります。
よって実際のアプリケーションでは、Cortex-A9 と Krait/Cortex-A15 では
ピーク値よりもさらに差が開くことが予想されます。
multi-thread は同じテストを CPU core の数だけ走らせています。
Tegra 3 のように single thread 時に動作クロックが上がるものがあるので、
single-thread の値を core 数倍しても正しい値にならないためです。
アプリの出力結果を見ると、Cortex-A15 は VFP のスカラ演算よりも
NEON の 64bit (float x2) の方が 2倍速く実行できることがわかります。
// Exynos 5 Dual Cortex-A15 1.7GHz dual (Nexus 10) * VFP/NEON (single fp) sec MFLOPS 最大 ---------------------------------------------------- VFP fmuls (32bit x1) n8 : 2.675 1495.4 1555.9 VFP fadds (32bit x1) n8 : 2.392 1672.1 1672.1 VFP fmacs (32bit x1) n8 : 3.171 2523.2 2523.2 VFP vfma.f32 (32bit x1) n8 : 2.985 2679.9 2679.9 NEON vmul.f32 (32bit x2) n8 : 1.187 6740.5 6740.5 ** NEON vadd.f32 (32bit x2) n8 : 1.187 6740.7 6740.7 ** NEON vmla.f32 (32bit x2) n8 : 1.187 13480.8 13480.8 ** NEON vfma.f32 (32bit x2) n8 : 1.187 13480.3 13480.3 ** NEON vmul.f32 (32bit x4) n8 : 2.373 6741.8 6741.8 NEON vadd.f32 (32bit x4) n8 : 2.374 6740.7 6740.7 NEON vmla.f32 (32bit x4) n8 : 2.373 13482.7 13482.7 NEON vfma.f32 (32bit x4) n8 : 2.373 13482.3 13482.3
以前予想したようにおそらく NEON の演算 unit は 64bit の 2 pipe ですが、
VFP は 1命令しか実行できない可能性があります。
Cortex-A8 で行ったように、VFP 命令を NEON 演算に置換する
Cortex-A15 最適化ができるかもしれません。
関連エントリ
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
・iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
・Nexus 10 CPU Cortex-A15 の速度
・Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
・Qualcomm APQ8064 GPU Adreno 320 の速度
・Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
・iPad 4/iPad mini A6X/A5 の CPU/GPU 速度
・iPhone 5 / A6 の CPU 速度 その 3
・ARM Cortex-A8 の NEON と浮動小数演算最適化
・benchmark 関連
・Android Adreno 320 OpenGL ES 3.0 (Nexus 7 2013)
・Android Adreno 320 OpenGL ES 2.0 (HTC J butterfly HTL21 )
・Android Mali-T604 OpenGL ES 3.0 (Nexus 10 2012)
・Android Tegra 4 ULP GeForce(72) OpenGL ES 2.0 (Tegra Note 7)
・Android Tegra 3 ULP GeForce(12) OpenGL ES 2.0 (Nexus 7 2012)
・iOS7 PowerVR SGX543MP3 OpenGL ES 2.0 (iPhone 5)
・iOS7 PowerVR G6430 OpenGL ES 3.0 (iPhone 5s)
・RK3066 Mali-400MP4 OpenGL ES 2.0 (MOMO7)
・Vivante GC4000 OpenGL ES 2.0 (dtab 01)
OpenGL ES 2.0 デバイスの大半は GL_OES_depth_texture だけに対応しており
フィルタはかかりません。
depth_texture が無い Tegra2/3 は ColorBuffer で代用しています。
Tegra 4 は OpenGL ES 2.0 ですが Extension で GL_EXT_shadow_samplers に
対応しておりハードウエアで sampling できるようになっています。
同じように iOS の PowerVR Series5XT も OpenGL ES 2.0 ながら早くから
GL_EXT_shadow_samplers に対応していました。
iOS5/6 の当初は PCF もなく見た目が全く変わらなかったのですが、
iOS7 ではいつの間にかフィルタがかかるようになっていました。
なお同じ PowerVR Series5XT の GPU でも Android では残念ながら
shadow_samplers が使えない場合が多いです。
OpenGL ES 3.0 以降は PC 同様そのまま shadow samplers が使えます。
ただし結果は GPU やドライバによってかなり差があるようで、
Adreno 320 や PowerVR G6430 が 4 tap PCF のみ。
逆に Mali-T604 のフィルタは他より質が高くなっています。
Tegra 2 → Tegra 3 は core 数(速度) が違うだけで機能は全く同一でした。
対して Tegra 4 の GPU は、Tegra2/3 と比べると大幅に拡張されています。
機能面で見ればほぼ別 GPU といえるほど差があるのですが、
OpenGL ES 3.0 未対応など先行する他 GPU より見劣りする部分もあります。
DX9 世代の G70 ベースの限界なのか、それとも単に Tegra2/3 で
削っていた能力を元に戻しただけなのかもしれません。
一般的に NVIDIA に期待するイメージは強力な GPU でしょう。
ですがこれまでの Tegra は真逆で CPU に偏重した作りでした。
次の Tegra K1 以降はようやく NVIDIA らしい GPU になりそうです。
関連エントリ
・OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度
・Android Adreno 320 OpenGL ES 2.0 (HTC J butterfly HTL21 )
・Android Mali-T604 OpenGL ES 3.0 (Nexus 10 2012)
・Android Tegra 4 ULP GeForce(72) OpenGL ES 2.0 (Tegra Note 7)
・Android Tegra 3 ULP GeForce(12) OpenGL ES 2.0 (Nexus 7 2012)
・iOS7 PowerVR SGX543MP3 OpenGL ES 2.0 (iPhone 5)
・iOS7 PowerVR G6430 OpenGL ES 3.0 (iPhone 5s)
・RK3066 Mali-400MP4 OpenGL ES 2.0 (MOMO7)
・Vivante GC4000 OpenGL ES 2.0 (dtab 01)
OpenGL ES 2.0 デバイスの大半は GL_OES_depth_texture だけに対応しており
フィルタはかかりません。
depth_texture が無い Tegra2/3 は ColorBuffer で代用しています。
Tegra 4 は OpenGL ES 2.0 ですが Extension で GL_EXT_shadow_samplers に
対応しておりハードウエアで sampling できるようになっています。
同じように iOS の PowerVR Series5XT も OpenGL ES 2.0 ながら早くから
GL_EXT_shadow_samplers に対応していました。
iOS5/6 の当初は PCF もなく見た目が全く変わらなかったのですが、
iOS7 ではいつの間にかフィルタがかかるようになっていました。
なお同じ PowerVR Series5XT の GPU でも Android では残念ながら
shadow_samplers が使えない場合が多いです。
OpenGL ES 3.0 以降は PC 同様そのまま shadow samplers が使えます。
ただし結果は GPU やドライバによってかなり差があるようで、
Adreno 320 や PowerVR G6430 が 4 tap PCF のみ。
逆に Mali-T604 のフィルタは他より質が高くなっています。
OS OpenGL depth-tex sh-sample PCF Linear
-----------------------------------------------------------------
APQ8064 Adreno 320 A44 ES 3.0 ◎ ◎ ◎ --
APQ8064 Adreno 320 A41 ES 2.0 ◎ -- -- --
Exynos5 Dual Mali-T604 A44 ES 3.0 ◎ ◎ ◎ ◎
Tegra 4 ULP GeForce(72) A43 ES 2.0 ◎ ◎ ◎ ◎
Tegra 3 ULP GeForce(12) A44 ES 2.0 -- -- -- --
A6 PowerVR SGX543MP3 i70 ES 2.0 ◎ ◎ ◎ ◎
A7 PowerVR G6430 i70 ES 3.0 ◎ ◎ ◎ --
K3V2 Vivante GC4000 A41 ES 2.0 ◎ -- -- --
RK3066 Mali-400MP4 A41 ES 2.0 ◎ -- -- --
OMAP4430 PowerVR SGX540 A42 ES 2.0 ◎ -- -- --
Tegra 2 → Tegra 3 は core 数(速度) が違うだけで機能は全く同一でした。
対して Tegra 4 の GPU は、Tegra2/3 と比べると大幅に拡張されています。
機能面で見ればほぼ別 GPU といえるほど差があるのですが、
OpenGL ES 3.0 未対応など先行する他 GPU より見劣りする部分もあります。
DX9 世代の G70 ベースの限界なのか、それとも単に Tegra2/3 で
削っていた能力を元に戻しただけなのかもしれません。
一般的に NVIDIA に期待するイメージは強力な GPU でしょう。
ですがこれまでの Tegra は真逆で CPU に偏重した作りでした。
次の Tegra K1 以降はようやく NVIDIA らしい GPU になりそうです。
関連エントリ
・OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度
2014/01/15
OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度
ベンチマークの結果を更新しました。
・Mobile GPU bench mark
Android 4.1 以降かつ対応しているデバイスでは SwapInterval を 0 に
変更したので 60fps 以上出ています。(関連)
Adreno 330 は予想以上に速く、Adreno 320 比でもおよそ 2倍の速度が出ています。
ついに一番負荷が高い設定でも Full HD (1920x1200) で 60fps を超えるように
なってしまいました。
2010 年の GPU では 800x480 でもわずか 3fps でした。
対する Tegra 4 はあまり速度が伸びていません。
負荷を下げても速度が上がらないので、SwapInterval 設定が効いていないか
何かしら問題が発生している可能性があります。
その代わり Tegra 3 で省かれていたさまざまな extension をサポートしており
描画結果が他の GPU とほぼ一致するようになりました。
特に GL_EXT_shadow_samplers は単なる Hardware ShadowMap ではなく
PCF にきちんと Bi-linear Filter もかかります。
GL_EXT_shadow_samplers は OpenGL ES 3.0 以降のデバイスはどれも対応
していますが、必ずしも Filter がかかるとは限らないようです。
下記はいくつかテストした結果です。
この辺りはもう少し詳しく調べたいと思っています。
なお Tegra4 の Extension 詳細は下記のページに追加しました。
・CPU/GPU OpenGL ES Extension (Mobile GPU)
関連エントリ
・Android OpenGL ES と V-Sync (eglSwapInterval)
・Nexus 10 GPU Mali-T604
・Qualcomm APQ8064 GPU Adreno 320 の速度
・さらに OpenGL ES 2.0 Mobile GPU の速度比較
・GPU 速度に関連するエントリ
・Mobile GPU bench mark
Android 4.1 以降かつ対応しているデバイスでは SwapInterval を 0 に
変更したので 60fps 以上出ています。(関連)
GPU SoC CPU clock OS Screen fps pix/sec --------------------------------------------------------------------- Adreno 330 MSM8974 2.2GHz A4.2 1920x1200 71.98fps 165.8M Adreno 320(64) APQ8064 1.5GHz A4.4 1920x1104 40.97fps 86.8M Mali-T604 Exynos5D 1.7GHz A4.4 2560x1504 20.73fps 79.8M ULP GeForce(72) Tegra4 1.8GHz A4.3 1126x800 44.58fps 43.4M ULP GeForce(12) Tegra3 1.2GHz A4.4 1280x752 15.70fps 15.0M (*1) *1: Shadow Map 無し, 16bit depth
Adreno 330 は予想以上に速く、Adreno 320 比でもおよそ 2倍の速度が出ています。
ついに一番負荷が高い設定でも Full HD (1920x1200) で 60fps を超えるように
なってしまいました。
2010 年の GPU では 800x480 でもわずか 3fps でした。
対する Tegra 4 はあまり速度が伸びていません。
負荷を下げても速度が上がらないので、SwapInterval 設定が効いていないか
何かしら問題が発生している可能性があります。
その代わり Tegra 3 で省かれていたさまざまな extension をサポートしており
描画結果が他の GPU とほぼ一致するようになりました。
特に GL_EXT_shadow_samplers は単なる Hardware ShadowMap ではなく
PCF にきちんと Bi-linear Filter もかかります。
GL_EXT_shadow_samplers は OpenGL ES 3.0 以降のデバイスはどれも対応
していますが、必ずしも Filter がかかるとは限らないようです。
下記はいくつかテストした結果です。
depth-tex sh-samplers PCF Filter
----------------------------------------------------------------
8064 Adreno 320 OpenGL ES 3.0 ◎ ◎ ◎ --
8064 Adreno 320 OpenGL ES 2.0 ◎ -- -- --
Mali-T604 OpenGL ES 3.0 ◎ ◎ ◎ ◎
Tegra 4 OpenGL ES 2.0 ◎ ◎ ◎ ◎
Tegra 3 OpenGL ES 2.0 -- -- -- --
iOS PVR 543MP3 OpenGL ES 2.0 ◎ ◎ ◎ ◎
Vivante GC4000 OpenGL ES 2.0 ◎ -- -- --
Mali-400MP4 OpenGL ES 2.0 ◎ -- -- --
PowerVR SGX540 OpenGL ES 2.0 ◎ -- -- --
この辺りはもう少し詳しく調べたいと思っています。
なお Tegra4 の Extension 詳細は下記のページに追加しました。
・CPU/GPU OpenGL ES Extension (Mobile GPU)
関連エントリ
・Android OpenGL ES と V-Sync (eglSwapInterval)
・Nexus 10 GPU Mali-T604
・Qualcomm APQ8064 GPU Adreno 320 の速度
・さらに OpenGL ES 2.0 Mobile GPU の速度比較
・GPU 速度に関連するエントリ