Android와 RISC-V: 준비를 위해 알아야 할 것들

 (opensource.googleblog.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Google은 Android를 새 CPU 아키텍처로 확장하기 위해 RISC-V 지원을 AOSP에 추가하고, 실험 가능한 단계에서 생태계 협업으로 넓히고 있음
  • 초기 지원은 rva22 프로파일과 vector·vector crypto 확장을 기준으로 삼아, Android가 기대하는 성능 구현에 필요한 기능 집합을 맞추는 데 초점을 둠
  • 지금도 Cuttlefish로 RISC-V용 Android를 빌드·테스트·실행할 수 있지만, ART 백엔드와 컴파일러 최적화는 아직 완성 단계가 아님
  • 2023년 말에는 NDK ABI 확정과 공개 CI canary 빌드가 예상되며, 2024년에는 여러 폼팩터 테스트용 공개 에뮬레이터가 계획돼 있음
  • Android 포팅만으로는 부족하기 때문에 Google은 RISE Project, RISC-V International, 툴체인·지원 라이브러리 커뮤니티와 함께 앱 개발 환경까지 준비하고 있음

Android에 들어오는 RISC-V 지원

  • Android는 여러 기기 유형과 CPU 아키텍처를 지원하는 오픈소스 운영체제이며, 새 플랫폼 대상으로 RISC-V를 추가하고 있음
  • RISC-V는 무료·오픈 명령어 집합 아키텍처(ISA)로, 오픈소스 소프트웨어의 산업 전반 협업 방식을 하드웨어 생태계로 가져오려는 접근임
  • UC Berkeley에서 10년 전 만들어진 뒤 임베디드와 마이크로컨트롤러 영역에서 빠르게 채택됐고, 최근에는 가속기·서버·모바일 컴퓨팅으로 확장됨

패치 수용에서 지원 성숙 단계로

  • Google은 2022년 11월 RISC-V Summit에서 Android용 RISC-V 패치를 받기 시작한다고 발표함
  • 현재는 단순 패치 수용을 넘어 Android에서 RISC-V 지원을 성숙시키는 단계로 이동함
  • RISC-V는 모듈형 ISA라 선택 확장이 많아, Android에서 기대하는 고성능을 내려면 초기 필수 기능 집합을 정해야 함
    • 기준에는 rva22 프로파일이 포함됨
    • vector와 vector crypto 확장도 포함됨

로컬에서 빌드·실행 가능한 AOSP 환경

  • RISC-V용 Android 지원은 다른 AOSP 플랫폼 대상처럼 Cuttlefish Virtual Device로 로컬 머신에서 빌드·테스트·실행할 수 있음
  • 관련 코드는 google/android-riscv64에서 확인할 수 있음
  • 실행 예시는 다음과 같음
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • 실행 중인 기기에는 vncviewer로 연결해 상호작용할 수 있음

아직 남은 최적화 과제

  • 현재 패치들은 기본적인 Android Open Source Project 경험을 빌드하고 실행할 수 있게 하지만, 완전히 최적화된 상태는 아님
  • Android Runtime의 ART 최적화 백엔드 작업은 아직 진행 중임
  • AOSP, 외부 프로젝트, 컴파일러도 최신 비준 확장을 활용하면서 완전히 최적화되고 축소된 코드를 생성하는 수준에는 이르지 못함
  • 현 단계의 목적은 완성된 제품 환경보다 실험과 협업을 가능하게 하는 데 가까움

개발자 테스트와 에뮬레이터 로드맵

  • 2023년 말에는 NDK ABI가 확정될 것으로 예상됨
  • Android 공개 CI에 canary 빌드도 곧 제공될 예정임
  • 호스트 머신에서 riscv64 Android 애플리케이션을 더 쉽게 테스트할 수 있도록 x86-64와 ARM64에서 RISC-V 실행을 지원할 계획임
  • 2024년에는 다양한 기기 폼팩터의 애플리케이션을 테스트할 수 있는 전체 기능 세트의 공개 에뮬레이터가 계획돼 있음
  • Qualcomm과의 협업 발표에 따르면 첫 폼팩터는 웨어러블이 될 것으로 예상됨

생태계 협업과 RISE Project

  • Android 운영체제 자체를 포팅하는 것만으로는 충분하지 않아, 주변 소프트웨어 생태계 준비가 함께 필요함
  • Google은 커뮤니티 및 RISE와 협업 중임
  • RISE Project는 고수준 운영체제를 실행하는 고성능·전력 효율 RISC-V 프로세서 코어에서 소프트웨어 가용성을 앞당기기 위해 만들어짐
  • 적용 범위는 Android뿐 아니라 Linux와 기타 운영체제를 포함함
  • 대상 애플리케이션 도메인에는 고성능 컴퓨팅도 포함됨
  • 참여사는 Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head, Ventana임

표준화와 기여 경로

  • Google은 RISC-V International에서 기존 Premium 멤버십과 이사회 참여를 넘어 투자를 계속 확대하고 있음
  • 여러 기여자가 수평 위원회, 워킹 그룹, 기술 위원회에서 핵심 역할을 맡아 사양 설계와 비준에 참여함
  • Android의 RISC-V 지원은 LLVM toolchain부터 기본 지원 라이브러리까지 폭넓은 기여에 의존함
  • 기여와 테스트를 위한 주요 리소스는 다음과 같음
    • google/android-riscv64: Android의 RISC-V 지원 빌드·테스트 방법, 알려진 이슈, AOSP와 툴체인·지원 라이브러리 기여 기회 제공
    • RISC-V Android SIG: 진행 상황을 확인하고 제안·피드백을 제공할 수 있는 메일링 리스트
  • Google은 Java와 Kotlin 개발자가 새 플랫폼을 대상으로 삼는 것처럼, 네이티브 코드를 작성하는 Android 개발자도 새 플랫폼을 쉽게 대상으로 삼을 수 있는 방법을 모색 중임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 개발자에게 준비하라고 기대하는 건가? 접근이 잘못됐음. Apple이 M1 전환 때 했던 것처럼 기본은 작업이 0에 가깝고, 그다음 선택적 최적화가 가능해야 함
    Google이 Android 앱을 x86에서 테스트하라고 했다가, 다시 MIPS에서도 테스트하라고 했던 때를 떠올리면 됨. 결국 아무 일도 안 일어났고, 개발자들은 시간을 낭비하지 않을 것임

    • 작업이 0이라고? 기억은 가끔 빨리 흐려지는 듯함
      Apple은 개발자들이 ARM 하드웨어를 만져보고 앱을 이식할 수 있게 DTK 시스템을 500달러에 대여했음. 작업이 0과는 거리가 멀었고, 하드웨어도 반납해야 했으며, 처음에는 양산 제품 구매에 쓸 500달러 크레딧조차 없었음. 예상 가능한 반발 뒤에야 고쳐졌음
      Google은 대신 소프트웨어 에뮬레이터를 제공하니 훨씬 다루기 쉽고 복잡한 기기 물류도 필요 없음. 실제로 준비 작업이 필요한 쪽은 NDK 앱을 만드는 사람이나 RISC-V 하드웨어 지원을 하는 사람들임
      Java/Kotlin 앱은 이식이 필요 없으니, 내 기준에선 작업 0에 가까움
    • Android 앱과 라이브러리의 x86 빌드는 에뮬레이터에서 가장 흔한 대상이라 매우 흔함
      MIPS는 Google이 강하게 밀었던 것 같지 않고, 그냥 존재만 했던 정도임
      게다가 이 글은 앱 개발자보다 기기 제조사를 더 겨냥해서 AOSP 빌드와 대기 중인 패치를 다루는 것임. 앱 개발자에게 뭔가 하라고 요구하는 글은 아니고, 오히려 마지막에 “Java와 Kotlin 개발자들이 새 플랫폼을 대상으로 삼는 것만큼 네이티브 Android 개발자도 쉽게 만들 방법을 살펴보겠다”고 되어 있음
    • Android에서 MIPS는 Imagination Technologies가 2013년에 인수한 뒤 사실상 죽었음. 새 SoC나 새 휴대폰이 없으면 Google이 할 수 있는 것도 없음
      x86은 Chromebook 덕분에 여전히 널리 쓰임. NDK를 쓰지 않는다면 새 대상 때문에 개발자 쪽에서 할 일은 없음
    • 일반적인 의미로는 개발자에게 준비하라고 기대하는 것 같지 않음. 제목도 “준비하려면 알아야 할 것”이라서, 준비하고 싶다면 정보와 조언을 제공하겠다는 뜻에 가까움. 받아들이든 말든 선택임
      여기서 “you”는 제목의 표현을 따른 것이지 특정 개인을 가리키는 건 아님
    • 그 아키텍처로 의미 있는 기기가 출시되지 않았기 때문임

  • Qualcomm이 그렇게 반대하는 C 확장이 필요해지는 건가?
    관련 하위 스레드는 https://news.ycombinator.com/item?id=37996820 참고
    Qualcomm의 최신 자료는 https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...인데, 자신들이 제안한 “RISC-V를 aarch64와 조금 비슷하게 만드는” Zics 확장과 32비트 긴 점프가 RV64GC보다 더 나은 코드 밀도를 내며, 그들이 계속 문제 삼아 온 C 확장의 단점도 없다고 주장함

    • 왜 내려찍히는지 모르겠음. 이 질문은 실제로 아직 진행 중인 쟁점임
      Qualcomm이 C 확장 없이 RISC-V Snapdragon을 만들겠다고 결정하면, 그 확장을 쓰는 Android NDK 앱이 어떻게 동작할지 보기 어려움. 어떤 트랩 후 에뮬레이션 같은 방식이 아니라면 말도 안 되게 느릴 것임
    • Qualcomm에게도 어느 정도 일리는 있어 보이지만, ARM 기술 재사용을 더 많이 하고 싶다는 동기도 있어 보임
      Google이 RV64GC나 RV64G_Zics를 강제하면 여기서 결판이 날 수도 있음
      다만 C 명령어를 빼거나 바꾸는 건 실제 배포 후에는 선택지가 아니고, 지금은 대부분 에뮬레이터 테스트 단계라 크게 신경 쓰지 않을 수도 있음
    • ARM의 Thumb 명령어 집합과 꽤 비슷해 보임
      진짜 질문은 왜냐는 것임
      참고: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • 곁가지지만 새 AOSP 에뮬레이터를 알게 됐을 때, 왠지 AOSP에서 Goldfish 대신 Cuttlefish 에뮬레이터를 쓰려면 acloud를 실행해야 한다고 생각했음. 그런데 acloud는 Ubuntu가 아니면 실행을 거부했음
    uname 함수 출력을 바꾸는 LD_PRELOAD 해킹도 해봤지만, 그다음에는 dpkg를 실행하려고 했음. 나는 NixOS를 씀
    예전 에뮬레이터는 제대로 동작시키기 정말 번거롭고, 새 에뮬레이터는 장점이 많음
    그런데 launch_cvd를 직접 실행하면 된다는 걸 이상하게도 전혀 몰랐음

  • “Android for RISC-V”가 완전히 재앙이었던 “Android for x86”보다 성공하길 바람. 아직도 Lenovo x86 Android 태블릿을 갖고 있음
    그래도 이 글을 읽어보면 신뢰가 많이 생기지는 않음. 기대는 크지만 예상은 낮음

    • RISC-V 구현체를 주 프로세서로 쓰는 값싼 소비자 기기가 시장에 넘쳐나는 건 피할 수 없어 보임
      오히려 ARM 지원이 정체되는 쪽을 더 걱정해야 할 듯함
    • Chromebook은 지금 대부분 x86이고 Android 앱을 실행함. Android 에뮬레이터도 마찬가지임
      모두가 ARM MacBook을 가진 부유한 미국인은 아님

  • 몇 년 전에는 휴대폰이나 태블릿이 아닌, 그래픽 터치스크린이 필요한 임베디드 분야에서 Android가 꽤 널리 쓰였지만, 지금은 거의 휴대폰용이고 어느 정도 태블릿용에 가까워졌음
    이유는 휴대폰·태블릿 제조사와 달리 작은 업체들은 매우 복잡한 Android의 새 변화들을 따라잡을 수 없어서 점점 떠났기 때문임

    • 대신 뭘 쓰고 있는지 궁금함
    • DJI는 아직 컨트롤러에 Android를 쓰는 것 같음

  • 상황을 잘 모르겠는데, RISC-V를 구현한 주요 휴대폰이 있나? 그리고 이건 전체 스택에 걸친 변경이 필요한가? 운영체제만 바꾸는 수준은 아닐 것 같은데

    • 아직은 없지만 출시가 다가오고 있음
      “스택”과 “운영체제”의 경계를 어디에 두는지 잘 모르겠음. 조금 더 풀어서 말해줄 수 있나?
    • 없음. 다만 Qualcomm은 RISC-V 스마트워치 프로세서를 준비 중임. 아무것도 아닌 건 아님
      LiCheePi 4A용 AOSP 포트는 아직 안 써봤음. 그냥 되는지 보려고 한번 돌려봐야 할 듯함
      PolyMC를 동작시키는 데 필요한 전체 도구체인을 부트스트랩하는 것보다, Play Store에서 Minecraft를 내려받아 보는 편이 더 쉬움

  • RISC-V에 설치할 것 중 Google Android는 가장 마지막 선택임

    • RISC-V가 모바일 CPU에서 자주 쓰이게 되면 생태계에 긍정적 영향을 줄지, 아니면 대기업들이 RISC-V를 더 기업용 사용 사례로 몰고 가면서 취미 개발자에게 덜 친화적으로 만들지 궁금함
    • 그래도 Android가 미리 설치된 RISC-V 기기를 산 뒤 지우게 될 수도 있음

  • 피할 수 있다면 Android를 실행하는 건 어리석은 선택이고, 아키텍처를 바꾸며 순정 Linux로 갈 기회가 있다면 더더욱 그렇음
    문제는 은행 업무임. 적어도 스웨덴에서는 아직 모바일 BankID에 의존하고 있음. 예를 들어 20달러 넘는 온라인 구매에도 필요하고, iOS와 Android에서만 동작함

    • Android가 아닌 운영체제를 휴대폰에서 돌리면서도 전력 효율, 멀티터치와 GPU 가속이 있는 Android 앱 지원 등을 확보할 현실적인 방법이 있나?
      예를 들면 Android를 KVM에서 효율적으로 돌리는 기성 솔루션이나, Android 커널 기능과 사용자 공간 RPC 서버를 제공하는 방식 같은 것 말임
      그게 없다면 모바일 앱 접근을 위해 Android를 돌릴 수밖에 없고, 이건 필수에 가까움
    • 덴마크에는 은행과 정부 사이트용 MitID가 있음. 구매 인증에도 가끔 씀
      스마트폰이 없거나 쓰고 싶지 않다면 인증에 쓰는 작은 기기를 받을 수 있음. 스웨덴이 은행 계좌가 있는 모든 사람에게 스마트폰 소유까지 강제한다는 건 이상해 보임. 특히 스마트폰이 없는 노인이 많을 텐데 말임
답변달기