Linux GPU

Blog

Android dans le cloud pour développeurs et testeurs : Redroid avec rendu GPU

Nous avons fait tourner Android 14 dans Docker (Redroid) sur un serveur Linux avec un Intel UHD 770 partagé et comparé le rendu GPU et le rendu logiciel : 58 fps au lieu de 7 sur un shader 3D, 60 fps au lieu de 19 dans un jeu 3D, et moins de 5 % de CPU au lieu de 95 %.

· Linux GPU

Android dans le cloud pour développeurs et testeurs : Redroid avec rendu GPU

Un appareil Android toujours allumé, joignable avec ADB depuis votre ordinateur portable ou votre CI, et que vous pouvez réinitialiser en quelques secondes : c’est ce que Redroid vous apporte sur un serveur Linux. Redroid (« remote Android ») fait tourner un système Android complet dans un conteneur Docker, sans machine virtuelle dans le serveur. C’est utile pour tester votre application sur un Android propre, pour lancer des tests d’interface automatisés (Appium, uiautomator, Espresso), ou pour faire tourner 24 h/24 une application qui n’existe que sur Android.

La question de cet article est simple : qu’est-ce que le GPU change ? Redroid peut dessiner l’écran avec le GPU du serveur (via Mesa) ou avec le CPU seul (rendu logiciel). Nous avons lancé les mêmes tests sur le même serveur dans les deux modes.

SuperTuxKart (gratuit, depuis F-Droid) dans Redroid, enregistré avec scrcpy sur le même serveur : rendu GPU en haut (59 fps), rendu logiciel en bas (16 fps). 5 secondes.

Les résultats en bref

  • Les applications simples sont fluides dans les deux cas : le défilement des Paramètres d’Android tournait à 60 fps avec 1 image lente sur environ 1 045 dans les deux modes. Mais le rendu logiciel utilisait 4 fois plus de CPU (17,3 % du serveur au lieu de 4,2 %).
  • Tout ce qui est en 3D a besoin du GPU : un shader de raymarching tournait à 58,4 fps sur le GPU contre 7,2 fps en logiciel, et le jeu SuperTuxKart à 60 fps contre 19 fps.
  • Le GPU libère le CPU : avec le GPU, Android utilisait moins de 5 % du CPU du serveur dans tous les tests. En mode logiciel, le travail 3D prenait 95 à 98 % des 4 vCPU, sans rien laisser pour vos tests.
  • Le démarrage n’est pas plus rapide avec le GPU : Android était prêt en environ 13 s en mode GPU et 7 s en mode logiciel.
  • iGPU Start suffit pour une instance Android ; choisissez iGPU Power pour en faire tourner plusieurs en parallèle ou pour tester des applications et des jeux 3D.

Configuration du test

ÉlémentValeur
ServeurDebian 13, Linux 7.3, Intel UHD 770 (GPU partagé), 4 vCPU, 10 Go de RAM
AndroidRedroid, image officielle redroid/redroid:14.0.0-latest (Android 14, x86_64), Docker 29.9
Écran1080×1920 à 420 dpi, 60 Hz (les jeux passent en 1920×1080 paysage)
Rendu GPUredroid_gpu_mode=host : Mesa 24.0.8, « Mesa Intel UHD Graphics 770 », OpenGL ES 3.2
Rendu logicielredroid_gpu_mode=guest : ANGLE sur SwiftShader (CPU), OpenGL ES 3.1
ApplicationsParamètres d’Android, Shader Editor 2.36.3 et SuperTuxKart 1.4 (tous deux open source, depuis F-Droid)
Mesuresimages par seconde par couche d’après SurfaceFlinger (dumpsys SurfaceFlinger --timestats), saccades d’après dumpsys gfxinfo, CPU de tout le serveur d’après /proc/stat
Affichagescrcpy 5.0.1 (version officielle), adb exec-out screencap pour les captures d’écran

Chaque mesure durait 10 à 20 secondes. Les chiffres CPU sont une part de tout le serveur (4 vCPU = 100 %).

1. Interface de tous les jours : fluide dans les deux modes, mais pas au même coût

Nous avons ouvert les Paramètres d’Android et fait défiler l’écran 20 fois vers le haut et vers le bas avec adb shell input swipe, puis lu le rapport d’images d’Android avec adb shell dumpsys gfxinfo com.android.settings :

Paramètres, 20 défilementsGPULogiciel
Images dessinées1 0451 047
Images saccadées1 (0,10 %)1 (0,10 %)
Temps par image, 50e / 90e / 99e centile17 / 18 / 18 ms17 / 17 / 18 ms
CPU du serveur4,2 %17,3 %

Pour une application normale avec des listes, des boutons et du texte, le CPU d’un serveur moderne est assez rapide pour dessiner l’écran tout seul. La différence, c’est le prix : le rendu logiciel rendait tout le serveur environ quatre fois plus occupé. Quand vos tests font tourner plusieurs instances ou enregistrent l’écran, ce CPU manque ailleurs.

2. La 3D : là où le GPU fait la différence

Nous avons utilisé deux applications open source de F-Droid : Shader Editor, qui dessine un shader GLSL en plein écran et affiche ses images par seconde, et SuperTuxKart, un jeu de course de karts en 3D. Dans Shader Editor, nous avons lancé le shader par défaut (très léger) et une scène en raymarching (sphères, ombres douces, brouillard) écrite pour ce test.

Images par seconde (CPU du serveur)GPULogiciel
Shader Editor, shader par défaut60,0 fps (4,0 %)60,1 fps (64,4 %)
Shader Editor, shader de raymarching58,4 fps (1,8 %)7,2 fps (98,1 %)
Tutoriel de SuperTuxKart, 1920×108060,0 fps (4,7 %)19,2 fps (95,2 %)
SuperTuxKart en course, enregistré par scrcpy59,2 fps16,1 fps
Graphique en barres : images par seconde dans Redroid avec rendu GPU et avec rendu logiciel, pour un shader de raymarching, SuperTuxKart et un shader simple
Images par seconde, GPU (vert) contre rendu logiciel (orange). Même le shader léger qui atteint 60 fps en mode logiciel coûte 64 % du CPU du serveur.
Graphique en barres : utilisation CPU du serveur dans Redroid avec rendu GPU et avec rendu logiciel, pour quatre charges
Utilisation CPU de tout le serveur (4 vCPU) pendant les mêmes tests : moins de 5 % avec le GPU, jusqu'à 98 % en mode logiciel.

Avec le GPU, les scènes 3D restent aux 60 fps de l’écran et le CPU est presque au repos. En mode logiciel, les quatre vCPU sont pleins et les images par seconde tombent à 7 à 19 fps : un jeu n’est plus jouable, et un test d’interface lancé en même temps serait lui aussi ralenti. Pendant qu’un jeu tournait, le conteneur Redroid utilisait environ 1,4 Go de RAM dans les deux modes, et Docker comptait 10 % d’un cœur avec le GPU contre 381 % (presque quatre cœurs) en mode logiciel.

Le shader de raymarching dans Shader Editor sur Redroid : 56 fps avec le GPU à gauche, 7 fps en mode logiciel à droite
Le même shader de raymarching dans Shader Editor, capturé avec adb exec-out screencap : GPU à gauche (l'application affiche 56 fps), logiciel à droite (7 fps). L'image est identique, seule la vitesse change.

3. Temps de démarrage

Nous avons chronométré docker run jusqu’à ce qu’Android signale sys.boot_completed=1, trois fois par mode, avec un dossier de données vide à chaque fois :

Démarrage jusqu’à « prêt »Essai 1Essai 2Essai 3
GPU12,7 s13,3 s12,8 s
Logiciel7,0 s6,5 s7,0 s

Le mode GPU démarre environ 6 secondes plus lentement, car le pilote graphique est chargé et configuré au démarrage. Pour un job de CI qui lance un Android neuf à chaque exécution, comptez environ 13 secondes avant qu’adb puisse installer votre application.

4. Voir et piloter Android depuis votre ordinateur

Redroid n’a pas d’écran à lui : vous l’utilisez comme un téléphone branché en USB, avec ADB.

  • Captures d’écran : adb exec-out screencap -p > screen.png, la méthode utilisée pour les images ci-dessus.
  • Écran en direct, souris et clavier : scrcpy (open source, par Genymobile) affiche l’écran d’Android dans une fenêtre et transmet vos clics et vos touches. Il passe par ADB, donc il fonctionne avec Redroid. Sur le serveur, nous l’avons utilisé sans fenêtre pour enregistrer les vidéos de cet article : scrcpy -s 127.0.0.1:5555 --no-window --no-audio --record=run.mp4 --time-limit=7.
  • Automatisation de l’interface : adb shell input (appuis, glissements, texte) a piloté tous les tests de cet article, et adb shell uiautomator dump renvoie l’arbre des vues de l’écran. Appium (pilote UiAutomator2), Espresso et Maestro se connectent de la même façon à un appareil ADB ; nous ne les avons pas lancés dans ce test.

N’ouvrez jamais le port ADB sur Internet : l’ADB de Redroid n’a pas de mot de passe et donne le contrôle complet du système Android. Nous le publions uniquement sur l’adresse locale du serveur (-p 127.0.0.1:5555:5555) et y accédons par un tunnel SSH :

# sur votre ordinateur
ssh -N -L 5555:127.0.0.1:5555 you@<server> &
adb connect 127.0.0.1:5555
scrcpy -s 127.0.0.1:5555
SuperTuxKart dans Redroid avec rendu GPU en 1920×1080, capture d'écran prise avec adb
Le tutoriel de SuperTuxKart dans Redroid avec rendu GPU, en 1920×1080 et 60 fps.

5. Ce qu’il faut savoir avant de commencer

  • C’est un Android x86_64. Les applications écrites en Java ou en Kotlin tournent telles quelles. Les applications et les jeux avec du code natif compilé uniquement pour ARM (beaucoup de jeux) ont besoin d’une couche de traduction : l’image Redroid annonce la prise en charge d’ARM (arm64-v8a) via une telle couche, mais nous n’avons pas testé d’applications uniquement ARM, et elles seront plus lentes et peuvent échouer.
  • Pas de Google Play Store. L’image officielle n’a pas les services Google. Installez vos propres APK avec adb install, ou des applications open source de F-Droid comme nous l’avons fait. Les applications qui ont besoin des services Google Play ne fonctionneront pas telles quelles.
  • Pour les tests et l’automatisation, pas pour simuler des téléphones. Redroid indique aux applications qu’il s’agit d’un appareil virtuel. Il est fait pour le développement, les tests et vos propres outils, pas pour faire tourner de nombreux « téléphones » pour plusieurs comptes, ce que la plupart des conditions d’utilisation des applications interdisent.
  • Pas de caméra, de GPS ni de carte SIM. Les capteurs sont absents ou simulés ; testez-les sur un vrai appareil.

6. Quelle offre ?

Avec le GPU, une instance Android utilisait moins de 5 % de nos 4 vCPU et environ 1,4 Go de RAM, même dans un jeu 3D. iGPU Start (2 vCPU, 8 Go de RAM, 14,99 € HT par mois) suffit pour une instance Android avec vos outils de test à côté. iGPU Power (4 vCPU, 14 Go de RAM, deux fois la part GPU de Start, 29,99 € HT par mois) est le meilleur choix pour faire tourner plusieurs instances Android en parallèle (une par job de test), pour tester des applications et des jeux 3D, ou pour enregistrer l’écran pendant les tests. iGPU Pro (6 vCPU, 14 Go, Perf 3, 44,99 €) ajoute plus de GPU et de CPU pour de plus grandes fermes de test.

Sans GPU, le même serveur devrait consacrer tout son CPU au dessin dès qu’une application utilise la 3D.

7. La mise en place sur un serveur Linux GPU

Envie d’un serveur prêt à l’emploi ? Demandez-le par e-mail à la commande (contact@linuxgpu.eu) : nous pouvons vous livrer le serveur avec Redroid déjà installé et réglé pour le rendu GPU. Il ne vous reste qu’à vous connecter avec ADB par SSH et à installer votre application.

Pour le faire vous-même sur Debian 13 :

  1. Chargez le pilote binder d’Android (inclus dans le noyau Debian) et gardez-le au démarrage :

    echo "options binder_linux devices=binder,hwbinder,vndbinder" > /etc/modprobe.d/binder.conf
echo binder_linux > /etc/modules-load.d/binder.conf
modprobe binder_linux

  2. Installez Docker et ADB (apt install docker.io adb), puis lancez Redroid avec le rendu GPU :

    docker run -d --name redroid --privileged \
  -v ~/redroid-data:/data -p 127.0.0.1:5555:5555 \
  redroid/redroid:14.0.0-latest \
  androidboot.redroid_gpu_mode=host \
  androidboot.redroid_gpu_node=/dev/dri/renderD128 \
  androidboot.redroid_width=1080 androidboot.redroid_height=1920 \
  androidboot.redroid_dpi=420 androidboot.redroid_fps=60

  3. Vérifiez qu’Android utilise le GPU : adb connect 127.0.0.1:5555 && adb shell dumpsys SurfaceFlinger | grep GLES doit afficher « Mesa Intel(R) UHD Graphics 770 ». « SwiftShader » signifie rendu logiciel.

  4. Connectez-vous depuis votre ordinateur par le tunnel SSH ci-dessus, installez votre APK avec adb install, et lancez vos tests.

Pour remettre Android dans un état propre, supprimez le conteneur et son dossier de données, puis relancez-le.

Pour les tests de navigateur sur le même type de serveur, lisez Selenium et Playwright accélérés GPU et Lancer Chrome avec le GPU sur un serveur Linux (headless). Pour comprendre comment un conteneur utilise le GPU d’une machine virtuelle, voir Cloud GPU : VM ou conteneur, GPU dédié ou partagé ?

Essayer

Voir les offres : iGPU Start coûte 14,99 € et iGPU Power 29,99 € HT par mois.

À lire aussi