돌핀 에뮬레이터 10월 진행 보고서

윈도우 디펜더의 클라우드 AI가 돌핀의 업데이트 프로그램을 트로이 목마로 인식하는 문제가 계속되었습니다.

마이크로소프트는 돌핀 업데이트 프로그램이 트로이 목마가 아니라는 걸 인정했지만, 손수 실행 파일을 화이트리스트로 만들어야한다는군요.

우리는 윈도우 디펜더가 업데이트로 배포하는 월간 빌드를 삭제하기 않게 화이트리스트에 들어있다는 걸 확인했습니다.

해결됐다고 알릴 때까지 계속 마이크로소프트에 잘못 됐다고 보고해주시면 감사하겠습니다.

이에 대한 보고서와 돌핀의 듀얼쇼크 4의 모션 컨트롤 지원 등의 내용을 얘기해보죠.

 

5.0-10950 XAudio2 제거

XAudio는 매우 긴 기간 동안 윈도우 버전 돌핀의 기본 오디오 백엔드였습니다.

윈도우에서 지연 시간이 짧고, 안정적이고, 일관적이며, 신뢰할 수 있는 오디오를 얻을 수 있는 거의 유일한 방법이었습니다. 플랫폼의 기본 오디오 백엔드로 선택하는 건 당연한 일이었죠.

하지만 시대가 바뀌었습니다.

 

돌핀의 새로운 기본 오디오 백엔드인 Cubeb는 모든 면에서 업그레이되었습니다.

Cubeb는 파이어폭스를 만드는 모질라가 개발한 오픈 소스 크로스 플랫폼 오디오 라이브러리로 로컬 오디오 API와 인터페이스하여 어디서나 지연 속도가 낮습니다.

오픈 디자인이라 지원하기도 굉장히 쉽고, 멀티플랫폼도 가능해서 모든 개선과 새로운 기능이 우리가 지원하는 모든 OS에 이득을 줄겁니다.

가장 중요한 것은 Cubeb가 XAudio2와 같은 내부 오디오 API(WASAPI)를 활용하면서도 지연 시간이 조금 더 줄어든다는 겁니다.

Cubeb에 없는 유일한 기능은 XAudio2도 없는 기능인 WASAPI 전용 모드입니다.

이 모드는 핵심 API에 직접 액세스하여 오직 돌핀만 소리를 내게 해 지연 시간이 매우 낮아집니다. 다른 프로그램에서는 소리가 안 나죠.

하지만 이 기능을 위해 특별히 WASAPI 전용 모드 오디오 백엔드가 있습니다.

XAudio는 여전히 잘 작동하지만, 더 다재다능하고 유지보수도 쉽고 성능도 더 좋은 걸 두고 굳이 유지할 이유는 없습니다.

 

숭고한 XAudio2는 이제 가장 나쁘다

이제 새로운 오디오 백엔드의 모든 성장통이 처리되었으니, XAudio2는 서부 영화의 주인공처럼 석양을 향해 떠날 때가 되었습니다.

이전 빌드에서 XAudio를 선택한 상태로 업데이트를 했다면 오디오 백엔드 선택창이 비어있을 테지만, 돌핀은 자동으로 Cubeb를 사용할 겁니다. 바꿔주면 좋지만 그렇지 않아도 괜찮아요.

 

 

5.0-10996 CPU 에뮬레이션 엔진 설정을 고급 탭으로 이동

돌핀은 사용자가 바꾸고 싶어하는 여러 CPU 에뮬레이션 설정을 가지고 있습니다.

JIT 버그, JITIL의 이상한 점, 인터프리터와의 문제를 계속 확인해야할 필요가 있어 설정을 바로 앞 중심에 두었죠.

오늘날에는 CPU 에뮬레이션 설정이 잘 되어서 일반 사용자가 JIT에서 바꿔야할 실질적인 이유가 없습니다.

이제는 디버그 문제를 찾는 고급 사용자만 필요할 것이라고 생각해 고급 탭으로 옮기기로 했습니다.

 

 

 

50.0-11035 수식 파서 개선

게임큐브는 물론 특히 위는 기존의 입력 장치에 지정하기 어려운 매우 독특한 컨트롤러를 쓰는 게임기입니다.

돌핀의 컨트롤러 설정 인터페이스가 모든 종류의 고급 기능을 쉽게 지정할 수 있도록 많은 일을 했습니다.

하지만 메인 컨트롤러 설정이 할 수 있는 일은 한계가 있기에 충분하지 않은 경우 사요자가 가장 복잡한 조작 설정도 할 수 있게 고급 입력 구성 창이 있습니다. 입력 상자를 오른쪽 클릭하면 쓸 수 있죠.

그렇긴 하지만 사용하기가 쉽지 않았습니다. 사용자는 이 강력한 도구를 이해하기 위해 혼자 힘으로 노력해야했죠.

익숙한 사람조차도 간혹 헷갈릴 때가 있었스비다.

Billiard는 우리의 입력 시스템을 개선하려는 그의 성전을 계속했고, 고급 입력 설정 UI을 더 이해하기 쉽게 할 뿐만 아니라 더 강력하게 만들었습니다.

 

항상 강력했지만 선뜻 도움이 되지 않던 고급 입력 설정이 더 강력하고 친숙해졌다

새로운 수식을 많이 넣는 것 외에도 사용자들이 가능한 것을 볼 수 있도록 하는 다양한 기능의 드롭다운을 추가했습니다. 제대로 한 건지 확인할 수도 있죠.

고급 입력 설정은 그 어느 때보다 강력하며 사용하기도 좀 더 쉬워졌습니다.

 

5.0-11054 Redump.org 통합 추가,  5.0-11059+5.0-11071 극단적인 핸들링 검증기 개선

게임 보존은 우리 커뮤니티에서 매우 중요한 주제입니다.

우리 개발자들은 위와 게임큐브의 시스템과 게임게 관심을 갖고 기기의 작동 방식을 재현하기 위해 수년간 노력했습니다.

하지만 아무리 정확하게 에뮬레이션을 해도 부적절하게 덤프한 디스크는 간단한 그래픽 결함부터 게임이 망가지는 것까지 모든 종류의 문제를 일으킬 수 있습니다.

최근 게임 속성 메뉴에 추가한 검증 탭은 사용자가 별도의 프로그램 없이 게임을 보다 쉽게 확인할 수 있도록 도와주는 우리 방식이었스비다.

게임을 확인할 수 있는 건 물론, 덤프에서 다른 잠재적인 문제를 알아챌 수도 있죠.

 

하지만 게임 검즘 휴리스틱에는 한계가 있습니다.

덤프의 작동 여부를 알려줄 수는 있지만, 검증된 덤프인지는 알려줄 수 없습니다.

게임큐브 게임에서 특히 문제가 되는데 덤프 데이터가 적절한지 아닌지 알아낼 방법이 많지 않기 때문입니다.

사실 우리가 쓸 수 있는 최선의 방법은 덤프할 때 다른 사람이 가진 것과 비교하는 겁니다.

그래서 돌핀은 Redump.org에서 관리하는 데이터베이스를활용하고 있죠.

거기에는 게임큐브를 포함한 많은 콘솔의 검증된 덤프가 거의 완전하게 정리되어 있습니다.

검증 탭에 그 데이터베이스를 활용하여 이전에 보지 못한 잘못된 덤프를 알아볼 수 있게 됩니다.

데이텔 프리부트 위 디스크는 특별히 예외인데 제대로 위 덤프를 하기 위한 규칙에도 불구하고 그쪽에서는 어떻게든 이상하게 만들기 때문입니다.

 

 

5.0-11083 듀얼쇼크 같은 모션 컨트롤러 지원

연초에 에뮬레이션한 모션플러스로 젤다의 전설: 스카이워드 소드 같은 게임을 위 리모컨 없이 플레이하는데 성공했습니다.

처음으로 자이로스코프와 가속도계 입력을 다른 입력 장치에 지정할 수 있었죠.

하지만 많은 게임은 모션 컨트롤러가 없으면 플레이하기 어렵기 때문에 다음 단계로 나아가야했습니다.

이런 경험을 위 리모컨의 수명을 넘어서 보존하려면, 현대 모션 컨트롤러의 힘을 이용할 수 있어야 했습니다.

 

안타깝게도 이를 깔끔하게 처리하는 방법을 찾는 건 거의 불가능에 가까웠습니다.

리눅스에서는 모션 센서 축이 노출되고 이용할 수 있습니다. 리눅스와 사람들은 모든 것을 완전히 통제하지 못한다면 분노에 휩싸여 일어날지도 모르기에 그런 것 같습니다.

윈도우에는 꽤 지저분했습니다. 윈도의 거의 모든 컨트롤러 API는 기존의 컨트롤러를 위해 만들어졌고 모션 센서를 완전히 무시할 테니까요.

선택지가 일부 있었고 오래된 UDPWiimote처럼 일부 구현한 것도 있었습니다. 하지만 한계가 크거나 필요에 따라 작동시킬 수 없다는 걸 깨달았죠.

다행히 이 문제를 다루는 건 우리 뿐만이 아니었습니다. Cemu와 Citra 돌 두 DSUClient 표준을 이용합니다.

DS4Windows의 커스텀 드라이버와 UDP 서버/클라이언트 시스템의 포크를 사용하면 표준 컨트롤러 API 없이 직접 모션 데이터에 액세스할 수 있었죠!

그리고 이제 돌핀도 rlnilsen의 작업 덕분에 그렇게 할 수 있습니다.

 

리눅스 사용자는 DSUClient가 필요 없지만, 모션 입력을 노출시키기위 해 UI를 작업하는 건 리눅스 사용자에게도 도움이 될 겁니다.

리눅스에서 윈도우에서 쓰는 커스컴 드라이버와 DSUClient 비트를 뺄 뿐이지 거의 동일합니다.

리눅스 사용자는 직접 모션 센서를 지정하면 됩니다.

 

새 프로필은 자동으로 채워진다

할 수 있는 것:

듀얼쇼크 3/4, 닌텐도 스위치 컨트롤러, 스팀 컨트롤러가 있다면 모션 센서 데이터를 직접 돌핀에 보낼 수 있습니다.

추가적으로 에뮬레이션 모션플러스를 제대로 작동하기 위해 추가한 위 리모컨 시뮬레이션 덕분에 자이로스코프와 가속도계 입력을 바탕으로 적외선 데이터도 만들 수 있습니다.

본질적으로 단순히 컨트롤러를 움직이면 위 리모컨과 센서 바를 쓰는 것처럼 적외선 포인터가 이동하여 적외선 데이터에 관해 걱정할 필요가 전혀 없다는 뜻입니다.

바이오하자드 4, 슈퍼 마리오 갤럭시 같은 게임에서 포인터 시뮬레이션은 적외선을 방해할 수 있는 많은 제한에 더 이상 얽매이지 않기 때문에 게임을 더 쉽게 할 수 있습니다.

 

적외선은 어디서든 매끄럽고 정확하며 버튼으로 간단히 작업할 수 있다

모션 패스스루는 실제 위 리모컨을 쓰는 것을 뛰어넘는 이점이 몇 가지 있습니다.

슈퍼 마리오 갤럭시에서는 흔들림을 버튼으로 지정하는 식으로 입력 에뮬레이션을 활용할 수 있습니다.

마리오가 도는 버튼을 누르면서 진짜 움직임으로 조준할 수 있다는 얘기입니다.

한계는 있습니다. 위 리모컨 모양에 맞춰 만든 게임은 두 번째 가속도계가 있으면 작은 문제가 생깁니다.

 

위 리모컨과 눈차크를 동시에 다른 방향으로 움직이도록 하는 노 모어 히어로즈 같은 게임에서는 좀 더 복잡해지는데요.

바로 위의 수식 파서 개선으로 약간 조정할 수 있습니다.

게임은 한 손으로 위 리모컨을 잡을 거라 가정하기 때문에 좌우 이동이 게임이 원하는 만큼 잘 되지 않을 수 있습니다.

하지만 수식 파서로 가속도계 움직임을 곱해 더 쉽게 움직일 수 있죠.

한 세트의 모션 입력으로 듀얼쇼크 같은 컨트롤러의 두번쨰 스틱을 눈차크 휘두르기로 지정할 수 있습니다.

이 모든 걸 고려하면 게임을 재미있게 즐길 수 있습니다.

 

위 리모컨의 특이함에 많이 의존하는 게임도 있다

현대 컨트롤러 센서의 힘을 사용하여 에뮬레이션한 위 리모컨으로 실제 위 리모컨과 거의 대등해졌습니다.

항상 완벽하지는 않을 것이며 일부 설정이 필요할 수도 있지만, 마침내 좋은 게임 경험을 위해 원래의 하드웨어에 의존하지 않아도 되는 시점에 왔다고 말할 수 있습니다.

불과 1년 전 돌핀의 모션 시뮬레이션이 얼마나 어색했는지 생각해보면, 이 지점까지 작업하여 이끌어준 개발자의 공로를 인정해야합니다.

지원되지 않는 기능을 없앴든, 버그를 고쳤든, 역설계를 했든 여기까지 올 수 있게 한 장본인이죠.

 

이외에도 위 리모컨 에뮬레이션에는 몇 가지 변경점이 더 기다리고 있습니다.

몇 주 내에 동일한 컨트롤러나 다른 컨트롤러에 눈차크 모션을 지정할 수 있는 눈차크 모션 입력이 완료될 거라 봅니다.

API 측면에서는 위 리모컨의 경험을 거의 1:1로 똑같이 재현할 수 있는 막대기 형태의 컨트롤러를 활용할 방법을 열심히 찾고 있습니다.

 

설정 방법:

윈도우에서는 모션 컨트롤이 너무 엉망이라 처음 설정하는 일이 좀 힘들 수도 있습니다.

사용할 컨트롤러에 따라 방식과 패스스루 모션 데이터에 사용할 프로그램이 달라집니다.

돌핀 위키에 접속하여 DSUClient 페이지에서 모든 설정 방법을 자세히 볼 수 있습니다.

리눅스에서는 훨씬 간단합니다. 모션 센서 축을 모션 입력 탭에 적절히 지정하면 끝입니다.

 

 

5.0-11098 안드로이드 말리 EFB2RAM 최적화

안드로이드 말리(Mali) 기기를 사용하는 사람에게 좋은 소식입니다.

여전히 아드레노(Adreno)가 더 빠르긴 하지만, stenzek은 드디어 말리에서 비정상적으로 낮은 성능의 원인인 거대한 병목 현상 중 하나를 해결하는데 성공했습니다.

'EFB 복사를 램에 담기'는 부담이 큰 기능이고 성능이 떨어질 걸 예상해야하지만, 말리에서는 생각 이상으로 성능이 떨어졌습니다.

stenzek은 프레임드랍을 조사했고 말리가 "__pi___inval_cache_range" 커널 함수에서 CPU 사용률이 많다는 걸 알아냈습니다.

우리 대부분에게는 별 의미 없을지도 모르지만, 본질적으로 캐시된 메모리를 무효화하는데 많은 시간을 쓴다는 겁니다.

그가 캐시되지 않은 메모리로 전환하자 'EFB 복사를 램에 담기'를 사용하는 게임은 프레임이 약 30% 개선되었습니다.

 

모든 게임이 아니라 'EFB 복사를 램에 담기'를 사용하는 게임만 개선되었으니 주의하세요.

아드레노 기기에는 아무 영향도 없습니다. 많이 시험해봤는데 성능이 똑같더군요.

 

 

5.0-11102 VK_EXT_full_screen_exclusive를 통한 Vulkan 독점 전체화면 지원

대부분의 그래픽 드라이버가 Vulkan으로 독점 전체화면이 가능하기 때문에 이번 건 다소 형식적인 겁니다.

이 기능을 지원해서 혼동을 없애고 상황을 더 일관되게 하길 바랄 뿐입니다.

다른 진행 보고서에서 언급했듯이 독점 전체 화면은 모니터로 출력하는 것보다 근본적으로 보다 직접적인 방식입니다.

데스크탑의 컴포지터를 바이패스하여 모든 프레임이 제대로 전달되도록 하여 지연 시간을 주이죠.

대부분은 별 영향이 없겠찌만 독점 전체화면이 안 되던 일부 사람들의 문제를 해결할 겁니다.

 

독점 전체면인 오른쪽은 록맨이 공격당하고 제대로 깜빡인다

이 기능은 꽤 새로운 것이라서 그래픽 드라이버를 업데이트해야할지도 모릅니다.

 

 

윈도우 디펜더: 클라우드 AI에 고함

서두에서 이야기했듯이 윈도우 디펜더(곧 마이크로소프트 디펜더로 개명 예정)은 우리의 updater.exe를 트로이 목마로 잘못 인식해왔습니다.

트위터에서 문제를 확인하고 재현하는 등 노력해왔는데 이 문제에 관해 수준 높은 논의와 해결책을 향한 우리의 투쟁을 자세히 알고 싶다면 읽어보세요.

진행 상황 보고서긴 하지만 우리가 이해하고 있는대로 상황에 관해 자세한 사항을 제대로 설명하는 게 가장 좋다고 생각했습니다. 알기 쉽게 설명할 방법이 없으니 이 얘기는 꽤 기술적일 겁니다.

 

사용자와 테스터 사이를 많이 다니며 문제를 화실히 재현하는 건 어려웠고, 몇 주간 애를 쓰다가 윈도우 디펜더의 잘못된 인식의 근원이 마이크로소프트의 기계학습 기반 클라우드 서비스라는 것을 알게 되었습니다.

마이크로소프트(MS)는 이 문제를 알고 정말 신속하게 대응했지만, 기계학습을 기반으로 하기 때문에 MS는 잘못된 인식을 '제대로된 답변 쪽으로 조정'하는 부분을 너무 많이 '고칠' 수 없었고, 그 회사의 AI는 업데이트 프로그램이 트로이 목마라고 확신하는 것 같았습니다.

MS가 할 수 있는 일은 업데이트 프로그램을 예외로 만드는 것 뿐이었죠.

이렇게 하면 문제가 해결될 거라 생각했지만 사용자가 계속 보고서를 보내오면서 우리 생각보다 훨씬 더 골치 아픈 문제라는 걸 깨달았습니다.

 

컴파일러의 작동 방식 떄문에 파일 안에서는 아무것도 바꾸지 않더라도 다시 빌드하면서 조금씩 바뀔 겁니다. 평범한 일이죠.

우리는 마이크로소프트의 공식을 모르지만, 윈도우 디펜더는 매우 기본적인 해시 알고리즘을 사용한 것 같습니다.

예외 처리한 파일의 단 한 비트만 바뀌어도 해시가 완전히 바뀌고 윈도우 디펜더는 고유한 별개의 파일로 인식하죠.

그런 이유로 예외 처리는 별 도움이 안 됩니다.

모든 새 빌드에는 새로 만들어진 updater.exe가 있고, 윈도우 디펜더는 새로운 파일로 인식합니다.

그래서 각 빌드의 파일을 마이크로소프트가 일일이 예외 처리해야하죠.

그래서 오래된 것이든 새로운 것이든 업데이트 프로그램을 사용한 거의 모든 빌드는 누군가가 MS에게 잘못된 탐지라고 보고하여 예외 처리될 때까지 윈도우 디펜더에게 삭제되고 있습니다.

아무리 좋게 말하려고 해도 안 좋은 상황입니다.

 

MS 측에서 할 수 있는 건 없고, 우리가 할 수 있는 건 거의 없습니다. 결국 별다른 일을 하고 있지 않지요.

컴파일러에서 다시 빌드하는 동안 조금 변하는 건 정상입니다. 정확한 비트의 빌드는 상당히 최근 개념으로 아직 잘 지원되지 않아요.

예를 들어 MS의 자체 컴파일러인 MSVC와 우리가 돌핀 윈도우 버전을 만들 때 쓰는 건 빌드 간 비트 정확도를 향상시키기 위한 BREPRO라는 컴파일러 플래그가 있습니다.

안타깝게도 우리한테는 효과가 없었고, BREPRO는 문서로 남아있지도 않아서 이유를 알 수가 없습니다.

 

이런 작은 빌드 변화를 피할 수 있는 한 가지 방법은 이전에 빌드한 모든 파일을 저장하는 겁니다.

새로운 빌드에 변경점이 없으면 수정하지 않은 기존 파일을 다시 쓰는 거죠.

컴파일 캐싱이라고 알려진 것인데 이론적으로 업데이트 프로그램을 더 오래 같을 것이고 예외처리도 더 오래 가겠죠.

하지만 이론은 이론일 뿐입니다. 현실은 그렇게 단순하지 않아요.

돌핀의 빌드봇은 수 년간 컴파일 캐싱을 했지만 우리는 아직도 이 문제에 직면해 있으니까요!

컴파일 캐싱은 빌드 간 바뀌지 않은 파일을 전송할 수 있지만, 파일과 파일 종속성이 바뀌지 않은 경우에만 가능합니다.

업데이트 프로그램은 돌핀과 많은 코드를 공유하며 돌핀의 공통 코드에 의존하기에 바꿀 때마다 다시 연결됩니다.

컴파일 캐싱도 마찬가지라서 update.exe는 매 빌드마다 아주 작은 차이가 있습니다.

 

cmake의 허용성 때문에 공통의 어떠한 변화도 업데이트 프로그램의 의존 여부와 관계 없이 재연결로 이어질 겁니다.

bazel 같은 허용성 낮은 빌드 시스템으로 이동하여 좀 줄일 수도 있겠지만, 그렇게 되면 전체 빌드 시스템을 교체해야합니다. 작업량이 어마어마하겠죠?

재연결 확률이 줄어들뿐 성능으로는 어떤 이득도 없습니다.

MS의 괴팍한 AI를 좀 더 쉽게 다루려고 우리 시간과 기력을 쓰는 건 진짜 엄청난 낭비에요.

 

여기까지 오면 선택지가 더 나빠질 뿐입니다.

업데이트 프로그램을 에뮬레이터에 완전히 분리하고 공유 코드를 복제하면... 아냐. 아냐. 아냐. 아니 안 돼.

그거 정말 끔찍한 생각이네요.

 

솔직히 말하면 우리가 걱정할 필요가 없는 일입니다.

빌드 간의 작은 비트 변화는 지극히 정상이고, 이런 변화를 줄이기 위해 해야할 작업량은 어마어마해요.

사용자들을 위해 이 문제를 해결할 방법을 찾고 싶지만, 우리로서는 안 될 것 같습니다.

잘못 행동하는 AI를 개선하고 정상적인 행동과 변형을 잘못 인식하는 걸 멈추게 하는 건 MS의 몫입니다.

MS가 이 문제를 해결할 수 있을 때까지 윈도우 디펜더가 업데이트 프로그램을 잘못 인식한다고 MS에 계속 보고해주세요.

다른 사용자가 잘못 인식당하는 상황에 처하지 않게 예외 처리를 하는 것은 물론, 결국에는 MS의 AI가 우리는 위협이 아니라는 걸 확신시킬 수 있을 겁니다.

 

 

https://ko.dolphin-emu.org/blog/2019/11/07/dolphin-progress-report-october-2019