Journal Ayé les processeurs Intel Ivy Bridge gèrent OpenCL 1.1 sous GNU/Linux

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
41
12
fév.
2014

J'avais rédigé cette dépêche au lancement des processeurs Ivy Bridge :

Depuis, les développeurs de l'Intel Open Source Technology Center (aka Intel OTC) ont mis les bouchées doubles et voici où en est la situation :

Les cœurs graphiques Ivy Bridge sont à présent compatibles OpenGL 3.3 (depuis Mesa 10.0) (Ivy Bridge peut gérer OpenGL 4.0 en théorie), OpenGL ES 3.0 (depuis Mesa 9.1), et, grande nouveauté : OpenCL 1.1 depuis Beignet 0.8 sorti ce jour (pour les HD 4000 en tout cas) !

Je pourrais aussi vous dire que le décodage matériel de JPEG, MPEG-2, MPEG-4:2, H.264 et VC-1 est possible depuis gstreamer-vaapi 0.5.7 et que le codage matériel en H.264 et MPEG-2 est possible depuis la toute récente 0.5.8 mais je sens que vous allez défaillir…

Bien sûr toutes ces briques sont open source, étant précisé que les pilotes 3D utilisent Mesa classique plutôt que Gallium 3D et que, fidèle à ses habitudes, Intel a développé sa propre bibliothèque, Beignet, pour exposer les fonctions OpenCL de ses puces plutôt que de se baser sur le procédé Clover pour Gallium 3D (avec encore moins d'excuses que précédemment étant donné que Clover prédate Beignet).

  • # Ah cool !

    Posté par  . Évalué à 5.

    Ça veut dire le moteur Cycles de Blender en rendu GPU entièrement libre ?
    On installe comment ?

  • # Mesa/Gallium/Beignet/Clover pour les nuls?

    Posté par  . Évalué à 8.

    Pour ceux qui n'y connaissent pas grand chose, je croyais moi que Intel avait justifié un éloignement de Gallium au prétexte que les puces Intel utilisent de la mémoire partagée au contraire des cartes "classiques" et que du coup leur approche était plus mieux pour eux, blablabla.
    J'ai bon jusque là?

    Et pour Beignet, c'est la même excuse ou sinon je ne comprends pas bien ce qu'ils cherchent à faire?

    (Ceci étant dit, j'ai du mal à être dur avec la boite qui a certainement le meilleur niveau de collaboration avec le monde Libre!)

    • [^] # Re: Mesa/Gallium/Beignet/Clover pour les nuls?

      Posté par  . Évalué à -5.

      sinon je ne comprends pas bien ce qu'ils cherchent à faire?

      NIH

    • [^] # Re: Mesa/Gallium/Beignet/Clover pour les nuls?

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 13 février 2014 à 09:46.

      Ceci étant dit, j'ai du mal à être dur avec la boite qui a certainement le meilleur niveau de collaboration avec le monde Libre

      Attention, Intel n'est pas du tout un bon copain du monde Libre, c'est seulement la division graphique d'Intel mais toutes les divisions d'Intel ne sont sont pas au même niveau, bien au contraire.
      V. par exemple https://www.fsf.org/campaigns/free-bios.html (que j'ai traduit dans ce billet http://libre-ouvert.toile-libre.org/index.php?article182/choisir-un-ordinateur-portable-machine-de-guerre-ou-machine-de-liberte) :

      La société la moins coopérative est Intel, qui a commencé un projet bidon de BIOS « open source ». Le logiciel regroupe toutes les parties sans intérêt du BIOS, sans les parties importantes. Il ne fonctionne pas et ne nous aide en rien à obtenir un BIOS fonctionnel. Il s'agit juste d'une distraction. Au contraire, AMD s'est montré coopératif en publiant des gros morceaux du code source de leur BIOS et en permettant à ses experts techniques de nous aider.

      • [^] # Re: Mesa/Gallium/Beignet/Clover pour les nuls?

        Posté par  . Évalué à 8.

        Malgré tout, Intel a libéré TBB (Threading Building Blocks), et récemment ils ont aussi libéré leur bibliothèque pour OpenMP. Et au moins pour ce qui est du boulot que je fais avec eux en termes de recherche, notre boulot sera libéré sous GPL.

        Je trouve qu'ils ne sont pas si mal. Après, il est évident qu'il est dans leur intérêt de garder le matos relativement fermé, étant donné la position qu'ils occupent sur le marché des processeurs.

        La seule chose qui m'énerve pas mal chez Intel, c'est la concurrence déloyale faite aux autres fabricants de x86 quand il s'agit de compiler avec icc ou d'utiliser la MKL (ils sous-optimisent volontairement lorsque le code ne tourne pas sur un processeur Intel).

      • [^] # Re: Mesa/Gallium/Beignet/Clover pour les nuls?

        Posté par  . Évalué à 2.

        Et Tianocore, c'est du poulaÿ ? J'imagine que c'est ce que la FSF qualifie de truc sans intérêt…

  • # Pas chez Debian tout de suite...

    Posté par  (site web personnel, Mastodon) . Évalué à -1. Dernière modification le 13 février 2014 à 10:15.

    … Ils en sont encore à la version 0.3

    Des volontaires ? ;)

    EDIT : arf, j'ai trop vite parlé, c'est bien beignet qui a fait un saut de version de 0.3 à 0.8 selon leur git. Donc ça va chez Debian, on suit gentiment.

  • # Support des puces Haswell ?

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

    Un commit laisse supposer que beignet 0.8 et censé fonctionner avec les puces Haswell… sauf qu'ayant essayé, la testsuite se foire systématiquement, en plantant le GPU à chaque test :

    [558625.061488] [drm] stuck on render ring
    [558625.061575] [drm:i915_set_reset_status] ERROR render ring hung inside bo (0x56e6000 ctx 0) at 0x56e60bc

    Quelqu'un d'autre a essayé avec des puces Haswell ?

  • # VAAPI : moi pas comprendre

    Posté par  . Évalué à 4.

    Salut,

    Je ne suis pas sûr de bien comprendre l'histoire de gstreamer-vaapi : normalement c'est pas vaapi lui-même qui est censé supporter des trucs et gstreamer-vaapi va juste utilise la lib ?
    Par exemple, est-ce que ça veut dire que seul gstreamer supporte les trucs dont tu parles ou alors je peux aussi utilise vlc, mplayer ou autre pour lire des trucs avec vaapi ?

    Désolé si mes questions sont cons, c'est vraiment le bazar entre les api, les libs, les applis, etc, rien n'est vraiment très clair…

    • [^] # Re: VAAPI : moi pas comprendre

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 13 février 2014 à 15:39.

      VAAPI c'est comme Mesa qui implémente OpenGL si tu veux, après il faut que les logiciels utilisent cette bibliothèque.
      Chaque logiciel peut appeler la VAAPI donc, mais comme sous GNOME on a un paquet de logiciels qui sous-traitent le traitement A/V à GStreamer, c'est particulièrement intéressant que GStreamer soit capable d'utiliser la VAAPI comme ça tous les logiciels de l'environnement en profitent.
      Cf http://fr.wikipedia.org/wiki/Video_Acceleration_API#Logiciels_support.C3.A9s

      • [^] # Re: VAAPI : moi pas comprendre

        Posté par  . Évalué à 2.

        Ok je comprend, en fait ce que dis le journal c'est que la version 0.5.7 supporte vaapi en lecture, et la 0.5.8 en encodage en fait.

        Merci, en fait c'était tout bête, et puis j'ai testé avec mplayer-vaapi et je crois que ça marche… (mais bon, avec ces trucs on est jamais vraiment sûr de ce qui est utilisé et si ça apporte quelque chose… !).

Suivre le flux des commentaires

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