유니티 공식 가이드

유니티에서 제공하는 문서의 내용을 참조

에디터 로그

  • 빌드 후 콘솔 창 오른쪽 상단의 드롭다운 메뉴 클릭 후 Open Editor 선택
  • 로그 파일을 보면서 필요없는 파일이나 제대로 조정되지 않은 리소스가 포함되지 않았는지 확인

텍스처

  • 텍스처 원본의 사이즈를 줄일 필요는 없고, 인스펙터의 임포트 세팅에서 사이즈를 변경
  • 플랫폼 별로 알맞은 압축 방식을 지정. 유니티에서 사용되는 텍스처 포맷에 대한 설명은 이 문서를 참조

DLL

  • Stripping Level의 설정을 Strip Assemblies 이하로 설정 시 사용하지 않는 어셈블리(dll 파일)을 빌드파일에 포함하지 않음.
  • 문서를 보면 특정 컨테이너는 System.dll에 포함되므로 그런 컨테이너를 피하라고 적혀있음.
  • 정확하게는 List, Dictionary와 그에 관련된 컬렉션 컨테이너 이외에는 모두 System.dll에 포함(LinkcedList, Stack, Queue, SortedDictionary 등)
  • 하지만 Unity 5 이후에는 UnityEngine.dll이 System.dll과 System.Core.dll을 참조하므로 빈 프로젝트를 빌드해도 두 어셈블리가 포함되는 것을 막을 수 없음.
  • 실제로 빌드해보면 어셈블리 자체는 들어가있으나, Stripping Level을 설정하는 경우 Disabled로 설정했을 때보다 확실히 작아진 어셈블리가 포함됨[각주:1]

다중 APK 지원 이용

대상 디바이스로 FAT(arm + x86)을 지정하면 두 플랫폼용 라이브러리가 같이 들어가서 용량이 커짐. 조금이라도 용량을 줄이고 싶다면, 플랫폼별로 따로 빌드하는 것도 고려해볼 수 있음. 다행히 구글 플레이에서는 한 앱에 기능별로 다른 APK를 제공할 수 있는 기능이 있음.

다중 APK 지원을 위한 기본 규칙

  1. 모든 APK는 패키지 명이 같아야 하고, 같은 인증키를 사용하여 사인되어야 함.
  2. APK 별로 버전 코드가 서로 달라야 함.
  3. API level이 높을수록 버전 코드가 높아야 함.
  4. 높은 버전 코드에서 낮은 버전 코드로 업데이트할 수 없음.

이상의 규칙으로 인해 구글 측에서는 다음과 같은 버전 코드 규칙을 가이드라인으로 제시하고 있음.

위와 같이 API level을 가장 앞에, 앱 버전을 가장 뒤에 두고 그 사이에 플랫폼이나 OpenGL ES 버전, 텍스처 포맷 등의 구분자를 넣어 작성하는 것을 추천.

관련 문서


  1. 유니티 2017.1에서 테스트 [본문으로]

※ 이 글은 CodeIQ 매거진의 기사를 번역한 것입니다. 이 글의 저작권은 CodeIQ에 있으며, 사정에 따라 예고없이 삭제될 수 있습니다. (원문)

Cygames가 「그랑블루 판타지」를 네이티브가 아닌 브라우저 베이스로 개발한 이유

「그랑블루하고 있어?」라는 CM으로 친숙한 「그랑블루 판타지」는 Cygames가 개발하고 Mobage가 제공하는 스마트폰용 소셜 게임. 그 그랑블루 판타지의 무대 뒷편을 캰치와 마스이 유이치로 씨가 직격 인터뷰!
by 바바 미유키 (CodeIQ 안의 사람)

하나의 게임 타이틀에 관여하는 사람은 약 100명!

캰치:오늘은「그랑블루 판타지」를 개발한 Cygames에 마스이 씨와 함께 취재하러 왔습니다!

요즘 화제의 「그랑블루」가 어떻게 개발되고 있는지, 개발에 깊이 관여하고 있는 두분께 이야기를 들을 수 있게 되어 두근두근합니다.


▲캰 치아키 일명 캰치 씨, 주식회사 트레타 CTO 마스이 유이치로 씨

이번에 이야기를 들려주실 분은 CTO인 아시하라 에이토시 씨, 「그랑블루 판타지」 개발팀의 엔지니어 리더 타카하시 미츠루 씨입니다.

캰치:먼저 두분의 자기소개부터 부탁드릴 수 있을까요?

아시하라:이사 CTO 아시하라입니다. 개발부문, 연구부문이나 인프라 등의 기술분야 전반을 총괄하고 있습니다. 입사 전에는 대학 졸업 후 취업한 이후로 계속 컨슈머 게임 업계에서 엔지니어를 해왔고, 전 직장에서는 당사의 대표와 상무와 같은 팀에서 개발을 했습니다.


▲주식회사 Cygames의 이사 CTO, 아시하라 에이토시 씨

다른 회사에서도 엔지니어의 통괄역을 맡은 적이 있습니다만, Cygames만큼 조직의 규모가 급격하게 커진 적은 없습니다. 현재는 스탭 수가 1200명을 넘어, 엔지니어만 해도 300명 이상이 재적하고 있습니다.

타카하시:「그랑블루 판타지」의 엔지니어 팀 리더를 맡고 있는 타카하시 미츠루입니다. 그랑블루는 개발초기부터 관여했고, 당시에는 개발도 했습니다만 현재는 팀의 관리업무가 메인입니다.


▲주식회사 Cygames 게임 엔지니어/서버 사이드 타카하시 미츠루 씨

마스이:Cygames 사에서는 다수의 타이틀을 개발하고 있다고 들었는데요, 한 타이틀 당 개발 인원은 어느 정도인가요?

아시하라:한 타이틀 당 엔지니어의 수는 개발 초기에 아직 멤버가 적을 때에는 3~4명, 그 후로 릴리즈, 운용을 거치면서 사람 수가 늘어나서 많은 팀은 40명 정도가 되기도 합니다.

타카하시:엔지니어 이외의 기획자나 디자이너도 포함하면 한 타이틀 만으로 100명 정도의 스탭이 관여할 때도 있습니다.

캰치:한 타이틀에 100명! 엄청난 수의 스탭분들이 관여하시는 거군요.

마스이:그만큼 살림이 커지면 정보공유도 큰일이겠네요.

아시하라:그러게요. 기술이나 노하우의 공유를 위해 여러가지 궁리를 하고 있습니다. 예를 들자면, 매일 각 타이틀의 엔지니어 리더가 모여서 미팅을 실시하고, 거기서 일어난 문제나 그 해결책을 공유·상담하고 있습니다. 「그랑블루」는 독자적인 게임 엔진을 사용하기에 조금 경우가 다릅니다만, 우리 회사의 타이틀은 「신격의 바하무트」를 베이스로 하여 개발한 타이틀이 많기에, 하나의 타이틀에서 일어난 문제는 다른 타이틀에서도 일어날 가능성이 있습니다.

그렇기 때문에, 횡적인 연대를 강화하여 정보를 공유하는 것이 중요합니다. 그 외에도, 한달에 한번 엔지니어 직군의 멤버 전원이 모이는 「엔지니어 전체 미팅」을 실시하여 회사의 기술적인 방침이나 생각을 전달함과 동시에 친목을 다짐으로써, 타이틀의 벽을 넘어 엔지니어 사이의 유대를 강화하고 있습니다.

마스이:같은 시스템에서 유래했으니 팀 간의 정보공유가 중요하겠네요. 그리고 그런 장소가 준비되어 있다는 건 좋은 일이죠. 그런데, 왜 「그랑블루」만 독자적인 게임 엔진을 사용했나요?

타카하시:「그랑블루」도 「신격의 바하무트」와 마찬가지로 브라우저 베이스로 개발했습니다만, 여러가지 새로운 도전을 하고 있는 타이틀이므로, 엔진에 관해서는 「그랑블루」전용의 사양이 되었습니다.

브라우저의 한계에 도전해보면 재미있지 않을까

마스이:스마트폰 게임의 네이티브화라는 흐름 속에서, 「그랑블루」를 브라우저 베이스로 개발한 것은 어째서인가요?

아시하라:처음에는 단순히 「"브라우저의 한계"에 도전해보면 재미있지 않을까」하는 생각에서 시작했습니다. 네이티브에 존재하는 제한을 받지 않고, 브라우저만의 강점을 살려, 보다 여러 방향에 도전해보고 싶다는 의도도 있었습니다. 실제로 개발해본 결과, 브라우저만의 메리트를 살린 게임이 되었다고 생각하고 있습니다.

캰치:브라우저만의 메리트라면 어떤 점인가요?

타카하시:우선, 브라우저 베이스의 게임은 「어디서나 누구나 즐길 수 있다」는 점에서, 유저의 폭을 넓힐 수 있다는 메리트가 있습니다. 네이티브에서는 앱을 인스톨해야만 플레이할 수 있습니다만, 브라우저 베이스라면 그럴 필요없이 누구나 즐길 수 있습니다.

처음에는 스마트폰의 브라우저에만 대응했습니다만, 지금은 PC에도 대응하고 있어 더욱 폭이 넓어졌습니다.

아시하라:그 외에도 네이티브에서는 데이터 용량을 신경써야만 합니다만, 브라우저는 서버만 있으면 돌아가므로 그런 걱정을 할 필요가 없습니다.

갱신할 때에도 서버의 데이터만 바꾸면 되고, 수정할 때마다 스토어에 신청하지 않아도 된다는 것도 이점이죠.

타카하시:극단적인 예를 들자면, 브라우저 게임이라면 릴리즈 10분 전까지 개발할 수도 있고, 개발시간을 오래 확보할 수 있는 만큼 퀄리티를 추구하는 것으로도 이어집니다.

「그랑블루 판타지」를 지탱하는 기술이란?

마스이:「그랑블루」는 어떤 언어와 툴을 사용해서 만들어졌나요?

타카하시:메인은 PHP와 Backbone.js이고, 배틀 부분은 Node.js를 사용했습니다. 스토리지 쪽은 memcached와 MySQL, 흔히 말하는 LAMP 환경이죠.

의외라고 생각하실지도 모릅니다만, 조금씩 튜닝했을 뿐 그렇게까지 특별한 일을 하지는 않았습니다.

다만, 역시 이 타이틀은 많은 유저 수로 인해 막대한 부하가 걸리는 서비스이므로, 그 규모가 바로 특수한 부분이라 말할 수 있을지도 모르겠습니다.

아시하라:Node.js는 채팅 등 서버에서 보내는 통지기능에 사용하고 있습니다. Web만이 아니라 Node.js도 동시에 사용하여, 하이브리드가 되어있다는 점이 하나의 특징이죠.

Node.js로 채팅 기능을 만들 때에는 Redis의 Pub/Sub를 사용하는 케이스가 일반적이라고 생각하는데요, 「그랑블루」에서는 그것만으로 다 감당하지 못해 Pub/Sub가 엄청나게 무거워졌습니다.

그래서 앞단에 Nginx를 넣어서 분담시키고, 뒷쪽의 Pub/Sub를 없앰으로써 서버 대수를 줄일 수 있었습니다. Pub/Sub로는 쫓아가지 못할 정도로 규모가 커진거지요.

그만큼 대규모의 시스템을 수습한 경험과, 그 경험을 통해 노하우 및 능력을 익힐 수 있는 환경이라는 건 꽤나 자극적이라고 생각합니다.

마스이:그정도로 큰 게임이 일반적인 Web 시스템으로 구성되어 있었군요. 모바일용 게임이라면 막대한 수의 단말에서 동작을 체크할 필요도 있지 않나요?

타카하시:그러게요. 테스트에서는 HTML5의 Canvas를 사용했습니다만, 단말에 의존하는지라 조금 쓰기가 힘들었죠.

참고로, 테스트 환경은 자동화하고 싶었습니다만, 개발환경을 따라가지 못해서 지금도 인력으로 하고 있습니다.

처음에는 Android 2.3 이상, iOS 4.1 이상으로 상당히 넓게 잡았습니다만, 모든 단말에서 움직이게 만드는데는 굉장히 고생을 많이 했습니다.

계속해서 인기 게임이 만들어지는 개발현장에는 무엇이 있나?

캰치:Cygames 사의 오피스 내에는 사운드 수록용의 스튜디오가 있어, 성우 분의 목소리 수록이나 이벤트 생중계 등을 한다고 합니다. 오늘은 특별히 스튜디오를 견학을 허가받았습니다.


▲사운드 수록 스튜디오를 견학했습니다.


▲게임의 목소리 수록도 완벽!

캰치:게임의 개발현장에서 중요하게 생각하는 것은 무엇인가요?

아시하라:Cygames의 비전이 「최고의 컨텐츠를 만드는 회사」이므로, 게임개발할 때 「보다 재미있게」하는 것을 무엇보다 중요하게 생각하고, 시행착오를 반복하는 것이죠.

게임은 한번 돌려보지 않으면 재미있는지 아닌지 알 수 없으므로, 우선 돌아갈 때까지 만들고, 「보다 재미있게 만들 수 있다」고 생각하면 다시 만드는 것을 반복하고 있습니다. 그렇게 해서 완성할 때까지 몇번이나 다시 만드는 것 자체가 "게임제작"이라고 생각합니다.

마스이:몇번이나 다시 만들면 현장의 의욕이 떨어지거나 하지 않나요?

타카하시:의욕이 내려가지는 않습니다. 돌려보고 나서야 그 게임의 재미를 처음 알 수 있고, 새로운 과제와 개선점을 찾을 수 있으므로, 어떤 의미에서는 다시 만드는 것이 당연하다고 생각합니다.

또, 「재미있게 만들자, 최고의 물건으로 만들자」는 명확한 비전을 팀 내에서 공유하고 있어, 설령 수고가 들거나 고생을 하게 되더라도 같은 방향을 향해 움직일 수 있습니다.

우리 팀도 전원이 「그랑블루를 더 좋게 만들자」는 강한 마음을 품고 전력으로 퀄리티를 추구하고 있죠.

아시하라:이 「계속해서 게임을 재미있게 만든다」는 것과 「수많은 유저 환경에서 안정화시킨다」는 것을 양립시키는 것은 힘든 일입니다만, 보다 많은 유저 분들께 즐겨주시기 위해서는 필요한 일이기도 합니다.

거대한 규모로 쌓아올린 치밀한 노력을 끊이지 않고 계속하는 것이 Cygames의 강점 중 하나라고 생각합니다.

밴드맨에 바 경영!? 여러 경력을 가진 엔지니어가 활약중

캰치:그렇게까지 정열을 가진 개발팀이라면, 역시 처음부터 게임을 좋아해서 업계에 들어온 분이 많겠네요?

타카하시:그러게요. 제 경우에는 물론 게임을 좋아하기도 했습니다만, 이전에는 Web 시스템 회사에서 아르바이트를 하면서 밴드에서 음악활동을 했습니다.

결국 음악의 길은 버리고 게임업계에 들어왔습니다. 실은 바를 경영한 적도 있습니다(웃음).

아시하라:우리 회사는 여러 배경을 가진 사람들이 있거든요. 타카하시 씨를 면접할 때 바 점장이라고 들었을 때는 확실히 놀랐지만요(웃음).

그 외에도 전 복서나, 휴일에는 반드시 캠핑하러 가는 사람이라던가…. 개성이 풍부한 사람이 많아서 같이 일하는 몸으로서 즐겁습니다.

타카하시:지금 말 나온 사람은 전부 우리 팀 멤버예요(웃음).

마스이:재미있는 사람이 많아보이네요(웃음).


▲기술서가 진열되어있는 책장. 오라일리 저팬 발행서적은 전권 구비되어 있다고!

월간 300억 PV의 「그랑블루」 개발팀이 원하는 인재란?

캰치:「그랑블루」의 개발현장에서는 어떤 분이 활약하고 있나요?

타카하시:브라우저 베이스의 소셜 게임은 Web앱이므로, 당연히 Web을 잘 아는가가 중요하죠. 또, 트래픽이 막대해지고 있으니 서버를 어떻게 처리하는가하는 노하우도 강하게 요구됩니다.

마스이:CM도 잔뜩 내보내고 있으니 상당히 거대한 트래픽이 몰리겠는데요?

아시하라:말씀하신 대로입니다. 매달 PV 수가 약 300억에 이르렀습니다. 예를 들자면, 국내에서 80%의 점유율을 갖고 있는 거대 포털 사이트의 스마트폰 버전이 약 200억PV/월이므로, 그것을 넘는 막대한 트래픽이 발생하고 있다는 것을 이해하실 수 있을 겁니다.

캰치:엄청난 숫자네요…! 그런 서비스를 운영하는 Cygames에서는 어떤 엔지니어를 필요로 하시나요?

아시하라:「커다란 시스템을 다루고 싶다」고 하시는 분은 꼭 Cygames에 흥미를 가져주시기 바랍니다. 이정도 규모의 게임개발은 다른 곳에서는 경험할 수 없을 거라 생각합니다.

또, Cygames는 「최고의 컨텐츠를 만드는 회사」를 비전으로 하여 내세우고 있으므로, 기술면에서만이 아닌 「보다 좋은 게임을 만들고 싶다」「모든 유저분들이 진심으로 즐겨주길 바란다」는 생각을 가진 분들과 꼭 함께 일하고 싶습니다.

타카하시:기술면에서는 서버의 부하에 관해서도 생각할 수 있는 사람이 활약하고 있습니다. 대규모 시스템의 부하대책과 관련되어 있던 분은 노하우를 살릴 수 있을 것이라 생각합니다.

마스이:대규모 서버나 데이터 등, Cygames에서밖에 도전할 수 없는 게임개발이 여러가지 있을 것 같군요.

캰치:오늘은 귀중한 이야기를 들을 수 있어서 즐거웠습니다. 감사합니다.

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

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 프로세서가 될 것이라 생각됩니다.

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

관련글

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

SHIELD Android TV(Tegra X1)는 OpenGL ES 3.2 대응

(원문 : SHIELD Android TV (Tegra X1) は OpenGL ES 3.2 対応)

NVIDIA SHIELD Android TV는 이미 OpenGL ES 3.2의 Context에 대응하고 있다는 것을 알게 되었습니다.

Android 5.1 Tegra X1 Maxwell (256)

GL_VERSION: OpenGL ES 3.2 NVIDIA 349.00
GL_RENDERER: NVIDIA Tegra
GL_VENDOR: NVIDIA Corporation
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.20

OpenGL ES 3.2는 ES 3.1 AEP가 포함되어 있고 D3D11/OpenGL 4.x에 상당하는 API입니다. Android SDK가 3.2에 대응하지 않으므로 현재로서는 그다지 의미가 없습니다만, Desktop과 공통의 드라이버가 사용되고 있다는 사실을 읽을 수 있습니다.

아래는 Tegra K1(Nexus 9 Driver 343.00)에서 추가된 Extension입니다.

GL_EXT_discard_framebuffer
GL_EXT_draw_elements_base_vertex
GL_EXT_multi_draw_indirect
GL_EXT_post_depth_coverage
GL_EXT_raster_multisample
GL_EXT_shader_texture_lod
GL_KHR_context_flush_control
GL_KHR_robust_buffer_access_behavior
GL_KHR_robustness
GL_NV_conditional_render
GL_NV_conservative_raster
GL_NV_fill_rectangle
GL_NV_fragment_coverage_to_color
GL_NV_fragment_shader_interlock
GL_NV_framebuffer_mixed_samples
GL_NV_geometry_shader_passthrough
GL_NV_path_rendering_shared_edge
GL_NV_polygon_mode
GL_NV_sample_locations
GL_NV_sample_mask_override_coverage
GL_NV_shader_noperspective_interpolation
GL_NV_viewport_array
GL_NV_viewport_array2
GL_OES_copy_image
GL_OES_draw_buffers_indexed
GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp
GL_OES_tessellation_point_size
GL_OES_tessellation_shader
GL_OES_texture_buffer
GL_OES_geometry_point_size
GL_OES_geometry_shader
GL_OES_gpu_shader5
GL_OES_shader_io_blocks
GL_OES_texture_view
GL_OES_primitive_bounding_box
GL_OES_texture_cube_map_array

↑ GL_NV_conservative_raster나 GL_NV_fragment_shader_interlock 등, Maxwell GM2xx에서 추가된 D3D12에 해당하는 기능도 보입니다. (참고)

↓ 그 밖에도 K1과의 차이로는 fp16 대응이 있습니다.

Precision:
 0: [15 15] 10       VS float  lowp
 1: [15 15] 10       VS float  mediump
 2: [127 127] 23     VS float  highp
 3: [31 30] 0        VS int    lowp
 4: [31 30] 0        VS int    mediump
 5: [31 30] 0        VS int    highp
 6: [15 15] 10       FS float  lowp
 7: [15 15] 10       FS float  mediump
 8: [127 127] 23     FS float  highp
 9: [31 30] 0        FS int    lowp
10: [31 30] 0        FS int    mediump
11: [31 30] 0        FS int    highp

자세한 것은 다음 글에 추가했습니다.

공식 사이트에서는 Tegra X1의 CPU clock이 올라와있지 않습니다만, 조사해본 바로는 2.0GHz였습니다. 다만 VFP Benchmark로 실제로 측정한 결과로는 2.1GHz에 상당하므로 TB같은 기능이 동작하고 있으리라 생각됩니다.

관련글

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

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 카드에 의존하므로 참고만 하시기 바랍니다.

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

관련 글

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

Direct3D 12 GPU별 Descriptor Size, 문제점 등

(원문 : Direct3D 12 GPU 毎の Descriptor Size, 問題点等)

Direct3D 12에서는 리소스 바인드의 방법이 크게 바뀌었습니다. 셰이더의 종류도, 넘기는 리소스 수도 늘어났고, 바인드의 비용도 무시할 수 없게 되었기 때문입니다. 리소스는 디스크립터 힙 위에 확보한 일련의 디스크립터에 등록합니다. 이 힙 위의 앞 어드레스를 지정하는 것만으로 묘화 시의 바인드가 완료되는 구조입니다.

디스크립터는 GPU가 액세스하는 영역이므로, 하드웨어에 따라 사이즈가 다릅니다. 실제로 어느 정도나 차이가 나는지 조사해보았습니다. 수치의 단위는 바이트입니다.

GPUFeatureLevelCBV_SRV_UAVSAMPLERRTVDSV
RADEON GCN 1.011_1321632144
RADEON GCN 1.112_0321632144
GeForce Kepler11_03232328
GeForce Maxwell GM111_03232328
GeForce Maxwell GM212_13232328
Intel HD Graphics Gen7.511_132163296
Intel HD Graphcis Gen811_1641632128

이와 같이 GPU에 따라 사이즈가 다른 만큼, 디스크립터의 어드레스를 계산할 때에는 반드시 GetDescriptorHandleIncrementSize()를 참조해야 합니다. 디스크립터란 말하자면 리소스를 참조하기 위한 포인터같은 것인데, 뷰에 해당하는 액세스에 필요한 정보도 포함합니다. 사이즈를 보면 단순한 어드레스일 뿐이 아니라는 것을 알 수 있습니다.

전체적으로 DSV가 큰 것은 Depth 외에 Stencil Surface의 필요, 고속화를 위한 (PreZ 등의) 추가 리소스가 포함되어 있기 때문이라 생각됩니다. 그런 의미에서 DSV가 8바이트 밖에 없는 GeForce는 그야말로 어드레스 뿐. 나아가 다른 정보구조체를 간접적으로 참조하고 있는 것이 아닐까요.

Intel HD Graphcis의 경우에는 세대간에도 차이가 발생합니다. 외부에서는 그다지 차이를 알 수 없습니다만, 하드웨어의 차이는 생각보다 큰 것 같습니다.

이 표는 아래 페이지에도 게재했습니다.

알게 된 문제점 등

DirectX12는 현재에도 빈번히 드라이버가 갱신되고 있습니다. 아직 안정되지 않은 상태인 것 같습니다. 이하는 사용하면서 알게 된 것입니다. (2015/09/22현재)

GeForce Maxwell/Kepler (355.82)

  • Indirect Draw의 CommandSignature에서 RootDescriptor가 반영되지 않는 문제가 있었으나 드라이버 355.82에서 수정됨

RADEON GCN 1.0/1.1 (15.8Beta)

  • CommandSignature에서 Root 32bit Constant/Root Descriptor가 반영되지 않음
  • Bundle에서 RootSignature의 파라미터가 상속되지 않음

Intel HD Graphcis Gen7.5/8 (10.18.15.4256)

  • RootSignature에 Root 32bit Constant가 복수 존재하는 경우, CommandSignature에서 첫 32bit Constant 밖에 갱신할 수 없음

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

그 외에도 문제점은 아니지만 API의 거동이 GPU에 따라 자잘한 차이가 꽤 있습니다.

관련글

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

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

관련글

+ Recent posts