Category Archives: 3D

Vrai départ pour les pilotes libres pour les GPU Mali

Si les premiers pilotes amorcés en 2012 avaient étés abandonnées un peu plus d’un an plus tard, depuis l’été 2017 des nouveaux pilotes ; Lima Driver pour l’architecture Utgard (Mali-400 et 450) et Panfrost, pour architecture Midgard (Mali-Txxx) et Bitfrost, sont tous deux partis en flèche, au point d’effectuer les fonctions basiques et de bientôt pouvoir rejoindre le noyau Linux et la bibliothèque Mesa.

Luc Verhaegen (libv) avait commencé le premier pilote libre pour le processeur graphique ARM Mali-400 (architecture ugard) aux alentours de 2012, pour l’abandonner aux alentours de 2013. Les pilotes étaient restés figés depuis, à part quelques mises à jour minimes avortées. Mais depuis l’été 2017, Qiang Yu à relancé le projet et suit au plus près le noyaux Linux (aujourd’hui 4.17rc) et Mesa (aujourd’hui 18), pour une intégration rapide à ceux-ci.

D’un autre côté, Panfrost est un pilote réunissant le travail de Connor Abbott (qui avait fait un début de pilote en 2013 également pour l’architecture Midgard (Mali-T6xx et supérieur), créé un désassembleur de shaders, puis différents outils (compilateur Lima) pour l’architecture Midgard et Bitfrost (Mali-Gxx). Toujours au même moment, Alyssa Rosenzweig, qui a commencé le développement pour l’architecture Midgard avec le pilot Chai, coordonne ses travaux avec ceux de Connor Abbott dans un projet nommé Panfrost. Les progrès sont très rapide comme pour le nouveau pilote Lima. Les auteurs prévoient d’utiliser LLVMpipe pour l’émulation Logicielle des parties non encore intégrées pendant leur progression. en mai 2018, le test du cube utilisant des shaders initialement produit pour le pilote Freedreno, fonctionne parfaitement. Les shaders passent par NIR (une représentation intermédiaire des langages de shaders (comme glsl) dont le but est de faciliter la compilation dans le langage du processeur lui même), de Jason Ekstrand.

Vous pouvez suivre leur progrès :
* Sur le blog d’Alyssa Rosenzweig pour Panfrost (et les sources sur GitLab).
* Sur le compte dépôt git des sources de Qiang Yu pour Lima sur gitlab.Freedesktop.org (linux-lima (pilote noyau DRM) et mesa-lima (pilote OpenGL ES/Gallium pour Mesa))
* Compte GitHub de Connor Abbott.

Quelques mises à jours dans les paquets Archlinux ARM faits maison

Toujours dans mon dépôt perso de binaires et PKGBUILD Archlinux ARM
* Ajouté l’émulateur PPSSPP (pour PSP, console portable), étonnamment il détecte si c’est OpenGL ou OpenGL ES qui est accéléré et s’adapte !!! Espérons que ça en pousse d’autres à faire pareil en attendant Vulkan. Par contre sur le RK3288, on peut pas agrandir la fenêtre et l’application plante (en figeant X) si l’accélération matérielle est active. (il est possible de ne redémarrer que lightdm si on est connecté en ssh sur la machine.

* Nouvelle version de qemu (2.4.1, je sais plus si je l’avais dit), on doit pouvoir améliorer encore, mais c’est déjà mieux. Il n’y a pas l’exécutable qemu-kvm par exemple. Mise à jour du 10 décembre : mise à jour en version 2.5.0 de mon paquet (requiet libcacard qui est un paquet à part, se trouve dans le même dossier), ajoute les émulations de systèmes complets, les bios, le support GTK, les PKGBUILD sont plus propres.

* Mise à jour d’Entangle (même version mais avec lib récente)

* Mise à jour de 0ad (Alpha19, il vaut mieux du full OpenGL accéléré, sinon, c’est du 3 fps en pur logiciel ^^

* Mise à jour de blender en 2.76.b, plus besoin de mon patch puisque le patch pour non-x86 a été appliqué dans les sources originales, le PKGBUILD officiel d’archlinux (pour x86) fonctionne donc parfaitement sous arm (et autres à priori)

* en ARM et x86_64 à la fois, j’ai ajouté perl-glib-object-introspection qui permet d’utiliser gstreamer avec gmusicbowser (any comme écrit en perl, également disponible) et donc de jouer plus de formats de fichiers. Penser à choisir pulse à la place d’auto pour la sortie de gstreamer dans les prefs). Ils sont tirés d’AUR sans modification.

J’ai créé un dossier obsolète pour les vieux paquets qui ne doivent plus fonctionner (entre changement de gcc, libc et api/abi).

J’ai commencé une méthode de saisie pour le mongol traditionnel pour ibus, ça marche assez bien mais c’est pas encore complet, donc, je n’ai pas mis. Je ne suis pas sur de la meilleur disposition pour le clavier, chaque clavier que j’ai vu (sur Android (application Bainu),, ou différents schéma sur les sites webs (sur un clavier cyrillique mongol ou russe, sur un clavier qwerty (pour les Mongols de Chine probablement ?)) de documentation de l’écriture sont différent…) j’en ai pris un relativement phonétique par rapport au qwerty donc. Je la mettrais à disposition dès que j’aurais mis les codes spéciaux indispensables pour certaines liaisons.

Blender est utilisable sur ARMv7 (32 bits) sans acceleration 3D grâce à LLVMpipe.

blender-17:2.76-1.0001-armv7h.pkg.tar.xz (paquet pour Archlinux ARM). (version mise à jour par l’équipe blender par défaut en utilisant le PKGBUILD d’archlinux x86, compile tout seul maintenant et devrais être intégré dans le build automatique archlinux ARM : blender-17:2.76.b-3-armv7h.pkg.tar.xz cette version ne marche plus en raison de la mise à jour d’autres librairies, utilisez pacman maintenant)

J’ai proposé un patch, accepté (mais retravaillé) par la formidable équipe Blender qui permet de compiler sur des architectures non-x86 (non Intel). J’ai proposé ce soir un PKGBUILD et patch pour Archlinux ARM en attendant que sorte la prochaine version de Blender.

.Sur mon Chromebook ARM (Asus Chromebook C201, utilisant un Rockchip RK3288 : CPU=4*Cortex-A17@1.8 Ghz + GPU=Mali-T764, uniquement compatible OpenGL ES (vivement Vulkan)), ça tourne plutôt bien en pure rendu logiciel, grâce à LLVMpipe pour l’interface et à la puissance de la machine pour le rendu. Il n’y a pas encore d’optimisation SIMD ARM NEON (pour ARMv7) ou pour (ARMv8) pour Cycle.

C’est une machine que j’ai pris il y a 2 semaines qui à l’avantage d’être :
* pas cher (200€ 2Go RAM, 250€ 4Go RAM en France) / 150$ 2 Go RAM, 200$ 4Go RAM aux États-Unis, cherchez l’erreur).
* Avoir une bonne autonomie : 13heure sous chromeOS (installé par défaut), jusqu’à environ 3j (oui, 72 heures de marche !!!) sous GNU/LInux, si on coupe les modules Wifi/BT lorsque l’on ne s’en sert pas.
* Être malgré tout léger (900 grammes), la faible consommation et grande efficacité du Rockchip permettant d’avoir cette autonomie avec une batterie 2 cellules/38 Wh, et évitant d’avoir à embarquer radiateur et ventilateur.
* Bien carburer malgré ces caractéristiques.

Je vais faire un autre article ou une page pour expliquer comment l’installer.

Il reste à installer le support OpenCL, pour utiliser l’accélération du GPGPU avec rendu 3d de Cycle (2e rendu en fin de vidéo).

En plus de son côté très léger et grande autonomie (introuvable sur les processeurs Intel, forcément plus lourds, avec pour les plus léger une autonomie moindre), J’aime bien le fait que ce soit une marque de République de Chine (Taïwan) et un processeur de République populaire de Chine (Chine continentale), parce qu’aucun de ce pays divisé en 2 n’est en guerre, je n’ai donc pas l’impression de participer à l’effort de guerre. De moins polluer (plus grande efficacité énergétique).

Méthodes de contrôle à distance d’une SBC (exemple avec la Cubieboard)

* Port série
* SSH
* SSH + X11
* XDMCP
* Protocole X

Port série/UART/RS232

Si il n’y a pas de réseau, dans la séquence U-boot, ou pour d’autres raisons. Connecté via (remplacer le x par le numéro correspondant) :
* Un câble série entre l’ordinateur de contrôle et la carte contrôlée (CubieBoard ici) et utiliser le port /dev/ttySx.
* Un câble/adaptateur USB< => série standard (comme compatible PL2303, CH340, FT2232C…) et utiliser le port /dev/ttyUSBx.

Branchement du port série sur la Cubieboard

Branchement du port série sur la Cubieboard

Voir aussi cet article, section Premiers tests de démarrage Continue reading