Il faut aimer les maths "basique" (matrices, quaternions, en gros bac+2/3). Avoir un intérêt lié à la 3D, les jeux par exemples, personnellement je ne crois pas pouvoir réusir dans un domaine qui ne m'attirerai pas d'une manière ou d'une autre. Pour commencer je dirais que le mieux c'est de bien comprendre une pipeline 3D et pour cela le mieux c'est d'écrire son propre moteur 3D (software et OpenGL). Ne pas visé d'écrire un moteur comme Crytek mais plutôt un truc simple capable de rendre une scène simple en gouraud, ou avec texture. C'est le minimum pour comprendre les bases. Il existe plusieurs article sur le net qui guide pour l'écriture d'un moteur 3D.
Il est également nécessaire d'avoir des connaissances dans le domaine des compilateurs, connaissance théorique et pratique. Encore une fois rien de tel qu'un petit projet comme implémenter son propre langage (encore une fois un langage simple).
Arrivé là, il faut se mettre a lire le code de mesa, du noyau, ... et voire si on arrive à comprendre isolément des bouts de codes. Quand on regarde des projets de cette taille il n'est pas possible de regarder une fonction et toute les fonctions qu'elle appellent ou toutes les fonctions qui l'appellent. Il faut donc arriver à deviner ce que fait chaque fonction à partir de son nom. Tout ça est de plus en plus facile plus on lit le code et mieux on le comprend. Lire du code pour lire du code c'est pas top, aussi je conseille de le faire avec un but précis comme corriger un bug, ou amélioré un truc, par exemple on peut voir un hot spot ou le driver passe du temps et chercher à comprendre pourquoi.
Un autre truc qui permet d'apprendre énormément c'est d'écrire son propre programme qui parle directement au GPU et qui dessine un triangle, dans le monde du libre il y a nouveau demo ou r300 demo ou r600 demo qui donne des exemples de programme complet qui parle au noyau et qui dessine un triangle. Ca permet de comprendre et jouer avec le gpu sans avoir à faire face à tout le code de mesa. C'est a mon avis le moyen le plus rapide pour bien comprendre le GPU qui t'intéresse.
Et il est préférable d'avoir une bonne dose de patience et de ne pas tester sur son ordi, je fais tout par ssh sur l'ordi qui a le GPU sur lequel je travail (trop de reboot, ou de tuage de X).
On peut ne pas avoir une large connaissance du noyau mais il est quand même nécessaire de comprendre des trucs fondamentaux comme ce qu'est la mémoire virtual, les iommu, les page fault, ... sans pour autant connaitre le détail de l'implémentation. Il faut connaître de même les principes de bases du fonctionnement d'une distribution, comme marche le boot, qui lance quoi quand et comment.
[^] # Re: Merci !
Posté par glisse . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
Il faut aimer les maths "basique" (matrices, quaternions, en gros bac+2/3). Avoir un intérêt lié à la 3D, les jeux par exemples, personnellement je ne crois pas pouvoir réusir dans un domaine qui ne m'attirerai pas d'une manière ou d'une autre. Pour commencer je dirais que le mieux c'est de bien comprendre une pipeline 3D et pour cela le mieux c'est d'écrire son propre moteur 3D (software et OpenGL). Ne pas visé d'écrire un moteur comme Crytek mais plutôt un truc simple capable de rendre une scène simple en gouraud, ou avec texture. C'est le minimum pour comprendre les bases. Il existe plusieurs article sur le net qui guide pour l'écriture d'un moteur 3D.
Il est également nécessaire d'avoir des connaissances dans le domaine des compilateurs, connaissance théorique et pratique. Encore une fois rien de tel qu'un petit projet comme implémenter son propre langage (encore une fois un langage simple).
Arrivé là, il faut se mettre a lire le code de mesa, du noyau, ... et voire si on arrive à comprendre isolément des bouts de codes. Quand on regarde des projets de cette taille il n'est pas possible de regarder une fonction et toute les fonctions qu'elle appellent ou toutes les fonctions qui l'appellent. Il faut donc arriver à deviner ce que fait chaque fonction à partir de son nom. Tout ça est de plus en plus facile plus on lit le code et mieux on le comprend. Lire du code pour lire du code c'est pas top, aussi je conseille de le faire avec un but précis comme corriger un bug, ou amélioré un truc, par exemple on peut voir un hot spot ou le driver passe du temps et chercher à comprendre pourquoi.
Un autre truc qui permet d'apprendre énormément c'est d'écrire son propre programme qui parle directement au GPU et qui dessine un triangle, dans le monde du libre il y a nouveau demo ou r300 demo ou r600 demo qui donne des exemples de programme complet qui parle au noyau et qui dessine un triangle. Ca permet de comprendre et jouer avec le gpu sans avoir à faire face à tout le code de mesa. C'est a mon avis le moyen le plus rapide pour bien comprendre le GPU qui t'intéresse.
Et il est préférable d'avoir une bonne dose de patience et de ne pas tester sur son ordi, je fais tout par ssh sur l'ordi qui a le GPU sur lequel je travail (trop de reboot, ou de tuage de X).
On peut ne pas avoir une large connaissance du noyau mais il est quand même nécessaire de comprendre des trucs fondamentaux comme ce qu'est la mémoire virtual, les iommu, les page fault, ... sans pour autant connaitre le détail de l'implémentation. Il faut connaître de même les principes de bases du fonctionnement d'une distribution, comme marche le boot, qui lance quoi quand et comment.