Bonjour à tous,
Je prend la plume aujourd'hui pour parler d'un sujet d'actualité, la gestion d'énergie du pilote graphique Nouveau, pilote libre et communautaire pour les cartes graphiques NVIDIA.
Ce sujet devient de plus en plus important dans les drivers graphiques libres car il est le nouvel objectif à remplir. En effet, l'infrastructure pour améliorer les performances 2D, 3D et le décodage matériel de vidéos est bien en place et le support est assez fiable. Cependant, les performances proposées par les drivers libres sont maintenant bien souvent limitées[1][2], notamment à cause de l'absence de gestion des niveaux de performance (aussi connu sous le nom de reclocking).
L'absence de gestion d'énergie impacte aussi durement les systèmes sur batterie, comme les ordinateurs portables. Du fait de la non-utilisation de plusieurs fonctionnalité matérielles pour réduire la consommation énergétique (clock/power-gating ou le manque de reclocking dynamique) la carte graphique consomme bien plus qu'elle ne devrait ce qui réduit l'autonomie de l'ordinateur et augmente sa température.
Cela fera 3 ans dans un mois que je travaille (majoritairement sur mon temps libre) sur la rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Durant ces 3 ans, j'ai obtenus beaucoup de petites victoires, mais la généralisation de ces résultats sur tous les GPUs demande un effort considérable ce qui explique le peu de fonctionnalités réellement implémentées dans Nouveau. Outre le manque de standardisation entre les différents chipsets, une autre raison majeure qui explique le manque de résultats est aussi liée au fait que j'ai dû me former sur le tas sur la problématique de la gestion d'énergie. En effet, je n'ai pas vraiment eu de formation sur le design de circuits matériels lors de mes études.
Sur l'invitation de Shinpei Kato, chercheur notamment connu pour avoir proposé un ordonnanceur pour GPU ou le support de l'exécution de noyaux OpenCL/CUDA dans le noyau Linux (gdev), j'ai soumis un papier sur mes découvertes dans la gestion d'énergie sur les cartes NVIDIA au Workshop OSPERT13. Le papier proposé touche un spectre assez large et devrait intéresser la communauté à la fois pour ses aspects techniques et pour la vision qu'il propose. Le papier ainsi que les slides de la présentation sont disponibles sur ma page de recherche.
Bonne lecture!
PS: Ce papier a été écrit avant l'annonce par AMD du support complet de la gestion d'énergie pour les dernières familles de Radeon. Bien que ce papier soit orienté pour les cartes NVIDIA, certains concepts sont applicables aux cartes AMD. Je vous conseille donc sa lecture si vous voulez mieux comprendre ce qui est proposé par AMD.
# Youpi !
Posté par znk . Évalué à 3.
Salut MuPuF, merci pour ton boulot ! La retro-ingienerie, pour moi, ca ressemble a de la magie noire tellement que ca a l'air complexe. J'aimerai bien comprendre la demarche, peut etre qu'un article vulgarisateur pour aider, si tu n'es pas contre.
Au passage, j'aimerai mettre en lumiere un autre projet qu'il mene, un IDE Arduido, arduide, en C++/Qt qui a sous le capot un debuggeur et qui est agreable a utiliser ! :)
(Desole, clavier en qwerty)
[^] # Re: Youpi !
Posté par maboiteaspam . Évalué à 2.
Hello,
il y à quelques mois il nous avait donné le plaisir d'assister à une conférence vidéo sur ces recherches qui permettait d'avoir un premier aperçu fort intéressant.
Par contre, je ne le retrouves pas……. Peut être qu'une bonne âme pourra reposter le lien du journal, ou peut être feras tu une recherche fructueuse.
Ceci dit oui je serais vraiment content d'écouter Mr Perez plus souvent, mais je radotes déjà : )
a+
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . Évalué à 4.
Je suppose que tu as assisté à une de ces conférences:
- Introduction to GPUs and to the Linux Graphics Stack
- A Deeper Look Into GPUs and the Linux Graphics Stack
Ah ah, merci. Ma prochaine conférence prévue est à l'XDC2013 à Portland. Je serai probablement aussi à la FOSDEM 2014 à Bruxelles. On verra ensuite.
[^] # Re: Youpi !
Posté par Mme Michu-cide . Évalué à 2.
Oui, Bravo MùPùf! Je suis admiratif!
Étendre le support à tous les GPU semble une tâche énorme et très certainement rébarbative pour un petit nombre de personnes, comment comptez-vous faire?
Avez-vous mis en place une suite de test, des scénarios qui pourraient être executés par des tiers, comprendre la communauté, et qui génereraient des données, statistiques que vous pourriez exploiter?
Quelle serait l'approche?
Exemple super grossier:
executer un model,une application avec le pilote proprio et ensuite avec le pilote nouveau et faire une sorte de diff des mesures récoltées.
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . Évalué à 2.
En général, ce n'est pas rébarbatif. Je suis presque certain que le code peut être majoritairement le même. C'est juste que certaines cartes sont plus sensibles à certaines opérations que d'autres ce qui permet d'exposer plus de problèmes sur mon code. Mais en effet, c'est beaucoup de travail.
Il existe déjà un programme à exécuter pour tracer ce que fait le driver propriétaire. Cela dit, nous avons déjà assez de traces. Ce qu'il nous manque maintenant, c'est du temps et du courage. Je n'ai pas pu travailler sur le reclocking depuis plus d'un an à cause de mon travail sur ptherm et la gestion de la température en général. Mon doctorat me prend aussi pas mal de temps. Mais j'espère m'y remettre très bientôt.
La raison pour laquelle je publie autant est que je suis actuellement en déplacement pour plusieurs mois et donc, je suis loin de mes ordinateurs et cartes graphiques. Je peux donc que travailler sur ce genre de choses. Cela dit, ça fait longtemps que j'aurai du le faire!
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . Évalué à 2.
De rien, on s'amuse comme on peut ;)
Hmm, on a des projets de documentation sur certains outils qu'on utilise pour faire de la rétro-ingénierie, mais y'a pas vraiment de recette magique. En général, ce qu'il faut c'est en premier pouvoir analyser les résultats de ce que tu veux reverser. Ensuite, tu peux potentiellement avoir besoin d'un outil pour tracer ce que fait le driver officiel. Et finalement, il te faut des outils pour modifier les contenus dans les registres et analyser l'impact sur ce que tu recherches. Ensuite, tu dois répéter ad nauseam!
Ce projet est un peu à l'abandon mais j'y pense toujours oui. Je dois le porter à la version beta du sdk qui va enfin me permettre de virer les tonnes d'options par défaut nécessaires pour compiler un projet. Cool.
# Contribution d'AMD
Posté par Malizor . Évalué à 4.
Justement, dans quelle mesure est-ce que l'énorme code dump d'AMD permettra d'aider à la rétro-ingénierie de la gestion de l'énergie chez Nvidia ?
Les infrastructures sont-elles très différentes ?
[^] # Re: Contribution d'AMD
Posté par Martin Peres (site web personnel) . Évalué à 7.
Si ce dump avait été fait il y a 3 ans, j'aurai pu mieux comprendre ce qu'il y avait à faire. Maintenant, c'est trop tard.
Les concepts doivent être les mêmes (ce qui ressort de mes conversations avec les développeurs AMD), mais l'implémentation n'a rien à voir. Celle pour NVIDIA a l'air aussi plus difficile. Dans le cas d'AMD, le vbios contient la liste des opérations à faire pour reclocker, ce qui n'est pas DU TOUT le cas pour NVIDIA (à part un petit script pour le changement de fréquence de la mémoire).
[^] # Re: Contribution d'AMD
Posté par kadalka . Évalué à -10.
A propos d AMD vous allez continuer ou pas ?
J ai garde le plan pour la suite.
P.S. Desole clavier QWERTY. Je ne pourrais relire qu apres le mercredi votre reponse parce aue je suis trop occupe la.
Si j ai un peu de chance je serais la avant.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.