Amazon Fire TV (2015) で vfpbench を走らせてみました。下記表の MT8173C (上 2つ) が Fire TV です。

(SP/DP/SP-MT/DP-MT の単位は MFLOPS GFLOPS,数値が大きい方が高速)

詳細な結果は下記に追加しています。(big core のみ計測しています)

・VFP Benchmark Log

Cortex-A72 はピーク性能に突出したところはなく core あたり 8 fop (単精度 SIMD4 FMA) と標準的。SIMD2 の結果から Cortex-A15 同様 64bit 2pipe の構成であることもわかります。

ただしスカラー命令にはかなり違いがあるようです。Cortex-A72 では NEON だけでなくスカラー命令も 2 pipe 並列に実行できるらしく、加算で Cortex-A15 のおよそ 2倍。これは AArch32 mode でも有効なので、ARMv7A でビルドしたバイナリでも 64bit CPU の方が高速に演算できることになります。

倍精度でも少々面白い結果になっています。AArch64 には倍精度浮動小数点演算の NEON 命令があるものの SIMD でも 2並列です。Cortex-A72 は 64bit x 2pipe なので、ピーク性能において NEON とスカラーの差がなくなっています。

AArch32 でも同じなので、倍精度 NEON 命令が使えない ARMv7A もピーク速度が落ちておらず AArch64 の NEON 相当の速度を維持しています。

下記は倍精度のみの抜粋です。AppleA7/TegraK1 は AArch32 と AArch64 で差が開いていますが Cortex-A72 はスコア差がありません。A7/K1 比でピーク速度で負けているものの AArch32 では逆転していることがわかります。

・CPU の浮動小数点演算能力の詳細

関連エントリ
・iPod touch 6 の浮動小数点演算速度は Core 2 Duo ライン超え
・iPad Air 2 (Apple A8X) の浮動小数点演算能力
・Android x86 Binary Translator を試してみる
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
・VFP Benchmark 関連

Amazon Fire TV (2015) と Fire TV Stick (2015) が発売されました。

Fire TV は MT8173C を搭載しており Fire (Kindle) 初の 64bit 機となっています。CPU core は Cortex-A72 で ARM のハイエンド系 64bit Core の 2世代目です。ただし 2+2 の big.LITTLE なのでハイパフォーマンス Core の担当は実質 Dual core になります。

GPU も PowerVR GX6250 と、Fire HD 6/7 に使われている Rogue G6200 (Series6) よりも一つ新しい Series6XT になりました。Apple でいえば A8/A8X と同じ世代ですが、Shader core 数は A8/A8X の 1/2～1/4 と少なくなっています。

どちらも世代は新しいものの Core の数は決して多くなく、コストとのバランスを保っている印象です。

Fire TV (2015) で気になっていたのは Developer サイトの公式の Spec 表で OpenGL ES 3.1 AEP に対応しているかのように書かれていたことです。AEP に対応しているのは Series7 以降のはずなので、実機で確認してみました。

下記の通り AEP には非対応でした。

// Amazon Fire TV 2015

GL_VERSION: OpenGL ES 3.1 build 1.4@3443629
GL_RENDERER: PowerVR Rogue GX6250
GL_VENDOR: Imagination Technologies
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.10 build 1.4@3443629

Extension:
GL_EXT_blend_minmax
GL_EXT_color_buffer_float
GL_EXT_discard_framebuffer
GL_EXT_draw_buffers
GL_EXT_multi_draw_arrays
GL_EXT_multisampled_render_to_texture
GL_EXT_occlusion_query_boolean
GL_EXT_read_format_bgra
GL_EXT_robustness
GL_EXT_separate_shader_objects
GL_EXT_shader_framebuffer_fetch
GL_EXT_shader_texture_lod
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_format_BGRA8888
GL_EXT_texture_rg
GL_EXT_texture_sRGB_decode
GL_IMG_multisampled_render_to_texture
GL_IMG_program_binary
GL_IMG_read_format
GL_IMG_shader_binary
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_compression_pvrtc2
GL_IMG_texture_format_BGRA8888
GL_IMG_texture_npot
GL_KHR_blend_equation_advanced
GL_KHR_blend_equation_advanced_coherent
GL_KHR_debug
GL_KHR_texture_compression_astc_ldr
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24
GL_OES_depth_texture
GL_OES_EGL_image
GL_OES_EGL_image_external
GL_OES_EGL_sync
GL_OES_element_index_uint
GL_OES_fragment_precision_high
GL_OES_get_program_binary
GL_OES_mapbuffer
GL_OES_packed_depth_stencil
GL_OES_required_internalformat
GL_OES_rgb8_rgba8
GL_OES_shader_image_atomic
GL_OES_standard_derivatives
GL_OES_surfaceless_context
GL_OES_texture_float
GL_OES_texture_half_float
GL_OES_texture_npot
GL_OES_texture_stencil8
GL_OES_texture_storage_multisample_2d_array
GL_OES_vertex_array_object
GL_OES_vertex_half_float

より詳細なデータは下記に掲載しました。

・CPU/GPU OpenGL ES Extension (Mobile GPU)

Fire TV Stick (2015) はスティック状のストリームプレイヤーで Chromecast に似ています。ただし Chromecast と違い普通に Fire OS (Android) が動作しており Native なアプリがローカルで走ります。

ハードウエアの仕様自体は最初に発表された Fire TV Stick 2014 から特に変わっていないようです。Developer サイトの Spec 表でも 2014 モデル時のまま Fire OS 3.0 (API Level 17) と記載されています。

ところが実際に実機を調べたところ、低スペックながら Fire TV 同様 Fire OS 5.0 が動作しており API Level 22 (Android 5.1 相当) であることがわかりました。

GL_VERSION: OpenGL ES 2.0
GL_RENDERER: VideoCore IV HW
GL_VENDOR: Broadcom
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.00

Extension:
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_compressed_paletted_texture
GL_OES_texture_npot
GL_OES_depth24
GL_OES_vertex_half_float
GL_OES_EGL_image
GL_OES_EGL_image_external
GL_EXT_discard_framebuffer
GL_OES_rgb8_rgba8
GL_OES_depth32
GL_OES_packed_depth_stencil
GL_EXT_texture_format_BGRA8888
GL_EXT_debug_marker

GPU は Raspberry Pi と同じ VideoCore IV です。
こちらも詳細は下記のページに追加しました。

・CPU/GPU OpenGL ES Extension (Mobile GPU)

関連エントリ
・Android 5.0 Nexus Player x86 と対応 ABI
・(Kindle) Fire HD 6 は OpenGL ES 3.0 対応で非対称 4 core CPU
・Amazon Fire TV の性能

Direct3D 12 ではリソースバインドの方法が大きく変わっています。Shader の種類も渡すリソースの数も増えており、Bind のコストが無視できなくなっているからです。リソースは Descriptor Heap 上に確保した一連の Descriptor に登録します。この Heap 上の先頭アドレスを指定するだけで描画時のバインドが完了する仕組みです。

Descriptor は GPU がアクセスする領域なので、ハードウエアによってサイズが異なっています。実際にどれくらい違いがあるのか調べてみました。数値の単位は byte です。

このように GPU によってサイズが異なるため、Descriptor のアドレス計算を行う場合は必ず GetDescriptorHandleIncrementSize() を参照しなければなりません。Descriptor とはいわば Resource を参照するためのポインターですが、View に相当するアクセスに必要な情報も含まれます。サイズ的に単純なアドレスだけではないことがわかります。

全体的に DSV が大きいのは、Depth の他に Stencil Surface が必要なこと、高速化のための (PreZ 等) の追加 Resource が含まれているためと考えられます。そういう意味では DSV が 8byte しかない GeForce はまさにアドレスだけ。更に他の情報構造体を間接的に参照しているのではないでしょうか。

Intel HD Graphics の場合は世代間でも差が生じています。外部からはあまり違いがわかりませんが、ハードウエアの差は思ったよりも大きいようです。

この表は下記ページにも掲載しています。

・RootSignature と Descriptor

●気がついた問題点など

DirectX12 は現在も頻繁にドライバの更新が行われています。まだ安定していない機能があるようです。以下使っていて気がついたもの。(2015/09/22現在)

GeForce Maxwell/Kepler (355.82)
　・Indirect Draw の CommandSignature で RootDescriptor が反映されない問題が生じていたが Driver 355.82 で修正された。

RADEON GCN 1.0/1.1 (15.8Beta)
　・CommandSignature で Rooto 32bit Consnta/Root Descriptor が反映されない
　・Bundle で RootSignature のパラメータが継承されない

Intel HD Graphcis Gen7.5/8 (10.18.15.4256)
　・RootSignature に Root 32bitConstant が複数存在する場合、CommandSignature で最初の 32bit Constant しか更新できない。

下記ページも更新しています。

・Direct3D 12 (DirectX 12) Windows 詳細

他にも問題ではありませんが API の挙動で GPU による細かい違いは結構あります。

関連エントリ
・Direct3D12 ROV を試してみる (3) 半透明ソートと Intel HD Graphics
・Direct3D12 ROV を試してみる (2) Depth Test と半透明ソート
・Direct3D12 ROV (Rasterizer Order View) を試してみる
・3D 低レベル API の違い Direct3D 12/Metal
・Direct3D 12 GeForce GTX970 は FeatureLevel 12_1 対応、Resource Bind/Heap Tier は低い
・3D 低レベル API の現状 Direct3D 12/Metal

Mac の Metal API 対応機種が明らかになっています。mid 2012 以降、Mac Pro のみ 2013以降となります。これらの機種を GPU に照らし合わせると下記の通り。

・Intel HD Graphics 4000 Gen7 以降 (Ivy Bridge)
・GeForce Kepler 以降
・RADEON GCN 以降

Metal はもともと Mobile OpenGL ES 3.1 世代向けの API なので、機能面の要求はそれほど厳しくなく Direct3D 12 よりも多くの GPU に対応しています。ですが予想よりも対応 GPU には差が少ないことがわかりました。

比較すると下記の通りです。いずれも Direct3D 11 世代以降の GPU となります。

一番の違いは Metal が Intel HD Graphics 4000 Ivy Bridge に対応していることです。
この世代の GPU は BayTrail として Windows Tablet の多くに採用されていますが D3D12 を使うことができなくなっています。

iOS の Metal 対応機種は下記の通り

下記ページも更新しました

・GPU 世代対応表 (API 対応表)
・Metal (iOS/OS X)

Mac 対応機種は下記より。

・Apple Mac Developer Library : Metal Feature Set Tables

関連エントリ
・歴代 iPad の CPU/GPU 速度の比較と iPad Pro の速度の目安
・3D 低レベル API の違い Direct3D 12/Metal
・3D 低レベル API の現状 Direct3D 12/Metal

Apple の製品紹介には、前モデルからどれだけパフォーマンスが向上したか比較値が載っています。この数値をまとめてみました。

iPad mini/iPad 2 はどちらも Apple A5 (Cortex-A9 1.0GHz dual/PowerVR SGX543MP2) が用いられており同一です。これを 1.0 とした時の速度の比較は下記のとおり。数値が大きい方が高速です。

誤差が含まれていると思われるため目安程度にお願いします。
iPad mini2/3, iPad Air はどちらも A7 を搭載しており、きちんと同じ数値になっています。実際は mini と Air は CPU Clock で僅かに (7%ほど) 違いがあります。

GPU の速度向上が著しいことがよくわかります。
iPad Pro に至っては CPU 10倍、GPU 40倍という結果に。Metal でも新たに iOS GPUFamily3 が追加されているので、A9/A9X (または A9X のみ) には新しい GPU が搭載されている可能性があります。

元にした数値は下記の通り。

これらのデータは下記公式ページより。

・Apple: iPad Pro
・Apple: iPad Pro Technology
・Apple: iPad mini 4
・Apple: iPad mini 4 パフォーマンス
・Apple、iPad Air 2を発表—これまでで最も薄く、最もパワフルなiPad
・Apple、iPad Airを発表 劇的に薄く、軽く、よりパワフルなiPad
・Apple、iPad miniを発表
・Apple、新しいiPadを発表