Je suis pas tout à fait d'accord. Une question que je me pose depuis l'annonce d'OpenCL c'est à qui ça se destine.
En fait je crois que c’est là le nœud du problème.
Il me semble qu’il y a deux types d’utilisateurs :
Les utilisateurs qui sont les auteurs de leur propre solution à leur propre besoin et qui maîtrisent toute la chaîne ;
Les utilisateurs et développeurs de logiciel génériques pour tout le monde et qui ne sont qu’un maillon d’une chaîne.
Les premiers sont aussi les seuls utilisateurs de leur logiciel. Ils choisissent une matériel, ils choisissent un environnement logiciels, et ils développent une solution. Ceux-là n’ont pas vraiment de problèmes. À la base ils n’ont pas vraiment de problème de portabilité. Et on voit bien que ROCm vise ce genre de client. Même si ROCm ne prenait en charge qu’une seule carte par génération de 3 ans, ça répondrait au besoin.
Une entreprise a des besoins en calcul pour un problème donné ? Hop, elle achète 200 cartes du modèle recommandé, prend la bibliothèque qui va bien, envoie ses gars au turbin et voilà.
Il y a clairement un marché du calcul sur GPU pour faire des trucs très complexe dans des fermes de calcul où l’on trait la dernière goûte de puissance sur un matériel préconisé avec un pilote fournit par le fabriquant du matériel sur une distro qui a deux ans.
Il y a plein de trucs dans ROCm qui n’ont d’ailleurs rien à voir avec OpenCL. C’est probablement pour ce besoin-là.
Peut-être qu’AMD répond déjà parfaitement à ce besoin, je ne sais pas.
Les seconds ne maîtrisent pas toute la chaîne, ils sont fournisseurs, ils sont clients, ils sont intermédiaires.
En tant qu’utilisateur de Darktable, je ne suis pas développeur OpenCL. Le développeur de Dartkable, lui, n’a pas pour objectif de répondre à mon petit cas particulier de la puce graphique intégrée dans l’ordinateur portable que j’achète pour des raisons de taille et de poids (et de présence de trackpoint) ou la carte graphique que j’achète parce que, mettons, je suis tombé sur une bonne affaire.
Les développeurs comme les utilisateurs de logiciels comme Darktable, Blender ou DaVinci Resolve ou Natron aimeraient bien pouvoir simplement fournir et se faire fournir des logiciels qui exploitent leur matériel, même si ce n’est qu’à 80%.
Et c’est là que c’est la misère.
Je ne doute pas qu’OpenCL n’est pas parfait, qu’il faille parfois faire des adaptations ne m’étonne pas. Mais il y a un vrai besoin d’une API dont 95% du code est commun et fonctionne pour 95% des utilisateurs même si ça n’exploite pas 95% des performances.
Pour prendre exemple avec OpenGL que je connais mieux, je sais que la façon de mettre en œuvre OpenGL dans un programme est spécifique à chaque système d’exploitation (j’ai dû implémenter le partage de contexte dans GtkGLExt pour GTK2 sur macOS pour porter NetRadiant sur macOS). Je sais aussi qu’on peut rencontrer des bugs qui sont spécifiques à un fabriquant ou un pilote (récemment dans Unvanquished il a fallu réimplémenter un calcul d’une manière différente pour contourner un bug du pilote Nvidia).
Si OpenCL est aussi chiant, ça reste acceptable. Au final on peut quand même viser les trois OS principaux et la quasi totalité des utilisateurs moyennant quelques adaptations et des rustines.
Est-ce que l’avenir de Blender c’est CUDA pour Nvidia et un truc spécifique à AMD pour AMD ? Ça ne me pose pas problème s’ils ont les moyens d’implémenter des variantes spécifiques à chaque fabriquant si ça permet d’extraire plus de jus, mais il y a un besoin pour une solution générique (ou quasi générique).
Si un jour OpenCL sur Vulkan fonctionne, ça sera un immense soulagement pour tous ceux qui sont dans la deuxième catégorie : ceux qui veulent faire du développement photo ou du montage vidéo avec un logiciel générique, je me demande même si ça ne pourrait pas réveiller une regain d’intérêt pour OpenCL si magiquement OpenCL marche partout où Vulkan marche...
Pour les entreprises qui fabriquent des fermes de calculs et qui salarient leurs développeurs pour répondre à leurs propres besoins, OpenCL sur Vulkan ne sera d’aucun intérêt.
Il y a deux besoins qui semblent confondus, et ce depuis le début du calcul sur GPU. Il me semble qu’Nvidia a su les identifier et les adresser tout les deux avec CUDA.
Apple a aussi identifié le second besoin, celui du poste de travail (tandis qu’ils ne sont pas vraiment concernés par le premier besoin des fermes de calcul). Pour Apple il est important que les acheteurs de mac aient des logiciels de création qui marchent sur leur mac qu’ils utilisent une puce Nvidia (dans le passé) ou AMD (aujourd’hui), et que les logiciels continuent de marcher à travers les générations de matériel même s’ils ne sont pas mis à jour.
OpenCL c’est aussi ce marché : le marché du créateur, celui qui voudrait s’acheter une gros ThreadRipper avec une grosse RDNA pour faire de la vidéo 4K@60 avec des effets sexy pour son public sur Youtube. Ce même créateur n’est pas concerné par les solutions utilisées par les entreprises et institutions qui font des simulations d’ouragan ou qui minent du duckcoinTM.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: OpenCL, portabilité et performance en général
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 10. Dernière modification le 02 février 2022 à 01:14.
En fait je crois que c’est là le nœud du problème.
Il me semble qu’il y a deux types d’utilisateurs :
Les premiers sont aussi les seuls utilisateurs de leur logiciel. Ils choisissent une matériel, ils choisissent un environnement logiciels, et ils développent une solution. Ceux-là n’ont pas vraiment de problèmes. À la base ils n’ont pas vraiment de problème de portabilité. Et on voit bien que ROCm vise ce genre de client. Même si ROCm ne prenait en charge qu’une seule carte par génération de 3 ans, ça répondrait au besoin.
Une entreprise a des besoins en calcul pour un problème donné ? Hop, elle achète 200 cartes du modèle recommandé, prend la bibliothèque qui va bien, envoie ses gars au turbin et voilà.
Il y a clairement un marché du calcul sur GPU pour faire des trucs très complexe dans des fermes de calcul où l’on trait la dernière goûte de puissance sur un matériel préconisé avec un pilote fournit par le fabriquant du matériel sur une distro qui a deux ans.
Il y a plein de trucs dans ROCm qui n’ont d’ailleurs rien à voir avec OpenCL. C’est probablement pour ce besoin-là.
Peut-être qu’AMD répond déjà parfaitement à ce besoin, je ne sais pas.
Les seconds ne maîtrisent pas toute la chaîne, ils sont fournisseurs, ils sont clients, ils sont intermédiaires.
En tant qu’utilisateur de Darktable, je ne suis pas développeur OpenCL. Le développeur de Dartkable, lui, n’a pas pour objectif de répondre à mon petit cas particulier de la puce graphique intégrée dans l’ordinateur portable que j’achète pour des raisons de taille et de poids (et de présence de trackpoint) ou la carte graphique que j’achète parce que, mettons, je suis tombé sur une bonne affaire.
Les développeurs comme les utilisateurs de logiciels comme Darktable, Blender ou DaVinci Resolve ou Natron aimeraient bien pouvoir simplement fournir et se faire fournir des logiciels qui exploitent leur matériel, même si ce n’est qu’à 80%.
Et c’est là que c’est la misère.
Je ne doute pas qu’OpenCL n’est pas parfait, qu’il faille parfois faire des adaptations ne m’étonne pas. Mais il y a un vrai besoin d’une API dont 95% du code est commun et fonctionne pour 95% des utilisateurs même si ça n’exploite pas 95% des performances.
Pour prendre exemple avec OpenGL que je connais mieux, je sais que la façon de mettre en œuvre OpenGL dans un programme est spécifique à chaque système d’exploitation (j’ai dû implémenter le partage de contexte dans GtkGLExt pour GTK2 sur macOS pour porter NetRadiant sur macOS). Je sais aussi qu’on peut rencontrer des bugs qui sont spécifiques à un fabriquant ou un pilote (récemment dans Unvanquished il a fallu réimplémenter un calcul d’une manière différente pour contourner un bug du pilote Nvidia).
Si OpenCL est aussi chiant, ça reste acceptable. Au final on peut quand même viser les trois OS principaux et la quasi totalité des utilisateurs moyennant quelques adaptations et des rustines.
Est-ce que l’avenir de Blender c’est CUDA pour Nvidia et un truc spécifique à AMD pour AMD ? Ça ne me pose pas problème s’ils ont les moyens d’implémenter des variantes spécifiques à chaque fabriquant si ça permet d’extraire plus de jus, mais il y a un besoin pour une solution générique (ou quasi générique).
Si un jour OpenCL sur Vulkan fonctionne, ça sera un immense soulagement pour tous ceux qui sont dans la deuxième catégorie : ceux qui veulent faire du développement photo ou du montage vidéo avec un logiciel générique, je me demande même si ça ne pourrait pas réveiller une regain d’intérêt pour OpenCL si magiquement OpenCL marche partout où Vulkan marche...
Pour les entreprises qui fabriquent des fermes de calculs et qui salarient leurs développeurs pour répondre à leurs propres besoins, OpenCL sur Vulkan ne sera d’aucun intérêt.
Il y a deux besoins qui semblent confondus, et ce depuis le début du calcul sur GPU. Il me semble qu’Nvidia a su les identifier et les adresser tout les deux avec CUDA.
Apple a aussi identifié le second besoin, celui du poste de travail (tandis qu’ils ne sont pas vraiment concernés par le premier besoin des fermes de calcul). Pour Apple il est important que les acheteurs de mac aient des logiciels de création qui marchent sur leur mac qu’ils utilisent une puce Nvidia (dans le passé) ou AMD (aujourd’hui), et que les logiciels continuent de marcher à travers les générations de matériel même s’ils ne sont pas mis à jour.
OpenCL c’est aussi ce marché : le marché du créateur, celui qui voudrait s’acheter une gros ThreadRipper avec une grosse RDNA pour faire de la vidéo 4K@60 avec des effets sexy pour son public sur Youtube. Ce même créateur n’est pas concerné par les solutions utilisées par les entreprises et institutions qui font des simulations d’ouragan ou qui minent du duckcoinTM.
ce commentaire est sous licence cc by 4 et précédentes