Journal Enfin l'accélération du décodage vidéo par la carte graphique sous linux !

Posté par  (site web personnel) .
Étiquettes :
30
14
juil.
2011

Site au message de Christian König (un des nouveaux développeurs AMD sur les pilotes Libres) sur la mailing list mesa-dev, il vient de commiter les 19 000 lignes de code de la branche pipe-video.

Cette branche avait été créée par Younes Manton, l'étudiant du google summer of code qui avait commencé à implémenter le décodage de vidéos avec Nouveau.

Ce merge devrait donc permettre d'avoir dans les prochaines versions de mesa un décodage des vidéos par VDPAU en utilisant les shaders de nos chères cartes graphiques (r300 et r600 pour les cartes AMD)

Les petits liens :
Message sur mesa-dev : http://lists.freedesktop.org/archives/mesa-dev/2011-July/009319.html
The commit : http://cgit.freedesktop.org/mesa/mesa/commit/?id=ed24e19070b7dff12670151b2d184f31c845ccae

  • # Explication ?

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

    • C'est dans nouveau qu'il y a enfin l'accélération du décodage par la carte graphique ?
    • C'est pour AMD/ATI ?
    • C'est pour quelles cartes graphiques ?
    • C'est pour quels codecs ?

    Parce que cette accélération, je l'ai déjà sous linux depuis 4 ans (uniquement avec les drivers propriétaires pour ma carte nvidia, mais avec les drivers libres pour ma carte intel (et plus récemment)).

    • [^] # Re: Explication ?

      Posté par  . Évalué à 3.

      D'après ce que j'ai compris, ça concerne Gallium, et donc Nouveau, les drivers Intel et les drivers libres pour AMD R300-R900.

      Pour les codecs, je suppose que ça dépend de la carte graphique. Le commit parle de VDPAU, XvMC et VA. D'après Wikipedia :

      Actuellement, les parties de code pouvant être déchargées par VDPAU vers le processeur graphique sont la compensation de mouvement (mo comp), la transformée en cosinus discrète inverse (IDCT), le décodage de longueur de variable (VLD), et le déblocage pour MPEG-1, MPEG-2, MPEG-4 ASP (MPEG-4 partie 2, H.264 ou MPEG-4 AVC et VC-1 ainsi que des vidéos codées en WMV3 ou WMV9.

      VDPAU est le plus complet des trois il me semble. VA n'implémente qu'une sous-partie de VDPAU et XvMC est un peu (beaucoup ?) dépassé.

    • [^] # Re: Explication ?

      Posté par  . Évalué à 8.

      Alors dans l'ordre :

      • C'est nouveau pour les drivers libres oui.
      • C'est pour l'instant surtout réservé à certaines cartes graphiques qui utilisent les drivers Gallium3D r300 et r600. Cela demande le support de certaines instructions qui ne sont pas encore implémentées dans tous les drivers graphiques. Patience.
      • A terme, ce sera pour à peu près toutes les ATI et NVIDIA suffisamment récentes.
      • Pour l'instant c'est pour les vidéos encodées en mpeg 1 et 2. Donc pour les DVD mais aussi les Blu-ray qui sont encodés en mpeg 2 (ça existe oui).

      • [^] # Re: Explication ?

        Posté par  . Évalué à 1.

        Pour l'instant c'est pour les vidéos encodées en mpeg 1 et 2

        Ha, subitement, je suis très interessé.
        Est-ce que VLC, ffmpeg en tirent parti, dans leur version HW-accelerated ?

        • [^] # Re: Explication ?

          Posté par  . Évalué à 3.

          Oui tout à fait, tous les logiciels pouvant utiliser l'api vdpau sont compatibles. Et cela inclus VLC et tous les autres logiciels basés sur ffmpeg/libav.

          • [^] # Re: Explication ?

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

            Et pourquoi ne pas passer la libva si j'ai bien tout compris libva s'interface avec toute les méthodes propriétaires donc il est possible d'utiliser libva sur du Nvidia (libva va donc passer par vdpau).

            Ensuite libva est fortement poussé par Intel donc il y a peut être un conflit d'intérêt.

  • # Efficacité éléctrique ?

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

    Les cartes graphiques ont du matériel dédié à la décompression vidéo, alors que ça coùte cher aux constructeurs, donc je ne pense pas que ce soit sans raison, et je me demande si faire du décodage par shader est efficace niveau consommation éléctrique.

    Si c'est pour se retrouver avec un système qui chauffe encore plus qu'un décodage par le CPU, l'interêt se limite aux petites configs niveau cpu mais puissantes niveau GPU.

    • [^] # Re: Efficacité éléctrique ?

      Posté par  . Évalué à 6.

      Niveau consommation éléctrique ce n'est pas forcement rentable en effet.
      Les puces dédiées au décodage vidéo qui sont sur les cartes graphiques, les drivers libres n'y ont pas accès, donc c'est réglé.

      L’intérêt de la chose c'est en effet les petites configs (qui ont quand même des cartes graphiques avec suffisamment d'unités de shaders) ou alors pour les très grosses vidéos, car oui, c'est parfaitement possible de saturer son core i7 avec une bonne grosse vidéo.

    • [^] # Re: Efficacité éléctrique ?

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

      Ceci est une implémentation initiale. Le but final est bien sûr d'utiliser le hw dédié.

      Pour Nouveau (je bosse que sur ce driver), on sait décoder du mpeg 2 en hardware pour les geforce 7 jusqu'aux geforce 9. Pour AMD, pas de docs. Peut être Jérome Glisse pourra nous dire plus :)

      Quelqu'un est en train de voir de notre coté comment gallium pourrait se servir du circuit de décodage mpeg2. Ça sera la première implémentation libre qui utiliserait un décodage totalement hardware :).

      • [^] # Re: Efficacité éléctrique ?

        Posté par  (site web personnel) . Évalué à 6. Dernière modification le 14 juillet 2011 à 19:57.

        Concernant Nouveau il fait quoi exactement ce patch qui est entré dans le noyau 3.0 ?
        J'avais cru comprendre que ça concernait le décodage vidéo des flux mpeg pour certaines cartes NVidia.

Suivre le flux des commentaires

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