돌핀 에뮬레이터 2019년 12월~2020년 1월 진행 보고서

시작하기 전에 몇몇 사용자가 고통받는 걸 보았기 때문에 설명하겠습니다.

돌핀 프로젝트를 마이크로소프트 비주얼 스튜디오 C++ 2019로 업데이트했습니다.

당시는 문제가 없을 거라고 생각했습니다. 마이크로소프트가 VS2019 런타임은 VS2015, VS2017과 호환된다고 말했으니까요. 하지만 항상 그런 건 아니었고, 우리는 문제에 부딪혔습니다.

지난 2개월 동안, 수많은 사용자가 "VCRUNTIME140_1.dll을 컴퓨터에서 찾을 수 없음"(혹은 프로그램을 실행할 수 없음)이라는 오류를 겪었고 어떻게 해야할지 몰랐습니다.

 

만약 MSVS나 VCRUNTIME 오류가 뜨면 마이크로소프트 사이트에서 최신 x64 마이크로소프트 비주얼 스튜디오 런타임을을 설치하세요. [마이크로소프트 홈페이지] [바로 받기]

윈도우 업데이트를 했더라도 업데이트로 런타임이 배포되지 않는 경우가 있습니다.

이 방법으로 사람들이 겪는 문제가 해결되길 바랍니다.

 

자, 그럼 AMD 젠 아키텍처부터 ARM 윈도우까지 주목할만한 변화를 살펴봅시다.

 

5.0-11318 메인 GUI에 메모리 관리 장치 설정을 넣고 기본적으로 비활성화

지난 몇 년간은 일종의 실험이었습니다.

효율성과 정확성 면에서 게임큐브/위의 메모리 관리 장치(MMU) 에뮬레이션이 발전하면서 무기한 풀타임으로 사용하기로 활성화하기로 했습니다.

테스트에서 이 기능을 활성화해도 성능에는 별 영향이 없었으며 돌핀이 이상한 게임 버그와 충돌을 더 정확하게 에뮬레이션할 수 있는 이점이 있었습니다.

가장 큰 이점은 메모리 범위를 넘어 읽더라도 돌핀이 꺼지지 않으며 게임 충돌 핸들러가 처리한다는 것이었죠.

 

전반적인 성능에는 영향이 없었지만, 특정 게임에서는 대가가 필요했습니다.

메탈 기어 솔리드: 더 트윈 스네이크나 트루 크라임: 뉴욕 시티 같은 게임은 ARAM(게임에서 사용할 수 있는 DSP 보조 램)에서 불러오는 방식 떄문에 MMU 에뮬레이션을 완전히 활성화하면 생성된 코드가 크게 부풀어오릅니다.

그러면 돌핀의 JIT 캐시를 채우죠. JIT 캐시가 넘치면 돌핀은 그걸 치우고, 그동안 게임은 계속 끊겼습니다.

메탈 기어 솔리드는 적이 새로운 방에서 여러분을 발견할 때마다 엄청나게 끊깁니다.

트루 크라임은 돌핀으로 실행하면 도입부에서 충돌하지만, 이 부분을 저장 파일을 이용해 넘긴다면 넘치는 캐시 때문에 최악의 게임을 볼 겁니다. 거대하고 피할 수 없는 끊김이 몇 초마다 괴롭힐 테니까요!

MMU 에뮬레이션을 끄면 메탈 기어 솔리드는 끊기지 않게 되고, 트루 크라임은 캐시를 지울 때만 끊깁니다.

 

혼절

그래서 우리는 다소 어려운 결정을 내려야했습니다.

MMU 에뮬레이션은 의심의 여지 없이 더 정확하고 언뜻 보기엔 성능 저하도 없는 것 같았지만, 수년간 부정적인 영향을 받은 게임이 있다는 걸 알았습니다.

좋은 소식은 MMU 에뮬레이션을 끈 상태로 돌핀의 MMU 스피드핵을 이용하는 게임만 영향이 있다는 겁니다.

MMU 스피드핵은 게임이 ARAM을 매핑하는 영역을 알고 있는 경우 근본적으로 MMU 에뮬레이션의 필요성을 바이패스합니다. 모든 걸 번역하기보다는 게임에서 이거 유효하고 문제 없이 잘 작동한다고 딱 잘라 말하는 거죠.

그렇지만 예상보다 코드에 끼치는 영향이 컸고, 생각도 못한 문제를 초래했습니다.

 

이 문제를 해결하려면 돌핀의 JIT(저스트 인타임 컴파일러)를 크게 갈아엎고 현대적인 해결책을 써야할 겁니다.

그래도 상당히 기념비적인 작업이 되겠죠.

이 문제를 해결하는 주 작업은 간단하게 MMU 스피드핵을 사용하는 겁니다.

스피드핵을 구성하는 추가 NAT를 설정하기만 하면 기술적으로 MMU 에뮬레이션과 마찬가지로 작동할 겁니다.

 

하지만 두 가지 이유로 그렇게 하지 않기로 했습니다. 먼저 이것은 과거에 많이 시험해보지 못한 새로운 구성입니다.

어떤 문제가 일어날 거라고 생각하진 않지만, 확신할 수는 없어요.

둘째는 x86-64 JIT에서 기본적으로 비활성화함으로써 ARM 기기의 돌핀과 동일한 저장 상태를 쓸 수 있습니다.

돌핀 x86-64 JIT와 달리, 돌핀 AArch64(ARM 64비트) JIT는 최적화가 부족해 MMU 에뮬레이션을 자유롭게 활성화할 수 있으며 그 플랫폼에서는 기본적으로 사용하지 않게 해놓았습니다.

x86-64에서 MMU 에뮬레이션을 비활성화한 결과로, 사용자가 설정을 손댈 필요 없이 ARM과 저장 상태가 호환될 겁니다.

이런 점을 고려해 MMU 에뮬레이션은 기본적으로 비활성화하고 GUI에 추가해 정확성을 원하는 사용자가 쉽게 활성화할 수 있게 만들기로 했습니다.

돌핀은 게임 INI와 상관없이 확실히 MMU 에뮬레이션이 필요한 게임은 자동으로 활성화할 겁니다.

새로운 MMU 에뮬레이션 설정은 옵션 - 고급에서 'MMU 활성화'라는 이름으로 볼 수 있습니다.

 

 

5.0-11409 ARM64 기반 윈도우 지원, 5.0-11455 DolphinQt: ARM64 컴파일 지원

돌핀은 x86-64 JIT 윈도우 빌드가 있고, AArch64 JIT 안드로이드 빌드가 있습니다.

그렇다면 여러분은 ARM에서 윈도우 10을 실행하는 'ARM 기반 윈도우 10'에서도 쓸 수 있을 거라고 생각할지 모릅니다.

그냥 AArch64 JIT와 윈도우 빌드를 교환하면 된다고 말이죠.

별 거 아니잖아요, 그렇죠? 네, 맞아요. 실제로 매우 쉬웠습니다.

실망시켜서 미안하지만 이번에는 얼마나 악몽 같이 끔찍했는지 설명하는 수필 따위는 없어요!

그렇지만 새로운 플랫폼을 지원하고, 이야깃거리도 있으니 잠깐 이야기해보죠.

 

지금까지 ARM 기반 윈도우 10은 그렇게 흥미를 끌지 못했습니다.

문제 있는 플랫폼에 이미 잘 알고 있는 하드웨어로 실행하니까요.

예를 들자면, 2019년 말까지 최고의 ARM 기반 윈도우 기기는 레노버 요가 C630입니다. 스냅드래곤 850으로 작동하죠.

하드웨어와 기기 품질은 좋고 배터리 시간도 정말 긴데, 스냅드래곤 850은 모바일 SoC라서 C640은 모바일 드라이버로 작동합니다.

모바일 드라이버는 몇 년간 개선되어왔지만, 여전히 우리가 다루는 것 중 최악의 드라이버로 항상 모바일 드라이버 버그를 처리하고 있습니다.

윈도우는 이런 문제를 완화시키기는 커녕 실제로는 조금 더 악화시킵니다.

퀄컴은 여러분이 특정 드라이버 버전을 사용하는 걸 잊어버릴까봐 윈도우 업데이트로만 드라이버를 배포합니다.

거기에 더해, 대부분의 윈도우 소프트웨어는 ARM에 이식되지 않아 마이크로소프트의 x86-32(x86-64가 아니에요. 오직 32비트!) 에뮬레이션으로 실행하여 C630의 뛰어난 배터리 성능과 작은 기기 성능을 박살냅니다.

그렇지만 C640의 가장 큰 문제점은 스냅드래곤 850이 평범한 인텔 노트북 CPU보다 끔찍하게 느리다는 겁니다.

또한 스냅드래곤 850을 많이 봐서 성능이 어떤지 알고, 리눅스에서도 써봤기 때문에 '안드로이드가 아니다'는 별 문제가 안 됩니다.

솔직히 말해서 C630을 살필 이유도 없었죠. 이게 ARM 기반 최고의 윈도우 10이라니.

재미없는 하드웨어, 나쁜 드라이버, 골치아픈 생태계 때문에 우리 모두 플랫폼을 무시했습니다.

 

이 작은 짐승은 꽤 재밌다

이는 퀄컴의 노트북급 ARM SoC인 8cx가 출시하면서 바뀌었습니다.

인텔 노트북 CPU에 필적할만한 성능, 인텔 iGPU를 훨씬 뛰어넘는 GPU 성능으로 주목을 끌었죠.

8cx로 처음 나오는 기기는 기술적으로 가볍게 커스텀한 마이크로소프트 서피스 프로 X로 ARM 기반 윈도우 전용제품입니다.

단단히 잠겨있었고, 몇 개월간의 역설계가 겨우 진전을 보이기 시작했죠.

종내에는 리눅스 커뮤니티가 프로 X를 뚫겠지만, 그동안 이 독특한 ARM SoC는 야생에서 'ARM 기반 윈도우'라는 갑옷을 입고 우릴 놀릴 겁니다.

그 녀석의 끔찍한 드라이버와 생태계, 그 외 다른 모든 문제에대 불구하고 우리는 저항할 수가 없었습니다.

대체 돌핀이 8cx에서 어떻게 실행될지 너무너무 궁금했어요!

그래서 프로 X를 가지고 놀면서 stenzek는 ARM 기반 윈도우 10을 지원하는 걸 검토해보기로 했습니다.

 

그리고 꽤 쉬운 일이라는 걸 알게 되었습니다. AArch64 JIT를 윈도우 빌드로 바꾸는 건 가벼운 일이었어요.

윈도우 ARM64 빌드를 위해 몇 가지 작은 수정을 해야했지만, 코드 베이스 대부분은 호환됐습니다.

ARM 기반 윈도우 10용 Qt GUI를 만드는 건 좀 더 번거로웠지만, stenzek이 적절한 구성을 알아내자 꽤 쉬운 일이었습니다.

아직 작업하지 않은 비디오 드라이버 버그가 몇 개 있지만, 작동은 하고 어렵지도 않습니다.

동기 자체는 순수하지 않았을지 몰라도 이제 ARM 기반 윈도우 10을 지원한다고요!

 

서피스 프로 X에서 실행하는 돌핀

그렇지만 다운로드 페이지에 ARM 기반 윈도우는 없고, 빌드봇으로 빌드를 만들지도 않습니다.

빌드를 저장할 만큼 충분한 사용자가 없으니까요.

ARM 기반 윈도우가 있고 이 빌드를 쓰려먼, 윈도우 빌드 지침을 따르세요. 단, 플랫폼은 ARM64로 설정하세요.

 

 

5.0-11478 눈차크 모션 패스스루 지원

에뮬레이션된 위 리모트 모션 패스스루 직후, 눈차크(눈챠쿠) 모션 패스스루가 뒤따를 거라고 생각했습니다.

위 리모트와 눈차크를 같이 조작할 수 있도록 두번째 가속도계도 손보는 게 당연한 거 아니겠어요?

하지만 돌핀의 GUI가 컨트롤러를 다루는 방식에 영향이 좀 있어서 늦어졌습니다.

항상 보이는 게 당연한 위 리모트의 모션 패스스루와 달리, 눈차크는 끼웠다 뺄 수 있는 많은 확장장치 중 하나입니다.

눈차크는 모션 입력을 가진 유일한 확장장치이므로 다른 장치를 끼웠는데 모션 입력 탭을 사용할 수 있다면 이상하겠죠.

그래서 모션 패스스루를 구성하는 사람들은 일을 단순하게 하기 위해서 눈차크를 선택했을 때만 눈차크 모션 패스스루 페이지를 띄우게 했습니다.

오른쪽처럼 확장을 눈차크로 선택하면 모션 탭이 등장

이렇게 하면 컨트롤러의 모션 센서 데이터를 에뮬레이션된 눈차크에 더해 위 리모트로도 패스스루할 수 있습니다.

여러 기기가 모션 입력을 지원하므로 양손에 듀얼쇼크 4를 하나씩 들고 재밌게 위 스포츠의 복싱을 할 수 있습니다.

 

 

5.0-11524 반복 프레임을 수동으로 삽입해 프레임 페이싱 개선

간혹 문제를 해결할 때까지 문제를 모를 수 있고, 더 나쁘게 하드웨어 구성에 따라 많은 사용자가 겪는 걸 못 볼 수도 있습니다.

오래 전부터 돌핀은 60FPS 게임은 괜찮지만, 30FPS 게임에서 프레임 페이싱이 심각하게 나쁘다는 불만이 제기되어 왔습니다.

30FPS 게임은 60FPS 게임보다 부드럽지 않은 게 당연하고, 프레임 페이싱은 하드에어나 다른 요인에 따라 크게 달라질 수 있기에 크게 신경 쓸 일은 아니었습니다.

그런데 조사를 좀 해보니, 돌핀에서 30FPS 게임의 프레젠테이션 프레임 페이싱이 매우 나쁘다는 사실이 드러났습니다.

 

이전에도 프레임 페이싱에 관해 말했었지만 그 때는 프레임 타임 얘기였습니다.

디스플레이에서 일어나는 일과 상관없이 수직 동기화와 속도 제한을 끈 상태에서는 끊기고 렌더링 문제가 일어난다는 거였죠.

프레젠테이션 프레임은 특히 돌핀이 렌더링하고 비디오 드라이버가 내보내는 것들, 특히 화면에 나타는 프레임의 페이싱에 관한 모든 것입니다.

60Hz 주사율 디스플레이에서는 화면이 16.66ms마다 새로 고쳐지기 때문에 매 16.66ms마다 프레임이 준비됐는지 확인해야합니다.

1밀리초라도 프레임이 늦는다면, 드라이버는 다음 16.66ms 때 그 프레임을 보내거 아예 안 보낼 겁니다.

60Hz 패널의 30FPS 게임은 좀 복잡합니다.

이상적으로는 33.33ms마다 프레임을 보내거나 패널을 새로 고칠 때마다 드라이버가 빈 공간을 채우는 겁니다.

하지만 프레임이 조금 늦는다면, 즉 34ms라면 33.33ms는 지나가고 다음 16.66ms로 보내져 총 49.99ms가 됩니다.

동기화를 유지하고 렌더링된 프레임을 모두 표시하기 위해서 다음 프레임은 16.66ms에서 초기로 밀리겠죠.

그러면 프레임 페이싱은 33ms, 49ms, 16ms 프레임이 섞이게 되고 의도보다 훨씬 더 나쁜 결과가 됩니다.

돌핀에서 30FPS 게임을 살표본 결과가 이렇습니다.

 

33.333ms가 아니다. 결과는 아주 나쁘다

조사할 가치가 있었고, stenzek이 테스트 빌드에서 문제를 완화할 수 있게 되면서 고치는 게 더 중요해졌습니다.

그가 처음 시도한 건 모니터의 프레임을 게임이 실행되고 있는 정황한 프레임으로 수동으로 바꾸게 하는 거였습니다.

NTSC 게임은 59.94/29.97Hz, PAL 60을 지원하지 않는 PAL 게임은 50/25Hz를 의미했죠.

모든 프레임을 지원하는 경우, 프레임 충실도가 크게 증가했고, 특히 PAL 게임이 그랬습니다.

하지만 단점이 있었습니다.

돌핀이 모니터의 주사율을 바꿀 때 다소 불안정했고, 윈도우에서만 작동했으며, 애초에 이걸 지원하는 모니터가 많지 않았습니다.

언젠가는 이 방법을 쓰고 싶었지만, stenzek은 문제 일부를 해결하는 단기 해결책을 내놓았습니다.

그는 플레이스테이션 에뮬레이터인 덕스테인션으로 해결책을 시험해보았습니다. 30FPS 게임에 패딩으로 프레임 페이싱 문제를 해결하려고 했죠.

렌더링 파이프라인이 더 단순했기 때문에 패딩이 프레임 충실도를 개선했는지 더 빨리 시험하고 확인할 수 있었습니다.

효과가 확인되자 그는 이 기능을 돌핀에 넣었고, 형편없는 프레임 페이싱으로 고통받는 사람들에게 시험해보게 했습니다. 결과는 훌륭했죠.

 

좀 더 손봐야하지만 훨씬 낫다. 게임마다 결과는 다양하다. 이보다 나을 수도, 더 나쁠 수도 있지만 전과는 확실히 다르다

30FPS 게임에서 프레임 페이싱 문제를 겪고 있는 많은 사용자들은 '반복 프레임들 제출 스킵(Skip Presenting Duplicate Frames)'이라는 새로운 설정을 볼 수 있습니다. 이걸 켜면 예전처럼 작동합니다.

이걸 끄고 수직 동기화를 켜면 30FPS 게임의 프레임 페이싱 문제가 크게 개선됩니다.

XFB 즉시 표시 설정을 켰다면 돌핀은 모든 XFB 사본을 이 설정으로 표시하므로 이 기능은 필요 없습니다.

그래도 XFB 즉시 표시는 해킹이며 많은 게임에서 작동하지 않는다는 점을 고려하면, 이 방법은 더 많은 게임을 더 부드럽게 출력하게 하는 올바른 방식이라서 여전히 매우 중요합니다.

 

옵션 - 그래픽 설정 - 핵에 새로운 설정이 있다

이전 방식에 비해 이 방식이 가진 한 가지 단점은 60Hz 모니터에서 25FPS 혹은 50FPS로 실행되는 PAL 게임에는 도움이 되지 않는다는 겁니다.

50Hz 모니터를 갖는 것 외에는, 일반 모니터로는 할 수 있는 게 많지 않아요.

하지만 가변 주사율 디스플레이가 있고 전체 화면으로 한다면 돌핀이 실행할 수 있는 어떤 게임이든 프레임 페이싱 걱정 없이 실행할 수 있어야합니다.

사실 뛰어난 VRR 디스플레이는 프레임 반복, 안티 티어링, 안티 고스팅 기능을 가지고 있기 때문에 이번에 구현한 어떤 것도 필요하지 않습니다.

 

 

5.0-11578 많은 위 파일 시스템을 보다 정확하게 다시 구현

돌핀은 위 에뮬레이터로 개량하는 건 많은 문제와 단계가 있는 매우 긴 여정이었습니다.

이 정도쯤 오면 한때 돌핀이 위 낸드를 취급하기 위해 의지해던 가장 큰 문제와 핵들과 작별 인사를 하게 되죠.

Leoetlino의 변경 사항 배치에서는 이것들을 교체하는 일을 시험하고 검증합니다.

이 모든 기능을 다시 쓰고, 다시 만들고, 시험해서 얻는 가장 큰 이점은 더 정확한 에뮬레이션이 필요한 게임이 제대로 작동하게 하면서 낸드나 버추얼 SD 카드를 손상시킬 사능성이 훨씬 낮아진다는 겁니다.

 

99% 작동하는 위 소프트웨어를 정리하는 게 그렇게 재밌어 보이지 않을 수 있지만, 그 덕에 두 게임의 호환성을 향상시켰고 또 다른 게임을 유지하기 쉬워졌습니다.

가장 큰 건 파일 시스템 모듈이 생성 순서대로 파일 목록을 보고해야하는 디즈니의 게임인 볼트입니다.

게임은 가장 최근에 만들어진 저장 파일이 첫번째일 거라고 가정하고 위에서는 항상 그렇게 작동할 겁니다.

하지만 돌핀에서는 그렇지 않았고, 보통은 완전히 불가능한 일이었죠!

그래서 게임이 가장 최근의 저장 파일이 아닌 걸 고르면, 게임은 저장 파일을 읽지 못하고 완전히 진행이 불가능하기도 하죠!

 

지금까지는 왼쪽이 끝이었지만, 이제 게임을 진행할 수 있다

세트 하드웨어에 맞게 한 프로그래밍의 악의 없는 부작용처럼 보이지만 한 가지 생각해봐야할 점이 있습니다.

이 게임은 일부러 돌핀에서 제대로 안 돌아가게 만든 것으로 추측되는 디즈니 파괴 삼총사를 만든 아발란체 스튜디오라는 아주 좋-은 친구들이 만들었습니다.

우리가 디즈니 파괴 삼총사라고 부르는 3개의 게임은 돌핀에서 작동하는 걸 막기 위해 특별한 안티 에뮬레이션 기술을 사용했고, 우린 최근에서야 게임을 실행할 수 있게 됐습니다.

이 게임은 그보다 훨씬 오래 전에 나왔고, 그때는 돌핀이 오픈 소스로 나온지 몇 개월 밖에 되지 않았습니다.

우리는 2007년 게임인 로빈슨 가족에 숨겨진 조잡한 메시지에서 아발란체가 이미 홈브류와 에뮬레이션에 화가 났다는 충분한 증거를 얻었지만, 볼트가 안티 에뮬레이션을 위해 이렇게 했을 가능성은 매우 낮습니다.

 

악명 높은 디즈니 파괴 삼총사

왜냐하면 닌텐도 자체도 시스템 메뉴의 이전 버전에서는 이렇게 만들었기 때문입니다.

그 버전에서 시스템 메뉴는 IOS(구체적으로 ES 모듈)에 게임, 시스템 소프트웨어, 채널을 포함해 설치된 것의 목록을 요구합니다.

ES 모듈은 볼트와 같은 방식으로 단순히 파일 시스템에 저장된 폴더의 전체 목록을 얻어 어떤 게 설치되었는지 확인합니다.

실제 위에서 시스템 메뉴는 처음 설치된 것 중 하나로 절대로 가장 최근 게 될 수 없죠. 따라서 콘솔 목록의 첫 번째 항목으로 나올 수 없습니다.

하지만 돌핀에서는 사용자가 원하는 순서대로 자유롭게 설치할 수 있습니다. 즉, 시스템 메뉴가 잘못된 시간에 나타나면 볼트처럼 맛이 갈 수 있다는 겁니다.

몇 년간 더 많은 사용자가 이런 문제를 겪지 않은 이유는 돌핀 개발자가 자료를 남기지 않고 해킹해버렸기 때문입니다.

그리고 이 해킹은 볼트가 요구한 것과 모순되죠!

 

Leoetlino는 FST 파일에 올바른 순서와 다양한 메타데이터를 지정하여 이 문제를 해결했습니다.

메타데이터가 빠지거나 부저확해지는 문제를 막기 위해 생성 순서와 기타 파일 메타 데이터를 추적합니다.

그렇게 하여 볼트가 제대로 작동하게 되었고, 오래된 시스템 메뉴는 물론 그가 고칠 생각이 전혀 없었다고 말한 위 사진 채널 문제도 해결했습니다.

 

이전까지는 여러 번 재실행해야했지만, 이제는 새로운 위 낸드에서도 한 번에 된다

보다 구체적인 메타데이터를 신경 쓰는 게임이라면, 드래곤 퀘스트 X 뿐입니다.

이런 변화는 낸드가 게임과 훨씬 더 쉽게 호환되게 해줄 겁니다.

우리가 시험하고 위 지원이 끊기기 전에 돌핀이 서버에 접속하는 영상을 녹화할 때, 게임이 작동을 멈추게 만드는 어떤 일이라도 일어나는 건 정말 흔한 일이었습니다.

뭔가를 설정할 때마다 문제를 줄이기 위해 새로운 낸드로 시작해도 간혹 문제가 있었죠.

이제는 심각한 문제 없이 드래곤 퀘스트 X를 플레이하고 싶은 사람은 추가 설정에서 너무 많은 걸 신경 쓰지 않아도 될 겁니다.

그저 적절한 지역의 낸드인지, 필요한 모든 IOS를 설치했는지 확인하세요.

마지막으로 Leoetlino는 파일 시스템 에뮬레이션에 관한 광범위한 유닛 시험을 제공하여 향후 추가로 변경할 때 그 과정에서 더 나빠지는 걸 막을 수 있게 해주었습니다.

 

 

5.0-11590 AMD 젠에서 PDEP와 PEXT 사용 금지

보고서에 적지는 않아도, 작지만 수많은 최적화가 이뤄지고 있습니다. 정말 감사합니다.

하나 하나는 작을지 모르지만 눈덩이처럼 불어나 돌핀의 실행을 진정으로 개선합니다.

이번 달에는 최적화 전문가인 MerryMage가 Double2Single 플로팅 포인트 변환을 최적화했습니다.

이제 더 깨끗하고, 효율적이고, 더 새롭고 빠른 명령어를 사용합니다.

매우 작은 최적화라서 그래프로 표시하거나 특정 게임에서 얼마나 좋아졌는지 말할 수 없지만, 그 덕분에 돌핀은 정말로 더 좋아졌습니다.

안타깝게도 이 작은 최적화를 진행 보고서에 실지 못하게 만드는 예상치 못한 일이 일어났습니다.

최적화 후에 ADM 젠 프로세서 소유자들이 게임의 특정 상황에서 얼마나 느려졌는지에 관해 물밀듯이 보고했기 때문이지요.

 

최적화의 일환으로, 돌핀은 CPU가 지원한다면 PEXT 명령어를 사용합니다.

꽤 새로운 이 방식은 돌핀이 Double2Single 변환 중에 비트를 보다 효율적으로 이동할 수 있게 약간 교묘하게 처리한 것인데요.

우리 중 누구도 몰랐지만 PEXT는 AMD 젠과 젠 2 아키텍처에서 매우 느렸습니다.

사람들은 다른 CPU 아키텍처에서 단 한 번의 사이클을 하는데 비해 최대 289 사이클을 한다고 전했습니다.

그 이유는 CPU 자체에 직접 구현한 게 아니라 마이크로코드로 구현했기 때문이었죠.

마이크로코드는 번역기 역할로 많은 CPU 사이클을 사용해 비원시 명령어를 CPU가 실행할 수 있는 로우 레벨 μops로 변환합니다. 효과적으로 모방해서 이런 결과를 내는 거였죠. 어쩐지 너무 느리더라니!

 

끔찍한 성능에도 불구하고 젠은 PEXT를 지원했기에 돌핀은 이를 감지하고 Double2Single에 사용했습니다.

Double2Single 플로팅 포인트 변환을 수행할 때마다 성능은 곤두박칠쳤습니다. 아이고.

그래서 젠에서는 PEXT를 쓰지 않게 예외를 두었습니다. 하는 김에 PDEP도 추가했죠.

PDEP로 느려졌다는 보고는 없었지만, PDEP도 젠에 마이크로코딩되어있고 성능도 나빴으니 예방 차원이었습니다.

다른 CPU 아키텍처는 영향을 받지 않습니다. 우리가 아는 바로는 젠 이외의 모든 CPU는 직접 PEXT를 지원하거나 지원하지 않습니다.

 

https://ko.dolphin-emu.org/blog/2020/02/07/dolphin-progress-report-dec-2019-and-jan-2020/