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

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의 새 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 성능이 매우 높음

    관련글

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

    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 정정:

    ※ 이 글은 impress watch 에 실린 컬럼을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

    최근의 태블릿/스마트폰용 SoC 제 4회~괴롭지만 SoC 비즈니스에 매진하는 Intel과 NVIDIA

    (원문 : 今どきのタブレット/スマートフォン向けSoC 第4回~苦しみながらもSoCビジネスに邁進するIntelとNVIDIA)

    지금까지 소개해온대로, 스마트폰/태블릿 시장은 ARM 천하, 더 정확하게 말하면 ARM 생태계의 천하가 되었고, 그 이외의 플레이어가 들어오기에는 굉장히 어려운 상황이다. 그럼에도 여기에 적극적으로 진입을 시도하는 벤더가 둘 있다. 말할것도 없이 Intel과 NVIDIA이다. 마지막회가 되는 이번회에는 그 양사의 움직임을 소개할까 한다.

    IA/x86으로 ARM 생태계와 싸우는 Intel


    2003년에 발표된 「PXA800」

    Intel은 휴대전화에 흥미가 없지는 않았다. 1997년, Intel은 구 DEC과의 특허소송의 화해조건으로써 「StrongARM」의 제품 포트폴리오를 얻는다. 당시 이 StrongARM은 COMPAQ의 「iPAQ」시리즈 등의 PDA에 이용되는 것을 시작으로 나름대로 수요를 얻게 되는데, 여기서 "배팅 금액을 두배로 올리는" 것이 인텔 스타일. StrongARM은 ARM v4 기반의 제품이었지만, 1999년에 ARM에게서 ARM v5의 아키텍처 라이선스를 입수. StrongARM을 기반으로 내부를 완전히 뜯어고친 「XScale」을 완성시킨다.

    이 시점에서 Intel의 계획은 지금과는 조금 다른 것이었다. PDA 시장은 나름대로 성장하고 있었지만 새 아키텍처 제품 라인을 유지하기에 충분하다고는 할 수 없는 출하량이었다. 그래서 휴대폰 시장에도 XScale을 투입함으로써 셰어의 확대 + 장기적인 매상 확보를 노리는 것이 속마음이었을 것이다.

    이를 목표로 2003년, GSM/GPRS에 대응한 「PXA800」이라는 칩을 화려하게 발표한다. CPU 코어는 XScale, 베이스밴드에 관한 부분은 ADI(Analog Devices Inc.)에서 라이선스를 받아 DSP를 입수, 이것을 「Intel MicroSignal Architecture」로 실장했다. 당시에는 아직 Intel 자신이 플래시 메모리 부분을 보유하지 않았기에 이것도 실장. 거기에 SRAM을 4.5Mbit나 실장하는, 130nm 공정으로는 사치스럽다고 해야할지 욕심을 잔뜩 부린 사양의 SoC였다. 또 PXA800의 발표 이전에 발매한 「PXA210」도 피처폰용으로 투입할 계획이었다.

    이미 알고 있겠지만 PXA210이나 PXA800을 채용한 휴대폰 메이커는 단 한곳도 없었고, PXA800의 후계인 「PXA900」이 RIM의 「Blackberry 7800」등 몇 기종에 채용되는 정도였으며, 그 수량도 그렇게 많지는 않았다. 그 결과, Intel은 XScale 아키텍처 자체를 포함한 PXA의 제품 라인을, 여기에 관련된 인원까지 통채로 Marvell에 매각해버린다. 여기서 한번 휴대폰용 비즈니스는 완전히 좌절되었다.


    PXA800의 상세


    피처폰용 「PXA210」

    이런 뼈아픈 경험에도 불구하고 Intel이 다시 휴대폰 시장에 참가한 이유는, 이것도 알고 있겠지만 PC 시장의 축소경향 때문이다. 현시점에서 Intel의 경쟁력의 원천은 자사의 Fab에 의한 우수한 공정기술이다. 하지만 이 우수한 공정기술을 유지하기 위해서는 막대한 비용이 들어간다. 이는 단순히 공정을 개발하는 것만이 아니라, 양산을 위한 설비 비용도 점점 올라가고 있기 때문이다. 지금까지는 판매가격이 높은 PC용 프로세서를 대량으로 출하하는 형태로 커버할 수 있었다. 하지만 PC용 프로세서의 출하수량 자체가 쇠퇴경향을 보이는 현재로는

    • 차세대 공정 노드용 개발에 필요한 비용이 상승하여 프로세서 1개당 차지하는 개발/설비 비용도 상승. 반면 판매가격은 오히려 내려가고 있는지라 점점 이익이 줄어들어간다.
    • 순수하게 출하수량이 줄면 그만큼 Fab의 가동률이 내려가게 된다. 특히 Intel의 경우, 「Copy Exactly」라 불리는 복수 Fab에서 양산하는 방식을 전제로 생산라인의 개발이나 기기 발주를 하는데다, 애초에 자사 제품만을 생산하므로 소품종/다량이라는 형태의 양산이 된다. 그러므로 PC용 프로세서의 출하량이 줄어들었을때 다른 제품으로 메우기가 어려우며, 그대로 가동률 저하로 이어진다.

    는 문제를 노출하게 된다.


    PC 시장과 스마트폰/태블릿 시장의 역전 (JEDEC의 자료에서)

    사실 Intel은 비교적 조기에 이런 문제를 알고 있었다. 애초에 2008년에 투입된 Atom은 당초부터 스마트폰용으로 투입될 것을 상정하고 있었고, 이를 위해 「Moorestown」플랫폼도 빠른 시기에 발표되었다. 그렇지만 이 Moorestown이 투입된 것은 2년 늦은 2010년이었다. 이유는 두가지다.

    하나는 CPU측(Lincroft)가 재설계된 코어였다는 것이다. Lincroft의 기반이 된 Silverthorne은 순수하게 CPU만 있는 다이였지만, 스마트폰등을 대상으로 하려면 역시 GPU 통합이 필요하다. 최종적으로는 「Intel GMA 600」이라는 GPU를 통합했지만, 사실 이것은 Imagination의 「PowerVR SGX」였으며, 통합작업에 1년 이상을 요하게 되었다. 일반적으로는 Silverthorne의 개발과 병행하여 Lincroft의 개발작업이 진행되었으리라 생각하지만, 당시 Intel은 Atom을 이용하여 광범위한 제품 라인업을 제공할 예정이었으며, 필자는 개발측의 리소스가 부족한 게 원인아니었을까 생각한다.

    또 하나는 45nm 세대의 SoC 공정 구축에 사실상 실패한 것이다. 고속 로직 대상 45nm 공정인 「P1266」은 2007년에 제공을 개시하고, 이 뒤를 이어 SoC 대상인 「P1267」을 2008년에 출시할 예정이었다. 당초 Lincroft는 이 P1267을 사용하여 제공할 예정이었다고 한다. 실제로 저전력을 추구한다면 고속 로직 대상인 P1266보다 P1267 쪽이 맞다. 하지만 Intel은 이 P1267의 개발에 사실상 실패. 이것을 채용한 것은 정말 극히 일부 제품에 머무르며, Lincroft만이 아니라 같은 SoC 공정을 사용하는 PC용 칩셋도 전부 32nm SoC용 「P1269」가 나올때까지 기다리는 처지가 되었다. 그 결과, Lincroft는 2010년에 투입되었음에도 동작주파수는 1GHz 전후(하이엔드인 Z625도 간신히 1.9GHz)밖에 되지 않았다. 2010년이라고 하면 40nm에 2GHz로 구동하는 Dual/Quad Cortex-A9 기반의 SoC가 나오고 있던 시기이며, 상품경쟁력이 전무하다고는 할 수 없어도 상당히 낮다고는 할 수 있다.



    Atom 시리즈 발표 당시부터 Moorestown으로 스마트폰 시장을 상정하고 있었다.

    다만, 45nm SoC에서 오랫동안 트러블을 경험한만큼 32nm의 P1269나 22nm의 「P1271」에서는 비교적 스무스하게 개발이 진행된듯, 2012년에는 기본적인 구성은 크게 바꾸지 않은 채 P1269를 사용한 「Medfield」가 등장, 거기에 2014년에는 CPU 코어의 마이크로아키텍처를 쇄신하고 P1271를 탑재한 「Merrifield」가 투입될 예정이다.

    Medfield/Merrifield 모두 기본적인 아키텍처는 태블릿용인 「Clover Trail」이나 「Bay Trail」과 마찬가지로, 동작주파수나 소비전력을 스마트폰용으로 맞춘 정도의 물건이다. 참고로 Merrifield의 존재 자체는 2013년 6월의 COMPUTEX에서 소개되었지만, 제품 레벨의 상세 내용은 2014년 2월의 MWC로 미루어져, 공식으로는 아직 발표되지 않았다. 하지만 기본적으로는 Bay Trail과 같기에, 이미 제품은 스마트폰 벤더에게 넘겨져 실장이 어느 정도 끝나있을 것인지라, MWC가 열리는 타이밍에는 탑재제품도 발표되지 않을까 한다.


    Medfield의 블럭 다이어그램


    차기 스마트폰용 SoC 「Merrifield」

    자, 예전에 앞으로의 로드맵을 나타낸 것이 다음 그림이다. 원래 베이스가 되는 Atom 코어 자체가 현재 22nm인 「Silvermont」에서 14nm 세대인 「Airmont」(Silvermont의 14nm공정 슈링크판)으로 바뀌는 것에 대응하여, 이 코어를 탑재한 「Moorefield」가 투입된다는 이야기는 예전에도 있었지만, 2013년 11월의 Investor Meeting에도 좀 더 이후의 이야기가 나왔다.


    Intel이 예전부터 공표한 로드맵

    먼저 2014년을 보면 전반에 Merrifield, 후반에 Moorefield가 투입되는 것은 기정사항이다. 하지만 이와는 별도로 「SoFIA」라 불리는 새로운 코어가 로우엔드용으로 투입된다. 이 SoFIA는 3G 모뎀을 내장한 제품이지만, 2015년에는 하이엔드로(Airmont의 후계로 기능을 강화한) 「Goldmont」코어를 내장한 「Boxton」, 로우엔드로는 내장 모뎀을 LTE 대응으로 바꾼 「SoFIA LTE」가 각자 투입되게 된다. 이 결과, 2015년에는 라인업이 매우 충실해진다.


    11월 Investor Metting에서 공개된 로드맵. 2014년 후반에 「SoFIA」라 불리는 로우엔드용 코어가 제공된다.


    2015년에는 「Boxton」, 「SoFIA LTE」도 투입


    2015년의 태블릿용 라인업

    재미있는 것은 이 SoFIA가 Intel 사내에서 제조하는 것이 아니라는 것이다. 명확히 표시되지는 않았지만 지금까지의 경위를 생각하면 TSMC에서 20nm 공정 혹은 16nm FinFET 공정으로 제조될 것 같다(필자는 전자의 가능성이 높다고 생각한다). 이러한 움직임은 처음 설명한 「Fab의 가동률을 높이는 것」과 정면으로 대립되는 것이지만, 이에 관해서 CEO인 Brian Krzanich 씨는 「우리는 현실적으로 생각해야한다」고 이야기했다. Intel의 Fab은 확실히 높은 기술을 자랑하지만, 그 반면 생산에 요하는 코스트도 높다. 즉 판매가격을 높게 잡을 수 있는 Boxton은 그렇다치고, 저가격제품용인 SoFIA까지 제조하면 비용을 맞추지 못하게 된다. 그렇기에 SoFIA는 외부 파운드리를 쓰기로 했다,는 말이리라.

    이 배경도 역시 Investor Meeting에서 밝혀졌다. PC나 데이터서버 부문에서는 나름 흑자를 내고 있고 소프트웨어/서비스도 적자는 아니었지만, 그에 반하여 태블릿이나 스마트폰 부문은 명확한 적자였기 때문이다. 매상이 40억 달러인데 반해 영업이익은 25억달러 적자. 이렇게 되면 아무리 종합적으로는 흑자액이 많다고는 해도 부문 존속을 위해서는 뭔가 수를 써야 한다. 그 방법론의 하나로, 원가율을 낮추기 위해 제조를 외부위탁할 수 밖에 없었던 것이다.


    「그 외 IA 제품」, 즉 스마트폰이나 태블릿 부문이 적자가 되어있다.

    그럼, 여기서 손을 쓰면 Intel의 스마트폰용 SoC는 안녕할 것인가?하면 상당히 의심스럽다는 것이 솔직한 마음이다. 2회의 Qualcomm 항목에서도 설명했듯, 일단 스마트폰 시장에 들어가려는데 모뎀이 없으면 가격경쟁력이 현저하게 떨어진다. 그래서 힘내서 모뎀을 내장했다. 하지만 이미 그것만으로는 차별화 요인이 되지 못한다. 3회에서도 소개했듯, Spreadtrum이나 HiSilicon의 저가격 SoC들조차 모뎀을 내장하고 있으며, 이들과 호각으로 승부하려 한다면 상당히 힘든 싸움이 된다. Intel이 주로 Atom 기반 SoC의 높은 성능을 어필하는 것은, 그쪽으로밖에 승부할 수 밖에 없기 때문이라는 이면도 있다.

    더 심각한 문제는, 이렇게까지해도 Intel의 SoC에는 매력이 그다지 없다는 점이다. 이 문제는 스마트폰용에서 특히 현저해진다. 이는 ARM 대 Intel의 대립이란 실제로는 성능이나 명령어셋이 아니라 생태계의 대립이며, 휴대폰용 메이커에 있어서 Intel의 생태계는 매력적이지 않다,는 점에서 이야기는 끝난다.

    Intel의 생태계란, 딱잘라 적자면 Intel(과 Microsoft)의 단독 승리가 예정된 생태계다. 이는 오랜 시간에 걸쳐 Intel과 Microsoft가 높은 영업이익률을 매년 유지해온 반면, PC 벤더의 영업이익률은 몇 %에 그마저 앞부분은 저공비행했던 걸 생각해보면 이해하기 쉬울거라 생각한다. 그에 반해 ARM 생태계의 경우에는 이익의 태반은 기기 벤더의 손에 들어간다. 일단 SoC의 원가율은 대략 5% 정도,라고 생각하면 이것도 이해하기 쉬울거라 생각한다. 휴대폰 벤더에 있어 어느쪽 비즈니스가 바람직한지는 말할 필요도 없다.

    하는 김에 적어두자면, 실은 성능면에서의 차이라는 건 기기 메이커에 있어 그렇게 중요한 부분은 아니다. 이 부분은 실장 방식에 따라 최종적으로 어떻게든 변하기 때문이다. 물론 10배나 100배 정도되는 성능차가 있으면 이야기는 달라지겠지만, 수십% 차이는 실제로는 최종제품에서는 큰 차이가 되지 않는다. 제품기획을 위해 독자적인 상주 소프트를 넣거나 하는 것만으로도 배터리 수명이나 성능에 영향을 끼치기 때문이다.

    또, SoC의 경우 일단 정격 스펙은 있지만 실제로는 기기 벤더가 동작주파수나 구성을 자유롭게 고칠 수 있고, 실제로 상품기획에 맞춰 세세하게 변경되므로 레퍼런스 성능 그대로 나오는 일은 일단 없다. 물론 최종적으로는 성능이 엔드 유저의 조작감이라는 형태로 영향을 미치겠지만, 일반적으로 사람의 감각은 대수에 비례하는지라 10배의 성능이 나오면 대충 「2배정도 빠르다」는 감각. 수십%의 성능차라면 거의 인식하지 못하는 게 현실이다. 이런 상황에서 Intel SoC의 장점으로 드는 「높은 성능」은 그다지 차별화를 위한 무기는 되지 못하는 것이다.

    물론 태블릿용으로는 나름대로 셰어를 확보하고 있지만, 이것은 「Windows 8/8.1이 움직이는 것은 현실문제로 x86밖에 없다」는 사정에 의한 것이다. Windows RT의 보급이 진행되지 않아 Windows 계의 태블릿에서는 다른 선택지가 없어져버렸다. 반대로 Android를 움직이는데 x86일 필요는 없다는 상황에는 아무런 타격을 주지 못하고 있는 것이 현실로, Windows의 힘이 미치지 않는 스마트폰 분야에서의 존재감은 여전히 굉장히 희미하다. 기댈 대상이던 Microsoft도 또 Windows Phone 부진으로 고민, 게다가 대응 플랫폼은 ARM 뿐. 기사회생책이어야했던 Tizen은 계속 늦어지고 있다. 전해듣는 말로는 2014년 2월의 MWC에서 첫 Tizen 탑재 스마트폰이 등장할 것"같다"지만, 과연 이것이 어떤 기폭제가 될 수 있을지 현시점에서는 판단하기 힘들다.

    Intel이 스마트폰 분야에서 어느 정도의 셰어를 획득하기 위해서는, 우선 생태계(비즈니스 모델) 방식을 고쳐야 할 것이다. 설령 거기까지는 했다고 해도, 앞서 이야기한 Fab의 가동률 저하나 전체적인 이익률 저하라는 근본적인 문제의 해결로는 이어지기 힘들다. 그렇다고 여기서 손을 떼버린다면 추락하는 것밖에 남지않는, 굉장히 고통스러운 방향전환을 강제받는 것이 현재 Intel의 스마트폰용 SoC 비즈니스인 것이다.

    x86에서 ARM으로 축을 옮긴 NVIDIA

    이어서 NVIDIA다. NVIDIA가 이용하는 CPU 코어는 ARM 기반이므로, 정확하게는 기사 앞머리에 이야기한 「ARM 생태계 이외의 플레이어」라는 표현은 약간 맞지 않는다. 하지만, ARM 생태계에서는 CPU에 중심을 두는 것에 반해 NVIDIA는 GPU를 중핵에 놓고 있다는 점이 다른 생태계 파트너와 다른 점이다.

    그 NVIDIA의 휴대폰/PDA용 솔루션 최초의 물건은 2003년에 발표한 「GoForce 2150」이다. 원래 이 제품은 2003년 8월에 매수한 MediaQ라는 벤더가 개발하던 휴대폰용 2D Graphics + 카메라 인터페이스의 SoC인 「MQ2100」을 기반으로 한 것으로, 아직 NVIDIA의 독자적인 색깔은 아직 없었다.

    이를 이어 동사는 3D 렌더링 기술을 탑재한 「GoForce 4500/4800/5300/5500」같은 제품을 내놓는다. 이 3D 렌더링 기법은 타일 기반이라는 것 이상의 자세한 내용은 알 수 없다. NVIDIA는 2000년에 3dfx를 매수하였는데, 이 3dfx는 같은 2000년에 GigaPixel이라는 메이커를 매수한다. 이 곳은 휴대폰 등에 맞는 타일기반의 렌더링 엔진을 개발하였고, 1999년에는 MFP(MicroProcessor Forum) 회장에서 「Quake 2」의 동작 데모가 움직일 정도의 완성도였다. 최종적으로 이 GigaPixel의 기술이 어느 정도나 NVIDIA에서 이용되었는지는 알 수 없지만, GoForce 4500 등의 내부가 이것을 기반으로 했다고 해도 그다지 신기한 일은 아니다.

    2003년에 발표된 GoForce 2150을 탑재한 PDA와 휴대폰


    GoForce 4500 등은 타일기반의 3D 기법을 채용했다


    3dfx가 매수한 GigaPixel은 타일기반의 렌더링 기법으로 Quake 2의 동작까지 실현했다.

    이렇게 계속 GoForce를 제공해온 NVIDIA지만, 휴대폰에서 GPU를 외장하는 구성은 실장면적에서 불리하다는 건 말할 필요도 없다. 그래서 GoForce의 최종제품인 「GoForce 6100」에서는 애플리케이션 프로세서로 ARM 1176JZ-S 코어를 탑재하고, 나머지는 모뎀만 접속하면 스마트폰 완성,이라는 부분까지 집적도를 높였다. 이 GoForce 6100이 발표된 것은 2007년 2월의 MWC 회장이지만, 그 4개월 후에는 400MHz로 동작하는 ARM11을 탑재한 iPhone이 투입된다. 아무래도 성능면에서 나름 체감성능차가 있기도 해서, 채용사례는 그리 많지 않았다.

    자, 이 무렵부터 NVIDIA를 둘러싼 환경이 조금씩 변해온다. 이 무렵에 NVIDIA는 GPU 카드 사업만이 아니라 칩셋 비즈니스에도 힘을 쏟고 있었다. GPU 카드를 사용하려면 성능이 좋은 칩셋이 필요하고, 특히 SLI 구성이라도 하게 되면 PCI Express 슬롯을 2개 쓰게 되므로, 이쪽을 타겟으로 한 칩셋은 나름 잘 팔렸다. 또 당시의 CPU는 GPU를 내장하지 않았으므로, 성능이 좋은 GPU 통합칩셋에 대한 수요도 꽤 있었다.

    하지만, 여기서 흐름이 이상하게 된다. 우선 Intel과의 사이에서 버스 라이선스에 관한 교섭에 난항을 겪게 되고, 겨우 P4 버스의 라이선스를 얻어 출하할 수 있게 되자 중요한 Intel이 QPI & DMI로 CPU 인터페이스를 변경해버리고, 거기에 Intel은 이런 인터페이스의 라이선스 계약을 단호하게 거절함으로써 최신 CPU용 칩셋을 제공할 수 없게 되어버린다. 덤으로 Intel은 GPU를 CPU측에 통합하기 시작해, GPU 카드의 수요자체도 줄고 있었다.

    더 극단적인 것은 AMD용으로, 마켓 셰어를 반영해서 원래 Intel용 정도의 수량을 내지 않았던데다가 2006년에 AMD가 ATI Technologies를 매수. ATI가 제공하던 칩셋을 AMD 자신이 제공하게 됨으로써, NVIDIA의 셰어는 크게 줄어들게 된다. AMD도 역시 CPU를 GPU에 통합하는 방향성을 확실히 하였기에, NVIDIA의 칩셋 사업의 앞날은 점점 알수 없게 된다. 이런 동향에 따라 NVIDIA는 2010년에 최종적으로 칩셋 사업에서 철수하게 되지만, 그 이전 타이밍에 플랫폼을 종래의 x86에서 ARM으로 전환하기로 결단한다. x86 베이스로는 출하수량이 점점 작아지리라는 것은 명백했고, 새로운 시장을 얻기 위해 ARM으로 전환하기로 결단을 내린 것이다.

    이에 따라 2008년에 첫 「Tegra」를 출시한다. 원래 이 Tegra는 말하자면 GoForce 6100의 연장선상에 있는 제품으로 성능면에서 충분하다고는 할 수 없었다. 그래서 CPU 코어를 Cortex-A9으로 전환함과 동시에 듀얼코어화한 「Tegra 2」를 2010년에 투입한다. 이쪽은 Google의 Honeycomb의 레퍼런스가 되어 많은 태블릿에 채용되고, 괜찮은 출발이 되었다.

    하지만 2011년 11월에 발표된 「Tegra 3」는 Google의 리드 디바이스인 「Nexus 7(2012)」에 채용되는 등 처음 평판은 나쁘지 않았지만, 점점 속도를 잃게 된다. 그 최대 이유는 CPU를 강화했음에도 GPU 코어의 성능개선이 충분하지 않았기 때문이다. 확실히 Tegra 2와 비교하면 성능은 개선되었지만, 이 무렵에는 경합하는 SoC 모두가 GPU 성능을 강화했으며, 결과적으로 GPU의 성능은 어드밴티지가 되지 않았다. 또, 태블릿에서는 어느 정도 채용예를 획득했지만, 스마트폰용의 채용예는 그리 많지 않았다. 실제로 이 당시 Tegra 3, 혹은 Texas Instruments의 「OMAP 4」를 스마트폰에 채용한 메이커의 다수가 「실은 Snapdragon을 채용하고 싶었지만 Qualcomm의 공급이 부족해서 어쩔수 없이 Snapdragon 이외를 검토할 수 밖에 없었다」는 소극적인 이유에 의한 것으로, Snapdragon의 공급이 회복되자 급속도로 쪼그라든 것은 무리도 아니었다.

    또, NVIDIA도 모뎀이 없으면 이야기가 안된다는 것은 Tegra 2 세대에 이미 인식하고 있었던 듯 하지만, 당시에는 아쉽게도 모뎀 관계 기술의 축적은 전무했다. 결국 동사는 2011년에 영국의 Icera라는 베이스밴드 모뎀을 제조하는 회사를 매수. 이것을 기반으로 「Tegra 4」 세대에 겨우 모뎀을 제공할 수 있게 되었다. 그 Tegra 4는 2013년에 발표되었지만, 현재 채용사례는 동사의 레퍼런스 디자인인 Phoenix나 중국 Xiaomi 등, 극히 일부밖에 없는 상황이다. OEM 메이커에 대한 출하는 이미 개시되었기에 2014년의 MWC에서는 다른 회사에서도 나올 가능성이 있지만, 현시점에서는 상당히 난항을 겪고 있다. 이 역시 이유는 명백하여, NVIDIA 모뎀의 캐리어 인증이 전혀 끝나지 않았기 때문이다. 이 점에서 통신기기 메이커와 얽혀있는 HiSilicon이나 애초에 통신관계 비즈니스 역사가 길고, 거기에 자본력을 살린 역량으로 인증을 진행하고 있는 Intel과 달리, NVIDIA에게는 그런 경험의 축적도 엔지니어도 없고, 캐리어 인증에 그만큼 비용을 들일 수도 없다.


    Tegra 4와 스마트폰용인 Tegra 4i의 개요

    여기부터는 필자의 주관이지만, NVIDIA가 「Shield」나 「Tegra Note 7」같은 제품을 연이어 내놓는 것은, 일단 캐리어 인증을 따낼 때까지 스마트폰용 출하를 기대할 수 없고 스마트폰 이외의 Tegra 4의 채용사례를 늘려놓지 않으면 이도저도 못한다,는 상황에 빠졌기 때문이 아닐까 한다. 적어도 현재로서는 NVIDIA의 SoC 비즈니스가 순조로운가 묻는다면 고개를 가로저을 수 밖에 없다.

    포스트 PC 시대를 향해 ARM 생태계 안에서 GPU를 판다,는 비즈니스의 큰 틀은 틀리지 않았다고 생각하지만, 거기서 IP를 파는 것이 아니라 실리콘(반도체)를 파는 것을 골랐기에 고생하게 된 것이 NVIDIA의 현재 모습이다. 그렇다면 NVIDIA도 IP판매에 매진했어야 했는가 묻는다면, ARM의 Mali나 Imagination의 PowerVR을 밀어내고 채용을 획득할만한 생태계 구축에도 역시 그만한 비용과 수고가 드는지라 어느쪽이든 가시밭길이었으리라. 지금은 괴로워하면서도 경험을 쌓아나가는 단계, 라는 것이 바른 인식일지도 모른다.

    참고로 NVIDIA가 이 시장에서 철수할 기척은 없으며, 차세대 코어로 「Logan」, 차차세대 코어로 「Parker」를 각자 개발중이다. 특히 「Parker」는 동사가 ARM v8의 라이선스를 받아 자사에서 아키텍처부터 설계한 「Denver」코어를 기반으로 하고 있는 모양이다. 과제는 마찬가지로 ARM v8 아키텍처 라이선스를 받은 Broadcom이나 APM, Apple같은 기업과 달리, 자사에서 CPU 아키텍처를 설계한 적도 없으며 공식적으로 그런 회사를 매수하지도 않았다는 것이다. 소문으로는 2009년 쯤에 실리콘 밸리에서 CPU 설계자를 널리 채용하여, x86 설계팀 1개팀 분을 손에 넣었다는 보도가 흐른 적은 있다. 이것이 사실이라면 개발 리소스는 있다고 할 수 있지만, 이 부분은 명확하지 않다. NVIDIA의 SoC 비즈니스도 Intel과 마찬가지로 괴로워하면서도 계속하고 있다고 하는 것이 정확한 표현이 아닐까.


    NVIDIA SoC의 로드맵

    + Recent posts