Journal Rendu 3D logiciel

Posté par  .
Étiquettes :
15
13
déc.
2011

Je me souviens d'un temps, ou le mixage audio était réalisé par le hardware, car c'était une opération couteuse.
Aujourd'hui le mixage est fait pas le logiciel et les cartes sons, ne sont presque plus que des entrées/sorties jack avec un contrôleur basique.

Grâce à Gallium 3D LLVMpipe, on commence à avoir un rendu 3D logiciel potable sur certains processeurs multi-coeurs.

Évidement, pour le moment, même une carte à 30€ arrive à battre les performances de ce rendu logiciel. Mais j'ai quand même l'impression que d'ici deux ou trois ans, ces processeurs haut de gamme seront plus démocratisés et par la même la question d'avoir besoin d'une carte graphique au lieu d'un simple contrôleur VGA/DVI/HDMI pourrait se poser à un plus grand nombre.

On annonce d'ailleurs que Gnome Shell, Compiz ou encore KWin fonctionnent avec LLVMpipe, ce qui fait que les desktops GNU/Linux pourront profiter de la composition, de Wayland, sans avoir besoin d'une grosse carte graphique.

Je trouve que c'est une bonne nouvelle pour le libre. En effet, nous sommes confrontés à des constructeurs qui ne fournissent pas les specs de leurs cartes graphiques, et le cas échéant, ne fournissent souvent pas de driver libre.
Avec un driver logiciel, les effort d'optimisations peuvent être cumulés car les processeurs ont tous des specs ouvertes par principe, et il est inutile de refaire un driver pour chaque CPU, le compilateur s'en occupe.
J'espère donc que l'on va assister à la mort des cartes graphiques, pour le grand publique tout du moins, avec la montée du nombre de coeurs dans les prochaines générations de processeurs.

  • # mouais

    Posté par  (site web personnel) . Évalué à 10.

    En fait c'est exactement l'inverse qui se produit : les GPU se "généralisent" pour effectuer des tâches sans rapport direct avec l'affichage vidéo.
    Sans parler des unités spécialisées dans le décodage des flux MPEG & Co.
    Sur les devices mobiles, le GPU est la pièce maîtresse sans laquelle les IHMs rament, les vidéos ne peuvent être décodées en full HD, bref, le GPU est de plus en plus incontournable.

    Ce que tu présentes, est juste la démonstration de l'énorme avance des GPU en terme de puissance de calcul spécialisée et parallélisée.

    • [^] # Re: mouais

      Posté par  (site web personnel) . Évalué à 8.

      Ce qu'on voit c'est deux choses :

      • les CPU continuent à voir leurs performances augmenter de manière importante et leur exploitation également (par exemple ici au travers de LLVM)
      • les GPU deviennent aussi des GPGPU et commencent à équiper de nombreux serveurs (par exemple avec du Nvidia Tesla 512 core)

      Ce qui est intéressant c'est qu'on se met à utiliser l'architecture des GPU pour faire du calcul et qu'on se met à utiliser les bon vieux x68(-64) pour faire du graphique. Maintenant, peut-être un jour une solution plus uniforme (un super ensemble comportant les deux ?)

      • [^] # Re: mouais

        Posté par  . Évalué à 1.

        Je pense que ce que tu veux dire par "plus uniforme", c'est du point de vue de la vectorisation?

        En fait, les GPU sont essentiellement vectoriels (>= 32 opérations identiques simultanées sur des float), et les CPU moins (AVX: 8 opérations sur des floats, 4 avec les SSE*). Bien sûr, ces chiffres ont plutôt tendance à augmenter avec le temps, ce qui peut (peut-être) amener à une uniformisation.

        Sans vouloir troller, pour le code général, je pense que si les gens écrivaient du code mieux vectorisable par le compilateur, on gagnerait déjà pas avant de devoir utiliser quelque chose comme CUDA. Notamment en évitant les if dans les boucles, et en utilisant le mot clé restrict (__restrict__ en C++) lorsque c'est approprié.

        • [^] # Re: mouais

          Posté par  (site web personnel) . Évalué à 4.

          Je pense que ce que tu veux dire par "plus uniforme", c'est du point de vue de la vectorisation?

          Ce que je veux dire c'est cpu-gpu en un seul composant (façon de parler) et pas un cpu + un gpu à côté. Il y aura toujours du matos spécifique, mais je pense que les puissances actuelles permettent d'avoir d'assez bon composants embarqués contrairement à il n'y a pas si longtemps.

          Pour la deuxième partie, totalement d'accord. D'ailleurs on commence malgré tout à voir les problèmes arriver. La plupart des ordinateurs ont 2 ou 4 cores, parfois hyperthreadés et pourtant on continue a écrire des applications qui ne tournent que sur un core (peu parallèles quoi).

          • [^] # Re: mouais

            Posté par  (site web personnel) . Évalué à 2.

            En gros, tu veux Larrabee, 80 x86 de type atom mais avec un jeu d'instruction SIMD de 512 bits. Je pense aussi que c'est l'avenir : les gpu sont trop complexes, ont trop de variation entre eux (il faut recoder pour chaque gpu ou presque). A moins qu'un des 2 constructeurs proposent un vrai compilo llvm pour leur shader et que du code shader complexe puisse vivre plusieurs années dans un logiciel.

            "La première sécurité est la liberté"

          • [^] # Re: mouais

            Posté par  (site web personnel) . Évalué à 3.

            Il me semble que c'est ce vers quoi tend AMD avec "Fusion" :
            http://www.amd.com/us/products/technologies/fusion/Pages/fusion.aspx

            En gros, ils mettent un GPU et un CPU sur un même chip et partagent un certain nombre de composants partageables. C'est intéressant comme approche. Je me demande si Intel fait la même chose avec les cartes graphiques de ses i3/i5/i7 ?

          • [^] # Re: mouais

            Posté par  (site web personnel) . Évalué à 2.

            Cela changera peut-être avec AVX d'intel ? Je crois qu'il veulent enfin vectoriser les load.

            Pour avoir voulu vectoriser un pauvre filtre 2D d'image, je me suis rendu compte que la nécessité d'avoir les accès mémoires alignés, est une très très forte contrainte quand on traite des tableaux 2D. Je comprends pourquoi Altivec était tellement plus efficace, lui qui n'avait pas cette contrainte.

            "La première sécurité est la liberté"

            • [^] # Re: mouais

              Posté par  (site web personnel) . Évalué à 2.

              altivec a les mêmes contraintes d'alignement sur les load et les store que SSE, et il n'a même pas d'instructions non-alignées comme les movups de SSE. Par contre le shuffle de altivec est autrement plus puissant que celui de sse.

          • [^] # Re: mouais

            Posté par  . Évalué à 5.

            Ça s'appelle le Cell.

            BeOS le faisait il y a 20 ans !

    • [^] # Re: mouais

      Posté par  . Évalué à 4.

      On a plutôt deux mouvances :

      • Les GPU empiètent sur le terrain de CPU avec le GPU computing.
      • Les CPU empiètent sur le terrain des GPU avec la multiplication des core dans un même die.

      Je pense au contraire que l'on va assister à une sorte de fusion des deux, et le modèle hautement programmable des CPU seront plus avantageux que celui des GPU, ne serait-ce que pour leurs jeux d'instructions ouvert.
      Cependant, les CPU risquent de lâcher quelques fonctionnalités, comme la cohérence des caches qui bouffent toute la place des coeurs actuels. A mon avis, le modèle actuel ne tiendra pas très longtemps avec la multiplication des Coeurs.

      • [^] # Re: mouais

        Posté par  . Évalué à 2.

        Sur x86 il y a zéro chance que le modèle mémoire "de base" soit relâché (rétrocompatibilité, toussa), même s'il serait tout à fait envisageable de requérir explicitement un modèle mémoire plus laxiste (c'est déjà possible principalement pour pouvoir faire de l'IO et des frames buffer pas trop moisis). Néanmoins étant donné que le modèle de base doit survivre, la place prise sur le die pour l'implémenter restera...

        Sur ARM je sais pas trop, je connais pas assez (et en plus il n'y a pas de plateforme ARM équivalente à la plateforme PC, même si l'arrivée de windows 8 va probablement changer fortement la donne sur ce point)

        • [^] # Re: mouais

          Posté par  (site web personnel) . Évalué à 3.

          Il manque pas tant de chose que cela au cpu pour jouer au gpu en fait. Il faut créer des load/store un peu plus complexe pour faire de l'adressage multidimensionnel en un seul cycle, qui peut avoir une absence de cohérence, les barrières devenant explicites. Ensuite, il faut une série d'alu lié pourquoi pas à des instructions haut niveau (manipulation de matrice vecteur) et surtout il faut un énorme paquet de registres ( 128 000 de mémoires dans un bloc nvidia). Ces registres peuvent être lié au load/store special (genre load de la taille du registre mais lecture partiel possible si les registres sont SIMD).

          "La première sécurité est la liberté"

          • [^] # Re: mouais

            Posté par  . Évalué à 2.

            Même si je connais pas trop ça m'a l'air de ressembler pas mal à un Cell toussa. Pour ressembler à une CG moderne il faudrait pas aussi un moyen d'augmenter massivement le parallélisme des ALU ? Et peut-être d'avoir des modèles comme le SIMT (vrai questions je ne connais pas assez le milieu pour savoir si c'est toujours à l'ordre du jour)

            Le problème c'est qu'à programmer sans moulinette magique qui te mâche le boulot, c'est chiant (les développeurs de jeux vidéos sur PS3 semblent majoritairement de cet avis). On y arrivera sans doute mieux depuis l'écosystème PC (les drivers de CG, CUDA et autre semblant faire office de moulinette magique acceptable) que depuis ce que Sony avait proposé aux développeurs, mais reste à voir quel ouverture va avoir un tel écosystème. Si on reste dans l'état présent où les meilleurs moulinettes sont propriétaires et celles libres sont au mieux moyen-moins (et que sur du matos lui même moyen-moins) c'est mal barré.

            Reste aussi que pour les x86 ça ne fera pas disparaître la taille prise sur le die par la cohérence de cache pour le jeu d'instruction x86 généraliste. (Mais en fait je ne sais pas quelle proportion ça représente, donc si ça se trouve OSEF)

            • [^] # Re: mouais

              Posté par  (site web personnel) . Évalué à 2.

              Un cell est simplement un dsp flottant qui exécutent 2 instructions en même temps, sur des registres SIMD. La particularité est de ne pas avoir de cache mais d'utiliser uniquement de la mémoire locale. C'est très rapide, mais très chiant à utiliser. Il faut utiliser un gros DMA pour transférer la mémoire depuis et vers la DRAM externe. Il serait sans doute possible d'automatiser tout cela avec un compilo opencl, mais je ne crois pas que cela existe.

              Par rapport au GPU, il n'y a pas d'absence de cohérence de mémoire, il n'y a pas d'accès mémoires complexe, ni de lecture de type de données compliqué (genre éclater un vecteur RGB, ou une texture compressé).

              Concernant la cohérence de cache, je ne pense pas que cela soit gros, mais cela fait perdre des cyclee d'horloge sur les accès.

              "La première sécurité est la liberté"

              • [^] # Re: mouais

                Posté par  . Évalué à 2.

                Ça fait perdre des cycles d'horloge mais pour les logiciels généralistes plus de cohérence dans le CPU rend souvent la programmation moins complexe (1), au prix d'une perte de performance négligeable devant d'autres facteurs. Et les instructions non cohérentes sont déjà là ci vraiment on a besoin d'optimiser.

                (1): D'ailleurs la complexité est un des facteurs qui doit être le plus évité pour les systèmes critiques ou semi-critiques. Par exemple certains PPC de Freescale sont in-order explicitement pour limiter la complexité du processeur ainsi que la variabilité des temps d'exécution des programmes de manière à ce que les tests des systèmes aient encore plus de chance d'être représentatif des cas d'utilisation réels qui seront rencontrés -- mais bon là on s'écarte de la volonté d'optimiser les performances.

                • [^] # Re: mouais

                  Posté par  (site web personnel) . Évalué à 2.

                  C'est vrai pour le calcul généraliste mais pas pour le calcul bourrin. D'ailleurs ton (1), marche si on accepte de ne jamais faire de modification en place. On lit une grande quantité de donné, pour créer une autre quantité de donné réutilisé dans la passe suivante. Chaque passe n'a pas le droit d'utiliser, les donnés générées par la passe, à un autre moment.

                  Concernant les PPC, tu parles des quicklogic ? Il me semble qu'il utilise des coeurs ppc classique, genre 603e ou e300.

                  "La première sécurité est la liberté"

  • # tester / débugger

    Posté par  . Évalué à 8.

    LLVMPIPE qui fournit un driver 3D purement logiciel, est surtout prévu pour tester et débugger des applis 3D ou des fonctionnalités de Mesa, car il contient des fonctionnalités intéressantes à ce niveau la.

    Effectivement ça peut fournir l'accélération 3D suffisante pour Compiz par exemple si ont à une carte graphique sans driver matériel disponible.

    Comme on peut le voir sur le benchmark de phoronix, 30fps sur open arena, on est quand même vachement loin d'un truc utilisable "in-game". Surtout qu'open arena utilise presque uniquement la rasterization et pas de shaders (ou très peu ?). Même si ils sont supportés par llvmpipe ils n'ont aucune chance d'être compétitif avec une carte graphique me très bas de gamme. Et les shaders c'est quand même le coeur d'une carte graphique actuelle...

  • # Pas sûr qu'il y ai un remplacement

    Posté par  . Évalué à 6.

    Les CPU ont une bande passante mémoire ridicule par rapport aux "GPU monolithiques", ce qui change pas mal de choses..
    Après il est possible que ça change en empilant la mémoire sur le CPU par exemple, ou bien la façon de faire le rendu pour économiser la bande passante (tile based rendering par exemple) mais ça ne marche que pour des nouveau jeux, en attendant ces changements (s'ils arrivent un jours), le rendu sur les CPUs sera toujours faibles

    • [^] # Re: Pas sûr qu'il y ai un remplacement

      Posté par  (site web personnel) . Évalué à 2.

      tu oublis que les cpu ont des caches moins "statique" que les gpu. La bande passante manquante peut aussi se compenser de cette façon.

      "La première sécurité est la liberté"

      • [^] # Re: Pas sûr qu'il y ai un remplacement

        Posté par  . Évalué à 3.

        Pas faux, mais les GPU ont aussi des niveaux de caches, donc pas sûr que le cache des CPU suffise a compenser l'écart.

        • [^] # Re: Pas sûr qu'il y ai un remplacement

          Posté par  (site web personnel) . Évalué à 2.

          Oui les caches de textures, mais c'est beaucoup plus rigide que ce qui est possible de faire avec un cpu.

          "La première sécurité est la liberté"

          • [^] # Re: Pas sûr qu'il y ai un remplacement

            Posté par  . Évalué à 2.

            Il me semble qu'il n'y a pas que le cache des textures: les registres sont plus ou moins rapide suivant leur nombre.
            Je ne vois pas vraiment quel fonctionnalités d'un cache sur un CPU ne pourrait pas être dupliquée sur un cache mis dans un GPU, tu pense à quoi?

            • [^] # Re: Pas sûr qu'il y ai un remplacement

              Posté par  (site web personnel) . Évalué à 2.

              Je pense à l'exemple donné par les EFL sous un chip Samsung dont le code était plus rapide en pure SW qu'en utilisant le GPU, la bande passante mémoire était partagé. La différence était que le code était plus "fin" en cpu, et cela économisait des accès. Mais je suis d'accord l'exemple est un peu spécial (bus partagé) et les shaders deviennent de plus en plus des cpu, il ne restera plus que la quasi-absence de cohérence mémoire.

              "La première sécurité est la liberté"

            • [^] # Re: Pas sûr qu'il y ai un remplacement

              Posté par  . Évalué à 1.

              Il me semble qu'il n'y a pas que le cache des textures.

              Effectivement, pas de cache de textures en tant que tel.

              Je ne vois pas vraiment quel fonctionnalités d'un cache sur un CPU ne pourrait pas être dupliquée sur un cache mis dans un GPU, tu pense à quoi?

              (Si je ne dis pas de bêtises, la il faudrait un expert) Certains GPU utilisent en plus de leur nombres hallucinant de registres de petits caches (~64kio), équivalent à ceux des L1 sur CPU, mais partagés entre "cluster" d'unités de shaders, et une sorte de cache L2 partagé entre ces clusters (pas directement avec les unités qui les composent). Ils peuvent êtres utilisés pour mettre des textures (au sens plage mémoire) en cache.

              Et tous ça reste super dépendant du modèle de GPU que l'on prends comme exemple.

              Après par exemple un "gros" cache L3 partagé entre tous les coeurs / thread (de 1 à 8 on va dire) d'un CPU n'aura pas sa place dans un GPU, car cela voudrai dire le partager entre 40 et 500 unités de shaders. Dur dur niveau cohérence on en reviens la. Mettre des caches par unités de shader n'est pas possible non plus, ça prendrait une place monstrueuse sur des puces déjà monstrueuses...

              Mais je suis d'accord l'exemple est un peu spécial (bus partagé) et les shaders deviennent de plus en plus des cpu, il ne restera plus que la quasi-absence de cohérence mémoire.

              Une différence qui semble perdurer c'est quand même que les shaders sont mauvais sur tous ce qui n'est pas du calcul vectoriel. Ou alors qu'on aura du mal a avoir des gains si on les utilisent pour faire du logique ou de l'entier. Partant de la, peut on les considérer comme se rapprochant des CPU ?

              • [^] # Re: Pas sûr qu'il y ai un remplacement

                Posté par  (site web personnel) . Évalué à 2.

                Une différence qui semble perdurer c'est quand même que les shaders sont mauvais sur tous ce qui n'est pas du calcul vectoriel.

                Cest un peu passé; C'est fini les shader complètement vectoriels. Il me semble que ATI ne gère que 2 éléments à la fois, et nvidia est scalaire. Les codes des shaders utilisent des vecteurs de taille 1 à 4. Avec du simd, les taux d'utilisation des fpu seraient trop faibles.

                "La première sécurité est la liberté"

                • [^] # Re: Pas sûr qu'il y ai un remplacement

                  Posté par  . Évalué à 1.

                  Oui alors un peu passé seulement comme tu dis ^^

                  Il est maintenant possible de faire des calculs logiques sur des cartes dernières génération (avant pas possible), au prix de 25% d'utilisation d'une unité seulement, même 20% sur les ATI VLIW.
                  Il est possible par contre (la encore, sa doit vachement dépendre du modèle/marque de carte) de faire simultanément un calcul sur un entier 32bits et un calcul sur un vecteur de 3 flottants pour garder une utilisation maximale de l'unité (si les deux opérations ne sont pas interdépendantes bien sur, ce qui doit souvent être le cas quand on travail pas en 100% vectoriel).
                  Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.

                  • [^] # Re: Pas sûr qu'il y ai un remplacement

                    Posté par  (site web personnel) . Évalué à 2.

                    Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.

                    Pour moi, c'est le problème principal. On a vraiment l'habotude d'avoir le même genre de performance entre un modèle amd et un modèle Intel. C'est rare d'avoir un bench 50% plus rapide pour un processeur et 50% plus lent sur un autre bench.

                    Le compilateur opencl fait au mieux, mais selon les contraintes internes par rapport au code, les performances ne seront pas du tout les mêmes, ce qui demande un gros boulot d'optimisation pour les jeux. De mémoire, ati gère les flottant 16 bits et pas nvidia, sur un code qui n'a pas besoin de mieux, il sera 2x plus rapide qu'un code utilisant du 32 bits classique. C'est pareil, si le hardware interne gère des vecteurs de taille 2, sur une machine ayant une telle largeur, l'efficacité sera plus grande que sur un gpu scalaire.

                    Je sais qu'augmenter de manière énorme le nombre de registre augmente le temps de changement de tâche. Mais si il s'agit d'un banc de registres spécial, peut être que l'ancienne astuce, de sauver/restaurer le registre uniquement sur demande peut être appliqué.

                    Il faudrait un banc de registre par exemple 1 000 registres 256 bits. On pourrait faire des lecture mémoire de 256 à 8 bits, et ensuite faire des transferts de la taille que l'on veut vers les registres classiques. Si le core "out of order" est bien fait, il pourrait détecter ces transferts entre registres et seulement faire un "alias".

                    Avoir autant de registre peut permettre d'éviter un gros besoin de transfert vers la mémoire forcément plus lent que le cpu.

                    "La première sécurité est la liberté"

  • # Pas compris…

    Posté par  (site web personnel) . Évalué à -2.

    Je me souviens d'un temps, ou le mixage audio était réalisé par le hardware, car c'était une opération couteuse.
    Aujourd'hui le mixage est fait pas le logiciel et les cartes sons, ne sont presque plus que des entrées/sorties jack avec un contrôleur basique.

    Désolé d'avance, mais je ne comprends ni la phrase, ni le rapport avec le reste du journal…

    Debug the Web together.

    • [^] # Re: Pas compris…

      Posté par  (site web personnel) . Évalué à 5.

      les cartes son ont perdu en fonctionnalité (mixage en hard) car ça n'avait plus aucun interet de faire cette operation sur la carte son, le coût de cette opération étant epsilonesque pour un cpu moderne. Il se demande si le même phénomene ne va pas un jour rendre les GPUs obsoletes.

    • [^] # Re: Pas compris…

      Posté par  (site web personnel) . Évalué à -3. Dernière modification le 13 décembre 2011 à 18:17.

      Désolé d'avance, mais je ne comprends ni la phrase, ni le rapport avec le reste du journal…

      Ah là là ! Mais t'as du mal toi -_-'
      Faut lire la phrase comme ça :

      Je me souviens d'un temps où le mixage audio était réalisé par le hardware, car c'était une opération coûteuse.
      Aujourd'hui le mixage est fait par le logiciel, et les cartes sons ne sont presque plus que des entrées/sorties jack avec un contrôleur basique.

      T'es content, maintenant ?
      Quoi ? Oui, je sais, on fait encore principalement du mixage console… mais ferme-la, tu nous énerve !

      Debug the Web together.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.