[Index Software] Coin des développeurs :]

[Bubu]

Ce qui m’a dégouté des maths,c'est la deuxième année. On m'a forcé à apprendre à diagnonaliser les endomorphismes. C'est con, parce que ça demande infiniment plus de calculs que de se contenter de multiplier les matrices directement. Il faut calculer les valeurs propres, les vecteurs propres, la base et son inverse...Bref, en 3eme année j’ai changé de cursus pour aller en informatique tout court.

[Tugdual]

Chez Korben :

• AYA - Une interface graphique pour Android...

[Tugdual]

Chez Korben :

• DecompAI - L'IA qui révolutionne le reverse engineering...

[Tugdual]

Chez Korben :

• o3 d'OpenAI découvre une vulnérabilité zero-day dans Linux...

Extrait :

Ce qui rend cette découverte exceptionnelle, c’est la complexité du raisonnement nécessaire à sa découverte. o3 a dû pour cela comprendre comment deux connexions SMB distinctes peuvent partager la même session grâce au session binding de SMB 3.0, analyser les interactions entre threads concurrents, et identifier qu’un objet critique est libéré par un thread pendant qu’un autre thread l’utilise encore. C’est le genre de bug qui demanderait normalement de comprendre au minimum 3300 lignes de code et leurs interactions subtiles.

Et les chiffres parlent d’eux-mêmes car quand on donne à o3 le code de gestion des sessions SMB (~27k tokens), il trouve cette vulnérabilité dans 8 runs sur 100. Claude Sonnet 3.7 ? 3 sur 100. Claude 3.5 ? Zéro pointé. On n’est plus dans la même cour de récré.

[Bubu]

J'ai franchement galéré avec le multitâches. Et surtout avec les systèmes de synchronisation de tâches.
Si on s'y prend mal, et que le code est mauvais, il se peut qu'un thread en attende un autre qui lui même l'attende lui aussi. On appelle ça des deadlocks en anglais. Et c'est catastrophique parce que ça bloque le système et c'est très difficile à déboguer. Parce que techniquement ce n'est pas un bug. Un thread en attend un autre, et pareil pour un autre, c'est tout. Donc ça n'est pas détecté et ne provoque pas d'erreur.
Quand je programmais en C++ pour windows, je me contentais des sections critiques.
Quand un thread entre dans une section critique, aucun autre thread ne peut y entrer, il est mis en pause jusqu’à ce que le thread à l’intérieur en sorte, et du coup le thread suivant peut à son tour entrer dedans.C'est comme une file d'attente, chacun son tour.
Et justement c'est cette situation que l'on cherche à tout prix à éviter chez les GPUs. Que les cœurs s'attendent mutuellement.


J'ai déjà rencontré ce cas là. J'écris fièrement mon shader, et je lance le programme. La catastrophe, je devais en être arrivé à 2 images par seconde. Parce que j'avais mis une condition qui engendrait dans un cas un certain calcul et dans l'autre cas un autre. Donc les cœurs du GPU étaient complètement désynchronisés.
Juste en changeant une ligne, le rendu était de fréquence normale. C'était pour les ombres.
La seule solution, du moins pour les GPUs, c'est de calculer les couleurs 2 fois : une fois à l'air libre, et l'autre quand on est dans l'ombre.
On se doute bien qu'il y aura 1 calcul sur les 2 qui sera inutile.
Mais on utilisera la fonction test pour choisir la bonne valeur.

Code : Tout sélectionner

(heure > 6 ? jour : nuit)

Ce qu'il veut dire que s'il est plus que 6 heures c'est le jour et sinon il fait nuit.
Pas besoin d'embranchements.

Code : Tout sélectionner

(booléen ? true : false )

[Bubu]

Les GPUs sont programmables depuis au moins 20 ans.
Les programmes pour GPUs sont appelés shaders.
A ma connaissance, il y en a 4 différents.
Les vertex shaders, les pixels shaders, les geometry shaders et les domain shaders.
Les plus importants sont les vertex shaders et les pixels shaders.
OpenGL parle plutôt de fragment shader que de pixel shader.

La base, c'est de bien comprendre les vertex shaders et les pixel shaders.

Les vertex shaders travaillent sur des vertex, qui sont des points affublés d'autres donnés comme leur normale.
Un objet 3D est défini par un ensemble de triangles qu'il faut transformer. Comme le placer dans la scène, le mettre à la bonne échelle, et sous une certaine orientation.

Une fois que tout est prêt dans le GPU, il faut bien savoir quoi en faire.
Et c'est là que les pixels (ou fragments) shaders calculent l'éclairage des objets, mais pixel par pixel. Oh malheur.
C’est ce qui est le plus couteux, à un tel point qu'on néglige les vertex shaders quand on parle performance.

[Bubu]

Mais qu'y a-t-il entre le vertex shader et le pixel shader ?
La rasterisation. Qui consiste à transformer 3 points théoriques en une suite de points physiques d'un triangle à l'écran. Et le pixel shader est invoqué pour chacun de ces pixels.
Les positions sont calculées par le rasteriseur, mais le reste est calculé via des interpolations. Par exemple les normales sont interpolées elles aussi.
Et tout cela se fait en parfaite transparence.
Donc la première chose à faire dans un pixel shader pour commencer, c'est de normaliser les normales.