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

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처럼, 플랫폼을 넘어선 새로운 사양의 등장을 기대합니다.

    관련 페이지

+ Recent posts

티스토리툴바