Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 31 à 60 sur 61
  1. #31
    Citation Envoyé par Møgluglu Voir le message
    Les entrées-sorties.
    Avec des unités conventionnelles tu décomposes ton produit de matrice en produits scalaires, et tu calcules chaque produit scalaire avec une succession d'instructions FMA : c_ij = a_ik × b_kj + c_ij. Pour un produit de deux matrices n×n, ça te fait 3n^3 nombres à lire et n^3 nombres à écrire dans les registres, pour faire n^3 FMA.
    Avec une unité de produit de matrice dédiée, mettons 16×16, tu décomposes ta matrices en blocs. Pour chaque bloc, tu calcules le sous-produit C_ij = A_jk × B_kj + C_ij, dans lequel il y a 3×16^2 nombres à lire et 16^2 à écrire pour 16^3 FMA. Tu peux alors faire 20 fois plus de calculs pour une bande passante avec les registres donnée.
    Du mal à comprendre les calculs. Pour un produits de n*n utilisant cette instruction FMA on obtient bien pour chaque produit scalaire 3*n nombre à lire (car j'imagine qu'on parle de lire a_ik, bk_j et c_ij et ça fait n instruction d'accumulation) mais je n'arrive pas à voir en quoi c'est puissance 3. parce que sur une matrice n*n j’obtiens logiquement n*n produit scalaire et.............. ha merde en l'écrivant c'est bon, je suis débile 3n*n^2 = 3n^3

    Quelques question du coups :
    - pourquoi il n'est pas possible de gagner des opérations dans l'instruction FMA en lui donnant un registre dédié d'un nombre pour c_ij (pas via le pipeline général, tu le fout à coté), impossible ?
    - il n'y a pas du tout d'unité spécialisé 4*4 dans une CG ? Vu le nombre d'opération 4*4 pour le rendu on aurait pu s'attendre à ce que ce soit le cas non ?

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Ce n'est pas utilisé quand on travaille en double ou même en simple précision, car les registres SIMD ne sont pas assez larges pour permettre des sous-matrices de taille suffisante pour que le gain soit suffisant pour justifier d'ajouter des instructions (au mieux tu arrives à 4×4). Mais plus tu travailles sur des mots petits, plus tu gagnes. À l'extrême, le Cray 1 avait une instruction de produit de matrices de bits 64×64 (quelques processeurs modernes aussi).
    Qu'est ce qui n'est pas utilisé ? Le produit dédié ou le produit classique ?

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Ce n'est pas utilisé quand on travaille en double ou même en simple précision, car les registres SIMD ne sont pas assez larges pour permettre des sous-matrices de taille suffisante pour que le gain soit suffisant pour justifier d'ajouter des instructions (au mieux tu arrives à 4×4). Mais plus tu travailles sur des mots petits, plus tu gagnes. À l'extrême, le Cray 1 avait une instruction de produit de matrices de bits 64×64 (quelques processeurs modernes aussi).

    Je te rassure, il y a 9 ans tout le monde était déjà convaincu qu'il fallait calculer en simple ou double, quasiment personne ne parlait encore de deep learning sur GPU, et la question ne se posait pas.

    Pour être clair : les tensor cores n'ont pas de rapport avec le lancer de rayon, c'est prévu pour les réseaux de neurones convolutifs. Je le mentionnais juste comme unité spécialisée en général, pardon pour le hors sujet.
    Hoooo, ça n'a juste pas de rapport du coups
    Bon je suis toujours douteux sur les archis dédié à l’exécution de deep learning ou autre réseaux de neurones tant ça me semble ultra spécifique et plus basé sur de "futures application peut-être même si on ne sais pas exactement lesquelles" que sur la réalité de l'utilisation des GPU . En tout cas pour les GPU de joueur et autre grand public (en dehors des applis dédié ou on exécute en boucle un réseau de neurone, comme sur un appareil photo) et tant les utilisation plus fines des réseaux de neurones impliquent de toute manière de sortir du produits matriciel ou de travailler avec des matrices creuses. De là ou on en était resté avec le labo le soucis est encore actuellement au niveau du transfert entre la mémoire de la CG et la mémoire du CPU, ou c'est vraiment pas opti actuellement (donc ça limite le changement en directe des produits que tu veut réaliser si tu apprends en live).

  2. #32
    Citation Envoyé par Nilsou Voir le message
    - pourquoi il n'est pas possible de gagner des opérations dans l'instruction FMA en lui donnant un registre dédié d'un nombre pour c_ij (pas via le pipeline général, tu le fout à coté), impossible ?
    On peut, mais c'est une très mauvaise idée en général.
    Si tu ajoutes un registre au niveau micro-architectural, tu dois soit l'ajouter aussi à l'état architectural, soit avoir un mécanisme de renommage complexe pour désigner quel registre logique il représente. Si tu l'ajoutes à l'état architectural, il faut modifier le compilateur (pour allouer les variables dans ce registre) et l'OS (pour sauvegarder et restaurer le registre lors des basculements de contexte et exceptions).

    Essentiellement, tu crées une seconde FPU à part avec un banc de registres dédié d'un seul registre. Tu vas vite te rendre compte qu'avoir seul registre complique la sauvegarde, les appels de fonction et t'empêche d'exécuter des instructions indépendantes en parallèle, comme plusieurs produits scalaires à la fois. L'étape suivante est d'employer une pile de plusieurs registres, et à ce stade tu as réinventé x87.

    Et c'est une optimisation ad-hoc qui ne fonctionne que dans des cas très particuliers comme un seul produit scalaire dans une boucle bien propre. Dans le cas général le compilateur ne saura pas utiliser ce registre, parce que le code fait plusieurs produits scalaires en même temps, parce qu'il y a du contrôle un peu plus compliqué qu'un if-then-else, un appel de fonction, des pointeurs, de l'aliasing... Comme la vectorisation.

    Enfin, tu ne gagnes qu'un facteur constant en économisant les lectures-écritures des c_ij. Tu as toujours les 2n^3 lectures des a_ik et b_kj. Ça reste en O(n^3), alors que tu peux faire du O(n^2).

    - il n'y a pas du tout d'unité spécialisé 4*4 dans une CG ? Vu le nombre d'opération 4*4 pour le rendu on aurait pu s'attendre à ce que ce soit le cas non ?
    Il y a eu des opérations de type 4+4 : addition, multiplication terme à terme et produit scalaire de vecteurs de taille 4, chez Nvidia avant les GTX 8800 et chez AMD avant GCN.
    Par contre pas d'opération sur des matrices 4×4 : pour le rendu on ne fait quasiment jamais de produit de matrices, seulement des produits matrice-vecteur.

    Qu'est ce qui n'est pas utilisé ? Le produit dédié ou le produit classique ?
    Les opérations sur les matrices en double précision, pour autant que je sache.

    Bon je suis toujours douteux sur les archis dédié à l’exécution de deep learning ou autre réseaux de neurones tant ça me semble ultra spécifique et plus basé sur de "futures application peut-être même si on ne sais pas exactement lesquelles" que sur la réalité de l'utilisation des GPU .
    La réalité de l'utilisation des GPU, c'est aussi que Nvidia a fait 2 milliards de chiffre d'affaire sur le marché "datacenter" l'an dernier. Le "gaming" c'est 5 milliards. (https://s22.q4cdn.com/364334381/file...VIDIA-2018.pdf)
    S'ils ajoutent des fonctionnalités spécifiques au deep learning, c'est pour conserver et consolider leur position dominante. Et leurs concurrents font de même pour leur prendre des parts de marché. Ce n'est plus de la recherche, c'est du business.

  3. #33
    Citation Envoyé par Møgluglu Voir le message
    S'ils ajoutent des fonctionnalités spécifiques au deep learning, c'est pour conserver et consolider leur position dominante. Et leurs concurrents font de même pour leur prendre des parts de marché. Ce n'est plus de la recherche, c'est du business.
    This
    Mes propos n'engagent personne, même pas moi.

  4. #34
    Citation Envoyé par Møgluglu Voir le message
    La réalité de l'utilisation des GPU, c'est aussi que Nvidia a fait 2 milliards de chiffre d'affaire sur le marché "datacenter" l'an dernier. Le "gaming" c'est 5 milliards. (https://s22.q4cdn.com/364334381/file...VIDIA-2018.pdf)
    S'ils ajoutent des fonctionnalités spécifiques au deep learning, c'est pour conserver et consolider leur position dominante. Et leurs concurrents font de même pour leur prendre des parts de marché. Ce n'est plus de la recherche, c'est du business.
    On est bien d'accord. Mais du business sans débouché, c'est pas une bulle commerciale ?
    Parce que vu d’où je suis (labo de recherche dans le domaine) ça ressemble quand même énormeeeeeeeeeeeeement à une bulle commerciale. Nous ça nous inquiète un peu, parce que ça a déjà été le cas dans l'histoire de l'IA (à ses tout débuts, tout les indus s'était jeté dessus et on promettait le robot "humain qui fait le café et vous fait l'amour pour dans 5 ans", tout les 5 ans
    Alors évidemment quand la bulle a explosé c'est les chercheurs qui ont trinqué : plus personnes n'y croyais, plus de financement et pouf, un trou de 20 ans sans sous. Mon labo a d'ailleurs été en France l'un des rare à passer ce passage à vide en captant les financement du tout début des nouveau budget et en survivant via ses autres branches (électronique, radio, traitement d'image etc...).

    Maintenant l'autre question, c'est que ce soit une bulle ou non, ça aura principalement un intérêt pour les datacenter et cie... Comme nvidia a 2 Milliards la dedans, je les comprends, mais est-ce que ça a le moindre intérêt de le rajouter sur les cartes "gamer" du coups ?

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Il y a eu des opérations de type 4+4 : addition, multiplication terme à terme et produit scalaire de vecteurs de taille 4, chez Nvidia avant les GTX 8800 et chez AMD avant GCN.
    Par contre pas d'opération sur des matrices 4×4 : pour le rendu on ne fait quasiment jamais de produit de matrices, seulement des produits matrice-vecteur.
    Hum OK, mais du coups ... ils en ont plus (vu que tu emploie le passé)... et comme ils en ont plus ils inventent les tensors core ?
    Un pas en avant ... deux en arrière ?

  5. #35
    Citation Envoyé par Nilsou Voir le message
    Maintenant l'autre question, c'est que ce soit une bulle ou non, ça aura principalement un intérêt pour les datacenter et cie... Comme nvidia a 2 Milliards la dedans, je les comprends, mais est-ce que ça a le moindre intérêt de le rajouter sur les cartes "gamer" du coups ?
    C'est exactement ce que j'expliquais au-dessus : tu ne rajoutes rien, c'est deja la sur ton chip et tu ne vas pas fabriquer 50 masques (sauf a faire un chip vraiment plus petit) donc certaines features datacenter sont la. Du coup deux possibilites : rendre ces features inaccessibles (NVidia l'a fait dans le passe pour certaines features OpenGL, ou pour le calcul double precision) ; laisser ces features accessibles et inventer quelque chose de plus ou moins utile autour (il me semble que NVidia veut utiliser de l'AI pour faire du denoising dans les jeux).

  6. #36
    Citation Envoyé par Nilsou Voir le message
    On est bien d'accord. Mais du business sans débouché, c'est pas une bulle commerciale ?
    Je ne sais pas, j'ai renoncé à comprendre le modèle économique des fournisseurs de services Internet/mobile. Peut-être que demain les gens vont tous jeter leur smartphone et revendre leurs actions Google, Facebook, Twitter ou Amazon, mais même dans ce cas extrême une bulle aussi grosse mettra du temps à se dégonfler.

    Maintenant l'autre question, c'est que ce soit une bulle ou non, ça aura principalement un intérêt pour les datacenter et cie... Comme nvidia a 2 Milliards la dedans, je les comprends, mais est-ce que ça a le moindre intérêt de le rajouter sur les cartes "gamer" du coups ?
    A priori non, pas pour l'instant.

    Hum OK, mais du coups ... ils en ont plus (vu que tu emploie le passé)... et comme ils en ont plus ils inventent les tensors core ?
    Un pas en avant ... deux en arrière ?
    Non, on est passé de produit scalaire à produit de matrice.

    Citation Envoyé par newbie06 Voir le message
    C'est exactement ce que j'expliquais au-dessus : tu ne rajoutes rien, c'est deja la sur ton chip et tu ne vas pas fabriquer 50 masques (sauf a faire un chip vraiment plus petit) donc certaines features datacenter sont la. Du coup deux possibilites : rendre ces features inaccessibles (NVidia l'a fait dans le passe pour certaines features OpenGL, ou pour le calcul double precision) ; laisser ces features accessibles et inventer quelque chose de plus ou moins utile autour (il me semble que NVidia veut utiliser de l'AI pour faire du denoising dans les jeux).
    Oui mais c'est Nvidia, ils maintiennent 2 designs de SM, 5 ou 6 backends dans leur compilateur pour des jeux d'instructions différents et une dizaine de jeux de masques, dont un seul dédié au datacenter/HPC. Ils peuvent se permettre de choisir d'inclure ou pas les Tensor Cores dans leurs GPU gamers.

  7. #37
    Citation Envoyé par Møgluglu Voir le message
    A priori non, pas pour l'instant.
    Hoo, bon ben un core d'inutile pour nous alors

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Non, on est passé de produit scalaire à produit de matrice.
    Hum, bon certes.
    Bon j’admets, si c'est générique et facile à programmer. C'est super cool. Je m'incline.

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Oui mais c'est Nvidia, ils maintiennent 2 designs de SM, 5 ou 6 backends dans leur compilateur pour des jeux d'instructions différents et une dizaine de jeux de masques, dont un seul dédié au datacenter/HPC. Ils peuvent se permettre de choisir d'inclure ou pas les Tensor Cores dans leurs GPU gamers.
    Pas faux du tout ...

  8. #38
    Citation Envoyé par Møgluglu Voir le message
    Oui mais c'est Nvidia, ils maintiennent 2 designs de SM, 5 ou 6 backends dans leur compilateur pour des jeux d'instructions différents et une dizaine de jeux de masques, dont un seul dédié au datacenter/HPC. Ils peuvent se permettre de choisir d'inclure ou pas les Tensor Cores dans leurs GPU gamers.
    Soit. Cela nous laisse donc avec la possibilite que j'evoquais : NVIDIA estime qu'il y a de la valeur ajoutee pour le gaming.

  9. #39
    Citation Envoyé par newbie06 Voir le message
    Soit. Cela nous laisse donc avec la possibilite que j'evoquais : NVIDIA estime qu'il y a de la valeur ajoutee pour le gaming.
    En fait j'ai compris un truc très con en regardant d'affilé plusieurs vidéo de présentation de Nvidia sur le sujet. Les tensors core n'ont qu'une utilité au départ dans l'esprit de Nvidia : c'est faire tourner en temps réel leur algo de deep learning (enfin, leur filtre, car il n'apprends plus une fois en jeu) qui compense les défauts de leur unités de raytracing, qui ne peuvent fonctionner dans ce mode de sous-echantillonage sinon...

    Les tensors core sont donc nécessaire au tricks du filtrage par deep learning sans impacter le reste des perfs, tricks qui est lui même absolument indispensable pour justifier de la sortie sans attendre de l'architecture Turing (gamme RTX). Les tensors core ne sont donc pas un truc de ouf implémenté dans un but particulier qu'il faudrait découvrir, mais une unité indispensable à l'architecture actuelle pour que le reste de l'archi ait un intérêt... donc il est inutile de débattre sur ce que Nvidia veut faire des tensors cores ... il ne veut rien en faire de particulier, il est juste plus ou moins obligé de les foutre là ...

    Je suis trop con, c'était assez évident en fait


    Par contre, du coups, les tensors core ne sont pas conçu dans l'idée de développeurs allant coder leur IA dessus, en tout cas c'est pas tourné ainsi dans les présentations. Même si c'est probablement ainsi qu'ils vont le vendre ensuite. On peut aussi se poser la question de la viabilité à terme : Une fois que l'astuce du filtrage ne sera pas nécessaire lorsque les CG auront une puissance suffisante pour ne plus trop sous échantillonner ... on peut se demander quel sera alors l'utilité de conserver la gravure des tensors core... surtout si les devs n'ont pas sauté le pas et codé dessus des trucs essentiels ... ce qui n'est pas gagné du tout ...

  10. #40
    Oui, c'est ça. Pour le deep learning sur les GPU "gamer" ils présentent le débruitage comme application.

    Plus globalement c'est une stratégie où ils tentent de créer des marchés sur lesquels ils sont les seuls à avoir la techno. Ils lancent des idées régulièrement en espérant que ça deviennent une killer app. C'est comme leur appli de réalité virtuelle pour bébés robots, oh, ça alors il y a besoin de rendu 3D + deep learning en même temps et Nvidia sont les seuls à proposer les deux sur la même puce...

    Par contre le débruitage n'est pas une astuce, c'est une partie essentielle des moteurs de rendu par lancer de rayons modernes. Si tu as assez de puissance pour tracer une scène simple sans sous-échantilonner, alors tu vas vouloir tracer des scènes plus complexes en sous-échantillonnant. Les studios de films d'animation le font, et ils sont à ~1 FPH (frame per CPU-hour ). Avant qu'on arrive à simplement faire le même rendu en temps réel, il y a de la marge.

  11. #41
    Citation Envoyé par Møgluglu Voir le message
    Par contre le débruitage n'est pas une astuce, c'est une partie essentielle des moteurs de rendu par lancer de rayons modernes. Si tu as assez de puissance pour tracer une scène simple sans sous-échantilonner, alors tu vas vouloir tracer des scènes plus complexes en sous-échantillonnant. Les studios de films d'animation le font, et ils sont à ~1 FPH (frame per CPU-hour ). Avant qu'on arrive à simplement faire le même rendu en temps réel, il y a de la marge.
    C'est pas faux.
    N’empêche que le risque dans l'histoire c'est que cette partie de leur puce ne servent qu'a ça ! A tout jamais ^^
    Puisque rien ne dit que les programmeurs vont sauter sur ça pour leurs application d'IA. Faudrait déjà que les boites de jeu utilisent du "learning" en général et c'est tellement rare que c'est anecdotique, les compétences sur le sujets sont loin d’être là et tout les types de jeu ne se prêtent pas à l'exercice, loin de là. Je dirais même que les jeux qui se prêtent à l'exercice sont minoritaire, car déjà on parle de jeu non multi, non mmo, solo mais pas tout seul (donc exit les jeu type super meat boy) ce qui est aujourd'hui une frange ridicule du marché. Même dans les jeux solos nécessitant des IA, il restent que les réseaux de neurones s'appliquent plutôt aux IAs comportementales qu'aux IAs stratégiques (pour le moment) et que bien souvent une simple IA à test est suffisante pour ce que veut en faire le programmeur et donc ... qu'il ne reste plus beaucoup de jeu hormis les FPS solo et certains jeu de niche comme DF ou Rimworld...

    Et pourtant je fais de l'IA tout les jours, mais je ne parierais rien de rien sur le fait que ça deviennent suffisamment important dans le milieu du JV en général pour justifier de l'implémentation de puces physiques . Si on ajoute à tout ceci qu'une IA sympa doit pouvoir apprendre, donc que les matrices à multiplier changent sans cesse (ce qui implique des trucs assez lourd actuellement vu que le liens CPU/CG n'est pas super opti) on arrive à un résultat peu reluisant si on essai de prédire l'attrait des programmeurs pour ce type de puce vis à vis de l'IA.

    Reste la possibilité que le calcul matriciel soit détourné pour servir un autre but, genre les calcul physiques ou autres, pourquoi pas.

    Dans tout les cas l'un des soucis avec le bouzin c'est qu'au départ j'imagine que la taille de la puce implémenté interdira de faire ET du raytracing ET de l'exploiter pour autres choses. Ce qui n'encouragera pas non plus ce qui aurait envie de tester... ils préféreront bien souvent les graphismes à l’expérimental...

    Perso j'attends surtout qu'ils fassent du taf sur les liens entrant et sortant de la CG, pour le moment il me semblait que c'était le point le plus critique, bien plus que le temps d’exécution interne

  12. #42
    Citation Envoyé par Nilsou Voir le message
    N’empêche que le risque dans l'histoire c'est que cette partie de leur puce ne servent qu'a ça ! A tout jamais ^^
    C'est pas un risque ça, c'est un avantage compétitif. Surtout si AMD ne l'a pas.

    Tu as surement plein de CPU Intel qui n'ont jamais exécuté une instruction d'accélération AES ou de manipulation de chaîne, ou même des Athlon 64 qui n'ont jamais exécuté une instruction 64-bit de leur vie à l'époque de Windows XP. Et ma machine à laver n'a jamais fait d'essorage à 1200 tr/min... Ça ne choque plus personne depuis la révolution industrielle.

    Perso j'attends surtout qu'ils fassent du taf sur les liens entrant et sortant de la CG, pour le moment il me semblait que c'était le point le plus critique, bien plus que le temps d’exécution interne
    Le taf est fait, c'est les liens NVLink et la puce NVSwitch, comme dans la machine DGX-2 et les supercalculateurs à base de POWER 8 ou 9 + GPU (à commencer par Summit, 1er au Top500 cette année).
    Mais les tarifs (et Intel) s'assurent que ça reste réservé aux marchés datacenter et HPC.

  13. #43
    Citation Envoyé par Møgluglu Voir le message
    Le taf est fait, c'est les liens NVLink et la puce NVSwitch, comme dans la machine DGX-2 et les supercalculateurs à base de POWER 8 ou 9 + GPU (à commencer par Summit, 1er au Top500 cette année).
    Mais les tarifs (et Intel) s'assurent que ça reste réservé aux marchés datacenter et HPC.

  14. #44
    Le whitepaper de Turing :
    https://www.nvidia.com/content/dam/e...Whitepaper.pdf

    Plus de 80 pages, ça parle des RT cores et des Tensor cores mais pas que, le mesh shading a l'air intéressant aussi.

  15. #45
    C'est la premiere fois quils sortent un document aussi detaille / exhaustif non ?

  16. #46
    Citation Envoyé par Møgluglu Voir le message
    Le whitepaper de Turing :
    https://www.nvidia.com/content/dam/e...Whitepaper.pdf

    Plus de 80 pages, ça parle des RT cores et des Tensor cores mais pas que, le mesh shading a l'air intéressant aussi.
    Ha oui le mesh-shading ça a l'air d’être de la bonne.

    Sinon j'ai lu ça récemment lorsque je me suis intéressé au Sluttering, j'ai pas mal appris de truc. Mais je me demandais si du coups dans les prochaines archi Nvidia a prévu un moyens de récupérer le moment précis de l'affichage à l'écran pour en informer le jeu... ce qui mettrait à bas ce problème une fois pour toute. Surtout combiné au Gsync Freesync.

  17. #47
    Citation Envoyé par newbie06 Voir le message
    C'est la premiere fois quils sortent un document aussi detaille / exhaustif non ?
    Oui, les whitepapers précédents étaient beaucoup plus synthétiques et centrés sur le hardware. Celui-ci a l'air de reprendre le contenu de plusieurs présentations différentes au GTC.

    Citation Envoyé par Nilsou Voir le message
    Ha oui le mesh-shading ça a l'air d’être de la bonne.
    Ils viennent de donner plus de détails :
    https://devblogs.nvidia.com/introduc...-mesh-shaders/

    Sinon j'ai lu ça récemment lorsque je me suis intéressé au Sluttering, j'ai pas mal appris de truc. Mais je me demandais si du coups dans les prochaines archi Nvidia a prévu un moyens de récupérer le moment précis de l'affichage à l'écran pour en informer le jeu... ce qui mettrait à bas ce problème une fois pour toute. Surtout combiné au Gsync Freesync.
    J'ai rien compris. C'est pas censé être résolu depuis le double et triple buffering, sans même parler de Gsync ?

  18. #48
    Citation Envoyé par Møgluglu Voir le message
    J'ai rien compris. C'est pas censé être résolu depuis le double et triple buffering, sans même parler de Gsync ?
    Non ça c'est pour résoudre le tearing (la carte qui rafraîchit le buffer d'affichage pendant que l'écran dessine une frame = on voit des morceaux de deux frames en même temps).

    Là l'artice parle du fait que lorsque le GPU a fini son calcul envoie le rendu sur le buffer écran, le CPU na pas de feedback direct.
    Du coup le timing utilisé par le CPU est celui où le GPU a reçu les ordres de rendu pour toute la frame. Si il y a un écart entre le temps de rendu réel et celui de réception des commandes du GPU, le CPU "voit" un temps de calcul différent pour la frame, du coup la time frame estimée ne colle plus et donc la physique (vitesse de déplacement de la caméra par ex) calculée n'est plus correct. Comme en moyenne ça s'arrange quand même, on va avoir ponctuellement des mouvements trop lents puis trop rapides.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  19. #49
    Ah OK, merci, ça se tient. Fondamentalement, le problème est qu'on aurait besoin de connaître le temps de rendu d'une frame et donc le moment où elle s'affiche avant de commencer à la calculer, pas après, c'est ça ?

  20. #50
    Citation Envoyé par Møgluglu Voir le message
    Ah OK, merci, ça se tient. Fondamentalement, le problème est qu'on aurait besoin de connaître le temps de rendu d'une frame et donc le moment où elle s'affiche avant de commencer à la calculer, pas après, c'est ça ?
    Ah bah c'est sûr que a résoudrait tous les soucis de synchro.

    Mais bon ce n'est pas vraiment le soucis, le CPU va toujours faire ses calculs en décalage du GPU.

    C'est surtout qu'on a pas de feedback sur l'affichage des frames. On sait quand le GPU est prêt à recevoir les primitives de rendu de la prochaine frame, pour autant il n'a peut-être pas fini d'afficher voir même de rendre la frame précédente. Du coup on va mesurer un pseudo timeframe qui ne correspond pas à l'affichage des frames mais à la disponibilité de la queue de rendu. Et il peut arriver qu'on mesure une variance à ce niveau alors que la charge est uniforme et le temps de rendu régulier.
    Dernière modification par Lazyjoe ; 18/09/2018 à 00h49.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  21. #51
    Citation Envoyé par Møgluglu Voir le message
    Ils viennent de donner plus de détails :
    https://devblogs.nvidia.com/introduc...-mesh-shaders/
    Ça a l'air vraiment sympatoche, je lirais plus en détail demain, mais juste en parcourant il y a pas mal de potentiel.

    - - - Mise à jour - - -

    Citation Envoyé par Lazyjoe Voir le message
    Non ça c'est pour résoudre le tearing (la carte qui rafraîchit le buffer d'affichage pendant que l'écran dessine une frame = on voit des morceaux de deux frames en même temps).

    Là l'artice parle du fait que lorsque le GPU a fini son calcul envoie le rendu sur le buffer écran, le CPU na pas de feedback direct.
    Du coup le timing utilisé par le CPU est celui où le GPU a reçu les ordres de rendu pour toute la frame. Si il y a un écart entre le temps de rendu réel et celui de réception des commandes du GPU, le CPU "voit" un temps de calcul différent pour la frame, du coup la time frame estimée ne colle plus et donc la physique (vitesse de déplacement de la caméra par ex) calculée n'est plus correct. Comme en moyenne ça s'arrange quand même, on va avoir ponctuellement des mouvements trop lents puis trop rapides.
    Voila, et il semble que la majorité des saccades ressentit sur de bonne config sont due à ceci. Le phénomène semble aussi avoir pas mal empiré récemment, surement à cause des divers appli lié à l'OS et cie qui viennent jouer avec ce buffer et foutre encore un peu plus le boxon...

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Ah OK, merci, ça se tient. Fondamentalement, le problème est qu'on aurait besoin de connaître le temps de rendu d'une frame et donc le moment où elle s'affiche avant de commencer à la calculer, pas après, c'est ça ?
    Non c'est surtout qu'on voudrait avoir le temps d'affichage à l'écran. Même après. Là le truc c'est que le CPU n'a strictement aucune info sur la sortie de la CG, donc si la CG accélère puis décélère pour compenser, le CPU voit une "saccade" et génère une saccade via le moteur du jeu. (vitesse des objets et cie) alors que coté GPU tout va très bien et la saccade n'est jamais vraiment arrivé à l'écran. Résultat des courses, comme sur les schéma montré dans l'article : un 60hz propre sur l'écran mais un CPU qui a fait de la merde.
    La solution serait de pouvoir avoir l'indication du temps de sortie de frame du GPU vers l'écran, et que ce soit renvoyé vers le CPU. Ce qui améliorerais un peu tout. Et c'est, comme ce qu'ils ont montré dans l'article, immédiatement ce qu'on proposait les mecs de Vulkain comme implémentation. Reste qu'il va falloir attendre des CG compatible et ce n'est pas pour tout de suite.
    En plus en vrai, pour s'affranchir de tout problème il faudrait que ce soit l'écran qui envois le moment précis ou la frame est affiché à la toute fin. Avec les nouvelles électronique embarquées type gsync et cie, si ça se trouve l'écran en lui même introduit des variances maintenant.

    Comme le dit le mec dans l'article, c'est donc tout l'environnement du joueur qui doit changer, une solution complète au problème devant passer par quasiment toutes les étapes du matos... de l'écran à la CG en passant par les nouvelles implé de directX et Vulkain
    Pas prés de voir des jeux dénué de saccade pendant encore un bout de temps

  22. #52
    Il suffirait que le GPU fasse du rendu prédictif :
    - soit il prend l'option divination et izipizi c'est réglé
    - soit il calcule toutes les possibilités d'images suivantes et choisit la bonne au dernier moment

    Mes propos n'engagent personne, même pas moi.

  23. #53
    Citation Envoyé par Neo_13 Voir le message
    Il suffirait que le GPU fasse du rendu prédictif :
    - soit il prend l'option divination et izipizi c'est réglé
    - soit il calcule toutes les possibilités d'images suivantes et choisit la bonne au dernier moment

    Le turfu du deeplearning !
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  24. #54
    Haha, hier en quittant le topic j'ai pensé exactement à la même chose

    Le problème c'est qu'il faudrait faire l'affichage en directe sur l'ordi de la personne, et que comme on a pas accès à la sortie de la CG, la "vérité terrain" est inaccessible ... sauf à connecter une caméra qui regarde l'écran pour faire l'apprentissage, ce qui n'a rien d'impossible. Pour le faire généraliser ça risque d’être un peu difficile après

    Sinon plus sérieusement je crois qu'en interne la CG fait déjà une sorte de prédictif pour gérer le buffer, et que c'est une partie de la cause du soucis. Donc on va faire un modèle qui apprends leur modèle

    Par contre ça a l'avantage d’être réalisable et donnable via un "patch" à tout le monde, qui viendrais se substituer aux valeurs de temps du buffer pour toutes les applis.

  25. #55
    Citation Envoyé par Nilsou Voir le message
    Haha, hier en quittant le topic j'ai pensé exactement à la même chose

    Le problème c'est qu'il faudrait faire l'affichage en directe sur l'ordi de la personne, et que comme on a pas accès à la sortie de la CG, la "vérité terrain" est inaccessible ... sauf à connecter une caméra qui regarde l'écran pour faire l'apprentissage, ce qui n'a rien d'impossible. Pour le faire généraliser ça risque d’être un peu difficile après
    Ca fait un paquet d'années qu'on peut récupérer directement le buffer de rendu hein, c'est même la base de nombreuses techniques de rendu.

    Fin bon avec toutes les technos trucSync la carte graphique est tout à fait capable d'envoyer une info de timing très précise à un écran, il n'y a en soi aucune barrière matérielle qui empêcherait le CPU de récupérer cette même info.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  26. #56
    Sachant que dans le GPU et le driver graphique il y a tout un bazar qui tente aussi de prédire le volume de calcul de chaque frame pour adapter dynamiquement les fréquences d'horloge...

    Il est peut-être simplement temps de reconnaître que le rendu 3D est une appli temps réel, fut-il mou.

  27. #57
    Résumé des extensions Vulkan et OpenGL pour Turing, avec les liens :
    https://blog.icare3d.org/2018/09/nvi...xtensions.html

  28. #58
    Citation Envoyé par Lazyjoe Voir le message
    Ca fait un paquet d'années qu'on peut récupérer directement le buffer de rendu hein, c'est même la base de nombreuses techniques de rendu.

    Fin bon avec toutes les technos trucSync la carte graphique est tout à fait capable d'envoyer une info de timing très précise à un écran, il n'y a en soi aucune barrière matérielle qui empêcherait le CPU de récupérer cette même info.
    Pas compris, le truc de l'article c'est qu'on ne peut pas recup la sortie précise du buffer. Et c'est le soucis. L'article est récent donc je pense que c'est encore valable. Et si tu veut cette vérité terrain, ben hormis cam externe c'est la lose.
    Oui il n'y a théoriquement pas de barrière matériel, mais c'est tout de même le bordel en théorie. Et les truc sync n'aide pas du tout du tout, au contraire.
    Si on fait le cheminement d'un rendu écran gsync :

    -> envoie des commandes de mise dans la file du buffer par l'OS.
    -> la commande fait sa vie, potentiellement chaotique, potentiellement parfaitement stable, dans le buffer de la CG.
    -> La CG envoie la commande à l'écran et dis à l'écran "affiche toi maintenant"
    -> la commande arrive dans la puce embarqué Gsync blabla puis passe par toute la logique supplémentaire d'affichage de l'écran. (petite latence probable en plus)

    Alors certes l'écran a surement moyens de savoir quand il change pile poil d'image, mais d’abord, c'est même pas dit que ce soit implémenté matériellement, c'est peut-être encore un "sous-entendu" (comme j'envoie la commande ça va bien finir par s'afficher).
    Et même si ça l'est, ou même si tu suppose l'écran parfait et que tu récupère la date de la commande envoyé au dernier stage d'affichage, bah il faut que l'écran renvoie cette info spécifiquement et très rapidement à la CG.
    Théoriquement rien ne l’empêche, mais il est possible que dans tout ça un changement de logique interne aux écrans, ou un câblage physique qu'il n'avais pas imaginé, soit nécessaire. Donc nouvel écran et à priori il faudra la CG compatible avec les version de Vulkain et cie qui va bien et qui implémente ça. Donc nouvelle CG. Et la version de vulkain et la version des drivers qui va bien etc...

    Donc en fait c'est bien comme le suppose l'article à la fin ... c'est une "petite modif" et débile à faire, mais c'est bien toute la chaine qu'il faut changer

    Ajoutons à la difficulté que l'info de l'écran doit dire, dans le langage de la CG, quel frame vient d’être rendu ... donc ce n'est pas qu'un timing à passer, il faut probablement aussi passer un genre d'ID de la frame à l'écran et qu'il la renvoie avec la date de l'affichage une fois l'affichage fait.

    En tout cas pour le moment aucun moyens d'avoir l'info via le GPU :
    Probably not. Usually, measuring GPU time is suggested as an alternative to display timing. But that doesn’t take into account presence of the compositor and the fact that none of the GPU rendering timers actually synchronize directly with the display refresh. What we need for perfect animation is definitely time when image was shown, not time when it finished rendering.
    Citation Envoyé par Møgluglu Voir le message
    Sachant que dans le GPU et le driver graphique il y a tout un bazar qui tente aussi de prédire le volume de calcul de chaque frame pour adapter dynamiquement les fréquences d'horloge...

    Il est peut-être simplement temps de reconnaître que le rendu 3D est une appli temps réel, fut-il mou.
    C'est pas l'inverse du coups ?
    De reconnaitre que ce n'est pas du tout temps réel, que c'est totalement asynchrone et qu'on doit faire avec ?

    - - - Mise à jour - - -

    Citation Envoyé par Møgluglu Voir le message
    Résumé des extensions Vulkan et OpenGL pour Turing, avec les liens :
    https://blog.icare3d.org/2018/09/nvi...xtensions.html
    Arf et le fameux VK_GOOGLE_display_timing dont l'article que je citait sur les saccade citait comme la fameuse solution qui résoudrait tout.
    Aucune chance de l'avoir sur Turing ?
    Pour l'instant l'article dit ceci :
    Worry not, it’s not all that grim. Many people in the graphics ecosystem are currently busily working on implementing support for proper frame timing, under various names for different APIs. Vulkan API already has an extension called VK_GOOGLE_display_timing which was shown useful in a proof of concept implementation, but it is available only for a limited range of hardware and mostly on Android and Linux.
    En tout cas, et c'est la bonne solution, il semble avoir résolu le problème en implémentant des astuces sur les noyaux linux récent. Même si je ne sais pas du tout comment ils s'y sont pris. Quant aux hardware, ça semble limité mais sans plus de précision.

    edit : les slides de la conf qui a emmené à certaines solutions, un peu plus de précision, en tout cas les preuves de concepts ont été faites sur Talos Principle et semblent fonctionner nickel :
    https://twvideo01.ubm-us.net/o1/vaul...rameTiming.pdf

  29. #59
    Citation Envoyé par Nilsou Voir le message
    C'est pas l'inverse du coups ?
    De reconnaitre que ce n'est pas du tout temps réel, que c'est totalement asynchrone et qu'on doit faire avec ?
    Les API actuelles ne sont pas du tout adaptées au temps réel, mais dans l'absolu elles devraient.

    Le rendu graphique répond exactement à la définition d'un problème temps réel :
    - Si le rendu est trop lent et que tu rates la VSync, c'est pas bon. En général, tu es prêt à perdre en qualité de rendu pour conserver la fluidité : le timing est plus important que la précision.
    - Si le rendu est plus rapide que prévu, ça ne t'apporte rien de plus, et pire, ça cause ces problèmes de stuttering.

    Idéalement, ce qu'on voudrait, c'est fixer le temps de rendu arbitrairement, et utiliser la qualité du rendu comme variable d'ajustement. Le pipeline de rendu actuel fait tout le contraire et n'est pas adapté pour ça, mais avec du lancer de rayon Monte-Carlo + débruitage, il y a moyen.

  30. #60
    Citation Envoyé par Nilsou Voir le message
    Pas compris, le truc de l'article c'est qu'on ne peut pas recup la sortie précise du buffer. Et c'est le soucis. L'article est récent donc je pense que c'est encore valable. Et si tu veut cette vérité terrain, ben hormis cam externe c'est la lose.
    Petite nuance mais importante ici. Le problème n'est pas la sortie du buffer, mais la sortie sur l'affichage, c'est à dire le moment où le GPU envoie le buffer de rendu sur l'écran. Effectivement on n'a rien pour mesurer cette sortie et il faudrait filmer l'écran pour lavoir exactement. Mais le buffer en lui-même pas de soucis c'est par exemple la base des effets miroir on fait le rendu en plaçant la caméra derrière le miroir, on récupère le buffer de rendu dans une texture on plaque cette texture dans le rendu final. Le buffer du deuxième rendu est envoyé à l'écran, le premier ne le sera jamais.

    Physiquement c'est bien le GPU qui fait cet envoi en plaçant ses petits pixels sur la sortie HDMI, c'est bien lui qui a le dernier mot. Le problème c'est qu'entre l'étage rendu et l'étage affichage, il y a plein de monde qui peut venir perturber les choses (OS qui ne rend pas la main au driver, windows manager qui veut afficher autre chose...).

    Après il y aura une latence dûe au matériel c'est sûr, je ne sais pas si elle n'est pas néglageable mais sur un setup métariel donné (GPU/câble/écran) elle sera fixe donc on fait avec et on a toujours fait dans tous les systèmes même quand on peut assurer un rendu régulier). Bon je m'avance peut-être pour les écran trucSync il y a peut-être une variabilité sensible quand la fréquence d'affichage varie ?
    Dernière modification par Lazyjoe ; 21/09/2018 à 13h30.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •