※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPad Air 2(Apple A8X)의 GPU

(원문 : iPad Air 2 (Apple A8X) の GPU)

가장 큰 차이는 ASTC의 지원여부입니다.

GL_VERSION: OpenGL ES 3.0 Apple A8X GPU - 50.6.10
GL_RENDERER: Apple A8X GPU
GL_VENDOR: Apple Inc.
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.00

Metal의 시대까지 와서 무슨 OpenGL ES이냐는 생각도 들지만 일단 체크해둡니다. A8X에서는 A7에 없던 ASTC 압축 텍스처 형식이 추가되었습니다. ASTC에 관한 자세한 내용은 다음을 참조하시기 바랍니다.

OpenGL ES는 3.0 그대로입니다만, 이미 Metal API가 있으니 없어도 별 문제는 되지 않으리라 생각됩니다. Metal에서는 ES 3.1에 해당하는 기능을 이용할 수 있습니다.

Extension:
GL_OES_standard_derivatives
GL_KHR_texture_compression_astc_ldr
GL_EXT_color_buffer_half_float
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_pvrtc_sRGB
GL_EXT_read_format_bgra
GL_EXT_separate_shader_objects
GL_EXT_shader_framebuffer_fetch
GL_EXT_shader_texture_lod
GL_EXT_shadow_samplers
GL_EXT_texture_filter_anisotropic
GL_APPLE_clip_distance
GL_APPLE_color_buffer_packed_float
GL_APPLE_copy_texture_levels
GL_APPLE_rgb_422
GL_APPLE_texture_format_BGRA8888
GL_IMG_read_format
GL_IMG_texture_compression_pvrtc

TextureFormat 42
00=8c00  GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG
01=8c01  GL_COMPRESSED_RGB_PVRTC_2BPPV1_IMG
02=8c02  GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG
03=8c03  GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG
04=9270  GL_COMPRESSED_R11_EAC
05=9271  GL_COMPRESSED_SIGNED_R11_EAC
06=9272  GL_COMPRESSED_RG11_EAC
07=9273  GL_COMPRESSED_SIGNED_RG11_EAC
08=9274  GL_COMPRESSED_RGB8_ETC2
09=9275  GL_COMPRESSED_SRGB8_ETC2
10=9278  GL_COMPRESSED_RGBA8_ETC2_EAC
11=9279  GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC
12=9276  GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2
13=9277  GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2
14=93b0  GL_COMPRESSED_RGBA_ASTC_4x4_KHR
15=93b1  GL_COMPRESSED_RGBA_ASTC_5x4_KHR
16=93b2  GL_COMPRESSED_RGBA_ASTC_5x5_KHR
17=93b3  GL_COMPRESSED_RGBA_ASTC_6x5_KHR
18=93b4  GL_COMPRESSED_RGBA_ASTC_6x6_KHR
19=93b5  GL_COMPRESSED_RGBA_ASTC_8x5_KHR
20=93b6  GL_COMPRESSED_RGBA_ASTC_8x6_KHR
21=93b7  GL_COMPRESSED_RGBA_ASTC_8x8_KHR
22=93b8  GL_COMPRESSED_RGBA_ASTC_10x5_KHR
23=93b9  GL_COMPRESSED_RGBA_ASTC_10x6_KHR
24=93ba  GL_COMPRESSED_RGBA_ASTC_10x8_KHR
25=93bb  GL_COMPRESSED_RGBA_ASTC_10x10_KHR
26=93bc  GL_COMPRESSED_RGBA_ASTC_12x10_KHR
27=93bd  GL_COMPRESSED_RGBA_ASTC_12x12_KHR
28=93d0  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR
29=93d1  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x4_KHR
30=93d2  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x5_KHR
31=93d3  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x5_KHR
32=93d4  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x6_KHR
33=93d5  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x5_KHR
34=93d6  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x6_KHR
35=93d7  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR
36=93d8  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x5_KHR
37=93d9  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x6_KHR
38=93da  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x8_KHR
39=93db  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x10_KHR
40=93dc  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_12x10_KHR
41=93dd  GL_COMPRESSED_SRGB8_ALPHA8_ASTC_12x12_KHR

다음 페이지를 갱신했습니다.

관련 글

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPad Air 2(Apple A8X)의 부동소수점 연산능력

(원문 : iPad Air 2 (Apple A8X) の浮動小数点演算能力)

iPad Air 2(A8X)의 부동소수점 연산능력을 조사해보았습니다. 더 자세한 기록은 다음 페이지에 올려놓았습니다.

// iPad 2 Air (Apple A8X)

ARCH: ARMv8A
VFP: AArch64 NEON
SingleT SP max:  23.568 GFLOPS
SingleT DP max:  11.751 GFLOPS
MultiT  SP max:  68.591 GFLOPS
MultiT  DP max:  33.968 GFLOPS
CPU core: 3
FMA: Yes
NEON: Yes

↑정말로 CPU가 3 core였습니다. 모바일 기기에서는 좀처럼 보기 힘들고 Xbox360이나 Wii U 등 게임기에서 많이보이는 구성입니다.

원래 Cyclone은 Apple A7에서도 부동소수점 연산능력이 돌출된 CPU였는데, A8X에서도 거의 같은 경향을 보입니다. 부동소수점 연산능력은 스칼라와 벡터 모두 2 명령 동시 실행이 가능하고, NEON의 128bit 덧곱셈[각주:1]도 병렬로 실행합니다. 동작 클럭은 낮지만, 3 core가 됨으로써 다른 ARM Core의 4 core에 필적하는 수치를 보여줍니다. (아래 표의 (*1))

	      Apple A8X   Snapdragon 800   Tegra K1    Atom Z3745
               Cyclone      Krait 400     Cortex-A15   Silvermont
	      1.5GHz x3     2.2GHz x4     2.2GHz x4    1.83GHz x4
------------------------------------------------------------------
SingleT SP      23.568       17.128        17.136        8.946
SingleT DP      11.751        4.289         3.431        2.797
MultiT  SP(*1)  68.591       67.539        70.174       35.473
MultiT  DP      33.968       16.874        14.036       11.060

 * 수치는 GFLOPS, 값이 클수록 고속
 * 배정밀도(DP)에서 차가 크게 벌어진 것은 ARMv7A(32bit)에 NEON이 없기 때문
 * 최대치이므로 실제 애플리케이션 동작속도와는 다를 수 있음

명령별 로그를 더 자세히 살펴보면, A7에서 왠지 느렸던 배정밀도의 스칼라 덧곱셈 연산이 개선되었음을 알 수 있습니다.

// iPhone 5s (Apple A7)
배정밀도연산
                             실행시간　연산수   연산수
---------------------------------------------------------------
FPU fmul (64bit x1) n8      :  1.642   2436.1   2436.1
FPU fadd (64bit x1) n8      :  1.045   3827.0   3827.0
FPU fmadd (64bit x1) n8     :  3.915   2043.6   2043.6 --- (A-7)
NEON fmul.2d (64bit x2) n8  :  1.567   5105.1   5105.1
NEON fadd.2d (64bit x2) n8  :  1.034   7736.5   7736.5
NEON fmla.2d (64bit x2) n8  :  1.958   8172.1   8172.1 --- (B-7)

↑ Apple A7에서는 FPU fmadd의 덧곱셈(A-7)만 3.915로 이상하게 실행시간이 길었습니다. 같은 덧곱셈이라도 NEON fmla은 그렇게까지 떨어지지 않고, (B-7)을 보면 알 수 있듯 오히려 스칼라보다 고속으로 실행되었습니다.

// iPad Air 2 (Apple A8X)
배정밀도연산
                             실행시간　연산수   연산수
---------------------------------------------------------------
VFP fmul (64bit x1) n8      :  1.442   2773.8   2773.8
VFP fadd (64bit x1) n8      :  0.926   4321.2   4321.2
VFP fmadd (64bit x1) n8     :  1.772   4513.6   4513.6 --- (A-8)
NEON fmul.2d (64bit x2) n8  :  1.408   5681.0   5681.0
NEON fadd.2d (64bit x2) n8  :  0.922   8680.2   8680.2
NEON fmla.2d (64bit x2) n8  :  1.744   9175.5   9175.5 --- (B-8)

↑ Apple A8X에서는 스칼라의 배정밀도 덧곱셈(A-8)도 NEON(B-8)과 같은 속도로 실행되고 있어, Apple A7의 약점이 극복되어있음을 알 수 있습니다.

아래 페이지의 표에 이 연산능력의 차이를 정리했습니다.

관련 글

  1. 실수 두 값을 곱한 후 그 결과를 목표값에 더하는 연산(fd += fn * fm)의 의역 [본문으로]

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

CPU 부하가 낮은 새 3D API

(원문 : CPU 負荷が低い 新しい 3D API)

작년 AMD Mantle을 시작으로 DirectX 12가 발표되고, 얼마전에는 Apple로부터 Metal도 등장했습니다. DirectX 11 이후 정체 혹은 안정되어 있던 상태가 일변, 새로운 GPU용 API로의 흐름이 가속되고 있습니다. 모두가 DirectX11, OpenGL과는 호환성이 없는 새로운 API 집합입니다.

지금까지와 느낌이 크게 다른 건 CPU를 위한 쇄신이라는 점입니다. 새로운 묘화기능에 대한 대응은 없고 딱히 GPU의 하드웨어 성능 추가를 목적으로 한 것도 아닙니다. 목적은 CPU 부하의 경감입니다.

API           Platform   Beta SDK   GPUs
-------------------------------------------------------------
Mantle        Windows    2014/5     RADEON GCN
Direct3D 12   Windows    ?          GCN,Fermi,Kepler,Maxwell
Metal         iOS 8      2014/6     PowerVR G6430

그만큼 높아진 CPU의 부하가 문제가 되고 있다는 말이 되겠습니다.

지금까지는 공통 API의 호환성을 댓가로 두터운 드라이버 레이어가 존재했고, 성능이 향상됨에 따라 CPU가 전송하는 커맨드의 규모도 커졌습니다. Multi Core CPU의 사용이 일반화되었음에도 불구하고, 구태의연한 OpenGL은 스레드를 통한 최적화를 가로막고 있었습니다.

드라이버의 오버헤드는 게임 전용기(Game Console)과 범용기 PC/Smartphone의 큰 차이 중 하나입니다.

간단하게

고정기능은 단계적으로 줄어들어, 3D 묘화에 필요한 알고리즘의 대부분이 애플리케이션 측의 소프트웨어로 구현되게 되었습니다. 범용화가 진행되고 GPU의 용도가 넓어지면서, 기존의 고도의 기능이나 드라이버의 두터운 보호가 오히려 프로그래밍의 자유도를 막기도 합니다.

원래 GPU는 진화속도가 빨라, 기능도 성능도 사용방법도 단기간에 변화해왔습니다. Desktop에서 Mobile로 바뀌어도 마찬가지입니다. 하이레벨에서 통합된 API로는 큰 변화에 따라가기가 힘듭니다. 뭐든지 해주는 명령은 편리하지만, 사양을 정하기 위해서는 어느 정도 쓰임새가 결정되어야 하기 때문입니다. 변경이 빈번해질수록 설계는 보다 심플해지고, 의존을 줄이는 방향으로 진행됩니다.

Direct3D 10에서는 Shader의 통합과 리소스의 Buffer화 같은 개혁이 이루어졌습니다. 실제로 사용해보면 리소스 관리는 생각했던 것처럼 간단하지 않다는 것을 알게 됩니다. Resource View에는 자잘한 플래그 설정이 필요하고, 익숙해질때까지는 조합의 제한으로 고민했습니다. 정말로 자유롭다고 느낀 것은 Direct3D 11의 ComputeShader부터입니다. 용도도 데이터의 사용도 모두 프로그래머가 정할 수 있습니다.

Texture Atlas는 복수의 텍스처를 거대한 텍스처에 통합합니다. 안쪽 배치는 프로그래머가 스스로 관리해야 합니다만, 그 대신 셰이더는 uv만으로 필요한 텍스처를 읽어들일 수 있습니다. 만약 GPU의 메모리 전부를 거대한 한장의 텍스처로 볼 수 있다면 uv는 포인터와 거의 같다고 볼 수 있겠습니다. 현재 리소스 관리는 프로그래머에게 개방되어 있지 않지만, Texture Atlas는 그 제한을 넘기 위한 수법의 하나로 볼 수 있습니다.

OpenGL의 Shader 명령은 DirectX보다도 상당히 나중에 디자인된지라, Uniform의 배치나 셰이더 사이의 바인드도 자동화되어 있습니다. OpenGL 3.x 이후는 메모리 배치를 프로그래머가 정할 수 있게 되었고, 4.x 이후는 심볼의 바인드도 단순한 번호지정으로 바뀌었습니다. Direct3D의 로우레벨 명령에 가까워지고 있습니다.

GPU는 범용성을 늘리고 있습니다만, 호환성 유지를 위한 래핑은 필요 이상으로 복잡해진 감이 있습니다. 새로운 API에서는 CPU 부하의 저감과 동시에 보다 간단하고 쓰기 쉬운 API로의 복귀도 기대할 수 있습니다.

Command Buffer

묘화시에 CPU가 처리하는 것은 Command Buffer의 구축입니다. 말하자면 GPU(Command Processor)가 실행하는 프로그램 그 자체로, 애플리케이션은 프레임마다 동적으로 프로그램을 생성하는 것이라 할 수 있습니다.

드라이버는 GPU의 성능을 최대한 뽑아내게 만들어져있어, 쓸데없는 Command를 생략하는 등의 최적화 처리를 합니다. 하드웨어별로 구조가 다르므로, GPU Native한 형식으로 변환하는 작업도 필요합니다. GPU Command의 생성과 발행은 나름대로 비용이 들어가는 일입니다.

상태값은 Draw 타이밍에 필요하므로, Command의 생성은 묘화명령까지 지연됩니다. Draw 명령에 부하가 집중되어보이는 것은 그 때문입니다.

각종 Buffer화는 Command 부하경감수단의 하나입니다. 파이프라인 상태라면 묘화할때마다 Command Buffer에 쓰여지지만, Buffer에서는 미리 전송시켜둔 리소스를 어사인하는 것만으로 끝나기 때문입니다.

게임 전용기(Console)

게임 전용기는 PC와 사정이 크게 다릅니다.

  • 호환성의 족쇄가 없음
    • 하드웨어 호환성이 불필요(단일 하드)
    • 소프트웨어 호환성을 가지지 않음(SDK의 상위호환성을 가지지 않음)
  • 필요에 따라 더 로우레벨의 최적화수단이 준비됨
  • 하드 내부의 정보가 어느 정도 공개되어 있음

게임 전용기는 수년 사이클로 리프레시되고, 호환성 확보에는 전용 하드웨어 또는 소프트웨어 에뮬레이션이 이용됩니다. 그렇기에 소프트웨어(SDK) 호환성은 그다지 중요하지 않습니다.

처음부터 GPU Native한 형식을 사용할 수 있는 경우도 있고, CPU의 오버헤드도 PC와 비교하면 상당히 낮습니다.

필요에 따라 보다 로우레벨의 최적화가 가능한 것도 전용기의 특징입니다.

최근에는 그런 경우가 적어진 듯 하지만, 예를 들자면 GPU Command를 직접 조작할수 있는 경우 사전에 모델 데이터를 GPU Native한 Command 형식으로 변환해둘 수 있습니다. 메모리에 Buffer Data와 Command Buffer를 로드하는 것 만으로 묘화가 가능해집니다. 동적인 Command 생성과 비교하여 CPU 부하는 거의 생기지 않습니다. (다만 몇가지 트레이드 오프가 발생하므로 항상 최선의 방법이라고는 할 수 없음)

하드의 내부구조가 어느 정도 공개되어 있다는 점도 프로그래머의 부담을 줄여줍니다. 묘화 알고리즘의 설계시에 내부의 구조를 알고 있으면 어떤 방법이 효율이 좋은지 어느 정도 판단할 수 있어, 고민할 필요가 줄어듭니다.

호환성과 앞으로의 전망

  • 게임 전용기와의 차이가 적어진다
  • API의 분열

    • 새 API는 현재의 CPU/GPU 성능과 사용법에 맞춰 재설계되었습니다. 전체적인 동작효율이 올라가고, CPU 오버헤드가 경감되는 등 퍼포먼스 특성이 보다 게임 전용기에 가까워져갈 것입니다. 그 반면, 현재는 플랫폼별로 사양이 분단되어 있어, 호환성이라는 새로운 과제가 남겨집니다.

    OpenGL ES 2.0는 모바일에서 브라우저까지 플랫폼의 벽을 넘어 이용되고 있고, 통일된 API로서 큰 의미를 갖고 있습니다. 마찬가지로 앞으로도 OpenGL ES 3.0/3.1이 널리 이용될것인가하면 반드시 그럴 것 같지도 않습니다. 특히 iOS의 경우에는 Metal 대응기기와 일치하기에, 성능이나 기능을 위해 OpenGL ES 3.0을 선택할 메리트가 사라집니다.

                                          ES2.0  ES3.0  Metal
----------------------------------------------------------
Apple A5/A6    PowerVR SGX543/554       Y      -      -
Apple A7       PowreVR G6430            Y      Y      Y

    Android의 ES 3.0이나 Desktop의 OpenGL 4.x와 호환성을 가지기 위해서는 필요합니다만, 성능이나 쉬운 사용을 우선한다면 Metal이 선택될 가능성이 높습니다. 용도에 따라 적절하게 사용될 듯 합니다.

    그렇다고는 해도 각종 플랫폼에 개별적으로 대응하는 건 큰일입니다. OpenGL의 Low Overhead Profile이나 Multi thread Extension처럼, 플랫폼을 넘어선 새로운 사양의 등장을 기대합니다.

    관련 페이지

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

Android의 새 BayTrail-T Intel HD Graphics

(원문 : Android の新しい GPU BayTrail-T Intel HD Graphics)

Bay Trail-T 탑재 Android 단말이 발매되었기에 간단하게 조사해보았습니다. Android 단말에 사용되는 GPU 종류에 Intel HD Graphics가 새롭게 추가되었습니다.

Qualcomm     Adreno
Imagination  PowerVR
NVIDIA       Tegra
ARM          Mali
Vivante      GC
Intel        HD Graphics   ← NEW

Adreno 320/330, Mali-T604, PowerVR G6430 (iOS) 다음으로 입수가능한 OpenGL ES 3.0 대응단말이 되었습니다.

대응하는 Extension은 다음과 같습니다.

// ASUS MeMO Pad 7 ME176 Android 4.4
// Atom Z3745 x86 RAM 1GB

GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics for BayTrail
GL_VERSION: OpenGL ES 3.0 - Build eng.yunweiz.20140425.225700

GL_EXT_blend_minmax
GL_EXT_multi_draw_arrys
GL_SUN_multi_draw_arrys
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_compression_s3tc
GL_EXT_texture_lod_bias
GL_EXT_color_buffer_float
GL_EXT_packed_float
GL_EXT_texture_rg
GL_INTEL_performance_queries
GL_EXT_texture_storage
GL_OES_EGL_image
GL_OES_framebuffer_object
GL_OES_depth24
GL_OES_stencil8
GL_OES_packed_depth_stencil
GL_OES_rgb8_rgba8
GL_ARM_rgba8
GL_OES_depth_texture
GL_EXT_color_buffer_half_float
GL_OES_vertex_half_float
GL_EXT_shadow_samplers
GL_OES_point_sprite
GL_OES_blend_subtract
GL_OES_blend_func_separate
GL_OES_blend_qeuation_separate
GL_OES_standard_derivatives
GL_OES_read_format
GL_OES_mapbuffer
GL_EXT_discard_framebuffer
GL_EXT_texture_format_BGRA8888
GL_OES_compressed_paletted_texture
GL_OES_ELG_image_external
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_fixed_point
GL_OES_vertex_array_object
GL_OES_get_program_binary
GL_OES_texture_3D
GL_OES_texture_cube_map
GL_OES_fbo_render_mipmap
GL_OES_texture_float
GL_OES_texture_float_linear
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
GL_OES_stencil_wrap
GL_OES_element_index_uint
GL_OES_texture_npot
GL_OES_texture_mirrored_repeat
GL_EXT_sRGB
GL_EXT_frag_depth
GL_APPLE_texture_max_level
GL_EXT_occlusion_query_boolean
GL_INTEL_timer_query
GL_ANGLE_texture_compression_dxt1
GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5
GL_EXT_texture_compression_dxt1
GL_OES_required_internalformat
GL_EXT_separate_shader_objects
GL_OES_surfaceless_context
GL_OES_EGL_sync
GL_EXT_robustness
GL_EXT_shader_texture_lod
GL_EXT_unpack_subimage
GL_EXT_read_format_bgra
GL_EXT_debug_marker
GL_KHR_blend_equation_advanced
GL_EXT_shader_integer_mix

대응하는 압축 텍스처 포맷은 ETC2/EAC, ETC1, DXT(S3TC). DirectX11 세대의 GPU라 기능쪽으로 걱정할 필요는 없을 것 같습니다.

Android 용으로는 BayTrail 외에도 새로운 Atom(Silvermont core) SoC로 Z3400/Z3500(Moorefield)가 발표되었습니다. 탑재 GPU는 Intel HD Graphics가 아닌 PowerVR G6400입니다.

실제로 2014/5/8에 au에서 Z3580를 탑재한 MeMO Pad 8이 발표되었습니다. 발매자체는 8월로 좀 더 있어야합니다.

Tablet            SoC   core clock   display    GPU
---------------------------------------------------------------------
MeMO Pad 7 ME176  Z3745  4  1.86GHz  1280x800   Intel HD Graphics 4EU
MeMO Pad 8 ME181  Z3745  4  1.86GHz  1280x800   Intel HD Graphics 4EU
MeMO Pad 8 (au)   Z3580  4  2.33GHz  1920x1200  PowerVR G6430

PowerVR G6430은 Full HD 모델에 사용됩니다. ME176/ME181의 화면사이즈는 대다수의 Windows Tablet과 마찬가지로 1280x800 이므로, 순수한 GPU 성능으로는 Intel HD Graphics (4EU)보다 PowerVR G6430 쪽이 높지 않을까 싶습니다.

SoC core CPU-clock  GPU                   GPU-clock  fop   GFLOPS
-----------------------------------------------------------------
Z3745  4  1.86GHz   Intel HD Graphics 4EU   778MHz    64     49.8
Z3580  4  2.33GHz   PowerVR G6430           533MHz   256    136.4

Android에서도 x86 단말이 드물지 않게 되었습니다. CPU 자체는 x64에도 대응합니다.

앞으로는 Android도 64bit에 대응하리라 생각됩니다만, 기존의 단말에 대해서 64bit 판이 제공될지는 알 수 없습니다. 당분간은 구입할 타이밍을 잡기 힘든 상태가 될 것 같습니다.

관련글

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)

(원문 : BayTrail vs Kabini (Celeron J1900 vs Athlon 5350))

저소비전력 Desktop PC용 CPU로 Intel에서는 BayTrail-D, AMD에서는 Kabini가 등장했습니다. BayTrail-D Celeron J1900과 Kabini Athlon 5350 모두 4 core CPU + 마더보드로 딱 1만엔. 가격대도 스펙도 많이 닮았기에 비교해봤습니다.

                    BayTrail-D              Kabini
                    Celeron J1900         Athlon 5350
-----------------------------------------------------
CPU core             Silvermont             Jaguar
CPU cores                4                    4
CPU clock            2.0-2.41GHz           2.05GHz
RAM                DDR3-1333 dual         DDR3-1600
MEM BW                21.3GB/s             12.8GB/s
L2                      2MB                  2MB
SSE                    SSE4.2               SSE4.2
AVX                      --                  AVX
AES                      --                 AES-NI
CPU SP              24 fop/clock         32 fop/clock
CPU SP FLOPS        57.81 GFLOPS          65.6 GFLOPS
CPU DP               6 fop/clock         12 fop/clock
CPU DP FLOPS        14.46 GFLOPS          24.6 GFLOPS
GPU core         Intel HD Graphics 3G    RADEON R3 (GCN)
GPU clock            688-854MHz             600MHz
GPU SP              64 fop/clock         256 fop/clock
GPU SP FLOPS         54.7 GFLOPS         153.6 GFLOPS
OpenGL Windows       OpenGL 4.0           OpenGL 4.3
OpenGL Linux         OpenGL 3.3           OpenGL 4.3
TDP                     10W                  25W

부동소수점 연산능력

VFP Benchmark     Celeron J1900    Athlon 5350
-------------------------------------------------
SingleT SP max:   14.477 GFLOPS    15.943 GFLOPS
SingleT DP max:    3.619 GFLOPS     6.127 GFLOPS
MultiT  SP max:   57.902 GFLOPS    63.737 GFLOPS
MultiT  DP max:   14.471 GFLOPS    24.504 GFLOPS

・값이 클수록 고속

전전회에 예상했던대로 부동소수점 연산능력은 Jaguar (Kabini/Athlon) 쪽이 높게 나타나고 있습니다. J1900 (BayTrail)은 높은 동작 클럭으로 보충하는 모습입니다.

연산능력/clock    Single FP   Double FP
-----------------------------------------------
Celeron J1900         6          1.5
Athlon 5350           8            3

재측정한 후에 깨달았습니다만, 예전 글에서 J1900의 배정밀도 연산의 성능평가가 잘못되어 있었습니다. 아래 글은 정정했습니다. 죄송합니다.

「Atom Bay Trail의 부동소수점 연산능력」

전회의 컴파일 속도비교를 Kabini에서도 해봤습니다. 놀랄정도로 팽팽합니다.

flatlib3 Linux       clock  core  RAM   OS   arch compiler    time sec
-------------------------------------------------------------------------
Kabini Athlon 5350  2.05GHz  x4   8GB  14.04  x64  clang-3.5    54.8
BayTrail-D J1900    2.41GHz  x4   8GB  14.04  x64  clang-3.5    54.6

・time이 작을수록 고속

테스트한 환경은 다음과 같습니다.

Test 환경
Celeron J1900 (Q1900B-ITX DDR3-1333 dual   8GB  21.3GB/s)
Athlon 5350   (AM1l       DDR3-1333 single 8GB  10.7GB/s)

Kabini는 DDR3-1600를 사용할 수 있습니다만, 테스트 환경에서는 갖고 있던 DDR3-1333를 사용했습니다. 본래 능력보다도 스코어가 낮아질 것이 예상되므로 미리 양해바랍니다.

AES 변환 테스트

AES CTR 599MByte  Celeron J1900    Athlon 5350
-------------------------------------------------
Table1               18.708          18.964
Table2               15.409          14.600
Table3               14.902          12.374
AES-NI                   --           4.238

・단위는 초, 값이 적은 쪽이 고속, Single Thread

AES-NI를 쓸 수 있는 Jaguar (Athlon/Kabini) 쪽이 고속입니다. 같은 알고리즘을 사용하는 경우에도 미세하게 Jaguar 쪽이 빠른 것 같습니다. 메모리 속도, CPU 동작 클럭 모두 J1900 (BayTrail)가 높으므로 Jaguar (Athlon/Kabini)의 Core 성능 자체가 높음을 알 수 있습니다.

단순한 신의 렌더링 속도 비교

Ubuntu 14.04   GPU                    API            fps
----------------------------------------------------------
Celeron J1900  Intel HD Graphics 3G   OpenGL 3.3     17fps
Athlon 5350    RADEON R3              OpenGL 4.3     89fps

・fps가 높은 쪽이 빠름

비교할 것도 없이 내장 GPU의 성능에서는 압도적인 차이가 납니다. RADEON은 OpenGL에서 신 API를 쓸 수 있다는 점에서도 높은 점수를 받을 수 있습니다. J1900의 GPU는 사용하고 있으면 다소 성능부족이 느껴집니다.

CPU core의 기본성능은 Jaguar (Athlon/Kabini) 쪽이 위. 메모리 속도나 동작 클럭을 가미하면 양쪽이 상당히 비슷한 성능이 됩니다.

GPU는 당연히 RADEON (Athlon/Kabini) 쪽이 빠르고, 성능차에는 몇배의 간격이 있습니다.

● BayTrail-D (Celeron J1900/Silvermont)
  • 소비전력이 낮고 팬리스
  • 메모리 대역이 넓음
    • ● Kabini (Athlon 5350/Jaguar)
    • 부동소수점 연산능력이 높음
    • AVX/AES 명령에 대응
    • GPU 성능이 매우 높음

    관련글

    ※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

    컴파일 시간의 비교 BayTrail

    (원문 : コンパイル時間の比較 BayTrail)

    BayTrail-D Celeron J1900 PC에서 컴파일 시간을 비교해보았습니다.

    flatlib3 Linux       clock  core  RAM   OS   arch compiler   time sec
-------------------------------------------------------------------------
Raspberry Pi ARM11   0.7GHz  x1 0.5GB wheezy arm6 gcc-4.7    2276.8 (38m)
Atom Z540            1.9GHz  x1   2GB 14.04  x86  clang-3.5   446.9  (7m)
Atom Z540            1.9GHz  x1   2GB 14.04  x86  gcc-4.8     369.4  (6m)
Tegra3 Cortex-A9     1.2GHz  x4   1GB 13.04  arm7 gcc-4.8     247.4  (4m)
BayTrail-D J1900     2.0GHz  x4   8GB 14.04  x64  gcc-4.8      72.1
BayTrail-D J1900     2.0GHz  x4   8GB 14.04  x64  clang-3.5    53.2
Core i7-2720QM Sandy 2.2GHz  x4  16GB 14.04  x64  gcc-4.8      26.6
Core i7-2720QM Sandy 2.2GHz  x4  16GB 14.04  x64  clang-3.5    20.2

・time이 낮을수록 고속

    Linux용 build는 ARM에서도 작동합니다. 4core BayTrail은 1분 남짓. Mobile용 i7에서 20초이니 속도차이는 2.6배 정도. Desktop PC라면 3배 이상 차이가 날 것이라 생각됩니다. i7과 ARM11과의 차이는 100배 이상.

    아래는 Android NDK를 사용한 build 시간입니다. armeabi, armeab-v7a, mips, x86의 4종류에다가 OpenGL ES2/ES3의 2종류를 생성하므로 위에 적은 Linux build보다 몇배의 시간이 걸렸습니다.

    flatlib3 AndroidNDK  clock  core  RAM  OS           arch   time sec
-------------------------------------------------------------------------
Core 2 Duo P7350     2.0GHz  x2   8GB  MacOSX 10.9   x64   482.1  (8m2s)
BayTrail-D J1900     2.0GHz  x4   8GB  Windows 7     x64   424.1  (7m4s)
BayTrail-D J1900     2.0GHz  x4   8GB  Ubuntu 14.04  x64   277.2  (4m37s)
Core i5-3210M Ivy    2.5GHz  x2   8GB  MacOSX 10.9   x64   219.0  (3m39s)
Core i7-2720QM Sandy 2.2GHz  x4  16GB  Windows 8.1   x64   157.7  (2m37s)
Core i7-3615QM Ivy   2.3GHz  x4  16GB  Windows 8.1   x64   146.5  (2m26s)
Core i7-2720QM Sandy 2.2GHz  x4  16GB  MacOSX 10.9   x64   142.7  (2m22s)
Core i7-3615QM Ivy   2.3GHz  x4  16GB  MacOSX 10.9   x64   114.1  (1m54s)
Core i7-2720QM Sandy 2.2GHz  x4  16GB  Ubuntu 14.04  x64   102.9  (1m42s)

・time이 낮을수록 고속
・Android NDK (r9d) gcc 4.8
・armeabi, armeabi-v7a, mips, x86

    ↑이쪽은 ARM에서는 돌릴 수 없는 대신 OS에 의존하지 않고 비교할 수 있다는 이점이 있습니다. 다만 OS 환경에 의한 차이가 예상 이상으로 커서 프로세서의 성능을 보려면 동일 OS 끼리 비교하는 것이 좋을 듯 합니다. Cygwin을 경유하지 않고 gcc를 사용하였습니다만, 그래도 Windows에서의 컴파일은 느렸습니다.

    아래는 OSX target에서의 비교.

    flatlib3 Mac OSX     clock  core  RAM   OS   arch compiler    time sec
-----------------------------------------------------------------------
Core 2 Duo P7350     2.0GHz  x2    8GB  10.9 x64  clang-3.4    69.0
Core i5-3210M Ivy    2.5GHz  x2    8GB  10.9 x64  clang-3.4    38.8
Core i7-2720QM Sandy 2.2GHz  x4   16GB  10.9 x64  clang-3.4    26.1
Core i7-3615QM Ivy   2.3GHz  x4   16GB  10.9 x64  clang-3.4    21.8

・time이 낮을수록 고속
・x86_64 만

    i7-2720QM과 Core 2 Duo의 시간차이는 OSX 대상에서 2.64배, OSX에서의 Android build는 3.37배의 차이가 났습니다. Ubuntu에서의 Android build로 비교하면 i7-2720QM과 BayTrail은 2.2배. 따라서 Core 2 Duo보다도 BayTrail 4core가 빠르다고 할 수 있겠습니다.

    아래는 Windows target의 비교입니다. Windows 용은 x86/x64 바이너리를 둘 다 생성하는 것도 있고, OS에 따라 코드의 양이 달라지기에 더 많은 시간이 걸립니다.

    flatlib3 Windows     clock  core RAM   OS    arch  compiler    time sec
------------------------------------------------------------------------
BayTrail-D J1900     2.0GHz  x4   8GB  Win7   x64  VS2013TCP    402.1
Core i7-2720QM Sandy 2.2GHz  x4  16GB  Win8.1 x64  VS2013TCP    137.3
Core i7-3615QM Ivy   2.3GHz  x4  16GB  Win8.1 x64  VS2013TCP    113.4

・time이 낮을수록 고속
・x86, x64

    ↑이 데이터를 보면 2.9배의 차이가 났으며, 비율로 보면 Core 2 Duo와의 차이가 적어졌습니다.

    마지막으로 데이터로서의 의미는 없지만 만일의 경우를 위한 iOS용 build입니다. 5종류 분의 Fat Binary를 생성하므로 시간이 걸립니다. OSX와 비교하면 거의 5배로 계산대로입니다.

    flatlib3 iOS         clock  core  RAM   OS   arch compiler    time sec
---------------------------------------------------------------------------
Core 2 Duo P7350     2.0GHz  x2    8GB  10.9 x64  clang-3.4   350.6  (5m51s)
Core i5-3210M Ivy    2.5GHz  x2    8GB  10.9 x64  clang-3.4   189.1  (3m9s)
Core i7-2720QM Sandy 2.2GHz  x4   16GB  10.9 x64  clang-3.4   128.5  (2m8s)
Core i7-3615QM Ivy   2.3GHz  x4   16GB  10.9 x64  clang-3.4   107.6  (1m48s)

・time이 낮을수록 고속
・armv7, armv7s, arm64, x86, x86_64

    Desktop PC로 쓰기에는 아무래도 답답함이 느껴지지지만, CPU core수가 많아서 나름대로 퍼포먼스는 나온다는 인상입니다.

    8inch 클래스의 경령 Tablet PC로 휴대하면서, 컴파일 시간이 노트북의 몇배 범위내라면 충분히 쓸만하다고 느꼈습니다. 다만 실제 Tablet에서는 동작 클럭도 탑재 RAM 용량도 크게 줄었으므로 그 점을 검증할 필요가 있을 것 같습니다.

    관련글

    ※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

    Atom Bay Trail의 부동소수점 연산능력

    (원문 : Atom Bay Trail の浮動小数点演算能力)

    최근의 Windows Tablet 등에 쓰이는 Bay Trail은 새로운 세대의 Atom CPU core(Silvermont)를 탑재했습니다. HT 없는 2/4 core의 Out-of-Order로, 구 Atom과 비교하여 실행성능이 크게 향상되었습니다.

    Bay Trail의 부동소수점 연산능력을 조사해보았습니다. 테스트 환경은 Bay Trail-D (Celeron J1900)으므로 엄밀히 말하자면 Celeron입니다.

    그 결과, 단정밀도의 부동소수점 연산능력은 구 Atom과 다르지 않고, 1 core당 6 fop(add 4 + mul 2) / clock이라는 것을 알 수 있었습니다. 구 Atom과 마찬가지로 add, mul의 비대칭적인 interleave에서 좋은 결과가 나왔습니다. 그 대신 배정밀도 연산이 강화되어, 구 Atom의 2배에 상당하는 값이 나왔습니다.

    VFP Benchmark의 결과를 통해 구한 cycle 당 연산 (1core 당)

                           Single FP   Double FP
---------------------------------------------------------
Atom Bonnell (구Atom)     6          1.5
Atom Silvermont (신)      6            3 1.5     (Bay Trail)
Core 2 Duo                8            4
Core i7 Sandy Bridge     16            8
Core i7 Ivy Bridge       16            8
Core i7 Haswell          32           16     (미계측, 예상치)

Cortex-A9                 4            1
Cortex-A15                8          1.4
Krait                     8            2     (Snapdragon 800)
Swift                     8            1     (iPhone 5)
Cyclone ARM64            16            8     (iPhone 5s)

    연산내용의 내역은 다음과 같습니다.

                           Single FP         Double FP
SIMD(Vector)           mul  add  mad     mul  add  mad
-------------------------------------------------------
Atom Bonnell (구Atom)   2    4   (6)     0.4  0.5    ?
Atom Silvermont (신)    2    4   (6)       1    2   (3)  0.5  1.0  (1.5)
Core 2 Duo              4    4   (8)       2    2  (3?)
Core i7 Sandy Bridge    8    8  (16)       4    4   (8)
Core i7 Ivy Bridge      8    8  (16)       4    4   (8)

Cortex-A9               2    2    4       --   --   --
Cortex-A15              4    4    8       --   --   --
Krait                   4    4    8       --   --   --
Swift                   4    4    8       --   --   --
Cyclone ARM64           8   12   16        4    6    8

    Scalar일 때의 결과 등, 보다 자세하게 정리한 표를 아래에 올려놓았습니다.

    아래는 실제 J1900의 VFP Benchmark 결과입니다. 연산명령단위 등 보다 자세한 결과를 보시고 싶은 분은 이쪽에서 보시길 바랍니다. 각종 CPU의 로그를 올려놓았습니다.

    Bay Traild-D Celeron J1900 2.0GHz (TB:2.5GHz 2.41GHz)

ARCH: x64
FPU: SSSE3 SSE4.1 SSE4.2
SingleT SP max: 14.477 GFLOPS
SingleT DP max:  3.619 GFLOPS
MultiT  SP max: 57.902 GFLOPS
MultiT  DP max: 14.471 GFLOPS
CPU core: 4
SSE: yes
AVX: no
FMA: no
～

    이론치는 2GHz 4core로 48 GFLOPS인데, 계측결과 그보다 높은 수치가 나왔습니다. Turbo Boost가 작동하고 있는 것이 원인으로, 57.902 / 24 = 2.41이므로 Multi Thread 시에 대충 2.4GHz로 동작한다는 것을 알 수 있습니다.

    다른 CPU와의 비교

    VFP Benchmark 실측값        clock core    Single FP     Double FP
-------------------------------------------------------------------
Bay Trail-D  J1900           2.0GHz x4    57.9 GFLOPS   14.5 GFLOPS
Menlow       Atom Z540       1.9GHz x1    10.9 GFLOPS    1.9 GFLOPS
Core 2 Duo   P7350           2.0GHz x2    31.7 GFLOPS   12.7 GFLOPS
Ivy Birdge   Core i5-3210M   2.5GHz x2    90.2 GFLOPS   45.2 GFLOPS
Sandy Bridge Core i7-2720QM  2.2GHz x4   162.3 GFLOPS   74.0 GFLOPS

Kindle HDX 7 Krait 400       2.2GHz x4    67.5 GFLOPS   16.9 GFLOPS
Tegra Note 7 Cortex-A15      1.8GHz x4    51.3 GFLOPS    9.8 GFLOPS
iPhone 5s    Cyclone         1.3GHz x2    40.9 GFLOPS   20.5 GFLOPS

・최대값 비교. GFLOPS가 높을수록 빠름

    ↑ Multi Thread 시의 비교이므로, Core수가 많고 Clock이 높은 쪽이 결과가 좋습니다.

    현저한 Mobile용 CPU의 성능향상으로, 구 Atom(Bonnell/Saltwell)으로는 하이엔드 Quad core ARM과 맞상대를 할 수가 없었습니다만, 새 Atom Silvermont는 충분한 성능을 갖고 있습니다. 다만 부동소수점 연산은 그렇게 뛰어나지 않은 듯 합니다. 아마 AVX에도 대응되는 Jaguar 쪽이 더 위일 겁니다.

    또한 Tablet용 Bay Trail-T는 동작 클럭이 내려가므로, 위의 표보다도 성능이 낮아질 거라 생각됩니다.

    또, 어디까지나 부동소수점 연산에 특화된 수치이므로, 실제 애플리케이션의 동작속도와는 차이가 있다는 점에 주의하시기 바랍니다. 당 blog가 부동소수점 연산성능의 데이터를 모으는 것은 게임을 개발할 때의 최적화가 목적입니다.

    2014/05/15 정정:

    개인적인 메모용입니다. 보일때마다 추가해나갈 예정입니다.

    종합

    그래픽(3D)

    그래픽(2D)

    사운드

    기타 북마크

    1. 규약상으로는 경기도민 및 경기도 소재 업체만 사용가능. 저작권상으로 문제가 될 소지가 있어 상용이용은 힘들고 프로토타입 제작용 정도가 한계로 보임. [본문으로]
    2. 서비스가 종료되면서 제작사가 공개. 이용규약의 한국어 번역은 이 곳을 참고. [본문으로]

    + Recent posts

    티스토리툴바