Martin - Développeur C

1/ Contractor – ARM. Industrie : Conception de processeurs. Lieu : Cambridge, UK. Septembre 2012 – present.
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.
Technologies : C, C++, OpenCL, python, unit-tests, conformance tests, gdb, subversion, JIRA, Linux, Load Sharing Facility, programmation pour l'embarqué.
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

2/ Software Design Engineer - Imagination Technologies. Industrie : conception de processeurs graphiques.
Lieu : Kings Langley, London UK. Juillet 2011 – Août 2012.
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)

3/ Stage de fin d'étude / Stage de recherche – laboratoire : CERV, LISyC.
Secteur : Développement logiciel.
Lieu : Brest, Bretagne, France. Février 2011 - Juin 2011.
Technologies : C++, OpenCL, OpenGL, pthread.
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
→ Environnement linux ubuntu

4/ Stage puis CDD à Diateam - Diateam.
Lieu : Brest, Bretagne, France. Mars 2010 - Août 2010.
Secteur : Développement logiciel.
Technologies : C++ (Linux), C (user et kernel level sur Windows), python, Java, Java disassembler, bash, Linux, bazaar, git, Windows kernel debugger.
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éliorer la lisibilité des graphes) pour le layout et la librairie Qt pour le rendu et l'interface. J'ai travaillé sur le GUI, implémenté un composant permettant de d'automatiser des actions utilisateurs (ECMA script, en utilisant QScript) et écrit des scripts de collecte de données en python et bash.
→ Calcul de layout de graphes avec graphviz dans l'application (C++)
→ Transformation des graphes (C++)
→ Affichage des graphes (Qt)
→ Implémentation d'algorithmes de calcul de proprités de ces graphes (dont l'implémentation d'algorithmes non triviaux)
→ Ajout de fonctionnalités au GUI (affichage (log) des opérations réalisées et de leur résultats, manipulation des nœuds du graphe, ..)
→ Ajout d'un composant permettant d'écrire et d'exécuter des scripts ECMA (javascript) dans l'application, afin de pouvoir automatiser toute action de l'utilisateur (Qt, QScript)
→ Ecriture de scripts de collectes de données (python, bash, nmap, traceroute, ..)
→ Versionning avec bazaar, système linux ubuntu
Enfin, j'ai travaillé sur la librairie open source libvirt (API pour la virtualisation, code en C uniquement), à laquelle j'ai ajouté ce qui permet de gérer les machines virtuelles VMware player et workstation.
→ Ajout du code nécessaire au support des hyperviseurs VMware player & workstation (C)

5/ Stage chez Viametris – Viametris.
Lieu : Laval, Pays de la Loire, France. Juin 2009 - Août 2009.
Secteur : Développement pour l'embarqué.
Technologies : C embarqué, électronique, microprocesseur PIC, lidar, Rs232/422, bus CAN.
J'ai concu et développé un système (breveté) de détection et de capture de panneaux routiers. J'ai utilisé un microprocesseur PIC, un lidar (laser radar), le bus CAN du véhicule, deux appareils photographique à commande numérique et un ordinateur embarqué. Le système est toujours utilisé par l'entreprise.
J'étais l'unique personne à travailler sur le projet et j'ai travaillé en complète autonomie. Ca m'a prit un peu plus de deux mois. J'ai commencé par sélectionner une carte de développement, une carte d'extension pour le bus CAN, et ai commandé le processeur (DSPIC33F – choix imposé). J'ai effectué des modifications sur la carte afin d'ajouter un controlleur RS422. En utilisant l'IDE de Microchip (qui permet aussi de flasher la carte via ICD2) j'ai implémenté le programme de détection de panneaux. Quand la réflectivité recut du lidar correspond à une certaine forme, the système déclanche une première (ou plus, en fonction de la configuration) prise de photo de la face du panneau, et l'envoit à l'ordinateur embarqué. Ensuite, en fonction de la vitesse du véhicule et de l'angle du volant (lus via le bus CAN), le système effectue un calcul et déclanche le second appareil photo au moment opportun afin de prendre un photo de l'arrière du panneau. J'ai enfin réalisé des tests, d'abord à l'arrêt, puis sur route ouverte. Le système était extrèmement fiable et précis.
→ Conception complète d'un système embarqué hardware + software (langage C)
→ Choix d'une carte de développement et d'un modèle de processeur
→ Développement sous windows avec l'IDE de Microchip
→ Ajout d'une carte d'extension pour supporter CAN, et ajout d'un controlleur RS422 + soudure
→ Lecture des trames envoyées par le lidar + configuration
→ Test de détection de panneux dans le bureau
→ Test de détection de panneux et de prise de photo de face dans le garage
→ Branchement sur le bus CAN du véhicule, lecture des trames, identification des trames de vitesse et d'angle au volant
→ Implémentation d'un algorithme de calcul de trajectoire
→ Test de détection de panneux et de prise de photo face arrière dans le parking
→ Ajout d'une API de configuration & commande de la carte par un ordinateur embarqué
→ Test de détection sur route