tag:linuxfr.org,2005:/tags/opencl/publicLinuxFr.org : les contenus étiquetés avec « opencl »2022-02-07T23:10:22+01:00/favicon.pngtag:linuxfr.org,2005:News/408552022-02-01T11:02:40+01:002022-02-01T22:59:54+01:00OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrxLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Ces dernières années, en même temps que les cartes graphiques AMD restaient compétitives, les pilotes pour ces cartes sont devenus les meilleurs pilotes graphiques sous Linux sur quasiment tous les aspects (fiabilité, performance, stabilité, intégration…), sauf pour un usage pour lesquels les pilotes Linux sont un naufrage : le calcul sur carte graphique avec OpenCL.</p>
</div><ul><li>lien nᵒ 1 : <a title="https://gitlab.com/illwieckz/i-love-compute" hreflang="en" href="https://linuxfr.org/redirect/109824">Dépôt I ♥ Compute!</a></li><li>lien nᵒ 2 : <a title="https://rebuild.sh/post/2022-01-25-OpenCL_on_Linux_state_of_AMD_drivers_is_now_worse_than_it_was_back_in_the_days_of_fglrx/" hreflang="en" href="https://linuxfr.org/redirect/109825">OpenCL on Linux: state of AMD drivers is now worse than it was back in the days of fglrx</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#toc-les-pilotes-amd-sont-excellents-pour-vulkan-opengl-va-api">Les pilotes AMD sont excellents pour Vulkan, OpenGL, VA-API…</a></li>
<li><a href="#toc-les-pilotes-opencl-amd-sous-linuxnont-jamais-%C3%A9t%C3%A9-en-aussi-mauvaise-posture">Les pilotes OpenCL AMD sous Linux n’ont jamais été en aussi mauvaise posture</a></li>
<li><a href="#toc-mon-initiative-i--compute-pour-maintenir-scripts-et-bidouilles-documentation-et-suivi">Mon initiative I ♥ Compute! pour maintenir scripts et bidouilles, documentation et suivi</a></li>
<li><a href="#toc-don-de-mat%C3%A9riel-financement-prestations-professionnelles">Don de matériel ? Financement ? Prestations professionnelles ?</a></li>
<li><a href="#toc-le-mot-de-la-fin">Le mot de la fin</a></li>
</ul>
<p><a href="https://illwieckz.net/media/image/20220125.test-carte-graphiques.thomas-debesse/20220125-010849-000.test-carte-graphiques.thomas-debesse.jpg"><img src="//img.linuxfr.org/img/68747470733a2f2f696c6c776965636b7a2e6e65742f6d656469612f72656475632f32303232303132352e746573742d63617274652d677261706869717565732e74686f6d61732d646562657373652f32303232303132352d3031303834392d3030302e746573742d63617274652d677261706869717565732e74686f6d61732d646562657373652e3732302e6a7067/20220125-010849-000.test-carte-graphiques.thomas-debesse.720.jpg" alt="test de cartes graphiques" title="Source : https://illwieckz.net/media/reduc/20220125.test-carte-graphiques.thomas-debesse/20220125-010849-000.test-carte-graphiques.thomas-debesse.720.jpg"></a><br>
<em>Cartes graphiques au banc d’essai</em></p>
<h2 id="toc-les-pilotes-amd-sont-excellents-pour-vulkan-opengl-va-api">Les pilotes AMD sont excellents pour Vulkan, OpenGL, VA-API…</h2>
<p>Sur le plan graphique, la prise en charge d’OpenGL par le pilote libre radeonsi de Mesa est excellent depuis longtemps. Ça fait plusieurs années que le pilote libre est recommandé à la place du pilote propriétaire. La version 4.6 et la plupart des extensions sont implémentées depuis un bon moment maintenant, et le pilote prend même désormais en charge les versions récentes d’OpenGL avec le <em>compatibility profile</em> qui furent longtemps une spécificité du pilote propriétaire et qui était une fonctionnalité spécifique à certains besoins industriels.</p>
<p>Du côté de Vulkan, la nouvelle API graphique plus bas niveau, le pilote libre RADV de Mesa fonctionne très bien, et le pilote libre AMDVLK de AMD fonctionne très bien aussi. Il est même possible d’installer les deux et de choisir le plus performant pour tel ou tel cas d’usage avec une simple variable d’environnement. Il existe en fait même un troisième pilote qui est la variante amdgpu-pro du pilote AMDVLK qui peut parfois apporter certaines fonctionnalités avant les autres. En d’autres termes, l’utilisateur de carte AMD a l’embarras du choix, et ils sont tous bons.</p>
<p>Sur le plan de l’accélération du décodage et du codage de vidéo en utilisant la carte graphique, les APIs VDPAU et VA-API sont très bien prises en charge.</p>
<p>Grâce à la plateforme amdgpu, tous ces pilotes peuvent cohabiter.</p>
<p>Le pilote amdgpu de Linux est globalement très bon, je connais quelques cas spécifiques où ça pourrait être meilleur, mais pour l’écrasante majorité des utilisateurs, tout cela marche très bien. De plus ce pilote noyau amdgpu, et les pilotes radeonsi, radv, vdpau et va-api sont intégrés dans les distributions sans nécessiter de dépôt tiers. Toutes ces fonctionnalités sont à portée d’installation via les paquets officiels de la distribution, quand ces paquets ne sont pas déjà installés par défaut.</p>
<p>Mais il reste un domaine dans lequel la qualité des pilotes AMD n’est pas au rendez-vous, et est même désastreuse : le calcul avec l’API OpenCL.</p>
<p>OpenCL est utilisable par certaines applications comme Darktable (développement photo numérique), Blender (modélisation et rendu 3D), LuxRender (moteur de rendu 3D par lancer de rayon), DaVinci Resolve (montage vidéo), Natron (Compositeur vidéo), et même GIMP (dessin et traitement d’image 2D) et LibreOffice Calc (tableur), et d’autres.</p>
<p>La plupart du temps, ces applications peuvent se passer d’OpenCL, mais le gain de performance apporté par OpenCL est très appréciable, que ce soit en distribuant le calcul entre le CPU et le GPU au lieu de reposer sur le CPU seul, ou en exploitant un GPU qui serait plus performant qu’un CPU pour un type de tâche donnée.</p>
<h2 id="toc-les-pilotes-opencl-amd-sous-linuxnont-jamais-été-en-aussi-mauvaise-posture">Les pilotes OpenCL AMD sous Linux n’ont jamais été en aussi mauvaise posture</h2>
<p>L’état d’OpenCL pour les GPUs AMD sous Linux est maintenant pire que ce qu’il était à l’époque de fglrx (jusqu’à 2015).</p>
<p>Il existe une multitude de pilotes OpenCL pour AMD, visant telle ou telle architecture et la cohabitation est parfois difficile. Parfois les pilotes ne peuvent fonctionner si une autre carte d’une autre génération est branchée, parfois des pilotes différents pour des cartes différentes essaient de s’installer en utilisant les mêmes noms de fichiers.</p>
<ul>
<li>La dernière version d’AMD OpenCL PAL pour la génération GCN 5 et suivants date du 29 septembre 2020. Les récentes versions du pilote propriétaire AMDGPU-PRO ne prennent plus en charge OpenCL pour les cartes GCN 5.</li>
<li>La dernière version d’AMD OpenCL Orca (« Legacy ») pour GCN 1, 2, et 3 datent du 21 juin 2021. Les récentes versions du pilote propriétaire AMDGPU-PRO ne prennent plus en charge OpenCL pour ces cartes. Je ne sais pas si c’est une erreur, car ce pilote est toujours fourni mais ne prend pas en charge GCN 1, 2 et 3 (et je n’ai pas de GCN 4 pour tester).</li>
<li>
<a href="https://en.wikipedia.org/wiki/ROCm#OpenCL">ROCm</a> n’est pas pour les utilisateurs ordinaires, il semble développé pour des utilisations industrielles spécifiques, il <a href="https://github.com/RadeonOpenCompute/ROCm/issues/1397">ne prend pas en charge les applications graphiques</a> (AMD a dit que c’était temporaire mais cela peut durer longtemps) et ne prend en charge qu’une très petite quantité de matériel : une infime sélection de cartes graphiques PCIe et aucune carte graphique intégrée dans les APU AMDs.</li>
</ul>
<p>Ce pilote ROCm peut même reconnaître certains matériels, tenter de faire quelque chose et <a href="https://github.com/RadeonOpenCompute/ROCm/issues/1624">déstabiliser le noyau</a> de telle sorte que les utilisateurs sont invités à redémarrer leur machine.</p>
<p>Le pilote ROCm a remplacé le pilote PAL sans être une alternative, ni dans le but, ni dans la prise en charge matérielle, ni dans l’implémentation, ni dans sa capacité à répondre aux besoins.</p>
<p>ROCm déprécie très rapidement le matériel. L’architecture GCN 2 n’a fonctionné que quelque mois il y a des années, et l’architecture GCN 4 (Polaris) est rapportée comme ayant cessé de fonctionner il y a quelque temps (seulement deux étaient alors prises en charge). Actuellement il est dit que <a href="https://github.com/RadeonOpenCompute/ROCm/blob/c3f91afb2688deb638c360497e35b249f8026667/README.md#hardware-and-software-support">seulement trois puces</a> sont prises en charge par ROCm (Vega 10, Vega 7nm, MI1000).</p>
<p>Du côté de la communauté, Clover fonctionne pour certains usages (exemple : LuxRender) mais pas pour d’autres (exemple : Darktable) puisque le traitement d’image n’est pas encore implémenté. Avec Clover LuxMark est deux fois plus rapide qu’Orca et ROCm sur GCN (probablement aussi avec PAL).</p>
<p>Malheureusement j’ai remarqué que Clover est devenu cassé au cours des dernières années. La dernière version précompilée pour Ubuntu que j’ai trouvée et qui fonctionne date de 2019. J’ai écrit un script pour compiler la dernière version de Clover avec la dernière version de LLVM et je peux confirmer que c’est cassé en amont. Ah, et pour les dernières versions fonctionnelles, elles ont perdu <a href="https://gitlab.com/illwieckz/i-love-compute/-/issues/17">entre 15 et 20%</a> en performance par rapport à 2018.</p>
<p>Clover est d’ailleurs le seul pilote existant fonctionnant avec les cartes graphiques TeraScale 2 et 3 (et une paire de TeraScale 1 pourraient théoriquement être implémentées mais ce n’est pas fait), car le dernier pilote officiel AMD pour ces cartes était Radeon Software (fglrx). Il est abandonné depuis de très nombreuses années (dernière version en 2015, et celui pour TeraScale 1 datent de 2013) et est incompatible avec la plateforme amdgpu et les noyaux récents.</p>
<p>En parlant de fglrx, j’ai vu ces dernières années des personnes rapporter qu’ils utilisaient encore fglrx (et donc des environnements de 2015) pour utiliser OpenCL avec du matériel GCN, c’est aussi pourquoi j’ai souvent conseillé mes scripts pour aider ces personnes à mettre à jour leurs systèmes.</p>
<h2 id="toc-mon-initiative-i--compute-pour-maintenir-scripts-et-bidouilles-documentation-et-suivi">Mon initiative I ♥ Compute! pour maintenir scripts et bidouilles, documentation et suivi</h2>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f646c2e696c6c776965636b7a2e6e65742f622f692d6c6f76652d636f6d707574652f6272616e64696e672f692d6c6f76652d636f6d707574652e3235362e706e67/i-love-compute.256.png" alt="I ♥ Compute!" title="Source : https://dl.illwieckz.net/b/i-love-compute/branding/i-love-compute.256.png"></p>
<p>J’ai un grand intérêt dans OpenCL parce que j’utilise beaucoup Darktable (logiciel de développement photographique), et pour cela, depuis des années, je maintiens des scripts et des bidouilles pour conserver cette fonctionnalité, pour mon usage d’abord, et que je partage ensuite avec qui en a besoin.</p>
<p>Au fil des années, j’ai écrit et réécrit plein de scripts. Et puis j’ai commencé à ressentir le besoin de tracer au même endroit les tickets que j’ouvrais à droite et à gauche. J’ai donc ouvert un dépôt sur GitLab que j’ai appelé « <em>I ♥ Compute!</em> » pour y conserver ma documentation, mes scripts, et avoir un gestionnaire de ticket unifié.</p>
<p>La dernière version de mon script pour Ubuntu (marche peut-être ou partiellement avec Debian) permet d’installer sur Ubuntu 20.04 LTS et Ubuntu 21.10, et simultanément :</p>
<ul>
<li>La dernière version fonctionnelle d’AMD OpenCL Orca (ancienne archive AMDGPU-PRO) ;</li>
<li>La dernière version fonctionnelle d’AMD OpenCL PAL (ancienne archive AMDGPU-PRO) ;</li>
<li>La dernière version d’AMD ROCm (dépôt AMD) ;</li>
<li>La dernière version fonctionnelle de Mesa Clover (dépôt Ubuntu) ;</li>
<li>La dernière version identifiée de la platforme AMD APP pour CPUs (ancienne archive Radeon Software de l’ère fglrx).</li>
</ul>
<p>Le dernier pilote est seulement la partie CPU qui était fournie avec fglrx et qui permet à un logiciel OpenCL de répartir des tâches OpenCL à la fois sur le CPU et le GPU pour exploiter tout le matériel disponible. La partie GPU de fglrx est inutilisable aujourd’hui de toute façon.</p>
<p>Il faut savoir que certains pilotes ont des bugs. Par exemple, la dernière version fonctionnelle d’Orca devient inutilisable s’il existe une seule carte utilisant le pilote radeon (au lieu d’amdgpu) dans le système, ainsi si vous avez une carte pilotée par radeon et une autre pilotée par amdgpu, Orca ne fonctionnera pas avec celle pilotée par amdgpu à cause de la présence de l’autre, alors que ça marcherait si l’autre est enlevée physiquement du système.</p>
<p>Comme je l’ai écrit plus haut, ROCm peut mettre en vrac le noyau s’il essaie de piloter certaines cartes GCN, donc si votre système a une carte GCN affectée comme une R9 390X et une autre carte plus récente comme une Vega et que vous installez ROCm pour prendre en charge la Vega, vous aurez des problèmes. Ah et j’ai pu constater que toutes les Vegas (y compris des cartes PCIe) ne fonctionnent pas avec ROCm (j’ai dû utiliser PAL une fois). Certaines sont prises en charge par PAL mais PAL a été retiré. Je vous avais déjà dit que c’était galère ?</p>
<p>Il y a actuellement un script pour installer les pilotes OpenCL AMD sur Ubuntu, un script pour compiler Clover soi-même, et un script pour compiler <a href="https://github.com/kpet/clvk">clvk</a> (un projet d’implémentation d’OpenCL sur Vulkan), mais à l’heure actuelle aucun de ces deux-là ne marche (même si Clover a partiellement fonctionné dans le passé).</p>
<p>Mes scripts viennent avec une aide intégrée (<code>--help</code>).</p>
<p>Vous trouverez donc un condensé de mes connaissances sur le dépôt <a href="https://gitlab.com/illwieckz/i-love-compute">I ♥ Compute!</a> sur GitLab.</p>
<p>Ça ne traite pas que d’AMD mais la situation d’AMD est la pire de toutes. Les pilotes (certes propriétaires et non intégrés) de Nvidia prennent généralement en charge OpenCL et les pilotes Intel commencent à être pas trop mal (même si là aussi, c’est la prolifération des pilotes, ça me semble moins mauvais).</p>
<p>Vous y trouverez donc également <a href="https://gitlab.com/illwieckz/i-love-compute#scripts">des scripts</a>. Je préviens que je n’ai pas les moyens de maintenir la compatibilité antérieure. Si vous utilisez un de mes scripts pour installer un pilote, assurez-vous de conserver quelque part le script en question dans la version que vous avez utilisée, pour que vous puissiez désinstaller la version que vous avez installée. Je n’ai pas les moyens de m’assurer que les nouvelles versions des scripts désinstallent ce qui a été installé avec une ancienne version.</p>
<p>Et vous y trouverez également un <a href="https://gitlab.com/illwieckz/i-love-compute/-/issues">espace de suivi</a> où je trace au même endroit les problèmes que je rencontre et que je rapporte ailleurs (ou qui n’ont parfois pas d’endroit pour être rapportés).</p>
<h2 id="toc-don-de-matériel-financement-prestations-professionnelles">Don de matériel ? Financement ? Prestations professionnelles ?</h2>
<p>Je ne teste d’ailleurs pas que les cartes AMD, même si c’est ma priorité (parce que c’est ce que j’utilise).</p>
<p>Du côté AMD je possède déjà des cartes TeraScale 1 (AGP, PCI, PCIe),<br>
TeraScale 2 (PCIe),TeraScale 3 (PCIe), GCN 1 (PCIe), GCN 2 (PCIe), GCN 3 (integrée), et GCN 5 (integrée). J’ai aussi les cartes-mères qui vont avec (AGP, PCIe 2, 3, 4).</p>
<p>Je n’ai pas de carte AMD GCN 4 (Polaris), RDNA1/CDNA1 (Navi), RDNA2/CDNA2 (Big Navi) et en particulier pas de matériel AMD pris en charge par ROCr. Des cartes non-intégrées GCN 3 et GCN 5 seraient utiles aussi (celles qui sont embarquées dans des APUs peuvent avoir leur propre limitations spécifiques).</p>
<p>Plus de détails sur le matériel que je possède et les instructions pour les dons de matériel éventuels <a href="https://gitlab.com/illwieckz/i-love-compute#hardware-donation">sont référencés là</a>.</p>
<p>En particulier j’ai besoin d’une carte GCN 4 pour tester si la dernière version de Orca qui ne gère plus GCN 1, 2 et 3 gère tout de même GCN 4 (autrement AMD la distribuerait pour rien).</p>
<p>Ce matériel fait partie de celui que j’utilise pour tester et valider le jeu <a href="https://unvanquished.net">Unvanquished</a>, avec <a href="https://wiki.unvanquished.net/wiki/GPU_compatibility_matrix">ce genre de tableau</a> (ici pour OpenGL). Il serait utile d’avoir un tel tableau pour OpenCL mais c’est beaucoup de travail.</p>
<p>Pendant toutes ces années j’ai fourni ces scripts OpenCL et mes conseils autour de moi, mais alors que la situation devient plus mauvaise, je me suis dit que c’était une bonne idée de proposer la capacité de faire des dons (matériel et financier). Comme je suis actuellement à mon compte, le cas échéant je pourrai affecter plus de temps à cette initiative si je reçois quelques dons financiers. J’ai donc <a href="https://gitlab.com/illwieckz/i-love-compute#funding">ajouté des liens pour faire des dons</a> sur la page.</p>
<p>Et vu que j’ai mon entreprise, certains seront peut-être intéressés par des prestations spécifiques ? Par exemple dans le passé et dans un cadre professionnel j’avais écrit un script pour installer le pilote AMD OpenCL PAL sur Mageia pour piloter une carte Vega afin d’accélérer Blender. Je n’ai pas du tout les moyens de maintenir ce genre de script, mais il y a peut-être un besoin.</p>
<p>J’ai donc ajouté <a href="https://rebuild.sh">sur mon site professionnel</a> que je propose mes services pour faire marcher OpenCL avec AMD pour des clients professionnels.</p>
<h2 id="toc-le-mot-de-la-fin">Le mot de la fin</h2>
<p>Pour résumer, sans utiliser des logiciels obsolètes qu’AMD ne soutient plus et n’inclut plus dans sa suite de pilotes, l’état actuel de la fourniture OpenCL avec le matériel AMD sous Linux semble être ROCm dont la documentation <a href="https://github.com/RadeonOpenCompute/ROCm/blob/c3f91afb2688deb638c360497e35b249f8026667/README.md#hardware-and-software-support">ne liste que trois puces</a> officiellement considérées et il est dit que <a href="https://github.com/RadeonOpenCompute/ROCm/blob/95493f625cadb3457cedb454e4ebd0df7b991443/README.md?plain=1#L194">les applications graphiques ne sont pas prises en charge</a>.</p>
<p>Il y a quelques tentatives de faire tourner OpenCL sur Vulkan, comme <a href="https://github.com/kpet/clvk">clvk</a> qui repose sur <a href="https://github.com/google/clspv">clspv</a>, peut-être que c’est ça l’avenir ? Pour le moment ça ne marche pas encore en tout cas.</p>
<p>AMD devrait peut-être s’inquiéter de la tentative d’Intel de sortir des cartes PCI express tout en ayant une prise en charge d’OpenCL entièrement libre et intégrée dans les dépôts.</p>
<p>Si AMD a besoin d’aide, a priori je sais faire cohabiter leurs pilotes…</p>
<p>Et vous, quelle est votre expérience avec OpenCL, Linux et AMD ?</p>
</div><div><a href="https://linuxfr.org/news/opencl-sous-linux-l-etat-des-pilotes-amd-est-desormais-pire-que-ce-qu-il-etait-a-l-epoque-de-fglrx.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126699/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/opencl-sous-linux-l-etat-des-pilotes-amd-est-desormais-pire-que-ce-qu-il-etait-a-l-epoque-de-fglrx#comments">ouvrir dans le navigateur</a>
</p>
Thomas DebessevmagninalkinoMaxzorBenoît Sibaudhttps://linuxfr.org/nodes/126699/comments.atomtag:linuxfr.org,2005:Bookmark/42142022-01-30T01:50:31+01:002022-01-30T01:50:31+01:00In defense of NIR within Mesa driver stack - phoronix<a href="https://www.phoronix.com/scan.php?page=news_item&px=Mesa-NIR-Success-Story">https://www.phoronix.com/scan.php?page=news_item&px=Mesa-NIR-Success-Story</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126742/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/in-defense-of-nir-within-mesa-driver-stack-phoronix#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/126742/comments.atomtag:linuxfr.org,2005:Diary/391062020-04-25T16:51:27+02:002020-04-25T16:51:27+02:00OpenCL : avoir l'accélération GPU avec l'AMD libreLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bonjour Nal,</p>
<p>Pour des raisons qui m'échappent encore, il n'est pas possible sous Fedora 31 (en attendant peut-être sous la 32 ?) d'avoir l'accélération OpenCL et les drivers libres intégrés à Fedora, sauf manipulations dangereuses (copier à la main des bibliothèques, installer des pilotes qui peuvent péter votre installation etc..). Il existe un support pour RHEL/CentOS mais les utilisateurs Fedora en sont privés…<br>
Pour moi il était hors de question de prendre le risque, je m'étais ravisé mais c'était sans compter un utilisateur qui s'est basé sur les rpm (système de package commun à RHEL/CentOS/Fedora) fournis par AMD.<br>
Voici le lien de son post dont je ne fais que retranscrire (en adaptant 2 ou 3 petits trucs) :<br>
<a href="https://ask.fedoraproject.org/t/setting-up-folding-home-to-use-opencl-with-the-amdgpu-drivers/6132">https://ask.fedoraproject.org/t/setting-up-folding-home-to-use-opencl-with-the-amdgpu-drivers/6132</a></p>
<p>Bon voilà ma transcription/adaptation :<br>
1 - <a href="https://drivers.amd.com/drivers/linux/amdgpu-pro-20.10-1048554-rhel-8.1.tar.xz">Télécharger les packages fournis par AMD sur son site (la version 20.10 est la dernière)</a>.</p>
<p>2 - on va créer un repo local pour notre installation. Un petit :<br>
<code><br>
cd /var/local<br>
sudo tar xf ~/Téléchargements/amdgpu-pro-*-rhel-8.1.tar.xz<br>
sudo mv amdgpu-pro-*-rhel-8.1 amdgpu<br>
sudo curl -LO https://hobbes1069.fedorapeople.org/amdgpu/amdgpu.repo<br>
</code><br>
3 - faites un petit <code>sudo dnf update</code> pour bien charger le repo local que l'on vient de créer<br>
4 - Installez les paquets qui vous concernent. Je n'ai eu besoin que de ceux-ci (à vérifier dans quel ordre ils peuvent s'installer :<br>
<code><br>
$ rpm -qa | grep amdgpu<br>
opencl-orca-amdgpu-pro-icd-20.10-1048554.el8.x86_64<br>
amdgpu-pro-core-20.10-1048554.el8.noarch<br>
libdrm-amdgpu-2.4.100-1048554.el8.x86_64<br>
libdrm-amdgpu-common-1.0.0-1048554.el8.noarch<br>
</code><br>
5 - Plusieurs remarques : il y a deux versions de pilotes OpenCL ; "orca" sont pour les anciennes générations de cartes AMD (avant la série Vega, comme moi ici), donc un <code>sudo dnf install opencl-orca-amdgpu-pro-icd</code> suffit, sinon, si vous avez une plus récente, un <code>sudo dnf install opencl-amdgpu-pro-icd</code> ; il se peut que dnf se plaint d'avoir échoué installer une dépendance (pour mon cas il s'agissait de amdgpu-core), car le rpm est fait pour rhel et non pour fedora. Ignorez le message et le paquet que vous êtes en train d'installer s'installera malgré tout (ne me demandez pas pourquoi).</p>
<p>6 - maintenant on va vérifier avec clinfo voir si cela a marché (installez-le au préalable) :<br>
<code>$ clinfo -l<br>
Platform #0: AMD Accelerated Parallel Processing<br>
`-- Device #0: Ellesmere<br>
Platform #1: Clover<br>
`-- Device #0: Radeon RX 580 Series (POLARIS10, DRM 3.36.0, 5.5.17-200.fc31.x86_64, LLVM 9.0.0)<br>
Platform #2: Portable Computing Language<br>
`-- Device #0: pthread-AMD Ryzen 7 1700 Eight-Core Processor</code><br>
Il doit avoir apparu la ligne <code>Platform #0: AMD Accelerated Parallel Processing</code> (peu importe le numéro de la plateforme) qui confirme que l'installation a marché.</p>
<p>7 - maintenant, on peut tester sous un logiciel comme darktable, la case "Activer OpenCL" n'est plus grisée :<br>
<a href="https://nsa40.casimages.com/img/2020/04/25/200425044816201307.png"><img src="//img.linuxfr.org/img/68747470733a2f2f6e736134302e636173696d616765732e636f6d2f696d672f323032302f30342f32352f6d696e695f3230303432353034343831363230313330372e706e67/mini_200425044816201307.png" alt="Darktable1" title="Source : https://nsa40.casimages.com/img/2020/04/25/mini_200425044816201307.png"></a><br>
<a href="https://nsa40.casimages.com/img/2020/04/25/200425044816488697.png"><img src="//img.linuxfr.org/img/68747470733a2f2f6e736134302e636173696d616765732e636f6d2f696d672f323032302f30342f32352f6d696e695f3230303432353034343831363438383639372e706e67/mini_200425044816488697.png" alt="Darktable2" title="Source : https://nsa40.casimages.com/img/2020/04/25/mini_200425044816488697.png"></a><br>
<a href="https://nsa40.casimages.com/img/2020/04/25/200425044823336919.png"><img src="//img.linuxfr.org/img/68747470733a2f2f6e736134302e636173696d616765732e636f6d2f696d672f323032302f30342f32352f6d696e695f3230303432353034343832333333363931392e706e67/mini_200425044823336919.png" alt="Darktable3" title="Source : https://nsa40.casimages.com/img/2020/04/25/mini_200425044823336919.png"></a></p>
<p>A noter que malgré la présence de Clover (implémentation des drivers OpenCL de Gallium) dans la liste de clinfo l'accélération n'est pas fonctionnelle et n'est pas détectée par les logiciels tant que vous n'installez pas ces pilotes. Vous gardez malgré tout les pilotes libres sans rien n'avoir cassé et sans avoir bidouillé salement. Si jamais vous avez des soucis de stabilité depuis, il suffit de désinstaller les rpm que vous avez installez pour que ça rentre dans l'ordre.</p>
<div><a href="https://linuxfr.org/users/alexterieur/journaux/opencl-avoir-l-acceleration-gpu-avec-l-amd-libre.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/120174/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/alexterieur/journaux/opencl-avoir-l-acceleration-gpu-avec-l-amd-libre#comments">ouvrir dans le navigateur</a>
</p>
AlexTérieurhttps://linuxfr.org/nodes/120174/comments.atomtag:linuxfr.org,2005:Diary/375092017-09-27T01:54:42+02:002017-09-27T01:54:42+02:00LXC et OpenCL c'est possible !Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Hello, juste un petit journal rapide car je suis content:<br>
j'ai réussi à faire fonctionner <a href="https://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a> dans <a href="https://linuxcontainers.org/fr/">LXC</a><br>
en <a href="https://fr.wikipedia.org/wiki/Espace%20utilisateur" title="Définition Wikipédia">Espace utilisateur</a>.</p>
<p>C'est pratique pour pouvoir expérimenter des librairies etc. sans casser son système !</p>
<p>Malheureusement je ne suis pas sur d'avoir tout noté, mais tout de même un petit récap.</p>
<h2 id="création-du-container">Création du container</h2>
<p>Je pars d'un LXC en Espace utilisateur.<br>
Pour cela voir <a href="https://linuxcontainers.org/fr/lxc/getting-started/">la doc officielle de lxc</a>,<br>
mais en résumé c'est (pour mon utilisateur nommé <em>alex</em>):</p>
<ul>
<li>édition de <code>/etc/lxc/lxc-usernet</code> pour dire que mon utilisateur à le droit de créer une interface réseau virtuelle lxcbr0 (<a href="http://manpages.ubuntu.com/manpages/zesty/en/man5/lxc-usernet.5.html">man lxc-usernet</a>)</li>
</ul><pre><code> alex veth lxcbr0 10
</code></pre>
<ul>
<li>édition /etc/subuid qui dit quels uid supplémentaire mon utilisateur peut utiliser (<a href="http://manpages.ubuntu.com/manpages/zesty/en/man5/subuid.5.html">man subuid</a>)</li>
</ul><pre><code> alex:165536:65536
</code></pre>
<ul>
<li>édition /etc/subgid pareil pour les groupes (<a href="http://manpages.ubuntu.com/manpages/zesty/en/man5/subgid.5.html">man subgid</a>)</li>
</ul><pre><code> alex:165536:65536
</code></pre>
<ul>
<li>copie de la template générale de lxc dans son dossier:</li>
</ul><pre><code class="bash"> $ cp /etc/lxc/default.conf to ~/.config/lxc/default.conf</code></pre>
<ul>
<li>Dans ce fichier, on ajoute des instruction de translation d'uid.
<strong>Attention c'est un point important</strong> !
Pour que notre utilisateur ubuntu du container est accès au socket X11 de l'hôte,
on va lui donner le même uid (cf. <a href="https://fr.wikipedia.org/wiki/User%20identifier" title="Définition Wikipédia">User identifier</a>) que notre utilisateur sur l'hôte.
Dans mon cas, le futur utilisateur <em>ubuntu</em> (dans le container) aura pour uid 1000, mais mon utilisateur <em>alex</em> a pour uid 1001.</li>
</ul><pre><code> # mapping uid before 1000 to 165536+ on host
lxc.id_map = u 0 165536 1000
lxc.id_map = g 0 165536 1000
# mapping uid 1000 to 1001 on host
lxc.id_map = u 1000 1001 1
lxc.id_map = g 1000 1001 1
# mapping uid above 1000 to 166537+
lxc.id_map = u 1001 166537 64535
lxc.id_map = g 1001 166537 64535
</code></pre>
<p>cette configuration est une adaptation de celle proposée dans <a href="https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/">ce billet de blog</a><br>
mais c'est également bien pratique en général,<br>
vu que l'utilisateur de l'hôte pourra ainsi voir les fichiers de l'utilisateur du container !</p>
<ul>
<li>enfin sur ubuntu zesty, pour des problématiques de sécurité liés à AppArmor,
il me faut ajouter (toujours dans ce fichier):</li>
</ul><pre><code> lxc.aa_allow_incomplete = 1
</code></pre>
<p>De là on peut créer un container LXC, par exemple:</p>
<pre><code class="bash">$ lxc-create -n opencl-test -t download -- -d ubuntu -r zesty -a amd64</code></pre>
<h2 id="options-spéciales">Options spéciales</h2>
<p>Maintenant pour que ce container puisse utiliser la carte graphique,<br>
on doit encore monter <code>/dev/dri</code>, l'accès à l'accélération graphique<br>
et <code>/tmp/.X11-unix</code> qui contient les sockets pour communiquer avec le serveur X11.<br>
(comme indiqué par <a href="https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/">ce billet de blog cité précédemment</a>).</p>
<p>Pour cela on édite la configuration de notre container,<br>
normalement dans <code>~/.local/share/lxc/opencl-test/config</code> pour ajouter:</p>
<pre><code># access to resource for opencl
lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
</code></pre>
<p><strong>Attention</strong> ce partage du socket X11 ne fonctionne que parce-que l'on a donné à l'utilisateur <em>ubuntu</em> le même uid que <em>alex</em> (cf. ci-dessus). Sinon le fichier sera présent mais non accessible.</p>
<p>On peut démarrer notre container et entrer dedans (après avoir mis un mot de passe)</p>
<pre><code class="bash">$ lxc-start -n opencl-test
$ lxc-attach -n opencl-test passwd ubuntu
$ lxc-console -n opencl-test</code></pre>
<h2 id="test">Test</h2>
<p>Pour tester, ayant une Intel <a href="https://fr.wikipedia.org/wiki/Skylake" title="Définition Wikipédia">Skylake</a>,<br>
j'ai installé <a href="https://www.freedesktop.org/wiki/Software/Beignet/">beignet</a><br>
et <a href="http://manpages.ubuntu.com/manpages/zesty/man1/clinfo.1.html">clinfo</a>:</p>
<pre><code class="bash"><span class="o">(</span>opencl-test<span class="o">)</span>$ sudo apt update <span class="o">&&</span> sudo apt upgrade
<span class="o">(</span>opencl-test<span class="o">)</span>$ sudo apt install beignet-opencl-icd clinfo
<span class="o">(</span>opencl-test<span class="o">)</span>$ clinfo</code></pre>
<p>Cette dernière commande devrait vous donner les infos sur votre carte graphique.</p>
<p>On peut également essayer une lib comme <a href="https://documen.tician.de/pyopencl/">pyopencl</a>:</p>
<pre><code class="bash"><span class="o">(</span>opencl-test<span class="o">)</span>$ sudo apt install build-essential libffi-dev libblas-dev liblapack-dev
<span class="o">(</span>opencl-test<span class="o">)</span>$ sudo -H pip3 install Cython numpy
<span class="o">(</span>opencl-test<span class="o">)</span>$ sudo -H pip3 install pyopencl</code></pre>
<p>Et après avoir copié l'exemple de la documentation dans <code>test_pyopencl.py</code>:</p>
<pre><code class="bash"><span class="o">(</span>opencl-test<span class="o">)</span>$ <span class="nv">PYOPENCL_CTX</span><span class="o">=</span><span class="s1">'0'</span> python3 test_pyopencl.py
Beignet: <span class="s2">"unable to find good values for local_work_size[i], please provide\n"</span> <span class="s2">" local_work_size[] explicitly, you can find good values with\n"</span> <span class="s2">" trial-and-error method."</span>
<span class="o">[</span> <span class="m">0</span>. <span class="m">0</span>. <span class="m">0</span>. ..., <span class="m">0</span>. <span class="m">0</span>. <span class="m">0</span>.<span class="o">]</span>
<span class="m">0</span>.0</code></pre>
<p>Le warning n'est pas top, mais ne pose pas de problème.<br>
Le résultat égal à 0 est ce qu'on attendait.</p>
<p>Bon j'ai essayé l'installation de <a href="http://www.deeplearning.net/software/theano/">theano</a> et <a href="http://deeplearning.net/software/libgpuarray/installation.html">gpuarray</a>, mais pour le moment c'est pas ça (segfault lors des tests) !</p><div><a href="https://linuxfr.org/users/alexg/journaux/lxc-et-opencl-c-est-possible.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112756/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/alexg/journaux/lxc-et-opencl-c-est-possible#comments">ouvrir dans le navigateur</a>
</p>
Alex G.https://linuxfr.org/nodes/112756/comments.atomtag:linuxfr.org,2005:News/370742016-02-01T09:36:07+01:002016-02-01T10:23:36+01:00Formation OpenCL en contribuant à GIMPLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>L'encyclopédie Wikipédia introduit <a href="https://fr.wikipedia.org/wiki/OpenCL">OpenCL</a> ainsi:</p>
<blockquote>
<p>OpenCL (Open Computing Language) est la combinaison d'une API et d'un langage de programmation dérivé du C, proposé comme un standard ouvert par le <a href="https://fr.wikipedia.org/wiki/Khronos_Group">Khronos Group</a>. OpenCL est conçu pour programmer des systèmes parallèles hétérogènes comprenant par exemple à la fois un CPU multi-cœur et un GPU. OpenCL propose donc un modèle de programmation se situant à l'intersection naissante entre le monde des CPU et des GPU, les premiers étant de plus en plus parallèles, les seconds étant de plus en plus programmables.</p>
</blockquote>
<p>Il s'agit donc d'une API permettant d'améliorer les performances algorithmiques en parallélisant les calculs complexes sur les périphériques divers présents de nos jours sur les ordinateurs (CPU, GPU…).<br>
Côté pilotes, le support de cette API sur Linux fut notamment détaillé il y a quelques jours dans un <a href="//linuxfr.org/news/les-pilotes-graphiques-libres-retrospective-et-vue-sur-l-avenir">autre article</a>. Si vous êtes plutôt intéressé par le côté "utilisation" d'OpenCL, pour l'intégrer par exemple dans vos propres programmes, la société <a href="http://streamcomputing.eu/">StreamComputing</a> lance l'initiative "<em>OpenCL training</em>" (en français: "formation OpenCL") proposant une formation gratuite (à distance, par Internet interposé), avec <a href="http://gegl.org">GEGL</a> — le nouveau moteur de traitement d'image de <a href="http://gimp.org">GIMP</a> — comme "support de cours".</p>
<p>La ruse est donc de vous faire contribuer à GEGL tout en vous enseignant la technologie OpenCL. Moi je dis que c'est "double victoire", mais certains pourraient prétendre que les libristes sont fourbes! :P</p></div><ul><li>lien nᵒ 1 : <a title="https://www.khronos.org/opencl/" hreflang="en" href="https://linuxfr.org/redirect/96310">Standard OpenCL</a></li><li>lien nᵒ 2 : <a title="http://www.gimp.org/news/2016/01/28/gegl-opencl-streamcomputing/" hreflang="en" href="https://linuxfr.org/redirect/96311">L'annonce sur le site web de GIMP</a></li><li>lien nᵒ 3 : <a title="http://gegl.org" hreflang="en" href="https://linuxfr.org/redirect/96312">Site web de GEGL</a></li><li>lien nᵒ 4 : <a title="http://opencl.org/" hreflang="en" href="https://linuxfr.org/redirect/96313">Site de l'initiative "OpenCL training"</a></li><li>lien nᵒ 5 : <a title="http://linuxfr.org/news/les-pilotes-graphiques-libres-retrospective-et-vue-sur-l-avenir" hreflang="fr" href="https://linuxfr.org/redirect/96314">Les pilotes graphiques libres : rétrospective et vue sur l’avenir</a></li><li>lien nᵒ 6 : <a title="https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie" hreflang="fr" href="https://linuxfr.org/redirect/96326">DLFP : GEGL 0.3.0 et babl 0.1.12 sont de sortie</a></li></ul><div><h2 id="offre-limitée">Offre limitée</h2>
<p>Le but de l'initiative est d'enseigner OpenCL et d'y intéresser les développeurs. L'initiative accepte pour le moment un maximum de 20 participants (7 sont déjà inscrits).</p>
<h2 id="gratuit-nexiste-pas">"gratuit" n'existe pas</h2>
<p>Le marché est le suivant: l'assurance qu'à la fin de la formation, vous saurez programmer OpenCL en échange de votre contribution à des projets libres utilisant OpenCL.</p>
<p>À ce jour, le "support de cours", c'est à dire le projet libre auquel vous contribuerez, est la plateforme de traitement d'image GEGL, utilisé notamment par GIMP, <a href="//linuxfr.org/news/g-mic-1-6-8-c-est-deja-noel-pour-les-traiteurs-d-images">G'Mic</a>, GNOME photos (voir cette très <a href="https://youtu.be/31omSU-VcRc">cool vidéo</a> pour avoir un aperçu du futur de GNOME photos propulsé par GEGL), MyPaint…<br>
Il est clairement indiqué sur la plateforme de développement (un projet sur <a href="https://github.com/OpenCL/GEGL-OpenCL">Github</a>) que GIMP/GEGL est le premier projet de portage officiel. D'autres projets similaires pourront donc voir le jour à l'avenir, dans le but d'enseigner OpenCL aux développeurs.</p>
<p>C'est donc un échange de service, plutôt que financier.</p>
<h2 id="organisation">Organisation</h2>
<p>Le projet est organisé par Vincent Hindriksen et Adel Johar qui souhaitent baser leur enseignement sur la <em>gamification</em> du développement en évaluant les vitesses d'exécution des <em>kernels</em> OpenCL (un <em>kernel</em> est une fonction OpenCL qui sera exécutée sur un périphérique) pour comparer des implémentations, et ainsi faire ressortir des "vainqueurs". Ils souhaitent également travailler l'optimisation des kernels pour pousser aux limites d'OpenCL.</p>
<p>On peut donc s'attendre à ce que les participants devraient bien connaître OpenCL à la suite de cette formation.</p>
<p>Victor Oliveira, le développeur GEGL qui a écrit la majeure partie du code OpenCL dans GEGL, participe au projet en tant que "conseiller".</p>
<h2 id="À-propos-de-streamcomputing">À propos de StreamComputing</h2>
<p><a href="http://streamcomputing.eu/">StreamComputing</a> est une société néerlandaise de développement logiciel, apparemment spécialisé (en se référant au site web) à l'optimisation, aux algorithmes et à la connaissance matérielle.<br>
Ils fournissent du service, de la consultation logicielle et des formations dans les domaines de la programmation GPU et du traitement parallélisé.</p>
<p><em>Note: l'auteur de cette dépêche n'a aucune relation avec cette société et ne la connaissait même pas avant cette annonce. Je ne fais que relayer l'information.</em></p></div><div><a href="https://linuxfr.org/news/formation-opencl-en-contribuant-a-gimp.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108057/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/formation-opencl-en-contribuant-a-gimp#comments">ouvrir dans le navigateur</a>
</p>
JehanBenoît Sibaudhttps://linuxfr.org/nodes/108057/comments.atomtag:linuxfr.org,2005:News/366472016-01-30T22:52:41+01:002016-01-31T20:51:15+01:00Les pilotes graphiques libres : rétrospective et vue sur l’avenirLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Cette année 2015 fut très riche et très excitante au sujet des pilotes graphiques libres. Grosse nouveauté, <a href="http://mesa3d.org/relnotes/11.0.0.html">Mesa 3D 11 a été annoncée le 12 septembre 2015</a>, avec une prise en charge d’OpenGL 4.2, après une très longue stagnation en version 3.3.</p>
<p>Cette dépêche fait donc la part belle aux récentes nouveautés de Mesa 3D, mais s’attarde aussi sur les actualités des puces graphiques embarquées, et se permet quelques incursions du côté de certains pilotes propriétaires dans leur collaboration avec les projets libres ou leurs initiatives qui profitent à tous.</p>
<p>Pour finir, nous nous permettrons d’annoncer quelques actualités à venir ayant pris racine en 2015.</p>
<p>Merci à tous les contributeurs de cette rétrospective !</p></div><ul><li>lien nᵒ 1 : <a title="http://mesamatrix.net/" hreflang="en" href="https://linuxfr.org/redirect/94815">The OpenGL vs Mesa matrix</a></li><li>lien nᵒ 2 : <a title="http://www.linuxsystems.it/2015/08/radeonsi-with-si-scheduler-humiliates-catalyst-in-all-tests/" hreflang="en" href="https://linuxfr.org/redirect/94816">Radeonsi with si scheduler humiliates Catalyst in all tests</a></li><li>lien nᵒ 3 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=Intel-ASTC-Mesa-Skylake" hreflang="en" href="https://linuxfr.org/redirect/94886">Intel Enables ASTC Texture Compression In Mesa For Skylake</a></li><li>lien nᵒ 4 : <a title="http://lists.freedesktop.org/archives/mesa-dev/2015-September/094286.html" hreflang="en" href="https://linuxfr.org/redirect/94968">[Mesa-dev] Mesa 11.0.0</a></li><li>lien nᵒ 5 : <a title="http://lists.freedesktop.org/archives/mesa-dev/2015-December/103231.html" hreflang="en" href="https://linuxfr.org/redirect/95065">[Mesa-dev] Mesa 11.1.0</a></li><li>lien nᵒ 6 : <a title="https://github.com/grate-driver/grate" hreflang="en" href="https://linuxfr.org/redirect/95821">Pilote libre Tegra 1 à 4</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#nouveaut%C3%A9s-de-mesa3d-%C3%A0-la-lumi%C3%A8re-du-trio-amd-intel--nvidia">Nouveautés de Mesa 3D à la lumière du trio AMD, Intel & NVIDIA</a><ul>
<li><a href="#un-peu-dhistoire">Un peu d’histoire</a></li>
<li><a href="#mesa3d110">Mesa 3D 11.0</a></li>
<li><a href="#mesa3d111">Mesa 3D 11.1</a></li>
<li><a href="#adaptive-scalable-texture-compression">Adaptive Scalable Texture Compression</a></li>
<li><a href="#progression-de-linitiative-amdgpu">Progression de l’initiative amdgpu</a></li>
<li><a href="#nir-new-intermediate-representation">NIR (New Intermediate Representation)</a></li>
<li><a href="#lentement-mais-s%C3%BBrement">Lentement mais sûrement</a></li>
</ul>
</li>
<li>
<a href="#%C3%89volution-du-c%C3%B4t%C3%A9-de-l%C3%A9cosyst%C3%A8me-arm">Évolution du côté de l’écosystème ARM</a><ul>
<li><a href="#freedreno">Freedreno</a></li>
<li><a href="#etnaviv">Etnaviv</a></li>
<li><a href="#vc4">VC4</a></li>
<li><a href="#powervr">PowerVR</a></li>
<li><a href="#lima--tamil">Lima & Tamil</a></li>
<li><a href="#tegra">Tegra</a></li>
<li><a href="#allwinner">Allwinner</a></li>
</ul>
</li>
<li>
<a href="#les-attentes-de-lann%C3%A9e-2016">Les attentes de l’année 2016</a><ul>
<li><a href="#vulkan">Vulkan</a></li>
<li><a href="#mesa3d112-quelques-pr%C3%A9dictions">Mesa 3D 11.2 : quelques prédictions</a></li>
<li><a href="#opengl-vendor-neutral-dispatch-library">OpenGL Vendor Neutral Dispatch Library</a></li>
<li><a href="#gpuopen">GPUOpen</a></li>
<li><a href="#openswr">OpenSWR</a></li>
<li><a href="#bient%C3%B4t-de-gros-changements-du-c%C3%B4t%C3%A9-des-performances-chez-radeonsi">Bientôt de gros changements du côté des performances chez radeonsi ?</a></li>
</ul>
</li>
</ul><p>Après des années de stagnation à n’annoncer que la prise en charge d’OpenGL 3.3, les développeurs de la bibliothèque Mesa 3D ont annoncé fin 2015 la prise en charge d’OpenGL 4.2 ! Actuellement, seuls les pilotes <em>radeonsi</em> et <em>nouveau</em> (pour les processeurs graphiques <em>Fermi</em> <a href="http://nouveau.freedesktop.org/wiki/CodeNames/#NVC0">NVC0</a>) prennent en charge OpenGL 4.1. Aucun pilote matériel ne prend encore en charge OpenGL 4.2 et les autres pilotes restent encore à OpenGL 3.3. Mais cela arrive vite ! Pourquoi un tel saut ? Qu’est‐ce que cela signifie ? Comment en profiter ? On fait le tour !</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f646c2e696c6c776965636b7a2e6e65742f622f6d6573612f32303136303132372e6d6573612d31312e322d6f70656e676c2d342e312d7562756e74752d7061646f6b612e706e67/20160127.mesa-11.2-opengl-4.1-ubuntu-padoka.png" alt="Mesa 11.2 et OpenGL 4.1 sur Ubuntu" title="Source : http://dl.illwieckz.net/b/mesa/20160127.mesa-11.2-opengl-4.1-ubuntu-padoka.png"></p>
<p><em>En attendant l’inclusion dans les dépôts officiels des distributions, les plus intrépides peuvent déjà bénéficier de toutes ces avancées en utilisant des dépôts tiers (comme les dépôts</em> <a href="https://launchpad.net/%7Epaulo-miguel-dias/+archive/ubuntu/mesa">padoka</a> <em>et</em> <a href="https://launchpad.net/%7Eoibaf/+archive/ubuntu/graphics-drivers">oibaf</a> <em>sur Ubuntu).</em></p>
<h2 id="nouveautés-de-mesa3d-à-la-lumière-du-trio-amd-intel--nvidia">Nouveautés de Mesa 3D à la lumière du trio AMD, Intel & NVIDIA</h2>
<h3 id="un-peu-dhistoire">Un peu d’histoire</h3>
<p>Pourquoi la pile graphique Mesa 3D est‐elle passée d’un coup de la prise en charge d’OpenGL 3.3 à OpenGL 4.1 sans passer par l’étape intermédiaire 4.0 ? En réalité, comme on peut le voir sur l’excellente page <a href="http://mesamatrix.net"><em>mesamatrix.net</em></a> (<a href="//linuxfr.org/news/mesamatrix-pour-suivre-les-progres-de-mesa">merci <em>Creak<</em></a>), chaque version d’OpenGL est une liste de différentes extensions à implémenter. Or, elles ne sont pas nécessairement implémentées dans l’ordre, ou bien elles le sont dans un ordre différent de celui auquel on pourrait s’attendre.</p>
<p>C’est pourquoi, par exemple, on peut voir que le pilote Intel <em>i965</em> a une certaine avance sur ses concurrents de chez NVIDIA et AMD concernant la prise en charge d’OpenGL 4.2 (les extensions 4.2 sont toutes implémentées), mais comme il lui reste à implémenter une extension 4.0 et une extension 4.1, il reste bloqué à la version 3.3. Il en était exactement de même pour les pilotes <em>nouveau</em> et <em>radeonsi</em> qui stagnaient en 3.3 malgré de nombreuses extensions 4.0 et 4.1 implémentées.</p>
<p>C’est pour cette raison que, bien que Mesa 3D annonce déjà la prise en charge d’OpenGL 4.2, en réalité, vous ne pourrez pas en bénéficier, car aucun pilote matériel n’est encore à ce niveau‐là…</p>
<p>Si Intel est encore en 3.3 (bouh, même les <em>reverseux</em> font mieux !), il faut tout de même noter qu’ils ont la liste d’extensions implémentées la plus complète, ils ont repris la tête du peloton après s’être fait temporairement doubler par le projet <em>nouveau</em>.</p>
<p>Si l’on est attentif, on remarque qu’en réalité Intel priorise la prise en charge d’<a href="https://fr.wikipedia.org/wiki/OpenGL_ES" title="Open Graphics Library for Embedded System — OpenGL pour systèmes embarqués">OpenGL ES</a> 3.1, qui regroupe un sous‐ensemble d’extensions communes à différentes versions d’OpenGL. On comprend donc pourquoi la prise en charge des extensions semble désordonnée malgré un grand nombre d’extensions développées… Intel est actuellement la seule plate‐forme à prendre entièrement en charge OpenGL ES 3.1, on ne peut pas être partout à la fois !</p>
<p>Pour bénéficier d’une prise en charge d’OpenGL supérieure à 3.3, il ne suffit pas d’utiliser une version récente de Mesa 3D, il faut que Mesa 3D ait été compilé avec une version récente de <a href="https://fr.wikipedia.org/wiki/LLVM" title="Low Level Virtual Machine — machine virtuelle de bas niveau">LLVM</a> (plus de détails sont fournis ci‐après).</p>
<h3 id="mesa3d110">Mesa 3D 11.0</h3>
<p>De gros changements du côté de Mesa 3D ont fait les titres à l’été 2015. </p>
<p>Le 23 juillet 2015, Dave Airlie <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=c3fad009c54fb526d236fd10f4377ce7fbb54459">a ajouté</a> à Mesa 3D la prise en charge de l’extension <code>ARB_shader_subroutine</code>, qui était la dernière qui restait à implémenter pour que Mesa 3D annonce la prise en charge d’OpenGL 4.0. Au même moment, Ilia Mirkin envoyait du code pour la prise en charge du <a href="https://fr.wikipedia.org/wiki/pavage" title="Définition Wikipédia">pavage</a> (<em>tesselation</em>) pour les cœurs graphiques Intel, et Marek Olšák en <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=bac12c8948681a23fd1a8f8a6bbb5523ccfe0939">faisait de même</a> pour les cœurs et cartes graphiques AMD.</p>
<p>Mais cela ne s’arrêtait pas là, car à cet instant il ne manquait plus à Mesa 3D qu’une seule extension pour annoncer la prise en charge d’OpenGL 4.1 : <code>GL_ARB_shader_precision</code>, et une seconde extension pour annoncer la prise en charge d’OpenGL 4.2 : <code>ARB_shader_image_load_store</code>.</p>
<p>Tout cela est arrivé très vite : Dave Airlie <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-July/090032.html">annonça</a> la prise en charge d’OpenGL 4.1 le 28 juillet, et l’extension <code>ARB_shader_image_load_store</code> fut <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=d03c65793a5ee31f1138cbd0fba6fac6cd942428">ajoutée le 11 août</a>. Ainsi, <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=3c04a90e91a64a4a09d77c76c6ddcaca949e9b0e">la liste des extensions nécessaires fut enfin complète</a> pour annoncer la prise en charge d’OpenGL 4.2.</p>
<p>Jusque‐là, Mesa 3D n’annonçait donc que la prise en charge d’OpenGL 3.3. Certains proposaient de renommer Mesa 3D 10.7 en Mesa 3D 11, qui allait être distribué en septembre. Il faut dire que ça valait le coup ! Emil Velikov <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=6f2d88927a77f902157704d16b70b1265e0ca357">sanctionna</a> cette numérotation le premier août et <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-September/094286.html">publia</a> Mesa 3D 11.0 le 12 septembre.</p>
<p>Mais attention, le pilote <a href="https://fr.wikipedia.org/wiki/Gallium3D" title="Définition Wikipédia">Gallium3D</a> <em>radeonsi</em> (le pilote qui gère les puces graphiques Radeon basées sur l’architecture <a href="https://en.wikipedia.org/wiki/Graphics_Core_Next"><em>Graphics Core Next</em></a>, ou GCN) utilise un compilateur de <a href="https://fr.wikipedia.org/wiki/Shader" title="nuanceur"><em>shader</em></a> construit à partir de LLVM. L’architecture GCN étant utilisée par toutes les cartes graphiques d’AMD depuis les Radeon HD 7xxx, pour prendre en charge OpenGL 4.0, Mesa 3D devait être compilé avec LLVM 3.6.2, tandis que pour OpenGL 4.1 et supérieur, Mesa 3D devait être compilé avec LLVM 3.7, qui était alors annoncée pour fin août. C’est finalement le premier septembre qu’<a href="http://lists.llvm.org/pipermail/llvm-announce/2015-September/000065.html">Hans Wennborg a annoncé la publication de LLVM 3.7</a>, ce qui a enfin permis au public libriste de bénéficier d’OpenGL 4.x.</p>
<h3 id="mesa3d111">Mesa 3D 11.1</h3>
<p>Mesa 3D 11.1 voit l’arrivée d’un tout nouveau pilote nommé <em>VirGL</em> basé sur <a href="https://fr.wikipedia.org/wiki/Gallium3D" title="Définition Wikipédia">Gallium3D</a>. Ce pilote permet à une machine virtuelle de bénéficier de l’accélération matérielle de la machine hôte. Pour en bénéficier, il faut utiliser un noyau Linux 4.4 (qui n’est sorti qu’en janvier 2016) et un <a href="https://fr.wikipedia.org/wiki/QEMU" title="Définition Wikipédia">QEMU</a> récent.</p>
<p>Pour rester du côté de la virtualisation, le pilote VMware (<em>VMWgfx</em>) prend désormais en charge OpenGL 3.3.</p>
<p>Du côté de la bibliothèque de calcul intensif exécuté sur processeurs graphiques, <a href="https://fr.wikipedia.org/wiki/OpenCL" title="Open Computing Language">OpenCL</a>, le travail a commencé pour les cartes NVIDIA des générations <em>Tesla</em> <a href="http://nouveau.freedesktop.org/wiki/CodeNames/#NV50">NV50</a> et <em>Fermi</em> <a href="http://nouveau.freedesktop.org/wiki/CodeNames/#NVC0">NVC0</a>. Très peu de choses sont implémentées pour le moment, mais c’est encourageant.</p>
<p>Le pilote Intel permet désormais l’<a href="https://fr.wikipedia.org/wiki/anticr%C3%A9nelage" title="Définition Wikipédia">anticrénelage</a> <em>16× <a href="https://en.wikipedia.org/wiki/Multisample_anti-aliasing">MSAA</a></em> (à partir des processeurs <em><a href="https://fr.wikipedia.org/wiki/Skylake" title="Définition Wikipédia">Skylake</a></em>).</p>
<p>AMD a contribué à la gestion du décodage <a href="https://fr.wikipedia.org/wiki/H.265/HEVC">H.265/HEVC</a> pour Gallium3D, accessible via l’interface <a href="https://fr.wikipedia.org/wiki/Video_Acceleration_API">VA-API</a>.</p>
<p>Côté plate‐forme ARM, le pilote <em>Freedreno</em> prend désormais en charge OpenGL 3.1, et le pilote <em>VC4</em> pour <em>Raspbery Pi</em> a été beaucoup retravaillé. Vous trouverez plus de détails concernant ces processeurs graphiques plus loin dans la dépêche.</p>
<h3 id="adaptive-scalable-texture-compression">Adaptive Scalable Texture Compression</h3>
<p>Intel a publié en août 2015 du code pour prendre en charge le format <em>ASTC</em> à partir de la plate‐forme <em>Skylake Gen9</em>. ASTC, pour <em><a href="https://en.wikipedia.org/wiki/Adaptive_Scalable_Texture_Compression">Adaptive Scalable Texture Compression</a></em> est un format de compression de texture exempt de brevets destiné à remplacer <em><a href="https://en.wikipedia.org/wiki/S3_Texture_Compression">S3TC</a></em> (bardé de brevets, lui). Le principe de ces formats de compression est que la décompression est faite par la carte graphique elle‐même. Ainsi, à la différence, par exemple, d’une texture JPEG qui serait décompressée par le processeur généraliste (qui est donc mis à contribution) et qui serait ensuite envoyée décompressée à la carte graphique (ce qui consomme beaucoup de bande passante), la texture est envoyée directement compressée à la carte qui se charge de la décompresser elle‐même, économisant donc les ressources de calcul du processeur généraliste et la bande passante entre la mémoire centrale et la mémoire dédiée du processeur graphique. En plus d’être exempt de brevet, ce nouveau format est bien évidemment meilleur et a la bonne idée d’être officiellement pris en charge par les récentes spécifications OpenGL, OpenGL ES et DirectX. Les fabricants aussi expriment <a href="http://www.phoronix.com/scan.php?page=news_item&px=MTE1NDk">leurs enchantements</a> concernant ce nouveau format, ASTC est donc le format du futur qui met tout le monde d’accord !</p>
<h3 id="progression-de-linitiative-amdgpu">Progression de l’initiative amdgpu</h3>
<p>En octobre 2014, lors de la <a href="http://www.x.org/wiki/Events/XDC2014/"><em>XDC 2014</em></a> (<em>X.Org developer conference</em>), Alex Deucher a annoncé qu’AMD souhaitait augmenter le partage de code sous Linux entre le pilote libre et le pilote propriétaire. Pour cela, les développeurs allaient créer un nouveau pilote noyau nommé AMDGPU qui pourrait être utilisé aussi bien par le pilote libre Mesa 3D/Gallium3D que par un nouveau pilote propriétaire redistribué par AMD, la partie binaire et fermée étant limitée à l’espace utilisateur.</p>
<p>Le 20 avril 2015, Alex Deucher publie la <a href="http://lists.freedesktop.org/archives/dri-devel/2015-April/081501.html">version initiale du pilote <em>amdgpu</em></a>. Ce nouveau pilote est créé comme une copie du pilote <em>radeon</em> et est ensuite adapté pour gérer les particularités des nouveaux processeurs graphiques. Il peut gérer les puces CI (<em>Sea Islands</em>) pour tester le pilote, mais celui‐ci est prévu pour les nouvelles cartes (<em>Volcanic Islands</em> et suivantes). Le <a href="http://lists.freedesktop.org/archives/dri-devel/2015-June/084083.html">pilote a été intégré dans le noyau Linux 4.2</a> et reçoit depuis des améliorations à chaque nouvelle version du noyau. Par exemple, une nouvelle gestion de l’alimentation appelée <a href="http://lists.freedesktop.org/archives/dri-devel/2015-November/094230.html"><em>powerplay</em></a>, destinée à remplacer DPM (<em>Dynamic Power Management</em>), sera intégrée à la version 4.5 de Linux. Dans le même temps, la partie <em>libdrm</em> a été intégrée et le pilote Gallium3D <em>radeonsi</em> a été mis à jour pour gérer le pilote <em>amdgpu</em>. En revanche, à l’heure actuelle, il n’y a pas d’information sur la publication du pilote propriétaire qui sera basé sur le pilote <em>amdgpu</em>. Le pilote <em>Vulkan</em> d’AMD devrait dans un premier temps être seulement disponible pour Linux sous forme binaire, et il est possible que le premier pilote propriétaire basé sur le pilote <em>amdgpu</em> sera celui intégrant <em>Vulkan</em>.</p>
<p>Pendant ce temps, AMD a renommé sa suite de pilotes propriétaires et le centre de contrôle <em>Catalyst Control Center</em> en <em>Radeon Software Crimson Edition</em>. Si les utilisateurs de Windows bénéficient déjà de changements sensibles (amélioration des performances et nouvelle interface utilisateur), les utilisateurs de GNU/Linux ne voient que le même pilote et les mêmes outils sous un nouveau nom. Il est fort probable que ce pilote <em>amdgpu</em> fasse partie de cette nouvelle stratégie commerciale et que les améliorations promises par Crimson seront fournies lorsque le pilote propriétaire rebasé sur <em>amdgpu</em> sera publié. Tout comme le pilote <em>amdgpu</em> est prévu pour les cartes de dernière génération, la suite Crimson annonce ne prendre en charge que les cartes basées sur l’architecture GCN (<em>Graphics Core Next</em>), ce qui correspond à peu près au même périmètre.</p>
<h3 id="nir-new-intermediate-representation">NIR (New Intermediate Representation)</h3>
<p>Le code <a href="https://fr.wikipedia.org/wiki/GLSL" title="Définition Wikipédia">GLSL</a> des jeux ou applications 3D nécessite d’être compilé en langage machine avant de pouvoir être exécuté par les unités de <em><a href="https://fr.wikipedia.org/wiki/shader" title="Définition Wikipédia">shader</a></em> du processeur graphique. Mesa 3D utilise une représentation intermédiaire appelé <em>GLSL IR</em>, mais celle‐ci a des défauts difficiles à résoudre. Dans le cadre d’un stage chez Intel, Connor Abbott avait travaillé sur un nouveau langage intermédiaire qui permet de mieux gérer le code des <em>shaders</em> et de meilleures optimisations. C’est ainsi que <em>NIR</em> est né.</p>
<p>Présenté a la <a href="http://www.x.org/wiki/Events/XDC2014/" title="X.Org Developer’s Conference"><em>XDC 2014</em></a> à Bordeaux, il a été <a href="https://www.phoronix.com/scan.php?page=news_item&px=Mesa-NIR-Lands">intégré dans Mesa 3D</a> en janvier 2015, grâce au travail de Jason Ekstrand de chez Intel (<a href="http://lists.freedesktop.org/archives/mesa-dev/2014-December/072761.html">sa présentation de NIR sur la liste <em>mesa-dev</em> vaut la lecture</a>). NIR a <a href="http://cgit.freedesktop.org/mesa/mesa/log/?id=d3636da9026dd10493fb57b0d6803e33166abd1b&qt=grep&q=nir">continué de mûrir</a> tout au long de l’année et un nombre croissant de pilotes l’utilisent désormais. NIR est aujourd’hui utilisé par défaut par le pilote Intel, le pilote <em>VC4</em> (Raspberry <em>Pi</em> 1 et 2) et le pilote <em>Freedreno</em>.</p>
<p>Un convertisseur SPIR-V vers NIR est également en cours de développement. SPIR-V est un format standard de représentation intermédiaire de <em><a href="https://fr.wikipedia.org/wiki/shader" title="Définition Wikipédia">shader</a></em>. C’est un format en <em><a href="https://fr.wikipedia.org/wiki/bytecode" title="Définition Wikipédia">bytecode</a></em> pré‐optimisé qui est ou sera utilisé par <a href="https://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a> 2.1 et <em>Vulkan</em>. Avec OpenGL, les <em><a href="https://fr.wikipedia.org/wiki/shaders" title="Définition Wikipédia">shaders</a></em> <a href="https://fr.wikipedia.org/wiki/GLSL" title="Définition Wikipédia">GLSL</a> sont fournis au pilote 3D en format texte, le pilote doit donc embarquer un analyseur de texte, un optimiseur de code et enfin un compilateur pour générer le code machine. Avec SPIR-V, le pilote n’a plus besoin que du compilateur final (et éventuellement d’un petit optimiseur), ce qui est plus léger à la fois en empreinte mémoire et en temps de calcul.</p>
<h3 id="lentement-mais-sûrement">Lentement mais sûrement</h3>
<p>Vous vous souvenez peut‐être de la <a href="https://www.indiegogo.com/projects/improve-opengl-support-for-the-linux-graphics-drivers-mesa#/">campagne de financement participatif</a> visant à salarier Timothy Arceri (il n’en est pas à <a href="//linuxfr.org/users/florentin_raud/journaux/succes-de-l-extension-de-mesa-en-financement-participatif">son coup d’essai</a>) pour travailler sur l’implémentation de l’extension <em>Array of array</em> (prérequis de OpenGL ES 3.10 et GLSL 4.30) ? Cela a été long, mais le travail n’a pas été abandonné ! Ce dernier travail de Timothy <a href="http://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=AoA">a été fusionné dans Mesa 3D</a> et la première à en bénéficier est la plate‐forme Intel (depuis le 4 novembre), les autres plates‐formes devraient suivre sous peu. Tout cela a mis beaucoup de temps parce que le processus de revue pour inclusion est assez lent mais, bonne nouvelle, Timothy <a href="http://www.itsqueeze.com/2015/09/arrays-of-arrays-update-and-where-to-from-here/">annonçait en septembre</a> qu’à partir de novembre, il serait embauché par Collabora pour travailler à temps plein sur Mesa 3D. <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=64831832791139328a67b80387f062d39e304d24">Sa priorité désormais</a> est de travailler sur l’extension <code>GL_ARB_enhanced_layouts</code>, une extension OpenGL 4.4.</p>
<p>Côté OpenCL, beaucoup de choses sont encore à faire… Comme indiqué précédemment, le développement pour <em>nouveau</em> est balbutiant. Du côté de <em>radeonsi</em>, la version 1.1 de la norme est exploitable, mais la prise en charge des images n’y est pas fonctionnelle. En revanche, le développement de <a href="http://www.freedesktop.org/wiki/Software/Beignet/"><em>Beignet</em></a> (Intel) est assez actif, mais a lieu en dehors de Mesa 3D. Pour le moment, si vous souhaitez bénéficier de l’OpenCL (par exemple avec <em><a href="http://www.darktable.org/">Darktable</a></em>), il vous faudra encore vous tourner vers les pilotes propriétaires pour les cartes autres qu’Intel. On peut cependant noter que <em>Clover</em> intègre déjà certaines fonctionnalités de la norme 1.2, par exemple <em><a href="http://www.phoronix.com/scan.php?page=news_item&px=Clover-CL1.2-Create-Image">clCreateImage</a></em>. Espérons que les choses seront plus encourageantes en 2016 !</p>
<h2 id="Évolution-du-côté-de-lécosystème-arm">Évolution du côté de l’écosystème ARM</h2>
<p>Les systèmes monopuces (<a href="https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce"><em>System On a Chip</em></a>) ont la particularité d’avoir un découpage explicite en modules des fonctionnalités fournies ensemble par les processeurs graphiques d’ordinateurs de bureau. Là où, grâce à un seul pilote, un processeur graphique de bureau prend en charge la gestion de l’affichage (sortie vidéo), les accélérations 2D et 3D, ainsi que les accélérations de l’encodage et du décodage vidéo, les systèmes monopuces ARM ont souvent des modules et pilotes séparés pour les différentes parties. Modules qui peuvent même venir de concepteurs différents.</p>
<p>De nombreux moteurs d’affichage utilisés par les systèmes monopuces ARM ont un pilote développé en amont dans le noyau Linux, et de nouveaux pilotes sont régulièrement intégrés. On peut citer <em>omap</em>, <em>imx</em>, etc. Mais beaucoup de modules d’accélération 2D/3D ont un pilote intégré ; pour l’instant, il y a le pilote <em>freedreno</em>, tandis qu’un pilote <em>etnaviv</em> est en développement pour une intégration prochaine (peut‐être pour le noyau 4.5 ?).</p>
<h3 id="freedreno">Freedreno</h3>
<p>Les processeurs graphiques <em><a href="https://fr.wikipedia.org/wiki/Adreno">Adreno</a></em> des systèmes monopuces <em><a href="https://fr.wikipedia.org/wiki/Snapdragon">Snapdragon</a></em> de <a href="https://fr.wikipedia.org/wiki/Qualcomm">Qualcomm</a> utilisent un pilote nommé <em>freedreno</em>. Le développement de ce pilote libre a été démarré en rétro‐ingénierie par Rob Clark pendant son temps libre ; Rob a ensuite été embauché par Red Hat pour continuer de travailler dessus et sur la <a href="https://fr.wikipedia.org/wiki/pile%20graphique%20Linux" title="Définition Wikipédia">pile graphique Linux</a> par la même occasion. Les processeurs graphiques <em>Adreno</em> ont une base commune avec les processeurs graphiques <em>Radeon</em> (Qualcomm a racheté la branche processeurs graphiques mobiles d’AMD), le fait que les <em>Radeon</em> aient un pilote libre et de la documentation publique aurait aidé la rétro‐ingénierie. Aujourd’hui, le pilote progresse bien, il est actuellement capable de gérer jusqu’à OpenGL ES 3.0 (pour le matériel qui le prend en charge), reçoit la participation de <a href="https://fr.wikipedia.org/wiki/Qualcomm">Qualcomm</a> et la prise en charge des nouveaux processeurs graphiques est intégrée peu à peu. Un travail est également en cours pour que ce pilote marche avec Android, et peut‐être même deviendra‐t‐il un jour le pilote officiel pour Android ?</p>
<h3 id="etnaviv">Etnaviv</h3>
<p>Les modules d’accélération 2D/3D vectoriels de <em>Vivante</em> sont pris en charge par le pilote libre <em>etnaviv</em>. Les processeurs graphiques <em>Vivante</em> bénéficient d’un pilote noyau libre qui utilise l’<a href="https://fr.wikipedia.org/wiki/Interface_de_programmation" title="Application Programming Interface — interface de programmation">API</a> <em><a href="https://fr.wikipedia.org/wiki/Framebuffer_Linux" title="Framebuffer Linux">fbdev</a></em> (mais qui n’est pas intégré au noyau Linux en amont) et d’une partie propriétaire en espace utilisateur.</p>
<p>Initialement nommé <em>etna_viv</em>, le projet a été lancé par <a href="https://blog.visucore.com">Wladimir J. van der Laan</a> et rendu public au début de l’année 2013. Il a créé un pilote libre en espace utilisateur par rétro‐ingénierie. Ensuite, Christian Gmeiner a pris le relai pour créer un pilote noyau <a href="https://fr.wikipedia.org/wiki/Kernel-based_mode-setting" title="Kernel‐based mode‐setting">KMS</a> et <a href="https://fr.wikipedia.org/wiki/Direct_rendering_infrastructure" title="Direct rendering infrastructure">DRM</a>, mais y travaillant uniquement sur son temps libre, la progression était lente. Heureusement, au printemps 2015, Lucas Stach a diffusé une série de modifications correspondant à un pilote <a href="https://fr.wikipedia.org/wiki/Kernel-based_mode-setting" title="Kernel‐based mode‐setting">KMS</a>. Ce pilote a été créé sur la base du travail de Christian et activement développé par Russell King (<em>Le</em> mainteneur ARM dans le projet Linux) et Lucas dans le cadre de son travail chez Pengutronix.</p>
<p>Plusieurs mises à jour ont depuis été diffusées sur la liste de diffusion <em>dri-devel</em>, et le code pour la <em>libdrm</em> et Mesa 3D (Gallium3D) progresse avec le travail de Christian, Russell et Lucas. D’ailleurs, Christian maintient sur son profil GitHub un dépôt <em><a href="https://github.com/austriancoder/libdrm">libdrm</a></em> et un dépôt <a href="https://github.com/austriancoder/mesa-1">Mesa 3D</a>. Les précédentes diffusions sur la liste de de diffusion <em>dri-devel</em> du noyau Linux avaient seulement pour but de recueillir des retours des autres développeurs de pilotes DRM, mais le 4 décembre une série de correctifs de la partie noyau du pilote a été diffusée pour relecture dans le but, cette fois, d’avoir une intégration dans la branche principale. Une deuxième version avec quelques corrections a été diffusée le 9 décembre, et le 15 décembre une <a href="http://lists.freedesktop.org/archives/dri-devel/2015-December/097164.html">demande d’intégration</a> dans le noyau 4.5 a été diffusée sur la liste de diffusion <em>dri-devel</em>.</p>
<p>On est donc en bonne voie de pouvoir utiliser une Fedora avec bureau GNOME 3 (par exemple) de façon fluide sur une <em>Wandboard</em> ou une <em>Cubox-i</em> dans les mois à venir (ou autre utilisation d’OpenGL).</p>
<h3 id="vc4">VC4</h3>
<p>Le processeur graphique des Raspberry <em>Pi</em> (1 et 2) est le <em>VC4</em>. Broadcom a embauché Eric Anholt pour travailler sur un pilote libre (KMS/DRM + Mesa 3D/Gallium3D). Côté Mesa, le pilote Gallium3D <em>vc4</em> est intégré en amont depuis quelque temps et continue d’évoluer. Côté noyau, une première version du pilote a été intégrée dans la version 4.4, cette première version permet la prise en charge du module de gestion de l’affichage. Le code permettant l’accélération 3D devrait être intégré dans la version 4.5.</p>
<h3 id="powervr">PowerVR</h3>
<p>Nous n’avons pas d’informations sur un éventuel pilote libre pour processeur graphique <em>PowerVR</em>, mais Imagination cherche un programmeur pour travailler sur un pilote Linux (espérons que ce soit un pilote libre)…</p>
<h3 id="lima--tamil">Lima & Tamil</h3>
<p>Les processeurs graphiques <a href="https://en.wikipedia.org/wiki/Mali_%28GPU%29"><em>Mali</em></a> (venant directement d’ARM) ont pour eux le projet libre de pilote <em>Lima</em>. Bien qu’ayant démarré début 2012 et ayant bien progressé (il a réussi à faire fonctionner <em>Quake III Arena</em>), le projet est en pause depuis plus de deux ans. La dernière nouvelle sur le <a href="http://limadriver.org/" title="limadriver.org">site officiel</a> était de mars 2013, mais un appel à contribution est apparu le 20 décembre 2015, signifiant peut‐être un redémarrage du projet (en tout cas une certaine volonté). Il semblerait qu’ARM ne le voyait pas d’un très bon œil, en effet sur le <a href="http://libv.livejournal.com/27461.html"><em>blog</em> de Luc Verhaegen</a> on peut lire une publication datant du 23 avril 2015 :</p>
<blockquote>
<p><em>In May 2013, I wrote another proposal to ARM for an open source strategy for Mali (the first was done in Q2 2011 as part of Codethink), hoping that in the meantime sentiments had shifted enough and that the absence of an in‐between company would make the difference this time round. It got the unofficial backing of some people inside ARM, but they just ended up getting their heads chewed off, and I hope that they didn’t suffer too much for trying to do the right thing. The speed with which this proposal was rejected by Jem Davies (ARM MPD VP of Technology), and the undertone of the email reply he sent me, suggests that his mind was made up beforehand and that he wasn’t too happy about my actions this time either.</em></p>
<p>Traduction :</p>
<p>« En mai 2013, j’ai écrit une nouvelle proposition à ARM à propos d’une stratégie <em>open source</em> pour Mali (la première avait été faite au 2<sup>e</sup> trimestre 2011 dans le cadre de Codethink), espérant qu’entretemps en l’absence de société intermédiaire, leur point de vue aurait significativement évolué. Elle a reçu un soutien non officiel de gens chez ARM, mais ils ont juste obtenu le droit de se taire, et j’espère qu’ils n’ont pas trop souffert d’avoir essayé de faire le bon choix. La vitesse avec laquelle ma proposition a été rejetée par Jem Davies, et le ton de son courriel de réponse, suggérait que son opinion était déjà faite et qu’il n’était toujours pas très emballé par mes actions. »</p>
</blockquote>
<p>Sur ce même <em>blog</em>, on peut lire que l’écriture du pilote <em>Mali</em> lui a causé beaucoup de déboires ; il soupçonne même que son renvoi d’une société fût causé par le <em>lobbying</em> d’ARM :</p>
<blockquote>
<p><em>When Codethink ran into a cashflow issue in October 2012 (which apparently was resolved quite successfully, as Codethink has grown a lot more since then), I was shown the door. This wasn’t too unreasonable a decision given my increasing disappointment with how Lima was being treated, the customer projects I was being sent on, and the assumption that a high profile developer like me would have an easy time getting another employer. During the phonecall announcing my dismissal, I did however get told that ARM had already been informed about my dismissal, so that business relations between ARM and Codethink could be resumed. I rather doubt that that is standard procedure for dismissing people.</em></p>
<p>Traduction :</p>
<p>« Quand Codethink a eu des problèmes de trésorerie en octobre 2012 (qui apparemment ont été plutôt bien résolus, puisque Codethink s’est beaucoup développé depuis), on m’a mis à la porte. Cela n’était pas une si mauvaise décision vue ma déception grandissante quant à la manière dont a été traité <em>Lima</em>, les projets client sur lesquels j’ai été envoyé, et en considérant qu’un développeur hautement qualifié comme moi aurait de la facilité à trouver un autre employeur. Pendant la conversation téléphonique annonçant mon licenciement, on m’a cependant laissé entendre qu’ARM avait déjà été informé de mon départ, de telle sorte que les relations commerciales entre ARM et Codethink pourraient être restaurées. Je doute que ce soit une procédure standard de licenciement. »</p>
</blockquote>
<p>Tout cela est vraiment dommage, car on peut trouver ce processeur graphique dans une multitude de systèmes monopuces comme, par exemple, les Allwiner A10 et A20, la majorité des Exynos… Luc Verhaegen, l’auteur des pilotes <em>Lima</em> et <em>Tamil</em> (pour les processeurs graphiques Mali <em>T-Series</em>), explique qu’il n’est plus aussi motivé pour nettoyer et faire évoluer le code de ces pilotes. <em>Lima</em> et <em>Tamil</em> existent, mais seul <em>Lima</em> est sorti. Personne n’est suffisamment intéressé pour l’embaucher et financer le travail sur ces pilotes. Beaucoup de monde (personnes, entreprises, organisations) lui expliquent que cela ne sert à rien et que l’existence d’un pilote libre pourrait même être contre‐productif. <a href="http://www.linaro.org/">Linaro</a>, une organisation dont le but est de faire tourner Linux sur ARM, explique qu’elle compte sur le soutien d’ARM pour avancer ; mais Linaro (et certainement d’autres…), ne voulant pas se fâcher avec ARM, ne veut pas subventionner Luc Verhaegen.</p>
<p>En tout cas, une chose est sure, c’est que le manque de soutien général l’a réellement démotivé pendant pas mal de temps (au moins deux ans), mais il semblerait que cette période soit passée, peut‐être travaillera‐t‐il à nouveau sur Lima :</p>
<blockquote>
<p><em>When I was putting together the FOSDEM Graphics DevRoom schedule around christmas, I noticed that there was a inexcuseably low amount of talks, and my fingers became itchy again. The consulting job had boosted morale sufficiently to do some code again and showing off some initial renders on Mali T series seemed doable within the 5 or so weeks left. It gave the FOSDEM graphics devroom another nice scoop, and filled in one of the many many gaps in the schedule. This time round i didn’t kid myself that it would change the world or help boost my profile or anything. This time round, i was just going to prove to myself that i have learned a lot since doing Lima, and that i can do these sort of things still, with ease, while having fun doing so and not exerting myself too much. And that’s exactly what I did, nothing more and nothing less.</em></p>
<p>Traduction :</p>
<p>« Lorsque j’étais en train de mettre sur pieds le programme de la conférence des développeurs de pilotes graphiques pour le <a href="https://fr.wikipedia.org/wiki/FOSDEM" title="Définition Wikipédia">FOSDEM</a> aux environs de Noël, j’ai remarqué qu’il y avait un manque inexcusable de conférences, et mes doigts se mirent à nouveau à me démanger. Le travail de consultant a suffisamment renforcé mon moral pour coder à nouveau et présenter quelques rendus initiaux sur le Mali <em>série T</em> semblait faisable dans les quelque cinq prochaines semaines restantes. J’ai donné à l’assemblée des développeurs de pilotes graphiques du FOSDEM un scoop sympa, et rempli une des très nombreuses lacunes du programme des conférences. Cette fois, je ne voulais pas jouer à changer le monde ou me faire mousser, mais je voulais me prouver que j’avais beaucoup appris depuis que j’avais travaillé sur <em>Lima</em>, et que je pouvais encore faire ce genre de choses, avec facilité, tout en prenant du plaisir à le faire et sans trop me surmener. Et c’est exactement ce que j’ai fait, ni plus ni moins. »</p>
</blockquote>
<p>Malgré tout, <a href="http://www.phoronix.com/scan.php?page=news_item&px=Allwinner-A10-DRM-Display">les choses avancent</a> dans la prise en charge des <em>Mali</em> sur Linux. Phoronix avait publié un <a href="https://www.phoronix.com/scan.php?page=news_item&px=Liba-Tamil-Lost-Traction">petit état des lieux en avril</a>, à défaut de code, il faudra s’en contenter pour le moment.</p>
<h3 id="tegra">Tegra</h3>
<p>Les systèmes monopuces de la gamme <em>Tegra</em> semblent avoir leur pilote principal de moteur d’affichage nommé <em>tegra</em>, et NVIDIA a travaillé pour utiliser <em>Nouveau</em> pour les <a href="https://en.wikipedia.org/wiki/Tegra">Tegra K1 et X1</a>. Ces systèmes monopuces utilisent des processeurs graphiques directement dérivés de leurs homologues dédiés aux ordinateurs de bureau (respectivement les architectures <em>Kepler</em> et <em>Maxwell</em>). Pour les systèmes monopuces plus anciens <em>Tegra</em> 1 à 4, il existe une documentation partielle, un pilote libre (<em>grate</em>) existe.</p>
<h3 id="allwinner">Allwinner</h3>
<p>Le pilote du moteur d’affichage des systèmes monopuces <em>Allwinner</em> est développé par un employé de <a href="http://free-electrons.com">Free Electrons</a>. En revanche, la partie accélération 3D est gérée par des modules <em>Mali</em> de chez ARM ou <em>PowerVR</em> de chez Imagination Technologies, qui ne possèdent pas de pilotes libres. Ses pilotes sont nommés <em>sun4i</em> et <em>sunxi</em> dans le noyau Linux.</p>
<h2 id="les-attentes-de-lannée-2016">Les attentes de l’année 2016</h2>
<h3 id="vulkan">Vulkan</h3>
<p><a href="https://www.khronos.org/vulkan">Vulkan</a> est une <a href="https://fr.wikipedia.org/wiki/Interface_de_programmation" title="Application Programming Interface — interface de programmation">API</a> poussée par le groupe <a href="https://fr.wikipedia.org/wiki/Khronos_Group">Khronos</a> (les mêmes derrière OpenGL) qui a pour but affiché de remplacer OpenGL dans le futur et de proposer dès maintenant une interface plus moderne. Vulkan se veut multi‐plate‐forme. Il est soutenue par de nombreux acteurs majeurs du marché, et annonce de bien meilleures performances qu’OpenGL (voir la page Wikipédia <a href="https://fr.wikipedia.org/wiki/Vulkan_%28API%29"><em>Vulkan</em></a> pour plus de détails et de vulgarisation en français). Connue initialement sous le nom de code <em>glNext</em>, Vulkan a été annoncé lors de la <em><a href="https://fr.wikipedia.org/wiki/Game_Developers_Conference" title="Game Developers’ Conference">Game Developers’ Conference</a></em> de 2015. La publication des spécifications était attendue pour fin 2015, mais cela ne devrait plus tarder ! Cependant, si nous savons que certains pilotes propriétaires seront publiés avec la prise en charge de Vulkan dès la publication des spécifications, il faudra certainement attendre plus de temps pour en voir une implémentation dans les pilotes Mesa 3D.</p>
<h3 id="mesa3d112-quelques-prédictions">Mesa 3D 11.2 : quelques prédictions</h3>
<p>Intel est en train de rattraper son (apparent) retard, mais les nouveautés intéressantes sont arrivées trop tard pour faire partie de la version 11.1, comme le code pour le pavage (<em>tesselation</em>), pourtant <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-December/102235.html">déjà fonctionnel</a> chez Intel.</p>
<p>Du côté des radeon R600, le <a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=33404f141551d0ace00101e78f9b2d93cad135f1">code pour le pavage est là aussi</a>.</p>
<p>Chose très intéressante, il ne manquera plus que deux extensions (<code>GL_ARB_vertex_attrib_64bit</code> et <code>GL_ARB_gpu_shader_fp64</code>) pour que le pilote Intel fasse le grand saut depuis OpenGL 3.3 vers OpenGL 4.2. Vivement Mesa 3D 11.2 !</p>
<p>Du côté de chez AMD, les cartes de la génération R600 et celles prises en charge par le pilote <em>radeonsi</em> n’attendent plus que les deux extensions <code>GL_ARB_shader_atomic_counters</code> et <code>GL_ARB_shader_image_load_store</code> pour passer d’OpenGL 4.1 à OpenGL 4.2. Il en est de même pour les cartes NVIDIA de la génération <em>NVC0</em>. Quel pilote activera la gestion d’OpenGL 4.2 le premier ? Intel va‐t‐il laver l’affront ? La course est serrée !</p>
<p>En revanche, nous le savons déjà, les puces graphiques <em>NV50</em> n’arriveront jamais à l’OpenGL 4 de par leurs limites matérielles… Dommage, mais que cela ne gâche pas la fête : Mesa 3D 11.2 est très attendu !</p>
<h3 id="opengl-vendor-neutral-dispatch-library">OpenGL Vendor Neutral Dispatch Library</h3>
<p>Le 30 septembre 2015, Kyle Brenneman a annoncé son projet <em><a href="https://github.com/NVIDIA/libglvnd">libglvnd</a></em> (<em>OpenGL Vendor Neutral Dispatch Library</em>) sur la liste de diffusion <em><a href="https://www.mail-archive.com/mesa-dev%40lists.freedesktop.org/msg94800.html">mesa-dev</a></em> en vue d’une intégration. C’est une initiative poussée par NVIDIA depuis 2013 et qui semble plutôt bien vue par Mesa 3D, mais à quoi cela sert‐il ? Cela servirait à pouvoir utiliser plusieurs implémentations d’OpenGL en même temps, par exemple la pile OpenGL Mesa 3D sur un écran et la pile propriétaire <em>nvidia</em> sur un autre. Aaron Plattner de chez NVIDIA <a href="https://devtalk.nvidia.com/default/topic/908423">a publié un premier pilote</a> (bêta) compatible <em>libglvnd</em> le 5 janvier. Cela ne concerne que le pilote propriétaire NVIDIA pour le moment, mais AMD <a href="http://www.phoronix.com/scan.php?page=news_item&px=AMD-Looking-At-GLVND">ne cache pas son intérêt</a> et l’on a hâte que <em>libglvnd</em> fasse son petit bout de chemin dans Mesa 3D, et que cela profite à d’autres, ce qui semble <a href="http://www.phoronix.com/scan.php?page=news_item&px=Mesa-Will-Do-GLVND">bien parti</a>.</p>
<h3 id="gpuopen">GPUOpen</h3>
<p>AMD a annoncé en décembre 2015 <a href="http://www.hardware.fr/news/14446/gpuopen-reponse-amd-gameworks.html">l’initiative <em>GPUOpen</em></a> qui vise à concurrencer GameWorks de NVIDIA. L’idée de <em>GPUOpen</em> est un partage de code source libre d’un maximum de ressources logicielles (exemples, démos, librairies). Lors du <a href="http://gpuopen.com/welcometogpuopen/">lancement le 26 janvier 2016</a>, du code a <a href="https://github.com/GPUOpen-Tools">commencé à être publié sur GitHub</a>. Plus de détails peuvent être trouvés dans le <a href="//linuxfr.org/users/freejeff/journaux/gpuopen">journal de <em>freejeff</em></a> et ses commentaires.</p>
<h3 id="openswr">OpenSWR</h3>
<p>Intel travaille sur un nouveau <em><a href="https://fr.wikipedia.org/wiki/Rast%C3%A9risation">rasterizer</a></em> logiciel nommé <a href="http://openswr.org/"><em>OpenSWR</em></a> et concurrençant <a href="http://www.mesa3d.org/llvmpipe.html"><em>LLVMPipe</em></a>. Un <em>rasterizer</em> est un logiciel de rendu graphique développé pour se satisfaire d’un processeur généraliste. Bien que forcément moins performant qu’un processeur graphique dédié, cela permet par exemple de simplifier les procédures de test de rendu graphique. Timothy Rowley de chez Intel a <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-October/097816.html">annoncé ce projet le 20 octobre dernier</a> (l’annonce est très détaillée et vaut le détour), on retiendra que l’équipe derrière ce projet n’est pas la même que celle développant les pilotes des processeurs graphiques chez Intel et que, contrairement à ce dernier, OpenSWR se base sur Gallium3D. OpenSWR annonce de <a href="http://openswr.org/slides/SWR_Sept15.pdf">bien meilleures performances que LLVMpipe</a> (OpenSWR répartit notamment plus de tâches entre les cœurs), et est lui aussi basé sur LLVM. OpenSWR fait partie du projet <a href="http://sdvis.org/"><em>Software Defined Visualization</em></a> et le <a href="https://github.com/OpenSWR/openswr-mesa">code est libre</a>, bien entendu.</p>
<h3 id="bientôt-de-gros-changements-du-côté-des-performances-chez-radeonsi">Bientôt de gros changements du côté des performances chez radeonsi ?</h3>
<p>Grosse surprise de fin d’année 2015, le <em><a href="https://github.com/axeldavy/llvm/commit/5005a869e01debaf3f78df804ab4fe67325ad88a">SI Machine Scheduler</a></em>, un nouvel ordonnanceur expérimental créé par Axel Davy a fait parler de lui : une fois activé, le pilote libre <em>radeonsi</em> surpasserait <em>Catalyst</em> sur toute la ligne. Cet ordonnanceur est encore expérimental, mais on attend son intégration pour 2016 avec impatience !</p>
<p>Comme l’a écrit <em>darkbasic</em> <a href="http://www.linuxsystems.it/2015/08/radeonsi-with-si-scheduler-humiliates-catalyst-in-all-tests/">dans un article</a> qui compare <em>radeonsi</em> et <em>Catalyst</em> :</p>
<blockquote>
<p><em>Catalyst got completely humiliated! Radeonsi is so much faster that I will no longer consider Catalyst as a reference for future performance improvements: we aim at the Nvidia performance now.</em></p>
</blockquote>
<p>Traduction :</p>
<blockquote>
<p>« Catalyst s’est fait complètement humilier ! Le <em>radeonsi</em> est tellement plus rapide que, dorénavant, je ne considérerai plus <em>Catalyst</em> comme une référence pour les futures améliorations de performances : maintenant nous visons les performances du pilote <em>nvidia</em>. »</p>
</blockquote>
<p><strong>N. D. M. :</strong> pondération de l’auteur quelques semaines plus tard :</p>
<blockquote>
<p>« <em>As I stated on IRC, the boost was largely due to a big regression reverted in Mesa while doing the first test. Only a little boost is accountable for the SI scheduler.</em> »</p>
</blockquote>
<p>Traduction :</p>
<blockquote>
<p>« Comme je l’ai écrit sur IRC, le gain était largement dû à une grande régression corrigée dans Mesa 3D pendant mon premier test. Seul un petit gain est imputable à l’ordonnanceur SI. »</p>
</blockquote>
<p>L’année 2016 est déjà là, et elle s’annonce comme une année très excitante !</p></div><div><a href="https://linuxfr.org/news/les-pilotes-graphiques-libres-retrospective-et-vue-sur-l-avenir.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/106602/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/les-pilotes-graphiques-libres-retrospective-et-vue-sur-l-avenir#comments">ouvrir dans le navigateur</a>
</p>
Thomas DEBESSEDavy DefaudBAudxoddarkreynumZeroHeurepalm123antistressbubar🦥Yves BourguignonbabytuxesdeemEdBLucasLe GabSpyhawkMohamed MEDIOUNIBenoît SibaudptitjanoNÿcojcr83AnonymecomeChristophe "CHiPs" PETITʭ ☯ PolePositionM5oulNarannerr404ariasuniFrédéric Massothttps://linuxfr.org/nodes/106602/comments.atomtag:linuxfr.org,2005:Diary/363282016-01-26T20:23:02+01:002016-01-26T20:23:02+01:00GPUOpenLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>AMD sort <a href="http://gpuopen.com/welcometogpuopen/">GPUOpen</a>, il semblerait que leur volonté serait de permettre d'aller plus bas dans les couches de la carte graphique que ce que les APIs classiquent permettent. Je ne sais pas trop ce que cela signifie en détail mais ils ont déjà sorti 3 projets en C++ sur leur <a href="https://github.com/GPUOpen-Tools/amd-codexl-analyzer">github</a>, un outil de maillage, un analyseur de code (noyau OpenCL et OpenGL shaders) et un analyseur de performances DirectX 12 (cela nous concerne un peu moins). Peut être des gens ici ont une idée plus précise de ce qu'il veulent faire, en tout cas la démarche est plutôt positive.</p><div><a href="https://linuxfr.org/users/freejeff/journaux/gpuopen.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108000/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/freejeff/journaux/gpuopen#comments">ouvrir dans le navigateur</a>
</p>
freejeffhttps://linuxfr.org/nodes/108000/comments.atomtag:linuxfr.org,2005:Diary/356702015-03-06T08:52:53+01:002015-03-06T08:52:53+01:00Vulkan le successeur d'OpenGLLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Une information qui a son importance dans la pile graphique de Linux, le 3 mars 2015, le <a href="https://fr.wikipedia.org/wiki/Khronos%20Group" title="Définition Wikipédia">Khronos Group</a>, un consortium industriel qui gère entre autre les standards <a href="https://fr.wikipedia.org/wiki/OpenGL" title="Définition Wikipédia">OpenGL</a>, <a href="https://fr.wikipedia.org/wiki/OpenGL%20ES" title="Définition Wikipédia">OpenGL ES</a>, <a href="https://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a> et <a href="https://fr.wikipedia.org/wiki/WebGL" title="Définition Wikipédia">WebGL</a> a dévoilé l'API qui devrait succéder à OpenGL à savoir Vulkan, , sa prochaine génération d'API de haute performance dédiée au graphisme 3D et au calcul GPU.</p>
<ul>
<li><a href="https://www.khronos.org/vulkan">Vulkan - Graphics and compute belong together</a></li>
<li><a href="https://www.khronos.org/news/press/khronos-reveals-vulkan-api-for-high-efficiency-graphics-and-compute-on-gpus">Khronos Reveals Vulkan API for High-efficiency Graphics and Compute on GPUs</a></li>
<li><a href="http://arstechnica.com/gadgets/2015/03/khronos-unveils-vulkan-opengl-built-for-modern-systems/">Khronos unveils Vulkan: OpenGL built for modern systems</a></li>
<li><a href="http://www.clubic.com/carte-graphique/actualite-757251-vulkan-opengl.html">Vulkan succédera à l'OpenGL de Khronos</a></li>
<li><a href="http://www.phoronix.com/scan.php?page=news_item&px=Khronos-GDC-2015-Presentations">The Khronos Group's Vulkan, SPIR-V & OpenCL 2.1 Presentations</a></li>
<li><a href="http://www.phoronix.com/scan.php?page=news_item&px=Valve-Intel-Vulkan-Driver">Valve Developed An Intel Linux Vulkan GPU Driver</a></li>
<li><a href="http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv&num=1">Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V</a></li>
<li><a href="http://www.phoronix.com/scan.php?page=news_item&px=PowerVR-Vulkan-Drivers-Demo">Imagination Already Has A Vulkan Driver In The Works For PowerVR GPUs</a></li>
<li><a href="http://www.hardware.fr/news/14101/gdc-vulkan-api-bas-niveau-khronos.html">GDC: Vulkan, l'API bas niveau de Khronos</a></li>
</ul><div><a href="https://linuxfr.org/users/lawless/journaux/vulkan-le-successeur-d-opengl.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/105015/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/lawless/journaux/vulkan-le-successeur-d-opengl#comments">ouvrir dans le navigateur</a>
</p>
Lawlesshttps://linuxfr.org/nodes/105015/comments.atomtag:linuxfr.org,2005:News/351262014-03-03T19:09:42+01:002014-03-03T19:09:42+01:00Les journaux LinuxFr.org les mieux notés du mois de février 2014Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>LinuxFr.org propose des dépêches et articles, soumis par tous (vous y compris), puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.</p>
<p>Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation <em>a priori</em> des modérateurs. Ceux-ci s'appellent des journaux (ou « blogs » en termes anglicistes). Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les lecteurs du site… qui notent. Lumière sur ceux du mois de février 2014 passé.</p>
<p>Participez à l'écriture d'articles ! <a href="//linuxfr.org/redaction">http://linuxfr.org/redaction</a> Écrivez votre journal ! <a href="//linuxfr.org/journaux/nouveau">http://linuxfr.org/journaux/nouveau</a></p>
<ul>
<li>
<a href="//linuxfr.org/users/andrianarivony/journaux/avoir-du-marbre-et-des-discussions-techniques">Avoir du marbre (et des discussions techniques)</a> par ZeroHeure ;</li>
<li>
<a href="//linuxfr.org/users/atem18/journaux/ubuntu-passera-lui-aussi-sur-systemd">Ubuntu passera lui aussi sur systemd</a> par Atem18 ;</li>
<li>
<a href="//linuxfr.org/users/ptifeth/journaux/debian-rejoint-les-utilisateurs-de-systemd">Debian rejoint les utilisateurs de Systemd</a> par feth ;</li>
<li>
<a href="//linuxfr.org/users/ecolbus/journaux/annonce-manux-0-0-4">Annonce : Manux 0.0.4</a> par Emmanuel Colbus ;</li>
<li>
<a href="//linuxfr.org/users/mupuf/journaux/compositeurs-wayland-pourquoi-et-comment-gerer-les-clients-privilegies">Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?</a> par Martin Peres ;</li>
<li>
<a href="//linuxfr.org/users/elessar/journaux/debian-adopte-systemd-comme-init-par-defaut">Debian adopte systemd comme init par défaut</a> par Tanguy Ortolo ;</li>
<li>
<a href="//linuxfr.org/users/devnewton/journaux/jnuit-et-la-recette-des-mombolini">jnuit et la recette des mombolini</a> par devnewton ;</li>
<li>
<a href="//linuxfr.org/users/ptifeth/journaux/you-re-talking-about-a-revolution">You're talking about a revolution</a> par feth ;</li>
<li>
<a href="//linuxfr.org/users/lezardbreton/journaux/twitter-vs-rss-atom-pour-suivre-un-site">Twitter vs RSS/ATOM pour suivre un site</a> par lezardbreton ;</li>
<li>
<a href="//linuxfr.org/users/antistress/journaux/aye-les-processeurs-intel-ivy-bridge-gerent-opencl-1-1-sous-gnu-linux">Ayé les processeurs Intel Ivy Bridge gèrent OpenCL 1.1 sous GNU/Linux</a> par antistress.</li>
</ul></div><ul><li>lien nᵒ 1 : <a title="http://linuxfr.org/redaction" hreflang="fr" href="https://linuxfr.org/redirect/89593">Participez à l'écriture d'un article</a></li><li>lien nᵒ 2 : <a title="http://linuxfr.org/journaux/nouveau" hreflang="fr" href="https://linuxfr.org/redirect/89594">Écrivez votre journal</a></li><li>lien nᵒ 3 : <a title="http://linuxfr.org/news/nouveau" hreflang="fr" href="https://linuxfr.org/redirect/89595">Proposez une dépêche</a></li></ul><div></div><div><a href="https://linuxfr.org/news/les-journaux-linuxfr-org-les-mieux-notes-du-mois-de-fevrier-2014.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/101410/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/les-journaux-linuxfr-org-les-mieux-notes-du-mois-de-fevrier-2014#comments">ouvrir dans le navigateur</a>
</p>
Florent ZaraNÿcohttps://linuxfr.org/nodes/101410/comments.atomtag:linuxfr.org,2005:Diary/347342014-02-12T20:13:50+01:002014-02-12T20:13:50+01:00Ayé les processeurs Intel Ivy Bridge gèrent OpenCL 1.1 sous GNU/LinuxLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>J'avais rédigé cette dépêche au lancement des processeurs Ivy Bridge :</p>
<ul>
<li><a href="//linuxfr.org/news/intel-ivy-bridge-et-linux-ca-juste-marche">Intel Ivy Bridge et Linux : ça juste marche</a></li>
</ul><p>Depuis, les développeurs de l'<a href="https://01.org/about"><em>Intel Open Source Technology Center (aka Intel OTC)</em></a> ont mis les bouchées doubles et voici où en est la situation :</p>
<p>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 <a href="http://fr.wikipedia.org/wiki/Beignet_%28biblioth%C3%A8que%29">Beignet</a> 0.8 sorti ce jour (pour les HD 4000 en tout cas) !</p>
<p>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 <a href="http://fr.wikipedia.org/wiki/Video_Acceleration_API">gstreamer-vaapi</a> 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…</p>
<p>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).</p><div><a href="https://linuxfr.org/users/antistress/journaux/aye-les-processeurs-intel-ivy-bridge-gerent-opencl-1-1-sous-gnu-linux.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/101250/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/journaux/aye-les-processeurs-intel-ivy-bridge-gerent-opencl-1-1-sous-gnu-linux#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/101250/comments.atomtag:linuxfr.org,2005:Diary/344742013-11-08T04:29:27+01:002013-11-08T04:29:27+01:00Petit tour d’horizon de la haute performance et du parallélismeLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#petit-rappel-sur-les-bases">Petit rappel sur les bases:</a></li>
<li>
<a href="#un-petit-tour-dhorizon-pour-la-haute-performance-sur-une-machine-">Un petit tour d'horizon pour la haute performance sur une machine :</a><ul>
<li><a href="#openclopen-compute-languagecuda">OpenCL(open compute language)/Cuda:</a></li>
<li><a href="#openmp-open-multi-processing">OpenMP (Open Multi-Processing):</a></li>
<li><a href="#renderscript">RenderScript:</a></li>
<li><a href="#hsail">HSAIL:</a></li>
<li><a href="#opengl-esdirectx">OpenGL (ES),DirectX:</a></li>
<li><a href="#directcomputecomputeshader">DirectCompute/ComputeShader:</a></li>
<li><a href="#mantle">Mantle:</a></li>
</ul>
</li>
<li><a href="#pourquoi-il-nous-parle-de-ca">Pourquoi il nous parle de ca?</a></li>
</ul><p>(Allez j’ai pas sommeil donc continuons,aujourd’hui je troll: numéro 2 après mon journal sur l’API html5 sur la géométrie)</p>
<p>Ici je ne vais pas parler de la très très haute performance quand les mutants transgéniques de codeurs fous vont jusqu’à optimiser leur source pour que le scheduler de GCC génère du code machine encore plus rapide mais plutôt des outils abordable qui ne nécessite pas de passer 3 semaines sur 60 lignes de codes.</p>
<h2 id="petit-rappel-sur-les-bases">Petit rappel sur les bases:</h2>
<p>SIMD ( <a href="http://fr.wikipedia.org/wiki/Single_instruction_multiple_data">single instruction multiple data</a> ) : souvent associé aux SSE/MMX car dans la pratique c’est un calcul fait sur un tableau en parallèle qui interdit les branches conditionnelles (addition d’entiers 4 par 4 etc). On nommera ce fonctionnement <em>“parallélisme de données”</em>.</p>
<p>SPMD (<a href="http://en.wikipedia.org/wiki/SPMD">single program multiple data</a> ): on peut voir ce principe comme beaucoup de threads légers qui travaillent en parallèle potentiellement sur une donnée commune.</p>
<p>Message passing et la spécialisation en <a href="http://en.wikipedia.org/wiki/Actor_model">actor</a> : le model d’acteur de <a href="www.scala-lang.org">scala</a> ou les <a href="http://en.wikipedia.org/wiki/Web_worker">webworkers</a>: aucune mémoire n’est partagée, seuls des messages sont échangés entre les workers, le worker n’étant exécuté que dans un seul thread.Il n’y a donc pas d’accès concurrent mais on peut lancer des millions de workers en simultané! Ce type de parallélisme est un parallélisme de tâche car chaque worker est découpé en tâches qui peuvent ou non être différentes les unes des autres.</p>
<h2 id="un-petit-tour-dhorizon-pour-la-haute-performance-sur-une-machine-">Un petit tour d'horizon pour la haute performance sur une machine :</h2>
<p>(ou plusieurs si l’on ajoute des papiers de chercheurs)</p>
<p>Quand on parle de HPC (high performance computing), on fait plutôt référence à <a href="http://en.wikipedia.org/wiki/Hadoop">hadoop</a> et le map reduce -> on utilise un grand nombre de machines et on les fait collaborer pour répondre à un problème. Dans le même genre, Twitter a créé <a href="http://storm-project.net/">storm</a> pour gérer les grandes quantités de flux,contrairement à hadoop qui lui est orienté lancement de batchs distribués.</p>
<p>Cependant, il existe aussi ce que je nomme le micro HPC, des calculs optimisés qui sont souvent utilisés dans la simulation ou le rendu 3d, les moteurs de jeux à gros budgets… Voici ce qu’on peut trouver dans le domaine (ma liste n’est pas exhaustive)</p>
<h3 id="openclopen-compute-languagecuda">OpenCL(open compute language)/Cuda:</h3>
<p><a href="http://fr.wikipedia.org/wiki/OpenCL">OpenCL</a>, c’est une API définie par khronos et plus particulièrement par intel/amd/nvidia/apple dont le but est de créer des programmes haute performance qui utilisent toute la puissance du matériel. Cuda, c’est un peu OpenCL mais uniquement pour les GPU nvidia (que les puristes m’excusent, ce n’est pas exactement le cas mais pour le bien de la compréhension, je me permet de faire ce raccourci). Les deux APIs sont relativement proche en terme de fonctionnement. A noter qu’OpenCL permet une exécution sur CPU ou d’autres matérielles comme du FPGA…Personnellement,le cas le plus exotique dont j’ai entendu parlé était du cell ou la ps3. <br>
Pour utiliser cette API, on écrit un “kernel”, c’est à dire un code bas niveau qui va être compilé pour le matérielle avant d’être exécuté avec le nombre de tâche parallèle définie par le développeur. Je ne vais pas allez dans les détails ( si il y a besoin je pourrais faire un journal sur OpenCL 2.0, sinon je vous conseil de regarder l’article suivant : <a href="//linuxfr.org/news/opencl-en-version-10">https://linuxfr.org/news/opencl-en-version-10</a> ou d’aller sur le site de khronos ). Finalement, je dirais que l'API est répandu mais aussi légèrement immature, et que ces APIs de GPGPUs semblent avoir surtout du succès chez les chercheurs et peu chez les industriels.</p>
<h3 id="openmp-open-multi-processing">OpenMP (Open Multi-Processing):</h3>
<p>C’est une solution qui permet de faire du parallélisme (plutôt de données) directement dans le code. En C++, par exemple, on ajoute simplement des pragmas pour changer un for en un ensemble traitement dont chaque itération est traitée en parallèle. Je ne vais pas faire un état des pour et des contre mais disons simplement que c’est assez flexible (c’est du SPMD) mais ne peut être mis sur du GPU. Je n’irai donc pas plus loin d’autant que l’article <a href="http://en.wikipedia.org/wiki/OpenMP">wikipedia</a> en anglais est relativement bien fait.</p>
<h3 id="renderscript">RenderScript:</h3>
<p>Contrairement à son nom, <a href="http://developer.android.com/guide/topics/renderscript/index.html">l’API d’android</a> pour le traitement parallèle n’est pas seulement fait pour du rendu. C’est l’API avec laquelle je suis le moins à l’aise car, contrairement aux autres, j’en ai jamais vraiment fait… (bien que pour les autre, ce n’était souvent que pour des codes personnelles). L’ objectif ici est d’être un OpenCL plus générique: alors qu’OpenCL permet d’optimiser son code pour un matérielle précis,Renderscript serait efficace sur toutes les plateforme avec une pénalité dans l’exécution qui reste acceptable (c’est quoi acceptable?) … Attendez une minute…Quoi, mais ca devrait pas être un des but ou même la définition de <a href="www.khronos.org/webcl/">WebCL</a> ca? C’est dommage car je pense qu’il aurait été intéressant d’échanger entre les deux projets. Néanmoins, beaucoup de personnes sont critique envers renderScript :pas d’id de la tâche parallèle en cours ou impossibilité de savoir si son code s'exécute sur le GPU ou sur le CPU (<a href="http://streamcomputing.eu/blog/2013-08-01/google-blocked-opencl-on-android-4-3/">en autre</a> ).En quoi est ce gênant? Si on sait que notre code tourne uniquement sur le GPU, on peut alors éviter les échanges mémoires avec le CPU (et vice versa) qui sont souvent le goulot d’étranglement des programmes OpenGL/OpenCL/directX/Cuda. Je suis plus que mitigé sur le potentielle pour de la haute performance, mais google nous réserver peut être une bonne surprise car Renderscript est encore très jeune. OpenCL et renderscript rentre bien dans ma vision des choses dans le principe générale: un langage au niveau avec un autre bas niveau pour les codes à optimiser (comme python et C /Cython)</p>
<h3 id="hsail">HSAIL:</h3>
<p>(Pour une raison qui m’échappe, j’ai eu plusieurs personnes issue du web qui m’ont dis que ca pourrait être le standard pour la performance de demain dans le navigateur…)</p>
<p>Quand un compilateur transforme le code en natif, il passe par une représentation intermédiaire (pour llvm cela s’appelle llvm-IR). OpenCL tente d’utiliser ces représentations intermédiaires pour pouvoir distribuer du code GPGPU, cela s'appelle openCL-SPIR. <em>HSAIL</em> dans tout ca? Pour moi, il peut être vu un peu comme OpenCL-SPIR mais en plus générique car il doit pouvoir aussi bien traité du GPGPU que du C++ avec OpenMP.</p>
<h3 id="opengl-esdirectx">OpenGL (ES),DirectX:</h3>
<p>Bien que le calcul pur ne soit pas le but premier, OpenGL peut très bien être utilisé comme accélérateur dans les programmes. En utilisant les images comme moyen de transmission entre la ram du CPU et celle de la carte graphique, on peut effectuer pas mal d’opérations et calculs. Personnellement, j’utilise souvent webGL pour accélérer mes calculs et je suis loin d’être le seul, même mozilla la <a href="https://brendaneich.com/2013/05/today-i-saw-the-future/">conseil</a></p>
<h3 id="directcomputecomputeshader">DirectCompute/ComputeShader:</h3>
<p>La méthode exposé ci dessus possède un défaut majeur: les structures irrégulières ou une communication entre “thread” ne sont pas possible. C’est ici qu’intervient computeShader d’OpenGL et DirectCompute. A noter qu’openCL ou CUDA sont encore plus générique permettant, par exemple, de changer le nombre d'exécution à la volée ou même d’utiliser des queues de communication ou de lancer d’autres tâches en chaînes!</p>
<h3 id="mantle">Mantle:</h3>
<p>C’est la nouvelle API d’amd qui prétends être encore plus optimisé que directX et OpenGL car plus bas niveau. C’est censé être pour la visualisation 3D mais comme nous l’avons vu, on peut toujours détourné pour nos besoins de calculs. A voir quand elle sera publique mais beaucoup de personnes pense que c’est une sorte de sous ensemble d’OpenGL/directX plus proche du matérielle comme l’était <a href="http://en.wikipedia.org/wiki/Glide_API">l’API glide pour les 3dfx</a>. Mais sur le fond je suis tout nu car j'ai rien de concret dessus…</p>
<p>Dans tout ce que nous avons cité précédemment, il n’y a que cuda et openCL (et renderscipt dans un futur proche?) qui permettent de choisir comment répartir finement le travail entre les CPU et les GPUs , c’est d‘ailleurs les seuls qui permettent d’utiliser le GPU ou de choisir entre le CPU et le GPU (contrairement aux APIs de rendu 3D). C'est probablement pour cette raison que je les considère comme les plus amusant à utiliser :-)</p>
<h2 id="pourquoi-il-nous-parle-de-ca">Pourquoi il nous parle de ca?</h2>
<p>Pourquoi vos parler de tout ca?Autre le fait que j'ai une insomnie? parce que dès que j’aurai du temps, je vous ferais un petit journal sur comment je vois le calcul haute performance dans le navigateur, mes tests, mes conclusions (si j'ai encore un lecteur ;-)</p>
<p>Pour la personne qui a réussi à arriver jusqu'ici, je te le promet au chevalier du code, je dormirai avant de faire mes autres journaux et je ferais plus d'effort:<br>
mais saches que tu es l’élite de l’élite, l’élu, le vaillant guerrier qui cherche la connaissance, sans repos, parmi les plus infâmes écrits comme celui ci. A toi, le véritable sauveur, roi des hommes, je te dit ceci: n’abandonnes jamais, ne baisses jamais les bras, ne pleures jamais, ne dit jamais au revoir, ne ment jamais dans les commentaires, et garde la force de ne jamais être de mauvaise fois dans tes trolls les plus poilus! Et continus de chercher la vérité parmi les vieux grimoire et les vieux sages les plus poussiéreux![ cette fin de texte n’est pas de moi, je l’ai juste adapté à ma sauce :]</p><div><a href="https://linuxfr.org/users/tallion/journaux/petit-tour-d-horizon-de-la-haute-performance-et-du-parallelisme.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/100262/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/tallion/journaux/petit-tour-d-horizon-de-la-haute-performance-et-du-parallelisme#comments">ouvrir dans le navigateur</a>
</p>
tallionhttps://linuxfr.org/nodes/100262/comments.atomtag:linuxfr.org,2005:Diary/344442013-10-28T11:31:20+01:002013-10-28T11:31:20+01:00Séminaire à l'Ircam : Standards et librairies ouverts pour l'animation et le jeuLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Je fais suivre cette information qui pourrait intéresser des membres de notre communauté.</p>
<p><strong>Séminaire gratuit, mais inscription obligatoire</strong> à : <a href="http://paris.siggraph.org/activites/2013-14/standards-et-librairies-ouverts/standards-et-librairies-ouverts-pour-lanimation-et#inscription">http://paris.siggraph.org/activites/2013-14/standards-et-librairies-ouverts/standards-et-librairies-ouverts-pour-lanimation-et#inscription</a></p>
<p>Standards et librairies ouverts pour l'animation et le jeu vidéo<br><strong>Mardi 5 novembre 2013 16H - 17H30 en salle Stravinsky</strong>. </p>
<p>Bill POLSON, directeur de la stratégie industrielle chez Pixar Animation Studios, et <br>
Erik NOREKE, consultant spécialisé en technologie (software et hardware) et membre du Kronos Group.<br><strong>Présentation en anglais</strong>.</p>
<p>Résumé :</p>
<p>Le développement de l'informatique s'est largement fait en s'appuyant sur des standards, qu'ils soient fermés ou ouverts. L'infographie et le multimédia n'ont pas échappé à la règle.</p>
<p>Paris ACM SIGGRAPH, en association avec l'IRCAM et le CNRS, vous invite à une conférence sur le thème des standards et librairies ouverts dans l'industrie de l'animation et du jeu vidéo.</p>
<p>Bill Polson, Director of Industry chez Pixar, présentera OpenSubDiv, un ensemble de librairies open-source qui fournit un service d'évaluation performant pour la subdivision de surface, et ce sur des architectures massivement parallèles de CPU et/ou GPU. Ce code est le fruit d'un travail de plusieurs décennies des équipes de Pixar couplé à une collaboration plus récente et toujours active avec Microsoft Reseach dans le domaine du rendu rapide sur GPU.</p>
<p>Erik Noreke est le directeur du groupe de travail sur OpenSL ES au sein du Khronos Group. Ce dernier est un consortium industriel à but non-lucratif qui développe des standards ouverts pour la création et le rendu accéléré de contenu dynamique sur une grande variété de plateformes et de dispositifs mobiles. Le Khronos Group gère par exemple les standards OpenGL (graphique) et OpenCL (calcul). Erik présentera le Khronos Group ainsi que les dernières avancées des standards gérés.</p><div><a href="https://linuxfr.org/users/sebastien--3/journaux/seminaire-a-l-ircam-standards-et-librairies-ouverts-pour-l-animation-et-le-jeu.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/100140/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/sebastien--3/journaux/seminaire-a-l-ircam-standards-et-librairies-ouverts-pour-l-animation-et-le-jeu#comments">ouvrir dans le navigateur</a>
</p>
Sébastienhttps://linuxfr.org/nodes/100140/comments.atomtag:linuxfr.org,2005:News/334242012-10-09T18:47:13+02:002012-10-09T18:47:13+02:00Mesa 9.0 est sorti : OpenGL 3.1, OpenCL, VDPAU…Licence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<div><p>Nous avions relayé <a href="http://linuxfr.org/news/quoi-de-neuf-du-cote-d-opengl-et-linux">au mois d’août</a> la publication des spécifications <a href="http://fr.wikipedia.org/wiki/OpenGL" title="Définition Wikipédia">OpenGL</a> 4.3 et <a href="http://fr.wikipedia.org/wiki/OpenGL ES" title="Définition Wikipédia">OpenGL ES</a> 3.0 par le <a href="http://fr.wikipedia.org/wiki/Khronos Group" title="Définition Wikipédia">Groupe Khronos</a>.</p>
<p><a href="https://fr.wikipedia.org/wiki/Mesa_%28OpenGL%29" title="Définition Wikipédia">Mesa</a>, une implémentation libre de la spécification pour plates‐formes de type Unix, comme GNU/Linux, vient de sortir en version 9.0, offrant notamment la prise en charge de la version 3.1 d’OpenGL datant du 24 mars 2009. Du fait de cette importante mise à jour, Mesa 8.1 sort finalement sous le nom de Mesa 9.0.</p></div><ul><li>lien nᵒ 1 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=MTIwMjE" hreflang="en" href="https://linuxfr.org/redirect/83700">Mesa 9.0 Officially Released, Supports OpenGL 3.1</a></li><li>lien nᵒ 2 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=MTIwMjQ" hreflang="en" href="https://linuxfr.org/redirect/83701">Nine Good Things About Mesa 9.0</a></li><li>lien nᵒ 3 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=MTE4MTA" hreflang="en" href="https://linuxfr.org/redirect/83702">Geometry Shaders Soon To Hit Mesa, GL 3.2 Is Close</a></li><li>lien nᵒ 4 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=MTE4NDA" hreflang="en" href="https://linuxfr.org/redirect/83703">A New Linux OpenGL ABI Is Being Proposed</a></li><li>lien nᵒ 5 : <a title="http://www.phoronix.com/scan.php?page=news_item&px=MTE5MTY" hreflang="en" href="https://linuxfr.org/redirect/83704">The Future Of OpenGL On Linux Looks Better</a></li></ul><div><h2 id="toc_0">OpenGL 3.1 et OpenGL ES 2.0</h2>
<p>La principale nouveauté de cette version 9.0 de Mesa est en effet la prise en charge d’OpenGL 3.1, succédant à la version 8.0 sortie le 9 février 2012 et qui apportait la prise en charge d’OpenGL 3.0.</p>
<p>Dès à présent le pilote des puces Intel <em>Sandy Bridge</em> (Gen 6) et <em>Ivy Bridge</em> (Gen 7) serait prêt — ou quasiment — à en tirer parti, et celui des puces AMD R600/700, <em>Evergreen</em> (R800) et <em>Northern Islands</em> ne serait pas très loin derrière.</p>
<p>L’implémentation de la version 3.2 (du 3 août 2009), voire 3.3 (du 11 mars 2010), d’OpenGL devrait suivre assez rapidement : le gros du travail est fait pour ces deux versions. Il manque toutefois une pièce importante : le <em>GL Shading Language</em> de la version 3.2 — GLSL 1.50 —, de sorte que, une fois l’implémentation d’OpenGL 3.2 achevée, Mesa devrait sortir directement une version compatible OpenGL 3.3. L’étape suivante sera la série 4.<em>x</em> d’OpenGL, qui prendra un peu plus de temps.</p>
<p>Du côté d’OpenGL ES (la version d’OpenGL adaptée aux appareils mobiles), <a href="http://linuxfr.org/news/quoi-de-neuf-du-cote-d-opengl-et-linux">rappelons</a> simplement que Mesa 8.0 offre déjà la prise en charge de la version 2.0, et que la la prise en charge de la version 3.0 arriverait assez rapidement l’année prochaine.</p>
<h2 id="toc_1">OpenCL & VDPAU font leur entrée dans Mesa</h2>
<p>Mesa 9.0 inclut, pour les pilotes libres Gallium3D (puces NVIDIA et AMD), une première implémentation libre d’<a href="http://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a> (<em>Clover</em>), le pilote <em>r600g</em> pour cartes AMD <a href="http://www.phoronix.com/scan.php?page=news_item&px=MTA4MTM">semblant</a> <a href="http://www.phoronix.com/scan.php?page=news_item&px=MTExNTI">toutefois</a> le plus avancé des pilotes libres en la matière, de même qu’une première implémentation de <a href="http://fr.wikipedia.org/wiki/VDPAU" title="Définition Wikipédia">VDPAU</a> (pour le moment limitée à MPEG-1 et MPEG-2).</p>
<p>Pour rappel, du côté des puces Intel, si la <a href="https://fr.wikipedia.org/wiki/Video_Acceleration_API" title="Définition Wikipédia">VA-API</a> (qui équivaut à VDPAU) se porte très bien, il n’y a toujours rien d’annoncé quant à une possible prise en charge d’OpenCL.</p>
<h2 id="toc_2">Une nouvelle ABI OpenGL ?</h2>
<p>La <em>X.Org Developer Conference 2012</em> (<a href="http://www.x.org/wiki/Events/XDC2012">XDC2012</a>), qui s’est déroulée du 19 au 21 septembre 2012 à Nuremberg, a été l’occasion pour NVIDIA de proposer une refonte importante de Mesa qui implémenterait une nouvelle <a href="https://fr.wikipedia.org/wiki/Application_binary_interface" title="Définition Wikipédia">ABI</a> OpenGL tirant un trait sur l’actuelle, vieille de douze ans. Cette dernière serait toutefois conservée pour garder la compatibilité avec les applications de ces dix dernières années…</p></div><div><a href="https://linuxfr.org/news/mesa-9-0-est-sorti-opengl-3-1-opencl-vdpau.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/95916/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/mesa-9-0-est-sorti-opengl-3-1-opencl-vdpau#comments">ouvrir dans le navigateur</a>
</p>
antistressDavy DefaudThomas DebesseNÿcohttps://linuxfr.org/nodes/95916/comments.atomtag:linuxfr.org,2005:News/267922010-05-03T20:02:36+02:002010-05-03T20:02:36+02:00Spécifications de OpenGL 4.0<div>Le Khronos Group (consortium de standards ouverts) a annoncé la sortie de OpenGL 4.0 le 10 mars 2010 sous forme de PDF de 489 pages et 2.8 Mo. Pour mémoire, OpenGL, pour Open Graphics Library, est une spécification qui définit une API d'imagerie 3D et 2D, pour les ordinateurs allant du mobile au super-calculateur, en passant bien évidemment par le jeu vidéo.
<br />
<br />
Cette version 4.0 apporte son lot de nouveautés :
<br />
<ul><li>Amélioration de l'interopérabilité avec <a href="http://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a>, sans recourir au CPU ;
<br />
</li><li>Amélioration du rendu via le passage des opérations en virgule flottante du format simple précision au format double précision ;
<br />
</li><li>Et, bien sûr, le très attendu (essentiellement par les programmeurs de jeux) support de la <a href="http://fr.wikipedia.org/wiki/Pavage">tessellation</a> ! La tessellation est le pavage en français ou encore tiling en anglais. OpenGL la proposait déjà mais seulement via une extension fournie par AMD donc uniquement disponible pour les cartes ATI compatibles. OpenGL rattrape ainsi DirectX 11 qui propose déjà la tessellation. Par exemple, <a href="http://linuxfr.org/~lapinflemard/29273.html">ce journal de début d'année sur DLFP</a> évoquait les différences entre bibliothèques de jeux.</li></ul>
<br />
<br />
OpenGL 3.3 a été livré à la même occasion, ayant pour but de rétroporter un maximum de nouveautés 4.0 pour les vieux <a href="http://fr.wikipedia.org/wiki/Processeur_graphique">GPU</a>.
<br />
<br />
<abbr title="Note des modérateurs">NdM</abbr> : <i>ce sujet n'est plus de toute fraîcheur, mais il nous a paru intéressant de lancer le débat.</i></div><ul><li>lien nᵒ 1 : <a title="http://www.khronos.org/news/press/releases/khronos-unleashes-cutting-edge-cross-platform-graphics-acceleration-opengl4" hreflang="en" href="https://linuxfr.org/redirect/66765">L'annonce de Khronos</a></li><li>lien nᵒ 2 : <a title="http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf" hreflang="en" href="https://linuxfr.org/redirect/66766">La spécification d'OpenGL 4.0 (PDF)</a></li><li>lien nᵒ 3 : <a title="http://www.opengl.org/documentation/current_version/" hreflang="en" href="https://linuxfr.org/redirect/66767">Lien vers le site officiel d'OpenGL</a></li><li>lien nᵒ 4 : <a title="http://www.centrale3d.com/?OpenGL-4-0-arrive-sur-les-pas-de" hreflang="fr" href="https://linuxfr.org/redirect/66768">Article francophone</a></li></ul><div></div><div><a href="https://linuxfr.org/news/specifications-de-opengl-40.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/25783/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/specifications-de-opengl-40#comments">ouvrir dans le navigateur</a>
</p>
Nicolas Lefillastrehttps://linuxfr.org/nodes/25783/comments.atomtag:linuxfr.org,2005:News/247772008-12-10T09:39:17+01:002008-12-10T09:39:17+01:00OpenCL, en version 1.0<div>OpenCL (Open Computing Langage) est un projet ambitieux, initialement lancé par Apple. Les spécifications ont été proposées et acceptées par le consortium Khronos, qui par ailleurs s'occupe aussi d'<a href="http://fr.wikipedia.org/wiki/OpenGL" title="Définition Wikipédia">OpenGL</a>, en juin 2008. La version 1.0 est sortie aujourd'hui (09/12/2008) et est disponible sur <a href="http://www.khronos.org/registry/cl/">http://www.khronos.org/registry/cl/</a> (spécification et headers).
<br />
<br />
Le but de ce projet est de permettre aux développeurs de tirer parti des énormes capacités de calcul des processeurs graphiques (<a href="http://fr.wikipedia.org/wiki/Processeur_graphique">GPU</a>s) d'aujourd'hui. En effet, sauf quand une application graphique est lancée (un jeu par exemple), cette puissance de calcul reste inutilisée pour la plupart du temps. On appelle ce genre de technique, qui consiste finalement à détourner l'utilisation principale d'un processeur graphique, « <i>General Purpose Computing on Graphics processing Units</i> » ou tout simplement, <a href="http://fr.wikipedia.org/wiki/GPGPU" title="Définition Wikipédia">GPGPU</a>.
<br />
<br />
<a href="http://fr.wikipedia.org/wiki/OpenCL" title="Définition Wikipédia">OpenCL</a> permet donc de consolider la puissance de calcul absolue des machines en utilisant le GPU comme un simple <a href="http://fr.wikipedia.org/wiki/Processeur">CPU</a>, et donc d'utiliser ce CPU « <i>virtuel</i> » pour les besoins de n'importe quel type d'application. Cette technologie sera incluse dans Mac OS X v10.6 (Snow Leopard) et normalement strictement transparente pour les applications. Le package OpenCL + transparence pour les programmes répond au doux nom marketing « <i>Grand central</i> », et ce regroupement ne sera évidemment pas libre. Cependant, rien n'empêchera au monde du libre de l'adapter dans un « <i>Grand Central</i> » complètement libre.
<br />
<br />
La spécification est définie comme ouverte et libre de droit. Malheureusement, il m'a été impossible de trouver une quelconque licence ou de quelconques démos. Confidentialité sur Snow Leopard oblige...
<br />
<br />
Cependant, un grand nombre d'acteurs se sont joints au projet et aujourd'hui on trouve, entre autres : Apple, AMD, NVIDIA, Intel, Broadcom, Blizzard, EA, Ericsson, IBM, Movidia, Nokia, Sony, Symbian, Texas Instruments. Bref, on ne trouve que du beau monde.
<br />
<br />
Cette technologie, définie comme indépendante du matériel, pourra potentiellement donner un grand coup de fouet aux capacités de calcul de nos machines actuelles. Il ne reste plus qu'à espérer qu'elle soit réellement « <i>open and royalty-free</i> ».
<br />
<br />
<i>NdM : Afin d'éviter que <a href="http://fr.wikipedia.org/wiki/CUDA">CUDA</a> (la technologie propriétaire qui est soutenue par NVidia) ne s'empare totalement de ce nouveau marché, les autres acteurs se sont regroupés derrière la bannière d'OpenCL. Cette technologie va donc bien au delà de MacOS X et elle va sans doute devenir "la" technologie de GPGPU sur les systèmes libres.</i>
<br />
</div><ul><li>lien nᵒ 1 : <a title="http://www.khronos.org/registry/cl/" hreflang="en" href="https://linuxfr.org/redirect/59759">Version 1.0 d'OpenCL</a></li><li>lien nᵒ 2 : <a title="http://en.wikipedia.org/wiki/OpenCL" hreflang="en" href="https://linuxfr.org/redirect/59760">Sur wikipedia</a></li><li>lien nᵒ 3 : <a title="http://www.khronos.org/opencl/" hreflang="en" href="https://linuxfr.org/redirect/59761">Sur le site du Khronos Group</a></li></ul><div></div><div><a href="https://linuxfr.org/news/opencl-en-version-10.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/23884/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/opencl-en-version-10#comments">ouvrir dans le navigateur</a>
</p>
Antoine Mercadalhttps://linuxfr.org/nodes/23884/comments.atom