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

Raspberry Pi 3의 속도비교, Cortex-A53의 속도

(원문 : Raspberry Pi 3 の速度比較, Cortex-A53 の速度)

Raspberry Pi 3를 입수했기에 간단하게 벤치마크를 해봤습니다.

비슷한 스펙의 DragonBoard 410c (Snapdragon 410)가 작년에 발매되었습니다. CPU는 Cortex-A53 1.2GHz quad로 거의 동등, 둘 다 온보드로 Wi-Fi/BT를 탑재했습니다. RAM은 Pi 3 쪽이 살짝 느리고 내장 스토리지도 없습니다만, 가격은 절반 이하입니다. 조금 아쉬운 건 Pi 3의 OS가 32bit라는 것입니다. DragonBoard 쪽은 64bit로 동작합니다.

평소 하던대로 컴파일 시간을 비교해봤습니다. (Time이 작을수록 고속)

DeviceTime
Raspberry Pi 3175 sec ( 2m55s)10.8x
DragonBaord 410c186 sec ( 3m06s)10.1x
Raspberry Pi 2402 sec ( 6m42s)4.7x
Raspberry Pi1893 sec (31m33s)1.0x

역시 DragonBaord 410c와 비슷한 수치가 나왔습니다. SD Card의 차이도 있기에 딱 잘라 말할수는 없습니다만, 초대와 비교하여 대충 10배, Pi 2과 비교해도 2배 이상 고속입니다.

스펙 포함&보다 많은 기기와 비교하면 다음과 같습니다.

DevicecoreclockC/T64RAMTime
Core i7-4790KHaswell4.0GHz4/8Y16GB15 sec ( 0m15s)
Celeron J1900Silvermont2.0GHz4/4Y8GB88 sec ( 1m28s)
Athlon 5350Jaguar2.0GHz4/4Y8GB88 sec ( 1m28s)
Celeron 2955UHaswell1.4GHz2/2Y4GB93 sec ( 1m33s)
Celeron N3150Airmont1.6GHz4/4Y16GB108 sec ( 1m48s)
Raspberry Pi 3Cortex-A531.2GHz4/4N1GB175 sec ( 2m55s)
DragonBaord 410cCortex-A531.2GHz4/4Y1GB186 sec ( 3m06s)
Raspberry Pi 2Cortex-A70.9GHz4/4N1GB402 sec ( 6m42s)
Atom Z540Bonnell1.8GHz1/2N2GB426 sec ( 7m06s)
Raspberry PiARM11760.7GHz1/1N0.5GB1893 sec (31m33s)
NetwalkerCortex-A80.8GHz1/1N0.5GB1902 sec (31m42s)
・C/T = Core 수/Thread 수

vfp benchmark의 비교는 이쪽 (단위는 GFLOPS, 수치가 클수록 빠름)

DevicearchSP-STDP-STSP-MTDP-MT
DragonBoard 410cARMv8A9.4984.74937.96518.603
Raspberry Pi 3ARMv7A9.4312.47737.4429.994
Raspberry Pi 2ARMv7A1.7910.8777.0873.472
Raspberry PiARMv60.6740.6740.6740.674
・SP=단정밀도, DP=배정밀도, ST=SingleThread, MT=MultiThread

어디까지다 최대치이므로 실제 소프트웨어에서는 이정도로 차이가 나지 않습니다만, 잠재력으로 보자면 Pi 2의 5배 이상의 차이가 납니다. (SIMD에서 4배 x clock 차이) 단정밀도에서는 초대 Pi와 비교하여 55배나 빠릅니다. 장래에 64bit에 대응하면 배정밀도 연산도 DragonBoard와 비슷할 정도의 속도로 상승할 것입니다.

Cortex-A53는 big.LITTLE의 LITTLE로 사용됩니다만, 부동소수점 연산에서는 A7에서 대폭으로 확장되어 big core에 가까운 구성이 되었습니다. 아래 슬라이드 사진에서도 「2 배정밀도 MAC / cycle」「4 단정밀도 MAC / cycle」이라는 것을 알 수 있습니다.

또한 하위 모델인 Cortex-A35가 등장예정이고, 이쪽이 본래 Cortex-A7에 상당하는 64bit 프로세서가 될 것이라 생각됩니다.

아래 페이지를 갱신했습니다.

관련글

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

ARM Cortex-A53의 부동소수점 연산속도와 컴파일 시간 비교

(원문 : ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較)

Qualcomm의 DragonBoard 410c를 입수하였기에 vfpbench를 돌려보았습니다.

Snapdargon 410 Cortex-A53 1.2GHz quad core
OSarchSP-STDP-STSP-MTDP-MT
Android 5.1AArch649.3774.73730.81715.063
Android 5.1AArch329.4422.55829.2907.753
  • 단위는 GFLOPS, 수치가 높을수록 고속
  • SP=single fp, DP=double fp, ST=single thread, MT=multi thread

Cortex-A53는 big.LITTE의 LITTLE에 사용되는 코어로, Cortex-A7와 마찬가지로 in-order의 파이프라인을 갖고 있습니다. 하지만 부동소수점 연산의 최고속도는 예상 이상으로 높은 결과를 냈습니다.

위 결과가 사실이라면 Cortex-A7 대비 VFP에서 2배, NEON single에서는 최대 4배 빠르다는 것이 됩니다. 또 동일 클럭 및 최대치만으로 한정하면 big 코어에도 견줄 수 있습니다. 그러나 in-order에 동작 클럭도 낮기 때문에 실제 코드에서는 big 코어와는 상당한 차이가 생길 것이라 생각됩니다. 배정밀도 연산의 병렬성도 떨어지는 것 같습니다.

CPU corearchSP-STDP-STSP-MTDP-MTSoCclock
Cortex-A7armv7a2.3741.1659.4744.653MT81251.2GHz x4
Cortex-A53arm649.3774.73730.81715.063APQ80161.2GHz x4
Cortex-A53armv7a9.4422.55829.2907.753APQ80161.2GHz x4
Cortex-A72arm6415.8647.93431.77115.885MT8173C2.0GHz x2
Cortex-A72armv7a15.8757.94631.75615.882MT8173C2.0GHz x2
Cyclone 2arm6423.56811.75168.59133.968AppleA8X1.5GHz x3
Denverarm6417.9068.76234.88817.601TegraK12.3GHz x2

Linux 상에서 컴파일 속도도 측정해보았습니다. RAM이 적기는 하지만 충분한 속도가 나옵니다. 클럭 차이를 생각해도 데스크탑 CPU와의 차이가 적어지고 있다는 것을 잘 알 수 있습니다.

CPUcoreclockC/TCompilerRAMsec
Core i7-4790KHaswell4.0GHz4C8TClang-3.616GB15
Celeron J1900Silvermont2.0GHz4C4TClang-3.48GB79
Athlon 5350Jaguar2.0GHz4C4TClang-3.68GB88
Celeron 2955UHaswell1.4GHz2C2TClang-3.44GB93
Celeron N3150Airmont1.6GHz4C4TClang-3.616GB108
DragonBoard 410cCortex-A531.2GHz4C4TClang-3.51GB186
Raspberry Pi 2Cortex-A70.9GHz4C4TClang-3.51GB402
Atom Z540Bonnell1.8GHz1C2TClang-3.42GB426
Raspberry PiARM11760.7GHz1C1TClang-3.50.5GB1893
NetwalkerCortex-A80.8GHz1C1TGCC-4.70.5GB1902
* sec = 컴파일 시간(초), 수치가 낮을수록 고속
* Dragonboard 401c = Debian 8.0

RAM이 적은 디바이스는 스토리지 속도의 영향의 크다는 점에 주의하시기 바랍니다. 특히 Raspberry Pi 계열은 SD 카드에 의존하므로 참고만 하시기 바랍니다.

아래 페이지를 갱신했습니다.

관련 글

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

Desktop GPU와 OpenGL ES 3.1 API

(원문 : Desktop GPU と OpenGL ES 3.1 API)

OpenGL ES는 Mobile등에서 사용되는 API지만, Desktop 대상 OpenGL에도 적극적으로 이식되어 호환성을 가지게 되었습니다. OpenGL 4.5에서는 GL_ARB_ES3_1_compatibility를 지원하여, OpenGL ES 3.1 API로도 쓸 수 있습니다.

2015/06/25 현재 Windows에서의 대응상황 (beta driver 포함)

Windows           Desktop API   Mobile API
-------------------------------------------------------------
GeForce           OpenGL 4.5    OpenGL ES 3.1 AEP
RADEON            OpenGL 4.5    OpenGL ES 3.1
Intel 4000 (Gen7) OpenGL 4.0    OpenGL ES 3.1    IvyBridge세대
Intel 4600 (7.5)  OpenGL 4.3    OpenGL ES 3.1    Haswell세대

Intel과 GeForce는 OpenGL ES 3.1 Context를 다시 만들 필요가 있습니다. RADEON의 경우는 OpenGL 4.5 Context 그대로 사용합니다. Desktop GPU에서 OpenGL ES를 사용하는 방법에 대해서는 아래 페이지에 정리해두었습니다.

Intel HD Graphics (D3D11 세대)는 OpenGL 4.5에 대응하지 않지만, 새 드라이버에서 OpenGL ES 3.1에 대응합니다. 구체적으로는 Ivy Bridge 세대의 Intel HD Graphics 4000/2500 이후로, BayTrail의 HD Graphics도 포함됩니다.

Intel HD Graphics 4000 (Ivy Bridge) Windows 8.1 x64

GL_VERSION: OpenGL ES 3.1 - Build 10.18.10.4226
GL_RENDERER: Intel(R) HD Graphics 4000
GL_VENDOR: Intel
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.1 - Build 10.18.10.4226
Intel HD Graphics (BayTrail-T Atom Z3740) Windows 10 x86

GL_VERSION: OpenGL ES 3.1 - Build 10.18.10.3993
GL_RENDERER: Intel(R) HD Graphics
GL_VENDOR: Intel
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.1 - Build 10.18.10.3993
Intel HD Graphics 4600 (Haswell) Windows 10 x64

GL_VERSION: OpenGL ES 3.1 - Build 10.18.15.4235
GL_RENDERER: Intel(R) HD Graphics 4600
GL_VENDOR: Intel
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.10 - Build 10.18.15.4235

GeForce처럼 GL_ANDROID_extension_pack_es31a (AEP)는 없습니다만, Tessellator/GeometryShader 등 일부 기능은 독자적으로 대응이 이루어져있습니다. OpenGL ES 3.1 context에서는 다음 extension이 포함되어 있다는 것을 알 수 있습니다.

GL_INTEL_tessellation
GL_INTEL_geometry_shader

GeForce는 OpenGL ES 3.1 context로 AEP를 지원합니다. 다만 GPU에 따라서는 AEP에서 필요한 일부기능(ASTC Texture)을 소프트웨어로 에뮬레이션하는 것 같습니다. NVIDIA는 Mobile 용으로 GLES Emulator Library를 릴리즈하지 않으므로 그것을 겸하고 있는 것일지도 모릅니다.

RADEON는 OpenGL 4.x 그대로이므로 딱히 기능제한은 없습니다. 따라서 언제든지 GLES API로 OpenGL 4.x에 해당하는 기능을 쓸 수 있습니다.

GPU 별 상세는 아래 페이지에 실어두었습니다. 가능한 범위에서 각 OpenGL ES 3.1 context의 결과도 포함되어있습니다.

관련 글

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

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 별 상세는 이쪽.

관련글

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

Raspberry Pi 2에서 빨라진 컴파일 시간 비교

(원문 : Raspberry Pi 2 で速くなったコンパイル時間の比較)

Raspberry Pi 2를 입수했기에 사용해보았습니다. ARM11인 Raspberry Pi와 비교하면 현격하게 빨라졌습니다.

VFP Benchmark의 비교

               CPU       clock       single fp      double fp
----------------------------------------------------------------
Raspberry Pi B ARM1176   0.7GHz x1   0.674 GFLOPS   0.674 GFLOPS
Raspberry Pi 2 Cortex-A7 0.9GHz x4   7.087 GFLOPS   3.472 GFLOPS

ARM11세대 VFP와 비교하면 core당 2.6배(단정밀도시, 클럭차 포함).

상세결과는 아래에 추가했습니다.

Cortex-A7은 big.LITTLE에서도 전력절약용 core로 사용되며, 개별 성능은 그다지 높지 않습니다.

그럼에도 엔트리 클래스의 스마트폰이나 태블릿에서는 같은 Cortex-A7 Quad core의 기기가 다수 나와있습니다. Snapdraogn 400 MSM8926/8226이나 MT8125/8389/6582 등, 나름대로 밸런스가 좋은 구성이라 생각합니다.

아래는 제가 작성한 라이브러리(flatlib3)의 빌드시간 비교입니다. 36분에서 5분 30초라는 현실적인 수치가 되었습니다. SD Card의 속도에 의존하므로 아주 정확하지는 않지만, 대충 6.6배가 나와 공식수치대로라고 할 수 있겠습니다.

                                Clock  core  ISA    RAM    gcc-4.8 clang-3.4
---------------------------------------------------------------------------
(1) Raspberry Pi B ARM1176JZF   0.7GHz x1    armv6l 0.5GB   36m18s
(2) Raspberry Pi 2 Cortex-A7    0.9GHz x4    armv7l   1GB    5m29s
(3) Nexus 7 2012   Cortex-A9    1.3GHz x4    armv7l   1GB    3m42s
(4) Atom Z540      Bonnell      1.8GHz x1+HT x86      2GB    6m23s   6m18s
(5) BayTrail-D J1900 Silvermont 2.0GHz x4    x86_64   8GB    1m30s   1m11s
(6) Athlon-5350    Jaguar       2.0GHz x4    x86_64   8GB    1m33s   1m10s
(7) Core i7-2720QM SandyBridge  2.2GHz x4+HT x86_64  16GB    0m31s   0m24s

・36m18s = 36분18초
・값은 실행시간(3회의 평균). 수치가 작을 수록 고속.

Raspberry Pi 2에서 그냥 빌드하면 ARMv6의 바이너리가 생성되므로, gcc-4.8 -march=armv7-a mfpu=neon-vfpv4의 옵션으로 컴파일했습니다.

아래는 각 기기의 상세 내용입니다.

(1) Raspberry Pi model B
BMC2835 ARM1176JZF 0.7GHz x1
RAM 512MB, SD 16GB
Debian wheezy armv6l (console)


(2) Raspberry Pi 2 model B
BMC2836 Cortex-A7 0.9GHz x4
RAM 1GB DDR2, SD 16GB
Debian wheezy armv7l (console)
gcc-4.8 (-march=armv7-a mfpu=neon-vfpv4)


(3) Nexus 7 (2012)
Tegra 3 T30L Cortex-A9 1.3GHz x4
RAM 1GB DDR3L, 8GB
Ubuntu 13.04 armv7l (console)


(4) VAIO Type P
Atom Z540 Bonnell 1.86GHz x1+HT
RAM 2GB, SSD 64GB
Ubuntu 14.04LTS x86 (console)


(5) Desktop PC
BayTrail-D Celeron J1900 Silvermont 2.0GHz x4
RAM 8GB, HDD
Ubuntu 14.04LTS x86_64


(6) Desktop PC
Athlon-5350 Jaguar 2.0GHz x4
RAM 8GB, HDD
Ubuntu 14.04LTS x86_64


(7) Desktop PC
Core i7-2720QM SandyBridge 2.2GHz x4+HT
RAM 16GB, HDD
Ubuntu 14.04LTS x86_64

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

관련 글

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

Android Wear Sony SmartWatch 3 SWR50는 빠르다

(원문 : Android Wear Sony SmartWatch 3 SWR50 は速い)

Sony SmartWatch3의 vfpbench 스코어를 보내주신 분이 계십니다. LG G Watch (LG-W100)보다 빠르며, 실제로 1.2GHz로 작동하는 것으로 판단됩니다. 아직 제대로 확인하지는 않았습니다만 2 core가 살아있을 가능성도 있습니다.

// SmartWatch 3 SWR50
// MSM8226 Cortex-A7 1.2GHz x4 (1.2GHz x2?)

ARCH: ARMv7A
CPU core: 4
VFP: VFPv4-D32 NEON
FMA: Yes
NEON: Yes
Result
  SingleT SP max:  2.257 GFLOPS
  SingleT DP max:  1.144 GFLOPS
  MultiT  SP max:  4.946 GFLOPS
  MultiT  DP max:  2.278 GFLOPS

Motorola Moto 360이외에는 전부 같은 Snapdragon 400 (MSM8226)의 나열이었습니다만, 예상외로 차이가 있는 것 같습니다.

device                SoC             CPU       SoC의 spec  실질
----------------------------------------------------------------------
LG G Watch   LG-W100  Snapdragon 400  Cortex-A7 1.2GHz x4   0.8GHz x1
LG G Watch R LG-W110  Snapdragon 400  Cortex-A7 1.2GHz x4   ?
Galaxy Gear Live      Snapdragon 400  Cortex-A7 1.2GHz x4   ?
ASUS ZenWatch WI500Q  Snapdragon 400  Cortex-A7 1.2GHz x4   ?
SmartWatch 3 SWR50    Snapdragon 400  Cortex-A7 1.2GHz x4   1.2GHz x2?
Motolora Moto 360     TI OMAP3630     Cortex-A8 1.0GHz x1   1.0GHz x1

마찬가지로 Motorola Moto 360의 결과도 받았기에 아래에 정리합니다. 스코어로 보아 이쪽은 Cortex-A8의 1.0GHz로 움직이는 물건이라 보여집니다.

device (4.4W.2)       SP-ST   DP-ST   SP-MT   DP-MT
-----------------------------------------------------------
LG G Watch LG-W100    1.419   0.742   1.367   0.676  GFLOPS
SmartWatch 3 SWR50    2.257   1.144   4.946   2.278  GFLOPS
Motolora Moto 360     3.739   0.126   3.376   0.125  GFLOPS

  * SP=단정밀도, DP=배정밀도, ST=SingleThread, MT=MultiThread

언뜻 Moto 360가 가장 빠른 것처럼 보일지도 모릅니다. 최대값이 돌출되어있는 것은 Cortex-A8가 64bit 폭의 NEON ALU를 갖고 있기 때문입니다. (Cortex-A7는 32bit폭)

실제로는 세대가 오래된 SoC를 채용하고 있으며 Moto360의 CPU Core도 몇세대 전의 물건입니다. 배정밀도(DP)의 결과를 보면 알 수 있듯, VFP 연산에서는 다른 CPU의 1/5 이하의 속도입니다. 부동소수점 연산을 많이 사용하는 일반적인 애플리케이션(NEON 미사용)에서는 아마 Moto 360 쪽이 느릴겁니다. 이에 관한 것은 VFP Bencmark에서 명령별 수치를 비교해보면 잘 알 수 있습니다.

자세한 로그를 다음 페이지에 추가했습니다.

만약 다른 장치의 로그를 갖고 있는 분이 계시다면 꼭 보내주시기 바랍니다.

관련 글

+ Recent posts