OpenGL ES 적합성 인증을 받은 첫 M1 GPU 드라이버

 (rosenzweig.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • M1·M2 계열 GPU에서 OpenGL ES 3.1 애플리케이션을 표준대로 실행할 수 있는 Linux용 드라이버가 제공됨
  • Asahi Linux의 역공학 기반 무료·오픈소스 드라이버는 M1·M2 그래픽 하드웨어에서 Khronos 적합성 테스트를 통과한 유일한 OpenGL ES 3.1 구현임
  • 인증은 공식 테스트 통과와 Khronos 제출, 30일 검토 기간을 거치며 M1, M1 Pro/Max/Ultra, M2, M2 Pro/Max 항목이 등록됨
  • OpenGL ES 3.1은 6월의 실험적 OpenGL ES 3.0·OpenGL 3.1 지원을 갱신하고, 컴퓨트 셰이더와 이미지 원자 연산을 추가함
  • M1에는 이미지 원자 연산 전용 명령이 없어 주소 계산으로 우회했으며, 이후 비트 인터리브 명령을 찾아 10개 명령을 1개로 줄임

M1·M2용 OpenGL ES 3.1 적합성 인증

  • M1·M2 계열 GPU용 OpenGL ES 3.1 적합성 인증 드라이버가 제공됨
    • OpenGL ES 3.1 애플리케이션과 호환됨
    • Linux 설치로 사용할 수 있음
  • 기존 Asahi Linux 사용자는 배포판별 업그레이드 명령으로 최신 드라이버를 받을 수 있음
    • Fedora: dnf upgrade
    • Arch: pacman -Syu
  • 역공학 기반 무료·오픈소스 그래픽 드라이버는 asahi/mesa에 공개되어 있음
  • 이 드라이버는 M1·M2 계열 그래픽 하드웨어에서 세계에서 유일한 OpenGL ES 3.1 적합성 인증 구현임
    • 수만 개 테스트를 통과해 정확성을 입증함
    • 업계 표준 기구의 인정을 받음

Khronos 절차와 등록된 칩 계열

  • 적합성 인증을 받으려면 구현체가 공식 적합성 테스트 스위트를 통과해야 함
    • 테스트 스위트는 명세의 모든 기능을 검증하도록 설계됨
    • 테스트 결과는 표준화 기구 Khronos에 제출됨
    • 30일 검토 기간 동안 문제가 없으면 적합성 인증 구현이 됨
  • Khronos 웹사이트에는 다음 드라이버가 적합성 인증 구현으로 등록됨
  • 이번 성과는 OpenGL ES에만 머물지 않음
    • M1용 그래픽 표준 전체에서 첫 적합성 인증 구현에 해당함

제조사 드라이버와 표준 API의 간극

  • 제조사의 M1 드라이버는 Vulkan, OpenGL, OpenGL ES를 포함한 어떤 표준 그래픽 API에서도 적합성 인증을 받지 못함
  • Linux를 사용하지 않는 M1·M2 환경에서는 표준 기반 애플리케이션이 동작한다는 보장이 없음
  • Vulkan 사례에서 MoltenVK는 독점 드라이버 위에 Vulkan 일부를 계층화함
    • 해당 독점 드라이버에는 핵심 기능이 빠져 있음
    • 유효한 Vulkan 애플리케이션이 깨질 수 있음
    • M1·M2 컴퓨터를 Linux로 전환하지 않은 개발자와 사용자 모두에게 장애가 됨
  • Asahi Linux 드라이버 개발은 표준 소프트웨어가 M1 전용 해킹이나 포팅 없이 실행되는 것을 목표로 함
    • 독점 드라이버, 독점 API, 표준 구현 거부에 만족하지 않음
    • 명세에 맞는 오픈 표준 구현을 생태계의 바람직한 방향으로 봄

OpenGL ES 3.1의 핵심 추가 기능

  • OpenGL ES 3.1은 6월에 제공된 실험적 OpenGL ES 3.0 및 OpenGL 3.1을 갱신함
  • 주요 추가 기능은 컴퓨트 셰이더임
    • 그래픽 애플리케이션 안에서 일반 계산을 가속하는 데 주로 사용됨
    • 3D 게임은 물리 시뮬레이션을 컴퓨트 셰이더에서 실행할 수 있음
    • 시뮬레이션 결과를 렌더링에 바로 사용하면 GPU와 CPU 물리 시뮬레이션 사이 동기화로 생기는 정지를 줄일 수 있음
    • 그 결과 게임이 더 빠르게 실행될 수 있음

이미지 원자 연산이 필요한 이유

  • OpenGL ES의 이전 버전은 애플리케이션이 화면 표시를 위해 이미지를 읽을 수 있게 했음
  • ES 3.1은 애플리케이션이 보통 컴퓨트 셰이더에서 이미지에 쓰기를 할 수 있게 함
    • 이미지 처리 알고리듬을 고정 기능 3D 파이프라인에 맞춰야 하는 제약이 줄어듦
  • GPU는 수천 개 스레드를 동시에 실행하는 대규모 병렬 구조임
    • 두 스레드가 같은 위치에 쓰면 실행 순서에 따라 결과가 달라짐
    • 이 상황이 경쟁 조건임
  • 원자적 메모리 접근은 경쟁 조건을 다루는 기본 해법임
    • 메모리 서브시스템의 특수 하드웨어가 선택된 연산에 대해 스레드 순서와 무관하게 일관된 결과를 보장함
    • 최신 그래픽 하드웨어는 덧셈 같은 여러 원자 연산을 지원함
  • OpenGL ES 확장 OES_shader_image_atomic은 이미지 픽셀에 대한 원자 연산을 추가함
    • 이 확장은 ES 3.2에서 필수임
    • 예를 들어 컴퓨트 셰이더가 픽셀 (10, 20)의 값을 원자적으로 증가시킬 수 있음

M1에서 이미지 원자 연산을 구현한 방식

  • 다른 GPU는 이미지 원자 연산 전용 명령을 제공해 드라이버 구현이 단순함
  • M1에는 이미지 원자 연산 전용 하드웨어 명령이 없음
    • 비이미지 원자 연산은 있음
    • 비원자 이미지 기능도 있음
  • 그래서 픽셀에 원자 연산을 직접 수행하지 않고, 픽셀의 메모리 주소를 계산한 뒤 해당 주소에 일반 원자 연산을 수행함
  • 이미지가 선형으로 메모리에 배치되어 있다면 주소 계산은 단순함
    • Y 좌표에 행당 바이트 수인 stride를 곱함
    • X 좌표에 픽셀당 바이트 수를 곱함
    • 두 값을 더해 첫 픽셀 기준 바이트 오프셋을 구함
    • 첫 픽셀 주소에 오프셋을 더해 최종 주소를 얻음
  • 실제 이미지는 보통 선형으로 배치되지 않음
    • 현대 그래픽 하드웨어는 캐시 효율을 높이기 위해 X·Y 좌표를 인터리브함
    • 메모리의 픽셀 배치는 행 단위가 아니라 나선형에 가까운 곡선을 따름

비트 인터리브 최적화와 숨은 명령 탐색

  • X·Y 좌표를 인터리브할 때 한 비트씩 마스킹하고 시프트하는 방식은 비효율적임
  • 잘 알려진 비트 조작 알고리듬은 비트 그룹을 섞어 문제를 병렬화함
    • 셰이더 코드에서 이 알고리듬을 구현하면 성능이 개선됨
  • 실제로는 각 좌표의 하위 7비트 이하만 인터리브됨
    • X·Y 좌표를 32비트 레지스터의 하위·상위 16비트에 넣어 32비트 명령으로 동시에 처리할 수 있음
    • 명령 수를 절반으로 줄일 수 있음
    • GPU의 shift-and-add 결합 명령도 활용함
  • 이 기법을 합치면 M1 GPU 어셈블리 10개 명령으로 인터리브를 수행할 수 있었음
  • 이후 전용 비트 인터리브 명령 가능성을 검토함
    • PowerVR에는 shfl 셔플 명령이 있음
    • M1 GPU는 PowerVR에서 가져온 요소가 있어 유사 명령이 있을 가능성을 검토함
    • 독점 컴파일러가 테스트 셰이더 컴파일 시 해당 명령을 사용하지 않아, 컴파일 결과 관찰만으로는 역공학이 어려웠음

추측과 검증으로 확인한 인터리브 명령

  • Dougall Johnson은 이미 알려진 명령 인코딩을 바탕으로 후보를 추정함
  • 비트 반전 명령에는 연산을 지정하는 2비트 필드가 있고 값은 01임
    • 설정된 비트 수 세기 명령은 10
    • 첫 번째 설정 비트 찾기 명령은 11
    • 알려진 복잡한 비트 조작 명령은 이 세 값을 사용함
  • 남은 값 00이 관측되지 않은 미지의 값임
    • 인터리브 명령이 존재한다면 비트 반전 명령과 비슷하되 연산 코드가 00일 가능성을 검토함
  • 세 개의 알려진 명령은 입력 소스가 하나뿐이지만, 인터리브 명령에는 두 소스가 필요함
    • M1 GPU 명령은 보통 소스 위치를 일관되게 인코딩함
    • 두 소스 산술 명령에서 두 번째 소스가 있을 위치에 빈 공간이 있어, 그 위치를 두 번째 소스로 추정함
  • 검증은 컴파일러를 수정해 곱셈 같은 2소스 정수 연산을 추정한 인터리브 인코딩으로 바꾸는 방식으로 진행됨
    • 컴퓨트 셰이더에서 해당 연산을 사용함
    • 테스트 셰이더는 가능한 입력마다 미지의 명령이 인터리브 결과를 반환하는지 확인함
    • 명령은 두 개의 16비트 소스를 받기 때문에 약 40억 개 입력이 있음
    • M1 GPU는 드라이버의 새 컴퓨트 지원으로 모든 입력을 1초 미만에 확인함
  • 최종적으로 10개 명령짜리 벡터화 어셈블리를 1개 인터리브 명령으로 대체함
    • 이 방식은 빠르고 적합성 테스트도 통과함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Apple이 OpenUSD 렌더링/애니메이션/CAD/3D 장면 포맷을 두고 nVidia, Adobe, Autodesk, Microsoft 등과 협력하니 OpenGL·Vulkan 지원이 나아질지 궁금함
    OpenUSD의 핵심이 “어디서나 일관되게 렌더링되는 하나의 파일 포맷”이라면, Apple이 더 많은 3D 소프트웨어 업체를 macOS로 끌어들이는 수단으로 쓸 가능성이 있음
    앞으로는 Apple이 영화·게임 제작 파이프라인에서 힘을 얻는 기존 OpenGL/Vulkan 표준을 따르거나, 반대로 Metal을 더 강하게 밀어붙여 세상을 Metal + macOS로 끌고 가려는 두 길이 있어 보임
    마음은 전자를 바라지만, 직감으로는 Apple이 후자를 전력으로 추진할 것 같고, Apple뿐 아니라 nVidia, Autodesk, Adobe, Microsoft도 자신이 통제하지 않는 표준을 좋아하지 않는 편임

    • “Apple은 자신이 약할 때 개방 표준을 좋아한다” 정도로 뉘앙스를 더하고 싶음
      iMac과 초기 OS X는 USB, JPEG, MPEG, mp3, PostScript, 내장 TCP/IP, .rtf 같은 표준을 크게 내세웠고 Jobs도 이를 강조했음
      이후 벼랑 끝에서 회복하면서 다시 “가치 추가”를 시작했고, iPhone도 처음엔 독점적이고 형편없던 Flash나 미숙한 “모바일 HTML” 대신 HTML 기기라고 강조했음
      지금도 시장 지배력이 약한 영역에서는 H.264, Matter/Thread 같은 자신이 통제하지 않는 표준을 지원함
    • Apple은 여러 개방 표준을 지원하지만, “통제하지 않는 표준에 의존하고 싶어 하지 않는다”가 더 정확해 보임
      하드웨어와 소프트웨어를 강하게 결합해 의도한 사용자 경험을 만들기 때문에, 그 경험이 타인에게 좌우되지 않도록 어느 정도 통제 가능한 표준을 구현하려는 입장은 이해됨
      USB-C처럼 아직 방향이 굳지 않은 산업 표준도 먼저 움직이면 방향에 영향을 줄 수 있어서 Apple이 도입하는 경우가 있음
    • OpenUSD는 렌더링할 데이터를 묶고 명세하는 방식이지, 앱이 렌더링 가속에 어떤 API를 쓰는지와는 별개임
      Adobe, Autodesk, Blender 등 대부분은 운영체제별로 다른 백엔드를 이미 지원하고, macOS에서는 Metal도 포함됨
    • Apple이 OpenGL로 돌아갈 일은 없다고 봄
      OpenGL은 너무 오래됐고 좋은 드라이버를 쓰기도 악몽에 가까우며, 성능 좋은 애플리케이션 코드를 작성하는 것조차 어렵기 때문에 아쉽지는 않음
      다만 Metal을 만들기보다 Vulkan을 밀었으면 좋았겠지만, Linux 밖에서는 Vulkan이 대체로 2등 시민에 가깝고 그래도 타깃으로 삼기엔 꽤 괜찮은 2등 시민임
      게임이나 Steam 지원 관점에서는 많은 게임이 API 처리를 엔진에 맡기고, 직접 API를 다룰 여력이 있는 팀이라면 아주 첨단 기능을 쓰지 않는 한 MoltenVK로도 괜찮을 가능성이 큼
      평생 크로스 플랫폼을 위해 OpenGL을 많이 써 왔지만 전역 상태, 쓰면 안 되는 함수들, 함정, 거대한 확장 헤더, 어려운 디버깅 때문에 정말 형편없는 API였고, Vulkan은 장황하지만 여러 면에서 오히려 더 쉬움
    • Metal/Vulkan/OpenGL 상황은 아쉽고 Apple의 동기는 잘 이해되지 않음
      하지만 지금 쓰는 Mac은 USB-C 포트만으로 여러 주변기기와 큰 모니터에 표준 프로토콜로 연결되어 있음
      전반적으로 Apple은 표준이 충분하면 개방 표준을 선호하는 듯하고, USB2로 Lightning이 하던 많은 일을 못 하던 시절엔 Lightning을 만들었지만 USB-C가 나오자 Mac과 iPad에는 바로 받아들였고 iPhone에서는 안타깝게도 늦장 부리는 중임

  • Asahi와 Alyssa는 역공학의 거인들이고, 이들의 작업은 믿기 어려울 정도임
    Apple이 이들을 채용하려 했거나 이미 시도했지만 거절당했을 가능성이 크다고 봄

    • Alyssa는 이미 Valve와 계약 중임
      Apple보다 Valve 쪽이 이 역량을 사업적으로 활용할 이유가 더 크다고 볼 수도 있음
    • Apple이 이미 시도했지만 NDA와 경쟁 금지 조항 때문에 거절당했거나, 아니면 HR이 이들의 프로필을 제대로 평가하지 못했을 것 같음
    • 고용은 별로 좋은 제안이 아님
      보통 직원은 자신이 만들어내는 이익에 비해 보수가 낮고, IT에서는 특히 그렇다
      재능 있는 사람은 법인을 세워 정당한 가격에 서비스를 파는 편이 낫지만, 일부 국가에서는 대기업들이 정부에 로비해 이런 길을 막아 버렸음

  • 원자적 연산 트릭이 아주 만족스러웠고, PowerVR 계보에서 스위즐 명령을 추론해낸 것도 특히 인상적임
    Apple 엔지니어들도 여기서 배우거나 최소한 그 영리함을 높이 평가할 것 같음
    예전에 Accolade에서 Sega Genesis 비디오 하드웨어를 역공학할 때, 엔지니어들이 공개된 Texas Instruments TMS9918 VDP 문서를 출발점으로 삼아 Genesis(Mega Drive)의 9918 파생 VDP를 추론했던 일이 떠오름

    • Apple은 자기 칩에 대한 내부 문서를 가지고 있으니, 작업 자체는 높이 평가하겠지만 블랙박스를 만들어 놓고 소프트웨어를 작성할 때 설계 방식을 잊어버리는 상황은 아님

  • 명확히 하자면, 이것은 첫 번째 적합성 인증 Linux 드라이버가 아니라 더 큰 의미가 있음
    Apple 자신도 OpenGL ES 3.1에 적합하지 않기 때문에, 이는 어떤 운영체제에서든 M 시리즈용으로는 문자 그대로 첫 번째 적합성 인증 OpenGL ES 3.1 드라이버임
    그래서 팀에 기부해 달라는 요청이 나오는 것임
    https://asahilinux.org/support/

    • 하는 일은 정말 좋아하지만, 예전에 Hacker News에서 asahilinux 링크를 눌렀더니 Hacker News 독자는 사이트에서 환영받지 못한다는 팝업이 떠서 내용을 읽을 수 없었음
    • 이걸 macOS에서 사용할 수 있는지 궁금함
    • 거기 GitHub 링크는 Asahi를 이끄는 marcan으로 연결되는데, 주로 드라이버 개발을 지원하고 싶음
      그런 선택지가 있다면 어디서 하면 되는지 알고 싶고, 없다면 나중에 그냥 그 링크를 쓰겠음

  • 지금은 더 이상 권장되지 않는 macOS OpenGL 앱을 디버깅해 보면 이 문제가 아주 분명해짐
    추상화 계층이 실제 OpenGL 상태를 예전 Apple OpenGL 디버거가 읽을 수 있는 방식으로 노출하지 않기 때문임
    OpenGL이 내부적으로 Metal 위에서 동작하지 않던 오래된 macOS가 설치된 구형 Mac이 없다면, 기본 디버거로는 macOS에서 OpenGL을 사실상 디버깅할 수 없음
    디버거나 앱이 그냥 크래시남

  • 이건 주로 게임에 도움이 되고 딥러닝에는 큰 도움이 안 되는 것으로 보임
    Mac M1의 가장 매력적인 점은 큰 메모리 용량이고, 여러 카드에 분산할 수 없어서 학습에는 별로일 수 있지만 Stable Diffusion, LLaMA 같은 대형 모델 추론 엔진으로는 좋음

    • Apple Silicon이 이론적으로 사용할 수 있거나 구현할 수 있는 최신 크로스 플랫폼 범용 GPU 표준은 SYCL과 Vulkan Compute 두 가지임
      SYCL은 Khronos Group의 벤더 중립 고수준 프로그래밍 프레임워크지만 애플리케이션 지원은 제한적이고, Intel의 지원으로 점차 나아지길 기대함
      Vulkan Compute는 컴퓨트 셰이더로 문제를 우회하지만 애플리케이션 지원 상황은 잘 모름
      SYCL은 OpenCL과 OpenCL의 SPIR-V 확장 위에 구현할 수 있지만, 강한 벤더 종속 때문에 이 경로는 Intel과 Mesa 외에는 대체로 버려졌고, 현재는 ROCm, HIP, CUDA 같은 각 GPU 벤더 API용 백엔드로 구현되는 경우가 많음
      Metal에 같은 방식을 적용하는 건 매우 어려울 것이며, Mesa에는 Intel과 AMDGPU용 OpenCL+SPIR-V 실험 지원이 있어 이론상 Apple Silicon으로 확장할 수 있지만 현재 Apple Silicon의 OpenCL은 전혀 지원되지 않고 로드맵에 있는 정도였음
    • 맞음
      딥러닝을 돌리려면 CUDA, ROCm, MPS 같은 백엔드가 필요함
      큰 CUDA 서버에서 PyTorch 모델을 학습하고 MacBook Air에서 추론을 돌리는 건 비교적 쉬웠음
    • 컴퓨트 셰이더 부분은 좋은 진전이지만, 여전히 이런 딥러닝 도구들이 기대하는 인터페이스를 제공하지는 못함
      다만 eiln이 Apple Neural Engine 드라이버를 작성해서 GPU 대신 전용 하드웨어를 사용할 수 있게 했고, 앞으로 linux-asahi에 병합될 예정임
    • TensorFlow Lite는 실제로 OpenGL ES를 지원함

  • Asahi Lina와 두 사람이 최소한의 자금으로 대기업을 이겼다는 표현은 멋지지만, 실제로는 이겼다기보다 Apple이 신경 쓰지 않았던 것에 가까움
    Apple은 애초에 그 경주에 참가하지 않았음

  • “최소한의 자금으로 두 사람이 대기업을 이겼다”는 완곡한 표현이 좋음
    이건 Apple에게 명백히 창피한 일이고, Apple은 표준이나 준수에 관심이 없으며 사람들이 자기들만의 폐쇄된 정원에 갇히길 원함
    iOS 개발자가 아니었다면 오래전에 Apple 생태계를 떠났을 것임
    하드웨어는 좋아하고, 80~90년대의 Apple처럼 창의성과 인간 중심을 내세우던 브랜드도 좋아했지만, 지금의 회사는 정치적으로 올바른 마케팅 영상 뒤에 탐욕으로 썩어 있는 모습임

    • 완전히 동의하지만, 의미 있는 대안을 찾는 건 사실상 불가능에 가까움
      마지막 업그레이드 때 대안을 찾아봤지만 Apple을 벗어나려면 끝없는 타협을 감수해야 했음
      iPhone 대신 순정 Android와 긴 지원을 기대하고 Pixel을 봤지만 배터리 문제 얘기가 끊이지 않았고, 소프트웨어 완성도와 앱 생태계, 안정성도 걸림돌임
      기본형 MacBook Air M1의 빌드 품질, 배터리, 안정성에 가까운 가성비 제품도 찾기 어려웠음
      iPad로 만화와 잡지도 읽는데 태블릿 시장은 수년째 대안이 뭔지 모르겠고, Apple Watch는 버릴 수 있을지 몰라도 그냥 잘 작동하고 서드파티 액세서리가 풍부함
      이제는 새 ROM을 매일 올려 보는 시절이 지났고, 안정성과 사용 편의성에서는 Apple을 이기기 어려운 듯해서 아쉬움
    • 이 업계의 가장 큰 비밀은 두 사람이 최대 규모 회사보다 더 많은 성과를 낼 수 있다는 점일지도 모름
      모두의 일자리가 안전한 유일한 이유는 그 두 사람이 누구인지 아무도 정확히 알아내지 못하기 때문임
    • Apple이 노트북을 잠그는 건 비교적 쉬웠을 텐데도 다른 운영체제와 그 개발이 가능하도록 문을 열어 두었다는 부분을 다들 놓치는 듯함
      Apple은 직접 실리콘을 만들고 전체 플랫폼을 구축했는데, 다른 운영체제를 실행할 수 있게 남겨 둔 것이 단순한 실수였다고 보긴 어려움
      제3자 개발을 위해 의식적으로 문을 열어 둔 것이 분명한데도 Apple을 비난하는 분위기는 실망스러움
    • 어떤 표준이 존재한다는 이유만으로 Apple이 반드시 구현해야 한다고는 보지 않음
      예를 들어 지속적인 Vulkan 구현을 지원하려면 상당한 자원과 출시 일정 부담이 따르니 사업적 이유가 필요함
      “창피를 피하기 위해서”는 충분하지 않을 가능성이 큼
      커뮤니티 선의라는 논리는 가능하겠지만, Apple을 “정치적으로 올바른 마케팅 영상 뒤의 탐욕으로 썩은 회사”라고 부르는 사람들의 호감을 좇지는 않을 것 같음
    • OpenGL은 낡고 끔찍한 프로그래밍 모델에 기반한 죽어가는 명세이고, Khronos의 적합성 테스트도 이상하고 과한 면이 있음
      적합성 테스트는 오픈소스가 아니며, GitHub에 있는 별도 “conformance suite”는 Google의 dEQP 기반이지 Khronos 내부 테스트 묶음이 아님
      구현에 꽤 큰 버그와 빈틈이 있어도 “표준 호환 인증”을 받을 수 있음
      Apple은 OpenGL 3.1 지원만 약속했고, M1용 OpenGL 드라이버도 기존 앱이 계속 동작하도록 Metal 위의 에뮬레이션 계층으로 다시 작성했지만 더 새 버전의 OpenGL을 구현하지는 않을 것이며, 그럴 필요도 없음
      Apple에 대한 비판은 많고 Metal API와 도구를 더 좋게 만들 여지도 크지만, OpenGL에 신경 쓰지 않는 건 여기서는 충분히 합리적인 결정임

  • 원문에 ‘Apple’이라는 단어가 한 번도 나오지 않고 ‘제조사’와 ‘대기업’으로만 표현한 게 흥미로움
    의도적이라면 법적 이유인지 궁금함

    • 아마 이건 Apple에 관한 글이 아니기 때문일 것임
      관심사는 Apple이 아니라 M1/M2 아키텍처에서 Linux를 제대로 돌리는 것이고, 대상이 Microsoft, Amazon, Google이었어도 같은 식으로 다뤘을 것임

  • 이 드라이버 개발 과정을 보여주는 실시간 방송을 보는 게 재미있었고, 정말 놀라운 작업임

    • 모르는 사람을 위해 남기면 https://www.youtube.com/c/AsahiLina 에서 볼 수 있음
      지금까지 본 것 중 가장 놀라운 저수준 프로그래밍 작업 중 하나임
답변달기