AndroidとRISC-V: 準備のために知っておくべきこと

 (opensource.googleblog.com)
2 ポイント 投稿者 GN⁺ 2023-11-02 | 1件のコメント | WhatsAppで共有
  • 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アーキテクチャをサポートするオープンソースOSであり、新たなプラットフォーム対象としてRISC-Vを追加している
  • RISC-Vは無償・オープンな命令セットアーキテクチャ（ISA）であり、オープンソースソフトウェアの業界横断的な協業のあり方をハードウェアエコシステムへ持ち込もうとするアプローチである
  • 10年前にUC Berkeleyで生まれた後、組み込みおよびマイクロコントローラ分野で急速に採用され、最近ではアクセラレータ・サーバー・モバイルコンピューティングへと拡大している

パッチ受け入れからサポート成熟段階へ

  • 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 OS自体をポーティングするだけでは十分ではなく、周辺ソフトウェアエコシステムの整備も同時に必要である
  • GoogleはコミュニティおよびRISEと協業している
  • RISE Projectは、高性能かつ電力効率の高いRISC-Vプロセッサコア上で高水準OSを動かすためのソフトウェア可用性を前倒しする目的で作られた
  • 適用範囲はAndroidだけでなく、Linuxやその他のOSも含む
  • 対象アプリケーション分野には高性能コンピューティングも含まれる
  • 参加企業は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開発者も新しいプラットフォームを容易に対象にできる方法を模索している

関連記事

1件のコメント

 
GN⁺ 2023-11-02
Hacker Newsのコメント

  • 開発者に準備しろと期待しているのか？ それはアプローチが間違っている。AppleがM1移行のときにやったように、基本的には作業がほぼゼロで、そのうえで任意の最適化ができるべきだ
    GoogleがAndroidアプリをx86でテストしろと言ったり、その後またMIPSでもテストしろと言ったりしていた時期を思い出せばいい。結局何も起きず、開発者は時間を無駄にしないだろう

    • 作業がゼロ？ 記憶というのは時々ずいぶん早く薄れるものだ
      Appleは開発者がARMハードウェアに触れてアプリを移植できるよう、DTKシステムを500ドルで貸し出していた。作業はゼロどころではなかったし、ハードウェアも返却する必要があり、当初は量産製品の購入に使える500ドル分のクレジットすらなかった。予想どおりの反発を受けてからようやく修正された
      その代わりGoogleはソフトウェアエミュレータを提供しているので、はるかに扱いやすく、複雑なデバイス物流も不要だ。実際に準備作業が必要なのは、NDKアプリを作る人やRISC-Vハードウェアをサポートする人たちだ
      Java/Kotlinアプリは移植不要なので、私の基準では作業はゼロに近い
    • 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を実装した主要なスマートフォンはあるのか？ そしてこれはスタック全体にわたる変更が必要なのか？ OSだけ差し替える程度ではなさそうだが

    • まだないが、発売は近づいている。
      「スタック」と「OS」の境界をどこに置いているのかよく分からない。もう少し詳しく説明してもらえる？
    • ない。ただし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以外のOSをスマートフォンで動かしつつ、電力効率や、マルチタッチとGPUアクセラレーション付きのAndroidアプリ対応などを確保する現実的な方法はあるのか？
      たとえばAndroidをKVM上で効率よく動かす既製ソリューションや、Androidカーネル機能とユーザー空間RPCサーバーを提供する方式のようなものだ。
      それがないなら、モバイルアプリにアクセスするためにAndroidを動かすしかなく、これはほぼ必須だ。
    • デンマークには銀行や政府サイト向けのMitIDがある。購入認証にも時々使う。
      スマートフォンを持っていない、あるいは使いたくないなら、認証用の小さなデバイスを受け取れる。銀行口座を持つすべての人にスマートフォンの所有まで事実上強制しているように見えるスウェーデンは奇妙だ。特にスマートフォンを持たない高齢者が多いだろうに。