- Honeykrisp는 아직 최종 사용자용으로 미출시이며, 개발자용 source code만 공개된 상태임
- M1용 Honeykrisp가 Apple hardware에서 첫 conformant Vulkan 구현이며,
portabilitywaiver 없이 Vulkan 1.3 전체 사양을 구현함 - Honeykrisp는 기존 M1 Vulkan 작업이 아니라 NVIDIA GPU용 오픈소스 NVK driver를 기반으로 하며, M1 코드를 추가하고 NVIDIA 관련 부분을 제거하는 방식으로 시작함
- Vulkan 1.3 conformance test suite의 최종 결과가 Pass 686930, Fail 0으로 기록됨
- 모든 상태를 동적 상태로 처리하고, prolog와 epilog를 빌드·컴파일·캐시하는 코드를 추가해 full dynamic state와
EXT_shader_object방향으로 구현함 - zero-copy rendering을 위해
EXT_image_drm_format_modifier를 구현함 - Direct3D 호환성을 위해 DXVK와 vkd3d-proton이 요구하는
EXT_custom_border_color를 지원하며, border colour 보정은 shader에 코드를 주입하는 방식으로 에뮬레이션함 - custom border colour 에뮬레이션은 “simple, correct, and slow”로 명시됐으며, 이후 driver tricks로 속도를 높일 계획임
- 다음 작업은 DXVK와 vkd3d-proton이 Direct3D 계층화에 요구하는 항목 구현이며, 예시로 transform feedback이 제시됨
한 달 만에 M1에서 Vulkan 1.3 지원
(rosenzweig.io)댓글과 토론
Hacker News 의견들
-
정말 인상적인 작업이고, 공유·반복 개선되는 열린 구성요소의 가치가 잘 드러남
Proton이 포팅되기까지 얼마나 걸릴지 궁금하지만, Vulkan 구현이 최적이어도 GPU 아키텍처 차이, ARM 변환 오버헤드, Proton 자체 비용 때문에 많은 게임은 성능이 나쁠 것 같음
그래도 Snapdragon 같은 SoC가 데스크톱에서 더 흔해지면 앞으로 더 많은 게임이 통합 메모리와 ARM을 목표로 하리라 낙관함- Asahi에서의 게임 경험이 macOS보다 더 쉽고 단순해진다면 꽤 아이러니할 듯함
지난 10년간 Apple이 Vulkan을 무시한 것이 얼마나 큰 실수였는지 보여주지만, 너무 늦기 전까지는 절대 인정하지 않을 것 같음 - dxvk가 필요 없는 게임 상당수가 60FPS 이상으로 돌아감. https://vt.social/@lina/112524118075585601 참고
Alyssa는 최근 FEX 성능 개선도 진행 중임
- Asahi에서의 게임 경험이 macOS보다 더 쉽고 단순해진다면 꽤 아이러니할 듯함
-
Linux에 Vulkan을 추가하고 Asahi Linux에서 DirectX를 변환하는 이 작업이 Apple Silicon에 AAA 게임을 유치하려는 Apple의 꿈에 영향을 줄지 궁금함
Apple은 AAA 개발사들이 게임을 Metal로 포팅해서 iPhone, iPad, Mac, Vision Pro에서 하나의 코드베이스로 돌아가길 바랄 것임
어쩌면 Mac 게이머들이 AAA PC 타이틀을 하려고 Asahi Linux를 설치하게 될 수도 있음- Apple의 꿈은 AAA 게임이 Apple Silicon에 올라오는 게 아니라, Apple App Store에 올라오는 것임. Proton 같은 계층은 GPTK처럼 만들 수 있음
진짜 바라는 건 Steam이나 Epic Games Store가 아니라 App Store에 AAA 게임이 들어오는 것이고, 그래서 GPTK가 반쪽짜리이며 라이선스도 Valve가 Steam에 직접 통합하지 못하게 막는다고 봄 - Asahi Linux는 게임하려고 듀얼 부팅하던 Mac 사용자에게 새로운 Boot Camp가 될 수 있음
M1에서 Whiskey로 Diablo II Resurrected를 해봤는데, Windows 네이티브 게임이 그렇게 바로 되는 점이 꽤 인상적이었음. 지금은 멍청한 Blizzard 런처 업데이트가 크래시를 내서 게임 실행을 막을 뿐임
오래된 DX9 게임이긴 하지만 EverQuest II도 M1 Mac mini에서 1440p로 아주 잘 돌아갔고, Asahi Linux는 Guild Wars 같은 오래된 32비트 타이틀에도 도움이 될 수 있음 - Apple이 정말 그걸 원했다면 그냥 Vulkan을 구현하면 됨
- Apple은 이미 Game Porting Toolkit을 공개했음
- Apple의 꿈은 AAA 게임이 Apple Silicon에 올라오는 게 아니라, Apple App Store에 올라오는 것임. Proton 같은 계층은 GPTK처럼 만들 수 있음
-
Vulkan 1.3을 잘 모르지만 저수준 그래픽 API 작업에 관심이 있다면 꼭 살펴볼 만함. Vulkan 1.0과는 완전히 다른 수준이고 판도를 바꿔놓음
초기 장벽만 넘으면 작업이 즐겁고, 모든 동적 상태와 사전 렌더 패스 설정 제거 덕분에 훨씬 다루기 쉬움. 20년간 써온 OpenGL보다도 쉬워졌고, 그래픽 프로그래밍이 다시 재미있어짐
최신 드라이버만 있다면 대략 10년 이내 GPU를 가진 모든 데스크톱 플랫폼에서 대부분 기능을 쓸 수 있음
아쉽게도 바로 시작할 수 있게 해주는 “합리적 기본값” 프레임워크는 없지만, 여러 언어용 유용한 도우미 라이브러리는 많음- OpenGL은 20년 동안 조금씩 만져왔고, 전문 게임 프로그래머는 아니지만 여가 시간에 3D 콘텐츠를 만듦
Vulkan으로 넘어갈 시간이 없었는데, 결국 초기화와 설정 장벽만 넘으면 될 것 같음. 그 뒤에는 OpenGL로 돌아가지 않을 듯함
이 글이 조금 자극이 돼서 실제로 해봐야겠다는 생각이 듦 - Vulkan 1.3을 구체적으로 시작할 수 있는 튜토리얼이나 문서가 있을까? 마지막으로 찾아봤을 때는 예전 방식과 새 방식이 여러 조합으로 뒤섞인 자료뿐이었음
OpenGL도 원래 그랬으니 크게 다르지 않은 셈일지도 모르지만, Khronos가 참 잘도 해냈다는 느낌임
- OpenGL은 20년 동안 조금씩 만져왔고, 전문 게임 프로그래머는 아니지만 여가 시간에 3D 콘텐츠를 만듦
-
ES 3.2 지원 때문에 방금 업데이트했는데 벌써 놀라움. 내 M1은 Asahi를 위해 만들어진 것처럼 느껴짐
솔직히 macOS는 설치 중이거나 실수로 한 번만 부팅했을 가능성이 큼. 이런 자세한 업데이트가 있어서 좋음
브라우저 중에 무복사 렌더링을 지원하는 게 있는지, 아니면 아직도 컴포지터 계층이 여러 겹 끼어 있는지 궁금함. WebGL2 변환 피드백이 읽기 되돌림을 유발해서 막혔던 기억도 있음- macOS를 완전히 제거할 수 있나? 이걸 보니 여행용으로 Mac mini를 고려하게 됨
-
뭔가 크래시가 나도 컴파일러 버그일 리는 절대 없다고 생각했는데, 4월 16일에는 실제로 컴파일러 버그였음
커리어 동안 그런 일을 겪어본 적은 없다고 자신 있게 말할 수 있지만, 추상화 수준이 낮아질수록 덜 드문 일일 수도 있겠음- 컴파일러 버그일 리 없고, CPU 버그일 리도 절대 없음
단, 저수준 커널 개발자라면 둘 다 맞을 수 있음
농담은 제쳐두고도 실제로는 아닌 경우가 훨씬 많지만, 분명히 발생하긴 함 - 적어도 레지스터 할당기 부분은 직접 작성한 것 아닌가?
테스트 중인 자기 작업물인 진행 중 컴파일러라면 “컴파일러 버그일 리 없다”는 격언이 잘 적용되지 않음
- 컴파일러 버그일 리 없고, CPU 버그일 리도 절대 없음
-
셰이더에 특이한 구조가 들어 있음:
if (condition) { while (true) { } }
condition은 항상 거짓이지만 컴파일러는 그걸 모름
표준을 지키는 셰이더 컴파일러 작성자를 괴롭히는 독약 말고, 이 구조의 목적이 뭔지 궁금함- 테스트의 핵심이 컴파일러 작성자에게 독약 같은 입력을 던져서 어떤 셰이더가 들어와도 깨지지 않게 만드는 것 아닌가?
해당 코드 자체가 실무에서 유용하다기보다, 셰이더 일부가 특정 상황에서 기능적으로 이런 형태로 단순화될 수 있다면 컴파일러가 제대로 처리해야 함 - 이 구조의 목적은 컴파일러에 조건이 항상 거짓이라는 사실을 알려서 최적화기가 더 많은 최적화를 하게 만드는 것일 수 있음
개념이 익숙하지 않다면 C++, LLVM, Rust의 이런 기능을 보면 됨:
https://en.cppreference.com/w/cpp/utility/unreachable
https://en.cppreference.com/w/cpp/language/attributes/assume
https://en.cppreference.com/w/cpp/memory/assume_aligned
https://llvm.org/docs/LangRef.html#unreachable-instruction
https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
무한 루프는 사실상 도달 불가능 명령이고, 분기 뒤의 도달 불가능 명령은 사실상 assume 명령이 됨 - 셰이더가 “패닉”을 내는 방식이 이런 건가?
- 어떤 코드 생성의 경계 사례일 수도 있음
- 테스트의 핵심이 컴파일러 작성자에게 독약 같은 입력을 던져서 어떤 셰이더가 들어와도 깨지지 않게 만드는 것 아닌가?
-
이걸 VM 안에서 쓸 수 있는지 궁금함. macOS에서 개발하고 대체로 만족하지만, 테스트용으로 VMware의 Ubuntu 이미지를 돌림
3D 그래픽 앱을 만들고 있어서 VMware의 패스스루가 어느 정도인지 잘 모르겠음. VM에서 Apple Silicon GPU가 가상화되는지, 이 배포판을 돌리면 그래픽 성능이 더 나아질 수 있는지 궁금함- 네이티브로 설치해야 함. macOS 위의 Windows/Linux/macOS VM에서 좋은 3D 성능을 원한다면 VMware보다 Parallels가 훨씬 나음
-
이게 MoltenVK와 어떤 관계인지 설명해줄 수 있나? 네이티브 드라이버라서 MoltenVK가 필요 없어지는 건가?
- MoltenVK는 macOS에서 Vulkan 애플리케이션을 실행할 수 있게 Metal 기반으로 만든 Vulkan 구현임
Asahi Linux는 Apple M 시리즈 프로세서에서 Linux를 호환되게 하려는 개발 중 배포판이고, 이 글은 Asahi에서 GPU 가속 Vulkan이 동작하게 만드는 내용임 - 이건 M1 Mac 하드웨어의 Asahi Linux에서 Vulkan을 쓰는 이야기임. MoltenVK는 macOS에서 Metal 위에 Vulkan을 제공함
- 이건 macOS가 아니라 Linux의 Vulkan에 관한 내용임
- MoltenVK는 Metal을 Vulkan으로 변환함. Metal은 OS X와 iOS의 주 그래픽 API이고, 이건 Linux용 네이티브 Vulkan 구현임
글에서도 그렇게 말하고 있음. 이건 OS X에서 직접 실행될 수 없으니 MoltenVK의 필요성을 없애지는 않음
- MoltenVK는 macOS에서 Vulkan 애플리케이션을 실행할 수 있게 Metal 기반으로 만든 Vulkan 구현임