Android e RISC-V: o que você precisa saber para se preparar

 (opensource.googleblog.com)
2 pontos por GN⁺ 2023-11-02 | 1 comentários | Compartilhar no WhatsApp
  • O Google está adicionando suporte a RISC-V ao AOSP para expandir o Android para uma nova arquitetura de CPU, saindo de uma fase experimental para uma colaboração mais ampla no ecossistema
  • O suporte inicial toma como base o perfil rva22 e as extensões vector e vector crypto, com foco em definir o conjunto de recursos necessário para atingir o desempenho esperado pelo Android
  • Já é possível compilar, testar e executar o Android para RISC-V com o Cuttlefish, mas o backend do ART e as otimizações do compilador ainda não estão concluídos
  • No fim de 2023, são esperados a definição da ABI do NDK e builds canary públicas de CI; em 2024, há planos para um emulador público voltado a testes em vários formatos de dispositivo
  • Como portar apenas o Android não basta, o Google também está preparando o ambiente de desenvolvimento de apps em conjunto com o RISE Project, a RISC-V International e comunidades de toolchain e bibliotecas de suporte

Suporte a RISC-V chegando ao Android

  • O Android é um sistema operacional de código aberto que oferece suporte a vários tipos de dispositivos e arquiteturas de CPU, e está adicionando o RISC-V como novo alvo de plataforma
  • O RISC-V é uma arquitetura de conjunto de instruções (ISA) livre e aberta, uma abordagem que busca levar ao ecossistema de hardware a forma de colaboração industrial já vista no software de código aberto
  • Criado na UC Berkeley há 10 anos, foi rapidamente adotado nas áreas de embarcados e microcontroladores, e mais recentemente expandiu para aceleradores, servidores e computação móvel

Da aceitação de patches à maturidade do suporte

  • O Google anunciou na RISC-V Summit, em novembro de 2022, que começaria a receber patches de RISC-V para o Android
  • Agora, passou da simples aceitação de patches para uma fase de amadurecimento do suporte a RISC-V no Android
  • Como o RISC-V é uma ISA modular com muitas extensões opcionais, é preciso definir um conjunto inicial obrigatório de recursos para entregar o alto desempenho esperado no Android
    • Os critérios incluem o perfil rva22
    • Também incluem as extensões vector e vector crypto

Ambiente AOSP que já pode ser compilado e executado localmente

  • O suporte do Android para RISC-V pode ser compilado, testado e executado na máquina local com o Cuttlefish Virtual Device, como acontece com outros alvos de plataforma do AOSP
  • O código relacionado pode ser visto em google/android-riscv64
  • Um exemplo de execução é o seguinte
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • Também é possível interagir com o dispositivo em execução conectando-se via vncviewer

Desafios de otimização que ainda restam

  • Os patches atuais já permitem compilar e executar a experiência básica do Android Open Source Project, mas ainda não estão totalmente otimizados
  • O trabalho no backend de otimização do ART do Android Runtime ainda está em andamento
  • O AOSP, projetos externos e compiladores também ainda não chegaram ao ponto de gerar código totalmente otimizado e enxuto, aproveitando as extensões ratificadas mais recentes
  • Nesta fase, o objetivo está mais próximo de viabilizar experimentação e colaboração do que de oferecer um ambiente de produto finalizado

Roteiro de testes para desenvolvedores e emulador

  • Espera-se que a ABI do NDK seja definida no fim de 2023
  • Builds canary também devem ser disponibilizados em breve no CI público do Android
  • Há planos para oferecer suporte à execução de RISC-V em x86-64 e ARM64, facilitando o teste de aplicativos Android riscv64 na máquina host
  • Em 2024, está planejado um emulador público com conjunto completo de recursos para testar aplicativos em vários formatos de dispositivo
  • Segundo o anúncio da colaboração com a Qualcomm, o primeiro formato de dispositivo deve ser o de wearables

Colaboração no ecossistema e RISE Project

  • Não basta portar apenas o sistema operacional Android; também é necessário preparar o ecossistema de software ao redor
  • O Google está colaborando com a comunidade e com o RISE
  • O RISE Project foi criado para acelerar a disponibilidade de software em núcleos de processador RISC-V de alto desempenho e eficiência energética, capazes de executar sistemas operacionais de alto nível
  • Seu escopo inclui não só o Android, mas também Linux e outros sistemas operacionais
  • Os domínios de aplicação-alvo também incluem computação de alto desempenho
  • Participam Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head e Ventana

Padronização e caminhos de contribuição

  • O Google continua ampliando seus investimentos na RISC-V International, indo além da associação Premium existente e da participação no conselho
  • Vários contribuidores desempenham papéis centrais em comitês horizontais, grupos de trabalho e comitês técnicos, participando do desenho e da ratificação de especificações
  • O suporte do Android a RISC-V depende de contribuições amplas, do LLVM toolchain até bibliotecas básicas de suporte
  • Os principais recursos para contribuição e testes são os seguintes
    • google/android-riscv64: oferece formas de compilar e testar o suporte a RISC-V no Android, problemas conhecidos e oportunidades de contribuição para o AOSP, toolchain e bibliotecas de suporte
    • RISC-V Android SIG: lista de discussão para acompanhar o andamento e enviar propostas e feedback
  • O Google está buscando formas de permitir que desenvolvedores Android que escrevem código nativo também possam segmentar facilmente a nova plataforma, assim como desenvolvedores Java e Kotlin fazem ao mirar novas plataformas

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-02
Opiniões do Hacker News

  • Esperam que os desenvolvedores se preparem? A abordagem está errada. Como a Apple fez na transição para o M1, o padrão deveria ser trabalho próximo de zero e, depois, otimizações opcionais
    É só lembrar de quando o Google pediu para testar apps Android em x86 e depois também em MIPS. No fim, nada aconteceu, e os desenvolvedores não vão desperdiçar tempo

    • Trabalho zero? A memória às vezes parece desaparecer rápido
      A Apple alugou sistemas DTK por US$ 500 para que desenvolvedores pudessem mexer em hardware ARM e portar seus apps. Ficou longe de ser trabalho zero; o hardware tinha que ser devolvido e, no início, nem havia um crédito de US$ 500 para usar na compra de produtos de produção. Só corrigiram isso depois da reação previsível
      O Google, por outro lado, oferece um emulador de software, o que é muito mais fácil de lidar e não exige logística complexa de dispositivos. Quem realmente precisa fazer trabalho de preparação são as pessoas que criam apps com NDK ou dão suporte a hardware RISC-V
      Apps Java/Kotlin não precisam de portabilidade, então, para mim, isso é perto de trabalho zero
    • Builds x86 de apps e bibliotecas Android são muito comuns, porque são o alvo mais comum no emulador
      MIPS não me parece algo que o Google tenha empurrado com força; era mais algo que simplesmente existia
      Além disso, este texto é mais voltado a fabricantes de dispositivos do que a desenvolvedores de apps, tratando de builds do AOSP e patches pendentes. Não é um texto pedindo que desenvolvedores de apps façam algo; pelo contrário, no fim diz que “vamos examinar formas de tornar isso tão fácil para desenvolvedores Android nativos quanto é para desenvolvedores Java e Kotlin mirarem a nova plataforma”
    • No Android, MIPS praticamente morreu depois que a Imagination Technologies foi adquirida em 2013. Sem novos SoCs ou novos celulares, não há muito que o Google possa fazer
      x86 ainda é amplamente usado graças aos Chromebooks. Se você não usa o NDK, não há nada a fazer do lado do desenvolvedor por causa de um novo alvo
    • No sentido geral, não parece que estejam esperando que desenvolvedores se preparem. O título também é “o que você precisa saber para se preparar”, então soa mais como oferecer informações e conselhos caso você queira se preparar. Aceita quem quiser
      Aqui, “you” segue a formulação do título, não aponta para uma pessoa específica
    • Porque nenhum dispositivo relevante com essa arquitetura foi lançado

  • Será que a extensão C, à qual a Qualcomm se opõe tanto, vai acabar sendo necessária?
    Veja a subthread relacionada em https://news.ycombinator.com/item?id=37996820
    O material mais recente da Qualcomm é https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS..., no qual ela afirma que a extensão Zics proposta por eles, que “torna o RISC-V um pouco mais parecido com a aarch64”, e saltos longos de 32 bits oferecem densidade de código melhor que RV64GC, sem as desvantagens da extensão C que eles vêm criticando

    • Não sei por que estão votando contra. Essa pergunta é, de fato, uma questão ainda em andamento
      Se a Qualcomm decidir criar um RISC-V Snapdragon sem a extensão C, é difícil ver como apps Android NDK que usam essa extensão funcionariam. A menos que seja algo como trap seguido de emulação, seria absurdamente lento
    • A Qualcomm parece ter alguma razão, mas também parece motivada a querer mais reutilização de tecnologia ARM
      Se o Google tornar RV64GC ou RV64G_Zics obrigatório, isso pode resolver a disputa
      Ainda assim, remover ou trocar instruções C não será uma opção depois de uma implantação real; por enquanto, como a maior parte está na fase de testes em emuladores, talvez não se importem muito
    • Parece bastante com o conjunto de instruções Thumb da ARM
      A verdadeira pergunta é: por quê?
      Referência: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • Como observação lateral, quando fiquei sabendo do novo emulador do AOSP, por algum motivo achei que, para usar o emulador Cuttlefish no AOSP em vez do Goldfish, eu precisava executar acloud. Só que o acloud se recusava a rodar se não fosse no Ubuntu
    Até tentei um hack com LD_PRELOAD para alterar a saída da função uname, mas depois ele tentou executar dpkg. Eu uso NixOS
    O emulador antigo é realmente trabalhoso para fazer funcionar direito, e o novo emulador tem muitas vantagens
    Mas, estranhamente, eu não fazia ideia de que bastava executar launch_cvd diretamente

  • Espero que “Android for RISC-V” tenha mais sucesso do que “Android for x86”, que foi um desastre completo. Ainda tenho um tablet Lenovo x86 com Android
    Mesmo assim, lendo este texto, não fico muito confiante. Minhas esperanças são grandes, mas minhas expectativas são baixas

    • Parece inevitável que o mercado seja inundado por dispositivos de consumo baratos usando implementações RISC-V como processador principal
      Acho que deveríamos nos preocupar mais com a possibilidade de o suporte a ARM estagnar
    • Hoje, a maioria dos Chromebooks é x86 e roda apps Android. O mesmo vale para o emulador Android
      Nem todo mundo é um americano rico com um MacBook ARM

  • Alguns anos atrás, o Android era bastante usado em áreas embarcadas que precisavam de uma tela sensível ao toque gráfica, e não em celulares ou tablets; hoje ele é praticamente para celulares e, em certa medida, tablets
    O motivo é que, ao contrário dos fabricantes de celulares e tablets, empresas pequenas não conseguiram acompanhar as novas mudanças muito complexas do Android e foram abandonando a plataforma aos poucos

    • Fico curioso para saber o que estão usando no lugar
    • A DJI ainda parece usar Android nos controladores

  • Não conheço bem a situação, mas existem celulares importantes que implementem RISC-V? E isso exige mudanças em toda a stack? Não parece ser algo apenas no nível de trocar o sistema operacional

    • Ainda não, mas o lançamento está se aproximando
      Não sei bem onde você traça a fronteira entre “stack” e “sistema operacional”. Pode explicar um pouco melhor?
    • Não. Mas a Qualcomm está preparando um processador RISC-V para smartwatches. Não é pouca coisa
      Ainda não testei o port do AOSP para o LiCheePi 4A. Acho que preciso rodar uma vez só para ver se simplesmente funciona
      É mais fácil baixar Minecraft pela Play Store do que fazer bootstrap de toda a toolchain necessária para rodar o PolyMC

  • Entre as coisas para instalar em RISC-V, o Google Android seria minha última opção

    • Fico curioso se, caso RISC-V passe a ser usado com frequência em CPUs móveis, isso terá um impacto positivo no ecossistema, ou se as grandes empresas vão empurrar o RISC-V mais para casos de uso corporativos e torná-lo menos amigável para desenvolvedores hobistas
    • Ainda assim, você pode acabar comprando um dispositivo RISC-V com Android pré-instalado e depois apagá-lo

  • Se der para evitar, rodar Android é uma escolha tola; ainda mais se, ao mudar de arquitetura, houver a oportunidade de ir para um Linux puro
    O problema é o banco. Pelo menos na Suécia, ainda dependemos do BankID móvel. Por exemplo, ele é necessário até para compras online acima de 20 dólares, e só funciona em iOS e Android

    • Existe alguma forma realista de rodar no celular um sistema operacional que não seja Android e ainda assim ter eficiência energética, suporte a apps Android com multitouch e aceleração de GPU etc.?
      Por exemplo, alguma solução pronta que rode Android de forma eficiente no KVM, ou algo que forneça recursos do kernel Android e um servidor RPC em user space
      Sem isso, não resta alternativa a não ser rodar Android para ter acesso a apps móveis, e isso é quase indispensável
    • Na Dinamarca há o MitID para bancos e sites do governo. Às vezes também é usado para autenticar compras
      Se você não tem smartphone ou não quer usar um, pode receber um pequeno dispositivo para autenticação. Parece estranho a Suécia obrigar todo mundo que tem conta bancária a também ter um smartphone. Especialmente considerando que deve haver muitos idosos sem smartphone