ARM est un des leaders en matière de conception de processeurs. Les processeurs ARM sont utilisés dans 95% des smartphones ainsi que dans de nombreux ordinateurs portables, télévision numériques et set-top boxes.
J'ai travaillé au sein d'une équipe inter-département (processor / media processing) chargée de la création d'un driver OpenCL multi-devices (gpu/cpu). J'étais en charge du développement des fonctionnalitées ayant trait à la partie runtime (c'est-à-dire pas les parties compilateur ni fonctions built-in) du plugin cpu (qui vise vise à utiliser les instructions Neon des processeurs de la famille Cortex-A). J'ai implementé de nouvelles fonctionnalitées et les tests unitaires correspondants, corrigé les bugs, surveillé et traqué toute regresssion dans les résultats des benchmarks, effectué des vérifications du code de collègues d'autres équipes et ai participé à l'évolution de l'infrastructure de test pour répondre aux exigences de robustesse du projet.
→ En charge du développement (langage C) du plugin CPU (Neon) au sein du driver OpenCL
→ Implémentation des fonctionnalités spécifiques au plugin CPU
e.g.: cohérence des caches gpu/cpu, suppression des opérations de caches superflues host/cpu, exécution multi-coeur des kernels opencl, threads-safety des structures du plugin CPU, support de multiple platformes, ...
→ Implémentation des fonctionnalités communes au CPU et GPU mais requises par l'ajout d'un plugin
→ Ajout (occasionnel) des fonctionnalités au compilateur / functions builtins
→ Ecriture des tests unitatires associés
→ Surveillance quotidienne des tests unitaires exécutés automatiquement
→ Investigation initiale (souvent avec gdb) + dispatch des tâches aux équipes adéquates (compilateur, functions built-in, runtime, kernel driver)
→ Réparation des bugs dans la partie runtime
→ Ecritures de scripts (python) et configuration de l'infrastructure de tests pour l'exécution automatique de tests de conformance
→ Soumission de rapport de bugs + patch concernant les tests de conformance au groupe Khronos (certification OpenCL)
→ Port des tests sur des platformes différentes (platformes utilisées : FPGA, Pandaboard, Arndale, Versatile Express, …)
→ Review du code de collègues (via CodeCollaborator) pour la partie runtime du plugin CPU
→ Travail effectué d'un cluster utilisant Load Sharing Facility (LSF), os : linux red hat 5
→ Versionning via subversion (svn) et git
→ Gestion des bugs et tâches via Jira et Bugzilla
Imagination Technologies est un des leaders en matière de conception de gpus (PowerVR) pour téléphones mobiles. Les GPUs PowerVR sont notamment utilisés dans de mombreux SoC d'Intel, de Samsung, d'Apple et de Texas Instrument. En 2012 Imagination à acheté MIPS, qui est une autre entreprise de renom concevant des processeurs.
Technologies : C, C++, OpenCL, intermediate langages and assembly, llvm/clang, conformance tests, gdb, autre outils de debug, perforce, git, Linux, programmation Unix (sockets, shared memory, pthread, ..).
Les six premiers mois j'ai travaillé sur un driver et un compilateur OpenCL pour certains GPUs PowerVR. J'ai ajouté des fonctionnalités afin de respecter les spécifications d'OpenCL 1.1. J'ai eu l'occasion de faire des modifications dans clang/llvm (compilateur), de réparer des bugs dans le compilateur bas-niveau et dans le driver lui-même (la partie runtime). J'ai en outre ajouté de nouvelles fonctionnalités au driver, executé des tests de conformance, créer des rapport de bug et soumis des patches au groupe Khronos OpenCL.
→Implémentation de fonctionnalités (langage C) ajoutées par OpenCL 1.1 (par rapport à OpenCL 1.0) dans la partie runtime du driver pour Powervr SGX (e.g. user events)
→ Implémentation de fonctionnalités au sein du compilateur (clang+llvm, langage C++), aussi bien dans le frontend (clang), dans les passes de transformation et d'optimisations du code llvm IR que dans le backend llvm.
→ Réparation des bugs détectés par les tests de conformance, avec une combinaison de gdb, de compilateur offline et de lecture d'assembleur
→ Réparation de bugs jusqu'au compilateur propriétaire bas niveau (commun avec les shaders OpenGL), et au sein du patcher live (pour cause de manque de ressources dans l'équipe compilateur)
e.g. bug dans l'ordre de réarrangement des instructions, mauvais flag (oubli de synchronisation) sur une instruction causant une corruption des données, ..
→ Versionning avec Perforce (driver) et subversion (tests de conformance), OS linux debian
Après six mois j'ai intégré l'équipe de développement pour Android, pour laquelle j'ai porté un logiciel sur ce système et implémenté un framebuffer capable d'être affiché via VNC. J'ai par ailleurs créé un outil permettant de réaliser un profiling des performances des GPUs (essentiellement pour OpenGL ES et EGL).
→ Implémentation d'un framebuffer VNC (langage C), s'intégrant avec le compositeur d'Android (Surfaceflinger)
→ Ajout de point de hooks au driver OpenGL ES (langage C), pour enregistrer ses performances, les traiter (programme en C) et les afficher dans l'outil de visualisation officiel Google
→ Configuration et compilation de kernel linux (Android) pour différentes platformes (TI Blaze + x86/FPGA)
→ Compilation d'android (Ice Cream Sandwich), utilisation d'uboot, pxelinux, tftp, nfs.
Trois mois avant mon départ j'ai rejoint une nouvelle équipe (de 2 personnes, moi compris) chargée de créer de toutes pièces un driver Renderscript Compute (concut par Google, c'est plus ou moins l'équivalent d'OpenCL sur Android). Nous étions capable d'executer les premiers kernels environ 1 mois et demi après avoir commencé, et de réussir les premiers tests réels après 2 mois.
→ Création d'un driver Renderscript Compute à partir de zero (langage C)
→ Création d'un backend llvm (langage C++) (Google a préalablement modifié le frontend pour supporter Renderscript)
→ J'ai personnellement implémenté les parties qui configurent le gpu et lui soumettent les tâches, une partie du backend et une partie de l'API (la partie runtime de renderscript est minimale, tout est synchrone, pas d'évènements)
→ Exécution des premiers example de kernels renderscript et validation des résultats
→ Versionning effectué avec Perforce (driver), git (patchs pour Android) et repo
→ Utilisation de linux ubuntu (OS supporté par Google pour compiler Android)
Le but de mon travail était d'étudier l'apport de l'utilisation d'un GPU pour le calcul du layout de gros graphes. J'ai implémenté divers algorithmes à la fois sur CPU en utilisant pthread et sur GPU en utilisant OpenCL. J'ai commencé par coder l'algorithme le plus basique (grande complexité algorithme) puis j'ai expérimenté des algorithmes plus complexes mais qui convergent plus rapidement vers une solution, en tirant pleinement partie de spécificités de l'architecture du GPU Nvidia utilisé. J'ai aussi proposé des améliorations à un algorithme qui venait d'être publié par un spécialiste du layout de graphes. Le travail que j'ai effectué est désormais utilisé dans une application concrete.
→ Recherche des techniques existantes pour le calcul de layout de graphes dans les bases de données de recherche
→ Implémentation d'algorithmes multithreads utilisant phtread (C++) (sur Intel Xeon)
→ Implémentation d'algorithmes utilisant OpenCL (OpenCL, C++) (sur Nvidia Quadro)
→ Affichage des graphes en utilisant OpenGL
→ Interface graphique avec Qt
→
Pendant ce stage j'ai implementé un rootkit pour les systèmes Windows RT utilisant l'état de l'art des techniques du domaine. J'ai eu essentiellement recours à la manipulation directe d'objets en mémoire afin de rendre le plus invisible possible un processus. Le rootkit (preuve de concept) créé était invisible de la plupart des anti-rootkits. J'ai aussi étudié et testé des techniques d'injection de dll.
→ Modernisation d'un rootkit trouvé sur internet
→ Ajout de fonctionnatlités (langage C)
→ Utilisation du debuggeur noyau windows (kd) pour l'étude des structures de données et l'affichage des symboles / adresses / tables
→ Test contre des antirootkits (une quinzaine)
J'ai ensuite analysé statiquement un binaire Java afin d'être capable de lire et d'écrire des fichiers du format propriétaire utilisé (non documenté, application obfusquée avec YGuard).
→ Décompilation du binaire Java avec JAD
→ Ecriture d'un programme Java reproduisant le comportement du programme analysé lors de l'écriture d'un fichier (sérialisation d'objets + padding + compression (gunzip))
→ Ajout de la fonctionnalité lecture + écriture de ce format de fichier à un logiciel (C++, Qt)
J'ai aussi écrit un module C++ pour le dessin de graphes, utilisant la librarie Graphviz (à laquelle j'ai ajouté d'autres opérations pour améliore...