pilotes graphiques et GPU "hardware scheduling"
#1
Bonjour,

J'ai deux questions pour lesquelles une rapide recherche ne m'a pas vraiment apporté le moindre résultat, du coup de les pose ici au cas où quelqu'un saurait une réponse.

Question 1 : la dernière version de Windows 10 a une option pour transférer la charge de la gestion de la mémoire graphique (si j'ai bien compris) du CPU au GPU (en gros la carte graphique gère elle-même sa mémoire au lieu de laisser le CPU s'en occuper, ce qui devrait réduire la latence et potentiellement améliorer les performances... mais comme c'est encore très récent les pilotes graphiques ne sont pas forcément mieux optimisés que Windows dans ce domaine)... est-ce que quelqu'un a essayé d'activer cette option, et si oui, est-ce que cela a un effet positif pour F@H avec un GPU NVidia ?

Question 2 : NVidia propose des pilotes graphiques (drivers) "Gaming" et des pilotes "Studio"... est-ce que la moindre différence a été observée entre ces deux types de pilotes pour ce qui est du PPD F@H sous Windows 10 ?

Merci.

Christophe
"Je sers la science et c'est ma grande joie."  -Disciple-

[Image: sigimage.php?u=600217]
Répondre
#2
Après un peu de test, je n'ai pas vu de vraie différence entre les pilotes "gaming" et les pilotes "studio".

Pour ce qui est du "GPU hardware scheduling", l'activer a peut-être un impact positif sur le PPD, mais c'est trop marginal pour vraiment en être certain.
"Je sers la science et c'est ma grande joie."  -Disciple-

[Image: sigimage.php?u=600217]
Répondre
#3
Pareil, de ce que j'ai lu, aucun gain notable ... Sad

Les pilotes Gaming sont mis à jour plus souvent que les Studio pour intégrer les optimisations spécifiques à chaque sortie de nouveau jeu. Sinon, c'est pareil à version de pilote égale.
Répondre
#4
Peut-être que les pilotes vont progressivement améliorer la gestion de la mémoire au fur et à mesure que les NVidia et AMD apprennent comment l'optimiser... on verra bien.
"Je sers la science et c'est ma grande joie."  -Disciple-

[Image: sigimage.php?u=600217]
Répondre
#5
Quand le core CUDA va sortir, on sera plus à ces pouillèmes près ... Angel
Répondre
#6
(05-09-2020 11:30:29)toTOW a écrit : Quand le core CUDA va sortir, on sera plus à ces pouillèmes près ... Angel

Bonjour toTOW !

Tu peux nous en dire plus ?
(Qu'est-ce qui va sortir ? Quand? etc. )

Je précise que je ne sais que très vaguement ce qu'est le CUDA, autant dire que je ne connais pas ... Wink

Bonne journée ! Smile
Répondre
#7
Tiens, deux lectures pour comprendre le sujet :
https://fr.wikipedia.org/wiki/OpenCL
https://fr.wikipedia.org/wiki/Compute_Un...chitecture
Répondre
#8
(07-09-2020 19:22:32)toTOW a écrit : Tiens, deux lectures pour comprendre le sujet :
https://fr.wikipedia.org/wiki/OpenCL
https://fr.wikipedia.org/wiki/Compute_Un...chitecture

Merci toTOW

Je regarde ça demain ...

Ce soir Sleepy !

Smile
Répondre
#9
Je peux tenter une explication peut-être un peu plus digeste.

Historiquement, les unités de traitement GPU (la carte graphique) étaient cablées en "dur", autrement dit, imprimées dans le Silicium. Lorsque le programme principal (qui tourne lui sur le CPU) avait besoin d'envoyer quelque chose à l'écran, il devait tout calculer lui-même, sauf ce qui était mis à disposition par le GPU. Pour ça, il suffisait au programme d'envoyer les données "brutes" et les unités de traitement du GPU se chargeaient de les calculer.

En gros, la logique c'était : CPU (Programme maître + calculs) > GPU (seulement les calculs dédiés) > Ecran.

Mais, dès le départ, le GPU contenait plusieurs unités de calculs même quand les CPU n'avait qu'un seul cœur (voir même parfois un seul "thread"). Quand le CPU faisait une seule chose à la fois, le GPU pouvait déjà en faire plusieurs.

Alors bien sûr, c'était sans aucune souplesse, le GPU était (et est toujours) plus lent qu'un CPU mais en imaginant 80 unités de calcul qui puissent travailler en parallèle ... l'apport de ces GPU n'était pas anecdotique ...

Pratiquement, lorsque le CPU devait afficher 1000 triangles (les formes plus complexes en 3D sont réalisées à partir d'un maillage triangulaire), il envoyait le job de 1000 triangles et le GPU (s'il disposait par exemple de 80 unités) en traitait 80 à chaque passe, jusqu'à ce que le "pot" de 1000 soit vide.

On peut représenter cela par
CPU > Job1 (1000 tâches) > GPU > Ecran
GPU (1 à 80)
GPU (81 à 160)
GPU (161 à 240)
...
GPU (961 à 1000) (et oui, il y a 40 unités inutilisées dans ce cas. Evidemment, c'est seulement à ce stade que tout est envoyé à l'écran)

CPU > Job2 (450 tâches) > GPU > Ecran
GPU (1 à 80)
...

Dans un second temps, les GPU ont légèrement pu évoluer et accepter des paramètres. Même si c'est probablement un peu "didactique" comme approche, je m'en sers pour clarifier ce qui suit. La logique est toujours "CPU > GPU > Ecran" mais le programmeur pouvait quand même influer légèrement sur le comportement du GPU.

En gros, la logique d'une séquence était donc (je ne représente plus les passes par "80" mais évidemment elles sont le cœur du calcul) :
CPU > Param1 > GPU
CPU > Job1 > GPU > Ecran
CPU > Job2 > GPU > Ecran
CPU > Param2 > GPU
CPU > Job3 > GPU > Ecran

Donc tant que les paramètres n'étaient pas modifiés, tous les "jobs" utilisaient les précédents. Par contre les paramètres valaient pour toutes les unités de traitement des GPU. Pas question de dire tiens, ces 56 là travaillent avec un set de paramètres différents. Non, un seul set (à la fois) pour le GPU et donc toutes ses unités.

Et les constructeurs sont allés une étape plus loin, plutôt que de ne permettre que du paramétrage, ils ont carrément permis d'envoyer des programmes. Fini donc les limitations du câblage "en dur" et du simple paramétrage, non aujourd'hui il est possible d'utiliser les unités de traitement comme des minis-ordinateurs puisqu'on peut les programmer.

Je vais légèrement détailler la séquence en y introduisant le transfert de données et la compilation (transformation d'un programme lisible par l'humain en programme compréhensible par le GPU).

La logique c'est du coup complexifiée, une séquence devient donc :
CPU > Prog1 > GPU (+compilation1)
CPU > Data1 > GPU
CPU > Job1 > GPU > Ecran
CPU > Data2 > GPU
CPU > Job2 > GPU > Ecran
....
CPU > Prog2 > GPU (+compilation2)
CPU > Data8 > GPU
CPU > Job8 > GPU > Ecran

Les restrictions restent présentes, c'est à dire qu'un même "programme" s'applique à toutes les unités de traitement du GPU.

Mais ça, c'est juste ce que les amateurs d'images et de jeux vidéos utilisent, où est alors l'intérêt du GPGPU (nom qui regroupe CUDA et OpenCL) ?

L'intérêt est qu'il est possible de renvoyer les résultats du calcul au ... CPU ! Le GPU devient donc un "co"-processeur.

La séquence, vue des données devient donc :
CPU > Prog1 > GPU (+compilation1)
CPU > Data1 > GPU
CPU < Résultat1 < GPU
CPU > Prog2 > GPU (+compilation2)
CPU > Data2 > GPU
CPU < Résultat2 < GPU

Et c'est pourquoi, certaines cartes "graphiques" (GPU) n'ont même plus de sortie écran !

Ah oui, j'oubliais un "léger" détail. Il y a 5 ans, si les "bons" CPU étaient 6 coeurs (12 threads, soit 12 tâches en //), les "bonnes" cartes graphiques disposaient déjà de 1500 unités de traitement ... Aujourd'hui alors que les "bons" CPU ont vu leur nombre de tâches en parallèle passer à 20, les "bons" GPU ont 8000 unités de calculs. C'est quand même 400x plus. Donc à chaque "passe" 8000 données sont "moulinées" jusqu'à épuisement des tâches (parfois des millions, enfin tant que la mémoire du GPU est suffisante pour accueillir les données).

Alors, quelles sont les limites ?
- un GPU excelle dès qu'il y a de nombreux calculs répétitifs à effectuer.
- les données des tâches doivent être indépendantes. Le tâche 4351 n'a accès qu'aux jeu de données 4351. Il est par exemple tout à fait impossible de réaliser un "tri" ascendant ou descendant (sauf bien sûr si les données à trier sont dans le jeu 4351). Il est impossible de trouver la plus petite valeur parmi les 8000, ça c'est au CPU de s'en charger lorsque les résultats reviennent du GPU).
- Les 8000 unités sont "préchargées" avec le même "programme".

Et voilà !

Sethenès
Répondre
#10
Bonjour et merci Sethenès !   Smile

Tes explications sont très détaillées et très claires ! Super

Nouveau merci également à toTOW pour ses liens que je viens de lire.

Je vais me coucher moins ignorant ce soir !  Big Grin

Bonne journée à toutes et tous ! Smile
Répondre





Utilisateur(s) parcourant ce sujet : 1 visiteur(s)