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

Android 5.x OpenGL ES 3.1과 대응 GPU

(원문 : Android 5.x OpenGL ES 3.1 と対応 GPU)

Android 5.0부터 OpenGL ES 3.1에 대응합니다. GPU의 대응상황을 조사해보았습니다. 현재까지 판명된 (직접 조사한) GPU는 다음과 같습니다.

GPU              OpenGL API           SoC
----------------------------------------------------
Tegra K1         OpenGL ES 3.1 AEP
Adreno 420       OpenGL ES 3.1 AEP    Snapdragon 805
Adreno 430       OpenGL ES 3.1 AEP    Snapdragon 810         
Mali-T604        OpenGL ES 3.1        Exynos 5
Mali-T760        OpenGL ES 3.1        Exynos 7
PowerVR G6200    OpenGL ES 3.1        MT8135
PowerVR G6430    OpenGL ES 3.1        Atom Z3580

Android 4.3부터 OpenGL ES 3.0을 지원합니다. 위의 결과를 보면 OpenGL ES 3.0 대응 GPU 태반이 그대로 OpenGL ES 3.1에도 대응된다는 것을 알 수 있습니다.

위의 표에는 없습니다만, Z37 계열의 Intel HD Graphcs (Gen7)도 Windows의 최신 드라이버에서 OpenGL ES 3.1에 대응합니다.(자세한 건 이쪽으로)

따라서 현재 예외가 되는 것은 Adreno 300 계열 뿐입니다. Adreno 300(305/306/320/330등)은 OpenGL ES 3.0 전용이라 생각해도 될 것 같습니다.

또 하나의 특수한 예외는 iOS입니다. 지원하는 OpenGL API는 ES 3.0까지 입니다만, Low Level API인 Metal을 사용함으로써 OpenGL ES 3.1에 해당하는 기능을 사용할 수 있습니다.

GPU              API                     SoC
--------------------------------------------------
PowerVR G6430    OpenGL ES 3.0 / Metal   A7
PowerVR GX6450   OpenGL ES 3.0 / Metal   A8
PowerVR GX6850   OpenGL ES 3.0 / Metal   A8X

OpenGL ES 3.1 대응상황에 대해서는 아래 페이지에 정리했습니다.

GPU 별 상세는 이쪽.

관련글

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

Android 5.0 Nexus Player x86과 대응 ABI

(원문 : Android 5.0 Nexus Player x86 と対応 ABI)

Android는 5.0부터 64bit CPU에 대응합니다. Android에서의 첫 64bit device는 Nexus 9입니다. 물론 상위호환성이 있어서 종래의 32bit ARM Native code도 실행가능합니다. 32bit ARM에는 2종류의 ABI가 존재하므로 전부 3종류입니다.

ARMv8A AArch64  arm64-v8a
ARMv7A          armeabi-v7a
ARMV5TE         armeabi

Android 4.4까지는 동시에 2종류의 ABI에 대응할 수 있었습니다. Android 5.0 이후는 위에 적은 대로 3개 이상 지정할 수 있게 되었습니다.

동시에 발표된 Nexus Player는 Nexus 첫 Intel CPU (Atom Z35xx) 탑재 단말입니다. OS도 Android 5.0이지만, 아쉽게도 64bit(x86_64)가 아니라 32bit(x86)로 동작하는 것 같습니다.

ro.product.cpu.abi=x86
ro.product.cpu.abi2=armeabi-v7a
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist64=

이전에 알아본대로, Android x86 단말은 Binary Translator를 통해 ARM의 Native code를 실행할 수 있습니다. 같은 x86(32bit)이라도 5.0 이후라면 3종류 지정할 수 있으므로, Nexus Player의 경우 armeabi도 포함되어있다는 것을 알 수 있습니다.

Device       Android CPU           ABI
-------------------------------------------------------------------
Nexus 5         5.0  Krait 400                armeabi-v7a  armeabi
Nexus 9         5.0  Denver        arm64-v8a  armeabi-v7a  armeabi
Nexus Player    5.0  Silvermont    x86        armeabi-v7a  armeabi
MeMO Pad ME176  4.4  Silvermont    x86        armeabi-v7a

Android 5.0부터는 지금까지 x86에서 돌지 않던 앱도 돌아가게 될 지도 모릅니다. 장래 x64(x86_64) 단말이 등장하면 x86_64를 포함하여 4종류가 됩니다.

관련글

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

Android Nexus 6 Adreno 420도 OpenGL ES 3.1 AEP 대응 (Direct3D 11 상당)

(원문 : Android Nexus 6 Adreno 420 も OpenGL ES 3.1 AEP 対応 (Direct3D 11相当))

Nexus 6의 GPU Adreno 420는 OpenGL ES 3.1 AEP(Android Extension Pack)에 대응한다는 것을 알게 되었습니다.

OpenGL ES 3.1은 ComputeShader에 대응합니다. 거기에 더해 OpenGL ES 3.1 AEP에서는 Tessellator (HullShader/DomainShader,TCS/TES)나 GeometryShader 등 Direct3D 11 상당하는 기능이 추가욉니다.

지금까지 판명된 OpenGL ES 3.0 이상에 대응하는 GPU

                SoC               GPU           OpenGL
------------------------------------------------------------------
Kindle Fire HD6 MediaTek MT8135   PowerVR G6430 OpenGL ES 3.0
iPhone/iPad     Apple A7/A8       PowerVR G6430 OpenGL ES 3.0
MeMO Pad ME176  BayTrail-T Z3745  HD Graphics   OpenGL ES 3.0
LG G Watch W100 Snapdragon 400    Adreno 305    OpenGL ES 3.0
Nexus 7(2013)   Snapdragon S4 Pro Adreno 320    OpenGL ES 3.0
Nexus 5         Snapdragon 800    Adreno 330    OpenGL ES 3.0

Nexus 10        Exynos 5 Dual     Mali-T604     OpenGL ES 3.1

Nexus 6         Snapdragon 805    Adreno 420    OpenGL ES 3.1 AEP
Nexus 9         NVIDIA Tegra K1   Kepler(192)   OpenGL ES 3.1 AEP

Nexus 9의 Tegra K1에 이어, 신형 Nexus는 둘다 AEP에 대응하게 되었습니다.

이하 Nexus 6 Snapdargon 805 APQ8084의 GL Extension

Extension:
GL_EXT_debug_marker
GL_OES_EGL_image
GL_OES_EGL_image_external
GL_OES_EGL_sync
GL_OES_vertex_half_float
GL_OES_framebuffer_object
GL_OES_rgb8_rgba8
GL_OES_compressed_ETC1_RGB8_texture
GL_AMD_compressed_ATC_texture
GL_KHR_texture_compression_astc_ldr
GL_OES_texture_npot
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_format_BGRA8888
GL_OES_texture_3D
GL_EXT_color_buffer_float
GL_EXT_color_buffer_half_float
GL_QCOM_alpha_test
GL_OES_depth24
GL_OES_packed_depth_stencil
GL_OES_depth_texture
GL_OES_depth_texture_cube_map
GL_EXT_sRGB
GL_OES_texture_float
GL_OES_texture_float_linear
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
GL_EXT_texture_type_2_10_10_10_REV
GL_EXT_texture_sRGB_decode
GL_OES_element_index_uint
GL_EXT_copy_image
GL_EXT_geometry_shader
GL_EXT_tessellation_shader
GL_OES_texture_stencil8
GL_EXT_shader_io_blocks
GL_OES_shader_image_atomic
GL_OES_sample_variables
GL_EXT_texture_border_clamp
GL_EXT_multisampled_render_to_texture
GL_OES_shader_multisample_interpolation
GL_EXT_draw_buffers_indexed
GL_EXT_gpu_shader5
GL_EXT_robustness
GL_EXT_texture_buffer
GL_OES_texture_storage_multisample_2d_array
GL_OES_sample_shading
GL_OES_get_program_binary
GL_EXT_debug_label
GL_KHR_blend_equation_advanced
GL_KHR_blend_equation_advanced_coherent
GL_QCOM_tiled_rendering
GL_ANDROID_extension_pack_es31a
GL_EXT_primitive_bounding_box
GL_OES_standard_derivatives
GL_OES_vertex_array_object
GL_KHR_debug

관련 글

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

Nexus 9 Tegra K1과 ARM 64bit Denver

(원문 : Nexus 9 Tegra K1 と ARM 64bit Denver)

iPhone 5s에 뒤쳐진지 대략 1년, 64bit 대응 Android와 ARM64 단말이 발매되었습니다. Nexus 9의 CPU core는 NVIDIA의 Denver.

Processor	: NVIDIA Denver 1.0 rev 0 (aarch64)
processor	: 0
processor	: 1
Features	: fp asimd aes pmull sha1 sha2 crc32 
CPU implementer	: 0x4e
CPU architecture: AArch64
CPU variant	: 0x0
CPU part	: 0x000
CPU revision	: 0

Hardware	: Flounder
Revision	: 0000
Serial		: 0000000000000000

좀 보기 힘들지만 "processor" 행이 2개 있으므로 dual core입니다.

$ cat /sys/devices/system/cpu/online
0-1

vfpbenchmark는 아래와 같습니다. single core 시의 부동소수점 연산능력은 SHILED Tablet(Cortex-A15 2.2GHz)과 거의 동등하여, 종합성능에서는 Core의 수만큼 떨어집니다. 어디까지나 32bit의 결과이고 나중에 64bit(AArch64)에서도 테스트해보려 합니다.

// Nexus 9
ARCH: ARMv7A
CPU core: 2
VFP: VFPv4-D32 NEON
FMA: Yes
NEON: Yes
  SingleT SP max: 17.799 GFLOPS
  SingleT DP max:  4.423 GFLOPS
  MultiT  SP max: 34.582 GFLOPS
  MultiT  DP max:  8.719 GFLOPS
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=arm64-v8a

arm64-v8a, armeabi-v7a, armeabi 3개의 ABI에 대응합니다. Android가 현재 NDK에서 지원하는 ABI는 아래의 7종류입니다.

armeabi       ARMv5TE
armeabi-v7a   ARMv7A VFPv3-D16 softfp (VFPv3-D32, NEON, hard-float)
arm64-v8a     ARMv8A (AArch64)
x86           x86 (IA-32)
x86_64        x64
mips          MIPS32-R1
miips64       MIPS64

참고로 iOS에서 개발용의 lib를 만들면 5종류.

armv7         ARMv7A VFPv3-D32+NEON softfp
armv7s        ARMv7A VFPv4-D32+NEON softfp
arm64         ARMv8A (AArch64)
i386          x86    simulator
x86_64        x86_64 simulator

GPU는 OpenGL ES 3.1의 Context를 반환합니다.

GL_VERSION: OpenGL ES 3.1 NVIDIA 343.00
GL_RENDERER: NVIDIA Tegra
GL_VENDOR: NVIDIA Corporation
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.10

대응하는 텍스처 포맷은 DXT, ETC1, ETC2/EAC, ASTC. 자세한 것은 아래 페이지에 게재했습니다.

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

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 판이 제공될지는 알 수 없습니다. 당분간은 구입할 타이밍을 잡기 힘든 상태가 될 것 같습니다.

관련글

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

iPhone 5s A7 64bit CPU와 AArch64

(원문 : iPhone 5s A7 64bit CPU と AArch64)

스마트폰에 탑재되어 있는 메모리 용량은 굉장히 빠른 페이스로 증가하고 있습니다. 다음 페이지에 일본에 발매된 단말의 스펙을 모았습니다.

대충 훑어보기만 했지만 대충 이런 느낌↓이 아닐까 합니다.

2008년 128MB
2009년 128MB〜256MB
2010년 256MB〜512MB
2011년 512MB〜1GB
2012년 1GB〜2GB
2013년 1/2GB〜?

특히 Android 기기에서 용량증가가 두드러짐을 알 수 있습니다. 이 페이스가 앞으로도 지속될 거라고 예상하면, 내년에는 32bit 프로세서의 벽에 부딪히게 됩니다.

많은 RAM 용량을 필요로 하게 되는 원인 중 하나로 화면의 고해상도화를 들 수 있겠습니다. 이쪽도 RAM 용량에 지지 않을 페이스로 진화해왔습니다.

2008년 128MB           480x320              x1.0
2009년 128MB〜256MB    480x320〜800x480     x2.5
2010년 256MB〜512MB    854x480〜1024x768    x5.12
2011년 512MB〜1GB      854x480〜1280x800    x6.67
2012년 1GB〜2GB        854x480〜2560x1600   x26.67
2013년 1/2GB〜?       1280x720〜?

고해상도화에 따라 응용 프로그램에 필요한 묘화 리소스량도 증가합니다. 해상도가 높으면 CPU 묘화가 늦어지므로, GPU의 지원이 필수가 됩니다. 묘화나 레이어의 합성 등 OS가 관리하는 GPU 리소스도 대폭으로 늘어나게 됨을 예상할 수 있습니다.

그 이외에도 여러가지 요인이 있을거라 생각하지만, 프로세서 전체의 성능향상과 그에 맞춘 요구에서 볼때, 64bit화는 자연스러운 흐름이라 할 수 있을 것입니다.

하지만 지금 가장 RAM 용량이 절박한 것은 Android 쪽입니다. iOS는 Android의 약 절반 정도의 RAM 용량으로 동작하고 있으므로, iPhone 5s의 A7가 스타트를 끊은 것은 상당히 의외라는 생각이었습니다.

64bit화의 메리트로 주소 공간의 확장을 듭니다만, 그 외에도 여러가지 메리트가 있습니다. 특히 64bit mode는 호환성의 족쇄에서 벗어날 큰 기회이며, 64bit 화되면서 여러가지 아키텍처의 변경이 이루어지고 있는 듯 합니다.

하나는 명령어 집합이나 레지스터 등 하드웨어적인 아키텍처의 변경이고, 또 하나는 소프트웨어적인 결정사항을 재설계할 수 있다는 것입니다. 전혀 쓰이지않지만 호환성 때문에 남겨져있는 기능이라던가, 설계가 낡아서 영 좋지않게 된 사양등을 쳐낼 수 있게 됩니다. (물론 32bit 동작 mode에서는 호환성이 유지됩니다.)

ARM은 로드 스토어형의 RISC 프로세서이지만, 한 인스트럭션에 복수의 기능이 들어간 다기능적인 명령체계였습니다. 예를 들면 명령 필드에 Condition Code가 포함되어 있어 조건부 실행이 가능하거나, 소스 오퍼랜드에 Shifter가 들어가 있는 등 상당히 독특합니다.

AArch64에서는 전혀 다른 명령어 집합이 되었습니다. 보다 심플하고 실용적인 설계가 되었다고들 합니다만, 대충 본 결과 편리해보이는 특이한 기능도 풍부하여, 충분히 ARM 답다고 느꼈습니다.

컴파일러의 출력 코드와 비교하면, 함수에 있어서는 64bit 쪽이 명령수가 줄어 컴팩트해짐을 알 수 있습니다.

위에서 적은 바와 같이 ARMv7에서는 호환성 문제로 softfp (soft-float)가 사용되는 경우가 있습니다. 부동소수점값도 함수 입출력에서는 일단 정수 레지스터를 경유하게 되어 낭비가 발생합니다.

AArch64 (64bit)에서는 이런 배려가 필요없으므로 처음부터 hard-float에 해당되게 된 것 같습니다.

// AArch64
__Z5func3fff:                           ; @_Z5func3fff
; BB#0:
	fadd	s0, s0, s1
	fsub	s0, s0, s2
	ret	lr

__Z5func419__simd128_float32_tS_:       ; @_Z5func419__simd128_float32_tS_
; BB#0:
	fmul.4s	v1, v0, v1
	fadd.4s	v0, v1, v0
	ret	lr
// AArch32
__Z5func3fff:                           @ @_Z5func3fff
@ BB#0:
	vmov	d18, r1, r1
	vmov	d20, r0, r0
	vmov	d16, r2, r2
	vadd.f32	d18, d20, d18
	vsub.f32	d0, d18, d16
	vmov	r0, s0
	bx	lr

__Z5func419__simd128_float32_tS_:       @ @_Z5func419__simd128_float32_tS_
@ BB#0:
	vmov	d17, r2, r3
	vmov	d16, r0, r1
	mov	r0, sp
	vld1.32	{d18, d19}, [r0]
	vmul.f32	q9, q8, q9
	vadd.f32	q8, q9, q8
	vmov	r0, r1, d16
	vmov	r2, r3, d17
	bx	lr

64bit 화가 직접적인 이유인 건 아니지만, ABI나 스택 프레임을 개량할 수 있다는 것도 실제 퍼포먼스에 영향을 주는게 아닐까 합니다.

실제로 Windows의 x86/x64에서도, 양쪽을 다 써보면 같은 CPU 위에서도 64bit 쪽이 확실히 빠름을 알 수 있습니다. 64bit 성능이 떨어진다는 Core 2에서도 확실히 효과가 납니다.

x64에서 레지스터 수가 두배로 늘어난 것이 가장 큰 원인이겠지만, ABI처럼 소프트웨어 디자인면에서 호환성을 가질 필요가 없다는 점도 커다란 메리트가 됨을 예상할 수 있습니다.

iPhone의 메모리 공간에는 아직 여유가 있습니다만, 퍼포먼스의 향상이나 이용효율을 올려 전력절감으로 유도한다는 의미에서도 iPhone 5s의 64bit 화는 의미가 있다고 생각합니다.

어제 ARMv8 AArch64의 부동소수점 연산속도 비교를 위해 컴파일러의 출력 코드를 조사해본 결과, 그때는 이것↓이 뭔지 몰랐습니다.

	orr.16b	v5, v1, v1

의미없는 or 명령은 레지스터간의 move였습니다. (mov v5,v1)

관련글

+ Recent posts