메탈 3년

3년 전, 저희는 렌더러를 Metal로 이식했습니다. 시간이 많이 걸리지도 않았고, 정말 재미있었으며 iOS에서 아주 잘 작동했습니다. 그래서 저희는 어떻게 결정을 내렸는지, 그리고 결과가 어땠는지(스포일러: 아주 좋았습니다!)를 다룬 기사를 작성했습니다. 당시 회고록의 대부분은 여전히 유효하지만, 오늘날 Metal은 그 어느 때보다 더 발전했습니다. 그래서 3년 만의 업데이트를 담아 이 글을 다시 게시하기로 했습니다.

그럼 시간을 거슬러 올라가 2016년 12월, iOS용 Metal 렌더러 버전을 막 출시한 시점으로 돌아가 보겠습니다.

왜 Metal인가?

2014년 WWDC에서 애플이 Metal을 발표했을 때, 제 첫 반응은 이를 무시하는 것이었습니다. Metal은 당시 최신 하드웨어에서만 지원되었는데, 우리 사용자 대부분은 그런 기기를 가지고 있지 않았고, 애플이 CPU 성능 문제를 해결했다고는 했지만, 가장 작은 시장을 위해 최적화를 한다는 것은 가장 빠른 기기와 가장 느린 기기 간의 격차가 더욱 벌어질 것을 의미했기 때문입니다. 당시 우리는 애플 기기에서만 OpenGL ES 2를 사용 중이었고, 안드로이드로 이식하는 작업도 막 시작하던 참이었습니다.

2년 반이 지난 지금, 우리 사용자들을 대상으로 한 Metal의 시장 점유율은 다음과 같습니다:

예전보다 훨씬 더 매력적으로 변했습니다. 여전히 Metal을 구현한다고 해서 가장 오래된 기기들에 도움이 되는 것은 아니지만, iOS의 GL 시장은 계속 축소되고 있으며, 이러한 구형 기기에서 실행되는 콘텐츠는 최신 기기에서 실행되는 콘텐츠와 종종 다르기 때문에, 속도를 높이기 위해 어느 정도 노력을 기울이는 것은 타당합니다. iOS용 Metal 코드는 거의 수정 없이 Mac에서도 실행될 수 있으므로, 모바일 중심이라 하더라도 Mac에서도 이를 활용하는 것이 합리적일 수 있습니다(현재 우리는 iOS에서만 Metal 빌드를 배포하고 있습니다).

시장 점유율을 좀 더 자세히 분석해 볼 가치가 있다고 생각합니다. iOS에서는 iOS 8.3 이상에서 Metal을 지원합니다. OS 버전 제한으로 인해 Metal을 실행할 수 없는 사용자도 일부 있지만, 여전히 GL을 사용하는 25%의 대부분은 단순히 SGX 하드웨어가 탑재된 구형 기기를 사용하고 있을 뿐입니다. 또한 이 기기들은 OpenGL ES 3 기능을 전혀 지원하지 않으며, 저희는 해당 환경에서 저사양 렌더링 경로를 사용하는 것에 만족하고 있습니다(물론 모든 기기가 Metal로 전환되기를 바라지만, 다행히 GL/Metal의 비중 차이는 점차 개선될 것입니다). Mac의 경우 Metal API가 더 최신 버전이며 OS가 상당히 중요한 역할을 합니다. Metal을 사용하려면 OS X 10.11 이상을 사용해야 하는데, 우리 사용자의 절반은 단순히 더 오래된 OS를 사용하고 있습니다. 이는 하드웨어보다는 소프트웨어의 문제입니다(Mac 사용자의 95%는 OpenGL 3.2 이상을 실행 중입니다).

따라서 시장 점유율을 고려할 때, Metal로 포팅하지 않는 다른 선택지도 여전히 있습니다. 그중 하나는 기존 OpenGL 코드를 그대로 사용하되 더 빠른 성능을 기대할 수 있는 MoltenGL을 사용하는 것이고, 다른 하나는 Vulkan으로 포팅(PC 및 향후 Android에서 더 나은 성능을 얻기 위해)하여 MoltenVK를 사용하는 것입니다. 저는 MoltenGL을 간단히 평가해 보았는데, 결과가 그리 만족스럽지 않았습니다. 코드가 작동하게 만드는 데만도 상당한 노력이 필요했고, 기본 OpenGL에 비해 성능은 조금 더 나았지만 기대했던 것보다는 부족했습니다. MoltenVK의 경우, 한 저수준 API를 다른 저수준 API 위에 레이어로 구현하려는 시도는 잘못된 접근이라고 생각합니다. 필연적으로 임피던스 불일치가 발생하여 성능이 최적화되지 않을 것이기 때문입니다. 이전에 사용하던 고수준 API보다는 나을지 모르겠지만, 가능한 한 가장 빠른 속도를 내기는 어려울 것입니다. 애초에 저수준 API를 선택한 이유가 바로 그 '최적의 속도' 때문이 아니었나요! 또 다른 중요한 점은 Metal 구현이 Vulkan 구현보다 훨씬 간단하다는 것입니다. 이에 대해서는 나중에 더 자세히 다루겠지만, 어떤 의미에서는 Vulkan -> Metal 래퍼보다는 Metal -> Vulkan 래퍼를 선호합니다.

또한 최신 아이폰의 iOS 10에서는 GL 드라이버가 존재하지 않는다는 점도 주목할 만합니다. GL은 Metal 위에 구현되어 있습니다. 즉, OpenGL을 사용한다고 해도 개발 노력을 조금 절약할 수 있을 뿐입니다. OpenGL이 내세우는 “한 번 작성하면 어디서나 실행된다”는 약속이 모바일에서는 실제로 통하지 않는다는 점을 고려하면, 그 절약 효과는 그리 크지 않습니다.

이식

전반적으로 Metal로의 포팅은 아주 수월했습니다. 저희는 Direct3D 9/11과 같은 고수준 API부터 PS4 GNM과 같은 저수준 API에 이르기까지 다양한 그래픽 API를 다뤄본 풍부한 경험을 가지고 있습니다. 덕분에 Metal처럼 합리적으로 고수준이면서도 CPU-GPU 동기화와 같은 일부 작업은 앱 개발자가 직접 처리하도록 남겨두는 API를 편안하게 활용할 수 있다는 독보적인 이점이 있습니다.

유일한 난관은 셰이더를 컴파일하는 것이었습니다. 일단 컴파일이 완료되고 코드를 작성할 단계에 이르자, API가 너무나 간단하고 직관적이어서 코드가 저절로 써지는 듯한 느낌이 들었습니다. 저는 하루 만에 약 10시간 동안 대부분의 요소를 최적화되지 않은 방식으로 렌더링하는 포트를 구동시켰고, 이후 2주 동안 코드를 정리하고, 유효성 검사 문제를 수정하며, 프로파일링과 최적화를 수행하고 전반적인 마무리 작업을 했습니다. 이 기간 내에 API 구현체를 완성했다는 사실은 API와 툴셋의 품질을 여실히 보여줍니다. 저는 다음과 같은 여러 요인이 기여했다고 생각합니다:

• 모든 단계에서 훌륭한 피드백을 받으며 코드를 점진적으로 개발할 수 있습니다. 초기 코드에서는 CPU-GPU 동기화를 모두 무시하고, 상태 설정의 특정 부분에서 매우 비효율적인 방식을 사용하며, 리소스에 대해 내장된 참조 추적 기능을 활용하고, 문제를 피하기 위해 CPU와 GPU를 절대 병렬로 실행하지 않았습니다. 이후 최적화 및 마무리 단계에서 이를 출시 가능한 형태로 전환했으며, 그 과정에서 렌더링 기능을 전혀 잃지 않았습니다.
• 도구들이 잘 갖춰져 있고, 제대로 작동하며 성능도 뛰어납니다. Direct3D 11에 익숙한 분들에게는 그리 놀라운 일이 아닐 수 있겠지만, 모바일 환경에서 CPU 프로파일러, GPU 프로파일러, GPU 디버거, GPU API 검증 레이어가 모두 유기적으로 잘 작동하여 개발 중 대부분의 문제를 포착하고 코드 최적화를 도운 것은 이번이 처음입니다.
• 이 API는 Direct3D 11보다 다소 저수준이며, 렌더 패스 구성이나 동기화와 같은 몇 가지 핵심적인 저수준 결정 사항을 개발자에게 맡기기는 하지만, 여전히 각 리소스가 생성 시 지정된 특정 “사용 플래그”를 갖되 파이프라인 배리어(pipeline barriers)나 레이아웃 전환(layout transitions)을 요구하지 않는 전통적인 리소스 모델과, 각 셰이더 스테이지에 리소스를 자유롭게 할당할 수 있는 여러 슬롯이 있는 전통적인 바인딩 모델을 사용합니다. 이 두 가지 모두 익숙하고 이해하기 쉬우며, 빠르게 시작하기 위해 필요한 코드 양도 매우 적습니다.

도움이 된 또 다른 점은, 우리의 API 인터페이스가 Metal과 유사한 API를 지원할 준비가 되어 있었다는 것입니다. 이 인터페이스는 매우 간결하지만, 성능이 뛰어난 구현을 쉽게 작성할 수 있도록 렌더 패스와 같은 충분한 세부 정보를 노출합니다. 구현 과정에서 상태를 저장하거나 복원해야 할 필요가 전혀 없었습니다(많은 API 인터페이스가 이 문제로 어려움을 겪는데, 특히 렌더 타겟 설정을 상태 변경으로 취급하고 리소스/상태 바인딩이 이를 통해 지속되기 때문입니다). 또한 리소스 수명 주기나 동기화에 대해 복잡한 결정을 내려야 할 필요도 없었습니다. 렌더링에 필요한 유일한 “복잡한” 코드 조각은 렌더 파이프라인 상태를 생성하는 데 필요한 비트들을 해싱하여 파이프라인 상태를 생성하는 부분뿐입니다. 파이프라인 상태 객체는 저희 API 추상화의 일부가 아닙니다. 심지어 그 부분조차도 꽤 직관적이고 빠릅니다. 저희 API 인터페이스에 대해서는 별도의 게시물에서 더 자세히 다루겠습니다.

자, 셰이더 컴파일하는 데 일주일, 다듬고 최적화된 구현을 완성하는 데 2주가 걸렸습니다¹ - 결과는 어떨까요? 결과는 훌륭합니다. Metal은 성능 면에서 확실히 기대에 부응합니다. 우선, 단일 스레드 디스패치 성능은 OpenGL보다 눈에 띄게 우수합니다(작업 부하에 따라 렌더 프레임의 드로우 디스패치 부분을 2~3배 단축). 이는 중복 상태 설정을 줄이고 패스트 패스를 사용하여 드라이버와 원활하게 연동하는 등, 저희 OpenGL 구현체가 꽤 잘 튜닝되어 있다는 점을 감안한 결과입니다. 하지만 여기서 그치지 않습니다. 렌더링 코드가 준비되어 있다면 Metal에서 멀티스레딩을 활용하는 것은 식은 죽 먹기입니다. 아직 스레드 기반 드로우 디스패치로 전환하지는 않았지만, 리소스 준비 작업을 렌더링 스레드 외부에서 수행하도록 일부 다른 부분을 이미 전환하고 있습니다. 이는 OpenGL과는 달리 거의 수고 없이 이루어집니다.

그 외에도 Metal은 쉽게 접근할 수 있고 신뢰할 수 있는 도구를 제공함으로써 다른 성능 문제들을 해결할 수 있게 해줍니다. 우리 렌더링 코드의 핵심 부분 중 하나는 CPU에서 월드 스페이스 기준으로 라이팅 데이터를 계산하고 이를 3D 텍스처의 특정 영역에 업로드하는 시스템입니다(이는 OpenGL ES 2 하드웨어에서는 에뮬레이션해야 합니다). 업데이트는 부분적으로 이루어지기 때문에 텍스처 전체를 복제할 수 없으며, 드라이버가 glTexSubImage3D를 어떻게 구현하느냐에 의존해야 합니다. 한때는 업데이트 성능을 개선하기 위해 PBO를 사용해 보았으나, 안드로이드와 iOS 모두에서 전반적으로 심각한 안정성 문제에 직면했습니다. Metal에서는 영역을 업로드하는 두 가지 내장 방식이 있습니다. 하나는 GPU가 현재 텍스처를 읽지 않고 있을 때 사용할 수 있는 MTLTexture.replaceRegion이고, 다른 하나는 GPU가 텍스처 사용을 시작할 시점에 맞춰 비동기적으로 영역을 업로드할 수 있는 MTLBlitCommandEncoder(copyFromBufferToTexture 또는 copyFromTextureToTexture)입니다.

마지막으로 전반적인 의견을 말씀드리자면, Metal 코드 유지 관리 역시 거의 수고가 들지 않습니다. 지금까지 추가해야 했던 모든 추가 기능들은 우리가 지원하는 다른 어떤 API보다 Metal에 더 쉽게 구현할 수 있었으며, 이러한 추세는 앞으로도 계속될 것으로 예상합니다. API를 하나 더 추가하면 지속적인 유지 관리가 필요할 것이라는 우려가 조금 있었지만, OpenGL에 비하면 실제로는 많은 작업이 필요하지 않습니다. 사실, iOS에서 더 이상 OpenGL ES 3를 지원할 필요가 없게 되었으므로, 이는 우리가 가지고 있는 일부 OpenGL 코드도 단순화할 수 있음을 의미합니다.

안정성

현재 iOS에서 Metal은 매우 안정적으로 느껴집니다. 2014년 출시 당시 상황이 어땠는지, 혹은 현재 Mac에서 어떤지 정확히 알 수는 없지만, iOS용 드라이버와 툴 모두 꽤 견고하게 느껴집니다.

iOS 10에서 Xcode 7로 컴파일된 셰이더를 로드하는 것과 관련된 드라이버 문제가 한 건 있었는데(Xcode 8로 전환하여 해결했습니다), iOS 9에서는 nextDrawable API를 잘못 사용한 결과로 발생한 드라이버 크래시가 한 건 있었습니다. 그 외에는 동작상의 버그나 크래시가 전혀 없었습니다. 비교적 새로운 API임에도 불구하고 Metal은 전반적으로 매우 견고했습니다.

또한, Metal과 함께 제공되는 도구들은 다양하고 풍부합니다. 구체적으로 다음과 같은 기능을 사용할 수 있습니다:

• API 사용 시 흔히 발생하는 문제를 식별해 주는 꽤 포괄적인 검증 레이어. 기본적으로 Direct3D 디버그와 유사하며, Direct3D 사용자들에게는 익숙하지만 OpenGL 환경에서는 거의 찾아보기 힘든 기능입니다(이론상 ARB_debug_callback이 이를 해결해야 하지만, 실제로는 대부분 사용할 수 없거나 사용 가능하더라도 별 도움이 되지 않습니다).
• 발송한 모든 명령어와 그 상태, 렌더 타겟 내용, 텍스처 내용 등을 보여주는 작동하는 GPU 디버거입니다. 제가 필요로 한 적이 없어서 셰이더 디버거가 작동하는지는 모르겠고, 버퍼 검사 기능이 조금 더 쉬웠으면 좋겠지만, 대체로 제 역할을 잘 해냅니다.
• 패스별 성능 통계(시간, 대역폭)와 셰이더별 실행 시간을 보여주는 제대로 작동하는 GPU 프로파일러입니다. GPU가 타일러(tiler) 방식이기 때문에 드로우콜(drawcall)별 타이밍을 기대할 수는 없겠지만요. 특히 iOS 그래픽 API에는 GPU 타이밍 정보가 전혀 없다는 점을 고려할 때, 이 정도의 가시성을 확보할 수 있다는 것은 대단한 장점입니다.
• GPUView와 유사하지만, 몇 가지 UI상의 특이점을 제외하면 실제로 사용하기 쉬운, CPU 및 GPU 렌더링 워크로드의 스케줄링을 보여주는 작동하는 CPU/GPU 타임라인 추적(Metal System Trace) 기능입니다.
• 셰이더 구문을 검증하고, 때때로 유용한 경고를 제공하며, 셰이더를 런타임에 매우 빠르게 로드될 수 있고 사전에 합리적으로 잘 최적화된 바이너리 블롭으로 변환하여, 드라이버 컴파일러가 더 빠를 수 있으므로 로드 시간을 줄여주는 오프라인 셰이더 컴파일러입니다.

Direct3D나 콘솔 개발 배경이 있다면 이 모든 기능을 당연하게 여길 수도 있겠지만, OpenGL에서는 이 모든 것이 이례적이며, 특히 가끔 고장 나는 드라이버, 유효성 검사 부재, GPU 디버거 부재, 유용한 GPU 프로파일러 부재, GPU 스케줄링 데이터 수집 기능 부재, 그리고 각 벤더마다 파서가 조금씩 다른 텍스트 기반 셰이더 언어를 강제로 사용해야 하는 모바일 환경에서는 더욱더 반가운 일입니다.

Metal은 코드를 작성하고 애플리케이션을 출시하는 데 모두 훌륭한 API입니다. 사용하기 쉽고, 성능이 예측 가능하며, 견고한 드라이버와 탄탄한 툴셋을 갖추고 있습니다. 이식성을 제외한 모든 면에서 OpenGL을 능가하지만, OpenGL의 현실은 사실 세 가지 플랫폼(iOS, Android, Mac)에서만 사용했어야 했으며, 그중 두 곳은 이제 Metal을 지원한다는 점입니다. 게다가 OpenGL이 내세우는 이식성이라는 약속은 대부분 지켜지지 않는데, 한 플랫폼에서 작성한 코드가 여러 가지 이유로 다른 플랫폼에서는 작동하지 않는 경우가 매우 빈번하기 때문입니다.

Unity나 UE4 같은 타사 엔진을 사용 중이라면 이미 Metal이 지원되고 있습니다. 그렇지 않더라도 그래픽 프로그래밍을 즐기거나 성능에 깊은 관심을 가지고 있으며 iOS나 Mac을 진지하게 고려하고 있다면, Metal을 꼭 한번 사용해 보시기를 강력히 권장합니다. 실망하지 않으실 것입니다.

현재의 Metal

지난 3년 동안 Metal에 일어난 가장 큰 변화는 대규모 도입과 관련이 있습니다.

3년 전만 해도 기기의 4분의 1은 OpenGL을 사용해야 했습니다. 오늘날, 저희 사용자층을 기준으로 이 수치는 약 2%에 불과합니다. 즉, OpenGL 백엔드는 이제 거의 중요하지 않게 되었습니다. 여전히 유지 관리하고는 있지만, 이 또한 오래가지 않을 것입니다.

드라이버도 그 어느 때보다 좋아졌습니다. 일반적으로 iOS에서는 드라이버 문제를 거의 볼 수 없으며, 문제가 발생하더라도 초기 프로토타입에서 주로 발생하고, 프로토타입이 양산 단계에 이르면 대개 문제가 해결됩니다.

또한 우리는 Metal 백엔드를 개선하는 데 시간을 할애했으며, 다음 세 가지 영역에 중점을 두었습니다:

셰이더 컴파일 툴체인 재설계

지난 3년 동안 일어난 또 다른 일은 Vulkan의 출시와 개발입니다. API가 완전히 다른 것처럼 보일 수 있지만(실제로 그렇습니다), Vulkan 생태계는 렌더링 커뮤니티에 훌륭한 오픈소스 도구 세트를 제공했으며, 이 도구들을 결합하면 사용하기 쉬운 생산 품질의 컴파일 도구 세트를 얻을 수 있습니다.

저희는 이 라이브러리들을 활용하여 HLSL 소스 코드(컴퓨트 셰이더를 포함한 다양한 DX11 기능 사용)를 받아 SPIRV로 컴파일하고, 해당 SPIRV를 최적화한 뒤, 결과물인 SPIRV를 MSL(Metal Shading Language)로 변환할 수 있는 컴파일 툴체인을 구축했습니다. 이는 DX9 HLSL 소스만 입력으로 사용할 수 있었고 복잡한 셰이더에서 다양한 정확성 문제가 있었던 기존 툴체인을 대체합니다.

애플이 이 일과 전혀 관련이 없다는 점이 다소 아이러니하지만, 어쨌든 여기까지 왔습니다. glslang(https://github.com/KhronosGroup/glslang), spirv-opt(https://github.com/KhronosGroup/SPIRV-Tools), SPIRV-Cross(https://github.com/KhronosGroup/SPIRV-Cross)의 기여자와 유지보수 담당자분들께 깊은 감사를 드립니다. 저희도 새로운 툴체인을 출시하고, 이를 사용하여 셰이더를 Vulkan, Metal 및 OpenGL API로 재타겟팅할 수 있도록 이 라이브러리들에 일련의 패치를 기여했습니다.

macOS 지원

macOS 포팅은 항상 가능성은 있었지만, 일부 기능이 부족해지기 전까지는 큰 중점을 두지 않았습니다. 그래서 더 빠른 렌더링을 확보하고 미래의 가능성을 열기 위해 macOS의 Metal에 투자하기로 결정했습니다.

구현 측면에서 볼 때, 이는 전혀 어렵지 않았습니다. 대부분의 API는 완전히 동일하며, 윈도우 관리 외에는 메모리 할당만이 상당한 조정이 필요한 유일한 영역이었습니다. 모바일에서는 버퍼와 텍스처를 위한 공유 메모리 공간이 있는 반면, 데스크톱에서는 API가 자체 비디오 메모리를 갖춘 전용 GPU를 전제로 합니다.

관리형 리소스를 사용하면 Metal 런타임이 데이터 복사를 대신 처리해 주므로 이 문제를 빠르게 해결할 수 있습니다. 우리는 첫 번째 버전을 이 방식으로 출시했지만, 이후 시스템 메모리 오버헤드를 최소화하기 위해 스크래치 버퍼를 사용하여 리소스 데이터를 보다 명시적으로 복사하도록 구현을 재작업했습니다.

macOS와 iOS 간의 가장 큰 차이점은 안정성이었습니다. iOS에서는 단일 아키텍처의 단일 드라이버 공급업체만 다루면 되었지만, macOS에서는 세 공급업체(Intel, AMD, NVIDIA) 모두를 지원해야 했습니다. 게다가 iOS에서는 운 좋게도 Metal이 지원되던 *첫 번째* 버전인 iOS 8을 건너뛸 수 있었지만, macOS에서는 당시 Metal을 사용하는 사용자가 너무 적을 것이 분명했기 때문에 이는 현실적으로 불가능했습니다. 이러한 문제들이 겹치면서, 우리는 macOS에서 API의 비교적 무해한 영역은 물론 비교적 잘 알려지지 않은 영역에서도 훨씬 더 많은 드라이버 문제를 겪게 되었습니다.

우리는 여전히 모든 버전의 macOS Metal(10.11+)을 지원하지만, 우회하기 어려운 셰이더 컴파일러 버그가 알려진 일부 버전에 대해서는 지원을 중단하고 레거시 OpenGL 백엔드로 전환하기 시작했습니다. 예를 들어, 10.11에서는 이제 Metal이 작동하기 위해 macOS 10.11.6이 필요합니다.

성능상의 이점은 예상과 일치했습니다. 시장 점유율 측면에서, 현재 macOS 플랫폼에서 OpenGL 사용자는 약 25%, Metal 사용자는 약 75%로, 상당히 건전한 비율을 보이고 있습니다. 이는 향후 어느 시점에 데스크톱 OpenGL 지원을 완전히 중단하는 것이 현실적일 수 있음을 의미합니다. 우리가 지원하는 다른 플랫폼에서는 OpenGL을 사용하지 않기 때문이며, 이는 지원하기 쉽고 우수한 성능을 얻을 수 있는 API에 집중할 수 있다는 점에서 매우 긍정적입니다.

성능 및 메모리 소비에 대한 반복 개선

저희는 역사적으로 사용하는 그래픽 API 기능에 대해 꽤 보수적인 편이며, Metal도 예외는 아닙니다. Metal은 지난 몇 년간 명시적 힙을 통한 개선된 리소스 할당 API, Metal 2의 타일 셰이더, 인자 버퍼, GPU 측 명령어 생성 등 여러 주요 기능 업데이트를 거쳤습니다.

저희는 대체로 이러한 새로운 기능들을 사용하지 않습니다. 지금까지 성능은 무난한 수준이었으며, 저희는 전반적으로 적용 가능한 개선 사항에 집중하고 싶기 때문에, 렌더러 전반에 걸쳐 매우 특수한 지원을 구현해야 하고 최신 하드웨어에서만 사용할 수 있는 타일 셰이더와 같은 기능은 그다지 매력적이지 않습니다.

그렇긴 하지만, 우리는 백엔드의 여러 부분을 단순히 *더 빠르게* 실행되도록 튜닝하는 데 어느 정도 시간을 할애하고 있습니다. 레벨 로딩 중 끊김 현상을 줄이기 위해 완전히 비동기적인 텍스처 업로드를 사용하는 것(이 작업은 전혀 어렵지 않았습니다), macOS에서 앞서 언급한 메모리 최적화를 수행하는 것, 캐시 미스를 줄여 백엔드의 여러 곳에서 CPU 디스패치를 최적화하는 것 등입니다. 그리고 - 우리가 명시적으로 지원하는 몇 안 되는 새로운 기능 중 하나인 - 가능한 경우 메모리리스 텍스처 저장을 사용하여 새로운 섀도우 시스템에 필요한 메모리를 대폭 줄였습니다.

미래

전반적으로, Metal 개선 작업에 너무 많은 시간을 할애하지 않아도 되었다는 사실은 사실 긍정적인 신호입니다. 3년 전에 작성된 코드가 대체로 잘 작동하며 빠르고 안정적이라는 것은 API가 성숙했다는 훌륭한 증거입니다. 소요된 시간과 우리 및 사용자에게 지속적으로 제공하는 이점을 고려할 때, Metal로의 이식은 훌륭한 투자였습니다.

우리는 다양한 API를 위해 투입하는 작업량의 균형을 끊임없이 재평가하고 있습니다. 향후 렌더링 프로젝트 중 일부를 위해 Metal API의 더 현대적인 부분을 깊이 파고들어야 할 가능성이 매우 높습니다. 만약 그렇게 된다면, 이에 대해 또 다른 글을 꼭 작성하겠습니다!

1. 네, 알겠습니다. 그리고 테스트 중에 발견된 몇 가지 버그를 수정하는 데 일주일 정도 더 걸릴 수도 있겠네요 ↩
2. 이 수치는 A10에서 프레임당 128KB 분량의 데이터(32x16x32 RGBA8 영역 2개)가 업데이트되는 경우를 기준으로 합니다. ↩

Roblox Corporation이나 이 블로그는 어떠한 회사나 서비스도 추천하거나 지지하지 않습니다. 또한, 이 블로그에 포함된 정보의 정확성, 신뢰성 또는 완전성에 대해 어떠한 보증이나 약속도 하지 않습니다.

이 블로그 게시물은 원래 Roblox Tech Blog에 게시되었습니다.