Il est étrange que Google ait abandonné OpenCL ouvert pour CUDA propriétaire.

À tout le moins, la bibliothèque Eigen devrait prendre en charge OpenCL.

:+1:

:+1:

:+1:

pouce levé et tout ça.

Je serai intéressé par l'expansion de Tensor Flow avec OpenCL. Comme nous avons déjà publié OpenCL caffe. https://github.com/amd/OpenCL-caffe. Espérons qu'il puisse être intégré de manière légère? Quelqu'un est-il intéressé à travailler ensemble sur ce sujet ?

@gujunli Ravi de voir AMD ici. /cc @naibaf7 @lunochod

serait génial.

:+1:

/cc @lukeiwanski pour Eigen/OpenCL/SYCL

@gujunli serait certainement intéressé à contribuer. S'il vous plaît laissez-moi savoir quand vous prévoyez de commencer.

Salut tout le monde,

Chez Codeplay, nous examinons le tenseur d'Eigen fonctionnant sur GPU en utilisant SYCL (une couche C++ moderne au-dessus d'OpenCL). D'après ce que nous avons recueilli jusqu'à présent, la conception du tenseur GPU est très étroitement couplée à CUDA et nécessitera des changements d'interface pour un autre modèle de programmation et en particulier une version SYCL et OpenCL 1.2.

Si quelqu'un est intéressé à creuser plus profondément / à aider, nous sommes très certainement intéressés à contribuer.

Merci,
Luc

@luceiwanski Merci pour les commentaires. Je pense que @benoitsteiner a travaillé sur la partie extension du tenseur de eigen.

:+1: Je peux aider à coder certains OpenCL/SYCL si quelqu'un fait un plan, divise le travail en tâches, etc. Je recommande d'utiliser Boost.Compute comme wrapper pour OpenCL (cela facilite l'exécution des noyaux, les tests, la création de modèles).

+1

:+1:

Salut tout le monde,

Juste pour vous tenir au courant, nous étudions toujours comment nous pouvons modifier l'interface Eigen pour mieux l'adapter au modèle de programmation SYCL/OpenCL 1.2.
Une fois que nous aurons trouvé une approche raisonnable ciblant des modèles de programmation hétérogènes (pas seulement OpenCL / SYCL), nous créerons une proposition.

Merci,
Luc

Veuillez me tenir au courant. J'ai développé opencl-caffe pour AMD. je regarde aussi
flux tenseur.

Merci.
Junlu
Le 8 décembre 2015 à 10h19, "Luke Iwanski" [email protected] a écrit :

Salut tout le monde,

Juste pour vous tenir au courant, nous étudions toujours comment nous pouvons changer le
Interface propre pour mieux s'adapter au modèle de programmation SYCL/OpenCL 1.2.
Une fois que nous aurons trouvé une approche raisonnable, nous créerons une proposition.

Merci,
Luc

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -162967662
.

/cc @ptillet @gongzg Est-ce que cela intéresse Intel ? J'espère vraiment que nous ne fragmenterons pas OPENCL ici comme dans Caffe où nous avons un fork AMD, des PR non fusionnés d'Intel, un autre PR AMD semi-non officiel et un long PR utilisateur de mise en scène (plus deux anciens efforts Opencl abandonnés). Si quelqu'un est intéressé par l'histoire, il peut jeter un œil aux commentaires https://github.com/BVLC/caffe/pull/2610 .

@bhack Cela nous intéresse. Merci de me le faire savoir. S'il y a une proposition pour l'implémentation OpenCL/SYCL d'Eigen, nous verrons ce que nous pouvons faire du côté d'Intel.

:+1:

Une initiative intéressante sur https://github.com/ptillet/isaac également si ici on s'appuie sur l'extension du tenseur Eigen.

J'aimerais aussi contribuer. @benoitsteiner pouvez-vous l'organiser ?

Cela a été inclus dans la feuille de route mais également étiqueté comme contribution, donc une direction/bootstrap pourrait être vraiment utile.

Je peux contribuer à l'organiser. qui est responsable du support OpenCL dans
Flux tenseur maintenant ?

Merci beaucoup.
Junli

Le mardi 19 janvier 2016 à 7h50, bhack [email protected] a écrit :

Cela a été inclus dans la feuille de route, mais également étiqueté comme contribution, de sorte qu'un
direction/bootstrap pourrait être vraiment utile.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172894538
.

---

Junli Gu--谷俊丽
Laboratoire scientifique coordonné
Université de l'Illinois à Urbana-Champaign

---

J'ai juste supposé Benoit parce qu'il s'est lui-même assigné la fonctionnalité, mais je pense que vous l'avez compris Junli ! Peut-être commencer par un e-mail ou un fil de discussion des parties intéressées ?

@benoitsteiner en sait plus sur les parties intéressées qui ne se sont peut-être pas manifestées
dans ce fil (ou ce problème). J'attendrais qu'il se coordonne pour faire
sûr que nous évitons le travail en double.

Le mar. 19 janvier 2016 à 11 h 42 Dan McLaughlin [email protected]
a écrit:

J'ai juste supposé Benoit parce qu'il s'est lui-même assigné la fonctionnalité, mais je pense
vous l'avez Junli! Peut-être commencer par un e-mail ou un fil de discussion de
parties intéressées?

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

Je suis intéressé. Existe-t-il une feuille de route ?

Le 19 janvier 2016, à 11h46, Martin Wicke [email protected] a écrit :

@benoitsteiner en sait plus sur les parties intéressées qui ne se sont peut-être pas manifestées
dans ce fil (ou ce problème). J'attendrais qu'il se coordonne pour faire
sûr que nous évitons le travail en double.

Le mar. 19 janvier 2016 à 11 h 42 Dan McLaughlin [email protected]
a écrit:

J'ai juste supposé Benoit parce qu'il s'est lui-même assigné la fonctionnalité, mais je pense
vous l'avez Junli! Peut-être commencer par un e-mail ou un fil de discussion de
parties intéressées?

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Existe-t-il une liste des bibliothèques de dépendances CUDA sur lesquelles Tensorflow s'appuie ?

Cela aiderait à voir si nous pouvions avoir des alternatives OpenCL immédiates.

@hsaputra
Il y a clFFT, clBLAS (alternativement ViennaCL). Le générateur de nombres aléatoires est un peu plus délicat (pas de curand), utilisez un générateur de CPU et transférez-le vers le GPU ou utilisez un autre noyau existant pour RNG.

Le plus gros écueil sera à nouveau des implémentations de convolution efficaces (quelque chose comme cuDNN).

Il y a de l'expérience sur ces problèmes ici:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-caffe

Tensorflow utilise l'extension de tenseur en amont vers Eigen. Je pense donc qu'un support Opencl/Sycl pour Eigen est nécessaire. Voir ce fil

Merci @naibaf7. Oui, je ne pense pas qu'il existe une alternative viable à cuDNN pour OpenCL pour le moment.

Le site Web http://opencl.org est créé pour soutenir des projets de portage open source comme ceux-ci ! Nous installons actuellement tous les outils nécessaires sur le site Web et avons de l'espace pour les référentiels sur https://github.com/OpenCL/ - plus tard, nous ajoutons des serveurs de construction pour tester plusieurs types de matériel et pouvons fournir notre expertise dans comment écrire du code qui s'exécute à pleine vitesse sur de nombreux matériels.

Nous lançons une initiative de portage pour GEGL la semaine prochaine, mais nous sommes heureux de vous soutenir également.

@bhack de ce fil et ici, il semble que @lukeiwanski se penche dessus. Je pense que nous avons suffisamment de personnes volontaires pour travailler dessus, nous avons juste besoin de @benoitsteiner , @lukeiwanski ou @gujunli pour se coordonner. Benoit a été silencieux, il est peut-être en vacances.

J'aimerais contribuer à cette initiative.

salut tout le monde,

nous coordonnerons l'effort de portage du module tenseur d'Eigen vers SYCL pour OpenCL car nous avons déjà quelque chose qui fonctionne principalement, mais il n'est pas encore prêt à être révisé.

Nous sommes en faveur de cette approche car elle introduira moins d'invasion dans la base de code. SYCL prend en charge le modèle basé sur un modèle C++ à source unique qu'eigen utilise déjà.

La conception de la feuille de route est en cours, elle ne devrait donc plus tarder.

Merci,
Luc

@lukeiwanski Vous travaillez ou êtes en contact avec l'amont ? Pensez-vous qu'il sera accepté en amont à Eigen ?

+1

Bonne nouvelle @lukeiwanski , faites-nous part de toute aide dont vous avez besoin.

Je suppose que vous utilisez votre propre implémentation de SYCL - sera-t-elle disponible pour les développeurs/chercheurs ? Sur quelles plateformes ?

@lukeiwanski SYCL semble être la bonne voie à suivre compte tenu de la quantité de métaprogrammation de modèles impliquée dans Eigen. Je suis un développeur C++ expérimenté avec une expérience OpenCL acquise en développant mes propres réseaux de neurones et ma bibliothèque d'algèbre linéaire . J'aimerais aider dans cet effort et commencer à développer avec SYCL.

@bhack Nous sommes en contact avec @benoitsteiner , mais nous discuterons de notre proposition avec les mainteneurs en amont avant d'investir trop d'efforts.

@DanMcLaughlin , @ville-k Nous développons notre implémentation de SYCL, ComputeCpp (https://www.codeplay.com/products/computecpp). Pour plus d'informations, pouvez-vous s'il vous plaît me contacter hors liste via l'adresse e-mail sur mon profil?

@lukeiwanski y a-t-il une mise à jour/estimation concernant les plans ?

+1.
J'ai un GPU AMD et un GPU Intel dans l'ordinateur portable. Je pense que les deux ont des pilotes OpenCL et que le support d'AMD semble être bien meilleur. J'aurais de meilleures performances, car j'ai 2 appareils OpenCL. J'espère que vous le ferez évoluer avec les appareils OpenCL.

Salut tout le monde,

Merci pour l'intérêt!
À ce stade, nous mettons en place notre infrastructure de test pour nous assurer que rien de ce que nous faisons n'introduit de régression.
Nous sommes en contact avec @benoitsteiner pour nous assurer que nous sommes en phase avec ce qu'il a fait jusqu'à présent.

Nous sommes toujours en train de compiler une feuille de route pour le processus d'intégration - cela devrait être fait dans quelques semaines, car il y a quelques détails commerciaux à clarifier.

Notre objectif est d'apporter l'OpenCL à TensorFlow via Eigen d'ici la fin de cette année.

Merci,

intéressé. aimerait contribuer.

Ok, il semble donc en fait que ce soit un effort de Codeplay avec une sorte de synchronisation interne à Google. Quel est le rôle des abonnés AMD et Intel ici ?

/cc @keryell si cela vous intéresse de l'univers SYCL/FPGA

Mes excuses pour ne pas avoir contribué davantage à cette discussion récemment, mon assiette a été plus que pleine ces 2 dernières semaines.

Je coordonnerai l'effort OpenCL du côté de TensorFlow. Notre réflexion actuelle est :

• TensorFlow s'appuie sur c++11 et a adopté une approche "source unique", donc SYCL semble être un excellent choix.
• Nous n'avons pas beaucoup d'expérience OpenCL en interne, nous collaborons donc étroitement avec Codeplay pour combler cet écart. En particulier, Codeplay dirige actuellement les efforts visant à ajouter la prise en charge de SYCL à la bibliothèque de tenseurs Eigen.
• TensorFlow s'appuie sur la bibliothèque cuDNN pour calculer les convolutions sur les GPU NVidia. Si quelqu'un est intéressé à contribuer un équivalent OpenCL, nous serions heureux de vous aider.

Afin d'aider à structurer l'effort, j'ai créé une liste de diffusion : [email protected].

@bhack bien sûr que j'ai un certain intérêt pour le C++ haut de gamme sur FPGA :-)
TensorFlow ressemble également à un bon cas d'utilisation de validation pour triSYCL.
D'ailleurs, si certaines personnes ici recherchent des stages sur ce sujet, j'ai des postes à pourvoir. Il semble que Codeplay recherche également des personnes, si je fais confiance à leur site Web.

Je suis vraiment intéressé par les opinions de @karlrupp et @hughperkins . J'espère qu'ils voudront se joindre à la discussion sur le nouveau groupe Google.

@benoitsteiner Merci pour la mise à jour. Ce serait merveilleux si tous les partenaires impliqués dans @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx, etc.) faisaient la promotion d'une API de type cudnn de manière standardisée. Une sorte d'effort de normalisation de la vision par ordinateur Khronos openvx mais pour un apprentissage en profondeur.

@bhack Quel nouveau groupe Google ?

En dehors de cela, OpenCL et CUDA sont des approches de programmation trop différentes. CUDA fonctionne comme il est parce qu'une entreprise a un contrôle total sur tout, de sorte qu'elle peut intégrer des blobs binaires et qui sait quoi dans l'exécutable final. Cela ne peut pas être fait avec OpenCL, à moins que l'on ne suive le chemin SyCL (j'ai mes inquiétudes ...) et que le fournisseur du compilateur SyCL ait un contrôle total sur toutes les architectures cibles possibles (peu probable ou impossible en pratique). Dans l'ensemble, mon opinion est qu'une bonne bibliothèque compatible OpenCL nécessite plus que quelques ajustements ici et là. Ce n'est probablement pas ce que vous vouliez entendre, mais vous m'avez demandé mon avis :-)

@karlrupp Voir https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 à la fin pour le groupe google.
J'ai demandé votre avis car vous avez une grande expérience avec ViennaCL interfaçant une bibliothèque d'algèbre avec plusieurs backends (CPU, GPU, MIC). Tensorflow s'appuie sur la bibliothèque Eigein et sa nouvelle extension de tenseur apportée par Google en amont (mais uniquement avec le backend CUDA). Je pense qu'ils n'ont pas beaucoup vécu tous les écueils que vous avez déjà rencontrés avec ViennaCL au cours de ces années de développement.

@bhack Nous sommes actuellement à la réunion en face à face à Seattle cette semaine mais bien sûr je ne peux pas dire si nous parlons de bibliothèques DNN ou non... :-)

@keryell Essayez de faire avancer la cause à Seattle ;)

@karlrupp Vous avez raison, OpenCL et CUDA sont des approches de programmation trop différentes. L'aspect source unique trouvé par exemple dans CUDA et OpenMP 4.5 est extrêmement puissant du point de vue de l'ingénierie logicielle. C'est pourquoi il existe ce standard SYCL pour les vrais programmeurs C++. SYCL peut être vu comme CUDA sur stéroïdes sans aucune extension de langage et avec certains aspects OpenMP (les tâches). Un compilateur de périphérique SYCL typique devrait générer des noyaux SPIR-V.

Vos préoccupations concernant la portabilité sont moins un problème avec la norme SPIR-V (sorte d'équivalent portable de nVidia PTX/AMDIL/... dans le monde Vulkan & OpenCL) qui est obligatoire à accepter dans OpenCL 2.1 et Vulkan. Donc, la beauté est que si vous avez un frontal qui génère SPIR-V, vous n'avez pas besoin de connaissances particulières sur les détails mêmes du matériel sur lequel fonctionner. Il existe un traducteur bidirectionnel open source Khronos entre LLVM IR et SPIR-V, il ouvre donc de tout nouveaux territoires.

@keryell Je suis d'accord que SPIR-V est un pas en avant. Cependant, il ne résout pas tous les problèmes de jitting exhaustif.

vous n'avez pas besoin de connaissances particulières sur les détails mêmes du matériel pour fonctionner sur

Est-ce un copier-coller du marketing OpenCL 1.0, qui prétendait exactement la même chose ? Vous devrez _toujours_ vous pencher sur les détails du matériel sous-jacent si vous visez des performances maximales. C'est notamment le cas dans le cadre des contractions rapides du tenseur.

... comme @scott-gray l'a démontré avec le néon

@karlrupp

Est-ce un copier-coller du marketing OpenCL 1.0, qui prétendait exactement la même chose ?

Ha ha. :-)

Vous devrez toujours descendre dans les détails du matériel sous-jacent si vous visez des performances maximales. C'est notamment le cas dans le cadre des contractions rapides du tenseur.

Bien sûr, mais avant de jouer avec l'optimisation de second ordre, il est utile que la majeure partie du code C++ modélisé s'exécute de manière accélérée.

Pour l'optimisation, soit vous assemblez vos noyaux binaires optimisés à la NervanaSys, soit, puisque SYCL est du pur C++, vous pouvez y utiliser asm("...") avec beaucoup de #ifdef pour tester l'architecture cible. :-) Cela dit, SPIR-V est lui-même extensible et je ne vois pas pourquoi nous ne pourrions pas y mettre du VHDL ou du Verilog en ligne à un moment donné. :-)

Mais plus concrètement, l'introduction récente des opérations de sous-groupe devrait aider à obtenir de bonnes performances de manière portable et l'utilisation de simples fonctions ad hoc intégrées peut aider.

C++ ajoute des fonctionnalités de métaprogrammation intéressantes qui permettent de remplacer la plupart des générateurs de code utilisés comme dans clBLAS ou d'autres frameworks pour générer du code plus adapté au matériel X ou Y.

Aussi N4355 en c++17 pourrait entrer dans le jeu tôt ou tard

@karlrupp , @bhack L'approche tensorflow consiste à s'appuyer sur une abstraction matérielle (le module tenseur) pour la majorité des opérations nécessaires à un réseau de neurones typique, tout en s'appuyant sur des bibliothèques spécialisées (telles que cudnn) pour les quelques opérations qui sont vraiment critique en termes de performances. L'abstraction matérielle nous permet d'implémenter la plupart des opérations TensorFlow une fois et de les exécuter sur un accélérateur avec des performances plus que suffisantes.

@bhack Oui, j'aime les tableaux multidimensionnels. Toujours dans notre domaine d'intérêt, il y a le SG14 dans le comité C++ qui essaie de faire converger toutes les personnes intéressées par ces questions vers la norme.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Bien sûr, SYCL est dans les discussions. :-)

@benoitsteiner Principalement sur cudnn pour la mise en commun et la convolution. Je pense que si chaque fournisseur produit une API avec son propre matériel pour ces opérations avec son propre assemblage binaire, ce ne sera pas une approche aussi évolutive. C'est pourquoi je pense que certains appels d'API cruciaux pour les performances feraient mieux d'être standardisés d'une manière ou d'une autre.

@keryell Il y a des sujets vraiment intéressants pour Matrix/Tensor dans le nouveau SG14 c++ spécialement dans l'agenda des appels vector/SIMD. Mais il semble que personne n'ait parlé de convolution, de mise en commun et d'autres interfaces d'apprentissage en profondeur "stabilisées" utiles. Il me semble également que dans ces sous-groupes de normalisation spécifiques, il y a des gens de Nvidia, Intel, Amd, CodePlay etc. mais pas de Google aussi si c'est dans d'autres groupes.

:+1:

@bhack Oui, il n'y a pas encore de proposition de style d'apprentissage automatique dans SG14. Mais la participation est ouverte, vous pouvez donc envoyer des propositions. :-) Mais peut-être que SG6 (sujets numériques) est plus pertinent. Je ne pense pas qu'ils aient encore leur propre liste de diffusion/forum.

@gujunli OpenCL Caffe fonctionne-t-il sur Android ? Désolé de poser cette question ici, mais je n'ai trouvé nulle part ailleurs pour le demander :) Ce serait formidable avec une bibliothèque d'apprentissage en profondeur qui fonctionnait sur des appareils Android _et_ pourrait utiliser le GPU, mais il semble qu'il n'y en ait pas pour le moment. (Corrige moi si je me trompe!)

@krikru
La branche OpenCL Caffe officielle (mais expérimentale) peut être conçue pour fonctionner sur des GPU Android, mais les performances sont pour le moment loin d'être optimales. Voir https://github.com/sh1r0/caffe-android-lib/issues/23 et https://github.com/BVLC/caffe/tree/opencl.

Une véritable alternative à cudnn pourrait être l'extension des objets standard OpenVx avec prise en charge des opérateurs Tensor, NdConvolution, NdPooling et (probablement) un autre opérateur qui pourrait être considéré comme standardisable.
De plus, l'équipe cudnn doit faire un choix sur les nouvelles API et opérateurs qu'elle introduira dans chaque version. Bien sûr, une norme ne peut pas évoluer aussi rapidement que les versions de cudnn, mais je pense que certaines opérations et certains objets ont suffisamment "d'historique des citations" pour être standardisés.

@hughperkins Pour le moment, je n'ai essayé aucune bibliothèque d'apprentissage en profondeur; Je fais juste quelques repérages pour voir quelle bibliothèque je pourrais potentiellement utiliser. Avez-vous essayé cltorch et DeepCL sur Android ? J'ai juste supposé que cltorch fonctionnait sur Android, car il existe une implémentation de Torch dédiée spécifiquement à Android. Et pourquoi auriez-vous une telle implémentation s'il y en avait déjà une qui fonctionnait à la fois sur Android _et_ utilisait OpenCL, n'est-ce pas ? Mais j'aurais peut-être dû savoir mieux.

@hughperkins Pour une raison quelconque, j'imaginais que torch-android était une implémentation officielle de Torch pour Android, ce qui signifie qu'aucune autre implémentation de Torch (du moins pas officielle) n'était susceptible de fonctionner correctement sur Android, y compris cltorch. Je ne sais pas pourquoi j'ai pensé cela, cela n'a bien sûr aucun sens.

Eh bien... Soumith coordonne en quelque sorte le développement de la torche. Il travaille chez Facebook AI Research. Donc, puisque le repo torch-android appartient à Soumith, je dirais que c'est assez proche de l'officiel. Mais cela ne fait peut-être pas partie du noyau pour une raison quelconque. Je suppose que vous pouvez poser la question comme un problème dans ce référentiel, ou dans https://groups.google.com/forum/#!forum/torch7 En fait, puisque Soumith est en quelque sorte la personne principale qui gère les requêtes en https : //groups.google.com/forum/#!forum/torch7 , je pense que vous voulez probablement y poster votre question.

ce qui signifie qu'aucune autre implémentation de Torch (du moins pas officielle) n'était susceptible de fonctionner correctement sur Android, y compris cltorch

Notez que cltorch n'est pas une implémentation de torche. C'est un plugin, qui fournit OpenCL. Vous avez besoin des deux.

Notez que cltorch n'est pas une implémentation de torche. C'est un plugin, qui fournit OpenCL. Vous avez besoin des deux.

Ah, merci pour la précision.

@naibaf7 La branche OpenCL Caffe et l'implémentation OpenCL Caffe par AMD ont-elles autre chose en commun que le nom ? Avez-vous comparé les deux ou savez-vous s'il y a une différence de performances? Vous écrivez que la branche OpenCL est loin d'avoir des performances optimales. Qu'est-ce que cela signifie et que faudrait-il pour l'améliorer? Il serait intéressant de l'essayer sur Android.

On s'éloigne du sujet

@bhack Ouais, désolé d'avoir détourné ce fil. Je ne savais juste pas où poser la question.

@krikru
veuillez soulever un problème à ce sujet sur la branche Caffe, le signaler avec Android et OpenCL. Ensuite, nous pourrons en discuter davantage. Merci.

@keryell Il semble que la prochaine réunion f2f SG14 en mars sera organisée par Google . Y aura-t-il un tensorflow interne là-bas ?

/cc @jfbastien

Peut-être que @benoitsteiner pourrait passer, puisqu'il est local.
Mais avant cet événement, il y a le plein C++ F2F à la fin du mois à Jacksonville, en Floride.
https://isocpp.org/files/papers/N4568.pdf
Malheureusement, je ne pourrai assister à aucun d'entre eux.

Je ne sais pas si CppCon 2015 talk C++ Multi-dimensional Arrays for Computational Physics and Applied Mathematics a généré un suivi papier.

+1

@bhack Merci d'avoir pointé le discours sur les tableaux multidimensionnels. Il est intéressant et aborde les vrais problèmes mais semble trop ad hoc pour être ratifié en C++ tel quel. Personnellement, j'utilise Boost.MultiArray et je suis plus confiant dans une version raffinée de Boost.MultiArray.

Il y a aussi des articles au WG21 . Comme vous pouvez le voir , @jfbastien chez Google a une certaine activité au WG21 et a également aidé à organiser la réunion SG14 f2f chez Google en mars.

@bhack @keryell Je pense que cela vaudrait la peine de porter cette discussion sur la liste de diffusion SG14 car les détails ne sont pas liés à OpenCL / tensorflow.

Oui probablement ce n'est plus si strictement confiné ici avec tous les détails. Autre que le support Eigen/sycl Existe-t-il un plan pour les appels cudnn ?

+1 sujet très intéressant. J'espère que ça viendra bientôt.

Ce fil est très intéressant. J'ai essayé de faire fonctionner Caffe sur Android. Les résultats semblent surprenants : le café fonctionnant avec le processeur graphique Mali semble être 2 à 3 plus lent que le processeur, mais environ 4 à 5 fois plus économe en énergie. Le test a été exécuté sur Galaxy S6 (Mali T760, Peak Performance 200 GFlops).

Étant donné que GEMM est au cœur de la convolution dans caffe, j'ai décidé de profiler ses performances sur Android. Il semble que ViennaCL ne soit pas aussi efficace que certains noyaux simples. Maintenant, je peux faire fonctionner le GPU aussi vite que le CPU pour les grandes matrices (2k x 2k). C'est toujours contre-intuitif, car normalement, nous nous attendons à ce que les GPU soient beaucoup plus rapides.

Voir:
https://github.com/strin/mocha-profile

Les implémentations du noyau peuvent être trouvées ici :

Noyaux OpenCL pour GEMM : https://github.com/strin/gemm-android

Des pensées?

@strin Avez-vous déjà suivi ce fil https://community.arm.com/thread/4935 ?

@bhack merci pour le partage. ce fil a l'air très intéressant. J'ai essayé de désactiver le DVFS comme suggéré, mais aucune performance significative n'a été observée pour sgemm dans ViennaCL.

+1

@strin Avez-vous essayé la dernière version de sgemm dans le SDK MALI ?

Tensorflow est en retard ! Ah ah
https://gist.github.com/jarutis/ff28bca8cfb9ce0c8b1a

Cela aura un impact sur la stratégie : http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
ÉDITER:
"StreamExecutor est actuellement utilisé comme moteur d'exécution pour la grande majorité des applications GPGPU internes de Google, et un instantané de celui-ci est inclus dans le projet open source TensorFlow_, où il sert de moteur d'exécution GPGPU."

+1

J'espère que les personnes qui y travaillent parviendront à surmonter le problème alternatif CUDNN au moment où tensorflow approchera de 1.0

@martinwicke pourquoi ce problème est-il clos ?

Je ne pense pas que votre commit corrige cela.

Vous ne pouvez pas toujours utiliser les mêmes commentaires de validation dans différents référentiels ;) https://github.com/tensorflow/skflow/issues/22

Oh GitHub

@vrv Maintenant que vous nous avez hyper informés, pouvez-vous nous faire part de vos commentaires sur la stratégie de l'exécuteur de flux ? ;)

Je vais juste blâmer GitHub pour tout, y compris le manque de support OpenCL. ;)

@benoitsteiner pourra peut-être commenter davantage. Je ne sais pas vraiment ce que vous entendez par stratégie de "stream executor". Nous utilisons actuellement une version de stream executor et CuDNN et Eigen et ils fonctionnent tous bien ensemble, donc je ne sais pas comment les plans ont changé pour le côté OpenCL des choses

Je veux dire:
"Qu'est-ce que StreamExecutor ?
========================
StreamExecutor est un wrapper unifié autour des modèles de programmation côté hôte CUDA et OpenCL (runtimes). Il permet au code hôte de cibler des périphériques CUDA ou OpenCL avec des noyaux parallèles aux données fonctionnant de manière identique."

Opérations en conserve
==================
StreamExecutor fournit plusieurs noyaux prédéfinis pour les opérations communes de données parallèles.
Les classes d'opérations prises en charge sont :

• BLAS : sous-programmes d'algèbre linéaire de base,
• DNN : réseaux de neurones profonds,
• FFT : transformées de Fourier rapides, et
• RNG : génération de nombres aléatoires.

@keryell Salut, je suis également intéressé par l'implémentation de TensorFlow sur FPGA, en utilisant des langages de programmation de haut niveau comme Xilinx C++ ou OpenCL. Je suis avec plaisir de contribuer si vous avez un plan.

@henline Pouvez-vous expliquer quel sera le rôle de StreamExecutor sur Opencl et de Canned pertinent
opérations pour Tensorflow. Je ne vois toujours pas comment cela s'intégrera aux plans SyCL sur Eigen et cudnn (remplacement ?)

:+1: J'aimerais aussi y contribuer.

@bhack StreamExecutor fournit des fonctionnalités équivalentes à celles du runtime CUDA et de certaines bibliothèques CUDA (telles que cublas ou cudnn). Cependant, vous devez toujours écrire vos noyaux GPU, c'est pourquoi nous utilisons Eigen.

@benoitsteiner Est-il donc encore nécessaire d'écrire deux noyaux, un pour CUDA et un pour Opencl ?

@benoitsteiner Alors, n'avez-vous pas encore un homologue tensorflow/tensorflow/stream_executor/opencl/ en interne ? Qu'en est-il des "opérateurs en conserve" ?

@bhack Eigen vous permet d'écrire une expression décrivant le calcul que vous souhaitez effectuer une fois et de générer automatiquement un noyau (que nous appelons l'évaluateur) pour évaluer cette expression sur le processeur et un autre noyau pour évaluer l'expression sur un périphérique CUDA. Une fois que nous aurons le support d'OpenCL dans Eigen (nous approchons), il sera également possible de générer automatiquement le noyau OpenCL.
Pour quelques opérations TensorFlow critiques pour les performances (telles que la convolution), nous utilisons des noyaux optimisés manuellement et/ou des bibliothèques tierces. Dans ces cas, nous aurons besoin d'une bonne implémentation OpenCL de ces opérations.

:+1:

Existe-t-il un plan pour pousser plus de code dans https://bitbucket.org/benoitsteiner/eigen-opencl ? Qu'en est-il du compilateur sycl ? Il semble qu'aucune implémentation de cible GPU open source n'ait été publiée.

@bhack @benoitsteiner
Je publierai bientôt un remplacement de cuDNN (uniquement la partie convolution, car c'est la plus critique en termes de performances et de mémoire pour que cela soit fait) pour OpenCL sur Caffe. Peut-être que ce sera aussi utile pour le port Tensorflow.

@bhack : Codeplay a fait beaucoup de progrès sur le front opencl. Restez à l'écoute pour un gros coup de pouce sur https://bitbucket.org/benoitsteiner/eigen-opencl dans les prochaines semaines.

@naibaf7 : Une implémentation rapide de l'opération de convolution serait extrêmement utile dans TensorFlow. J'ai hâte d'y être.

@benoitsteiner Belle prise, ils ont la chaise

@benoitsteiner Comment puis-je simplement supprimer l'implémentation de cuda ? parce que '#ifdef GOOGLE_CUDA' est si compliqué. Cela signifie parfois CUDA, parfois GPU.

Étant donné que ce problème a fait son chemin vers la feuille de route (voir _Platforms_) : avons-nous à peu près une idée du moment où le support OpenCL arrivera sur TensorFlow ? Vous aimez la version 0.9 / 1.0 ? Q3/4 2016 ? Ou 2017 est-il plus réaliste ?

@benoitsteiner Est-ce que eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl est suffisamment prêt pour supporter un développement de flux de tenseur opencl ?

Est-ce que tensorflow dépend uniquement des tenseurs Eigen ou existe-t-il d'autres dépendances d'Eigen ?

@NEELMCW Codeplay vient de publier une prise en charge partielle d'OpenCL pour Eigen Tensors. Le code est disponible dans ce référentiel bitbucket . Pour l'essentiel, TensorFlow dépend des tenseurs propres. Il existe des dépendances supplémentaires sur Eigen pour les opérations d'algèbre linéaire, mais nous n'avons pas à fournir une implémentation compatible OpenCL de ces opérations (du moins pas initialement). Par conséquent, nous sommes en très bonne position pour commencer à prendre en charge OpenCL dans TensorFlow.

Si vous êtes intéressé à contribuer, j'ai commencé à suivre ce qui doit être fait dans cette feuille de calcul

@benoitsteiner Je suis l'auteur d'une bibliothèque C++11 OpenCL BLAS (https://github.com/CNugteren/CLBlast) et j'y implémente actuellement un support de demi-précision. Je suis heureux de contribuer à la partie BLAS/GEMM de ce projet et/ou de modifier CLBlast pour mieux répondre à vos besoins.

@CNugteren
CLBlast est désormais également disponible dans OpenCL-Caffe, vous avez vu ça ? :)
Avez-vous également eu l'occasion de regarder les convolutions libDNN ?

@naibaf7 Je l'ai vu, oui ! :) Je n'ai pas du tout regardé libDNN jusqu'à présent, mais je ne suis pas sûr de ce que vous voulez dire exactement. Je suppose que la convolution est implémentée à l'aide de GEMM ?

@CNugteren
Oui, j'ai juste pensé que ce serait bien si vous pouviez y jeter un coup d'œil et peut-être donner des conseils d'amélioration ou de réglage sur libdnn.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Il utilise GEMM, mais implicite (pas via un BLAS, seulement de petits GEMM au niveau d'un groupe de travail) de sorte qu'un niveau de parallélisme plus élevé est possible, ainsi qu'aucun tampon intermédiaire n'est nécessaire (pour dérouler les données dans un schéma GEMM).

Salut à tous,

@benoitsteiner merci d'avoir mentionné notre poussée ! J'espère que ce sera utile!

Pour compiler ce code, vous avez besoin d'un compilateur SYCL. Actuellement, le seul compilateur pris en charge est ComputeCpp de Codeplay, qui est disponible via le programme d'évaluation de Codeplay. ComputeCpp sera mis à disposition gratuitement en tant que bêta ouverte publique, plus tard en 2016, puis publié avec une version gratuite (ComputeCpp Community Edition) en 2017. Cela permettra à quiconque de compiler et de développer TensorFlow sur des appareils OpenCL, tels que les GPU AMD ou Intel. et les processeurs.

d'ailleurs. ce problème ne devrait-il pas avoir l'étiquette OpenCL ? :)

Merci,
Luc

J'espère vraiment que cela pourrait être compilé aussi avec un outil open source. @keryell comment ça se passe avec votre nouvelle branche Opencl

@bhack Ce serait bien de voir s'il peut d'abord fonctionner avec triSYCL en mode périphérique hôte CPU OpenMP. Mais je n'ai pas la bande passante pour entrer dans le système de construction TensorFlow/Eigen maintenant. :-( Si quelqu'un veut essayer, n'hésitez pas à le faire. :-)

https://github.com/keryell/triSYCL/commits/opencl devrait permettre de faire tourner les noyaux OpenCL prochainement en mode d'interopérabilité OpenCL, mais pas dans le mode source unique SYCL dont nous rêvons tous car nous n'avons pas encore l'outliner Clang/LLVM pour extraire les noyaux de SYCL. Mais Khronos a récemment open-source les composants d'AMD & Intel pour supporter OpenCL C++ 2.2 & SPIR-V qui en seraient la base. C'est donc "juste" une question de temps...

Quelqu'un pourrait-il fournir des estimations sur le moment où Tensorflow pourrait être en mesure de fonctionner avec OpenCL (GPU AMD) ? Et à quoi ressemble la courbe performance/utilisabilité dans le temps ? Il est difficile d'analyser toutes les informations passées en informations d'achat de matériel exploitables. :)

Merci d'avance!

@djan92
Je dirais de lui donner un an jusqu'à ce qu'il soit utilisable, malheureusement. Il semble qu'il sera construit sur des bibliothèques et des technologies de pointe, dont la plupart ne sont pas encore tout à fait prêtes.
Je ne vais également me lancer que dès que la pile d'outils complète sera disponible en OpenSource et pas avant.

@naibaf7

Je dirais de lui donner un an jusqu'à ce qu'il soit utilisable, malheureusement. Il semble qu'il sera construit sur des bibliothèques et des technologies de pointe, dont la plupart ne sont pas encore tout à fait prêtes.
Je ne vais également me lancer que dès que la pile d'outils complète sera disponible en OpenSource et pas avant.

Pourquoi ne pas implémenter d'abord une version CL en attendant que le port SYCL soit prêt ? Je suppose qu'il y a pas mal de gens ici qui sont prêts à aider. Un an semble trop long.

@djan92
Oui, vous avez raison, #22 a presque 8 mois et a plus de 100 posts ! Les informations peuvent être submergées !

Quelqu'un pourrait-il fournir des estimations sur le moment où Tensorflow pourrait être en mesure de fonctionner avec OpenCL (GPU AMD) ?

TensorFlow utilise la bibliothèque Eigen pour le calcul des tenseurs (dans le module Tensor). Nous avons engagé une implémentation partielle pour OpenCL 1.2 en utilisant SYCL (https://bitbucket.org/benoitsteiner/opencl branch Codeplay). La raison pour laquelle nous avons utilisé SYCL pour ce travail est que cette section de TensorFlow utilise des arbres d'expression C++, ce qui est possible avec SYCL pour OpenCL, mais pas possible avec OpenCL C directement. D'autres composants de TensorFlow, tels que les convolutions ou BLAS, pourraient utiliser OpenCL C directement.

Actuellement, je travaille sur l'intégration de ComputeCpp (le compilateur SYCL de Codeplay) dans le système de construction bazel. Cela devrait être bientôt prêt (suivez ce dépôt : https://github.com/benoitsteiner/tensorflow-opencl/). Une fois cela fait, TensorFlow doit être accéléré sur les systèmes prenant en charge OpenCL SPIR (tels qu'AMD ou Intel) avec ComputeCpp. D'autres travaux se poursuivront pour accélérer davantage TensorFlow, ainsi que pour prendre en charge davantage d'implémentations OpenCL et le SYCL open source triSYCL. SYCL et OpenCL sont des normes ouvertes multifournisseurs et libres de droits, de sorte qu'il existe de nombreuses plates-formes et appareils qui peuvent être pris en charge à l'aide de cette approche (pas seulement les GPU AMD).

Le compilateur ComputeCpp Community Edition sera disponible gratuitement plus tard en 2016 (sous forme bêta : la conformité complète sera publiée gratuitement début 2017).

Le travail d'accélération des parties non C++ de TensorFlow (par exemple, BLAS et convolutions) pourrait être effectué sans SYCL et implémenté séparément. Différents fournisseurs de matériel peuvent avoir leurs propres bibliothèques optimisées pour ces fonctionnalités, ce qui pourrait faciliter l'accélération. Ou, nous pourrions utiliser Eigen avec C++ pour ces fonctionnalités.

Et à quoi ressemble la courbe performance/utilisabilité dans le temps ?

Nous pensons que les performances s'amélioreront régulièrement. Pour accélérer sur une grande variété d'appareils, nous devons gérer les données plus efficacement, c'est pourquoi il existe un élément de travail "tenseur géré", afin que le mouvement des données puisse être géré plus efficacement entre l'hôte et plusieurs appareils. Il est difficile de prédire comment les performances varieront sur une large gamme d'appareils, pour le moment. Actuellement, très peu de choses sont accélérées, mais nous mettons l'infrastructure en place pour permettre une accélération à standard ouvert dans TensorFlow.

@naibaf7

Je dirais de lui donner un an jusqu'à ce qu'il soit utilisable, malheureusement.

Les opérations de base devraient être là très bientôt. Nous mettons en place l'infrastructure de base dans le code pour prendre en charge l'accélération basée sur des normes ouvertes. Nous pensons qu'avec le soutien de la communauté, une version accélérée et utilisable sera prête dans moins d'un an.

Je ne vais également me lancer que dès que la pile d'outils complète sera disponible en OpenSource et pas avant.

ComputeCpp sera disponible publiquement, gratuitement, en 2016. Le support triSYCL open-source devrait suivre. L'open-source OpenCL est déjà pris en charge avec pocl, Shamrock, Clover, Beignet.

@robertwgh
Le code tenseur C++ dans Eigen ne serait pas facilement portable vers OpenCL C sans SYCL, mais il existe d'autres fonctionnalités qui fonctionneraient bien sur OpenCL C. Jetez un œil à cette feuille de calcul : https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 et remplissez gratuitement inscrivez votre nom sur les fonctionnalités qui doivent utiliser OpenCL C normal (comme BLAS et convolutions).

Nous donnons une version d'évaluation pour ComputeCpp avant la sortie publique. Si vous en souhaitez un, n'hésitez pas à m'envoyer un mail :)

@lukeiwanski Super, merci pour la mise à jour. J'espère que vous avez raison de le faire entièrement en moins d'un an.

Une autre étape de Streamexecutor dans LLVM

aucune chance d'obtenir une accélération sur le rx 480?

@benoitsteiner
LibDNN autonome serait disponible pour l'intégration :
https://github.com/naibaf7/libdnn

C'est super de lire que c'est en cours d'élaboration. Cela aiderait si Beignet 2.0 était poli. Beaucoup de potentiel avec Skylake et Iris en ce moment.

Une demande d'extraction récente a été ajoutée à https://github.com/benoitsteiner/tensorflow-opencl/pull/1 si quelqu'un veut jeter un coup d'œil.

Le SDK OpenCL d'Imagination (GPU) a besoin de NDA pour être accessible, nous n'avons que la bibliothèque partagée. Est-il possible d'exécuter tensorflow basé sur ces bibliothèques ?

@alephman
Vous n'avez pas besoin de fichiers d'en-tête spécifiques au fournisseur pour créer un programme OpenCL. Essayez cl.hpp depuis https://www.khronos.org/registry/cl/api/1.2/cl.hpp et opencl.h/cl.h depuis n'importe quel autre SDK. Par exemple - j'ai au moins 3 plates-formes OpenCL et tout cela fonctionne avec un /usr/include/CL/cl.h partagé

Nous ne prenons pas encore en charge TensorFlow exécuté sur OpenCL. C'est un travail en cours. Actuellement, nous travaillons sur des GPU AMD. La prise en charge de PowerVR devrait suivre. Si vous souhaitez contribuer au développement, vous devez nous contacter (Codeplay) directement. Si vous souhaitez exécuter TensorFlow sur PowerVR, vous devez attendre un peu plus de progrès.

@inferrna merci, cela ressemble à l'OpenGL qui cache l'implémentation du fournisseur spécifique.

@andrewrichards J'aime contribuer au développement, comment vous contacter ?

Le plus simple est de cliquer sur "enregistrer votre intérêt" sur notre page ici : https://www.codeplay.com/products/computecpp
Cela vous fera entrer dans notre programme de développement et nous pourrons travailler ensemble sur ce @alephman

Si vous le souhaitez, vous pouvez également contribuer à permettre de compiler avec une alternative open source. Voir https://github.com/tensorflow/tensorflow/issues/22#issuecomment -221841173

Salut à tous!
Très heureux d'apprendre que le support de Tensorflow est étendu en dehors de Nvidia Cuda. Je me demande si vous envisagez également de le faire fonctionner sur des APU comme celui-ci : http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
Les APU prennent en charge OpenCL pour la partie CPU et GPU.
Cela devrait fonctionner à peu près immédiatement lorsque le support OpenCL est prêt.
En attendant, si vous avez déjà un APU et que vous souhaitez essayer un autre framework ML, BVLC OpenCL Caffe fonctionne déjà.

@naibaf7 Merci pour la clarification. Je recherche des combinaisons matérielles/logicielles rentables pour exécuter localement Tensorflow et je suivrai certainement les progrès du développement OpenCL.

@hughperkins
Oui, cela peut être un problème, mais je pense que des parties telles que im2col/col2im et d'autres implémentations de convolution pourraient également être connectées en tant qu'API externes si c'est vraiment un problème avec le GCLA. Cela peut également être préférable pour les auteurs originaux de ces travaux.

@hughperkins Nous travaillons à apporter l'OpenCL au TensorFlow via le SYCL pour OpenCL 1.2.
Veuillez consulter https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 pour les "todos" et la progression.
Récemment, nous avons publié un compilateur pour SYCL https://www.codeplay.com/products/computesuite/computecpp appelé ComputeCpp Comunity Edition. Les gens peuvent l'essayer !
De plus, nous nous concentrons sur la bibliothèque Eigen https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp - l'amenant à l'étape requise par le MNIST de TensorFlow - il reste quelques éléments.
En ce qui concerne les contraintes, la version actuelle de ComputeCpp CE a été testée pour Intel (CPU, GPU) et AMD (CPU, GPU) comme pour les plates-formes que nous prenons en charge Ubuntu 14.04 64 bits et CentOS 64 bits.
ComptueCpp est téléchargeable gratuitement et peut être utilisé dans des projets commerciaux et open source.
Parce que nous <3 ouvrons des communautés :)

@lukeiwanski Désolé d'avoir discuté/demandé ceci ici dans le fil, mais je pense que cela peut également intéresser d'autres personnes : je comprends que Codeplay est très intéressé par l'implémentation de SYCL pour OpenCL et j'ai déjà entendu d'autres personnes s'intéresser à ce travail de vous aussi. J'ai lu un message d'un responsable de Movidius par exemple. Cependant, je voudrais demander quelle est vraiment la contribution de Google à cela ? Étant donné que Movidius, outre AMD et d'autres, sont répertoriés comme partenaires de Codeplay, je peux comprendre qu'ils encouragent ou même soutiennent SYCL pour OpenCL, mais pour autant que je sache, Google n'est pas votre partenaire et n'a pas contribué jusqu'à présent ? !

Ne vous méprenez pas, j'aime beaucoup votre travail, mais ne serait-il pas judicieux de consolider vos efforts, de mutualiser les ressources et d'essayer de travailler avec Google ? Pour moi, il semble que de nombreuses parties différentes s'intéressent à OpenCL pour TensorFlow, mais un énorme potentiel n'est pas utilisé, car ces parties ne se développent pas ensemble ? !

Je peux me tromper et veuillez m'excuser si cela a été suffisamment discuté, mais je ne suis toujours pas au courant de toute tentative majeure de Google (ou d'autres parties) de travailler ensemble à ce sujet et, par conséquent, je ne sais toujours pas comment la communauté pourrait aider ou soutenir (comme les personnes seules), soit via des contributions directes, des tests ou d'autres choses.

@ascenator Chez Google, nous travaillons en étroite collaboration avec Luke et ses collègues Codeplay sur ce projet depuis près de 12 mois maintenant. La contribution de Codeplay à cet effort a été énorme, nous avons donc pensé que nous devrions les laisser prendre les devants lorsqu'il s'agit de communiquer les mises à jour liées à OpenCL. C'est pourquoi vous n'avez pas beaucoup entendu parler de nous sur le sujet :)

Maintenant que le compilateur ComputeCpp est largement disponible, nous prévoyons de fusionner le travail effectué jusqu'à présent. Mais nous voulons d'abord mettre en place une infrastructure de test complète pour nous assurer que nous ne déstabilisons pas la base de code existante.

Nous accueillons toutes les contributions à cet effort, alors n'hésitez pas à me contacter si vous souhaitez aider. Nous sommes particulièrement intéressés par les noyaux OpenCL hautes performances pour la multiplication matricielle et les convolutions. Plusieurs candidats ont été suggérés, mais nous n'avons pas commencé à examiner les avantages et les inconvénients de chacun ni comment les intégrer.

@benoitsteiner merci beaucoup pour la clarification et désolé pour ma désinformation ! Cela semble très bon et prometteur ! Je vais certainement jeter un œil à ComputeCpp alors. J'attends avec impatience la prise en charge d'OpenCL pour TensorFlow, car cela offre de nombreuses nouvelles possibilités pour la robotique (qui est le domaine dans lequel je recherche et utilise TensorFlow pour des applications d'apprentissage en profondeur). Je vais au moins jeter un œil aux premières versions et essayer de tester/déboguer. Nous avons des puces Intel ainsi qu'un certain nombre de processeurs ARM qui attendent des tests ;)

@hughperkins... désolé mais n'est-ce pas complètement hors sujet ici ? Je ne vois pas en quoi cela est pertinent dans OpenCL TF ?

Je suis plus intéressé ici pour savoir si une approche de réglage des noyaux de multiplication matricielle et de convolution sera adoptée et s'il y aura une alternative open source valide à CompiteCpp qui produira SPIR-V.

http://llvm.org/docs/CompileCudaWithLLVM.html

Deux nouvelles normes du groupe Kronos sont publiées sur https://www.khronos.org/news/press/khronos-launches-dual-neural-network-standard-initiatives

Si cela peut aider, une meilleure version d'isaac est disponible : https://github.com/ptillet/isaac , et fournit des accélérations significatives par rapport à clBLAS et cuBLAS sur Maxwell, Pascal et Fiji. Fournit également des noyaux plus rapides (conscients des entrées) que Tensorflow pour les réductions 1D et 2D.

@hughperkins semble que vous avez plus de chances d'écrire un compilateur CUDA pour n'importe quel périphérique OpenCL, plutôt qu'un traducteur CUDA-OpenCL.

@hughperkins Peut-être que la fonctionnalité SVM d'OpenCL 2.0 pourrait résoudre le problème du pointeur ? Puisque tout le monde en dehors de Nvidia (AMD, Intel, ARM, Qualcomm) commence à prendre en charge OpenCL 2.0. C'est peut-être une bonne solution ?

@hughperkins c'est une implémentation blasée elle-même. Il implémente certains des symboles dans les en-têtes clblas et cublas, donc pas de recompilation ni de modification de code. est nécessaire. Je pourrais également implémenter certains des symboles pour clblast.h, car il utilise un en-tête différent. Certains avantages d'Isaac sont:

• Entièrement dynamique, de sorte qu'il peut utiliser CUDA ou OpenCL sans recompilation.
• Conscient des entrées, il ne règle pas les noyaux pour les grandes matrices carrées. Il devrait bien fonctionner sur toutes les formes auxquelles vous pouvez penser sans réaccorder.
• API C++ similaire à numpy/arrayfire. Une certaine fusion pour combiner le fonctionnement par éléments avec des réductions

@marty1885
Pas vraiment. AMD est revenu au support 1.2 sur les pilotes AMDGPU-PRO. Il faudra peut-être un certain temps avant que la prise en charge complète de la version 2.0 ne soit généralisée. Certainement pas une solution à court terme là-bas.

• Oui
• Je pourrais pirater la compatibilité pour un tas d'opérations si nécessaire (par exemple, transmettre ** MV à GEMV). Un support complexe sera délicat. Le double support est déjà là mais aucune architecture n'est adaptée pour cela.

@hughperkins

On dirait que mon code ne viole aucune règle OpenCL évidente

Oui, passer clairement toute structure __global (comme un tableau ou une structure) contenant des pointeurs est incorrect simplement parce que ces pointeurs peuvent pointer vers la mémoire d'un autre périphérique (OpenCL prend en charge le paradigme multi-périphérique où un périphérique ne peut pas accéder à la mémoire d'un autre). Mais il semble être possible de surmonter au niveau IR, sans traduction intermédiaire en code OpenCL - c'est ce que j'ai supposé :)

@benoitsteiner , @henline , de https://github.com/henline/streamexecutordoc , cela suggère que le streamexecutor a pris en charge l'opération prédéfinie de la version CL (comme DNN, BLAS) prête à l'emploi. Cela suggère-t-il que Google a déjà la mise en œuvre clDNN, clBLAS prête pour Tensorflow, mais tout simplement pas encore open source?

Sinon, OpenCL 2.0+ et SYCL 2.2 prennent en charge SVM, si vous souhaitez conserver la même architecture logicielle.
OpenCL 2.0+ est pris en charge par AMD et Intel GPU par exemple. Dans le monde embarqué, il est souvent pris en charge par effet secondaire même avec OpenCL 1.x, car les mémoires de l'hôte et de l'appareil sont souvent les mêmes pour des raisons de coût.

@keryell
Mais les plates-formes les plus notables, Linux + les nouveaux GPU AMD (RX 480, Vega à venir) ne prennent en charge que OpenCL 1.2 pour le moment... et qui sait quand cela va changer (mon pari est dans un an). Beignet (open source Linux Intel) pour OpenCL 2.0 est également toujours un gâchis bogué ; la version stable a 1.2.
Considérant également que toutes les petites entreprises qui fabriquent des puces compatibles OpenCL tirent à peine le support 1.2. Je suppose donc que tout ce qui repose sur OpenCL 2.0 verra de très mauvais taux d'adaptation dans la pratique.

Je pense .. que tout fournisseur de matériel a l'urgence de consommer SPIR-V? Je pense que la pression Graphic/Shaders sur Vulkan pourrait aider Opencl.

@naibaf7 pour revenir à la discussion sur OpenCL 2 ou non, à un moment donné, de vraies choses doivent être livrées... Sinon, il y a déjà nVidia GPU et CUDA avec TensorFlow en cours d'exécution... :-)
Mais bien sûr, une version de TensorFlow sans SVM a un certain intérêt.

@keryell Selon vous, quelle part du travail de Vulkan SPIR-V sur les pilotes (qui a déjà une bonne couverture des périphériques) poussera les versions modernes d'Opencl ?

@naibaf7 La réunion de Khronos aura lieu la semaine prochaine à Séoul avec OpenCL et Vulkan, mais les discussions ne sont pas publiques. Mais cela semble être une bonne idée d'avoir chaque monde pour améliorer l'autre, et à un moment donné profite à TensorFlow. :-)

@keryell
Oui, j'espère qu'ils discuteront de choses bénéfiques pour DeepLearning :)

Félicitations! Assurez-vous de vérifier le projet HIP, car ils ont essayé de résoudre le même problème. Ils ont choisi de créer un nouveau langage appelé HIP, qui définit ce qui doit être converti manuellement (comme vérifier la prise en charge de la double précision en vérifiant le niveau de calcul). Au fur et à mesure que le projet avancerait, le nombre de traductions manuelles diminuerait. Voir : https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

Ma suggestion pour vous est d'utiliser HIP et de corriger certains bogues qui bloquent l'avancement de Tensorflow ou vos propres objectifs, car vous avez maintenant la compréhension de LLVM pour le faire. De cette façon, vous n'avez pas à résoudre les problèmes qu'ils ont déjà résolus.

@hughperkins
impossible de construire le module python avec votre fork en suivant ceci https://github.com/tensorflow/tensorflow/blob/master/tensorflow/g3doc/get_started/os_setup.md#create -the-pip-package-and-install

INFO: From Compiling tensorflow/core/kernels/gather_functor_gpu.cu.cc:
gpus/crosstool: -x cuda
gpus/crosstool: using cocl
gpus/crosstool: PATH=/usr/bin:/usr/local/bin /usr/local/bin/cocl -D_FORCE_INLINES -gencode=arch=compute_30,\"code=sm_30,compute_30\"   -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DEIGEN_MPL2_ONLY -std=c++11  -I. -Ibazel-out/local_linux-py3-opt/genfiles -Iexternal/bazel_tools -Ibazel-out/local_linux-py3-opt/genfiles/external/bazel_tools -Iexternal/eigen_archive -Ibazel-out/local_linux-py3-opt/genfiles/external/eigen_archive  --compiler-bindir=/usr/bin/gcc -I . -fPIC  -x cu  -O2 -c  -o bazel-out/local_linux-py3-opt/bin/tensorflow/core/kernels/_objs/gather_functor_gpu/tensorflow/core/kernels/gather_functor_gpu.cu.pic.o tensorflow/core/kernels/gather_functor_gpu.cu.cc
dirname: invalid option -- 'O'
Try 'dirname --help' for more information.

Je suis sur Ubuntu 16.04, le nom du répertoire provient de coreutils-8.25-2ubuntu2

@hughperkins Je pense que modifier le fichier dockerfile TF sur votre référentiel avec ces instructions pourrait faciliter la configuration pour les autres.

Oui, quand il y aura quelque chose de plus fonctionnel. Fondamentalement, il s'agit d'une copie et d'un passé de ces instructions que vous avez publiées.

J'expérimente la construction de ceci sur MacOS 10.10.5 sur un MacBook fin 2015 avec ATI 6770M (OpenCL 1.2).

J'ai installé Xcode 8, Anaconda (Python 3.5) et les équivalents MacPorts de clang+llvm :

au lieu des lignes apt-get, faites :

installation du port sudo clang-3.8 llvm-3.8

Au lieu d'utiliser /proc/cpuinfo, faites :

NUM_PROCS=$(system_profiler SPHardwareDataType | grep "Nombre total de cœurs" | cut -d ":" -f 2)

Modifiez ensuite Makefile pour utiliser macports et exécutez make

perl -pi.bak -e 's|(CLANG)=.+|$1=/opt/local/libexec/llvm-3.8/bin/clag++|' Makefile
perl -pi -e 's|(LLVM_CONFIG)=.+|$1=/opt/local/bin/llvm-config-mp-3.8|' Makefile
perl -pi -e 's|(LLVM_INCLUDE)=.+|$1=/opt/local/libexec/llvm-3.8/include|' Makefile

mise à jour vers les répertoires Macos OpenCL ; futur : utilisez /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' conditionnel

grep -Rl 'include "CL/' * | xargs perl -pi.bak -e 's|include "CL/|include "OpenCL/|g'
faire -j ${NUM_PROCS}

C'est tout ce que j'obtiens:

$ make -j ${NUM_PROCS}
mkdir -p construction
mkdir -p construction
mkdir -p construction
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/hostside_opencl_funcs.o -std=c++11 -fPIC -g -O2 -I pwd /include -I pwd /src/EasyCL src/hostside_opencl_funcs.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/mutations.o -g -I/opt/local/libexec/llvm-3.8/include src/mutations.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/struct_clone.o -g -I/opt/local/libexec/llvm-3.8/include src/struct_clone.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/readIR.o -g -I/opt/local/libexec/llvm-3.8/include src/readIR.cpp
Dans le fichier inclus à partir de src/hostside_opencl_funcs.cpp:17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16 : avertissement : attribut 'host' ignoré [-Wignored-attributes]
attribut ((hôte)) inline unsigned long long atomicExch(volatile unsigned long long _p, unsigned long long val) {
^
src/hostside_opencl_funcs.cpp:194:33 : erreur : l'appel à la fonction membre 'in' est ambigu
launchConfiguration.kernel->in(offset);
~ ~ ~ ~ ~ ~~~^~
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15 : remarque : fonction candidate
CLKernel dans (valeur flottante);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15 : remarque : fonction candidateCLKernel *in(int32_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15 : remarque : fonction candidateCLKernel *in(int64_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15 : remarque : fonction candidateCLKernel *in(uint64_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15 : remarque : fonction candidateCLKernel *in(uint32_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15 : remarque : fonction candidate non viable : aucune conversion connue de 'size_t' (alias 'unsigned long ') à 'easycl::CLArray *'pour le 1er argumentCLKernel *in(CLArray *clarray1d) { return input(clarray1d);



}^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36 : remarque : modèle de fonction candidat non viable : nécessite 2 arguments, mais 1 a été fournimodèleCLKernel *in(int N, const T *data);^1 avertissement et 1 erreur générés.make : *_* [build/hostside_opencl_funcs.o] Erreur 1Fabriquer: * * En attente de travaux inachevés....
src/struct_clone. cpp:245 :12 : avertissement : 11 valeurs d'énumération non gérées dans le commutateur : 'HalfTyID', 'X86_FP80TyID', 'FP128TyID'... [-Wswitch]
switch(typeID) {
^
1 avertissement généré.

launchConfiguration.kernel->in((int64_t)offset);

Ce patch a fonctionné. Merci.

Après avoir appliqué cela, la poursuite de la construction a entraîné des erreurs d'espace de noms size_t :

$ make -j ${NUM_PROCS}
mkdir -p construction
mkdir -p construction
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/hostside_opencl_funcs.o -std=c++11 -fPIC -g -O2 -I pwd /include -I pwd /src/EasyCL src/hostside_opencl_funcs.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -o build/ir-to-opencl -g -I/opt/local/libexec/llvm-3.8/include src/ir-to-opencl.cpp build/struct_clone .o build/readIR.o src/ir-to-opencl-common.cpp build/mutations.o /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_events.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_events.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -o build/patch-hostside -g -I/opt/local/libexec/llvm-3.8/include src/patch-hostside.cpp build/readIR.o build/ mutations.o build/struct_clone.o src/ir-to-opencl-common.cpp /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
Dans le fichier inclus à partir de src/hostside_opencl_funcs. cpp:17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16 : avertissement : attribut 'host' ignoré [-Wignored-attributes]
attribut ((hôte)) inline unsigned long long atomicExch(volatile unsigned long long _p, unsigned long long val) {
^
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_blas.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_blas.cpp
1 avertissement généré.
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_error.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_error.cpp
Dans le fichier inclus à partir de src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:8:9 : erreur : aucun type nommé 'size_t' dans l'espace de noms 'std' ; vouliez-vous dire simplement 'taille_t' ?
typedef std ::size_t cublasStatus_t;
^ ~ ~
taille_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré ici
typedef SIZE_TYPE size_t ;
^
Dans le fichier inclus à partir de src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:17:5 : erreur : aucun type nommé 'size_t' dans l'espace de noms 'std' ; vouliez-vous dire simplement 'taille_t' ?
std ::size_t cublasCreate(cublasHandle_t phandle);^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^Dans le fichier inclus à partir de src/cocl_blas.
vouliez-vous dire simplement 'taille_t' ?std :: size_t cublasDestroy(cublasHandle_t handle);^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^Dans le fichier inclus à partir de src/cocl_blas.
vouliez-vous dire simplement 'taille_t' ?std ::size_t cublasSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^Dans le fichier inclus à partir de src/cocl_blas.
vouliez-vous dire simplement 'taille_t' ?std ::size_t cublasSetPointerMode(cublasHandle_t handle, cublasPointerMode_t mode);^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^Dans le fichier inclus à partir de src/cocl_blas.
vouliez-vous dire simplement 'taille_t' ?std ::size_t cublasGetPointerMode(cublasHandle_t handle, cublasPointerMode_t *mode);^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^Dans le fichier inclus à partir de src/cocl_blas.
vouliez-vous dire simplement 'taille_t' ?std :: size_t cublasSetStream(cublasHandle_t handle, cudaStream_t streamId);^ ~ ~taille_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23 : note : 'size_t' déclaré icitypedef SIZE_TYPE size_t ;^/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_memory.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_memory.cpp/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_device.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_device.cpp7 erreurs générées.make: *_* [build/cocl_blas.o] Erreur 1make: * * En attente de travaux inachevés....

Pouvons-nous pousser une longue connexion sur l'essentiel pour que le fil soit toujours lisible?

question : comment résolvez-vous le problème des espaces d'adressage ?

@hughperkins Les spécifications SYCL décrites dans la section 5.8 ("Déduction d'espace d'adresse")
comment une implémentation doit gérer différents types de mémoire. Ce
est similaire au travail précédent effectué pour PlayStation 3 et décrit dans
cet article : Offload – Automatisation de la migration du code vers l'hétérogèneSystèmes multicœurs ou C++ sur accélérateurs : prise en charge des modèles de programmation SYCL et HSA à source unique à l'aide de Clang

J'espère que ça t'as aidé.

@hughperkins Puis-je compiler votre code repo tensorflow-opencl pour appliquer ma carte ARM? Ma carte ARM a un GPU Imagination qui prend en charge opencl 1.2 .

Je suis tombé sur ce fil en cherchant le support tf/intel.

J'ai un MacBook Pro Intel, comment puis-je aider ? Je ne connais pas c/c++, mais je peux suivre les instructions de construction/compilation/test et renvoyer (pastebin) les résultats...

derek$ system_profiler SPDisplaysDataType
Graphiques/affichages :

Intel Iris:

  Chipset Model: Intel Iris
  Type: GPU
  Bus: Built-In
  VRAM (Dynamic, Max): 1536 MB
  Vendor: Intel (0x8086)
  Device ID: 0x0a2e
  Revision ID: 0x0009
  Metal: Supported
  Displays:
    Color LCD:
      Display Type: Retina LCD
      Resolution: 2560 x 1600 Retina
      Retina: Yes
      Pixel Depth: 32-Bit Color (ARGB8888)
      Main Display: Yes
      Mirror: Off
      Online: Yes
      Automatically Adjust Brightness: Yes
      Built-In: Yes
    PL2202W:
      Resolution: 1680 x 1050 @ 60 Hz
      Pixel Depth: 32-Bit Color (ARGB8888)
      Display Serial Number: 05884C7A57014
      Mirror: Off
      Online: Yes
      Rotation: Supported
      Adapter Type: Apple Mini DisplayPort To VGA Adapter
      Automatically Adjust Brightness: No
      Adapter Firmware Version: 1.03

@hughperkins Merci pour vos instructions !
J'essaie de compiler votre cuda-on-cl sur la plate-forme arm. En suivant le guide de votre cuda-on-cl :
Mes informations sur la carte ARM :
arm64, gcc 4.9, clang et llvm 3.5, openCL 1.2

* Dois-je utiliser la version clang++-3.8 ? *
git clone --recursive https://github.com/hughperkins/cuda-on-cl
Fabriquer
Erreur:
clang++-3.8 : Commande introuvable
J'édite le Makefile comme ceci : CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
puis refaites :
Erreur:
src/mutations.h:3:10 : erreur fatale : fichier 'llvm/IR/Module.h' introuvable

essayez d'exécuter make run-test-cocl-cuda_sample :
make: cocl : commande introuvable

@hughperkins laissez-moi essayer.

Erreur lors du test de keras avec tensorflow

keras$ KERAS_BACKEND=tensorflow pytest3

Erreurs de sortie :

Invalid kernel name, code -46, kernel _ZN5Eigen8internal15EigenMetaKernelINS_15TensorEvaluatorIKNS_14TensorAssignOpINS_9TensorMapINS_6TensorIfLi1ELi1EiEELi16ENS_11MakePointerEEEKNS_18TensorCwiseUnaryOpINS0_12scalar_rightIffNS0_17scalar_product_opIffEEEEKNS4_INS5_IKfLi1ELi1EiEELi16ES7_EEEEEENS_9GpuDeviceEEEiEEvT_T0_
__internal__ build log: 
"/tmp/OCL11307T1.cl", line 3: error: variable with automatic storage duration
          cannot be stored in the named address space
      local float mem[1024];

Code:

inline float __shfl_down_3(float v0, int v1, int v2) {
    local float mem[1024];
    int tid = get_local_id(0);
    int warpid = tid % 32;
    int warpstart = tid - warpid;
    mem[tid] = v0;
    //barrier(CLK_LOCAL_MEM_FENCE);
    int warpsrc = warpid + v1;
    warpsrc = warpsrc >= 32 ? warpid : warpsrc;
    return mem[warpstart + warpsrc];
}

salut tout le monde, je m'appelle ricardo, je suis un programmeur C++ avec de nombreuses années d'expérience en C++, et peu sur Cuda, je serai heureux de contribuer à cet effort. Comment puis-je contribuer à ce travail?

Ok, j'ai un Odroid Xu3 avec un Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 et OpenCL 1.1 Profil complet)
fonctionnant sous OS : LUbuntu 1404 64 bits
Je ferai une installation complète et posterai le résultat sur cette plateforme.
À propos des bogues, y a-t-il une liste de bogues (quelque chose comme Bugzilla ?) ou une feuille de calcul avec une liste de bogues ?
Acclamations!

Qu'en est-il de l'utilisation de HIP ?
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_faq.md#how-does-hip-compare-with-opencl
https://github.com/RadeonOpenCompute/hcc
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45
"Votre souhait est exaucé, Eigen est porté sur le GPU AMD via HIP. La deuxième partie de votre demande est de savoir si nous pouvons apporter un outil standardisé prenant en charge FLOAT16 qui est livré avec tous nos GPU GFX8, souhait exaucé."
Notre branche de développement du compilateur AMDGPU prend désormais en charge les instructions natives Float16 et Int16, au lieu d'émuler FP16/Int16 avec des instructions de conversion ascendante et descendante pour convertir de FP16/Int16 en Float et inversement.

Il s'agit de tests f16 sur du matériel Fiji exécutant avec succès une multiplication matricielle avec des demi-types avec conversion et avec des instructions natives."

De plus, pas lié, mais vous devez utiliser syCL/openCL 2.0 au lieu de 1.2, car nvidia est déjà pris en charge via CUDA. Et openCL 2.0 est pris en charge sur les pilotes AMD et Intel Windows. AMD a également déclaré qu'il ouvrirait bientôt un pilote openCL 2.0 pour Linux (qui pourrait être utilisé par Intel, opensource magic) (et Intel a déjà une implémentation Linux openCL 2.0 qui a juste besoin de maturation.) si vous demandez à Intel et AMD, peut-être ils pourraient accélérer les travaux, car le tensorflow est important pour leurs intérêts économiques. Et ils ont déjà dit dans cette section de commentaires qu'ils voulaient aider. De plus, tous les principaux fabricants d'ARM prennent en charge openCL 2.0. Cela pourrait ouvrir pas mal d'opportunités pour Android (ce qui est dans l'intérêt économique de Google), raspberry like, smart TV, etc.

Et à moyen terme, nous pourrions éventuellement développer une couche de secours opencl 1.2 pour le matériel non pris en charge.
Et l'implémentation devrait également utiliser openVX (qui est maintenant pris en charge par tous les principaux fabricants de matériel, et AMD a une implémentation open source) et avec https://www.khronos.org/news/press/khronos-launches-dual-neural-network -initiatives-standard
Et le tout avec Spir-V (qui peut être utilisé simultanément par Vulkan et openGL).
On pourrait dire que je fais une copie de ce qui a déjà été dit, mais la synthèse est importante.
Et enfin, tensorflow pourrait-il utiliser HSA ?

http://www.hsafoundation.com
HSA serait génial sur Android.

Je ne sais pas si HIP serait utile ou non. Il n'est pris en charge que sur certaines cartes AMD, de sorte que nous avons de toute façon besoin d'une implémentation OpenCL si nous voulons prendre en charge tous les appareils. Cela en vaut peut-être la peine si la mise en œuvre du HIP est nettement plus rapide. C'est peut-être le cas, mais je n'ai pas encore vu beaucoup de benchmarks (HIP vs OpenCL). Une autre raison pourrait être MLOpen (qui est écrit en HC) en remplacement de cudnn mais encore une fois, je n'ai aucune idée de sa rapidité ou des fonctionnalités qu'il prend en charge.

TensorFlow n'utiliserait pas HSA directement car il est assez bas niveau. Mais HC (et HIP) est implémenté par-dessus et vous pouvez également implémenter OpenCL par-dessus if (pocl le fait).

L'algorithme de relooper serait-il utile ici ? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins Ravi de voir que vous avez des progrès avec votre compilateur, mais je pense que cela devient hors sujet pour TensorFlow. Vous devriez plutôt démarrer de nombreux fils de discussion plus petits sur la page GitHub de votre projet de compilateur. Ce serait plus concentré et productif, je suppose.

Voir https://github.com/chihchun/opencl-docker

Il y a aussi https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.cpp

Voici l'article associé : https://github.com/kripken/emscripten/blob/master/docs/paper.pdf?raw=true

La prise en charge initiale d'OpenCL/SyCL a été fusionnée dans le maître avec https://github.com/tensorflow/tensorflow/pull/5267

Toutes nos félicitations!

@keryell Btw, qu'est-il arrivé au référentiel triSYCL ? Il semble avoir disparu et je ne peux trouver qu'une référence au Gitlab de Khronos qui n'est pas accessible au public.

EDIT : J'ai trouvé votre clone privé, seul celui d'amd a disparu.

@bhack , est-ce que opencl-docker prend en charge la plate-forme mac ?

@alephman Je n'ai pas de plate-forme OSX mais je pense qu'adapter un peu la commande de lancement pourrait fonctionner.

@bhack @alephman : voir mon commentaire sur mac ci-dessus, si vous me dirigez vers les instructions de construction, je vais essayer

@olesalscheider : oui, triSYCL est passé d'AMD à Xilinx https://github.com/Xilinx/triSYCL mais vous avez raison, la version sur mon espace de travail GitHub fonctionne aussi sur https://github.com/keryell/triSYCL

Nous n'avons pas encore essayé triSYCL sur TensorFlow. Il y a déjà un gros travail de config build à faire juste pour essayer...

@keryell Quel est le statut triSYCL ?

Le support d'Intel beignet opencl 2.0 est presque terminé !
http://phoronix.com/scan.php?page=news_item&px=Beignet-Birthday-CL2

@bhack triSYCL est principalement développé chez Xilinx maintenant. Toujours en ajoutant de plus en plus de fonctionnalités. Le compilateur de contour basé sur Clang/LLVM est toujours en développement pour avoir une expérience complète à source unique sur un appareil. Mais le mode de compatibilité OpenCL, déjà implémenté, a aussi une certaine valeur, en simplifiant les communications entre l'hôte et les noyaux avec le runtime SYCL effectuant les transferts paresseux en fonction des dépendances exprimées par les accesseurs.

Mon mac est compatible OpenCL, alors comment puis-je exécuter mon tensorflow avec openCL ? Je viens de découvrir qu'opencl avait été pris en charge dans tensorflow, lorsque je configure les nouveaux codes.

@hughperkins il n'y a pas d'instruction clinfo dans mon mac, que puis-je faire pour cela ? Mais je peux compiler le code de test ici pour opencl avec clang et obtenir les informations suivantes :
clang -framework OpenCL dumpcl.c -o dumpcl && ./dumpcl Device Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz supports OpenCL 1.2 Device Intel(R) Iris(TM) Graphics 6100 supports OpenCL 1.2

Merci @hughperkins , mais je pense avoir essayé le computecpp hier, et il semble que le système macbook ne soit toujours pas pris en charge avec le computecpp. Donc, peut-être que continuer à attendre de nouvelles mises à jour est la seule chose que je puisse faire (TT). BTW, mon Iris 6100 est de huitième génération, ce qui est bon pour OpenCL 1.2.

@hughperkins oui SYCL 1.2 est a priori pour OpenCL 1.2 et SYCL 2.2 est a priori pour OpenCL 2.2.
J'ai dit "a priori" car, si vous n'utilisez rien nécessitant le mode de compatibilité OpenCL de SYCL, SYCL ne nécessite pas vraiment OpenCL du tout. En fait, SYCL est un modèle très générique pour l'informatique hétérogène et peut s'exécuter sur n'importe quoi. Mais bien sûr, une implémentation réelle peut également nécessiter OpenCL.

Bonjour,

J'apprends/travaille avec TensorFlow et Keras pour le moment et je serais intéressé pour que le support OpenCL fonctionne sous macOS... Y a-t-il des nouvelles sur le travail effectué autour de macOS ?

J'ai réussi à compiler TensorFlow mais si j'essaie de configurer pour OpenCL, il me demande l'emplacement de computeCpp 1.2, et il me semble qu'il n'y a pas de ComputeCpp pour macOS.

Salut. En aucun cas un expert en ML / Tensorflow / ou même OpenCL, mais je suis un développeur graphique Mac expérimenté qui veut désespérément des performances plus rapides de Tensorflow sur des systèmes avec GPU intégré et AMD utilisant des bibliothèques intégrées et des dépendances simples :)

Comment puis-je aider?

En regardant le dernier échec de compilation sur OS X dans le travis log @hughperkins - il semble que l'exécution de 'xcode-select --install' pourrait résoudre? Il devrait reconnecter le répertoire /usr/include. J'ai moi-même eu ce problème lors de la mise à jour de la version bêta de Xcode et j'ai eu des problèmes pour compiler du code C++.

Il semble que le compilateur XLA (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) fournira la génération de code LLVM à partir de graphiques de flux de données. Cela signifie un accès très facile à spir-v et donc à l'API de calcul de Vulkan. Avec la génération de code triée, je ne peux pas imaginer que Google ne fournisse pas la compatibilité Vulkan étant donné le nombre élevé de GPU intégrés inutilisés fonctionnant sur Android.

@hughperkins

Rapidement : en ce moment, j'exécute Inception v3 sur une base de code C++/Object-C personnalisée et je transmets des images vidéo décodées au réseau. Je n'en sais pas assez sur TF pour connaître les besoins de bas niveau, mais de haut niveau : charger des modèles, exécuter une session, s'attendre à ce que les choses fonctionnent. Je pense que cela signifie une compatibilité à 100% pour être vraiment honnête. Je sais que cela n'aide pas à établir des priorités. Fondamentalement, la reconnaissance d'images C++ utilisant TF / InceptionV3 était mon point de départ.

cuda-on-cl s'exécutant sur Mac : j'ai consulté le référentiel et je peux aider à déboguer et exécuter des versions sur mes systèmes et vérifier les résultats sur une variété de matériels : j'ai accès aux Mac Pro AMD avec Dual D700, aux ordinateurs portables Nvidia Mac et Systèmes de bureau.

Merci pour vos commentaires détaillés. Je vais surveiller le repo, essayer de suivre et essayer d'aider du mieux que je peux.

Hugh, vous voudrez peut-être consulter http://chrec.cs.vt.edu/cu2cl/ pour savoir comment certaines fonctions sont mappées.

Dans mon entreprise StreamComputing, nous avons divers GPU pour les tests de construction et l'analyse comparative, que nous utilisons pour nos projets clients. Je pourrais connecter votre Github à notre Jenkins pour faire une course hebdomadaire.

Merci pour la réponse, je reviendrai sur le sujet au boulot cette semaine, avec des scripts précis.

Mes cas d'utilisation concernent l'analyse de correspondance texte/syntaxe, en utilisant Gensim et Keras/tensorflow dans mes expériences.

Je suis disposé à vous aider pour les tests

J'ai un PC Windows avec une carte AMD
Un MBP avec une carte AMD
Un MB avec un GPU intégré Intel

Hey @hughperkins - Je passe le test ci-dessus, ce soir, sur un AMD R9 390 8 Go. Jusqu'à présent, j'ai déjà obtenu un résultat différent; logistic_regression.py s'entraîne et ne renvoie pas nan . Si bon! Il segfaults à la fin, donc je vais rechercher si le script ou le code cl est en faute.

Où dois-je pousser mes résultats, là où ils peuvent vous être le plus utiles ?
Peut-être pourrions-nous obtenir un "script de test" standard qui génère un ensemble standard de résultats que les bénévoles peuvent vous transmettre (ou configurer sur des CI locaux ou autre) ?

py.test est une solution aussi bonne que n'importe quelle autre ; c'est juste à pip et cela fait partie du processus d'installation tensorflow toute façon.

J'ai découvert quelques choses intéressantes depuis le début de mes tests, et elles ne peuvent cependant pas être déboguées en utilisant uniquement la sortie Python :

• Différents appels au même script peuvent planter tôt, ou peuvent "se bloquer" (pas de sortie, pas de progression, pas de réponse à Ctrl-C , le processus doit être pkill -9 'd), ou peuvent planter tard soit lors de la partie de validation, soit une fois le script terminé avec succès. Les plantages (erreurs de segmentation) peuvent faire tomber Xorg.
• Les résultats varient apparemment sans raison : je peux appeler un script et l'avoir en erreur de segmentation, puis l'appeler à nouveau et cela fonctionnera.
• Des blocages peuvent se produire dans des portions de code qui fonctionnaient littéralement il y a quelques instants, j'ai eu un blocage dans ou après un lot de formation, après que plusieurs centaines de lots se soient déroulés avec succès.

Donc, il se peut qu'il y ait des choses non résolues du côté du GPU, et qu'une bonne erreur de segmentation soit nécessaire pour l'effacer ? Je ne connais pas encore grand-chose au modèle GPU ou à OpenCL, donc je ne peux pas beaucoup contribuer ici. Mais, il se peut que la sortie de débogage GPU soit nécessaire pour explorer correctement ce qui se passe.

De plus, je pensais que vous étiez avec AMD depuis votre github, mais il semble que vous soyez un "agent voyou" faisant tout ce truc CUDA-on-CL à votre rythme. Merci sincèrement pour ce fer de lance ! Existe-t-il un moyen pour moi et d'autres de contribuer à vos efforts, peut-être en vous finançant un GPU ? Ou vous pourriez créer un Patreon, je serais heureux de m'inscrire pour une contribution mensuelle au projet ?

Concernant les GPU AMD, nous sommes partenaire d'AMD. Voir mon message d'il y a 8 jours, que vous avez peut-être manqué :

Dans mon entreprise StreamComputing, nous avons divers GPU pour les tests de construction et l'analyse comparative, que nous utilisons pour nos projets clients. Je pourrais connecter votre Github à notre Jenkins pour faire une course hebdomadaire.

Je me demande si vous pourriez avoir la possibilité de mettre en place un serveur CI, qui s'exécute sur chaque commit ?

Aucun problème. J'ai probablement besoin d'un accès en écriture au projet, donc Jenkins peut écrire le fichier journal dans un répertoire build-log. Je viens de vous spammer, afin que nous puissions discuter.

Salut tout le monde,

Comme vous le voyez probablement déjà, un tas de choses SYCL ont été poussées vers TensorFlow. Nous ne sommes pas encore au complet et il reste encore beaucoup à faire. Mais on progresse pour y arriver.

Si vous êtes intéressé à contribuer ou simplement curieux de l'état actuel, consultez la répartition ci-dessous.

Infrastructure
Google a gentiment fait don de deux machines configurées pour tester périodiquement le fork de TensorFlow de @benoitsteiner (https://github.com/benoitsteiner/tensorflow-opencl)

Les deux ont des GPU AMD :

CL_DEVICE_NAME : Hawaï
CL_DRIVER_VERSION : 1912.5 (VM)

et

CL_DEVICE_NAME : Fidji
CL_DRIVER_VERSION : 1912.5 (VM)

Chez Codeplay, nous cherchons également à dédier des machines l'année prochaine. Améliorer la couverture de la diversité des appareils OpenCL.

Nous recherchons des contributeurs sur ce front si quelqu'un est intéressé à fournir un serveur de test pour les plates-formes pertinentes que nous prenons en charge.
Actuellement, les exigences sont :
-Ubuntu 14.04
- Pilotes OpenCL prenant en charge SPIR (Intel CPU/GPU ou AMD GPU)

@VincentSC peut-être pourriez-vous aider avec ça ?

Essais
Sur la machine Fiji ( https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull ) nous sommes confrontés à 164 échecs.

Sur la machine d'Hawaï ( https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull ), nous sommes tombés à 56 échecs.

Nous cherchons à corriger les tests de gradient défaillants et à enquêter sur les origines des échecs supplémentaires sur la machine Fiji.

propre
Au cours des derniers mois, nous avons activement implémenté les fonctionnalités nécessaires à TensorFlow, notamment : le remodelage, le découpage, la réduction de base, etc. Actuellement, nous implémentons la contraction. Une ventilation détaillée peut être trouvée dans l'onglet Eigen Tensor de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

TensorFlow
De nombreuses opérations de coefficient ont été implémentées, notamment Abs, Floor, IsFinite, Log, Pow, Mul, etc., ainsi que des manipulations de tenseur telles que Reshape, Shape, Identity, Fill, etc.
Une ventilation détaillée peut être trouvée dans l'onglet TensorFlow Kernels de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219

Organisation
Le tableur ci-dessus comporte plusieurs onglets qui catégorisent les efforts du projet comme : Plan global, Eigen Tensor, TensorFlow Kernels, Models.

Si vous souhaitez vous impliquer, veuillez mettre votre nom à côté de l'élément sur lequel vous travaillez ou ajouter quelque chose d'important qui manque.
Merci,
Luc

Cette feuille de route est-elle active ?

@lukeiwanski Oui, pas de problème. Contactez-nous via [email protected]

Après avoir lu tout cela, je suppose qu'il n'y a pas encore de solution solide pour utiliser OpenCL sur macOS/OS X ? J'ai essayé de compiler Tensorflow C++ avec le support OpenCL (ce qui, je suppose, nécessite ComputeCpp pour SYCL 1.2, comme quelqu'un l'a souligné).

J'ai regardé autour de moi et je n'arrivais pas à trouver où télécharger, compiler ou créer la bibliothèque SYCL. Est-ce ici https://www.codeplay.com/ ? Je ne sais vraiment pas comment procéder, merci...

@dylib Pour autant que je sache, il n'y a toujours pas de ComputeCpp pour macOS. Cela signifie donc qu'OpenCL pour macOS n'est pas prêt.

Je ne peux toujours pas le faire fonctionner sur Ubuntu 16.04 avec la carte AMD et le pilote de catalyseur https://github.com/tensorflow/tensorflow/issues/6497. Existe-t-il un mode d'emploi ?

J'ai dû regarder la sortie /usr/local/computecpp/bin/computecpp_info avant d'essayer d'utiliser TF compilé avec le support OpenCL. Dans mon cas, il montre

  Device is supported                     : NO - Unsupported vendor
  CL_DEVICE_NAME                          : Pitcairn
  CL_DEVICE_VENDOR                        : Advanced Micro Devices, Inc.

il y a maintenant 2 choix pour exécuter TF sur GPU :
bon fonctionnement sur un nombre limité (par fournisseur) d'appareils, mais CUDA propriétaire
mauvais fonctionnement sur un nombre limité (par les développeurs de computecpp) d'appareils et également sur un ordinateur propriétaire
Toujours pas de support OpenCL.

@inferrna Il s'agit d'une section spécifique à OpenCL dans la documentation générale de TensorFlow. Celle-ci sera bientôt publiée sur le site tensorflow.org.

@benoitsteiner Quel est l'état actuel du support des convolutions opencl ? Envisagez-vous d'exploiter directement les noyaux existants ? Qu'en est-il des multiplications matricielles ?

Une heure d'arrivée prévue ?

Que diriez-vous d'utiliser HIP pour porter le code CUDA sur une plate-forme indépendante ? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Il semble qu'AMD travaille là-dessus : https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45#issuecomment -269827686

Les backends XLA LLVM IR peuvent-ils être convertis en SPIR-V avec https://github.com/KhronosGroup/SPIRV-LLVM ?

Que dis-tu de ça? Je pense que ce package peut fonctionner sur le GPU Radeon.

https://github.com/RadeonOpenCompute/ROCm

@bhack De https://github.com/tensorflow/tensorflow/issues/6449#issuecomment -269245727

@lukeiwanski XLA aura-t-il également un impact sur vos efforts ?

Les solutions XLA et SYCL sont complémentaires pour différentes situations : SYCL est conçu pour offrir une programmabilité et une personnalisation complètes. XLA sert à optimiser des modèles bien définis dans les graphiques.

Ma compréhension de XLA est qu'il optimise certains graphiques TensorFlow existants lors de l'exécution à l'aide du compilateur LLVM. Il nécessite des passes d'optimisation à implémenter dans le compilateur pour chaque algorithme utilisé dans le graphe.
L'approche SYCL est la seule approche qui fournira un niveau de programmation CUDA - ce dont les développeurs ont besoin.

Avec SYCL, nous visons à fournir une assistance pour toutes les opérations TensorFlow et à faciliter le développement de nouvelles opérations.

Cela signifie que SYCL vous permet d'écrire très facilement de nouvelles opérations hautes performances, tandis que XLA peut optimiser des graphes entiers s'il prend en charge toutes les opérations du graphe.

Les backends XLA LLVM IR peuvent-ils être convertis en SPIR-V avec https://github.com/KhronosGroup/SPIRV-LLVM ?

Je ne vois aucune raison pour laquelle cela ne serait pas possible.

@lukeiwanski Merci, je cherchais spécifiquement à https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend

@k-hashimoto : nous discutons ici du portage de TensorFlow vers OpenCL, une norme du groupe Khronos, et en fait plus d'OpenCL SYCL, la norme de source unique C++ post-moderne du groupe Khronos.
ROCm ressemble à une autre solution non standard de certains fournisseurs.
Si vous êtes intéressé par les solutions propriétaires, il existe déjà une version CUDA de TensorFlow qui semble bien fonctionner. :-)

D'accord : maintenez la conversation / les efforts sur OpenCL et laissez les fournisseurs implémenter ce qu'ils veulent au-dessus de cette norme ouverte.

Le 17 janvier 2017 10:01:32 GMT+00:00, Ronan Keryell [email protected] a écrit :

@k-hashimoto : nous discutons ici du portage de TensorFlow vers
OpenCL, un standard du groupe Khronos, et en fait plus OpenCL SYCL,
la norme de source unique C++ post-moderne du groupe Khronos.
ROCm ressemble à une autre solution non standard de certains fournisseurs.
Si vous êtes intéressé par des solutions propriétaires, il existe déjà un CUDA
version de TensorFlow qui semble bien fonctionner. :-)

--
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -273076892

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

:+1:

👍

:+1:

Ce message a été créé automatiquement par le logiciel de distribution de courrier.

Un message que vous avez envoyé n'a pas pu être remis à un ou plusieurs de ses
destinataires. Il s'agit d'une erreur temporaire. La ou les adresse(s) suivante(s) différée(s) :

[email protected]
Le domaine biomassiv.es a dépassé le nombre maximal d'e-mails par heure (111/100 (111%)) autorisé. Le message sera réessayé plus tard

------- Ceci est une copie du message, y compris tous les en-têtes. ------
Reçu : de github-smtp2-ext6.iad.github.net ([192.30.252.197]:48606 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
par chi-server32.websitehostserver.net avec esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.87)
(enveloppe-de [email protected] )
identifiant 1cWmiQ-0032as-W9
pour [email protected] ; Jeu. 26 janvier 2017 10:16:03 -0600
Date : Mer, 25 janvier 2017 04:09:21 -0800
Signature DKIM : v=1 ; a=rsa-sha256 ; c=détendu/détendu ; d=github.com ;
s=pf2014 ; t=1485346161 ;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg= ;
h= From:Reply-To :To:Cc:In-Reply-To: References:Subject :List-ID:
List- Archive:List-Post :List-Un subscribe:From;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
De : Miguel Ángel [email protected]
Répondre à : tensorflow/tensorflow [email protected]
À : tensorflow/tensorflow [email protected]
Cc : Abonné [email protected]
ID du message:
En réponse à:
Les références:
Objet : Re : [tensorflow/tensorflow] Prise en charge d'OpenCL (#22)
Version Mime : 1.0
Type de contenu : multipart/alternatif ;
limite="--==_mimepart_5888957158d12_78b73ff902fe113c148134" ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits
Priorité : liste
Expéditeur X-GitHub : migpradel
X-GitHub-Recipient : biomasses
X-GitHub-Reason : abonné
ID de liste : tensorflow/tensorflow
Liste-Archive : https://github.com/tensorflow/tensorflow
Liste-Post : [email protected]
Liste-désinscription :,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Response-Suppress : Tout
X-GitHub-Recipient-Address : [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Type de contenu : texte/plain ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits

--
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Type de contenu : text/html ;
jeu de caractères=UTF-8
Encodage de transfert de contenu : 7 bits

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion .

----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Nouveau ici. Je voulais demander s'il y aura un support OpenCL dans tensorflow à l'avenir, cela signifierait-il qu'il y aura un support pour exécuter tensorflow sur FPGA ?
Merci

@atinzad : oui si la version et le code source OpenCL ou SYCL sont pris en charge par l'environnement FPGA. Mais comme TensorFlow est peut-être le framework le plus porté avec divers moyens, il se peut qu'une partie fonctionne déjà sur un FPGA quelque part...

OMG. https://www.youtube.com/watch?v=LqLyrl-agOw

Quelles sont les différences entre l'effort de développement sycl et XLA ciblant SPIR-V autre que PTX dans la vision à moyen terme ?

Quelle bonne question. Probablement - le nombre de personnes impliquées ? Ce serait très intéressant à savoir !

Le 16 février 2017, à 13h35, bhack [email protected] a écrit :

Quelle est la différence entre l'effort de développement sycl et XLA ciblant SPIR-V autre que PTX dans la vision à moyen terme ?

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

Quelle est la différence entre l'effort de développement sycl et XLA ciblant SPIR-V autre que PTX dans la vision à moyen terme ?

@bhack Ce serait une excellente discussion à avoir lors du TensorFlow Dev Summit d'hier

Demandez-vous quelles sont les ressources disponibles / le type de programmeurs nécessaires pour contribuer ?

Si tel est le cas, dans l'approche OpenCL/SYCL, les programmeurs C++ / les programmeurs OpenCL C peuvent rapidement être mis à niveau et pouvoir contribuer. L'approche XLA nécessite une expérience de compilateur / llvm.

XLA est le projet interne de Google par extension, ils ont plus de ressources qui lui sont associées. Mais, d'un autre côté, leur tâche est également beaucoup plus importante. Écrire un compilateur n'est pas une tâche facile.

Sinon, si vous demandez le modèle :

Comme je l'ai mentionné plus tôt dans https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870, nous considérons les deux efforts comme des approches complémentaires et les deux ayant des cas d'utilisation différents. Je suis toujours avec cette déclaration.

Par exemple, @tatatodd dans sa présentation a mentionné que certains des Ops n'auront jamais XLA comme cible. Je crois qu'il est possible de combler cette lacune.

D'autres choses à considérer sont de nouvelles plates-formes. J'utiliserai l'environnement mobile et embarqué pour cet argument, car les nouvelles puces ont tendance à apparaître plus fréquemment que les GPU (le principe est le même).

Si le semi-conducteur prend en charge SYCL / OpenCL, vous obtenez un support TF prêt à l'emploi (certains ajustements de performances peuvent être nécessaires).

Si l'architecture est exotique et qu'il n'y a pas de backend LLVM pour cela, XLA doit l'ajouter (cela n'arrivera peut-être pas trop souvent mais quand même). Ce qui arrive le plus souvent, c'est que l'architecture change un peu, puis de nouvelles passes d'optimisation doivent être ajoutées ou une passe existante doit être modifiée pour en tirer profit. Le réglage du code du noyau est plus facile.

Je n'ai pas regardé très profondément XLA mais je suppose que XLA doit appeler l'API CUDA d'une manière ou d'une autre pour exécuter le code du noyau PTX, donc devrait être porté sur OpenCL ou Vulkan pour exécuter les noyaux SPIR-V à la place - que je suppose passerait par StreamExecutor - un autre framework avec lequel se familiariser - probablement un gros effort.

En bref, nous fournissons une plate-forme unifiée / stable dans un écosystème très fragmenté / détourné que les sociétés de semi-conducteurs et les développeurs peuvent cibler. Alors que XLA devrait s'engager à soutenir.

@benoitsteiner ou @drpngx pourraient être en mesure de donner plus de connaissances sur XLA car je travaille avec beaucoup d'hypothèses/conclusions basées sur des conversations.

Oh, j'ai aussi créé un canal mou pour faciliter la communication https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Eidt :
Le lien lâche n'est plus valide. S'il vous plaît ping moi si vous souhaitez rejoindre.

Je pense que c'est correct et que cela dépendra en partie de la direction dans laquelle les producteurs de semi-conducteurs seront orientés.
"Ces backends émettent l'IR LLVM nécessaire pour représenter le calcul XLA HLO de manière efficace, puis invoquent LLVM pour émettre du code natif à partir de cet IR LLVM." Ainsi, LLVM IR pourrait être converti en SPIR-V . Mais le dialecte Opencl SPIRV est différent de Vulkan . Streamexecutor est poussé dans LLVM parallel-lib et dans la description originale de @henline , le plan original semble couvrir opencl.

/ cc @ dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
Nvidia devrait bientôt supporter opencl 2.0 sur Linux et Windows, c'est YUGE !

En termes de performances, il est probable qu'il soit plus lent que CUDA.

Rappelez-vous également que les gars de Noveau travaillent indépendamment sur Opencl avec SPIR-V . Le statut est un peu obsolète mais il y a de nouveaux commits.

Opencl n'est pas intrinsèquement plus lent que Cuda, c'est juste nvidia qui verrouille virtuellement le marché en paralysant son pilote opencl.
Mais le leadership de nvidia touche enfin à sa fin et même leurs pratiques anticoncurrentielles ammorales ne les sauveront pas. Avec l'impressionnant autotranslateur Cuda HIP ( https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
Les prochains apus et dgpus vega et ARM arrivant sur Windows, Nvidia n'a pas d'avenir, c'est pourquoi l'industrie a BESOIN de prendre en charge opencl/syCL/HIP/HSA très bientôt et massivement.

Qu'en est-il de la diapositive 40 de https://autodiff-workshop.github.io/slides/JeffDean.pdf ?

Bonjour, que je prévois que tensorflow prendra en charge le nouveau AMD Radeon Instinct ? (http://instinct.radeon.com/en-us/)

Salut, y a-t-il des progrès dans la prise en charge de TF-OpenCL pour les FPGA ?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 a été supprimé il y a quelques mois et la feuille de route de Streamexecutor n'est pas claire.

@bhack merci pour la réponse rapide
Alors, cela signifie-t-il qu'il n'y a pas de support, ou que le bon fonctionnement n'est pas garanti ?
De plus, d'après ce que j'ai lu sur ce fil, je vois que les tests sont principalement sur les GPU AMD ... est-ce que quelqu'un forme des réseaux sur les GPU Nvidia avec ce port OpenCL?

Streamexecutor a été renommé dans LLVM parallel-libs et est maintenant acxxel

Un membre de Google peut-il expliquer la différence et les feuilles de route entre streamexecutor et https://reviews.llvm.org/rL285111 ?

CC @zheng-xq

@henline et @jlebar sont les experts pour répondre à la différence entre streamexecutor et https://reviews.llvm.org/rL285111 ?

Axcell et StreamExecutor sont des projets distincts. Il n'est actuellement pas prévu de les fusionner. Je laisse aux gens de TensorFlow le soin de dire s'ils prévoient ou non de changer.

Donc aussi StreamExecutor et StreamExecutor llvm n'étaient pas les mêmes projets ?

C'est vrai, ce n'est pas le même projet.

Le jeudi 16 mars 2017 à 11h06, bhack [email protected] a écrit :

Donc aussi StreamExecutor et StreamExecutor llvm n'étaient pas les mêmes projets ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar La prochaine fois une unité créative pour le nommage ;) mais ce n'était probablement pas un manque de motivation créative mais juste un effort en amont d'un outil interne qui divergeait de celui maintenu dans TF..

@bhack , nous avons changé le nom, précisément quand nous avons réalisé que nous l'avions fait
ne pense pas qu'il soit logique de déplacer StreamExecutor dans la vente en gros de LLVM. C'est
maintenant appelé "Acxxel".

Je suis désolé pour la confusion et j'apprécie les commentaires. C'était un
processus d'apprentissage à coup sûr.

Le jeudi 16 mars 2017 à 11h24, bhack [email protected] a écrit :

@jlebar https://github.com/jlebar La prochaine fois, une unité créative pour nommer
;) mais ce n'était probablement pas un manque de motivation créative mais juste un
effort de remontée d'un outil interne qui divergeait de celui maintenu
en TF..

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Oui, j'ai encore un peu de confusion entre StreamExecutor, SyCL dans eigen, XLA (qui n'a en fait qu'un backend CUDA, autre que CPU et opencl dans certaines diapositives)

Cogner

Quelqu'un chez Google a-t-il parlé à Apple ou à AMD pour faciliter cela ? Je suppose que les gens d'AMD sont tellement perdus qu'ils ne savent même pas que le problème est là et qu'ils se demandent toujours pourquoi Nvidia a une part de marché si énorme. Je suppose aussi que l'équipe Apple AI serait plus qu'heureuse d'aider ici... si OpenCL n'était pas un abandonware de leur côté depuis 2013 et, pire encore, leurs patrons ne seraient pas en colère contre Google.

Quelle est la dernière à ce sujet ?

Selon les notes de publication de TF 1.1 , la prise en charge du GPU Mac (Nvidia uniquement) est obsolète. Espérons que cela aidera à améliorer l'approche OpenCL (pas très confiant à ce sujet).

Vous pouvez également suivre l'état du PR https://github.com/tensorflow/tensorflow/pull/9117

Merci! J'ai suivi ce problème au cours des derniers mois. Je ne suis pas convaincu de l'engagement Apple OpenCL, étant donné qu'ils sont bloqués sur OpenCL 1.2 depuis 2013 (Apple ne fournit pas encore de support SPIR 1.2).

Si TensorFlow sur OpenCL pouvait vous aider dans votre travail, faites-le moi savoir, dans la mesure où je peux aider à faire avancer la recherche et la pratique de l'apprentissage en profondeur, j'aimerais vous aider. Mon entreprise a construit un back-end OpenCL pour TensorFlow adapté à une variété de GPU dans le cadre de notre travail sur l'inférence sur l'appareil. Nous avons testé sur les principales familles de GPU mobiles et de bureau, y compris les configurations courantes sur Windows et Mac. S'il y a suffisamment d'intérêt, nous pouvons faire une sorte de distribution publique. Nous avons également Metal (GPU Apple) et LLVM (CPU), ainsi qu'un moyen de faire un déploiement sans dépendance. L'idée ici étant de donner à chaque appareil un excellent support pour l'apprentissage en profondeur.

@choongng - tout cela semble incroyablement utile et utile. Mon projet personnel https://github.com/Synopsis/ bénéficierait grandement d'OpenCL sur OS X, ainsi que du déploiement de Metal pour iOS et Desktop. S'il est possible que cela soit introduit dans Tensorflow proprement dit, je pense que ce serait une aubaine considérable pour des tonnes de développeurs.

Merci.

@choongng

Si votre entreprise publie une version OpenCL, ou plus intéressant une version Metal de TensorFlow, je pense que cela va être une excellente nouvelle pour beaucoup de monde, je suis en train de construire un eGPU avec une carte NVidia pour obtenir TensorFlow / Keras tourne sur mon MBP pour mon boulot...

Pour les personnes intéressées ... rendez-vous sur la communauté eGPU.io

@choongng

Je serais très intéressé à voir cela, donc je serais très reconnaissant que vous puissiez le poursuivre! Surtout s'il ne nécessite pas les compilateurs sommaires à source fermée que TF a choisis pour le support CL.

Le 26 avril 2017 03:33:51 GMT+01:00, Choong Ng [email protected] a écrit :

Si TensorFlow sur OpenCL pouvait vous aider dans votre travail, faites-le moi savoir, au
dans quelle mesure je peux aider à faire avancer la recherche et la pratique de l'apprentissage en profondeur
aime aider. Mon entreprise a construit un back-end OpenCL pour TensorFlow
optimisé pour une variété de GPU dans le cadre de notre travail sur l'inférence sur l'appareil.
Nous avons testé sur les principales familles de GPU mobiles et de bureau, y compris
configurations courantes sur Windows et Mac. S'il y a suffisamment d'intérêt, nous
peut faire une sorte de distribution publique. Nous avons aussi Metal (GPU Apple)
et LLVM (CPU), ainsi qu'un moyen de faire un déploiement sans dépendance. le
l'idée ici étant de donner à chaque appareil un excellent support pour l'apprentissage en profondeur.

--
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297220160

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Je pense que ce serait révolutionnaire ;)

@choongng Peut-être que cela aiderait si vous unissiez vos forces avec ces gars
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey quel est le compilateur open source que vous proposez d'utiliser alors ? Il est difficile de trouver une solution open source compatible OpenCL pour traiter un grand nombre d'appareils dans la nature...
Nous devons amorcer une solution à un moment donné d'une manière ou d'une autre...

Je n'ai pas dit que c'était une solution facile. Mais là, OpenCL n'est pas le problème. Après tout, CUDA est entièrement propriétaire, bien pire que même l'option OpenCL que TensorFlow a choisie.

Cela dit, il existe des options pour un système CL-ou-cuda si vous partez de zéro, y compris des runtimes middleware portables ou arrayfire, etc. Tensorflow est cependant trop lié à CUDA.

Je trouve frustrant que les gens soient prêts à écrire des noyaux dans CUDA mais rechignent à le faire pour CL, même si cela atteindrait plus d'utilisateurs et développerait sérieusement l'écosystème du marché. Une plate-forme ouverte pour tous présente des avantages directs et indirects, ce qui peut entraîner d'importantes économies de coûts pour tout le monde à long terme.

Si SYSCL est la façon dont cela se produit finalement, tant mieux : alors pourquoi certains grands noms ne misent-ils pas sur une distribution SYSCL ouverte au lieu d'acheter des options propriétaires marginales, ce qui va à l'encontre de l'objectif d'un standard ouvert ?

Le 28 avril 2017 09:13:06 GMT+01:00, Ronan Keryell [email protected] a écrit :

@cathalgarvey quel est le compilateur open source que vous proposez d'utiliser alors ?
Il est difficile de trouver une solution open source compatible OpenCL pour
s'adresser à beaucoup d'appareils dans la nature...
Nous devons amorcer une solution à un moment donné d'une manière ou d'une autre...

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297936468

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Ce que je veux demander dans ce contexte est ceci :

Ainsi, certains frameworks d'apprentissage en profondeur comme Tensorflow explorent quelque peu l'utilisation d'opencl comme alternative à CUDA. Bien sûr, CUDA n'est que le "langage" sur lequel cuDNN a été développé, et c'est (si ma compréhension est correcte) ce que la plupart des langages d'apprentissage en profondeur utilisent réellement. Dans ce contexte, je ne sais pas quelle est la version opencl de cuDNN.

AMD a également parlé d'alternatives open source à CUDA qu'ils développent en permanence et appellent rocM. Ils parlent également de miOpen pour être l'équivalent de cuDNN (bibliothèques d'assemblage artisanales pour les fonctions d'apprentissage en profondeur communes), qui n'a cependant pas encore été publiée. L'approche d'AMD est un peu plus holistique : nous ne nous contentons pas d'exporter des calculs lourds vers le GPU.

Dans ce contexte, je suis vraiment confus. Comment les efforts opencl comme ceux énumérés ci-dessus s'imbriquent-ils ? Pour les GPU NVIDIA, c'est facile... il y a CUDA, et il y a cuDNN écrit en CUDA. Pour les non-NVIDIA/ou dans ce cas AMD, cela semble tellement moins clair. Quand HIP est-il préféré? Quand est-il préférable d'utiliser le HCC ? Quand est-il préférable d'utiliser opencl ? Toute idée serait vraiment appréciée!

@cathalgarvey il y a beaucoup de politique derrière toutes ces énormes infrastructures logicielles/matérielles... :-(
Même si on peut rêver d'une table rase basée sur des critères scientifiques purs, je pense qu'il faut être pragmatique.
Google ne veut pas trop changer l'architecture TensorFlow. C'est pourquoi l'architecture basée sur OpenCL doit être très similaire, nécessitant un C++ à source unique comme "CUDA runtime" au lieu de la solution OpenCL C de niveau inférieur non à source unique. Dans le domaine Khronos, la version C++ à source unique d'OpenCL s'appelle SYCL.
Discutons-en lorsque vous passerez par Dublin, par exemple, puisque vous semblez également être basé en Irlande. :-)
En attendant, n'hésitez pas à contribuer à https://github.com/triSYCL/triSYCL et aux branches TensorFlow & Eigen traitant de SYCL...

@keryell Savez-vous si XLA:GPU :OpenCL est également prévu sur SyCL ?

Bonjour @benoitsteiner , concernant :

Là, dans une section spécifique à OpenCL dans la documentation globale de TensorFlow. Celle-ci sera bientôt publiée sur le site tensorflow.org.

J'ai fait une recherche sur tensorflow.org pour OpenCL et je n'ai pas semblé pouvoir trouver quoi que ce soit de significatif, tout semble pointer ici. Par "bientôt", tu veux dire avant ______ ? ( _insérez un drôle de sarcasme ici_ ).

J'ai pu compiler votre référentiel (yay !), même si je suppose qu'il a besoin d'autre chose pour créer un Tensorflow OpenCL fonctionnel pour Mac ; J'ai essayé de construire le compilateur triSYCL mentionné mais malheureusement j'ai échoué.

@bhack Puisque je ne travaille pas pour Google, je n'ai aucune idée des détails de XLA...

@dylib malheureusement tout ceci est un travail en cours...

@keryell Oui, je sais. J'étais juste curieux de savoir si cela avait été discuté lors de certaines réunions.

OpenCL est radicalement différent de CUDA. Je verrais cependant définitivement cela porté sur HIP à la place.
Donc +1 pour tous ceux qui l'ont suggéré.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

HIP permet aux développeurs de convertir le code CUDA en C++ portable. Le même code source peut être compilé pour fonctionner sur des GPU NVIDIA ou AMD

Peu de gens connaissent HIP.
Vous pouvez trouver plus d'informations sur tensorflow et HIP ici :
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
et
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Remarque complémentaire :
Je ne pense pas que nous devrions nous battre / nous vanter de Nvidia contre AMD. Ce sont des entreprises respectables qui fabriquent du matériel et des logiciels incroyables. Nous devrions plutôt nous concentrer sur la fourniture de tensorflow à une base d'utilisateurs plus large.
Cibler de nombreuses langues via des liaisons est déjà un bon point de départ, mais nous devons également cibler autant de matériel que possible. (Même si les solutions cloud sont incroyables, elles ne sont pas toujours la réponse)

Nous avons de l'expérience avec HIP, ici à Stream. Laisse-moi regarder.

Mettez-vous d'accord sur l'argument "mon entreprise est meilleure". J'aimerais savoir quels GPU TensorFlow devrait cibler. Il doit être pragmatique et utile. Par exemple les GPU Intel ou les GPU embarqués (Qualcomm, ARM, Imagination), RaspBerry Pi - oui ou non ?

AMD Radeon Vega édition frontière

Nous continuons d'améliorer de manière agressive notre plate-forme logicielle ouverte ROCm et nos bibliothèques d'apprentissage automatique. Nous prenons également en charge les frameworks ouverts d'intelligence artificielle comme Caffe (sorti en avril). Plus tard ce trimestre, nous prévoyons d'offrir un support pour Torch, et Tensor Flow est en préparation.

Ils ont déjà publié Caffe, seraient très intéressés d'entendre d'autres personnes sur ce fil partager leurs expériences avec la construction/les tests :

https://github.com/ROCmSoftwarePlatform/hipCaffe

J'ai commencé l'installation, mais j'ai rencontré un obstacle où tout ce qui nécessite CL se fige, même clinfo . Je ne sais pas si cela est dû à un problème logiciel ou si ma carte (R9 390) n'est tout simplement pas prise en charge par ROCm.

Le 17 mai 2017 15:18:32 GMT+01:00, Bryan Li [email protected] a écrit :

AMD Radeon Vega frontièreÉdition

Nous continuons à améliorer de manière agressive notre plate-forme logicielle ouverte ROCm
et les bibliothèques d'apprentissage automatique. Nous soutenons également la machine ouverte
cadres de renseignement comme Caffe (publié en avril). Plus tard ce
trimestre, nous prévoyons d'offrir un support pour Torch, et Tensor Flow est en
les travaux.

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -302103815

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

@cathalgarvey J'utilise la branche Caffe OpenCL sur les GPU d'AMD et cela fonctionne très bien. make run test a réussi tous les tests sauf un

Bon à entendre; puis-je poser des questions sur votre configuration HW/SW ? Par exemple, quelle carte vous êtes
en utilisant, quelle distribution/version de Linux, etc. ?

J'avais auparavant AMDGPU-pro, mais je l'ai désinstallé lors de l'installation de ROCm.
Il est possible qu'il y ait quelque chose d'héritage interférant avec moi.

--
@onetruecathal / @ [email protected]

Le mercredi 17 mai 2017 à 15h50, Bryan Li [email protected]
a écrit:

@cathalgarvey J'utilise la branche Caffe OpenCL sur les GPU d'AMD et
ça marche très bien. make run test a réussi tous les tests sauf un

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@cathalgarvey

• Branche Caffe OpenCL (commit testé c61d48746b2df1d237c64abc7416342ce98f3251 )
• Système d'exploitation : Ubuntu 16.04.2 LTS
• Testé sur Polaris (RX460), Fidji (Fury X) et Tonga (W7100)
• Pilote : pilote AMDGPU-Pro pour Linux 16.40 ou supérieur
• VienneCL
• Dépendances générales : libprotobuf-dev libleveldb-dev libsnappy-dev libopencv-dev libhdf5-serial-dev protobuf-compiler libatlas-base-dev libblas-dev libgflags-dev libgoogle-glog-dev liblmdb-dev libboost-all-dev cmake python-numpy
• cmake : cmake -DViennaCL_INCLUDE_DIR=<wherever you downloaded ViennaCL>/ViennaCL-<version> -DOPENCL_INCLUDE_DIRS=<wherever you downloaded ViennaCL>/ViennaCL-<version>/CL/ -DOPENCL_LIBRARIES=/opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1 ..

Oui, en plus de la branche OpenCL ci-dessus, naibaf7 publiera (très bientôt) un livre sur son utilisation pour l'inférence en temps réel sur du matériel de base utilisant des graphiques amd et hd.

Ah ; Je parlais de hipCaffe, pas de la branche OpenCL :

https://github.com/ROCmSoftwarePlatform/hipCaffe

L'installation de ROCm pour construire/tester hipCaffe m'a obligé à désinstaller
AMDGPU-pro, je vais peut-être réessayer la branche vanilla. C'est mal
documenté, malheureusement. Je suppose que je vais essayer un "make" aveugle et voir.

Donc, je suis toujours intéressé d'entendre les expériences des autres avec l'AMD
pile ROCm/HIP ; s'ils travaillent sur une fourche Tensorflow, ce serait génial,
à condition qu'il fonctionne réellement sur plus de 3/4 modèles de carte AMD dans le
sauvage.

--
@onetruecathal / @ [email protected]

Le mercredi 17 mai 2017 à 16h09, Bryan Li [email protected]
a écrit:

@cathalgarvey

Branche Caffe OpenCL (commit testé
c61d48746b2df1d237c64abc7416342ce98f3251)
Système d'exploitation : Ubuntu 16.04.2 LTS
Testé sur Polaris (RX460), Fidji (Fury X) et Tonga (W7100)
Pilote : pilote AMDGPU-Pro pour Linux 16.40 ou supérieur
VienneCL
Dépendances générales : libprotobuf-dev libleveldb-dev libsnappy-dev
libopencv-dev libhdf5-serial-dev protobuf-compiler libatlas-base-dev
libblas-dev libgflags-dev libgoogle-glog-dev liblmdb-dev
libboost-all-dev cmake git python-numpy cmake
—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@cathalgarvey J'espère qu'ils travaillent sur un backend branché, pas sur un fork complet. Ce serait triste et ne ferait que diviser l'effort de travail.
Il y a déjà assez d'outils :/

Les efforts de @YvanDaSilva AMD sont un peu mal coordonnés pour le moment (oui, toutes les fourches). De plus, cela ne semble pas encore fonctionner aussi bien sur une grande variété d'appareils, contrairement à la branche OpenCL de Caffe, par exemple...

@naibaf7 Je suis absolument d'accord.
Pour être honnête, ils semblent vraiment manquer de ressources humaines, ils travaillent sur tous les fronts.
Au fait : je ne savais pas que l'ETH avait une Neuroinformatique ;) sympa !

@cathalgarvey Pouvez-vous élaborer sur la pile ROCm/HIP pour un profane comme moi. J'ai joué à AMGPU-pro et AMDGPU avec mes cartes Sea Islands, donc je suis sûr que je pourrais publier des résultats utiles.

@YvanDaSilva
Ils ont parrainé mon projet original Caffe OpenCL, et malheureusement ne se sont pas bien coordonnés, donc la recherche AMD et un gars indépendant chez AMD ont également travaillé sur les ports OpenCL en parallèle - l'ancienne équipe de recherche AMD est maintenant dissoute et la plupart d'entre eux travaillent en fait pour Tesla ( projet de voiture autonome) maintenant ... donc une chaîne d'événements malheureux.
Je suis toujours en collaboration et en contact avec eux. Vega va être intéressant :)

@naibaf7 Nice, vous avez de la chance ! J'aurais aimé qu'il y ait de telles études quand j'étais au Heig-vd, j'aurais certainement continué vers un MSc.

Ouais... C'est ce que je pensais. Tant de travail, si peu de ressources humaines disponibles dans ces domaines.

Tout cela sonne bien, mais recentrons la discussion sur le fait que TensorFlow fonctionne avec OpenCL SYCL et pas seulement des solutions spécifiques au fournisseur... :-)
J'espère que RoC et d'autres HiP ont leur propre GitHub pour discuter de leurs propres problèmes...
@naibaf7 : au moins, je suis toujours dans le domaine OpenCL. Rejoignez à nouveau le club ! :-)

@keryell Je pense que la discussion sur HIP est valable, s'il y a un port HIP pour Tensorflow en préparation. Après tout, la solution officielle Tensorflow-on-CL consiste à utiliser un framework SYCL propriétaire avec une prise en charge de plate-forme et de noyau fortement limitée, donc ce n'est pas vraiment mieux que les solutions HIP "spécifiques au fournisseur" qui offrent une nouvelle façon de sortir de CUDA.

HIP est peut-être principalement le fait d'AMD en ce moment, mais autant que je sache, c'est une norme ouverte ? Peut-être que je me trompe. Si c'est le cas, et si AMD peut fournir un port tensorflow-on-HIP, il serait immédiatement plus ouvert que le port officiel tensorflow-on-SYCL.

HIP est un sous-ensemble de CUDA, il est donc aussi ouvert que CUDA.

OK bien; HIP-the-API est un sous-ensemble de CUDA-the-API, mais à moins que NVidia ne soit assez lâche pour commencer à canaliser Oracle, je doute que ce soit un problème. Je faisais référence au runtime/compilateurs pour HIP, dont je pense que les AMD sont ~ ouverts.

edit : Désolé si ce qui précède est sorti grossier ; juste essayer de clarifier ma position ci-dessus!

Vulkan et Opencl vont-ils fusionner ?

selon Reddit AMA de Raja, Vega prendra en charge Tensorflow, Cafe2, Cafe, Torch7 et MxNet via MIOpen.

@cathalgarvey la discussion est clairement valable, mais pas ici...
Vous êtes sur GitHub ici, en train de discuter du port de TensorFlow & Eigen en utilisant les standards du groupe Khronos.
Ceci n'est pas Twitter ou votre mur Facebook... :-)
Alors s'il vous plait, contribuez avec quelques commits sur ces projets ! :-)

Il existe une nouvelle version du guide d'installation pour compiler TensorFlow avec ComputeCpp, l'implémentation de SYCL par Codeplay, afin que les périphériques OpenCL puissent être utilisés. Nous apprécierions tout commentaire que vous pourriez nous donner à ce sujet. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

Avez-vous une idée du taux de réussite pour que cela fonctionne sur des GPU AMD non testés ? Je suis particulièrement intéressé s'il a été testé pour AMD Radeon Pro 460 @rodburns. Je serais heureux de passer quelques heures à faire fonctionner Ubuntu sur mon ordinateur portable Macbook s'il y a un espoir avec un GPU non testé

@samhains nous n'avons pas testé cela mais vous pouvez essayer. Vous devrez utiliser des pilotes AMD plus anciens avec Ubuntu qui prennent en charge l'extension SPIR. Je n'ai pas encore été en mesure de déterminer quels sont ces pilotes.

@samhains Si la route de lecture de code échoue, ne manquez pas tf-coriander , qui est enfin à un état d'utilisation pratique sur Ubuntu/Mac.

Je le teste actuellement sur des convnets, des rnns bidirectionnels, etc. et tout semble bien fonctionner. Il fonctionne sur OpenCL 1.2 "vanille", ce qui devrait permettre à Tensorflow d'utiliser une vaste gamme de matériel relativement ancien.

Le hic est, pour l'instant, qu'il est basé sur Tensorflow 0.11.

@rodburns. J'ai essayé de suivre les étapes répertoriées sur le lien https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp
J'obtiens l'erreur suivante :
ERREUR : /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD:609 :1 : inclusion(s) non déclarée(s) dans la règle '@protobuf//:python/google/protobuf/internal/_api_implementation.so ' :
En fait, j'obtiens la même erreur si j'essaie de compiler tensorflow à partir de la source. Je l'ai compilé plus tôt, mais je ne sais pas ce qui a changé.

@rahasayantan qu'est-ce qui est inclus ? De plus, l'obtenez-vous lors de la compilation sans --config=sycl ?

@lukeiwanski : Le problème, si je comprends bien, est que Bazel essaie de compiler Protobuf et qu'il ne trouve pas ou ne télécharge pas les sous-répertoires. J'ai fait un pull avec le sous-module récursif, mais il a toujours les mêmes problèmes. Et il a le même problème sans --config = sycl. En fait, je suis confronté au même problème lorsque je fais un git pull depuis le projet principal de tensorflow. Je ne pense pas que cela soit lié à openCL, c'est quelques problèmes avec la façon dont je fais le pull. Lorsque je télécharge manuellement le fichier zip du projet à partir de votre dépôt sans git ni compile, il se compile correctement, mais j'obtiens alors une erreur de segmentation. J'ai déjà soulevé ce problème sur votre projet GIT et nous en parlons là-bas, je donnerai les mises à jour liées au défaut de segmentation sur ce fil (inutile de dupliquer les choses). Merci pour votre réponse.

L'open source triSYCL arrive. Voir https://github.com/triSYCL/triSYCL/pull/45

Je suis nouveau ici. Très intéressé à voir TF prendre en charge OpenCL. Comment puis-je obtenir des mises à jour de ce fil ?

euh...Intéressant, mais pourquoi ? Je veux dire pourquoi Tensorflow a choisi cuda mais opencl au début ? Une raison commerciale je suppose ?

Salut @tensorflower-jardinier,

@hughperkins a créé Coriander qui pourrait exécuter le code NVIDIA® CUDA™ sur les appareils OpenCL 1.2. Vous voudrez peut-être jeter un coup d'œil si cela vous convient pour connecter TF aux appareils OpenCL 1.2. Merci d'attribuer son nom et sa contribution au cas où vous envisagez d'utiliser son travail.

Il semble que les espoirs de voir jamais le support de OpenCL pour Mac sont passés de peu à tf.zero . Je viens de lire que TensorFlow Mac n'aura apparemment plus AUCUN support GPU (1.2+):

Note: As of version 1.2, TensorFlow no longer provides GPU support on Mac OS X.

https://www.tensorflow.org/install/install_mac

TF-Coriander est testé sur Mac, donc si/quand il atteint la parité de version, vous devriez pouvoir l'utiliser.

Le 22 juin 2017 à 11:46:51 CEST, dylib [email protected] a écrit :

Il semble que l'espoir de voir un support OpenCL pour Mac est passé de
peu à tf.zero . Je viens de lire que les Mac n'y auront plus
N'IMPORTE QUEL support GPU apparemment (1.2+):

Note: As of version 1.2, TensorFlow no longer provides GPU support on
Mac OS X.

https://www.tensorflow.org/install/install_mac

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -310331281

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Triste parce que maintenant avec un eGPU et n Nvidia 980 Ti à l'intérieur, le pilote fonctionne et Cuda fonctionne

Je n'ai pas encore eu le temps d'essayer Tensor Flow dans ma configuration.

webdriver et Cuda toolkit installés sur mon ordinateur et les exemples Cuda fonctionnent bien

https://youtu.be/JN9fDmqf010

@cathalgarvey vous avez dit que vous testiez les convnets sur tf-coriander, mais il ne semble pas que les convnets fonctionnent encore. Pouvez-vous préciser si vous avez réussi à faire fonctionner les convnets sur le GPU à l'aide de tf-coriander ?

POUR VOTRE INFORMATION,
https://github.com/tensorflow/tensorflow/issues/10703

Pourquoi tensorflow ne prend-il plus en charge les GPU sous OS X ? Je prévoyais d'utiliser Tensorflow avec une configuration eGPU que j'ai commandée.

@justinrmiller ils prétendent qu'ils ne peuvent plus le tester sur mac os, et ont donc décidé d'arrêter le support. cependant, j'ai du mal à y croire. À l'avenir avec l'annonce d'egpus sur high sierra et avec les nouveaux pilotes nvidia, ce ne sera plus le cas.

@tscholak ouais exactement. J'allais utiliser mon nouveau boîtier egpu pour abandonner définitivement ma boîte Windows.

En gardant à l'esprit que bien que les cartes Nvidia fonctionnent dans les boîtiers eGPU, Apple ne prendra officiellement en charge le RX580 que dans son kit de développement, de sorte que le besoin d'OpenCL ne disparaîtra pas.

OpenCL sur Mac est 1.2, ce qui signifie qu'il ne semble pas y avoir de pilote actif
développement. Je pense que l'ajout du support Metal à TF est un processus laborieux
(en activant Eigen et l'exécuteur de flux) mais faisable.

Le dimanche 16 juillet 2017 à 15 h 17, Ferdia McKeogh [email protected]
a écrit:

En gardant à l'esprit que bien que les cartes Nvidia fonctionnent dans les boîtiers eGPU, Apple
ne prendra officiellement en charge le RX580 que dans son kit de développement, donc le besoin de
OpenCL ne disparaîtra pas.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Je suis très triste de l'abandon du support GPU pour macOS.

Toujours à la recherche de la prise en charge d'OpenCL pour le GPU sur macOS, car Apple ne changera évidemment pas de sitôt pour les GPU Nvidia.

Tensorflow est mon moteur de prédilection. Utiliser l'accélération GPU localement sur mon MacBook Pro ou mon futur iMac Pro serait génial.

Pour Microsoft, il serait logique de saboter Apple, mais puisque Google n'a pas de système d'exploitation de bureau, ils ne font que se faire du mal.

Honnêtement, quelqu'un de plus intelligent que moi devrait envisager d'intégrer les MPS - Metal Performance Shaders de Mac OS 10.13, qui prennent en charge un grand nombre de primitives de réseau neuronal prêtes à l'emploi. Cela permettrait un GPU à jour et hautes performances pour le déploiement d'inférence mobile et de bureau iOS et macOS Tensorflow.

Vous ne pouvez pas vous entraîner avec les primitives Apples si je comprends bien (elles ne fournissent rien), mais avec le support de Tensorflow, vous pourriez peut-être ? J'imagine que pour les gens sur la plate-forme Apple, ce serait une aubaine.

Je ne pense pas que Google fournirait cela en interne, et je n'ai pas les compétences requises pour l'essayer moi-même. Publier cette idée pour que des gens plus talentueux que moi puissent l'accepter.

:)

Apple vise uniquement à vendre des appareils Apple. Google vise à embaucher des services massifs de Google.

Si vous êtes prêt à faire de l'IA (apprentissage) avec un seul appareil, comme un ordinateur portable Apple, vous ferez "Apprentissage superficiel" au lieu de "Apprentissage en profondeur", vous feriez donc mieux de renoncer à faire autre chose que des tutoriels. L'inférence aboutit à un modèle formé pour un seul utilisateur, dans un seul appareil (même dans un téléphone pas trop multicœur), pourrait être une bonne chose à faire via des GPU, mais n'est parfaitement faisable qu'avec des CPU.

D'un autre côté, les GPU sont absolument nécessaires si vous allez alimenter des ensembles de données extrêmement volumineux pour l'apprentissage ou si vous allez servir une inférence formée à des groupes de clients simultanés extrêmement importants.

Même si, le faire à une telle échelle n'est pas si facile en raison des problèmes de réseau. Jetez un coup d'œil à l'architecture physique des TPU-Pods. C'est aux antipodes d'un ordinateur portable (plusieurs GPU par serveur multicœur surchargé en mémoire, avec fibre optique dédiée pour les communications inter-serveurs).

J'ai un MacBook Pro. C'est un terminal sympa pour accéder au cloud :-D

Je vois que TF on Metal peut également s'étendre à iOS. Si quelqu'un est intéressé à le récupérer, je recommande d'abord d'ajouter le support Metal à Eigen (peut utiliser OpenCL comme référence).

@rogerpasky Pour l'école, j'ai dû utiliser Tensorflow pour former des modèles, pas seulement pour évaluer un modèle. Et je devrai répéter cela dans un futur proche. Pour les étudiants comme moi, avoir une formation sur GPU est un must, ce qui permet de gagner beaucoup de temps. Il ne s'agit pas seulement de servir plusieurs utilisateurs simultanés.

@rogerpasky il s'agit de la possibilité de développer des modèles et des solutions localement sur un mac

@rogerpasky respectueusement en désaccord. Bien que les solutions multi-GPU basées sur le cloud fonctionnent très bien pour les services Internet, je cible les pipelines de production vidéo professionnels où l'inférence est exécutée sur des heures et des heures de vidéos pro-res et non compressées HD, 2K, 4K, ce qui a) aucune maison de production n'est vont télécharger sur un cloud, b) ils ne veulent pas que Google ou qui que ce soit ait leurs données, c) ils ont des salles pleines de systèmes compatibles multi-GPU (Mac et Windows) localement qu'ils aimeraient exploiter, et d) alors que l'inférence sur une seule image est bonne sur le CPU, l'exécution de films entiers pour l'inférence à travers plusieurs graphiques 100% voit une augmentation des performances en utilisant quelque chose comme MPS vs CPU. Parce que la communauté a refusé de soutenir / adopter les normes et utilise à la place le code Nvidia uniquement, les cas d'utilisation du monde réel sont classés et c'est vraiment dommage.

Il ne s'agit pas d'une demande inutile de la part d'un amateur exécutant des didacticiels - l'inférence GPU est importante, tout comme la prise en charge de diverses familles GPU / CPU pour diverses charges de travail sur du matériel réel. J'espère vraiment que Google prendra cela au sérieux, car ce serait formidable de pouvoir s'en tenir à une seule bibliothèque comme TF, ce qui est génial.

Merci de m'avoir entendu, je n'essaie pas de fulminer, mais de donner un autre point de vue à la communauté.

@pldelisle , @tscholak , @vade s'il vous plaît ne vous méprenez pas. J'adorerais l'avoir, et si vous cherchez dans ce fil, je me suis joint en tant que partisan, mais pour autant que je l'ai suivi, j'ai atteint la conclusion que j'ai écrite, pas seulement parce que je le pense (je suppose qu'un MacBook fondrait s'il était formé avec des milliers de vidéos :-D), mais avec les faits réels de l'industrie. N'attendez pas pour le résoudre dans un court laps de temps (à mon humble avis, il ne sera jamais résolu car Apple et Google se détestent depuis le problème iPhone/Android).

@rogerpasky Il y avait déjà un support pour les GPU nvidia sur Mac OS. Il vient d'être supprimé en 1.2.

Note: As of version 1.2, TensorFlow no longer provides GPU support on Mac OS X.

J'ai annulé ma commande d'un eGPU (Sonnet) et je vais simplement démarrer Linux sur ma plate-forme de jeu, mais c'est plutôt mauvais d'arrêter de prendre en charge quelque chose que les gens utilisaient. J'espérais vraiment le faire sur mon mac avec un eGPU (formation de modèle), mais je suppose que cela n'arrivera pas maintenant : https://github.com/lengstrom/fast-style-transfer

@rogerpasky Er, vous savez que CoreML prend en charge l'importation de modèles de flux tensoriels via Keras ? Apple ne "déteste" pas Google, les affaires sont les affaires, l'un des fournisseurs d'Apple est Samsung. Lisez cela un instant. Google, Apple, Samsung sont des entreprises et feront ce qui rapporte de l'argent. En remarque. Au fait, mon MacBook Pro n'a pas fondu après avoir exécuté des inférences sur des milliers de films. Je soupçonne que CUDA a été très pratique à adopter et que le support continu de Nvidia et les opportunités manquées d'AMD nous ont amenés là où nous en sommes. Je ne pense pas que ce soit néfaste, juste le coût de faire un changement par rapport aux deltas de performances par rapport au coût de maintenir le cap.

Je soupçonne qu'un génie viendra aider à résoudre le problème.

J'ai créé un groupe Google pour une discussion collaborative sur l'introduction de l'apprentissage en profondeur dans de nouveaux endroits comme OpenCL, Mac, iOS, CoreML, Vulkan, etc. Si vous souhaitez contribuer à leur réalisation, rejoignez-nous et publiez une note avec votre utilisation cas ou sur quelle partie du problème vous travaillez. Il y a déjà des gens qui travaillent très dur pour amener TF sur plus de plates-formes, y compris MIOpen, le travail de Codeplay, TF-Coriander et un projet interne à mon entreprise (Vertex.AI). Ce serait formidable de réunir les développeurs et les utilisateurs au même endroit, car ces efforts sont tous étroitement liés.

https://groups.google.com/forum/#!forum/deep-learning-everywhere

@benoitsteiner @hughperkins @cathalgarvey
@rogerpasky @vade @tscholak @pldelisle @adityaatluri @chocol4te @justinrmiller

@justinrmiller J'ai un eGPU sur Sierra (Titan Xp dans un boîtier Sonnet) exécutant Tensorflow 1.2.1 (CUDA 8, cuDNN 6) qui n'était pas trop compliqué si cela ne vous dérange pas de construire à partir de zéro. Si vous avez des problèmes, faites-le moi savoir.

tensorflow/core/common_runtime/gpu/gpu_device.cc:1045] Creating TensorFlow device (/gpu:0) -> (device: 0, name: TITAN Xp, pci bus id: 0000:4f:00.0)

In [5]: tf.__version__
Out[5]: '1.2.1'

@danbarnes333 C'est génial ! Merci pour l'info!

@ danbarnes333 comment avez-vous construit tf 1.2 avec cuDNN 6 ? Avez-vous utilisé LLVM ? CCG ? J'ai seulement réussi à le faire construire avec cuDNN 5...

Pour info, https://machinelearning.apple.com/

@tscholak Je ne le posterai pas ici pour le garder sur OpenCL mais je résumerai mal les étapes ici .

@choongng J'ai rejoint le groupe Google mais il semble être calme. Alors je vais fulminer ici ;-)

1. Machine learning / haute performance / GPU computing est un marché très concurrentiel. NVidia, qu'on le veuille ou non, domine le marché et garde ses cartes et ses logiciels à portée de main. Si vous avez un budget et un délai, vous êtes plus ou moins coincé avec NVidia pour le moment.

2. J'ai une carte AMD à l'ancienne ("Bonaire") et un budget zéro - amateur. J'ai caffe en cours d'exécution avec l'implémentation propriétaire AMD OpenCL 2 sur Arch Linux depuis hier, et je viens de faire fonctionner l'open source MIOpen d'AMD de la même manière ce matin. Cela me permettra de former des modèles ; le Bonaire culmine autour de 1800 GFLOPS en simple précision. Donc, si TensorFlow ne fonctionne pas avec OpenCL sur le Bonaire, je n'utiliserai pas TensorFlow.

3. Si un budget devait apparaître comme par magie, j'achèterais un processeur Intel et une carte NVidia et j'exécuterais un logiciel propriétaire pris en charge par le fournisseur. J'ai fini de faire de l'assurance qualité non rémunérée pour des fournisseurs comme Google, Red Hat, Canonical et AMD.

   Il m'a fallu trois mois (et trois distributions - Fedora 25, Ubuntu 16.04 LTS et Arch) pour tirer quelque chose d'un GPU que j'ai depuis trois ans. Il y a des bogues non corrigés dans le traqueur de bogues de Fedora avec mon nom dessus. Il en va de même pour Ubuntu et Freedesktop.org. La plupart des gens qui les réparent ne sont pas payés non plus, ou ils sont payés pour faire autre chose.

   Oui, les nouveaux processeurs d'AMD sont impressionnants, et oui, la plupart de leurs logiciels sont open source, mais les budgets et les délais changent les choses. Le soutien est essentiel. Le soutien est tout!

@znmeb Je ne savais même pas que vous pouviez utiliser du matériel pré-GCN pour TF.
Avec mon Tahiti, je n'ai qu'un seul support pour une distribution (ubuntu 14.01.x) car les pilotes propriétaires AMD ne fonctionnent qu'avec les anciens noyaux Linux pour GCN1. (Je reçois TF + openCL via SYCL (non testé sur 7970))

Là où je travaille, tout le département R&D dirige une équipe verte. Ils ont tous des PHD et tous sauf aucun n'ont écrit une seule ligne de cuda (ni OCL). Mais l'outillage est là pour accélérer leur charge de travail Keras . Je suis un peu excentrique avec mes GPU miniers recyclés qui essaient de leur donner une seconde vie.

tl;dr autre que le support de l'équipe verte n'apparaîtra que si la part de marché du GPU AMD apparaît.
C'est un problème de poule et d'œuf. J'ai des espoirs pour vega… mais oui… ce n'est pas un tueur 1080Ti.

@acoye FWIW voici le post GitHub qui m'a permis de continuer ce week-end après avoir battu et googlé depuis avril : https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . Voir aussi https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . C'était mon problème initial - essayer d'utiliser mon Bonaire pour accélérer l'algèbre linéaire sur R.

@acoye
Vous pouvez passer aux dernières distributions Linux et utiliser un noyau compilé personnalisé récent comme 4.11/4.12 avec les pilotes AMDGPU activés, RADEON désactivé et avec CONFIG_DRM_AMDGPU_SI=Y et/ou CONFIG_DRM_AMDGPU_CIK=Y définis dans la configuration du noyau, plus le firmware AMD pour 7970 (Tahiti) dans initramfs => le plus récent AMDGPU-PRO OpenCL fonctionnera sur toutes les cartes GCN. Oubliez FGLRX (sur les anciennes distributions Linux) et Clover via les pilotes RADEON, les deux sont de qualité inférieure.
Oubliez également les cartes pré-GCN. Je les ai testés avec OpenCL sur Windows pour Caffe, les performances ne valent pas la peine de faire des efforts pour des cartes aussi anciennes. Comme toutes les cartes AMD post 2012 devraient être GCN de toute façon.

@ naibaf7 J'ai passé quelques heures hier à essayer de faire fonctionner la pile open source d'AMD. J'ai obtenu MIOpen et ses dépendances mais il manque encore quelques bits hcc . J'aurai peut-être besoin de créer un noyau personnalisé pour tout obtenir. Je ne me soucie pas beaucoup du portage du code CUDA ou de l'exécution de C++ compilé sur le GPU - je veux faire des calculs dessus. ;-)

J'ai également vu quelque chose sur leur site Web à propos de la programmation en assembleur - qui pourrait m'intéresser, car il est facile de passer de l'assembleur à FORTH. ;-)

@znmeb Ouais, j'essaie également de faire fonctionner des éléments MIOpen et TensorFlow sur mon RX 480, mais je ne veux pas détruire ma plate-forme de développement principale, donc j'utilise à la place la virtualisation IOMMU et une machine virtuelle Ubuntu 16.04 qui peut utiliser le RX 480. Les pilotes AMD sont très conviviaux pour la virtualisation (contrairement aux pilotes nVidia conçus pour les cartes de jeu - seuls les pilotes Quadro le font).

@znmeb Tout ce que vous avez à faire est sudo apt-get install rocm miopen-hip

@adityaatluri C'est dans le référentiel d'utilisateurs Arch mais il ne s'installe pas - il ne s'installe pas non plus à partir de la source GitHub. Cela ressemble à quelque chose de simple - il ne peut pas trouver quelques dépendances.

@znmeb Pouvez-vous créer un problème ici (https://github.com/RadeonOpenCompute/ROCm/issues) afin que nous puissions en discuter ? Merci!

@adityaatluri Bien sûr - Je vais dîner mais je le classerai à mon retour

@ebrevdo Un moyen d'utiliser le GPU tensorflow sur Mac avec un processeur AMD ?

@gautam1858 https://news.ycombinator.com/item?id=14894653

Mon entreprise travaille sur l'apprentissage en profondeur OpenCL depuis un certain temps et nous avons quelques premiers résultats à montrer. Nous nous concentrons sur Keras à court terme, mais nous avons également construit un support TensorFlow (très) expérimental et nous y reviendrons après notre version initiale. Plus de détails ici, y compris les chiffres de débit initiaux sur AMD : http://vertex.ai/blog/bringing-deep-learning-to-opencl

Frais!

Petit tatillon : AFAIK, MIOpen n'est pas spécifique à AMD, car il peut être lié à OpenCL ainsi qu'à ROCm. Ce dernier est probablement plus rapide, mais quand même ; MIOpen est un énorme pas en avant pour le shtick "Open Source Neural Networks On GPU", et AMD mérite une énorme crédibilité pour cela s'il fonctionne bien sur OpenCL.

Le 14 août 2017 à 17h19, "Choong Ng" a écrit :
Mon entreprise travaille sur l'apprentissage en profondeur OpenCL depuis un certain temps et nous avons quelques premiers résultats à montrer. Nous nous concentrons sur Keras à court terme, mais nous avons également construit un support TensorFlow (très) expérimental et nous y reviendrons après notre version initiale. Plus de détails ici, y compris les chiffres de débit initiaux sur AMD : http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

—

Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416) ou désactivez le fil de discussion (https://github.com/notifications/unsubscribe-auth /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Merci pour la correction, j'ai basé mon commentaire sur la configuration système requise dans la documentation MIOpen (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#prerequisites) mais heureux de mettre à jour s'il y a un meilleur lien.

Attendez, je lis ce fil / problème depuis 10 minutes maintenant. Je suis arrivé à mi-chemin et j'ai sauté le reste. Les GPU AMD sont-ils déjà pris en charge ?

Utilisation d'une source fermée capricieuse qui ne fonctionne que sur une très ancienne combinaison de noyau / système d'exploitation (codeplay): oui

Utilisation d'une ancienne version de tensorflow et sans prise en charge de certaines non-linéarités (tf-coriander) : oui.

Vraiment : pas officiellement. Bien qu'AMD porte sur HIP, je m'attends donc à des progrès d'ici 3 mois environ. D'autres frameworks fonctionnent déjà bien grâce à leurs efforts.

Le 18 août 2017 02:09:55 GMT+01:00, abrad1212 [email protected] a écrit :

Attendez, je lis ce fil / problème depuis 10 minutes maintenant. je suis à mi-chemin
à travers et j'ai sauté à travers le reste. Les GPU AMD sont-ils déjà pris en charge ?

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -323233294

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

FWIW Je pense que les versions récentes de PyGpu peuvent utiliser CUDA ou OpenCL. J'ai tous les logiciels installés sur ma boîte Arch mais je ne les ai pas encore testés.

@ abrad1212 oui, ce problème existe depuis un moment maintenant. L'effort est énorme et beaucoup de gens essaient de "le faire fonctionner" comme @cathalgarvey l'a mentionné.

Une petite mise à jour de notre côté. Vous devriez pouvoir utiliser ComputeCpp 0.3.0 sur la pile de pilotes AMDGPU-pro pour Ubuntu 16.04, les instructions peuvent être trouvées ici : http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 -04-lts/

De plus, nous nous concentrons maintenant sur l'amélioration des performances de différents modèles - il y a beaucoup à faire, mais nous y arrivons.

@lukeiwanski Quelle est votre approche du benchmarking ? Nous chronométrons les modèles inclus avec Keras et normalisons par rapport à TF+cuDNN+K80 car il s'agit d'une configuration courante et bien optimisée. Notre méthodologie est similaire à celle de Max Woolf (http://minimaxir.com/2017/06/keras-cntk/), ce n'est pas beaucoup de code mais nous serions heureux de le partager. Nous avons quelques chiffres de débit sur notre site Web (http://vertex.ai), notre code est très légèrement plus rapide que TF 1.2 sur l'inférence Xception et il serait intéressant de comparer davantage d'approches côte à côte.

Existe-t-il des solutions Windows ? J'installerais Ubuntu sur mon PC mais je n'ai actuellement pas assez d'espace pour le faire.

Ubuntu 14.04
branche principale de tensorflow
construire le support opencl, et seul le runtime du processeur Intel opencl est installé.
python2.7
suivez le guide https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
exécuter python classify_image.py
il semble n'avoir pas appelé le pilote opencl. (J'ai ajouté mon wrapper opencl icd, je n'ai rien vu)
Y a-t-il une configuration à ajouter dans le code python ?
Comme sess.graph.device('/cpu0')

Mais si j'utilise le guide Eigen skcl, il peut s'exécuter sur un processeur avec le support OpenCL. (De plus, ce code de guide est un peu obsolète, il faut le modifier)
https://developer.codeplay.com/computecppce/latest/getting-started-with-eigen

Toute personne peut aider à vérifier comment l'interface python tensorflow peut également fonctionner avec le support OpenCL.

Et construire tensorflow avec cet ensemble d'options ne générera pas vraiment de binaire tensorflow. --config=sycl
Créez simplement tensorflow dans cette commande :
bazel build -c opt /tensorflow/tools/pip_package :build_pip_package

Peut-être que je construis oublier --config=sycl
Je vais essayer la commande build et vérifier si elle peut appeler la bibliothèque OpenCL. Après avoir obtenu le résultat, je posterai ici.
bazel build -c opt tensorflow/tools/pip_package :build_pip_package

@ joe8086 Si vous modifiez la création de tf.Session avec ce qui suit, il affichera un journal dans le terminal, mentionne-t-il SYCL quelque part?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Pour le guide Eigen, avez-vous des commentaires spécifiques où il est obsolète ?

@rodburns Merci.
Mon erreur est de construire l'option de configuration manquante de tensorflow --config=sycl
Après avoir ajouté cette option avec ce code de branche https://github.com/lukeiwanski/tensorflow.git
Je peux voir tensorflow fonctionner avec le backend OpenCL.

Pour le guide Eigen, l'erreur principale est à :
1, ne donne pas le fichier d'inclusion correct.
2, pour tableau, Tensor, TensorMap ne donne pas le bon paramètre de modèle.
3, pour static_cast, ne donnez pas le type de données.

ajoutez plus d'informations qui peuvent peut-être aider ce sujet de discussion.
1, le tensorflow principal ne peut pas créer de tensorflow avec --config=sycl correct.
2, avec CPU OpenCL, la vitesse est d'environ 4x ~ 8x fois plus que la mise en œuvre normale du processeur dans mon environnement.

temps python classify_image.py
2017-09-07 16:56:29.076054 : I tensorflow/core/platform/cpu_feature_guard.cc:137] Votre CPU prend en charge les instructions pour lesquelles ce binaire TensorFlow n'a pas été compilé : SSE4.1 SSE4.2 AVX
2017-09-07 16:56:29.077967 : W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] Aucun GPU OpenCL pris en charge par ComputeCpp, en essayant le processeur OpenCL
2017-09-07 16:56:29.159775 : I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Trouvé les appareils OpenCL suivants :
2017-09-07 16:56:29.159825 : I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id : 0, type : CPU, nom : processeur Intel(R) Core(TM) i7-6700HQ @ 2,60 GHz, fournisseur : Intel(R) Corporation, profil : FULL_PROFILE
2017-09-07 16:56:30.213375 : W ./tensorflow/core/framework/op_def_util.cc:333] Op BatchNormWithGlobalNormalization est obsolète. Il cessera de fonctionner dans la version 9 de GraphDef. Utilisez tf.nn.batch_normalization().
panda géant, panda, ours panda, ours coon, Ailuropoda melanoleuca (score = 0,89107)
indri, indris, Indri indri, Indri brevicaudatus (score = 0,00779)
petit panda, panda roux, panda, ours chat, chat ours, Ailurus fulgens (score = 0,00296)
pomme cannelle (score = 0,00147)
étoile terrestre (score = 0,00117)

réel 1m44.473s
utilisateur 2m8.980s
système 1m20.024s

Les gars, je ne vais pas lire tout ce fil, mais si quelqu'un pouvait répondre à ma question, ce serait génial! Puis-je encore utiliser Tensorflow avec un GPU AMD. Si oui, dans quel système d'exploitation, et puis-je le faire avec RX Vega ? Merci!

@ M3L0NM4N Hmmm ... Je n'ai pas suivi le fil mais il semble qu'il y ait peut-être du code OpenCL testable maintenant, au moins sur CPU OpenCL. J'ai un ancien GPU AMD ("Bonaire") et j'ai OpenCL fonctionnant à la fois sur le GPU et le CPU, donc je peux tester cela. Je pourrais tenter ma chance pendant le week-end ; Je veux vraiment OpenCL TensorFlow sur mon GPU.

tf-coriandre fonctionne https://github.com/hughperkins/tf-coriandre

Y a-t-il un support tensorflow 1.3 gpu/opencl sur macos ?

Dernières nouvelles : J'ai construit avec succès TensorFlow 1.3.1 avec OpenCL à partir de la source GitHub. Il y a pas mal de pièces manquantes dans la documentation, et je n'ai pas encore essayé d'exécuter quoi que ce soit dans le GPU, mais cela fonctionne au moins pour les CPU non-OpenCL. BTW, je n'ai pas installé CPU OpenCL, juste GPU OpenCL.

Quelqu'un a-t-il des cas de test pour TensorFlow avec un GPU OpenCL ? Je vais devoir en construire un pour moi-même, mais j'espérais une vérification rapide.

@znmeb Oui, il y a une application de test en cause que j'ai signalée. https://github.com/hughperkins/tf-coriander/issues/64

Pourriez-vous s'il vous plaît me dire si cela fonctionne dans votre cas?

@unoexperto Ouais - cela fonctionne (ne plante pas) mais rien n'indique s'il a trouvé ou non OpenCL.

 python ./hello-tensorflow.py 
b'Hello, TensorFlow!'

Je pense que le meilleur plan d'action ici est de déposer un problème séparé pour demander de la documentation, car il est clair (lorsque vous exécutez la construction ./configure à partir de la source) qu'il existe du code pour OpenCL. C'est comme ça que je l'ai trouvé, en tout cas.

@znmeb Je doute qu'il ait trouvé un périphérique GPU dans votre cas, car dans le mien, il a imprimé des informations de débogage au début sur la sélection du périphérique GPU. Peut-être que vous pouvez recompiler avec printf ajouté à la console quelque part dans tensorflow/core/common_runtime/gpu/gpu_device.cc .

@unoexperto J'ai rejoint le groupe Google de discussion et posté une demande de documentation. Je vais attendre de voir si quelqu'un répond avant de m'y mettre davantage.

@znmeb Quelles instructions suivez-vous ? Avez-vous exécuté clinfo? Avez-vous exécuté computecpp_info ? Cela indique-t-il que vos pilotes OpenCL sont installés comme prévu ? Les instructions pour Ubuntu 14.04 sont ici https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow et si vous utilisez 16.04, il y a des instructions expérimentales ici http://deep-beta.co. fr/tensorflow-1-3-sur-ubuntu-16-04-lts/

@rodburns clinfo et clpeak fonctionnent tous les deux. Je ne l'ai pas fait récemment, mais lorsque je crée du café à partir de la source et que j'exécute les tests, cela touche définitivement le GPU. Je suis donc à peu près sûr que les pilotes / bibliothèques OpenCL / GPU fonctionnent.

Je suis sur Arch Linux - le noyau est leur LTS - linux-lts 4.9.52-1. Si cela compte, le "Bonaire" culmine à environ 1,7 TFLOPS en mode 32 bits et fait partie de la famille "Sea Island" des GPU AMD.

bin/computecpp_info 
********************************************************************************

ComputeCpp Info (CE 0.3.2)

********************************************************************************

Toolchain information:

GLIBC version: 2.26
GLIBCXX: 20160609
This version of libstdc++ is supported.

********************************************************************************


Device Info:

Discovered 1 devices matching:
  platform    : <any>
  device type : <any>

--------------------------------------------------------------------------------
Device 0:

  Device is supported                     : UNTESTED - Untested OS
  CL_DEVICE_NAME                          : Bonaire
  CL_DEVICE_VENDOR                        : Advanced Micro Devices, Inc.
  CL_DRIVER_VERSION                       : 2442.7
  CL_DEVICE_TYPE                          : CL_DEVICE_TYPE_GPU 

If you encounter problems when using any of these OpenCL devices, please consult
this website for known issues:
https://computecpp.codeplay.com/releases/v0.3.2/platform-support-notes

Est-ce que quelqu'un collecte les journaux de test ? Il indique que mon appareil n'a pas été testé, je vais donc le tester. ;-)

Impossible pour moi de compiler TensorFlow pour Sycl/OpenCL !

Configuration :
Ubuntu 16.04
Tensorflow r1.3
OpenCL 2.0
ComputeCpp CE 0.3.2 (computecpp_info OK)
Carte graphique Intel HD 620
Bazel 0.5.4

Instructions d'installation (version OpenCL Intel / ComputeCpp) :
https://software.intel.com/en-us/articles/opencl-drivers#philinux
https://www.codeplay.com/portal/03-30-17-setting-up-tensorflow-with-opencl-using-sycl

Erreur :

ERROR: /home/erwang/workspace/ia/tf_original/tensorflow/tensorflow/core/kernels/BUILD:1695:1: C++ compilation of rule '//tensorflow/core/kernels:adjust_contrast_op' failed (Exit 1)
In file included from tensorflow/core/kernels/adjust_contrast_op.cc:19:
In file included from ./tensorflow/core/kernels/adjust_contrast_op.h:18:
In file included from ./third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1:
In file included from external/eigen_archive/unsupported/Eigen/CXX11/Tensor:14:
In file included from external/eigen_archive/Eigen/Core:299:
In file included from external/local_config_sycl/crosstool/../sycl/include/SYCL/sycl.hpp:20:
In file included from external/local_config_sycl/crosstool/../sycl/include/SYCL/sycl_interface.h:54:
external/local_config_sycl/crosstool/../sycl/include/SYCL/multi_pointer.h:342:3: error: multiple overloads of 'global_ptr' instantiate to the same signature 'void (pointer_t)' (aka 'void (__attribute__((address_space(1))) float *)')

Entraîner des modèles sur mon CPU prend du temps, j'ai vraiment besoin d'une accélération OpenCL/GPU...

@ErwanGalline Nous sommes en train d'apporter des modifications à Eigen ( https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None ) qui résoudre le problème que vous voyez.

De plus, nous nous préparons à améliorer les performances en amont d'Eigen - c'est un peu délicat et nécessite une coordination avec @benoitsteiner pour éviter un flux de conflits de fusion - mais nous y arrivons.

Pour les utilisateurs d'AMD, je suggérerais d'essayer mon fork : https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu
Les instructions de configuration pour Ubuntu 16.04 sont disponibles ici : http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Tous les changements seront en amont de tensorflow après que les changements Eigen mentionnés précédemment soient en place.

J'espère que ça t'as aidé.

@lukeiwanski Votre fourche ne prend-elle en charge que le GPU AMD R9 Nano / AMD FirePro ?

@lukeiwanski Existe-t-il un cas de test que je peux utiliser pour vérifier que j'utilise le GPU ? Je peux le surveiller avec radeontop mais j'aimerais quelque chose qui utilise TensorFlow lui-même.

@ZixuanLiang non, pas seulement..
Nous testons actuellement sur AMD ( R9 380, R9 Nano, FirePro ). Nous savons que le GPU Intel expose certains bogues de pilote, mais des correctifs sont à venir. Et nous avons annoncé Renesas R-Car et nous nous attendons à ce que d'autres suivent.

Je crois que Xilinx prend en charge en amont triSYCL https://github.com/tensorflow/tensorflow/pull/12882 - donc FPG (?) - @keryell devrait en savoir plus à ce sujet

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test devrait être une vérification juste .. la sortie devrait ressembler à ceci :
INFO: From Testing //tensorflow/python/kernel_tests:basic_gpu_test: ==================== Test output for //tensorflow/python/kernel_tests:basic_gpu_test: 2017-10-05 10:53:52.727745: I tensorflow/core/platform/cpu_feature_guard.cc:137] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA 2017-10-05 10:53:53.059908: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Found following OpenCL devices: 2017-10-05 10:53:53.059926: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id: 0, type: GPU, name: Tonga, vendor: Advanced Micro Devices, Inc., profile: FULL_PROFILE .....

@lukeiwanski Merci je vais l'essayer sur AMD GPU

@lukeiwanski La construction et le test semblent fonctionner sur mon Bonaire. J'utilise Python 3.6, cependant, et les instructions utilisent Python 2.7. Dois-je utiliser 2.7 ou est-ce que 3.6 fonctionnera ?

@znmeb Suite à https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647, il semble que Python 3.6 devrait fonctionner - je ne l'ai pas essayé cependant

@lukeiwanski Est-ce une version de ComputeCpp qui peut construire TF pour le moment ?
J'ai essayé différentes versions entre 0.3.2 et 0.1.4 et aucune n'a fonctionné. Ils se sont tous retrouvés avec l'erreur "plusieurs surcharges de 'global_ptr' instanciées à la même signature".
Au fait, je ne trouve pas le fichier TensorDeviceSycl.h dans les sources TF, est-ce un fichier renommé ? Est-il possible d'appliquer le patch aux sources actuelles ?

Merci d'avance.

@eLvErDe ComputeCpp 0.3.2 peut construire : https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu

Upstream manque un correctif pour Eigen qui le corrige.. voir https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564

Une idée de comment injecter ce patch Eigen lors de la construction de bazel ? Peut-être devrions-nous tomber quelque part sur la version Eigen tgz pour obtenir la version corrigée?

Merci Adam.

https://github.com/lukeiwanski/tensorflow/commit/8468d65e87e083337f18616f75ac56d3296d6ab1

Ce commit serait-il suffisant pour le construire ?

oui, vous devriez être en mesure de sélectionner cela

Malheureusement, ce n'est clairement pas suffisant, voici quelques-uns des prochains échecs de construction :

external/eigen_archive/Eigen/src/Core/util/BlasUtil.h:63:63: error: no type named 'ReturnType' in 'Eigen::ScalarBinaryOpTraits<cl::sycl::vec<float, 4>, std::complex<float>, Eigen::internal::scalar_product_op<cl::sycl::vec<float, 4>, std::complex<float> > >'
  typedef typename ScalarBinaryOpTraits<LhsScalar,RhsScalar>::ReturnType Scalar;
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~

external/eigen_archive/Eigen/src/Core/util/BlasUtil.h:69:34: error: invalid operands to binary expression ('const cl::sycl::vec<float, 4>' and 'const std::complex<float>')
  { return conj_if<ConjLhs>()(x) *  conj_if<ConjRhs>()(y); }
           ~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~

@eLvErDe il y a peu de commits que vous devez appliquer pour le faire compiler.
Je suggérerais d'utiliser l'astuce de dev/amd_gpu ou si vous ne voulez pas changer votre branche actuelle... vous pouvez y fusionner dev/amd_gpu.

En fait, je travaille sur mon paquet Debian/Ubuntu non officiel, donc j'essaie de rester proche de la version officielle 1.3.1. Je peux vivre sans support OpenCL mais je devrais être prêt à l'activer dès qu'il sera correctement supporté. Je mettrai peut-être à jour les packages de votre branche à des fins de test, mais cela suffit pour aujourd'hui ;)

J'ai une dizaine de variétés différentes de GPU AMD dans mes plates-formes minières. (de 7970 à RX 480 sous ubuntu 16.04 et amdgpu-pro). Faites-moi savoir si je peux contribuer en testant quoi que ce soit.

Faites-moi savoir si je peux contribuer en testant quoi que ce soit.
Que diriez-vous de https://github.com/ROCmSoftwarePlatform/hipCaffe
https://github.com/ROCmSoftwarePlatform/hipeigen

Le mardi 17 octobre 2017 à 10 h 54, slundell [email protected] a écrit :

J'ai une dizaine de variétés différentes de GPU AMD dans mes plates-formes minières. (à partir de
7970 à RX 480 exécutant Ubuntu 16.04 et amdgpu-pro). Faites-moi savoir si je peux
contribuer en testant n'importe quoi.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski Votre fork prendra-t-il également en charge les GPU AMD sur macOS ?

Salut,
Je construisais des API tensorflow sur Ubuntu16.04 x64 pour mon appareil Android avec GPU (Mali-T720) activé,

Informations sur mon système d'exploitation :
Ubuntu 16.04 x64
GPU de l'ordinateur : NVIDIA 1080Ti
CUDA 8.0
CUDNN 5.1 (bien que je n'utilise pas cuda ou cudnn pour la construction)
bazel 0.5.2
ComputeCpp CE 0.3.2

mon build.sh est:
'
bazel build -c opt --config=sycl //tensorflow/contrib/android:libtensorflow_cc.so --cxxopt="-
std=c++11" --cxxopt="-DTENSORFLOW_DISABLE_META" --verbose_failures --
crosstool_top=//external:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --
processeur = armeabi-v7a
'
avant construction. J'exporte LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, construire sans ' --config=sycl ' va bien et j'ai obtenu le bon libtensorflow_cc.so, mais avec ' --config=sycl ', le résultat final s'est avéré manquant -lComputeCpp sans aucun autre erreurs de compilation

Journal complet comme celui-ci :

ERREUR : /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1 : la liaison de la règle '//tensorflow/contrib/android:libtensorflow.so' a échoué : link_dynamic_library.sh a échoué : erreur lors de l'exécution de la commande
(cd /home/e0024/.cache/bazel/_bazel_e0024/783dad02ec856015f56356584726dd10/execroot/org_tensorflow && \
exec env - \
COMPUTECPP_TOOLKIT_PATH=/home/e0024/workspace/source/computeCppForSYCL1.2 \
HOST_CXX_COMPILER=/usr/bin/g++ \
HOST_C_COMPILER=/usr/bin/gcc \
LD_LIBRARY_PATH=/home/e0024/workspace/source/computeCppForSYCL1.2/lib:/home/e0024/workspace/caffe/build/lib:/home/e0024/workspace/cudnn/lib64 :\
CHEMIN=/home/e0024/bin:/home/e0024/.local/bin:/home/e0024/workspace/Anaconda2/bin:/opt/cuda:/home/e0024/workspace/source/protoc-3.3.0- linux-x86_64/bin:/home/e0024/workspace/bazel/output:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ jeux:/usr/local/jeux:/snap/bin\
PWD=/proc/self/cwd \
PYTHON_BIN_PATH=/home/e0024/workspace/Anaconda2/bin/python\
PYTHON_LIB_PATH=/home/e0024/workspace/Anaconda2/lib/python2.7/site-packages \
TF_NEED_CUDA=0 \
TF_NEED_OPENCL=1 \
external/bazel_tools/tools/cpp/link_dynamic_library.sh non ignoré ignoré ignoré external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -shared -o bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/contrib/android/libtensorflow.so '-Wl,-rpath,$ORIGIN/../../../ _solib_armeabi-V7A / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib '-Lbazel-out / bras-linux-androideabi-4,9-V7A-gnu-libstdcpp-opt / bin / _solib_armeabi-V7A / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib -Wl, Bazel-out / bras -whole-archives -linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/c/libc_api.a -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi- 4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu -libstdcpp-opt/bin/tensorflow/core/kernels/libandr oid_tensorflow_kernels.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib_lite.lo -Wl ,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libprotos_all_cc.a -Wl,-no-whole -archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf.a -Wl,-no-whole-archive -Wl, -archive entière bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf_lite.a -Wl,-no-whole-archive -lComputeCpp external/androidndk/ndk/ sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libsupc++.a -landroid -llog -lm -z defs -s -Wl,--gc-sections '-Wl,-soname=libtensorflow.so' -Wl,--version-script tensorflow/c/version_script.lds -lz -static-libgcc - pas de préfixes canoniques '-march=armv7-a' -Wl,--fix-cortex-a8 '--sysroot=external/androidndk/ndk/platforms/android-14/arch-arm'): com.google.devtools.build.lib.shell.BadExitStatusException : processus terminé avec statut 1.
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld : avertissement : ignorer bazel-out incompatible/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/_solib_armeabi-v7a/_U@local_Uconfig_Usycl_S_Sycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib/libComputeCpp.so lors de la recherche pour ComputeCpp
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld : erreur : impossible de trouver -lComputeCpp
collect2 : erreur : ld a renvoyé 1 état de sortie
Cible //tensorflow/contrib/android:libtensorflow.so n'a pas pu être construit
INFO : Temps écoulé : 617.736s, Chemin critique : 54.66s

euh .... Je veux créer des API tensorflow dans l'arche du bras avec le GPU (Mali-T720) activé,
Apprécié si quelqu'un pouvait laisser des expériences ou des suggestions ici. Merci beaucoup.

Venez à mon discours la semaine prochaine à Arm TechCon, @ laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Vous aurez besoin de pilotes Mali avec prise en charge de SPIR-V, qui n'est probablement pas encore facilement disponible. Et vous aurez besoin d'un environnement d'exécution ComputeCpp pour Android avec prise en charge du processeur Arm et de la prise en charge de SPIR-V, qui n'est pas non plus disponible (encore). Donc, vous devrez être juste un peu patient.

Nous (Vertex.AI) venons d'ouvrir PlaidML, notre pile d'apprentissage en profondeur avec prise en charge de l'exécution de Keras sur OpenCL. Le support de TensorFlow arrive, une aide là-bas serait la bienvenue. Et oui, le support Mac est en route (également Windows). http://vertex.ai/blog/announcing-plaidml @ggaabe

@choongng Je voulais essayer mais j'ai échoué.
pip search plaidml retourne

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Mais pip install plaidml ou pip install plaidml==0.1.0rc3
Retour

Could not find a version that satisfies the requirement plaidml (from versions: )
No matching distribution found for plaidml

@hy9be Je pense qu'il serait plus approprié de créer un problème dans le référentiel plaidml plutôt qu'ici, car ce problème concerne la prise en charge d'OpenCL dans tensorflow. De plus, en consultant les instructions d'installation, votre commande pip install peut être incorrecte.

Merci @andrewrichards pour votre attention et votre discours de séance.

Mais pour l'instant pour moi (un étudiant diplômé), pour créer une application utilisant Tensorflow sur un appareil Android et que le GPU (Mali-T720) soit activé, ce qui est nécessaire pour obtenir le pilote Mali avec le support SPIP-V et l'exécution ComputeCpp pour Android avec Arm CPU prise en charge et prise en charge de SPIR-V.

Depuis que j'ai téléchargé ComputeCpp (Ubuntu16.04 x64 avec bin/ doc/ include/ lib/) sur la page d'accueil de CodePlay, hier j'ai exécuté :
bazel build -c opt --config=sycl //tensorflow/contrib/android:libtensorflow_cc.so --cxxopt="-std=c++11" --cxxopt="-DTENSORFLOW_DISABLE_META" --verbose_failures --crosstool_top=//external:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --cpu=armeabi-v7a
les erreurs ont dit libComputeCpp.so incompatible , donc je considère que j'ai peut-être besoin de ComputeCpp pour Android avec le support du processeur Arm et le support SPIR-V, mais je n'ai trouvé aucun code source pour construire un ComputeCpp Android, il n'y a que des exemples sur github.

Et vous avez dit que ComputeCpp pour Android n'est plus disponible, il est donc prévu de prendre en charge un appareil Android ou comment puis-je l'obtenir s'il est pris en charge.

Pour les utilisateurs AMD GPU et Linux, AMD a récemment publié le port HIP de tensorflow ici . Vous pourriez être intéressé.

Je ne l'ai pas testé par contre.

Je peux le tester - restez à l'écoute. On dirait qu'il échoue CI cependant.

Effectivement c'est raté. Encore à un stade précoce, je suppose.

Je l'ai testé, j'ai immédiatement obtenu une erreur de segmentation dans l'exemple MNIST.
Je ne sais pas ce que je fais de mal ici.

$ python ./convolutional.py 
I tensorflow/stream_executor/dso_loader.cc:130] Couldn't open CUDA library libhipblas.so. LD_LIBRARY_PATH: :/home/masa/project/rendering/RadeonProRender-Baikal/Bin/Release/x64:/usr/local/lib64:/opt/CodeXL_2.5-25:/usr/lib/x86_64-linux-gnu/:/opt/CodeXL_2.5-25/RuntimeLibs/QT/
I tensorflow/stream_executor/cuda/cuda_blas.cc:2305] Unable to load HIPBLAS DSO.
I tensorflow/stream_executor/dso_loader.cc:130] Couldn't open CUDA library libhipfft.so. LD_LIBRARY_PATH: :/home/masa/project/rendering/RadeonProRender-Baikal/Bin/Release/x64:/usr/local/lib64:/opt/CodeXL_2.5-25:/usr/lib/x86_64-linux-gnu/:/opt/CodeXL_2.5-25/RuntimeLibs/QT/
I tensorflow/stream_executor/cuda/cuda_fft.cc:344] Unable to load cuFFT DSO.
I tensorflow/stream_executor/dso_loader.cc:139] successfully opened CUDA library libhip_hcc.so locally
I tensorflow/stream_executor/dso_loader.cc:130] Couldn't open CUDA library libhiprng.so. LD_LIBRARY_PATH: :/home/masa/project/rendering/RadeonProRender-Baikal/Bin/Release/x64:/usr/local/lib64:/opt/CodeXL_2.5-25:/usr/lib/x86_64-linux-gnu/:/opt/CodeXL_2.5-25/RuntimeLibs/QT/
I tensorflow/stream_executor/cuda/cuda_rng.cc:338] Unable to load cuRAND DSO.
I tensorflow/stream_executor/dso_loader.cc:139] successfully opened CUDA library libMIOpen.so locally
Extracting data/train-images-idx3-ubyte.gz
Extracting data/train-labels-idx1-ubyte.gz
Extracting data/t10k-images-idx3-ubyte.gz
Extracting data/t10k-labels-idx1-ubyte.gz
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE3 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use FMA instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/stream_executor/cuda/cuda_driver.cc:633] creating context when one is currently active; existing: 0x7f94fa357e90
I tensorflow/core/common_runtime/gpu/gpu_device.cc:892] Found device 0 with properties: 
name: Fiji [Radeon R9 FURY / NANO Series]
major: 2 minor: 0 memoryClockRate (GHz) 1
pciBusID 1����
Total memory: 4.00GiB
Free memory: 3.75GiB
I tensorflow/core/common_runtime/gpu/gpu_device.cc:913] DMA: 0 
I tensorflow/core/common_runtime/gpu/gpu_device.cc:923] 0:   Y 
I tensorflow/core/common_runtime/gpu/gpu_device.cc:972] Creating TensorFlow device (/gpu:0) -> (device: 0, name: Fiji [Radeon R9 FURY / NANO Series], pci bus id: 1����)
Initialized!
I tensorflow/core/kernels/conv_ops.cc:604] running auto-tune for Convolve
Invoking clang-ocl on "/tmp/miopen-MIOpenUtilKernels.cl-c377-1df5-8b6a-884c/MIOpenUtilKernels.cl"
/opt/rocm/bin/clang-ocl -DNUM_CH_PER_WG=1 -DNUM_IM_BLKS_X=1 -DNUM_IM_BLKS=4 -DLOCAL_MEM_SIZE=432 -DSTRIDE_GT_1=0 -DTILE_SZ_X=32 -DTILE_SZ_Y=8 -DUSE_IM_OFF_GUARD=1 -mcpu=gfx803 -Wno-everything MIOpenUtilKernels.cl -o /tmp/miopen-MIOpenUtilKernels.cl-c377-1df5-8b6a-884c/MIOpenUtilKernels.cl.o
writing gemm kernel to "/tmp/miopen-tinygemm.cl-836e-c4d4-abd3-b292/tinygemm.cl"
Invoking clang-ocl on "/tmp/miopen-tinygemm.cl-836e-c4d4-abd3-b292/tinygemm.cl"
/opt/rocm/bin/clang-ocl -mcpu=gfx803 -Wno-everything tinygemm.cl -o /tmp/miopen-tinygemm.cl-836e-c4d4-abd3-b292/tinygemm.cl.o
GCN assember path: /opt/rocm/opencl/bin/x86_64/clang
Arugment: --version 
Invoking clang-ocl on "/tmp/miopen-MIOpenConvDirUniC.cl-f5fc-85f4-7079-a024/MIOpenConvDirUniC.cl"
/opt/rocm/bin/clang-ocl -DMLO_HW_WAVE_SZ=64 -DMLO_DIR_FORWARD=1 -DMLO_FILTER_SIZE0=5 -DMLO_FILTER_SIZE1=5 -DMLO_FILTER_PAD0=2 -DMLO_FILTER_PAD1=2 -DMLO_N_OUTPUTS=32 -DMLO_N_INPUTS=1 -DMLO_BATCH_SZ=64 -DMLO_OUT_WIDTH=28 -DMLO_OUT_HEIGHT=28 -DMLO_OUT_BATCH_STRIDE=25088 -DMLO_OUT_CHANNEL_STRIDE=784 -DMLO_OUT_STRIDE=28 -DMLO_IN_WIDTH=28 -DMLO_IN_HEIGHT=28 -DMLO_IN_BATCH_STRIDE=784 -DMLO_IN_CHANNEL_STRIDE=784 -DMLO_IN_STRIDE=28 -DMLO_IN_TILE0=28 -DMLO_IN_TILE1=8 -DMLO_OUT_TILE0=28 -DMLO_OUT_TILE1=8 -DMLO_GRP_TILE0=16 -DMLO_GRP_TILE1=8 -DMLO_ACTIVE_ALUS=112 -DMLO_N_ALUTILES_PERSTACK=2 -DMLO_OUT_PIX_TILE0=2 -DMLO_OUT_PIX_TILE1=2 -DMLO_N_STACKS=1 -DMLO_N_OUT_TILES=8 -DMLO_N_OUT_TILES_PERSTACK=16 -DMLO_N_IN_TILES_PERSTACK=1 -DMLO_N_READ_PROCS=128 -DMLO_CONV_BIAS=0 -DMLO_ALU_VTILE0=14 -DMLO_ALU_VTILE1=4 -mcpu=gfx803 -Wno-everything MIOpenConvDirUniC.cl -o /tmp/miopen-MIOpenConvDirUniC.cl-f5fc-85f4-7079-a024/MIOpenConvDirUniC.cl.o
Invoking clang-ocl on "/tmp/miopen-MIOpenConvFFT.cl-2fbf-2ba2-0088-ebfc/MIOpenConvFFT.cl"
/opt/rocm/bin/clang-ocl -DCFF_TRANSP_WT_MOD16=1 -DCFF_CGEMM_CHOICE_0=1 -DCFF_IMG_SZ_28_28 -DCFF_IMG_H=28 -DCFF_IMG_W=28 -DCFF_BATCH=64 -DCFF_NFILTER=32 -DCFF_CHANNELS=1 -DCFF_HALFW=1148928 -mcpu=gfx803 -Wno-everything MIOpenConvFFT.cl -o /tmp/miopen-MIOpenConvFFT.cl-2fbf-2ba2-0088-ebfc/MIOpenConvFFT.cl.o
Segmentation fault (core dumped)

@masahi - assurez-vous que la base rocm 1.6.4 est installée.

@bensander Merci, je vais mettre à jour.

@bensander Autre chose dont j'ai besoin de la pile AMD ? Tout ce que j'ai maintenant est la bibliothèque opencl propriétaire d'AMD qui utilise le pilote open source "amdgpu".

@masahi - si vous installez le rocm et le rocm-libs (c'est-à-dire "apt-get install rocm rocm-libs") cela devrait être tout ce dont vous avez besoin. Le rocm_docs du dépôt contient des instructions complètes, y compris les résultats attendus.

@bensander comment savoir si j'exécute correctement rocm 1.6.4 (et non 1.6.3) ?

@masahi juste une supposition : vous devriez poser la question sur un endroit plus lié à votre problème, comme le projet AMD ou RoCM plutôt qu'ici...

@keryell c'est vrai, je m'éloigne du sujet. Je m'arrête ici.
Quoi qu'il en soit, je ne pouvais pas faire fonctionner hiptensorflow sur mon système. J'essaierai plus tard avec une installation propre d'Ubuntu.

@masahi - ouvrez simplement un problème là-bas et nous vous aiderons à vous installer.

Salut, je veux juste mentionner que j'ai pu faire fonctionner hiptensorflow, grâce à @bensander et à d'autres personnes chez AMD. Je peux exécuter tous les exemples dans leur guide de démarrage rapide.

Merci

Pour ceux qui veulent essayer TensorFlow sur du matériel AMD à l'aide de ROCm, j'ai écrit un blog décrivant comment exécuter des ordinateurs portables Fast.ai à l'aide d'AMD Fury Nano.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 j'ai hâte !

ROCm 1.7 est en route, avec ce qui semble être un bon support Tensorflow !

https://www.phoronix.com/scan.php?page=news_item&px=AMD-ROCm-1.7-Released

Port Tensorflow vers GPU AMD :
https://github.com/ROCmSoftwarePlatform/hiptensorflow/blob/hip/README.ROCm.md

Ça marche bien pour moi. Mon paramétrage matériel :
Processeur graphique : AMD Radeon RX 480
Processeur : Intel Xeon 2603 v3
Mo : supermicro x10srl-f

La clé est la carte mère et le processeur doivent prendre en charge PCIe v3

Ses performances sont similaires à Nvidia 980Ti

Je ne peux même pas faire fonctionner les pilotes AMD "supportés" sur mon installation Ubuntu 16.04 LTS "supportée". Obsolescence planifiée?

znmeb, quel est votre GPU AMD ? Si vous avez deux GPU, désactivez celui qui n'est pas pris en charge dans le BIOS.

Impossible de lire tout le fil... quel est l'état actuel de tensorflow sur OpenCL sur MacOS (sierra +) ? Plus précisément, j'ai un GPU Intell Iris et j'espérais pouvoir le construire à partir de la source Tf + Open CL.
De plus, tf corrainder semble bien fonctionner, à la version 1.2.

@ varun19299 FWIW il existe un SDK Intel pour OpenCL - je l'ai sur mon ancien ordinateur portable Sandy Bridge mais je suis sûr que cela fonctionnera sur votre machine. https://software.intel.com/en-us/intel-opencl

Est-ce actuellement dans un état utilisable sur des systèmes Linux non-ubuntu ? La page de la feuille de route renvoie simplement ici.

@pfc Qu'est -ce qui est actuellement utilisable sur Linux non-Ubuntu ? TensorFlow utilisant OpenCL en général ? Ou TensorFlow utilisant OpenCL sur un GPU AMD ? Je supposerai ce dernier, car c'est la seule raison pour laquelle vous voudriez exécuter TensorFlow en utilisant OpenCL. Pour un GPU NVidia, vous utiliseriez les pilotes / bibliothèques NVidia et pour le processeur uniquement, il n'y a rien à gagner d'OpenCL.

Je l'ai fait travailler il y a quelques semaines sur Arch Linux, en utilisant la bibliothèque propriétaire ComputeCpp SYCL et un GPU AMD "Bonaire" (architecture Sea Islands). Il y a une nouvelle version de ComputeCpp que je dois tester mais je suppose que cela fonctionnera.

Il s'avère que les bibliothèques propriétaires AMDGPU Pro dont vous avez besoin pour que cela fonctionne ne fonctionnent pas sur Ubuntu 16.04.3. La mise à niveau de 16.04.2 a introduit un noyau Linux et un serveur X plus récents, et AMD n'a pas encore livré quelque chose qui fonctionne dessus. Voir http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-Compatibility-Advisory-with-Ubuntu-16.04.2-and-16.04.3.aspx pour les détails. Je n'ai pas pu faire fonctionner AMD OpenCL sur Ubuntu.

Il existe une version AMD expérimentale de TensorFlow qui utilise un compilateur pour traduire le code CUDA en code OpenCL, mais je ne l'ai pas testé non plus. En l'absence d'un pilote pris en charge, il est inutile.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs est le moyen officiellement pris en charge pour exécuter le flux tenseur sur le matériel AMD.

@bensander Le runtime ROCm fonctionne-t-il sur Ubuntu 16.04.3 ? Je n'ai pas réussi à le faire fonctionner.

PS : Avez-vous une idée si/quand la configuration AMDGPU-Pro fonctionnera sur Ubuntu 16.04.3 ? J'en ai besoin pour un autre projet.

Hmm, je ne m'amuse pas (et je ne m'amuserais pas) avec Ubuntu n'importe où, mais j'ai un CentOS 7 avec repos et une GTX1080TI, exécutant le noyau 4.14.x et le dernier pilote bêta Nvidia, donc je pourrais aider à le tester là-bas à un moment donné aujourd'hui si cela aide?

--
Sam Mc Leod

Le 7 décembre 2017, à 07h28, M. Edward (Ed) Borasky [email protected] a écrit :

@bensander Le runtime ROCm fonctionne-t-il sur Ubuntu 16.04.3 ? Je n'ai pas réussi à le faire fonctionner.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@sammcj Pourquoi exécuteriez-vous un GPU NVidia avec OpenCL alors qu'il existe de très bonnes bibliothèques CUDA pour cela?

Juste pour aider à le tester pour vous!

Pas de soucis si vous n'avez pas besoin d'un test manuel, j'ai juste pensé que je proposerais. Je n'ai même pas essayé cette machine avec cuda TBH, je ne l'ai essayé que sur MacOS où je ne peux pas utiliser OpenCL via Docker pour le moment.

--
Sam Mc Leod

Le 7 décembre 2017, à 08h16, M. Edward (Ed) Borasky [email protected] a écrit :

@sammcj Pourquoi exécuteriez-vous un GPU NVidia avec OpenCL alors qu'il existe de très bonnes bibliothèques CUDA pour cela?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@znmeb J'allais essayer ComputeCpp SYCL mais ils ne fournissent que le programme d'installation d'ubuntu (je suis également sur arch) et le script d'installation aur est cassé. Il est bon d'entendre que cela peut fonctionner. Si je suis assez désespéré, je peux essayer.
@bensander Cela ressemble exactement à ce dont j'ai besoin pour obtenir le support ADM, mais je suis inquiet du fait que ce code n'a pas été rétroporté sur TF et que son code a été mis à jour pour la dernière fois il y a plus de 2 mois étant donné que mon code cible TF 1.4. 0
Il semble que pour le moment, tensorflow vous lie essentiellement à Nvidia, du moins pour nous, les programmeurs "mortels". Le manque de documentation/feuille de route mise à jour n'aide pas. Cela ne me dérangerait pas d'aider de toutes les manières possibles, mais j'ai eu peu de succès pour que les choses fonctionnent jusqu'à présent.

@pfc J'ai fait fonctionner le SYCL ComputeCpp sur Arch - il y avait une archive binaire sur leur site Web quand je l'ai fait.

Dans cette news sur la sortie de SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
ça dit :
_La nouvelle spécification intègre l'expérience significative acquise à partir de trois implémentations distinctes et les commentaires des développeurs de frameworks d'apprentissage automatique tels que TensorFlow, qui prend désormais en charge SYCL aux côtés du back-end d'origine de l'accélérateur CUDA._

Cela signifie-t-il qu'il est désormais possible d'exécuter "facilement" TensorFlow sur un GPU AMD prenant en charge OpenCL 1.2 sur lequel SYCL est construit ?

"Facilement" dans le sens où certains logiciels/pilotes/bibliothèques de bas niveau pour le matériel AMD se trouvent là où se trouvent la plupart des éléments défectueux, pas dans le matériel ou TensorFlow ou les normes OpenCL ou SYCL. ;-) Si vous avez des pilotes GPU AMD fonctionnels et des bibliothèques OpenCL fonctionnelles, vous avez TensorFlow sur les GPU AMD.

Ma configuration de travail pour un AMD Bonaire (architecture Sea Islands):

Arch Linux avec le module de noyau amdgpu chargé et le module de noyau radeon sur liste noire
Le package Arch User Repository opencl-amd
La bibliothèque ComputeCpp
TensorFlow construit à partir de la source sur mon poste de travail en utilisant le fork de @lukeiwanski :

https://github.com/tensorflow/tensorflow/issues/22#issuecomment-334154564

Je suis un peu surpris par ce que vous avez dit "Si vous avez des pilotes de GPU AMD fonctionnels et des bibliothèques OpenCL fonctionnelles, vous avez TensorFlow sur les GPU AMD". J'avais compris que la version "officielle" de TensorFlow ne fonctionnait pas sur OpenCL (CUDA uniquement). Il semble que je me sois embrouillé.
J'étais assez content de trouver le projet PlaidML qui permet au moins à du code Keras de s'exécuter sur mon iMac avec AMD Redeon HD 6970. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) AFAIK vous avez également essayé ce cadre.
Je vais essayer d'exécuter TensorFlow sur Ubuntu VirtualBox où Tensorflow est déjà en cours d'exécution (CPU uniquement).

@PALYGAP Je ne pense pas que VirtualBox exporte OpenCL d'un hôte Mac vers un invité Linux, et Ubuntu 16.04.3 ne fonctionne pas pour le moment. Je n'ai pas de Mac donc je n'ai aucun moyen de tester les choses.

Quelqu'un a-t-il essayé avec succès de travailler TensorFlow sur AMD via OpenCL et a-t-il réussi?.

@mohnkhan J'ai le fork @lukeiwanski qui fonctionne (Arch Linux) - voir https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . J'attends d'autres travaux AMDGPU-Pro avant de publier un article de blog - voir https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Merci pour les contributions

@mohnkhan BTW, AMD construit une voie alternative entièrement open source - traduisant le code CUDA en code OpenCL avec une chaîne d'outils de compilateur. Je ne sais pas quel est le statut de cela pour les anciennes cartes comme la mienne.

Si vous allez écrire un article, je suppose que cela ne ferait pas de mal d'expliquer également (il a fallu 3 heures pour obtenir l'image complète):

• TF a en fait un backend SYCL 1.2. Non *réel* opencl.
• à son tour, vous avez deux implémentations de la norme (trisycl a l' air cool, mais c'est limité atm)
• Au final, ComputeCpp 'hooks' SPIR /SPIR-V (en plus de PTX, mais c'est vraiment une autre histoire )

Et c'est ce qui vous amène finalement directement à votre putain d'OpenCL 1.2 (avec cl_khr_spir ext)

HIP est à la place un autre backend, se trouve en face de SYCL, et cible uniquement et exclusivement ROCm (ou bien, lol, même à son tour cuda si vous avez un gpu nvidia .. mais c'est encore une autre histoire)

AMD construit une voie alternative entièrement open source - traduisant le code CUDA en code OpenCL avec une chaîne d'outils de compilateur.

Nan. Vous parlez de HIP, et... c'est en fait ça, ce que vous finissez par convertir votre code en . Ce qui n'est pas OpenCL.
HIP tourne alors sur ROCm comme je le disais...
ROCm qui est également ce qui exécute OpenCL pour vous (sur les cartes prises en charge ), mais s'il vous plaît, j'insisterais sur le fait que les relations ne sont transmises qu'à partir de ROCm, jamais "intra-sous-couches"

Ce à quoi vous pensez peut-être pourrait être la coriandre .

Je ne sais pas quel est le statut de cela pour les anciennes cartes comme la mienne.

En résumé ici : pilote AMDGPU-PRO à part entière, amdgpu-pro-opencl-only comme vous le faites maintenant... Ou continuer à attendre jusqu'à la fin de la décennie pour que quelqu'un rende enfin le trèfle utilisable.

Aussi, fglrx... Mais si c'est difficile à recommander pour les cartes pré-gcn, je suppose qu'il vaut mieux jeter un voile dessus.

@mirh

1. Je ne suis pas concerné par les cartes pré-GCN. Le mien est un Sea Islands et je ne prévois pas d'acquérir quelque chose de plus ancien. Là encore, je ne prévois pas non plus d'acquérir un autre GPU AMD. ;-)
2. Je ne sais pas si ROCm fonctionnera sur mon poste de travail - il n'y a pas de testeur de matériel open source qui puisse me donner une réponse par oui ou par non. J'ai ouvert un sujet pour cela et je n'ai reçu aucune réponse.
3. SPIR-V est une cible de compilateur - j'y ai jeté un coup d'œil et j'ai levé la main, n'ayant pas de budget pour embaucher un compilateur.

Donc, cela laisse SYCL ... ou vomir mes deux autres mains et tout faire avec Keras, qui a TensorFlow, Theano (qui se bloque), CNTK ou PlaidML. D'un point de vue purement économique de l'ingénierie, Keras / PlaidML est un grand gagnant à condition que j'obtienne TensorBoard d'une manière ou d'une autre.

@mirh merci pour le bon résumé avec tous les liens. Je pense que tu n'as pas perdu tes 3 heures... :-)

Je ne sais pas si ROCm fonctionnera sur mon poste de travail - il n'y a pas de testeur de matériel open source qui puisse me donner une réponse par oui ou par non. J'ai ouvert un sujet pour cela et je n'ai reçu aucune réponse.

Comme je vous l'ai dit plusieurs fois , non ça ne marchera pas.
Les gpus pré GCN de 3e génération manquent simplement du matériel pour que ROCm fonctionne ou même fonctionne du tout.

SPIR(-V).. Je ne sais pas de quoi vous parlez. Ce n'est pas à toi de t'en soucier. Computecpp le fait à partir de "commandes" SYCL, puis tout est affaire de pilote (opencl).

Vous avez ce que j'appelle provisoirement amdgpu-pro-opencl-only, et je ne sais pas quel est le problème alors.
EDIT: ce serait aussi cool d'avoir une sorte d'ETA pour que le code de Luke atterrisse

@znmeb et tout le monde

J'ai (L)Ubuntu 17.10 incl. le noyau 4.14.x et les parties de la bibliothèque OpenCL du pilote AMDGPU Pro 17.40 s'exécutent et peuvent exécuter des applications OpenCL comme clinfo ou Boinc (par exemple Engima @Home , Milkyway@Home) sans problème sur mon APU AMD A12-9800E.

Je peux également compiler et utiliser avec succès la version CPU de tensorflow (actuellement version 1.4.1). Mais je ne parviens pas à compiler avec succès la version OpenCL de tensorflow. J'utilise computecpp 0.5 (l'actuel que je peux télécharger sans avoir besoin de m'inscrire) avec vanilla tensorflow 1.4.1 et avec la branche "dev/amd_gpu" du fork de @lukeiwanski .

Donc, s'il vous plaît, quelqu'un qui a compilé avec succès la version OpenCL de tensorflow pourrait-il fournir des informations sur la version de la bibliothèque computecpp et la branche de quel git tensorflow qu'il utilise?

Merci

@AlphasCodes Je n'ai rien en cours d'exécution sur Ubuntu - tous mes éléments de travail sont sur Arch. J'ai la machine à double démarrage avec Ubuntu 16.04.3 mais les bibliothèques propriétaires d'AMD ne fonctionnent pas encore là-bas. Pour autant que je sache, ils ne sont pas pris en charge sur 17.10, mais si la pièce OpenCL fonctionne sur 17.10, je pourrais ajouter un troisième démarrage - j'ai beaucoup d'espace disque. ;-)

Quel genre d'erreurs obtenez-vous ? S'il s'agit d'erreurs de construction, vous pourriez avoir une incompatibilité Bazel. Bazel avance constamment comme TensorFlow et parfois l'un devance l'autre.

Qu'est-ce que tu veux dire par "non pris en charge" ?

Ceci .
Quant à Ubuntu, seul 16.04.3 est censé être pris en charge (au moins officiellement, étant donné que même Arch peut le faire fonctionner après un peu de magie de script)
EDIT : le pilote AMDGPU-PRO "complet" nécessite le noyau 4.9, c'était probablement le problème

Si quelqu'un s'en soucie, le port du pilote AMDGPU-Pro 17.40 vers Arch est en cours et est très actif sur GitHub à https://github.com/corngood/archlinux-amdgpu/pull/54 ,

Nous devrions vraiment fermer ce problème, car, comme l'a souligné @mirh , TensorFlow utilise SYCL, pas OpenCL. Peut-être devrions-nous en ouvrir un autre, "TensorFlow sur les cartes AMD" ??

Non, c'est totalement légitime.
Vous voulez que tensorflow s'exécute éventuellement sur des appareils opencl, c'est le but. Légitime et fin.
Dire qu'il utilisait réellement SYCL n'était qu'une pinaille technique que j'ai faite, parce que tous ces acronymes de technologies magiquement aléatoires me rendaient fou.
EDIT : Je voudrais également remercier tous les gars de codeplay pour leur travail flagrant

Si vous voulez quelque chose de tout spécialement conçu pour amd, je vous recommande de vérifier leur hiptensorflow . ROCm uniquement cependant. Et s'il vous plaît, laissons de côté cet argument.

OK, je ne sais pas si j'ai assez de temps pour refaire la construction et fournir les erreurs de compilation jusqu'au week-end. Mais j'ai ajouté ma documentation existante à mon nouveau référentiel github.

Voir https://github.com/AlphasCodes/DeepLearning pour plus de détails (ma configuration matérielle/logicielle + configuration AMD OpenCL + configuration Tensorflow).

@mirh pour clarifier les "acronymes des technologies magiquement aléatoires [...] qui [vous] rendent fous":

Dans le domaine du groupe Khronos, OpenCL est l'API source non unique de bas niveau et SYCL est le langage embarqué spécifique au domaine (DSeL) C ++ à source unique de haut niveau. SYCL devrait être construit au-dessus d'OpenCL, donc par transitivité lorsque vous utilisez SYCL, vous utilisez souvent OpenCL.

Étant donné que TensorFlow utilise Eigen qui utilise une approche C++ à source unique avec CUDA à source unique, lorsqu'il a ensuite été porté sur OpenCL, SYCL a été choisi car c'est le moyen standard du groupe Khronos d'avoir un C++ à source unique .

Mais si vous pensez à CUDA, c'est encore plus subtil.

Presque tout le monde utilise la version à source unique de haut niveau de CUDA qui s'appelle en fait "CUDA Runtime API". Ceci est en quelque sorte similaire à SYCL.
Mais il existe en fait une version de bas niveau non source unique moins connue de CUDA qui s'appelle "CUDA Driver API", similaire à OpenCL, et utilisée par exemple par l'implémentation "CUDA Runtime API" elle-même.

Puisqu'il s'agit d'une sorte de FAQ, j'ai clarifié un peu https://en.wikipedia.org/wiki/SYCL et https://en.wikipedia.org/wiki/CUDA

ComputeCpp, qui est l'implémentation SYCL que vous utilisez avec TensorFlow, ne prend pas encore en charge Ubuntu 17.10. Vous devrez vous en tenir à Ubuntu 16.04 qui est le LTS actuel. Les instructions et pré-requis sont ici https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow

Soit dit en passant, la prise en charge d'OpenCL pour TensorFlow ne signifie pas uniquement la prise en charge des appareils AMD. L'intégration SYCL active également d'autres appareils OpenCL. Dans le cadre du travail que nous effectuons avec TensorFlow, la prise en charge des GPU ARM et Intel sera disponible lorsque les derniers pilotes de ces sociétés seront disponibles. Nous travaillons également pour permettre la prise en charge des processeurs d'accélérateur Renesas également pour la plate-forme R-Car.

@rodburns Merci ! Je travaille sur Arch Linux (noyau 4.14.4) avec la bibliothèque opencl-amd du Arch User Repository. La carte est une Bonaire (GCN 2.0). Je vais exécuter les tests sur cette page pour vérifier qu'il fait ce qu'il doit faire.

GCN 2e génération (alias 1.1) le cas échéant, 2.0 n'existe pas.
(devrait se baisser pour être si pédant)

SUCCÈS!

Les derniers commits de branche "dev/amd_gpu" dans @lukeiwanski fork ont ​​corrigé mon problème de compilation Tensorflow OpenCL. Je suppose que c'était les commits liés à SysCL 1.2.1.

J'ai compilé avec succès une version Tensorflow OpenCL et je peux l'utiliser. Voir mes documents de configuration Tensorflow pour plus de détails.

J'ai également ajouté une page de benchmarks où vous pouvez trouver des benchmarks de ma configuration sous différentes configurations Tensorflow (non optimisées pour le processeur, optimisées pour le processeur, OpenCL) à l'avenir.

La version 17.50 du pilote AMDGPU Pro fonctionne également pour moi. J'ai mis à jour le document de configuration AMD OpenCL associé.

Merci à tous les contributeurs.

J'ai fait quelques benchmarks et il semble que l'iGPU soit plus lent que les 4 threads CPU disponibles à l'exception du benchmark matmul_bench.py .

L'initialisation d'une exécution OpenCL Tensorflow est également beaucoup plus lente qu'une exécution OpenCL Tensorflow CPU uniquement. Quelque chose comme 5 secondes pour le CPU contre 1-2 minutes pour OpenCL.

Quelqu'un peut-il confirmer de tels résultats ?

OK, j'ai fait un peu plus de dépannage.

• j'ai utilisé l'exemple Tensorflow MNIST, voir le document Validate a Tensorflow Setup
• j'ai utilisé "sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info" pour vérifier/regarder l'horloge/le chargement de l'iGPU et "top" pour vérifier la charge du processeur
• la phase d'initialisation jusqu'à l'étape 0 a pris environ 6 minutes, la charge iGPU était d'environ 0%, l'horloge iGPU à 300 MHz (l'horloge minimale disponible) et l'utilisation du processeur du processus python était d'environ 200% (= 2 threads)
• à partir de l'étape 0, la charge de l'iGPU était d'environ 90 %, l'horloge de l'iGPU commutait toujours de 654 MHz - 720 MHz - 800 MHz - 900 MHz (horloge disponible maximale) et inversement, l'utilisation du processeur par le processus python était d'environ 100 % (= 1 CPU fil)

J'essaie toujours de compiler des choses sur Arch.

Ce que j'ai utilisé hier .
Après 14 heures (oui, ma patate est très lente) j'ai eu ce binaire , si vous voulez essayer.

J'ai essayé de comprendre ce qui se passait mais malheureusement je n'ai pas pu. J'apprécierais si quelqu'un qui connaît ce qui suit peut m'aider à me mettre au courant !

La plupart des discussions ci-dessus concernaient l'exécution de Tensorflow avec l'accélération OpenCL sur les puces AMD. Ai-je raison de dire cela? Si je veux obtenir un tensorflow accéléré par GPU en utilisant ma carte graphique intégrée (Intel HD 5000) qui prend en charge opencl, quelle devrait être mon approche?

Merci d'avance!

@znmeb Salut Ed, merci d'avoir répondu. J'ai téléchargé OpenCL et je l'exécute sur mon système. Mais ma question était - comment puis-je compiler tensorflow pour utiliser réellement les bibliothèques OpenCL ?

https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
Et surtout pour intel https://github.com/codeplaysoftware/computecpp-sdk/issues/78#issuecomment -352411192

@AlphaCodes Merci d'avoir publié vos résultats. En ce qui concerne le temps d'initialisation, la façon dont OpenCL fonctionne est que le code est compilé avant l'exécution, donc le temps de démarrage est le processus de compilation.

@brainwave Pour les appareils Intel, il existe un fil avec @mirh ici qui explique comment supprimer les restrictions concernant les appareils en cours d'exécution. Nous avons rencontré des problèmes avec les pilotes Intel, c'est pourquoi ces types de périphériques sont limités, mais nous espérons que des pilotes mis à jour seront bientôt disponibles pour les périphériques Intel qui améliorent la prise en charge. En attendant, vous pouvez recompiler TensorFlow avec la modification pour tester votre propre matériel Intel. Nous envisageons de supprimer les restrictions d'appareil dans la base de code.

@AlphasCodes Les gars, je m'excuse pour la question peut-être naïve, mais pourquoi cette version du GPU AMD est-elle uniquement? OpenCL n'est-il pas censé être standard ? Dois-je bien comprendre que cela ne fonctionnera pas sur mon Intel Carbon X1 avec les pilotes OpenCL 2.0 installés ?

Si vous lisez le problème qui a été lié deux fois, vous verrez qu'il n'y a rien à propos d'amd gpu.
Intel est actuellement exclu, mais cela n'a rien à voir avec le fait de vouloir forcer les utilisateurs, et il existe une solution de contournement temporaire - discutez-en le cas échéant.

Lorsque j'utilise la branche amd_gpu avec un cahier jupyter, il semble qu'il reste un fil. python utilise toujours 100% d'un processeur, même après la fin du calcul. Le redémarrage du noyau termine le thread perdu. Est-ce que quelqu'un d'autre vit cela?

@brainwave @unoexperto
Désolé, je ne peux pas aider avec Intel OpenCL car je n'ai que du matériel AMD OpenCL.

@desperadoduck
Je n'utilise pas encore jupyter. J'utilise un shell bash simple et un environnement Python 3 virtuel ( voir ma configuration Python 3 + Tensorflow ). Mais je n'arrive pas à reproduire le problème. Il n'y a pas d'utilisation du processeur par un processus python une fois le calcul terminé.

@rodburns
Merci pour l'information. Est-il possible d'accélérer le temps de compilation initial ? par exemple en utilisant tous les threads CPU disponibles au lieu de seulement 50 %.

@brainwave @rodburns
Pour le GPU Intel (Gen9) sous Linux, nous avons constaté des performances DNN nettement meilleures avec l'implémentation Beignet open source d'Intel par rapport à la source fermée lors de l'analyse comparative avec des réseaux de vision communs sur PlaidML. Beignet est également plus facile à installer, ce qui est agréable.

Prend-il en charge les graphiques intel hd615 (processeur de 7e génération) sur ubuntu17.10 ?

Le pilote opencl SRB5.0 pour linux64 fonctionne bien sur ubuntu17.10.

Et il n'a pas été mis à jour depuis longtemps :
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Pour l'amour de Dieu, ne pouvez-vous pas lire juste 2 (deux !) messages ci-dessus ?
Discutez du manque de support Intel GPU (ou AMD CPU) ici https://github.com/codeplaysoftware/computecpp-sdk/issues/78

@znmeb c'est un objectif d'utiliser pleinement diverses ressources informatiques (par exemple, processeur, processeur graphique, DSP, tout autre coprocesseur).
En fait, cela dépend du support des fournisseurs de matériel : pilote et système d'exploitation.
Comme je le sais, vous ne pouvez peut-être pas activer à la fois le GPU intel et le GPU nvida pour la vidéo en même temps, en raison de la limitation du pilote vidéo. (Vous pourrez peut-être basculer entre eux).
Cependant, opencl peut les utiliser en même temps. Ils sont tous les deux des "dispositifs" en elle.

@choongng C'est intéressant à savoir, nous avons fait du travail pour aider Beignet mais l'activité sur ce projet semble être restée un peu calme.

@znmeb Oui, n'importe quel GPU ne fonctionnera probablement pas beaucoup mieux sur un petit problème, content que vous fassiez des progrès cependant!

@unoexperto ComputeCpp avec TensorFlow peut être utilisé par tout matériel prenant en charge les instructions intermédiaires SPIR OpenCL qui incluent les GPU Intel, mais comme dans le fil ici , nous l'avons intentionnellement empêché de fonctionner car nous ne pensions pas que les pilotes actuels fonctionnaient pour le moment. . Vous pouvez supprimer cette restriction car il semble que certains utilisateurs l'ont fait fonctionner avec différents pilotes Intel. Nous travaillons également à l'activer pour les processeurs ARM et Renesas dotés de pilotes OpenCL.

@ sxpc722 Cela devrait alors fonctionner. Soit dit en passant, la nouvelle machine est Windows 10 et je ne prévois pas de la démarrer en double avec Linux tant que je n'y serai pas obligée ! J'en ai marre de chasser les bogues des pilotes et des bibliothèques pour les fournisseurs (en vous regardant, AMD). En fait, je peux mettre une partition Windows sur mon poste de travail pour la même raison AMD. ;-)

Cela fait 14 jours qu'il n'y a pas eu d'activité et ce problème a un responsable. Veuillez mettre à jour le libellé et/ou l'état en conséquence.

Les performances de Tensorflow AMD OpenCL sont très lentes selon mes tests. J'ai donc fait quelques tests de base avec un autre framework Deep Learning. Vous trouverez ma configuration et mes benchmarks sur ma page GitHub ici .

Longue histoire courte. L'autre framework Deep Learning est actuellement environ 10 fois plus rapide que Tensorflow AMD OpenCL.

@AlphasCodes @znmeb Je sais que l'équipe TF préfère garder le fil TF uniquement, nous sommes heureux d'héberger la conversation spécifique à PlaidML sur le projet PlaidML. Cela dit, nous espérons pouvoir éventuellement prendre en charge TensorFlow lui-même ainsi que les plates-formes non OpenCL (par exemple Apple's Metal pour iOS qui existe actuellement sous forme de prototype).

https://github.com/plaidml/plaidml

@choongng Merci pour les informations, j'ai modifié mon message en conséquence.

@znmeb L'iGPU AMD A12-9800E devrait être GCN v3.

La principale et unique raison pour laquelle je fais les benchmarks/tests est de trouver une réponse à ma question "Rester avec AMD ou passer à Nvidia pour mon aventure Deep Learning".

Et la réponse est. J'aime beaucoup l'approche open source d'AMD, mais je vais probablement passer à Nvidia en raison de 2 facteurs. Tout d'abord la pile logicielle de Deep Learning (par exemple Tensorflow) est beaucoup plus mature pour Nvidia. Deuxièmement, l'offre de carte graphique pour mes besoins très spécifiques (doit tenir dans un boîtier Dan A4 SFX et doit être très très silencieuse / presque silencieuse à pleine charge pendant des heures) est très limitée, voire inexistante du côté d'AMD.

Les GPU Intel sont-ils pris en charge ? Je pense que mon Iris Pro peut accélérer un peu l'entraînement séculaire.

Discutez du manque de prise en charge d'Intel GPU (ou AMD CPU) ici codeplaysoftware/computecpp-sdk#78

https://github.com/codeplaysoftware/computecpp-sdk/issues/82

J'essaie juste d'avoir une idée de l'état de ce problème. Ai-je raison de dire que ce dépôt :

https://github.com/lukeiwanski/tensorflow

...construit avec ComputeCpp, est-ce la meilleure option actuelle pour construire Tensorflow avec la prise en charge générale du GPU AMD ? Et si oui, y a-t-il des preuves de référence que cette version fournit une accélération par rapport au processeur ?

Cela dépend de ce que vous entendez par "prise en charge générale du GPU AMD". Si vous voulez dire de très vieux dGPU ou APU, je ne sais pas. Mais si vous avez un GCN plus récent (2e génération ou plus récent), hipTensorFlow (v1.0.1) fonctionnant sur ROCm fonctionnait plutôt bien.

@ briansp2020 Ah oui j'ai vu le travail d'AMD sur ROCm. Malheureusement, ils ne prennent en charge que Linux, et il ne semble même pas que la prise en charge d'un autre système d'exploitation figure sur leur feuille de route. J'espère quelque chose qui supporte Windows.

@mjmax Existe-t-il un package tensorflow accéléré par GPU disponible pour Windows? Je pensais que si vous vouliez un apprentissage en profondeur accéléré par GPU, Linux n'était qu'un choix. Si TensorFlow était porté sur OpenCL, cela faciliterait-il le portage sur Windows ? Je ne sais pas pourquoi TensorFlow n'est pas disponible sur Windows avec accélération GPU lorsque CUDA y est pris en charge.

Je suppose que c'est maintenant hors sujet, mais si quelqu'un connaît TensorFlow et/ou PyTorch pour Windows qui est accéléré par le GPU, j'aimerais aussi le savoir...

@ briansp2020 Pour autant que je sache, Tensorflow prend déjà en charge l'accélération GPU Nvidia sous Windows.

CL tensofrflow est déjà un gâchis sur linux, ne vous attendez pas à quoi que ce soit de sitôt.
Si vous voulez accélérer les choses là-bas, il n'y a que plaidML.
(et s'il vous plaît, nous sommes déjà à 500 commentaires.. essayons de ne poster que si vraiment, vraiment nécessaire)

@mirh OpenCL Caffe fonctionne sous Windows. Bien sûr, ce n'est pas TensorFlow en termes de fonctionnalités, mais assez solide pour les logiciels qui doivent être déployés partout.

Qu'en est-il du remplacement du port openCL par le port HIP soutenu par AMD ?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

Ha ha ! @LifeIsStrange La vie est très étrange en fait... Travaillez-vous pour l'équipe marketing HiP d'AMD ? :-)
Veuillez regarder le sujet de ce problème : "Support OpenCL".

Cela signifie qu'il s'agit de la norme Khronos https://en.wikipedia.org/wiki/OpenCL (et l'autre norme SYCL du groupe de travail OpenCL Khronos apparaît à la fin de la section "Aperçu").

Bien sûr, il y a un monde extérieur à cette question, mais il est... extérieur ! :-)

Merci d'essayer de ne pas augmenter inconsidérément l'entropie de l'univers en postant quelques posts au hasard sur cette discussion déjà trop longue... :-)
Ce commentaire s'applique à d'autres affiches ici, pas seulement à vous, d'ailleurs.
Il s'agit d'un problème GitHub pour résoudre un problème technique : faire fonctionner TensorFlow sur des appareils prenant en charge la norme OpenCL, et non une page FaceBook sur la façon dont les gens aiment ou n'aiment pas l'outil A ou B. :-)
Mais n'hésitez pas à envoyer des commits git liés à ce problème que nous pourrons examiner...

Il existe un fork de TensorFlow prenant en charge OpenCL https://github.com/hughperkins/tf-coriander

Et bien sûr le travail de @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

À mon humble avis, il est ridicule que la TF grand public n'ait toujours pas fusionné leur travail.

L'accent est-il mis ici sur le fait de le faire fonctionner comme lomg tel qu'il est OpenCL, ou de le faire fonctionner plus rapidement ? Je préférerais qu'il n'y ait pas de guerre sainte, mais que je me concentre sur son fonctionnement rapide sur plusieurs GPU. L'objectif de LifeIsStrange est de le faire fonctionner sur les GPU AMD, puis HIP est logique. Pour d'autres, l'objectif est de le faire fonctionner sur les GPU Intel ou Android, puis OpenCL a beaucoup plus de sens. Les langages GPU sont un gâchis, alors restez pratique,

Si je lis certains des commentaires ici, les performances sont un problème avec les ports OpenCL. Mais malheureusement, je ne vois pas beaucoup de repères autour. Y a-t-il plus de repères que celui-ci ? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

Si je comprends bien, l'analyse comparative est difficile si vous comparez CUDA à OpenCL, car vous devez utiliser un matériel différent. Apparemment, nVidia a délibérément fait/permis que leur implémentation OpenCL soit quelque peu cassée, donc l'analyse comparative sur le même matériel donnera toujours une belle apparence à CUDA.

Le 12 février 2018 14:26:11 GMT+00:00, VincentSC [email protected] a écrit :

L'accent est-il mis ici sur le fait de l'exécuter-comme-lomg-comme-c'est-OpenCL, ou
le faire fonctionner plus rapidement ? Je préférerais qu'il n'y ait pas une guerre sainte, mais
en se concentrant sur son exécution rapide sur plusieurs GPU. LifeIsStrange's
l'accent est mis sur le fonctionnement sur les GPU AMD, puis HIP fait du bien
sens. Pour d'autres, l'objectif est de le faire fonctionner sur les GPU Intel ou
Android, puis OpenCL a beaucoup plus de sens. Les langages GPU sont un
désordre, alors s'il vous plaît restez pratique,

Si je lis certains des commentaires ici, la performance est un problème avec le
Ports OpenCL. Mais malheureusement, je ne vois pas beaucoup de repères autour.
Y a-t-il plus de repères que celui-ci ?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -364936498

--
Envoyé depuis mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Comparer seulement 2 chiffres n'est pas une information - qui se soucie si OpenCL sur NVidia fonctionne à moitié vitesse s'il fonctionne à vitesse 4x sur d'autres GPU ?

Je pense que nous aurions besoin de ces repères:

1. CUDA sur GPU NV (benchmarks de référence)
2. https://github.com/hughperkins/tf-coriander sur les GPU AMD, Nvidia et Intel
3. https://github.com/benoitsteiner/tensorflow-opencl sur les GPU AMD, Nvidia et Intel
4. https://github.com/lukeiwanski/tensorflow sur les GPU AMD, Nvidia et Intel

Les repères de référence sont faciles à trouver. Nous avons ici des GPU haut de gamme, nous n'avons donc besoin que d'un endroit pour mettre les chiffres (avec des liens vers des documents de construction).

Support OpenCL Cela doit devenir vrai.

cuda trop limité, et nvidia ne veut pas le partager.
cuda ne fonctionne que pour les gpus Nv.
c'est une impasse pour TensorFlow,
si un autre "TensorFlow" sort mais plus de support que TensorFlow.
si TensorFlow ne prend toujours en charge que cuda dans Windows.
vous devez réaliser que TensorFlow n'est pas le seul choix.

Pourquoi OpenCL est-il meilleur que HIP ? Je pense qu'OpenCL n'a pas réussi à gagner du terrain et soutenir OpenCL à ce stade est probablement contre-productif et limite les ressources pour l'ensemble de la communauté/de l'industrie. Je préférerais voir TensorFlow prendre en charge HIP directement et laisser le compilateur/outil/bibliothèque s'occuper de la portabilité.

N'est-il pas préférable que le logiciel prenne en charge 1 langage/modèle de programmation ?

Le logiciel doit prendre en charge ce qu'il doit prendre en charge pour couvrir tous les cas d'utilisation.
HIP n'est que cloches et sifflets (au moins sur le papier) si vous avez du matériel pris en charge. Mais il n'y a pas que les "nouvelles cartes amd et nvidia" dans ce monde.

Maintenant, s'il vous plaît, pour l'amour de Dieu, plaignez-vous ici pour tout problème avec cela.
Et ici pour tous ceux qui s'intéressent à la suite de ce numéro.

Je pensais que SPIR-V remplacerait directement CUDA comme alternative multi-matériel :
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

Pourquoi Google s'appuie-t-il toujours sur CUDA ?

Est-ce que cela peut aider ?

Génération de nombres aléatoires OpenCL (Thomas Wang) :

uint wang_hash(uint seed)
{
               seed = (seed ^ 61) ^ (seed >> 16);
               seed *= 9;
               seed = seed ^ (seed >> 4);
               seed *= 0x27d4eb2d;
               seed = seed ^ (seed >> 15);
               return seed;
}

void wang_rnd_0(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(id);
               intSeeds[id]=rndint;
}

float wang_rnd(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(intSeeds[id]);
               intSeeds[id]=rndint;
               return ((float)rndint)/(float)maxint;
}


// initialize each thread's own random number seed
__kernel void rnd_0(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               wang_rnd_0(intSeeds,id);     
}

// get a new random value by each thread
__kernel void rnd_1(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               float randomFloat=wang_rnd(intSeeds,id);
}

OpenCL SHA3hashing (oublié qui a écrit ceci)

https://gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Veuillez supprimer le destinataire, car ce numéro invite des contributions externes. Sinon, supprimez l'étiquette contributions welcome . Merci.

Veuillez supprimer le destinataire, car ce numéro invite des contributions externes. Sinon, supprimez l'étiquette contributions welcome . Merci.

Il est dans l'intérêt de Google de prendre en charge OpenCL,
en ayant le matériel spécifique d'une (entreprise/marque/fournisseur) spécifique comme dépendance de votre logiciel, vous vous obligez à payer plus pour le matériel, la concurrence sur le marché réduit les coûts.
Google a toujours été axé sur le matériel de base depuis le tout début, ce qui était et reste crucial pour le succès de Google (dominance du marché), ayant des coûts d'exploitation de centre de données inférieurs, a permis les généreuses offres révolutionnaires de services essentiellement gratuits comme Gmail (espace de stockage) et Google Photos (espace de stockage espace et marquage automatique).

@wesamco Non, ce n'est pas nécessairement dans l'intérêt de Google. Ils fabriquent leur propre matériel - quelque chose appelé "TensorBoard", IIRC. Ils peuvent contourner OpenCL et CUDA/CUDnn et faire exécuter à la carte du code TensorFlow brut.

code TensorFlow brut.

Il n'y a rien de tel - ce n'est pas comme les aliments non transformés. Les TPU ont besoin de leur propre bibliothèque DNN qui gère les différents types d'appels.

Il semble qu'il soit temps de compresser à nouveau la discussion ci-dessus dans une seule liste :

• CodePlay travaille sur un backend SYCL
• Hugh Perkins travaille sur tf-coriandre
• AMD travaille sur un backend HIP
• PlaidML ne prend en charge que les processeurs pour le moment.
• L'état de la prise en charge des GPU Intel n'est pas clair.

Alors choisissez un projet que vous aimez et commencez à le soutenir. Peut-être que chacun des groupes peut faire le point sur son projet ?

Comprenez qu'OpenCL a été transformé d'un langage complet en une définition de langage/spécification matérielle qui est représentée dans SPIRV (noyaux), qui peut ensuite être exécuté sur une plate-forme comme les pilotes OpenCL et plus tard également sur les pilotes Vulkan (plates-formes). Ainsi, en prenant en charge SYCL, vous prenez également en charge OpenCL.

Résumé parfait, mais plaidml fonctionne aussi sur gpus.
C'est juste que pour le moment, ils sont un backend pour keras, pas tensorflow. Donc c'est un peu OT là.

Salut tout le monde,
@VincentSC merci pour le bon résumé des différents efforts !

Alors choisissez un projet que vous aimez et commencez à le soutenir. Peut-être que chacun des groupes peut faire le point sur son projet ?

L'approche SYCL prend désormais en charge une variété de plates-formes / appareils. Ceux que je peux citer sont :

• GPU AMD (séries FirePro W8100, R9 Nano et R9 380) Instructions disponibles ici ou ici
• ARM Mali ( HiKey 960 ) Instructions disponibles ici
• GPU Intel (série SkyLake) avec pilote Intel NEO OpenCL

En ce qui concerne AMD, pour le moment, les GPU mentionnés ci-dessus utilisent les pilotes AMDGPU-Pro 17.40-xxx avec OpenCL hérité activé.
Je ne vois aucune raison évidente pour laquelle d'autres séries ne fonctionneraient pas (en supposant que SPIR / SPIR-V est pris en charge)

La plate-forme principale sur laquelle nous nous concentrons est Linux - cependant, nous avons des efforts continus pour activer Windows à l'avenir. Nous n'avons pas l'intention de prendre en charge OSX dans un avenir proche. Je connais un visage triste.

Notre objectif est d'améliorer les performances des CNN. Les performances actuelles ne sont pas optimisées et loin de là où nous les voyons se terminer. Cela dit, nous battons déjà les performances du processeur pour la plupart des modèles sur différentes cibles.

Afin d'accélérer le cycle de développement et de réduire le temps de compilation global de TensorFlow (ainsi que d'améliorer la portabilité), nous travaillons sur les bibliothèques Eigen, BLAS et DNN.
Ces bibliothèques visent à résoudre le problème de performances ainsi qu'à créer un écosystème de bibliothèques portables qui peuvent être facilement intégrées à des projets complexes comme TensorFlow.

Ci-dessous, voir les graphiques de performances que nous pouvons partager actuellement. Ils sont tirés de mon fork https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu à 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
Le benchmark utilisé est https://github.com/tensorflow/benchmarks

Le graphique est normalisé aux résultats Intel i7-4790K.

Nous acheminons lentement les modifications vers Eigen une fois que cela se produira, nous suivrons avec TensorFlow.

J'espère que ça t'as aidé,
Luc

Pour l'inférence d'apprentissage en profondeur sur les appareils mobiles avec prise en charge GPU/OpenCL, vous pouvez consulter MACE , qui est optimisé pour les GPU Adreno, Mali et PowerVR. Voici quelques résultats de référence .

@keryell @benoitsteiner , quelle version de tensorflow et trisycl est requise pour l'intégration. J'ai du mal à construire tensorflow (1.9) avec la dernière version de trisycl.

Malheureusement, le dernier TensorFlow utilise des fonctionnalités plus avancées que le triSYCL actuel ne peut gérer, vous devez donc utiliser ComputeCpp, actuellement la seule implémentation SYCL entièrement conforme...

Tensorflow est supporté par Google Brain, et Google a un partenariat avec nVidia, je suppose qu'on ne s'attendra pas à ce que Tensorflow supporte OpenCL
Un gros effort de la communauté OpenCL est nécessaire

Support OpenCL s'il vous plait !

OpenCL nous convient mieux aussi.

@Makhaon Moi aussi. Je n'ai pas les moyens d'acheter une machine avec une carte graphique NVIDIA.

Outre les 2 messages ci-dessus, j'aimerais ajouter que maintenant les GPU Vega d'AMD (y compris ceux à l'intérieur des APU Raven Ridge) peuvent faire FP16 à deux fois le FLOPS, donc si TF pouvait les prendre en charge (via OpenCL), cela aiderait vraiment les gens avec moins de budget. De plus, beaucoup de ces personnes seraient des étudiants, et si nous les amenions à utiliser TF comme point de départ de leur voyage DNN, ils resteraient probablement avec TF sur la route, et même parleraient de TF aux autres ; c'est un excellent moyen d'aider à développer ce projet.

Je pense que ce fil n'a généralement aucun sens pour les développeurs (trop de bruit - et j'en ajouterai d'autres ;-) mais je pense que de nombreux commentaires passent à côté de l'essentiel :
Si vous souhaitez exécuter Tensorflow avec des cartes AMD, OpenCL N'EST PAS ce que vous recherchez - rendez-vous sur https://github.com/ROCmSoftwarePlatform/ et installez la pile ROCm. Autant que je sache , la stratégie actuelle d'AMD est basée sur ROCm au lieu d'OpenCL pour Tensorflow/pytorch .

L'OpenCL générique nécessitait trop de maintenance / n'offrait pas suffisamment d'avantages en termes de performances pour en valoir la peine pour AMD. Par conséquent , ce ticket n'est intéressant que si vous utilisez (par exemple) une plate-forme ARM qui utilise uniquement OpenCL.

(Avertissement: juste un étranger, pas de véritable intérieur dans le développement de Tensorflow, donc peut-être que les informations ci-dessus sont complètement fausses et trompeuses. N'hésitez pas à me frapper si vous savez mieux.)

Juste une pensée, qu'en est-il de llvm avec le nouveau déchargement GPU ? Cela mettrait un grand niveau d'abstraction entre tensorflow et le code spécifique à cuda.

Qu'en est-il de vous tous qui lisez seulement 10 messages ci-dessus et remarquez qu'il existe déjà un fork de lukeiwanski/codeplaysoftware que vous pouvez essayer ?
(également mon chapeau à xiaomi pour, une fois, avoir contribué à un sérieux effort open source)

@FelixSchwarz Juste pour que vous sachiez que ROCm utilise OpenCL, il s'agit du pilote OpenCL de l'espace utilisateur d'AMD sous Linux (c'est pourquoi il ne prend pas en charge Windows), donc si vous ne savez pas comment fonctionne l'écosystème de pilotes AMD sous linux, ils ont leurs pilotes côté noyau AMDGPU et AMDKFD (qui sont maintenant fusionnés dans AMDGPU), puis il y a les pilotes de l'espace utilisateur RadeonSI (pour OpenGL) RadV/AMDVLK (pour Vulkan) et ROCm (pour OpenCL).

À en juger par la dynamique de ce bogue et d'autres fourches, Google n'a aucun intérêt à cela et ne l'implémentera jamais dans le référentiel officiel. Je voterais pour fermer ce problème (ou le verrouiller) pour ne pas donner de faux espoirs à tout le monde.

Le problème devrait être ici pour au moins pointer ici tous les gens qui
rouvrez-le inévitablement.

Le samedi 15 septembre 2018, 09h45, Anton Kochkov [email protected] a écrit :

A en juger par la dynamique de ce bogue et d'autres fourches, Google a zéro
intérêt pour cela et ne mettra jamais cela en œuvre dans le cadre officiel
dépôt. Je voterais pour fermer ce problème (ou le verrouiller) pour
ne pas donner de faux espoirs à tout le monde.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Il existe un TensorRT qui prend en charge Movidius Pi Hat. Et ce Movidius Pi Hat est le "Kit AIY Vision" de Google à 45 $. Google établit un lien vers Target pour l'acheter.

Cela n'a aucun lien avec CUDA ou Nvidia ? Dit qu'il utilise une puce Intel. Au fond, peut-être que la puce est un FPGA ? Quelqu'un en sait-il plus ?

Je connais un peu la grande unité Movidius - c'est uniquement de l'inférence et elle exécute des modèles précompilés TensorFlow ou Caffe. IIRC, ils sont tous en mode 16 bits.

La puce Movidius elle-même est beaucoup plus puissante mais vous devez être un partenaire qualifié pour obtenir le SDK.

Avoir un lien pour d'autres qui essaient d'avoir tensor opencl:

https://github.com/hughperkins/tf-coriander
https://github.com/ChiahungTai/tensorflow-cl
https://github.com/guoyejun/tensorflow-cl
https://github.com/honggui/tensorflow-cl
https://github.com/benoitsteiner/tensorflow-opencl
https://github.com/lukeiwanski/tensorflow (le référentiel est obsolète)
https://github.com/codeplaysoftware/tensorflow
Peut-être vaut-il la peine de vérifier également:

https://documen.tician.de/pyopencl/
https://pypi.org/project/DeepCL/
https://www.khronos.org/sycl/

N'hésitez pas à ajouter des projets de travail.

Y a-t-il une mise à jour? Ce problème date de plus de 3 ans.

OUI IL Y A JUSTE REGARDEZ LA DERNIÈRE POIGNÉE DE POSTES.

@ filips123 non, il n'y a pas de mises à jour et ne le sera jamais dans un avenir prévisible - la probabilité de cela est inférieure à celle d'une invasion extraterrestre et de trouver un moyen de voyager dans le temps.

Cette initiative Intel PlaidML fonctionne raisonnablement bien, cela vaut la peine de la vérifier.
https://github.com/plaidml/plaidml
Il fonctionne sur opencl OU metal sur mac. Cela fonctionne avec les GPU Macbook Pro AMD, ce que je cherchais.
En attendant, pourriez-vous aider à voter pour le support de Pytorch dans PlaidML ? https://github.com/plaidml/plaidml/issues/63

PlaidML est certainement sympa et dandy (pour ma part, je pourrais en quelque sorte obtenir plus de performances sur un gpu nvidia sur opencl qu'avec le cuda de tf lui-même)..
Mais c'est un backend pour keras ? En remplacement complet de tensorflow, que vous savez, c'est le référentiel dans lequel nous en discutons ?
(pour autant que je semble comprendre que les dernières versions de tf peuvent exporter des modèles directement vers keras? donc il y a ça ..)

Quoi qu'il en soit, pour la quatrième fois, si vous voulez une solution récente sur opencl et quelque chose qui est toujours activement développé ( et aussi le truc avec les chances réelles d'être fusionné ici pour de vrai un jour), il y a juste une pile de codeplay.
De nouveau:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

PlaidML est certainement sympa et dandy (pour ma part, je pourrais en quelque sorte obtenir plus de performances sur un gpu nvidia sur opencl qu'avec le cuda de tf lui-même)..
Mais c'est un backend pour keras ? En remplacement complet de tensorflow, que vous savez, c'est le référentiel dans lequel nous en discutons ?
(pour autant que je semble comprendre que les dernières versions de tf peuvent exporter des modèles directement vers keras? donc il y a ça ..)

Quoi qu'il en soit, pour la quatrième fois, si vous voulez une solution récente sur opencl et quelque chose qui est toujours activement développé (_et aussi_ le truc avec les chances réelles d'être fusionné ici pour de vrai un jour), il y a juste une pile de codeplay.
De nouveau:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

Mes excuses, je n'avais pas réalisé qu'il n'y avait pas de support tensorflow. Mon cerveau assumant pensait que le support GPU de Keras == support de tensorflow.

plaidML est super cool. Fonctionne sur les keras.
Bien sûr, j'ai dû transférer du code tf vers des keras purs afin de travailler sur le backend plaidML (par exemple tf.image.ssim)
Mais résultat - mon code fonctionne sur les cartes NVIDIA et AMD.

PlaidML est également un paradis pour les chercheurs. Il génère automatiquement un gradient pour toute fonction que vous écrivez sur le langage "Tile" et il fonctionnera sur votre GPU avec une vitesse de 80 % de tensorflow.

Je ne comprends donc pas pourquoi les chercheurs en ML utilisent encore PyTorch ? Stimulons la science ML avec plaidML d'Intel ?

@iperov Vous voulez savoir pourquoi pratiquement personne n'utilise PlaidML ?

1. Il fonctionne pitoyablement lentement sur les implémentations OpenCL d'AMD par rapport au backend CUDA de Tensorflow, il y a donc au moins la moitié des raisons de l'utiliser. Des performances si mauvaises que l'utilisation de Tensorflow avec des processeurs est compétitive ou même carrément supérieure à leur matériel en utilisant PlaidML ?

2. Personne n'est intéressé à maintenir leur langage de programmation Tile spécialisé dans lequel seul quelqu'un comme un professeur de mathématiques pures concocterait de sorte que la qualité du code de PlaidML tombe à l'eau et qu'aucun programmeur sérieux dans son bon sens ne voudrait gérer un code trop intelligent...

3. Cela rejoint à peu près le n ° 2, mais depuis qu'Intel a racheté Vertex.AI, ils ne se soucient plus de PlaidML. La solution d'Intel pour l'apprentissage automatique accéléré par le calcul GPU introduit un nouveau compilateur spécifiquement pour l'apprentissage en profondeur maintenant connu sous le nom de nGraph pour cibler Tensorflow, PyTorch ou d'autres cadres d'apprentissage en profondeur comme backend pour eux. Aucune raison pour eux de continuer à développer PlaidML comme intermédiaire alors qu'ils ont nGraph ...

Les gens utilisent PyTorch pour d'autres raisons telles que la maintenabilité ou d'autres fonctionnalités. Pour résumer, PlaidML est l'outil d'Intel et ils n'ont probablement pas l'intention qu'il joue un rôle dans les dernières parties de leurs plans. Le backend GPU Intel actuel de nGraph est basé sur OpenCL 2.1 dont seul Intel a une implémentation conforme, de sorte qu'Intel n'existe que pour s'occuper d'eux-mêmes plutôt que purement pour l'amélioration de l'apprentissage automatique. Lorsqu'Intel poursuit le développement de nGraph, je ne les vois pas continuer à baser leur backend GPU sur OpenCL 2.1 uniquement, car de nombreux frameworks d'apprentissage en profondeur ont des noyaux modèles qui ne sont pas compatibles avec les modèles de programmation source séparés d'OpenCL, Metal ou Vulkan, c'est donc probablement uniquement à des fins expérimentales. Le backend GPU final d'Intel sera probablement basé sur SYCL 2.2 ou quelque chose d'autre de complètement différent comme OpenMP et peut-être apportera-t-il même une solution spécifique au fournisseur ...

Quant à AMD, qui s'en soucie ? OpenCL n'est pas pertinent pour eux et ils montrent enfin des résultats avec leur travail sur HIP...

@iperov Vous voulez savoir pourquoi pratiquement personne n'utilise PlaidML ?

1. Il fonctionne pitoyablement lentement sur les implémentations OpenCL d'AMD par rapport au backend CUDA de Tensorflow, il y a donc au moins la moitié des raisons de l'utiliser. Des performances si mauvaises que l'utilisation de Tensorflow avec des processeurs est compétitive ou même carrément supérieure à leur matériel en utilisant PlaidML ?
2. Personne n'est intéressé à maintenir leur langage de programmation Tile spécialisé dans lequel seul quelqu'un comme un professeur de mathématiques pures concocterait de sorte que la qualité du code de PlaidML tombe à l'eau et qu'aucun programmeur sérieux dans son bon sens ne voudrait gérer un code trop intelligent...
3. Cela rejoint à peu près le n ° 2, mais depuis qu'Intel a racheté Vertex.AI, ils ne se soucient plus de PlaidML. La solution d'Intel pour l'apprentissage automatique accéléré par le calcul GPU introduit un nouveau compilateur spécifiquement pour l'apprentissage en profondeur maintenant connu sous le nom de nGraph pour cibler Tensorflow, PyTorch ou d'autres cadres d'apprentissage en profondeur comme backend pour eux. Aucune raison pour eux de continuer à développer PlaidML comme intermédiaire alors qu'ils ont nGraph ...

Les gens utilisent PyTorch pour d'autres raisons telles que la maintenabilité ou d'autres fonctionnalités. Pour résumer, PlaidML est l'outil d'Intel et ils n'ont probablement pas l'intention qu'il joue un rôle dans les dernières parties de leurs plans. Le backend GPU Intel actuel de nGraph est basé sur OpenCL 2.1 dont seul Intel a une implémentation conforme, de sorte qu'Intel n'existe que pour s'occuper d'eux-mêmes plutôt que purement pour l'amélioration de l'apprentissage automatique. Lorsqu'Intel poursuit le développement de nGraph, je ne les vois pas continuer à baser leur backend GPU sur OpenCL 2.1 uniquement, car de nombreux frameworks d'apprentissage en profondeur ont des noyaux modèles qui ne sont pas compatibles avec les modèles de programmation source séparés d'OpenCL, Metal ou Vulkan, c'est donc probablement uniquement à des fins expérimentales. Le backend GPU final d'Intel sera probablement basé sur SYCL 2.2 ou quelque chose d'autre de complètement différent comme OpenMP et peut-être apportera-t-il même une solution spécifique au fournisseur ...

Quant à AMD, qui s'en soucie ? OpenCL n'est pas pertinent pour eux et ils montrent enfin des résultats avec leur travail sur HIP...

Qu'en est-il de tous les GPU à l'intérieur de la machine à bras comme les téléphones mobiles et Raspberry Pi Odroid, etc.?
Ils ne supportent pas opencl ?
Google devrait se soucier d'insérer tensorflow sur gpu sur android.
Les plus grandes bibliothèques de formation aux réseaux de neurones ne fonctionnent que sur le GPU Nvidia, cela rend le GPU Nvidia de plus en plus cher (parce que les gens et les entreprises ne l'achètent que pour la formation professionnelle au réseau de neurones), alors Google perdra plus d'argent de cette façon.

@Degerz de quelle planète vous venez ?
Comment comparer tf-CPU et AMD GPU ?
GPU AMD sur plaidML x30 plus rapide que tf-CPU

1. Il fonctionne pitoyablement lentement sur les implémentations OpenCL d'AMD par rapport au backend CUDA de Tensorflow, il y a donc au moins la moitié des raisons de l'utiliser

dans mes tests deepfakes, OpenCL n'est plus lent que de 20 %, mais dans certains mini-réseaux, OpenCL est 20 % PLUS RAPIDE.

Mon projet DeepFaceLab compte de nombreux utilisateurs qui attendent le support d'AMD. Combien de personnes ont été ravies lorsque les deepfakes peuvent enfin être formés sur des cartes AMD.
De plus, plaidML est le seul backend pour keras qui prend en charge AMD/IntelHD prêt à l'emploi.
Si un nouveau backend AMD pour keras apparaît, mon projet y basculera bien sûr.
PyTorch n'a pas d'avenir.

Que maintenir dans plaidML ? Les opérations sont auto différentiables, il n'y a rien à maintenir.

Langage de programmation de tuiles dans lequel seul quelqu'un comme un professeur de mathématiques pures concocterait

L'apprentissage automatique a été inventé par des professeurs de mathématiques, n'est-ce pas ?

@talregev Qu'en est-il d'ARM ou de Broadcom ? Le premier a probablement une implémentation OpenCL inférieure à la moyenne et le second ne fournit même pas officiellement de pilotes OpenCL ! Ce n'est pas la responsabilité de Google de créer et de maintenir une pile de calcul compétente pour les fournisseurs de matériel...

@iperov Vous réalisez que former des réseaux de neurones avec des couches d'intégration sur PlaidML est pénible, n'est-ce pas ? PlaidML a également un tas d'autres limitations, comme le fait qu'il n'est pas très bien adapté aux DenseNets ou le fait que ses graphiques de calcul sont statiques et PlaidML fonctionne-t-il même bien avec les RNN ?

Quant à votre projet, ne vous inquiétez pas. Vous passerez à quelque chose de mieux comme Tensorflow car AMD proposera bientôt un backend GPU natif une fois que MIOpen sera en amont, qui est leur bibliothèque accélérée par GPU de primitives pour les réseaux de neurones profonds similaires à la bibliothèque cuDNN de leur concurrent, qui laisseront PlaidML dans la poussière en termes de performances. Qui se soucie des iGPU Intel de toute façon ? Si Intel s'engage vraiment à fournir un apprentissage en profondeur hautes performances sur son futur matériel graphique discret, il proposera une option de source unique, tout comme les autres (AMD/HIP et Nvidia/CUDA) l'ont fait avant eux...

PyTorch n'a pas d'avenir.

Envie beaucoup ? PyTorch est ~10x plus populaire que PlaidML, les dernières techniques de DL sont facilement implémentées sur PyTorch, des tonnes de contributeurs différents et sont activement développées par Facebook pendant qu'Intel n'a pas contribué à PlaidML depuis près d'un mois ?

Que maintenir dans plaidML ? Les opérations sont auto différentiables, il n'y a rien à maintenir.

Je suppose donc que PlaidML ne devrait pas recevoir de nouveaux correctifs ou de nouvelles fonctionnalités à l'avenir ? Si vous ne voyez pas l'intérêt d'améliorer le code, il ne sert à rien de vous convaincre de reconnaître les défauts flagrants de PlaidML...

L'apprentissage automatique a été inventé par des professeurs de mathématiques, n'est-ce pas ?

Cela ne veut pas dire que nous devons reprendre n'importe quel langage de programmation qu'ils composent, en particulier dans le cas de Tile où l'élégance est clairement privilégiée par rapport à la lisibilité. Il n'est pas étonnant que tant de contributeurs potentiels aient peur de contribuer...

Jésus, je vous souhaite les gars STFU et retournez au travail à la place. Je vais devoir me désinscrire du ticket car c'est insupportable de recevoir des mails avec des guerres de flammes. Dommage que les mainteneurs ne coupent pas le fil.

@gunan @caisq @sanjoy Pourriez-vous faire quelque chose s'il vous plait ?