Android ve RISC-V: Hazırlanmak için bilmeniz gerekenler

 (opensource.googleblog.com)
2 puan yazan GN⁺ 2023-11-02 | 1 yorum | WhatsApp'ta paylaş
  • Google, Android’i yeni bir CPU mimarisine genişletmek için AOSP’ye RISC-V desteği ekliyor ve bunu deneysel aşamadan ekosistem iş birliğine doğru genişletiyor
  • İlk destek, rva22 profili ile vector ve vector crypto uzantılarını temel alarak Android’in beklediği performans uygulaması için gereken özellik kümesini eşleştirmeye odaklanıyor
  • Şu anda bile Cuttlefish ile RISC-V için Android’i derleyebilir, test edebilir ve çalıştırabilirsiniz; ancak ART backend’i ve derleyici optimizasyonları henüz tamamlanmış değil
  • 2023 sonlarında NDK ABI’nin kesinleşmesi ve herkese açık CI canary derlemelerinin gelmesi bekleniyor; 2024’te ise çeşitli form faktörlerinde test için herkese açık emülatörler planlanıyor
  • Android’i port etmek tek başına yeterli olmadığından Google, RISE Project, RISC-V International ve araç zinciri ile destek kütüphaneleri topluluklarıyla birlikte uygulama geliştirme ortamını da hazırlıyor

Android’e gelen RISC-V desteği

  • Android, çeşitli cihaz türlerini ve CPU mimarilerini destekleyen açık kaynaklı bir işletim sistemidir ve yeni bir platform hedefi olarak RISC-V’yi ekliyor
  • RISC-V, ücretsiz ve açık bir komut kümesi mimarisi (ISA) olup açık kaynak yazılımdaki sektör çapında iş birliği yaklaşımını donanım ekosistemine taşımayı amaçlıyor
  • 10 yıl önce UC Berkeley’de oluşturulduktan sonra gömülü sistemler ve mikrodenetleyiciler alanında hızla benimsendi; son dönemde ise hızlandırıcılar, sunucular ve mobil bilişime doğru genişledi

Yama kabulünden destek olgunlaştırma aşamasına

  • Google, Kasım 2022’de RISC-V Summit’te Android için RISC-V yamalarını kabul etmeye başlayacağını duyurdu
  • Şu anda yalnızca yama kabul etmenin ötesine geçerek Android’de RISC-V desteğini olgunlaştırma aşamasına ilerliyor
  • RISC-V modüler bir ISA olduğu için çok sayıda isteğe bağlı uzantı barındırır; Android’de beklenen yüksek performansı sağlamak için başlangıçta zorunlu özellik kümesinin belirlenmesi gerekir
    • Referanslar arasında rva22 profili yer alıyor
    • vector ve vector crypto uzantıları da dahil ediliyor

Yerelde derlenip çalıştırılabilen AOSP ortamı

  • RISC-V için Android desteği, diğer AOSP platform hedeflerinde olduğu gibi Cuttlefish Virtual Device ile yerel makinede derlenebilir, test edilebilir ve çalıştırılabilir
  • İlgili kod google/android-riscv64 üzerinden incelenebilir
  • Çalıştırma örneği aşağıdaki gibidir
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • Çalışan cihaza vncviewer ile bağlanıp etkileşim kurabilirsiniz

Hâlâ kalan optimizasyon işleri

  • Mevcut yamalar temel bir Android Open Source Project deneyimini derleyip çalıştırmayı mümkün kılıyor, ancak tamamen optimize edilmiş durumda değiller
  • Android Runtime’ın ART optimizasyon backend’i üzerindeki çalışma hâlâ devam ediyor
  • AOSP, harici projeler ve derleyiciler de en son onaylanmış uzantılardan yararlanarak tamamen optimize edilmiş ve küçültülmüş kod üretecek seviyeye henüz ulaşmış değil
  • Bu aşamanın amacı, tamamlanmış bir ürün ortamından çok deney ve iş birliğini mümkün kılmaya daha yakın

Geliştirici testleri ve emülatör yol haritası

  • 2023 sonlarında NDK ABI’nin kesinleşmesi bekleniyor
  • Android’in herkese açık CI sisteminde canary derlemeleri de yakında sunulacak
  • Ana makinede riscv64 Android uygulamalarını daha kolay test edebilmek için x86-64 ve ARM64 üzerinde RISC-V çalıştırma desteği planlanıyor
  • 2024’te farklı cihaz form faktörlerindeki uygulamaları test etmek için tam özellik setine sahip herkese açık emülatörler planlanıyor
  • Qualcomm ile yapılan iş birliği duyurusuna göre ilk form faktörünün giyilebilir cihazlar olması bekleniyor

Ekosistem iş birliği ve RISE Project

  • Android işletim sisteminin kendisini port etmek tek başına yeterli değil; çevresindeki yazılım ekosisteminin de hazır hale gelmesi gerekiyor
  • Google, topluluk ve RISE ile iş birliği yapıyor
  • RISE Project, üst seviye işletim sistemlerini çalıştıran yüksek performanslı ve enerji verimli RISC-V işlemci çekirdeklerinde yazılım erişilebilirliğini hızlandırmak için oluşturuldu
  • Kapsam yalnızca Android’i değil, Linux’u ve diğer işletim sistemlerini de içeriyor
  • Hedef uygulama alanları arasında yüksek performanslı bilişim de yer alıyor
  • Katılımcı şirketler Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head ve Ventana’dır

Standartlaşma ve katkı yolları

  • Google, RISC-V International’daki mevcut Premium üyeliği ve yönetim kurulu katılımının ötesinde yatırımlarını genişletmeye devam ediyor
  • Birçok katkı sağlayan kişi, yatay komitelerde, çalışma gruplarında ve teknik komitelerde temel roller üstlenerek spesifikasyon tasarımı ve onay süreçlerine katılıyor
  • Android’in RISC-V desteği, LLVM toolchain’den temel destek kütüphanelerine kadar geniş kapsamlı katkılara dayanıyor
  • Katkı ve test için başlıca kaynaklar şunlardır
    • google/android-riscv64: Android’in RISC-V desteğini derleme ve test etme yöntemleri, bilinen sorunlar, AOSP ile araç zinciri ve destek kütüphanelerine katkı fırsatları sunar
    • RISC-V Android SIG: İlerlemeyi takip edip öneri ve geri bildirim sunabileceğiniz e-posta listesi
  • Google, Java ve Kotlin geliştiricilerinin yeni platformları hedeflemesi gibi, yerel kod yazan Android geliştiricilerinin de yeni platformları kolayca hedefleyebilmesinin yollarını araştırıyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-02
Hacker News görüşleri

  • Geliştiricilerden hazırlık yapmalarını mı bekliyorlar? Yaklaşım yanlış. Apple’ın M1 geçişi sırasında yaptığı gibi, varsayılan durumda iş yükü sıfıra yakın olmalı; ardından isteğe bağlı optimizasyon mümkün olmalı
    Google’ın Android uygulamalarını x86’da test edin deyip sonra tekrar MIPS’te de test edin dediği zamanları hatırlamak yeterli. Sonunda hiçbir şey olmadı ve geliştiriciler zamanlarını boşa harcamayacak

    • İş yükü sıfır mı? Hafıza bazen çabuk bulanıklaşıyor gibi
      Apple, geliştiricilerin ARM donanımı deneyip uygulamalarını taşıyabilmesi için DTK sistemini 500 dolara kiraladı. İş yükü sıfırdan çok uzaktı; donanımı da iade etmek gerekiyordu ve başta seri üretim ürünü satın almak için kullanılabilecek 500 dolarlık kredi bile yoktu. Ancak beklenen tepkinin ardından düzeltildi
      Google bunun yerine yazılım emülatörü sağlıyor; bu çok daha kolay yönetilebilir ve karmaşık cihaz lojistiği de gerektirmiyor. Gerçekte hazırlık çalışması gereken taraf NDK uygulamaları geliştirenler ya da RISC-V donanım desteği üzerinde çalışanlar
      Java/Kotlin uygulamalarının taşınması gerekmiyor; benim ölçütüme göre bu sıfıra yakın iş
    • Android uygulamaları ve kütüphanelerinin x86 derlemeleri, emülatörde en yaygın hedef olduğundan çok yaygın
      MIPS’i Google’ın güçlü biçimde ittiğini sanmıyorum; daha çok sadece var olan bir şeydi
      Ayrıca bu yazı, uygulama geliştiricilerinden çok cihaz üreticilerini hedefleyerek AOSP derlemelerini ve bekleyen yamaları ele alıyor. Uygulama geliştiricilerinden bir şey yapmalarını isteyen bir yazı değil; hatta sonunda “Java ve Kotlin geliştiricilerinin yeni platformları hedeflemesi kadar yerel Android geliştiricileri için de bunu kolaylaştırmanın yollarına bakacağız” deniyor
    • Android’de MIPS, Imagination Technologies’in 2013’te satın almasından sonra fiilen öldü. Yeni SoC ya da yeni telefon yoksa Google’ın yapabileceği pek bir şey de yok
      x86, Chromebook sayesinde hâlâ yaygın kullanılıyor. NDK kullanmıyorsanız yeni hedef nedeniyle geliştirici tarafında yapılacak bir şey yok
    • Genel anlamda geliştiricilerden hazırlanmalarının beklendiğini sanmıyorum. Başlık da “hazırlanmak için bilmeniz gerekenler” şeklinde; yani hazırlanmak istiyorsanız bilgi ve tavsiye sunuyorlar. Kabul edip etmemek size kalmış
      Buradaki “you”, başlıktaki ifadeyi izliyor; belirli bir kişiyi kastetmiyor
    • Çünkü o mimariyle anlamlı bir cihaz piyasaya çıkmadı

  • Qualcomm’un bu kadar karşı çıktığı C uzantısı gerekecek mi?
    İlgili alt başlık için bkz. https://news.ycombinator.com/item?id=37996820
    Qualcomm’un en güncel materyali https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...; burada, kendilerinin önerdiği “RISC-V’yi aarch64’e biraz benzeten” Zics uzantısının ve 32 bit uzun sıçramaların RV64GC’den daha iyi kod yoğunluğu sağladığını, ayrıca sürekli sorun ettikleri C uzantısının dezavantajlarına da sahip olmadığını savunuyorlar

    • Neden eksi oy aldığını anlamıyorum. Bu soru gerçekten hâlâ devam eden bir tartışma konusu
      Qualcomm, C uzantısı olmadan bir RISC-V Snapdragon yapmaya karar verirse, o uzantıyı kullanan Android NDK uygulamalarının nasıl çalışacağını görmek zor. Bir tür trap sonrası emülasyon gibi bir yöntem değilse saçma derecede yavaş olur
    • Qualcomm’un da bir ölçüde haklı olduğu görünüyor ama daha fazla ARM teknolojisi yeniden kullanımı yapmak isteme motivasyonu da var gibi
      Google RV64GC ya da RV64G_Zics’i zorunlu kılarsa bu konuda karar verilmiş olabilir
      Ancak C komutlarını çıkarmak ya da değiştirmek, gerçek dağıtımdan sonra bir seçenek değil; şu anda çoğunlukla emülatör testi aşamasında olduğundan çok dert etmiyor da olabilirler
    • ARM’nin Thumb komut kümesine oldukça benziyor gibi
      Asıl soru bunun neden olduğu
      Referans: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • Konu dışı sayılır ama yeni AOSP emülatörünü öğrendiğimde, nedense AOSP’de Goldfish yerine Cuttlefish emülatörünü kullanmak için acloud çalıştırmak gerektiğini düşünmüştüm. Ama acloud, Ubuntu değilse çalışmayı reddediyordu
    uname fonksiyonunun çıktısını değiştiren bir LD_PRELOAD hack’i bile denedim, fakat sonra dpkg çalıştırmaya kalktı. Ben NixOS kullanıyorum
    Eski emülatörü düzgün çalıştırmak gerçekten zahmetli; yeni emülatörün ise pek çok avantajı var
    Ama garip biçimde launch_cvd’yi doğrudan çalıştırmanın yeterli olduğunu hiç bilmiyordum

  • “RISC-V için Android”in tamamen felaket olan “x86 için Android”den daha başarılı olmasını umuyorum. Hâlâ bir Lenovo x86 Android tabletim var
    Yine de bu yazıyı okuyunca çok güven vermiyor. Umudum yüksek ama beklentim düşük

    • Ana işlemci olarak RISC-V uygulamaları kullanan ucuz tüketici cihazlarının piyasayı doldurması kaçınılmaz görünüyor
      Asıl ARM desteğinin duraklamasından endişe etmek gerekecek gibi
    • Chromebook’ların çoğu şu anda x86 ve Android uygulamaları çalıştırıyor. Android emülatörü de aynı şekilde
      Herkes ARM MacBook’u olan zengin bir Amerikalı değil

  • Birkaç yıl önce Android, telefon ya da tablet olmayan ama grafik dokunmatik ekrana ihtiyaç duyan gömülü alanlarda oldukça yaygın kullanılıyordu; şimdi ise neredeyse telefonlara ve bir ölçüde tabletlere yönelik hale geldi
    Bunun nedeni, telefon/tablet üreticilerinden farklı olarak küçük şirketlerin Android’in çok karmaşık yeni değişikliklerine ayak uyduramayıp giderek ayrılmasıydı

    • Onun yerine ne kullandıklarını merak ediyorum
    • DJI hâlâ kontrolcülerinde Android kullanıyor gibi

  • Durumu tam bilmiyorum; RISC-V uygulayan başlıca telefonlar var mı? Ayrıca bu, tüm yığın boyunca değişiklik gerektiriyor mu? Sadece işletim sistemini değiştirmek düzeyinde bir şey değil gibi

    • Henüz yok, ama çıkışları yaklaşıyor
      “Yığın” ile “işletim sistemi” arasındaki sınırı nerede çizdiğinden emin değilim. Biraz daha açabilir misin?
    • Yok. Ancak Qualcomm bir RISC-V akıllı saat işlemcisi hazırlıyor. Bu da hiç yoktan iyidir
      LiCheePi 4A için AOSP portunu henüz denemedim. Sadece çalışıp çalışmadığını görmek için bir ara çalıştırmam gerekecek gibi
      PolyMC’yi çalıştırmak için gereken tüm araç zincirini bootstrap etmektense, Play Store’dan Minecraft indirmeyi denemek daha kolay

  • RISC-V’ye kurulacak şeyler arasında Google Android en son tercih olur

    • RISC-V mobil CPU’larda yaygın kullanılmaya başlarsa ekosisteme olumlu etkisi mi olur, yoksa büyük şirketler RISC-V’yi daha kurumsal kullanım senaryolarına itip hobi geliştiricileri için daha az dostane mi hâle getirir, merak ediyorum
    • Yine de Android ön yüklü bir RISC-V cihaz alıp sonra silebiliriz

  • Kaçınılabiliyorsa Android çalıştırmak aptalca bir seçim; mimariyi değiştirirken saf Linux’a geçme fırsatı varsa bu daha da geçerli
    Sorun bankacılık. En azından İsveç’te hâlâ mobil BankID’ye bağımlıyız. Örneğin 20 doların üzerindeki çevrimiçi alışverişlerde bile gerekiyor ve yalnızca iOS ile Android’de çalışıyor

    • Android olmayan bir işletim sistemini telefonda çalıştırırken aynı zamanda güç verimliliği, çoklu dokunma ve GPU hızlandırmalı Android uygulama desteği elde etmenin gerçekçi bir yolu var mı?
      Mesela Android’i KVM üzerinde verimli çalıştıran hazır bir çözüm ya da Android çekirdek özellikleriyle kullanıcı alanında RPC sunucusu sağlayan bir yaklaşım gibi
      Bu yoksa mobil uygulamalara erişmek için Android çalıştırmak zorundayız; bu da neredeyse şart
    • Danimarka’da bankalar ve kamu siteleri için MitID var. Satın alma doğrulamasında da ara sıra kullanılıyor
      Akıllı telefonun yoksa ya da kullanmak istemiyorsan, kimlik doğrulamada kullanılan küçük bir cihaz alabiliyorsun. İsveç’in banka hesabı olan herkesi akıllı telefon sahibi olmaya kadar zorlaması tuhaf görünüyor. Özellikle akıllı telefonu olmayan çok sayıda yaşlı varken