Es ist seltsam, dass Google offenes OpenCL für proprietäres CUDA aufgegeben hat.

Zumindest müsste die Eigen- Bibliothek OpenCL unterstützen.

:+1:

:+1:

:+1:

Daumen hoch und so.

Ich werde daran interessiert sein, Tensor Flow mit OpenCL zu erweitern. Da wir bereits OpenCL caffe veröffentlicht haben. https://github.com/amd/OpenCL-caffe. Hoffentlich kann es auf leichte Weise integriert werden? Hat jemand Interesse daran mitzuarbeiten?

@gujunli Schön, AMD hier zu sehen. /cc @naibaf7 @lunochod

wäre großartig.

:+1:

/cc @lukeiwanski für Eigen/OpenCL/SYCL

@gujunli Wäre sicherlich daran interessiert, einen Beitrag zu leisten. Bitte teilen Sie mir mit, wann Sie beginnen möchten.

Hallo alle,

Hier bei Codeplay untersuchen wir den Tensor von Eigen, der auf der GPU mit SYCL (einer modernen C++-Schicht auf OpenCL) läuft. Nach dem, was wir bisher gesammelt haben, ist das GPU-Tensor-Design sehr eng mit CUDA gekoppelt und erfordert Schnittstellenänderungen für ein anderes Programmiermodell und insbesondere eine SYCL- und OpenCL 1.2-Version.

Wenn jemand daran interessiert ist, tiefer zu graben / zu helfen, sind wir sicherlich daran interessiert, einen Beitrag zu leisten.

Danke,
Lukas

@lukeiwanski Vielen Dank für das Feedback. Ich denke, dass @benoitsteiner am Tensorerweiterungsteil von eigen gearbeitet hat.

:+1: Ich kann beim Coden von OpenCL/SYCL helfen, wenn jemand einen Plan erstellt, die Arbeit in Aufgaben aufteilt usw. Ich empfehle die Verwendung von Boost.Compute als Wrapper für OpenCL (es erleichtert das Ausführen von Kerneln, das Testen und das Erstellen von Vorlagen).

+1

:+1:

Hallo alle,

Nur um Sie auf dem Laufenden zu halten, untersuchen wir immer noch, wie wir die Eigen-Schnittstelle ändern können, um sie besser an das SYCL/OpenCL 1.2-Programmiermodell anzupassen.
Sobald wir einen vernünftigen Ansatz gefunden haben, der auf heterogene Programmiermodelle ( nicht nur OpenCL / SYCL ) abzielt, werden wir einen Vorschlag erstellen.

Danke,
Lukas

Bitte halten Sie mich auf dem Laufenden. Ich habe opencl-caffe für AMD entwickelt. schaue ich mir auch an
Tensorfluss.

Danke.
Junlu
Am 8. Dezember 2015 um 10:19 Uhr schrieb „Luke Iwanski“ [email protected] :

Hallo alle,

Nur um Sie auf dem Laufenden zu halten, wir untersuchen immer noch, wie wir das ändern können
Eigene Schnittstelle zur besseren Anpassung an das Programmiermodell SYCL/OpenCL 1.2.
Sobald wir einen vernünftigen Ansatz gefunden haben, erstellen wir einen Vorschlag.

Danke,
Lukas

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -162967662
.

/cc @ptillet @gongzg Gibt es irgendein Interesse von Intel daran? Ich hoffe wirklich, dass wir OPENCL hier nicht fragmentieren wie in Caffe, wo wir einen AMD-Fork, nicht zusammengeführte Intel-PRs, einen weiteren halbinoffiziellen AMD-PR und einen langen Staging-Benutzer-PR (plus zwei alte aufgegebene Opencl-Bemühungen) haben. Wenn sich jemand für die Geschichte interessiert, kann er einen Blick auf https://github.com/BVLC/caffe/pull/2610 Kommentare werfen.

@bhack Wir haben Interesse daran. Danke für die Information. Wenn es einen Vorschlag für Eigens OpenCL/SYCL-Implementierung gibt, werden wir sehen, was wir von Intel-Seite tun können.

:+1:

Eine interessante Initiative unter https://github.com/ptillet/isaac auch wenn wir hier auf die Eigentensorerweiterung setzen.

Auch ich möchte einen Beitrag leisten. @benoitsteiner kannst du das organisieren?

Dies wurde in die Roadmap aufgenommen, aber auch als Beitrag gekennzeichnet, sodass eine Richtung/ein Bootstrap wirklich nützlich sein könnte.

Ich kann zur Organisation beitragen. Wer ist verantwortlich für den OpenCL-Support in
Tensorfluss jetzt?

Vielen Dank.
Juni

Am Dienstag, den 19. Januar 2016 um 7:50 Uhr schrieb bhack [email protected] :

Dies wurde in die Roadmap aufgenommen, aber auch als Beitrag so a gekennzeichnet
Richtung/Bootstrap könnte wirklich nützlich sein.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172894538
.

---

Junli Gu – 谷俊丽
Koordiniertes Wissenschaftslabor
Universität von Illinois in Urbana-Champaign

---

Ich habe nur Benoit angenommen, weil er sich das Feature selbst zugewiesen hat, aber ich denke, du hast es, Junli! Beginnen Sie vielleicht mit einer E-Mail oder einem Forenthread von Interessenten?

@benoitsteiner weiß mehr über Interessenten, die vielleicht nicht erschienen sind
oben in diesem Thread (oder dieser Ausgabe). Ich würde warten, bis er sich koordiniert hat
sicher, dass wir Doppelarbeit vermeiden.

Am Dienstag, 19. Januar 2016 um 11:42 Uhr Dan McLaughlin [email protected]
schrieb:

Ich habe nur Benoit angenommen, weil er das Feature selbst zugewiesen hat, aber ich denke
du hast es Junli! Beginnen Sie vielleicht mit einer E-Mail oder einem Forenthread
interessierte Parteien?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

Ich bin interessiert. Gibt es einen Fahrplan?

Am 19. Januar 2016 um 11:46 Uhr schrieb Martin Wicke [email protected] :

@benoitsteiner weiß mehr über Interessenten, die vielleicht nicht erschienen sind
oben in diesem Thread (oder dieser Ausgabe). Ich würde warten, bis er sich koordiniert hat
sicher, dass wir Doppelarbeit vermeiden.

Am Dienstag, 19. Januar 2016 um 11:42 Uhr Dan McLaughlin [email protected]
schrieb:

Ich habe nur Benoit angenommen, weil er das Feature selbst zugewiesen hat, aber ich denke
du hast es Junli! Beginnen Sie vielleicht mit einer E-Mail oder einem Forenthread
interessierte Parteien?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Gibt es eine Liste von CUDA-Abhängigkeitsbibliotheken, auf die sich Tensorflow stützt?

Dies würde helfen zu sehen, ob wir unmittelbare OpenCL-Alternativen haben könnten.

@hsaputra
Es gibt clFFT, clBLAS (alternativ ViennaCL). Der Zufallszahlengenerator ist etwas kniffliger (kein Curand), entweder einen CPU-Generator verwenden und auf die GPU übertragen oder einen anderen vorhandenen Kernel für RNG verwenden.

Die größte Falle werden wieder effiziente Faltungsimplementierungen (etwas wie cuDNN) sein.

Erfahrungen zu solchen Problemen gibt es hier:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-caffe

Tensorflow verwendet die Tensorerweiterung, die Eigen vorgeschaltet ist. Daher denke ich, dass eine Opencl/Sycl-Unterstützung für Eigen benötigt wird. Siehe diesen Thread

Danke @naibaf7. Ja, ich glaube nicht, dass es derzeit eine brauchbare Alternative für cuDNN für OpenCL gibt.

Die Website http://opencl.org wurde erstellt, um Open-Source-Portierungsprojekte wie diese zu unterstützen! Wir installieren derzeit alle erforderlichen Tools auf der Website und haben Platz für Repositories unter https://github.com/OpenCL/ - später fügen wir Build-Server hinzu, um verschiedene Arten von Hardware zu testen, und können unser Fachwissen einbringen wie man Code schreibt, der auf zahlreicher Hardware mit voller Geschwindigkeit läuft.

Wir starten nächste Woche eine Portierungsinitiative für GEGL, aber wir unterstützen Sie auch gerne.

@bhack aus diesem Thread und hier sieht es so aus, als würde @lukeiwanski sich damit befassen. Ich denke, wir haben genug willige Leute, um daran zu arbeiten, wir brauchen nur @benoitsteiner , @lukeiwanski oder @gujunli , um zu koordinieren. Benoit war ruhig, vielleicht ist er im Urlaub.

Ich würde gerne einen Beitrag zu dieser Initiative leisten.

Hallo alle,

Wir koordinieren den Aufwand für die Portierung von Eigens Tensormodul auf SYCL für OpenCL, da wir bereits etwas haben, das größtenteils funktioniert, aber noch nicht zur Überprüfung bereit ist.

Wir befürworten diesen Ansatz, da er weniger Eingriffe in die Codebasis mit sich bringt. SYCL unterstützt das Single-Source-C++-Vorlagenmodell, das eigen bereits verwendet.

Das Roadmap-Design ist im Gange, es sollte also nicht mehr allzu lange dauern.

Danke,
Lukas

@lukeiwanski Arbeiten Sie oder stehen Sie mit dem Upstream in Kontakt? Glauben Sie, dass es stromaufwärts in Eigen akzeptiert wird?

+1

Tolle Neuigkeiten @lukeiwanski , lassen Sie uns wissen, wenn Sie Hilfe benötigen.

Ich vermute, Sie verwenden Ihre eigene Implementierung von SYCL - wird diese für Entwickler/Forscher verfügbar sein? Auf welchen Plattformen?

@lukeiwanski SYCL scheint angesichts der Menge an Template-Metaprogrammierung, die mit Eigen verbunden ist, der richtige Weg zu sein. Ich bin ein erfahrener C++-Entwickler mit OpenCL-Erfahrung, die ich durch die Entwicklung meiner eigenen Bibliothek für neuronale Netze und lineare Algebra gesammelt habe. Ich würde gerne bei diesen Bemühungen helfen und mit der Entwicklung mit SYCL beginnen.

@bhack Wir sind mit @benoitsteiner in Kontakt, aber wir werden unseren Vorschlag mit den Upstream-Betreuern besprechen, bevor wir zu viel Aufwand investieren.

@DanMcLaughlin , @ville-k Wir entwickeln unsere Implementierung von SYCL, ComputeCpp (https://www.codeplay.com/products/computecpp). Für weitere Informationen können Sie mich bitte außerhalb der Liste über die E-Mail-Adresse in meinem Profil kontaktieren?

@lukeiwanski gibt es ein Update/eine Schätzung bezüglich der Pläne?

+1.
Ich habe eine AMD-GPU und eine Intel-GPU im Laptop. Ich denke, beide haben OpenCL-Treiber und der Support von AMD scheint viel besser zu sein. Ich hätte eine höhere Leistung, weil ich 2 OpenCL-Geräte habe. Ich hoffe, Sie schaffen es, mit OpenCL-Geräten zu skalieren.

Hallo alle,

Danke für das Interesse!
An diesem Punkt richten wir unsere Testinfrastruktur ein, um sicherzustellen, dass nichts, was wir tun, eine Regression einleitet.
Wir stehen in Kontakt mit @benoitsteiner , um sicherzustellen, dass wir mit dem, was er bisher getan hat, auf dem Laufenden sind.

Wir sind immer noch dabei, eine Roadmap für den Integrationsprozess zusammenzustellen – dies sollte in ein paar Wochen abgeschlossen sein, da einige geschäftliche Details zu klären sind.

Unser Ziel ist es, OpenCL bis Ende dieses Jahres über Eigen zu TensorFlow zu bringen.

Danke,

interessiert. gerne beitragen.

Ok, also scheint es tatsächlich eine Anstrengung von Codeplay mit einer Art interner Synchronisierung mit Google zu sein. Welche Rolle spielen AMD- und Intel-Abonnenten hier?

/cc @keryell , wenn Sie Interesse daran aus dem SYCL/FPGA-Universum haben

Ich entschuldige mich dafür, dass ich in letzter Zeit nicht mehr zu dieser Diskussion beigetragen habe, mein Teller war in den letzten 2 Wochen mehr als voll.

Ich werde die OpenCL-Bemühungen auf der TensorFlow-Seite koordinieren. Unsere aktuelle Überlegung ist:

• TensorFlow basiert auf c++11 und hat einen „Single-Source“-Ansatz gewählt, daher scheint SYCL gut geeignet zu sein.
• Wir haben nicht viel OpenCL-Erfahrung im Haus, also arbeiten wir eng mit Codeplay zusammen, um diese Lücke zu schließen. Insbesondere Codeplay führt derzeit die Bemühungen an, Unterstützung für SYCL zur Eigen-Tensorbibliothek hinzuzufügen.
• TensorFlow verlässt sich auf die cuDNN-Bibliothek, um Faltungen auf NVidia-GPUs zu berechnen. Wenn jemand daran interessiert ist, ein OpenCL-Äquivalent beizusteuern, helfen wir gerne.

Um die Bemühungen zu strukturieren, habe ich eine Mailingliste erstellt: [email protected].

@bhack sicher habe ich Interesse an High-End-C++ auf FPGA :-)
TensorFlow klingt auch nach einem guten Anwendungsfall für die Validierung von triSYCL.
Übrigens, wenn hier Leute nach Praktika zu diesem Thema suchen, ich habe einige Stellen. Es sieht so aus, als ob Codeplay auch nach einigen Leuten sucht, wenn ich ihrer Website vertraue.

Ich interessiere mich sehr für die Meinungen von @karlrupp und @hughperkins . Ich hoffe, sie wollen sich an der Diskussion über die neue Google-Gruppe beteiligen.

@benoitsteiner Vielen Dank für das Update. Es wäre wunderbar, wenn alle beteiligten Partner in der @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx etc.) eine cudnn-ähnliche API auf standardisierte Weise fördern würden. Eine Art von Khronos openvx Computer Vision Standardisierungsbemühungen, aber für Deep Learning.

@bhack Welche neue Google-Gruppe?

Ansonsten sind OpenCL und CUDA zu unterschiedliche Programmieransätze. CUDA funktioniert so, wie es ist, weil ein Unternehmen die volle Kontrolle über alles hat, sodass es binäre Blobs und wer weiß was in die endgültige ausführbare Datei einbetten kann. Dies ist mit OpenCL nicht möglich, es sei denn, man geht den SyCL-Pfad (ich habe meine Bedenken ...) und der Hersteller des SyCL-Compilers hat die volle Kontrolle über alle möglichen Zielarchitekturen (in der Praxis unwahrscheinlich oder unmöglich). Insgesamt bin ich der Meinung, dass eine gute OpenCL-fähige Bibliothek mehr als nur ein paar Optimierungen hier und da braucht. Wahrscheinlich nicht das, was du hören wolltest, aber du hast nach meiner Meinung gefragt :-)

@karlrupp Siehe https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 am Ende für die Google-Gruppe.
Ich habe Sie nach Ihrer Meinung gefragt, weil Sie großartige Erfahrungen mit ViennaCL gemacht haben, das eine Algebra-Bibliothek mit mehreren Backends (CPU, GPU, MIC) verbindet. Tensorflow stützt sich auf die Eigein-Bibliothek und ihre neue Tensor-Erweiterung, die von Google Upstream beigesteuert wurde (jedoch nur mit CUDA-Backend). Ich denke, dass sie all die Fallstricke, denen Sie bereits mit ViennaCL in diesen Jahren der Entwicklung begegnet sind, nicht viel erlebt haben.

@bhack Wir sind diese Woche gerade beim persönlichen Treffen in Seattle, aber ich kann natürlich nicht sagen, ob wir über DNN-Bibliotheken sprechen oder nicht... :-)

@keryell Versuche, die Sache in Seattle voranzutreiben ;)

@karlrupp Du hast Recht, OpenCL und CUDA sind zu unterschiedliche Programmieransätze. Der Single-Source-Aspekt, der beispielsweise in CUDA und OpenMP 4.5 zu finden ist, ist aus softwaretechnischer Sicht äußerst mächtig. Deshalb gibt es diesen SYCL-Standard für die echten C++-Programmierer. SYCL kann als CUDA auf Steroiden ohne Spracherweiterung und mit einigen OpenMP-Aspekten (den Aufgaben) angesehen werden. Von einem typischen SYCL-Gerätecompiler wird erwartet, dass er SPIR-V-Kernel generiert.

Ihre Bedenken hinsichtlich der Portabilität sind weniger ein Problem mit dem SPIR-V-Standard (eine Art tragbares Äquivalent zu nVidia PTX/AMDIL/... in der Vulkan- und OpenCL-Welt), der in OpenCL 2.1 und Vulkan zwingend akzeptiert werden muss. Das Schöne ist also, dass Sie, wenn Sie ein Front-End haben, das SPIR-V generiert, keine besonderen Kenntnisse über die Details der Hardware benötigen, auf der es ausgeführt werden soll. Es gibt einen bidirektionalen Open-Source-Übersetzer von Khronos zwischen LLVM IR und SPIR-V, der also ganz neue Gebiete erschließt.

@keryell Ich stimme zu, dass SPIR-V ein Schritt nach vorne ist. Es behandelt jedoch nicht alle Probleme des erschöpfenden Jittings.

Sie benötigen keine besonderen Kenntnisse über die Details der Hardware, auf der ausgeführt werden soll

Ist das ein Copy&Paste von OpenCL 1.0 Marketing, das genau dasselbe behauptet? Sie müssen _immer_ auf die Details der zugrunde liegenden Hardware eingehen, wenn Sie maximale Leistung anstreben. Dies ist insbesondere im Zusammenhang mit schnellen Tensorkontraktionen der Fall.

...wie @scott-gray mit Neon demonstrierte

@karlrupp

Ist das ein Copy&Paste von OpenCL 1.0 Marketing, das genau dasselbe behauptet?

Haha. :-)

Sie müssen immer auf die Details der zugrunde liegenden Hardware eingehen, wenn Sie maximale Leistung anstreben. Dies ist insbesondere im Zusammenhang mit schnellen Tensorkontraktionen der Fall.

Natürlich, aber bevor Sie mit der Optimierung zweiter Ordnung spielen, ist es nützlich, den großen Teil des gesamten C++-Codes mit Vorlagen auf irgendeine beschleunigte Weise auszuführen.

Für die Optimierung stählt man entweder seine optimierten Binärkerne à la NervanaSys oder, da SYCL reines C++ ist, kann man darin asm("...") mit viel #ifdef verwenden, um die Zielarchitektur zu testen. :-) Allerdings ist SPIR-V selbst erweiterbar, und ich verstehe nicht, warum wir nicht irgendwann Inline-VHDL oder Verilog darin einbauen konnten. :-)

Konkreter gesagt sollte die kürzliche Einführung von Untergruppenoperationen dazu beitragen, auf tragbare Weise eine gute Leistung zu erzielen, und die Verwendung einfacher integrierter Ad-hoc-Funktionen kann hilfreich sein.

C++ fügt interessante Metaprogrammierungsfunktionen hinzu, die es ermöglichen, die meisten der verwendeten Codegeneratoren wie in clBLAS oder anderen Frameworks zu ersetzen, um Code zu generieren, der besser an X- oder Y-Hardware angepasst ist.

Auch N4355 in c++17 könnte über kurz oder lang ins Spiel kommen

@karlrupp , @bhack Der Tensorflow-Ansatz besteht darin, sich für die meisten Operationen, die ein typisches neuronales Netzwerk benötigt, auf eine Hardwareabstraktion (das Tensormodul) zu verlassen, während er sich für die wenigen Operationen auf spezialisierte Bibliotheken (wie cudnn) stützt wirklich kritisch Leistung weise. Die Hardware-Abstraktion ermöglicht es uns, die meisten TensorFlow-Operationen einmal zu implementieren und sie auf einem Beschleuniger mit mehr als ausreichender Leistung auszuführen.

@bhack Ja, ich liebe mehrdimensionale Arrays. Ebenfalls in unserem Interessengebiet gibt es die SG14 im C++-Komitee, die versucht, alle an diesen Themen interessierten Personen dazu zu bringen, sich dem Standard anzuschließen.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Natürlich ist SYCL in den Diskussionen. :-)

@benoitsteiner Hauptsächlich auf cudnn für Pooling und Faltung. Ich denke, wenn jeder Anbieter eine API mit seiner eigenen Hardware für diese Operationen mit seiner eigenen binären Assemblierung produzieren wird, wird dies kein so skalierbarer Ansatz sein. Aus diesem Grund denke ich, dass einige leistungsentscheidende API-Aufrufe besser in irgendeiner Weise standardisiert werden sollten.

@keryell Es gibt wirklich interessante Themen für Matrix/Tensor im neuen SG14 c++, speziell in der Agenda für Vektor-/SIMD-Aufrufe. Aber anscheinend hat niemand von Faltung, Pooling und anderen nützlichen "stabilisierten" Deep-Learning-Schnittstellen gesprochen. Mir scheint auch, dass es in diesen spezifischen Standardisierungsuntergruppen Leute von Nvidia, Intel, Amd, CodePlay usw. gibt, aber nicht von Google, auch wenn es in anderen Gruppen ist.

:+1:

@bhack Ja, es gibt noch keinen Vorschlag für maschinelles Lernen in SG14. Die Teilnahme ist jedoch offen, Sie können also einige Vorschläge einsenden. :-) Aber vielleicht ist SG6 (Numerikthemen) relevanter. Ich glaube nicht, dass sie noch eine eigene Mailingliste/Forum haben.

@gujunli Läuft OpenCL Caffe auf Android? Tut mir leid, dass ich das hier frage, aber ich habe nirgendwo anders gefunden, wo ich es fragen könnte :) Wäre großartig mit einer Deep-Learning-Bibliothek, die auf Android-Geräten lief _und_ die GPU verwenden könnte, aber es scheint, als gäbe es im Moment keine. (Korrigiert mich, wenn ich falsch liege!)

@krikru
Der offizielle (aber experimentelle) OpenCL Caffe-Zweig kann auf Android-GPUs ausgeführt werden, aber die Leistung ist im Moment alles andere als optimal. Siehe https://github.com/sh1r0/caffe-android-lib/issues/23 und https://github.com/BVLC/caffe/tree/opencl.

Eine echte Alternative zu cudnn könnte die Erweiterung von OpenVx-Standardobjekten mit Unterstützung für Tensor-, NdConvolution-, NdPooling-Operatoren und (wahrscheinlich) einige andere Operatoren sein, die als standardisierbar angesehen werden könnten.
Außerdem muss das cudnn-Team entscheiden, welche neuen APIs und Operatoren es in jeder Version einführen wird. Natürlich kann sich ein Standard nicht so schnell bewegen wie cudnn-Releases, aber ich denke, einige Operationen und Objekte haben genug "Zitationshistorie", um standardisiert zu werden.

@hughperkins Im Moment habe ich keine Deep-Learning-Bibliothek ausprobiert; Ich mache nur ein bisschen Scouting, um zu sehen, welche Bibliothek ich möglicherweise verwenden könnte. Haben Sie cltorch und DeepCL auf Android ausprobiert? Ich habe nur angenommen, dass cltorch auf Android funktioniert, da es eine Implementierung von Torch gibt, die speziell für Android vorgesehen ist. Und warum sollten Sie eine solche Implementierung haben, wenn es bereits eine gibt, die sowohl auf Android funktioniert _als auch_ OpenCL verwendet, richtig? Aber vielleicht hätte ich es besser wissen sollen.

@hughperkins Aus irgendeinem Grund stellte ich mir vor, dass Torch-Android eine offizielle Torch-Implementierung für Android sei, was bedeutet, dass wahrscheinlich keine andere Torch-Implementierung (zumindest nicht offiziell) reibungslos auf Android läuft, einschließlich cltorch. Ich weiß nicht, warum ich das dachte, es ergibt natürlich keinen Sinn.

Nun... Soumith koordiniert die Fackelentwicklung. Er arbeitet bei Facebook AI Research. Da also das Torch-Android-Repo Soumith gehört, würde ich sagen, dass es ziemlich offiziell ist. Aber es ist vielleicht aus irgendeinem Grund nicht Teil des Kerns. Ich denke, Sie können die Frage als Problem in diesem Repo oder in https://groups.google.com/forum/#!forum/torch7 stellen. Eigentlich, da Soumith die Hauptperson ist, die die Anfragen in https bearbeitet: //groups.google.com/forum/#!forum/torch7 , ich schätze, Sie möchten Ihre Frage wahrscheinlich dort posten.

Das bedeutet, dass wahrscheinlich keine andere Torch-Implementierung (zumindest nicht offiziell) reibungslos auf Android lief, einschließlich cltorch

Beachten Sie, dass cltorch keine Implementierung von Torch ist. Es ist ein Plugin, das OpenCL bereitstellt. Sie brauchen beides.

Beachten Sie, dass cltorch keine Implementierung von Torch ist. Es ist ein Plugin, das OpenCL bereitstellt. Sie brauchen beides.

Ah, danke für die Klarstellung.

@naibaf7 Haben der OpenCL Caffe -Zweig und die OpenCL Caffe -Implementierung von AMD neben dem Namen noch etwas gemeinsam? Hast du die beiden verglichen oder weißt du, ob es Unterschiede in der Leistung gibt? Sie schreiben, dass der OpenCL-Zweig weit von der optimalen Performance entfernt ist. Was bedeutet das und was wäre nötig, um es zu verbessern? Es wäre interessant, es auf Android zu versuchen.

Wir schweifen vom Thema ab

@bhack Ja, tut mir leid, dass ich diesen Thread gekapert habe. Ich wusste nur nicht, wo ich die Frage stellen sollte.

@krikru
Bitte melden Sie ein Problem im Caffe-Zweig und melden Sie es mit Android und OpenCL. Dann können wir das weiter besprechen. Danke.

@keryell Scheint, dass das nächste f2f SG14-Treffen im März von Google veranstaltet wird . Wird es dort einen internen Tensorflow geben?

/cc @jfbastien

Vielleicht könnte @benoitsteiner mal vorbeischauen, da er lokal ist.
Aber vor dieser Veranstaltung gibt es Ende des Monats in Jacksonville, Florida, das vollständige C++ F2F.
https://isocpp.org/files/papers/N4568.pdf
Leider kann ich an keiner davon teilnehmen.

Ich weiß nicht, ob der CppCon 2015-Vortrag C++ Multi-dimensional Arrays for Computational Physics and Applied Mathematics zu einigen Veröffentlichungen geführt hat.

+1

@bhack Vielen Dank, dass Sie den Vortrag auf mehrdimensionale Arrays verwiesen haben. Es ist interessant und spricht die wirklichen Probleme an, sieht aber zu ad-hoc aus, um in C++ so wie es ist ratifiziert zu werden. Ich persönlich verwende Boost.MultiArray und bin mehr zuversichtlich in eine ausgefeilte Version von Boost.MultiArray.

Es gibt auch einige Papiere bei WG21 . Wie Sie sehen können, hat @jfbastien bei Google einige Aktivitäten bei der WG21 und half auch bei der Ausrichtung des SG14 f2f-Meetings bei Google im März.

@bhack @keryell Ich denke, es würde sich lohnen, diese Diskussion auf die SG14-Mailingliste zu bringen, da die Details nichts mit OpenCL / Tensorflow zu tun haben.

Ja, wahrscheinlich ist es hier nicht mehr so ​​streng auf alle Details beschränkt. Außer Eigen/sycl-Unterstützung Gibt es einen Plan für die cudnn-Anrufe?

+1 sehr interessantes Thema. Hoffe es kommt bald.

Dieser Faden ist sehr interessant. Ich habe versucht, Caffe auf Android zum Laufen zu bringen. Die Ergebnisse scheinen überraschend zu sein: Caffe, das mit Mali-GPU läuft, scheint 2-3 langsamer als CPU zu sein, aber etwa 4-5x energieeffizienter. Der Test wurde auf dem Galaxy S6 (Mali T760, Peak Performance 200 GFlops) durchgeführt.

Da GEMM der Kern der Faltung in Caffe ist, habe ich mich entschieden, seine Leistung auf Android zu profilieren. Es scheint, dass ViennaCL nicht so effizient ist wie einige einfache Kernel. Jetzt kann ich die GPU für große Matrizen (2k x 2k) so schnell wie die CPU laufen lassen. Dies ist immer noch kontraintuitiv, da wir normalerweise erwarten, dass GPUs viel schneller sind.

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

Die Kernel-Implementierungen finden Sie hier:

OpenCL-Kernel für GEMM: https://github.com/strin/gemm-android

Irgendwelche Gedanken?

@strin Hast du diesen Thread schon verfolgt https://community.arm.com/thread/4935?

@bhack Danke fürs Teilen. dieser Thread sieht sehr interessant aus. Ich habe versucht, das DVFS wie vorgeschlagen auszuschalten, aber es wurde keine signifikante Leistung für sgemm in ViennaCL gesehen.

+1

@strin Hast du die letzte sgemm-Version im MALI SDK ausprobiert?

Tensorflow ist spät! ah ah
https://gist.github.com/jarutis/ff28bca8cfb9ce0c8b1a

Dies wird Auswirkungen auf die Strategie haben: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
BEARBEITEN:
"StreamExecutor wird derzeit als Laufzeit für die überwiegende Mehrheit der internen GPGPU-Anwendungen von Google verwendet, und ein Snapshot davon ist im Open-Source-TensorFlow_-Projekt enthalten, wo es als GPGPU-Laufzeit dient."

+1

Ich hoffe, dass es den Leuten, die daran arbeiten, gelingt, das CUDNN-Alternativproblem zu überwinden, bis Tensorflow sich 1,0 nähert

@martinwicke warum ist diese Ausgabe geschlossen?

Ich glaube nicht, dass Ihr Commit das behebt.

Sie können nicht immer dieselben Commit-Kommentare in verschiedenen Repositorys verwenden ;) https://github.com/tensorflow/skflow/issues/22

Ach GitHub

@vrv Nun, da Sie uns überaus benachrichtigt haben, können Sie etwas Feedback zur Stream-Executor-Strategie geben? ;)

Ich werde einfach GitHub für alles verantwortlich machen, einschließlich des Mangels an OpenCL-Unterstützung. ;)

@benoitsteiner kann aber vielleicht mehr kommentieren. Ich weiß nicht wirklich, was Sie mit der „Stream Executor“-Strategie meinen. Wir verwenden derzeit eine Version von Stream Executor sowie CuDNN und Eigen und sie spielen alle gut zusammen, daher bin ich mir nicht sicher, wie sich irgendwelche Pläne für die OpenCL-Seite geändert haben

Ich meine:
„Was ist StreamExecutor?
========================
StreamExecutor ist ein einheitlicher Wrapper um die hostseitigen Programmiermodelle (Laufzeiten) von CUDA und OpenCL . Es lässt Host-Code entweder auf CUDA- oder OpenCL-Geräte mit identisch funktionierenden datenparallelen Kerneln abzielen."

Gespeicherte Operationen
==================
StreamExecutor bietet mehrere vordefinierte Kernel für allgemeine datenparallele Operationen.
Die unterstützten Operationsklassen sind:

• BLAS: grundlegende lineare Algebra-Unterprogramme,
• DNN: Deep Neural Networks,
• FFT: schnelle Fourier-Transformationen und
• RNG: Generierung von Zufallszahlen.

@keryell Hallo, ich interessiere mich auch für die Implementierung von TensorFlow auf FPGA mit höheren Programmiersprachen wie Xilinx C++ oder OpenCL. Ich bin gerne bereit, einen Beitrag zu leisten, wenn Sie einen Plan haben.

@henline Können Sie erklären, was die Rolle von StreamExecutor auf Opencl und von relevantem Canned sein wird
Operationen für Tensorflow. Ich kann immer noch nicht sehen, wie sich dies in SyCL-Pläne für Eigen und cudnn integrieren lässt (Ersatz?)

:+1: Dazu möchte ich auch beitragen.

@bhack StreamExecutor bietet Funktionen, die denen der CUDA-Laufzeitumgebung und einigen CUDA-Bibliotheken (z. B. cublas oder cudnn) entsprechen. Sie müssen jedoch immer noch Ihre GPU-Kernel schreiben, wofür wir Eigen verwenden.

@benoitsteiner Ist es also noch notwendig, zwei Kernel zu schreiben, einen für CUDA und einen für Opencl?

@benoitsteiner Also hast du intern immer noch kein Gegenstück zu tensorflow/tensorflow/stream_executor/opencl/? Was ist mit "Konservenoperatoren"?

@bhack Eigen ermöglicht es Ihnen, einen Ausdruck zu schreiben, der die Berechnung beschreibt, die Sie einmal durchführen möchten, und automatisch einen Kernel (den wir den Evaluator nennen) zu generieren, um diesen Ausdruck auf der CPU auszuwerten, und einen anderen Kernel, um den Ausdruck auf einem CUDA-Gerät auszuwerten. Sobald wir Unterstützung für OpenCL in Eigen haben (wir kommen näher), wird es möglich sein, auch den OpenCL-Kernel automatisch zu generieren.
Für einige leistungskritische TensorFlow-Operationen (z. B. Faltung) verwenden wir handoptimierte Kernel und/oder Bibliotheken von Drittanbietern. In diesen Fällen benötigen wir eine gute OpenCL-Implementierung dieser Operationen.

:+1:

Gibt es einen Plan, mehr Code in https://bitbucket.org/benoitsteiner/eigen-opencl zu pushen? Was ist mit dem Sycl-Compiler? Scheint, dass keine Open-Source-GPU-Zielimplementierungen veröffentlicht wurden.

@bhack @benoitsteiner
Ich veröffentliche bald einen cuDNN-Ersatz (nur den Faltungsteil, da dies am leistungs- und speicherkritischsten ist) für OpenCL auf Caffe. Vielleicht wird es auch für den Tensorflow-Port von Nutzen sein.

@bhack : Codeplay hat an der OpenCL-Front große Fortschritte gemacht. Seien Sie gespannt auf einen großen Push auf https://bitbucket.org/benoitsteiner/eigen-opencl in den nächsten Wochen.

@naibaf7 : Eine schnelle Implementierung der Faltungsoperation wäre in TensorFlow äußerst hilfreich. Sich auf etwas freuen.

@benoitsteiner Guter Fang, sie haben den Stuhl bekommen

@benoitsteiner Wie kann ich die Cuda-Implementierung einfach entfernen? weil '#ifdef GOOGLE_CUDA' so kompliziert ist. Es bedeutet manchmal CUDA, manchmal GPU.

Da dieses Problem seinen Weg in die Roadmap gefunden hat (siehe _Plattformen_): Haben wir ungefähr eine Vorstellung davon, wann die OpenCL-Unterstützung TensorFlow erreichen wird? Wie Version 0.9 / 1.0? Q3/4 2016? Oder ist 2017 realistischer?

@benoitsteiner Ist das eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl bereit genug, um eine Opencl-Tensor-Flow-Entwicklung zu unterstützen?

Hängt Tensorflow nur von Eigen-Tensoren ab oder gibt es andere Abhängigkeiten von Eigen?

@NEELMCW Codeplay hat gerade eine teilweise Unterstützung von OpenCL für Eigen Tensors veröffentlicht. Der Code ist in diesem Bitbucket-Repository verfügbar. TensorFlow hängt zum größten Teil von Eigen-Tensoren ab. Es gibt zusätzliche Abhängigkeiten von Eigen für die Operationen der linearen Algebra, aber wir müssen keine OpenCL-kompatible Implementierung dieser Operationen bereitstellen (zumindest nicht anfänglich). Daher sind wir in einer sehr guten Position, um mit der Unterstützung von OpenCL in TensorFlow zu beginnen.

Wenn Sie daran interessiert sind, einen Beitrag zu leisten, habe ich begonnen, in dieser Tabelle zu verfolgen, was getan werden muss

@benoitsteiner Ich bin Autor einer C++11 OpenCL BLAS-Bibliothek (https://github.com/CNugteren/CLBlast) und implementiere dort derzeit Half-Precision-Unterstützung. Ich freue mich, zum BLAS/GEMM-Teil dieses Projekts beizutragen und/oder CLBlast so zu modifizieren, dass es Ihren Bedürfnissen besser entspricht.

@CNugteren
CLBlast ist jetzt auch in OpenCL-Caffe verfügbar, haben Sie das gesehen? :)
Hatten Sie auch Gelegenheit, sich die Faltungen von libDNN anzusehen?

@naibaf7 Ich habe es gesehen, ja! :) Ich habe mir libDNN bisher überhaupt nicht angesehen, bin mir aber nicht sicher, was du genau meinst. Ich nehme an, die Faltung wird mit GEMM implementiert?

@CNugteren
Ja, ich dachte nur, es wäre nett, wenn Sie darüber nachdenken und vielleicht einige Verbesserungs- oder Tuning-Tipps zu libdnn geben könnten.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Es verwendet GEMM, aber implizit (nicht durch ein BLAS, nur kleine GEMMs auf Arbeitsgruppenebene), sodass ein höheres Maß an Parallelität möglich ist und kein Zwischenpuffer erforderlich ist (um die Daten in ein GEMM-Schema zu entrollen).

Hallo zusammen,

@benoitsteiner danke für die Erwähnung unseres Pushs! Hoffe, es wird nützlich sein!

Um diesen Code zu kompilieren, benötigen Sie einen SYCL-Compiler. Derzeit ist der einzige unterstützte Compiler ComputeCpp von Codeplay, der über ein Evaluierungsprogramm von Codeplay verfügbar ist. ComputeCpp wird später im Jahr 2016 kostenlos als öffentliche offene Beta zur Verfügung gestellt und dann 2017 mit einer kostenlosen Version (der ComputeCpp Community Edition) veröffentlicht. Damit kann jeder TensorFlow auf OpenCL-Geräten wie AMD- oder Intel-GPUs kompilieren und entwickeln und CPUs.

übrigens. sollte dieses Problem nicht OpenCL-Label haben? :)

Danke,
Lukas

Ich hoffe sehr, dass sich das auch mit einem Opensource-Tool kompilieren lässt. @keryell , wie es mit Ihrem neuen Opencl-Zweig läuft

@bhack Es wäre schön zu sehen, ob es zuerst mit triSYCL im CPU OpenMP-Hostgerätemodus funktionieren kann. Aber ich habe nicht die Bandbreite, um jetzt in das TensorFlow/Eigen-Build-System einzusteigen. :-( Wer es ausprobieren möchte, kann das gerne tun. :-)

https://github.com/keryell/triSYCL/commits/opencl sollte es ermöglichen, OpenCL-Kernel bald im OpenCL-Interoperabilitätsmodus auszuführen, aber nicht im SYCL-Single-Source-Modus, von dem wir alle träumen, da wir den Clang/LLVM-Outliner noch nicht haben um die Kernel aus SYCL zu extrahieren. Aber Khronos hat kürzlich die Komponenten von AMD und Intel zur Unterstützung von OpenCL C++ 2.2 und SPIR-V, die die Grundlage dafür bilden würden, als Open-Source freigegeben. Es ist also "nur" eine Frage der Zeit...

Könnte jemand abschätzen, wann Tensorflow möglicherweise mit OpenCL (AMD-GPUs) ausgeführt werden kann? Und wie sieht die Kurve Performance/Usability über die Zeit aus? Es ist schwierig, alle vergangenen Informationen in verwertbare Kaufinformationen für Hardware umzuwandeln. :)

Vielen Dank im Voraus!

@djan92
Ich würde sagen, gib ihm ein Jahr, bis es benutzbar ist, leider. Es sieht so aus, als würde es auf hochmodernen Bibliotheken und Technologien aufbauen, von denen die meisten noch nicht ganz fertig sind.
Ich werde auch erst einsteigen, wenn der komplette Tool-Stack als OpenSource verfügbar ist und nicht vorher.

@naibaf7

Ich würde sagen, gib ihm ein Jahr, bis es benutzbar ist, leider. Es sieht so aus, als würde es auf hochmodernen Bibliotheken und Technologien aufbauen, von denen die meisten noch nicht ganz fertig sind.
Ich werde auch erst einsteigen, wenn der komplette Tool-Stack als OpenSource verfügbar ist und nicht vorher.

Warum nicht zuerst eine CL-Version implementieren, während man darauf wartet, dass der SYCL-Port bereit ist? Ich nehme an, es gibt hier einige Leute, die bereit sind zu helfen. Ein Jahr klingt einfach zu lang.

@djan92
Ja, du hast recht, #22 ist fast 8 Monate alt und hat über 100 Posts! Die Informationen können überschwemmt werden!

Könnte jemand abschätzen, wann Tensorflow möglicherweise mit OpenCL (AMD-GPUs) ausgeführt werden kann?

TensorFlow verwendet die Eigen-Bibliothek für die Tensorberechnung (im Tensor-Modul). Wir haben eine teilweise Implementierung für OpenCL 1.2 mit SYCL (https://bitbucket.org/benoitsteiner/opencl branch Codeplay) festgeschrieben. Der Grund, warum wir SYCL für diese Arbeit verwendet haben, ist, dass dieser Abschnitt von TensorFlow C++-Ausdrucksbäume verwendet, was mit SYCL für OpenCL möglich ist, aber nicht direkt mit OpenCL C. Andere Komponenten von TensorFlow, wie Convolutions oder BLAS, könnten OpenCL C direkt verwenden.

Derzeit arbeite ich daran, ComputeCpp (Codeplays SYCL-Compiler) in das Bazel-Build-System zu integrieren. Dies sollte bald fertig sein (folgen Sie diesem Repo: https://github.com/benoitsteiner/tensorflow-opencl/ ). Danach sollte TensorFlow auf Systemen beschleunigt werden, die OpenCL SPIR (wie AMD oder Intel) mit ComputeCpp unterstützen. Weitere Arbeiten werden fortgesetzt, um mehr von TensorFlow zu beschleunigen und mehr OpenCL-Implementierungen und das triSYCL-Open-Source-SYCL zu unterstützen. SYCL und OpenCL sind herstellerunabhängige, gebührenfreie offene Standards, daher gibt es viele Plattformen und Geräte, die mit diesem Ansatz unterstützt werden können (nicht nur AMD-GPUs).

Der ComputeCpp Community Edition-Compiler wird später im Jahr 2016 kostenlos verfügbar sein (in Beta-Form: vollständige Konformität wird Anfang 2017 kostenlos veröffentlicht).

Die Arbeiten zur Beschleunigung der Nicht-C++-Teile von TensorFlow (z. B. BLAS und Faltungen) könnten ohne SYCL durchgeführt und separat implementiert werden. Verschiedene Hardwareanbieter haben möglicherweise ihre eigenen optimierten Bibliotheken für diese Funktionen, die die Beschleunigung unterstützen könnten. Oder wir könnten Eigen mit C++ für diese Funktionen verwenden.

Und wie sieht die Kurve Performance/Usability über die Zeit aus?

Wir glauben, dass sich die Leistung stetig verbessern wird. Um auf einer Vielzahl von Geräten zu beschleunigen, müssen wir die Daten effizienter verwalten, weshalb es ein „verwaltetes Tensor“-Arbeitselement gibt, damit die Datenbewegung zwischen dem Host und mehreren Geräten effizienter verwaltet werden kann. Es ist derzeit schwer vorherzusagen, wie sich die Leistung bei einer Vielzahl von Geräten unterscheiden wird. Derzeit wird nur sehr wenig beschleunigt, aber wir stellen die Infrastruktur bereit, um Open-Standard-Beschleunigung in TensorFlow zu ermöglichen.

@naibaf7

Ich würde sagen, gib ihm ein Jahr, bis es benutzbar ist, leider.

Die grundlegenden Operationen sollten sehr bald hier sein. Wir stellen die grundlegende Infrastruktur innerhalb des Codes bereit, um eine auf offenen Standards basierende Beschleunigung zu unterstützen. Wir glauben, dass mit Unterstützung der Community eine beschleunigte und nutzbare Version in weniger als einem Jahr fertig sein wird.

Ich werde auch erst einsteigen, wenn der komplette Tool-Stack als OpenSource verfügbar ist und nicht vorher.

ComputeCpp wird 2016 kostenlos öffentlich verfügbar sein. Die Open-Source-Unterstützung von triSYCL sollte folgen. Open-Source OpenCL wird bereits mit pocl, Shamrock, Clover, Beignet unterstützt.

@robertwg
Der C++-Tensorcode in Eigen wäre ohne SYCL nicht leicht auf OpenCL C portierbar, aber es gibt andere Funktionen, die auf OpenCL C gut funktionieren würden. Sehen Sie sich diese Tabelle an: https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 und füllen Sie kostenlos Ihren Namen auf den Funktionen aus, die normales OpenCL C verwenden sollten (wie BLAS und Faltungen).

Wir geben eine Evaluierungsversion für ComputeCpp vor der Veröffentlichung. Wenn Sie möchten, schreiben Sie mir bitte eine E-Mail :)

@lukeiwanski Großartig, danke für das Update. Ich hoffe, Sie haben recht, wenn Sie es in weniger als einem Jahr mit vollem Funktionsumfang fertigstellen.

Ein weiterer Schritt von Streamexecutor in LLVM

Gibt es eine Chance, den RX 480 zu beschleunigen?

@benoitsteiner
LibDNN Standalone wäre für die Integration verfügbar:
https://github.com/naibaf7/libdnn

Schön zu lesen, dass daran gearbeitet wird. Es würde helfen, wenn Beignet 2.0 aufpoliert würde. Viel Potenzial mit Skylake und Iris im Moment.

Ein neuer Pull-Request wurde unter https://github.com/benoitsteiner/tensorflow-opencl/pull/1 hinzugefügt, falls jemand einen Blick darauf werfen möchte.

Das OpenCL SDK von The Imagination (GPU) benötigt NDA, um zugänglich zu werden, wir haben nur die gemeinsam genutzte Bibliothek. Ist es möglich, Tensorflow basierend auf diesen Bibliotheken auszuführen?

@Alefmann
Sie benötigen keine herstellerspezifischen Header-Dateien, um ein OpenCL-Programm zu erstellen. Probieren Sie cl.hpp von https://www.khronos.org/registry/cl/api/1.2/cl.hpp und opencl.h/cl.h von jedem anderen SDK aus. Zum Beispiel - ich habe mindestens 3 OpenCL-Plattformen und alles funktioniert mit einer gemeinsam genutzten /usr/include/CL/cl.h

Wir unterstützen TensorFlow noch nicht, das auf OpenCL ausgeführt wird. Es ist noch in Arbeit. Derzeit arbeiten wir an AMD-GPUs. PowerVR-Support soll folgen. Wenn Sie zur Entwicklung beitragen möchten, sollten Sie sich direkt an uns (Codeplay) wenden. Wenn Sie TensorFlow auf PowerVR ausführen möchten, sollten Sie etwas mehr Fortschritt abwarten.

@inferrna danke, es sieht ähnlich aus wie das OpenGL, das die herstellerspezifische Implementierung verbirgt.

@andrewrichards Ich liebe es, zur Entwicklung beizutragen, wie kann ich mit Ihnen Kontakt aufnehmen?

Am einfachsten ist es, wenn Sie auf unserer Seite hier auf „Registrieren Sie Ihr Interesse“ klicken: https://www.codeplay.com/products/computecpp
Das bringt Sie in unser Entwicklerprogramm und wir können gemeinsam an diesem @alephman arbeiten

Wenn Sie möchten, können Sie auch dazu beitragen, mit einer Open-Source-Alternative kompilieren zu lassen. Siehe https://github.com/tensorflow/tensorflow/issues/22#issuecomment -221841173

Hallo allerseits!
Ich freue mich sehr zu hören, dass die Tensorflow-Unterstützung außerhalb von Nvidia Cuda erweitert wird. Ich frage mich, ob Sie auch erwägen, es auf APUs wie dieser zum Laufen zu bringen: http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
APUs unterstützen OpenCL sowohl für den CPU- als auch für den GPU-Teil.
Dies sollte so ziemlich sofort funktionieren, wenn die OpenCL-Unterstützung bereit ist.
Wenn Sie bereits eine APU haben und ein anderes ML-Framework ausprobieren möchten, funktioniert BVLC OpenCL Caffe bereits.

@naibaf7 Danke für die Klarstellung. Ich suche nach kostengünstigen Hardware-/Software-Kombinationen, um Tensorflow lokal auszuführen, und werde den Entwicklungsfortschritt von OpenCL auf jeden Fall verfolgen.

@hughperkins
Ja, kann ein Problem sein, aber ich denke, Teile wie im2col/col2im und andere Faltungsimplementierungen könnten auch als externe APIs eingefügt werden, wenn es wirklich ein Problem mit der GCLA ist. Dies kann auch für die ursprünglichen Autoren solcher Arbeiten besser sein.

@hughperkins Wir arbeiten daran, die OpenCL über die SYCL für OpenCL 1.2 in TensorFlow zu bringen.
Unter https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 finden Sie Aufgaben und Fortschritte.
Kürzlich haben wir einen Compiler für SYCL https://www.codeplay.com/products/computesuite/computecpp namens ComputeCpp Comunity Edition veröffentlicht. Leute können es ausprobieren!
Außerdem konzentrieren wir uns auf die Eigenbibliothek https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp – um sie auf die von TensorFlows MNIST geforderte Stufe zu bringen – es bleiben noch ein paar Dinge übrig.
In Bezug auf Einschränkungen wurde die aktuelle Version von ComputeCpp CE für Intel (CPU, GPU) und AMD (CPU, GPU) getestet, da wir für die Plattformen Ubuntu 14.04 64bit und CentOS 64bit unterstützen.
ComptueCpp kann kostenlos heruntergeladen werden und kann in kommerziellen und Open-Source-Projekten verwendet werden.
Weil wir <3 Communitys öffnen :)

@lukeiwanski Entschuldigung für die Diskussion/Frage hier im Thread, aber ich denke, es könnte auch für andere von Interesse sein: Ich verstehe, dass Codeplay sehr an der Implementierung von SYCL für OpenCL interessiert ist, und ich habe bereits gehört, dass andere an dieser Arbeit interessiert sind du auch. Ich habe zum Beispiel einen Beitrag von einem Movidius-Beamten gelesen. Allerdings möchte ich fragen, was der Beitrag von Google dazu wirklich ist? Da Movidius, neben AMD und anderen, als Partner von Codeplay aufgeführt sind, kann ich verstehen, dass sie SYCL für OpenCL fördern oder sogar unterstützen, aber soweit mir bekannt ist, ist Google nicht Ihr Partner und hat sich bisher nicht beteiligt?!

Verstehen Sie mich nicht falsch, ich mag Ihre Arbeit wirklich, aber wäre es nicht eine gute Idee, Ihre Bemühungen zu bündeln, die Ressourcen zu bündeln und zu versuchen, mit Google zusammenzuarbeiten? Für mich sieht es so aus, als ob viele verschiedene Parteien an OpenCL für TensorFlow interessiert sind, aber ein riesiges Potenzial nicht genutzt wird, weil sich diese Parteien nicht gemeinsam entwickeln?!

Ich kann mich irren und bitte entschuldigen Sie mich, wenn dies ausreichend diskutiert wurde, aber mir sind noch keine größeren Versuche von Google (oder anderen Parteien) bekannt, an diesem Thema zusammenzuarbeiten, und daher ist mir immer noch nicht bekannt, wie die Community helfen oder unterstützen könnten (wie Einzelpersonen), entweder durch direkte Beiträge, Tests oder andere Dinge.

@ascenator Wir bei Google arbeiten seit fast 12 Monaten eng mit Luke und seinen Codeplay-Kollegen an diesem Projekt zusammen. Der Beitrag von Codeplay zu diesen Bemühungen war enorm, daher waren wir der Meinung, dass wir ihnen die Führung überlassen sollten, wenn es darum geht, Updates im Zusammenhang mit OpenCL zu kommunizieren. Deswegen hast du von uns noch nicht viel zu dem Thema gehört :)

Da der ComputeCpp-Compiler jetzt allgemein verfügbar ist, planen wir, die bisher geleistete Arbeit zusammenzuführen. Aber zuerst wollen wir eine umfassende Testinfrastruktur aufbauen, um sicherzustellen, dass wir die existierende Codebasis nicht destabilisieren.

Wir begrüßen alle Beiträge zu diesen Bemühungen, also zögern Sie nicht, mich zu kontaktieren, wenn Sie helfen möchten. Wir interessieren uns besonders für leistungsstarke OpenCL-Kernel für Matrixmultiplikation und Faltungen. Es wurden mehrere Kandidaten vorgeschlagen, aber wir haben noch nicht begonnen, die Vor- und Nachteile jedes einzelnen zu untersuchen oder wie man sie integriert.

@benoitsteiner vielen Dank für die Klarstellung & sorry für meine Fehlinformation! Das klingt sehr gut und vielversprechend! Dann werde ich mir auf jeden Fall ComputeCpp anschauen. Ich freue mich sehr auf die OpenCL-Unterstützung für TensorFlow, da dies viele neue Möglichkeiten für die Robotik bietet (das ist das Gebiet, in dem ich forsche und TensorFlow für Deep-Learning-Anwendungen einsetze). Ich werde zumindest einen Blick auf frühe Releases werfen und versuchen zu testen / zu debuggen. Wir haben einige Intel-Chips und eine Reihe von ARM-CPUs, die auf Tests warten ;)

@hughperkins ... Entschuldigung, aber ist das hier nicht völlig vom Thema abgekommen? Ich sehe nicht, wie das in OpenCL TF relevant ist?

Ich bin hier mehr daran interessiert zu wissen, ob ein Tuning-Ansatz für Matrixmultiplikations- und Faltungskerne verwendet wird und ob es eine gültige Open-Source-Alternative zu CompiteCpp geben wird, die SPIR-V produzieren wird.

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

Zwei neue Standards der Kronos Group werden unter https://www.khronos.org/news/press/khronos-launches-dual-neural-network-standard-initiatives veröffentlicht

Wenn es hilft, gibt es eine bessere Version von isaac: https://github.com/ptillet/isaac , und bietet erhebliche Beschleunigungen gegenüber clBLAS und cuBLAS auf Maxwell, Pascal und Fidschi. Bietet auch schnellere (eingabebewusste) Kernel als Tensorflow für 1D- und 2D-Reduktionen.

@hughperkins scheint mehr Chancen zu haben, einen CUDA-Compiler für jedes OpenCL-Gerät zu schreiben, als einen CUDA-OpenCL-Übersetzer.

@hughperkins Vielleicht könnte die SVM-Funktion von OpenCL 2.0 das Zeigerproblem lösen? Da alle außer Nvidia (AMD, Intel, ARM, Qualcomm) damit beginnen, OpenCL 2.0 zu unterstützen. Vielleicht ist es eine gute Lösung?

@hughperkins es ist selbst eine Blas-Implementierung. Es implementiert einige der Symbole in clblas- und cublas-Headern, also keine Neukompilierung und Code-Änderung. ist notwendig. Ich könnte auch einige der Symbole für clblast.h implementieren, da es einen anderen Header verwendet. Einige Vorteile von Isaac sind:

• Völlig dynamisch, so dass es ohne Neukompilierung entweder CUDA oder OpenCL verwenden kann.
• Input-aware, es stimmt keine Kernel für große quadratische Matrizen ab. Es sollte bei allen Formen, die Sie sich vorstellen können, ohne Neuabstimmung gut funktionieren.
• C++-API ähnlich wie numpy/arrayfire. Etwas Fusion zum Kombinieren von elementweisem Betrieb mit Reduktionen

@marty1885
Nicht wirklich. AMD kehrte zur 1.2-Unterstützung der AMDGPU-PRO-Treiber zurück. Es kann noch eine Weile dauern, bis die volle 2.0-Unterstützung weit verbreitet ist. Definitiv keine kurzfristige Lösung.

• Jawohl
• Ich könnte bei Bedarf die Kompatibilität für eine Reihe von Operationen hacken (z. B. **MV an GEMV weiterleiten). Komplexe Unterstützung wird schwierig sein. Doppelte Unterstützung ist bereits vorhanden, aber keine Architektur ist darauf abgestimmt.

@hughperkins

Scheint, als würde mein Code keine offensichtlichen OpenCL-Regeln verletzen

Ja, das einfache Übergeben einer __global-Struktur (wie Array oder Struktur), die Zeiger enthält, ist falsch, nur weil diese Zeiger auf den Speicher eines anderen Geräts zeigen können (OpenCL unterstützt ein Multi-Device-Paradigma, bei dem ein Gerät nicht auf den Speicher eines anderen zugreifen kann). Aber es scheint möglich zu sein, auf IR-Ebene zu überwinden, ohne Zwischenübersetzung in OpenCL-Code - das habe ich angenommen :)

@benoitsteiner , @henline , von https://github.com/henline/streamexecutordoc , es schlägt vor, dass der streamexecutor die vorgefertigte Operation der CL-Version (wie DNN, BLAS) standardmäßig unterstützt hat. Bedeutet es, dass Google bereits die clDNN-, clBLAS-Implementierung für Tensorflow bereit hat, aber noch nicht Open Source?

Ansonsten unterstützen OpenCL 2.0+ und SYCL 2.2 SVM, wenn Sie dieselbe Softwarearchitektur beibehalten möchten.
OpenCL 2.0+ wird beispielsweise von AMD und Intel GPU unterstützt. In der Embedded-Welt wird es oft per Nebeneffekt sogar mit OpenCL 1.x unterstützt, da Host- und Device-Speicher aus Kostengründen oft gleich sind.

@kerell
Aber die bemerkenswertesten Plattformen, Linux + die neuen AMD-GPUs (RX 480, kommende Vega) unterstützen vorerst nur OpenCL 1.2 ... und wer weiß, wann sich das ändern wird (ich wette, in einem Jahr). Beignet (Opensource Linux Intel) für OpenCL 2.0 ist auch noch ein fehlerhaftes Durcheinander; die stabile Version hat 1.2.
Auch wenn man bedenkt, dass all die kleineren Unternehmen, die OpenCL-kompatible Chips herstellen, kaum 1.2-Unterstützung ziehen. Ich denke also, dass alles, was sich auf OpenCL 2.0 stützt, in der Praxis sehr schlechte Anpassungsraten aufweisen wird.

Ich denke, jeder Hardware-Vedor hat die Dringlichkeit, SPIR-V zu konsumieren? Ich denke, dass der Druck von Grafik/Shadern auf Vulkan der Opencl-Seite helfen könnte.

@naibaf7 zurück zur Diskussion über OpenCL 2 oder nicht, irgendwann müssen echte Sachen geliefert werden... Ansonsten läuft schon nVidia GPU und CUDA mit TensorFlow... :-)
Aber natürlich hat eine Version von TensorFlow ohne SVM ein gewisses Interesse.

@keryell Wie viel der Vulkan SPIR-V-Arbeit an Treibern (die bereits eine gute Geräteabdeckung haben) wird Ihrer Meinung nach moderne Opencl-Versionen vorantreiben?

@naibaf7 Das Khronos-Treffen findet nächste Woche in Seoul mit OpenCL- und Vulkan-Leuten statt, aber die Diskussionen sind nicht öffentlich. Aber das klingt nach einer guten Idee, jede Welt zu haben, um die andere zu verbessern, und irgendwann profitiert TensorFlow davon. :-)

@kerell
Ja, ich hoffe, sie diskutieren einige nützliche Dinge für DeepLearning :)

Herzlichen Glückwunsch! Achten Sie darauf, das HIP-Projekt zu überprüfen, da sie versucht haben, das gleiche Problem zu lösen. Sie entschieden sich dafür, eine neue Sprache namens HIP zu erstellen, die definiert, was manuell konvertiert werden muss (wie die Überprüfung der Unterstützung doppelter Genauigkeit durch Überprüfung der Rechenebene). Während das Projekt fortschreitet, würde die Menge der manuellen Übersetzungen sinken. Siehe: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

Mein Vorschlag für Sie ist, HIP zu verwenden und einige Fehler zu beheben, die das Vorantreiben von Tensorflow oder Ihre eigenen Ziele blockieren, da Sie jetzt das Verständnis von LLVM haben, um dies zu tun. Auf diese Weise müssen Sie die bereits behobenen Probleme nicht lösen.

@hughperkins
kann kein Python-Modul mit Ihrem Fork erstellen, indem Sie diesem https://github.com/tensorflow/tensorflow/blob/master/tensorflow/g3doc/get_started/os_setup.md#create -the-pip-package-and-install folgen

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.

Ich bin auf Ubuntu 16.04, dirname ist von coreutils-8.25-2ubuntu2

@hughperkins Ich denke, dass das Optimieren der TF-Dockerdatei in Ihrem Repository mit diesen Anweisungen die Einrichtung für andere vereinfachen könnte.

Ja, wenn es etwas Funktionaleres geben wird. Im Grunde ist es eine ziemliche Kopie und Vergangenheit dieser Anleitung, die Sie gepostet haben.

Ich experimentiere damit, dies unter MacOS 10.10.5 auf einem MacBook Ende 2015 mit ATI 6770M (OpenCL 1.2) zu erstellen.

Ich habe Xcode 8, Anaconda (Python 3.5) und MacPorts-Äquivalente von clang+llvm installiert:

Anstelle von apt-get-Zeilen tun Sie Folgendes:

sudo port install clang-3.8 llvm-3.8

Anstatt /proc/cpuinfo zu verwenden, tun Sie Folgendes:

NUM_PROCS=$(system_profiler SPHardwareDataType | grep "Gesamtzahl der Kerne" | cut -d ":" -f 2)

Ändern Sie dann Makefile, um Macports zu verwenden, und führen Sie make aus

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

Update auf Macos OpenCL-Verzeichnisse; future: use /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' bedingt

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

So weit ich komme:

$ make -j ${NUM_PROCS}
mkdir -p bauen
mkdir -p bauen
mkdir -p bauen
/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
In der Datei enthalten von src/hostside_opencl_funcs.cpp:17:
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: Warnung: 'host'-Attribut ignoriert [-Wignored-attributes]
Attribut ((Host)) inline unsigned long long atomicExch(volatile unsigned long long _p, unsigned long long val) {
^
src/hostside_opencl_funcs.cpp:194:33: Fehler: Aufruf der Mitgliedsfunktion „in“ ist mehrdeutig
launchConfiguration.kernel->in(offset);
~ ~ ~ ~ ~ ~~~^~
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15: Hinweis: Kandidatenfunktion
CLKernel in (Float-Wert);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15: Hinweis: KandidatenfunktionCLKernel * in (int32_t-Wert);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15: Hinweis: KandidatenfunktionCLKernel * in (int64_t-Wert);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15: Hinweis: KandidatenfunktionCLKernel * in (uint64_t-Wert);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15: Hinweis: KandidatenfunktionCLKernel * in (uint32_t-Wert);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15: Hinweis: Kandidatenfunktion nicht realisierbar: keine bekannte Konvertierung von „size_t“ (auch bekannt als „unsigned long ') zu 'easycl::CLArray *'für das 1. argumentCLKernel * in (CLArray * clarray1d) { return input (clarray1d);



}^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36: Hinweis: Kandidat-Funktionsvorlage nicht realisierbar: erfordert 2 Argumente, aber 1 wurde bereitgestelltVorlageCLKernel *in(int N, const T *data);^1 Warnung und 1 Fehler generiert.make: *_* [build/hostside_opencl_funcs.o] Fehler 1machen: * * Warten auf unvollendete Jobs....
src/struct_clone. cpp: 245 : 12: Warnung: 11 Aufzählungswerte werden nicht im Schalter behandelt: 'HalfTyID', 'X86_FP80TyID', 'FP128TyID' ... [-Wswitch]
Schalter (TypID) {
^
1 Warnung generiert.

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

Dieser Patch hat funktioniert. Danke.

Nachdem dies angewendet wurde, führte das Fortsetzen des Builds zu size_t-Namespace-Fehlern:

$ make -j ${NUM_PROCS}
mkdir -p bauen
mkdir -p bauen
/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
In der Datei enthalten von src/hostside_opencl_funcs. cpp:17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: Warnung: 'host'-Attribut ignoriert [-Wignored-attributes]
Attribut ((Host)) 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 Warnung generiert.
/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
In der Datei enthalten von src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:8:9: error: no type named 'size_t' in namespace 'std'; Meinten Sie einfach 'size_t'?
typedef std::size_t cublasStatus_t;
^ ~ ~
Größe_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklariert
typedef SIZE_TYPE size_t;
^
In der Datei enthalten von src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:17:5: error: no type named 'size_t' in namespace 'std'; Meinten Sie einfach 'size_t'?
std::size_t cublasCreate(cublasHandle_t phandle);^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef SIZE_TYPE size_t;^In der Datei enthalten von src/cocl_blas.
Meinten Sie einfach 'size_t'?std::size_t cublasDestroy(cublasHandle_t handle);^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef SIZE_TYPE size_t;^In der Datei enthalten von src/cocl_blas.
Meinten Sie einfach 'size_t'?std::size_t cublasSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef SIZE_TYPE size_t;^In der Datei enthalten von src/cocl_blas.
Meinten Sie einfach 'size_t'?std::size_t cublasSetPointerMode(cublasHandle_t handle, cublasPointerMode_t mode);^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef SIZE_TYPE size_t;^In der Datei enthalten von src/cocl_blas.
Meinten Sie einfach 'size_t'?std::size_t cublasGetPointerMode(cublasHandle_t handle, cublasPointerMode_t *mode);^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef SIZE_TYPE size_t;^In der Datei enthalten von src/cocl_blas.
Meinten Sie einfach 'size_t'?std::size_t cublasSetStream(cublasHandle_t handle, cudaStream_t streamId);^ ~ ~Größe_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: Hinweis: Hier wird 'size_t' deklarierttypedef 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 Fehler generiert.make: *_* [build/cocl_blas.o] Fehler 1make: * * Warten auf unvollendete Jobs....

Können wir einen langen Log-on-Gist pushen, damit der Thread noch lesbar bleibt?

Frage: Wie lösen Sie das Problem der Adressräume?

@hughperkins Die in Abschnitt 5.8 ("Address-space deduction") beschriebenen SYCL-Spezifikationen
wie eine Implementierung mit unterschiedlichen Speichertypen umgehen muss. Dies
ähnelt früheren Arbeiten für PlayStation 3 und ist in beschrieben
dieses Whitepaper: Offload – Automating Code Migration to HeterogeneousMulticore-Systeme oder C++ auf Beschleunigern: Unterstützung von Single-Source-SYCL- und HSA-Programmiermodellen mit Clang

Ich hoffe, das hilft.

@hughperkins Kann ich Ihren Tensorflow-Opencl-Repo-Code kompilieren, um mein ARM-Board anzuwenden? Mein ARM-Board verfügt über eine Imagination-GPU, die opencl 1.2 unterstützt.

Ich bin auf diesen Thread gestoßen, als ich nach tf/intel-Support gesucht habe.

Ich habe ein Intel MacBook Pro, wie kann ich helfen? Ich kenne c/c++ nicht, aber ich kann Anweisungen zum Erstellen/Kompilieren/Testen folgen und Ergebnisse (Pastebin) zurückgeben ...

derek$ system_profiler SPDisplaysDataType
Grafik/Displays:

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 Danke für deine Anleitung!
Ich versuche, Ihr cuda-on-cl auf einer Armplattform zu kompilieren. Befolgen Sie die Anleitung Ihres cuda-on-cl:
Meine ARM-Board-Info:
arm64, gcc 4.9, clang und llvm 3.5, openCL 1.2

* Muss ich die Version clang++-3.8 verwenden? *
git clone --recursive https://github.com/hughperkins/cuda-on-cl
machen
Error:
clang++-3.8: Befehl nicht gefunden
Ich bearbeite das Makefile wie folgt: CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
dann nochmal machen:
Error:
src/mutations.h:3:10: schwerwiegender Fehler: Datei „llvm/IR/Module.h“ nicht gefunden

try run make run-test-cocl-cuda_sample:
make: cocl: Befehl nicht gefunden

@hughperkins lass es mich versuchen.

Beim Testen von Keras mit Tensorflow ist ein Fehler aufgetreten

keras$ KERAS_BACKEND=tensorflow pytest3

Ausgabefehler:

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];
}

Hallo zusammen, mein Name ist Ricardo, ich bin ein C++-Programmierer mit vielen Jahren Erfahrung in C++ und wenig Cuda, ich werde mich freuen, zu diesen Bemühungen beizutragen. Wie kann ich zu diesem Job beitragen?

Ok, ich habe ein Odroid Xu3 mit einem Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 und OpenCL 1.1 Vollprofil)
läuft auf Betriebssystem: LUbuntu 1404 64 Bit
Ich werde eine vollständige Installation vornehmen und das Ergebnis auf dieser Plattform veröffentlichen.
Was Bugs betrifft, gibt es eine Liste von Bugs (so etwas wie Bugzilla?) oder eine Tabelle mit einer Liste von Bugs?
Prost!

Was ist mit der Verwendung von 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
"Ihr Wunsch wird erfüllt, Eigen wird über HIP über AMD GPU portiert. Der zweite Teil Ihrer Anfrage lautet: Können wir ein standardisiertes Tool mitbringen, das FLOAT16 unterstützt, das mit allen unseren GFX8-GPUs geliefert wird, Wunsch erfüllt."
Unser Entwicklungszweig des AMDGPU-Compilers unterstützt jetzt sowohl die native Float16- als auch die Int16-Anweisung, anstatt FP16/Int16 mit Aufwärtskonvertierungs- und Abwärtskonvertierungsanweisungen zu emulieren, um von FP16/Int16 in Float und zurück zu konvertieren.

Dies sind f16-Tests auf Fidschi-Hardware, die erfolgreich eine Matrixmultiplikation mit Halbtypen mit Konvertierung und mit nativen Anweisungen ausführen.

Auch nicht verwandt, aber Sie sollten syCL/openCL 2.0 anstelle von 1.2 verwenden, da nvidia bereits über CUDA unterstützt wird. Und openCL 2.0 wird sowohl von AMD- als auch von Intel-Windows-Treibern unterstützt. Auch AMD hat gesagt, dass sie bald einen openCL 2.0-Treiber für Linux (der von Intel verwendet werden könnte, Opensource-Magie) öffnen werden (und Intel hat bereits eine Linux-openCL 2.0-Implementierung, die nur ausgereift werden muss). Wenn Sie Intel und AMD fragen, vielleicht sie könnten die Arbeit beschleunigen, denn Tensorflow ist wichtig für ihre wirtschaftlichen Interessen. Und sie haben bereits in diesem Kommentarbereich gesagt, dass sie helfen wollten. Auch alle großen ARM-Hersteller unterstützen openCL 2.0. Dies könnte viele Möglichkeiten für Android (was im wirtschaftlichen Interesse von Google liegt), Himbeer-ähnliche Smart-TVs usw. eröffnen

Und mittelfristig könnten wir schließlich eine opencl 1.2-Fallback-Schicht für nicht unterstützte Hardware entwickeln.
Und die Implementierung sollte auch openVX verwenden (das jetzt von allen großen Hardwareherstellern unterstützt wird und AMD eine Opensource-Implementierung hat) und mit https://www.khronos.org/news/press/khronos-launches-dual-neural-network -Standard-Initiativen
Und das alles mit Spir-V (das gleichzeitig von Vulkan und OpenGL genutzt werden kann).
Man könnte sagen, dass ich das bereits Gesagte dupliziere, aber Synthetisieren ist wichtig.
Und schließlich, könnte Tensorflow HSA verwenden?

http://www.hsafoundation.com
HSA wäre genial auf Android.

Ich weiß nicht, ob HIP nützlich wäre oder nicht. Es wird nur auf einigen AMD-Karten unterstützt, sodass wir sowieso eine OpenCL-Implementierung benötigen, wenn wir alle Geräte unterstützen wollen. Es könnte sich dennoch lohnen, wenn die HIP-Implementierung deutlich schneller ist. Dies könnte der Fall sein, aber ich habe noch nicht viele Benchmarks (HIP vs. OpenCL) gesehen. Ein weiterer Grund könnte MLOpen (das in HC geschrieben ist) als Ersatz für cudnn sein, aber auch hier habe ich keine Ahnung, wie schnell das ist oder welche Funktionen es unterstützt.

TensorFlow würde HSA nicht direkt verwenden, da es ziemlich niedrig ist. Aber HC (und HIP) wird darüber implementiert, und Sie können auch OpenCL darüber implementieren (pocl macht das).

Wäre der Relooper-Algorithmus hier hilfreich? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins Schön zu sehen, dass Sie einige Fortschritte mit Ihrem Compiler gemacht haben, aber ich denke, es wird für TensorFlow nicht zum Thema. Sie sollten stattdessen viele kleinere Diskussionsthreads auf der GitHub-Seite Ihres Compiler-Projekts starten. Es wäre konzentrierter und produktiver, denke ich.

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

Es gibt auch https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.cpp

Hier ist das zugehörige Papier: https://github.com/kripken/emscripten/blob/master/docs/paper.pdf?raw=true

Die anfängliche OpenCL/SyCL-Unterstützung wurde im Master mit https://github.com/tensorflow/tensorflow/pull/5267 zusammengeführt

Glückwünsche!

@keryell Übrigens , was ist mit dem triSYCL-Repository passiert? Es scheint weg zu sein und ich kann nur einen Verweis auf das Gitlab von Khronos finden, das nicht öffentlich zugänglich ist.

EDIT: Ich habe deinen privaten Klon gefunden, nur der von amd ist weg.

@bhack , unterstützt der Opencl-Docker auf der Mac-Plattform?

@alephman Ich habe keine OSX-Plattform, aber ich denke, dass eine kleine Anpassung des Startbefehls funktionieren könnte.

@bhack @alephman : Siehe meinen Kommentar zu Mac oben, wenn Sie mich auf die Bauanleitung verweisen, werde ich es versuchen

@olesalscheider : Ja, triSYCL ist von AMD zu Xilinx https://github.com/Xilinx/triSYCL umgezogen, aber Sie haben Recht, die Version auf meinem GitHub-Arbeitsbereich funktioniert auch unter https://github.com/keryell/triSYCL

Wir haben triSYCL auf TensorFlow noch nicht ausprobiert. Es gibt bereits eine große Build-Konfigurationsarbeit zu erledigen, nur um es zu versuchen ...

@keryell Was ist der triSYCL-Status?

Die Unterstützung von Intel beignet opencl 2.0 ist fast fertig!
http://phoronix.com/scan.php?page=news_item&px=Beignet-Geburtstag-CL2

@bhack triSYCL wird jetzt hauptsächlich bei Xilinx entwickelt. Es werden immer mehr Funktionen hinzugefügt. Der Clang/LLVM-basierte Outlining-Compiler befindet sich noch in der Entwicklung, um eine vollständige Single-Source-Erfahrung auf einem Gerät zu ermöglichen. Aber der bereits implementierte OpenCL-Kompatibilitätsmodus hat auch einen gewissen Wert, indem er die Kommunikation zwischen Host und Kernel vereinfacht, wobei die SYCL-Laufzeit die verzögerten Übertragungen gemäß den von den Zugriffsmethoden ausgedrückten Abhängigkeiten durchführt.

Mein Mac ist OpenCL-kompatibel, wie kann ich also meinen Tensorflow mit OpenCL ausführen? Ich habe gerade festgestellt, dass opencl in Tensorflow unterstützt wurde, als ich die neuen Codes konfigurierte.

@hughperkins es gibt keine clinfo Anweisung in meinem Mac, was kann ich dafür tun? Aber ich kann den Testcode hier für opencl mit Clang kompilieren und die folgenden Informationen erhalten:
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

Danke @hughperkins , aber ich glaube, ich hatte gestern die computecpp ausprobiert, und es scheint, dass das Macbook-System immer noch nicht von computecpp unterstützt wird. Vielleicht ist das Warten auf neue Updates das Einzige, was ich tun kann (TT). Übrigens, meine Iris 6100 ist die achte Generation, was gut für OpenCL 1.2 ist.

@hughperkins ja SYCL 1.2 ist a priori für OpenCL 1.2 und SYCL 2.2 ist a priori für OpenCL 2.2.
Ich sagte "a priori", denn wenn Sie nichts verwenden, das den OpenCL-Kompatibilitätsmodus von SYCL erfordert, benötigt SYCL OpenCL überhaupt nicht wirklich. Tatsächlich ist SYCL ein sehr generisches Modell für heterogenes Computing und kann auf allem laufen. Aber natürlich kann eine echte Implementierung auch OpenCL erfordern.

Hallo,

Ich lerne/arbeite derzeit mit TensorFlow und Keras und wäre daran interessiert, die OpenCL-Unterstützung unter macOS zum Laufen zu bringen ... Gibt es Neuigkeiten zur Arbeit rund um macOS?

Es ist mir gelungen, TensorFlow zu kompilieren, aber wenn ich versuche, es für OpenCL zu konfigurieren, fragt es mich nach dem Speicherort von computeCpp 1.2, und es scheint mir, dass es kein ComputeCpp für macOS gibt.

Hallo. Auf keinen Fall ein Experte für ML / Tensorflow / oder sogar OpenCL, aber ich bin ein erfahrener Mac-Grafikentwickler, der unbedingt eine schnellere Leistung von Tensorflow auf Systemen mit integrierten und AMD-GPUs haben möchte, die integrierte Bibliotheken und einfache Abhängigkeiten verwenden :)

Wie kann ich helfen?

Wenn Sie sich den letzten Kompilierungsfehler unter OS X im Travis-Protokoll @hughperkins ansehen , sieht es so aus, als ob das Ausführen von 'xcode-select --install' eine Lösung sein könnte? Es sollte das Verzeichnis /usr/include neu verknüpfen. Ich hatte dieses Problem selbst, als ich Xcode Beta auf die Veröffentlichung aktualisierte, und hatte Probleme beim Kompilieren von C++-Code.

Es scheint, als würde der XLA-Compiler (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) LLVM-Codegenerierung aus Datenflussdiagrammen bereitstellen. Dies bedeutet einen sehr einfachen Zugriff auf spir-v und damit auf die Compute-API von Vulkan. Mit der aussortierten Codegenerierung kann ich mir nicht vorstellen, dass Google angesichts der hohen Anzahl ungenutzter integrierter GPUs, die auf Android laufen, keine Vulkan-Kompatibilität bietet.

@hughperkins

Schnell: Im Moment führe ich Inception v3 auf einer benutzerdefinierten C++ / Object-C-Codebasis aus und übergebe decodierte Videoframes an das Netzwerk. Ich weiß nicht genug über TF, um die Anforderungen auf niedriger Ebene zu kennen, aber auf hoher Ebene: Modelle laden, Sitzung ausführen, erwarten, dass Dinge funktionieren. Ich denke, das bedeutet 100% Kompatibilität, um wirklich ehrlich zu sein. Ich weiß, das hilft nicht beim Priorisieren. Grundsätzlich war die C++ Bilderkennung mit TF /InceptionV3 mein Ausgangspunkt.

cuda-on-cl läuft auf Mac: Ich habe das Repo ausgecheckt und kann beim Debuggen und Ausführen von Builds auf meinen Systemen helfen und Ergebnisse auf einer Vielzahl von Hardware überprüfen: Ich habe Zugriff auf AMD Mac Pros mit Dual D700s, Nvidia Mac Laptops und Desktop-Systeme.

Vielen Dank für Ihr ausführliches Feedback. Ich werde das Repo überwachen, versuchen, mitzumachen, und versuchen, so gut ich kann zu helfen.

Hugh, vielleicht möchten Sie sich http://chrec.cs.vt.edu/cu2cl/ ansehen, um zu erfahren, wie einige Funktionen abgebildet werden.

In meiner Firma StreamComputing haben wir verschiedene GPUs für Build-Tests und Benchmarking, die wir für unsere Kundenprojekte verwenden. Ich könnte Ihren Github in unseren Jenkins einbinden, um einen wöchentlichen Lauf durchzuführen.

Vielen Dank für die Antwort, ich werde diese Woche bei der Arbeit mit bestimmten Skripten auf das Thema zurückkommen.

Meine Anwendungsfälle drehen sich um Text-/Syntax-Matching-Analysen, wobei ich Gensim und Keras/Tensorflow in meinen Experimenten verwende.

Beim Testen bin ich gerne behilflich

Ich habe einen Windows-PC mit einer AMD-Karte
Ein MBP mit einer AMD-Karte
Ein MB mit integrierter Intel-GPU

Hey @hughperkins - Ich gehe heute Abend den obigen Testsatz auf einer AMD R9 390 8GB durch. Bisher habe ich bereits ein anderes Ergebnis; logistic_regression.py trainiert und gibt nan nicht zurück. So gut! Es segfaults am Ende, also werde ich untersuchen, ob das Skript oder der cl-Code schuld ist.

Wo soll ich meine Ergebnisse pushen, wo sie für Sie am nützlichsten sein können?
Vielleicht könnten wir ein Standard-„Testskript“ bekommen, das einen Standardsatz von Ergebnissen generiert, die Freiwillige zu Ihnen schicken können (oder auf lokalen CIs oder was auch immer einrichten)?

py.test ist eine so gute Lösung wie jede andere; es ist nur pip entfernt und das ist sowieso Teil des Installationsvorgangs für tensorflow .

Ich habe seit Beginn meiner Tests ein paar interessante Dinge entdeckt, die jedoch möglicherweise nicht mit der Python-Ausgabe allein debuggt werden können:

• Verschiedene Aufrufe desselben Skripts können früh abstürzen oder "hängen" (keine Ausgabe, kein Fortschritt, keine Antwort auf Ctrl-C , Prozess muss pkill -9 'd sein) oder können spät abstürzen entweder beim Validierungsteil oder nachdem das Skript erfolgreich abgeschlossen wurde. Abstürze (Segfaults) können Xorg zum Erliegen bringen.
• Die Ergebnisse variieren scheinbar ohne Grund: Ich kann ein Skript aufrufen und es segfault haben, es dann erneut aufrufen und es wird funktionieren.
• Hänge können in Teilen des Codes auftreten, die vor wenigen Augenblicken buchstäblich funktionierten. Ich hatte einen Hänger innerhalb oder nach einem Trainingsstapel, nachdem mehrere hundert Stapel gerade erfolgreich ausgeführt wurden.

Es könnte also sein, dass es auf der GPU-Seite ungelöste Dinge gibt und dass ein guter Segfault benötigt wird, um sie zu löschen? Ich weiß noch nicht viel über das GPU-Modell oder OpenCL, daher kann ich hier nicht viel beitragen. Es kann jedoch sein, dass die GPU-Debugging-Ausgabe erforderlich ist, um richtig zu untersuchen, was passiert.

Außerdem dachte ich, Sie wären von Ihrem Github aus bei AMD, aber es scheint, dass Sie ein "Rogue Agent" sind, der diese ganze CUDA-auf-CL-Sache in Ihrer Freizeit macht. Herzlichen Dank, dass Sie dies vorangetrieben haben! Gibt es eine Möglichkeit, wie ich und andere zu Ihren Bemühungen beitragen können, vielleicht indem wir Ihnen eine GPU per Crowdfunding finanzieren? Oder Sie könnten einen Patreon einrichten, ich melde mich gerne für einen monatlichen Beitrag zum Projekt an?

Bei AMD GPUs sind wir Partner von AMD. Siehe meine Nachricht von vor 8 Tagen, die Sie vielleicht verpasst haben:

In meiner Firma StreamComputing haben wir verschiedene GPUs für Build-Tests und Benchmarking, die wir für unsere Kundenprojekte verwenden. Ich könnte Ihren Github in unseren Jenkins einbinden, um einen wöchentlichen Lauf durchzuführen.

Ich frage mich, ob Sie vielleicht die Möglichkeit haben, einen CI-Server einzurichten, der bei jedem Commit läuft?

Kein Problem. Ich brauche wahrscheinlich Schreibzugriff auf das Projekt, damit Jenkins die Protokolldatei in ein Build-Log-Verzeichnis schreiben kann. Ich spam dich nur zu, damit wir diskutieren können.

Hallo alle,

Wie Sie wahrscheinlich bereits sehen, wurde eine Menge SYCL-Zeug zu TensorFlow gepusht. Wir sind noch nicht fertig, und es gibt viel zu tun. Aber wir machen Fortschritte, um dorthin zu gelangen.

Wenn Sie daran interessiert sind, einen Beitrag zu leisten, oder einfach nur neugierig auf den aktuellen Stand sind, sehen Sie sich die Aufschlüsselung unten an.

Infrastruktur
Google hat freundlicherweise zwei Maschinen gespendet, die dafür eingerichtet sind, @benoitsteiners Fork von TensorFlow (https://github.com/benoitsteiner/tensorflow-opencl) regelmäßig zu testen

Beide haben AMD-GPUs:

CL_DEVICE_NAME : Hawaii
CL_DRIVER_VERSION: 1912.5 (VM)

und

CL_DEVICE_NAME : Fidschi
CL_DRIVER_VERSION: 1912.5 (VM)

Wir bei Codeplay wollen auch nächstes Jahr Maschinen dedizieren. Um die Diversity-Abdeckung von OpenCL-Geräten zu verbessern.

Wir suchen an dieser Front nach Mitwirkenden, wenn jemand daran interessiert ist, einen Test-Build-Server für relevante Plattformen bereitzustellen, die wir unterstützen.
Derzeit sind die Anforderungen:
- Ubuntu 14.04
- OpenCL-Treiber, die SPIR unterstützen (Intel CPU/GPU oder AMD GPU)

@VincentSC vielleicht könntest du da aushelfen?

Prüfungen
Auf der Fidschi-Maschine ( https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull ) sind wir mit 164 Fehlern konfrontiert.

Auf der Hawaii-Maschine ( https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull ) sind wir auf 56 Fehler gesunken.

Wir untersuchen die Behebung der fehlgeschlagenen Gradiententests und untersuchen die Ursachen der zusätzlichen Fehler auf der Fidschi-Maschine.

Eigen
In den letzten Monaten haben wir aktiv Funktionen implementiert, die von TensorFlow benötigt werden, darunter: Reshaping, Slicing, Basic Reduction usw. Derzeit implementieren wir Contraction. Eine detaillierte Aufschlüsselung finden Sie auf der Registerkarte Eigentensor von https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

TensorFlow
Viele koeffizientenbezogene Operationen wurden implementiert, darunter Abs, Floor, IsFinite, Log, Pow, Mul usw. sowie Tensor-Manipulationen wie Reshape, Shape, Identity, Fill usw.
Eine detaillierte Aufschlüsselung finden Sie auf der Registerkarte TensorFlow-Kernel unter https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219

Organisation
Die obige Tabelle hat mehrere Registerkarten, die die Bemühungen des Projekts kategorisieren, wie: Gesamtplan, Eigen-Tensor, TensorFlow-Kernel, Modelle.

Wenn Sie sich beteiligen möchten, setzen Sie bitte Ihren Namen neben das Thema, an dem Sie arbeiten, oder fügen Sie alles Wichtige hinzu, das fehlt.
Danke,
Lukas

Ist diese Roadmap aktiv?

@lukeiwanski Ja, kein Problem. Kontaktieren Sie uns über [email protected]

Nachdem ich das alles gelesen habe, vermute ich, dass es noch keine solide Lösung für die Verwendung von OpenCL unter macOS/OS X gibt? Ich habe versucht, Tensorflow C++ mit OpenCL-Unterstützung zu kompilieren (wovon ich annehme, dass ComputeCpp für SYCL 1.2 erforderlich ist, wie jemand darauf hingewiesen hat).

Ich sah mich um und konnte anscheinend nicht finden, wo ich die SYCL-Bibliothek herunterladen, kompilieren oder erstellen könnte. Ist es hier https://www.codeplay.com/ ? Ich bin mir wirklich nicht sicher, wie ich weiter vorgehen soll, danke ...

@dylib Soweit ich weiß, gibt es noch kein ComputeCpp für macOS. Das bedeutet also, dass OpenCL für macOS noch nicht bereit ist.

Kann es immer noch nicht unter Ubuntu 16.04 mit AMD-Karte und Katalysatortreiber https://github.com/tensorflow/tensorflow/issues/6497 zum Laufen bringen. Gibt es eine Anleitung?

Ich musste mir die Ausgabe von /usr/local/computecpp/bin/computecpp_info ansehen, bevor ich versuchte, TF zu verwenden, das mit OpenCL-Unterstützung kompiliert wurde. In meinem Fall zeigt es

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

Jetzt gibt es zwei Möglichkeiten, TF auf der GPU auszuführen:
funktioniert gut auf einer begrenzten (je nach Hersteller) Anzahl von Geräten, aber proprietäres CUDA
schlechtes Arbeiten auf einer begrenzten (von Computecpp-Entwicklern) Anzahl von Geräten und auch proprietärem Computecpp
Immer noch keine OpenCL-Unterstützung.

@inferrna Es gibt einen OpenCL-spezifischen Abschnitt in der gesamten TensorFlow-Dokumentation. Dies wird in Kürze auf der Website tensorflow.org veröffentlicht.

@benoitsteiner Wie ist der aktuelle Stand der Unterstützung von opencl-Konvolutionen? Planen Sie, die vorhandenen Kernel direkt zu nutzen? Was ist mit Matrizenmultiplikationen?

Irgendeine ETA?

Wie wäre es mit HIP, um CUDA-Code auf einen plattformunabhängigen zu portieren? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Anscheinend arbeitet AMD daran: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45#issuecomment -269827686

Können XLA-Backends LLVM IR mit https://github.com/KhronosGroup/SPIRV-LLVM in SPIR-V konvertiert werden?

Wie wäre es damit? Ich denke, dieses Paket kann auf Radeon GPU funktionieren.

https://github.com/RadeonOpenCompute/ROCm

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

@lukeiwanski Wird XLA auch Ihre Bemühungen beeinflussen?

XLA- und SYCL-Lösungen ergänzen sich für verschiedene Situationen: SYCL wurde entwickelt, um vollständige Programmierbarkeit und Anpassbarkeit zu bieten. XLA dient zur Optimierung gut definierter Muster in Diagrammen.

Mein Verständnis von XLA ist, dass es einige vorhandene TensorFlow-Graphen zur Laufzeit mit dem LLVM-Compiler optimiert. Es erfordert die Implementierung von Optimierungsdurchläufen im Compiler für jeden im Graphen verwendeten Algorithmus.
Der SYCL-Ansatz ist der einzige Ansatz, der eine CUDA-Programmierebene liefert – was Entwickler brauchen.

Mit SYCL zielen wir darauf ab, Unterstützung für alle TensorFlow-Operationen bereitzustellen und die Entwicklung neuer Operationen zu erleichtern.

Das bedeutet, dass Sie mit SYCL sehr einfach neue Hochleistungsoperationen schreiben können, während XLA ganze Diagramme optimieren kann, wenn es alle Operationen im Diagramm unterstützt.

Können XLA-Backends LLVM IR mit https://github.com/KhronosGroup/SPIRV-LLVM in SPIR-V konvertiert werden?

Ich sehe keinen Grund, warum das nicht möglich sein sollte.

@lukeiwanski Danke, ich habe speziell nach https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend gesucht

@k-hashimoto: Wir diskutieren hier über die Portierung von TensorFlow auf OpenCL, einen Standard der Khronos Group, und eigentlich mehr auf OpenCL SYCL, den postmodernen C++-Single-Source-Standard der Khronos Group.
ROCm sieht aus wie eine weitere Nicht-Standard-Lösung-von-einem-Anbieter.
Wenn Sie an proprietären Lösungen interessiert sind, gibt es bereits eine CUDA-Version von TensorFlow, die gut zu funktionieren scheint. :-)

Einverstanden: Konversation / Bemühungen über OpenCL fortsetzen und Anbieter ihre Dinge auf diesem offenen Standard implementieren lassen.

Am 17. Januar 2017 10:01:32 GMT+00:00 schrieb Ronan Keryell [email protected] :

@k-hashimoto: Wir diskutieren hier über die Portierung von TensorFlow auf
OpenCL, ein Standard der Khronos Group, und eigentlich mehr OpenCL SYCL,
der postmoderne C++-Single-Source-Standard der Khronos Group.
ROCm sieht aus wie eine weitere Nicht-Standard-Lösung-von-einem-Anbieter.
Wenn Sie an proprietären Lösungen interessiert sind, gibt es bereits eine CUDA
Version von TensorFlow, die gut zu funktionieren scheint. :-)

--
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -273076892

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

:+1:

👍

:+1:

Diese Nachricht wurde automatisch von der E-Mail-Zustellungssoftware erstellt.

Eine von Ihnen gesendete Nachricht konnte an einen oder mehrere davon nicht zugestellt werden
Empfänger. Dies ist ein vorübergehender Fehler. Die folgende(n) Adresse(n) zurückgestellt:

[email protected]
Die Domain biomassiv.es hat die maximal zulässige Anzahl an E-Mails pro Stunde (111/100 (111 %)) überschritten. Nachricht wird später erneut versucht

------- Dies ist eine Kopie der Nachricht, einschließlich aller Kopfzeilen. ------
Erhalten: von github-smtp2-ext6.iad.github.net ([192.30.252.197]:48606 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
von chi-server32.websitehostserver.net mit esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.87)
(Umschlag-von [email protected] )
id 1cWmiQ-0032as-W9
für [email protected]; Do, 26. Januar 2017 10:16:03 -0600
Datum: Mi, 25. Januar 2017 04:09:21 -0800
DKIM-Signatur: v=1; a=rsa-sha256; c=entspannt/entspannt; d=github.com;
s=pf2014; t=1485346161;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg=;
h= From:Reply-To :To:Cc:In-Reply-To: References:Subject :List-ID:
List -Archiv:List-Post :List-Un abonnieren:From;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
Von: Miguel Ángel [email protected]
Antwort an: tensorflow/tensorflow [email protected]
An: tensorflow/tensorflow [email protected]
Cc: Abonniert [email protected]
Nachrichten ID:
Als Antwort auf:
Verweise:
Betreff: Re: [tensorflow/tensorflow] OpenCL-Unterstützung (#22)
Mime-Version: 1.0
Inhaltstyp: mehrteilig/alternativ;
Grenze="--==_mimepart_5888957158d12_78b73ff902fe113c148134";
Zeichensatz=UTF-8
Content-Transfer-Encoding: 7bit
Vorrang: Liste
X-GitHub-Sender: migpradel
X-GitHub-Empfänger: Biomassen
X-GitHub-Grund: abonniert
Listen-ID: tensorflow/tensorflow
Listen-Archiv: https://github.com/tensorflow/tensorflow
Listen-Post: [email protected]
Listen-Abmeldung:,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Response-Suppress: Alle
X-GitHub-Empfängeradresse: [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Inhaltstyp: Text/Plain;
Zeichensatz=UTF-8
Content-Transfer-Encoding: 7bit

--
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Inhaltstyp: text/html;
Zeichensatz=UTF-8
Content-Transfer-Encoding: 7bit

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm .

----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Neu hier. Wollte fragen, ob es in Zukunft OpenCL-Unterstützung in Tensorflow geben wird, würde das bedeuten, dass es Unterstützung geben wird, Tensorflow auf FPGA auszuführen?
Danke

@atinzad : Ja, wenn die OpenCL- oder SYCL-Version und der Quellcode von der FPGA-Umgebung unterstützt werden. Aber da TensorFlow vielleicht das am besten portierte Framework mit verschiedenen Mitteln ist, könnte es schon irgendwo einen Teil auf einem FPGA laufen haben ...

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

Was sind die Unterschiede zwischen den sycl-Entwicklungsbemühungen und XLA, die in der mittelfristigen Vision auf SPIR-V als PTX abzielen?

Was für eine großartige Frage. Wahrscheinlich - die Anzahl der beteiligten Personen? Wäre sehr interessant zu wissen!

Am 16. Februar 2017 um 13:35 Uhr schrieb bhack [email protected] :

Was ist in der mittelfristigen Vision der Unterschied zwischen den Sycl-Entwicklungsbemühungen und XLA, die auf SPIR-V als PTX abzielen?

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Was ist in der mittelfristigen Vision der Unterschied zwischen den Sycl-Entwicklungsbemühungen und XLA, die auf SPIR-V als PTX abzielen?

@bhack Das wäre eine großartige Diskussion auf dem gestrigen TensorFlow Dev Summit

Fragen Sie nach den verfügbaren Ressourcen / der Art der Programmierer, die zum Beitragen benötigt werden?

Wenn ja, können im OpenCL/SYCL-Ansatz C++-Programmierer / OpenCL-C-Programmierer schnell auf den neuesten Stand gebracht werden und in der Lage sein, einen Beitrag zu leisten. Der XLA-Ansatz erfordert Compiler-/llvm-Erfahrung.

XLA ist Googles internes Projekt, dem entsprechend mehr Ressourcen zugeordnet sind. Aber auf der anderen Seite ist ihre Aufgabe auch viel größer. Einen Compiler zu schreiben ist keine leichte Aufgabe.

Ansonsten, wenn Sie nach dem Modell fragen:

Wie ich bereits in https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870 erwähnt habe, sehen wir beide Bemühungen als komplementäre Ansätze und beide haben unterschiedliche Anwendungsfälle. Ich bleibe immer noch bei dieser Aussage.

Zum Beispiel erwähnte @tatatodd in seiner Präsentation, dass einige der Ops niemals XLA als Ziel haben werden. Ich glaube, dass wir diese Lücke füllen können.

Andere Dinge, die zu berücksichtigen sind, sind neue Plattformen. Ich werde für dieses Argument mobile und eingebettete Umgebungen verwenden, da neue Chips dazu neigen, häufiger herauszukommen als GPUs (das Prinzip ist dasselbe).

Wenn der Halbleiter SYCL / OpenCL unterstützt, erhalten Sie TF-Unterstützung aus der Box (einige Leistungsoptimierungen könnten erforderlich sein).

Wenn die Architektur exotisch ist und es kein LLVM-Backend dafür gibt, muss XLA es hinzufügen (das passiert vielleicht nicht allzu oft, aber trotzdem). Was häufiger vorkommt, ist, dass sich die Architektur ein wenig ändert und dann neue Optimierungsdurchläufe hinzugefügt oder vorhandene modifiziert werden müssen, um die Vorteile zu nutzen. Das Optimieren des Kernel-Codes ist einfacher.

Ich habe mir XLA nicht sehr genau angeschaut, aber ich gehe davon aus, dass XLA irgendwie die CUDA-API aufrufen muss, um den PTX-Kernel-Code auszuführen, also müsste es auf OpenCL oder Vulkan portiert werden, um stattdessen SPIR-V-Kernel auszuführen – davon gehe ich aus würde durch StreamExecutor gehen - ein weiteres Framework, mit dem man sich vertraut machen muss - wahrscheinlich ein ziemlich großer Aufwand.

Kurz gesagt, wir bieten eine einheitliche / stabile Plattform in einem sehr fragmentierten / umgeleiteten Ökosystem, auf das sowohl Halbleiterunternehmen als auch Entwickler abzielen können. Wobei XLA sich zur Unterstützung verpflichten müsste.

@benoitsteiner oder @drpngx können möglicherweise mehr Insiderwissen über XLA vermitteln, da ich mit vielen Annahmen / Schlussfolgerungen arbeite, die auf Gesprächen basieren.

Oh, außerdem habe ich einen Slack-Kanal erstellt, um die Kommunikation zu erleichtern https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Eidt:
Slack-Link ist nicht mehr gültig. Bitte pingen Sie mich an, wenn Sie mitmachen möchten.

Ich denke, das ist richtig und wird teilweise davon abhängen, in welche Richtung sich die Halbleiterhersteller orientieren werden.
„Diese Backends geben die LLVM-IR aus, die erforderlich ist, um die XLA-HLO-Berechnung effizient darzustellen, und rufen dann LLVM auf, um nativen Code von dieser LLVM-IR auszugeben.“ So könnte LLVM IR in SPIR-V umgewandelt werden . Aber Opencl SPIRV-Dialekt unterscheidet sich von Vulkan . Streamexecutor wird in LLVM parallel-lib gepusht und in der ursprünglichen @henline - Beschreibung scheint der ursprüngliche Plan opencl abzudecken.

/cc @ dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
Nvidia sollte bald opencl 2.0 sowohl unter Linux als auch unter Windows unterstützen, das ist YUGE !

In Bezug auf die Leistung ist es jedoch wahrscheinlich langsamer als CUDA.

Denken Sie auch daran, dass Noveau-Leute unabhängig voneinander an Opencl mit SPIR-V arbeiten. Der Status ist etwas veraltet, aber es gibt frische Commits.

Opencl ist nicht von Natur aus langsamer als Cuda, es ist nur nvidia, das den Markt praktisch blockiert, indem es seinen opencl-Treiber lahmlegt.
Aber die Führung von NVIDIA geht endlich zu Ende und selbst ihre unmoralischen wettbewerbswidrigen Praktiken werden sie nicht retten. Mit dem beeindruckenden Cuda Autotranslator HIP ( https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
Die kommenden vega apus und dgpus und ARM, die zu Windows kommen, Nvidia hat keine Zukunft, deshalb MUSS die Industrie opencl/syCL/HIP/HSA sehr bald und massiv unterstützen.

Was ist mit Folie 40 von https://autodiff-workshop.github.io/slides/JeffDean.pdf?

Hallo, dass ich plane, dass Tensorflow die neue AMD Radeon Instinct unterstützt? (http://instinct.radeon.com/en-us/)

Hallo, gibt es Fortschritte bei der TF-OpenCL-Unterstützung für FPGAs?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 wurde vor einigen Monaten entfernt und die Streamexecutor-Roadmap ist nicht klar.

@bhack Danke für die schnelle Antwort
Bedeutet dies also, dass es keinen Support gibt oder dass ein korrekter Betrieb nicht gewährleistet ist?
Aus dem, was ich in diesem Thread gelesen habe, sehe ich auch, dass die Tests hauptsächlich auf AMD-GPUs stattfinden ... trainiert jemand Netze auf Nvidia-GPUs mit diesem OpenCL-Port?

Streamexecutor wurde in LLVM parallel-libs umbenannt und heißt jetzt acxxel

Kann irgendein Google-Mitglied den Unterschied und die Roadmaps zwischen streamexecutor und https://reviews.llvm.org/rL285111 erklären?

CC @zheng-xq

@henline und @jlebar sind die Experten, die den Unterschied zwischen streamexecutor und https://reviews.llvm.org/rL285111 beantworten?

Axcell und StreamExecutor sind separate Projekte. Es gibt derzeit keine Pläne, sie zusammenzuführen. Ich überlasse es den TensorFlow-Leuten zu sagen, ob sie einen Wechsel planen oder nicht.

Also waren auch StreamExecutor und StreamExecutor llvm nicht die gleichen Projekte?

Richtig, sie sind nicht das gleiche Projekt.

Am Do, 16. März 2017 um 11:06 Uhr schrieb bhack [email protected] :

Also waren auch StreamExecutor und StreamExecutor llvm nicht die gleichen Projekte?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar Das nächste Mal eine kreative Einheit für die Namensgebung ;) aber wahrscheinlich war es kein Mangel an Kreativitätsmotivation, sondern nur eine vorgelagerte Anstrengung eines internen Tools, das von dem in TF gepflegten abwich.

@bhack , wir haben den Namen geändert, genau als uns klar wurde, dass wir es getan haben
hielt es nicht für sinnvoll, StreamExecutor in den LLVM-Großhandel zu verschieben. Es ist
heißt jetzt "Acxxel".

Es tut mir leid für die Verwirrung und ich weiß das Feedback zu schätzen. Es war a
Lernprozess sicher.

Am Do, 16. März 2017 um 11:24 Uhr schrieb bhack [email protected] :

@jlebar https://github.com/jlebar Das nächste Mal eine kreative Einheit zum Benennen
;) war aber wohl kein Mangel an Kreativitätsmotivation sondern einfach nur einer
vorgelagerter Aufwand eines internen Tools, das von dem gepflegten abweicht
im TF..

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Ja, ich habe immer noch ein bisschen Verwirrung zwischen StreamExecutor, SyCL in Eigen, XLA (das hat eigentlich nur ein CUDA-Backend, außer CPU und Opencl in einigen Folien)

Stoßen

Hat jemand bei Google mit Apple oder AMD gesprochen, um dies zu erleichtern? Ich denke, die AMD-Leute sind so verloren, dass sie nicht einmal wissen, dass das Problem da ist, und sie fragen sich immer noch, warum Nvidia einen so großen Marktanteil hat. Ich schätze, auch das Apple-KI-Team würde hier mehr als gerne helfen ... wenn OpenCL nicht seit 2013 eine Abandonware von ihrer Seite wäre und, noch schlimmer, ihre Chefs wären nicht sauer auf Google.

Was gibt es dazu Neues?

Laut den Versionshinweisen zu TF 1.1 ist die Unterstützung für Mac-GPUs (nur Nvidia) veraltet. Hoffen wir, dass dies dazu beiträgt, den OpenCL-Ansatz zu verbessern (dabei bin ich nicht sehr zuversichtlich).

Sie können auch den Status des PR https://github.com/tensorflow/tensorflow/pull/9117 verfolgen

Danke! Ich verfolge dieses Problem in den letzten Monaten. Ich bin nicht zuversichtlich, was das OpenCL-Engagement von Apple betrifft, da sie seit 2013 an OpenCL 1.2 festhalten (Apple bietet noch keine Unterstützung für SPIR 1.2).

Wenn TensorFlow auf OpenCL Ihnen bei Ihrer Arbeit helfen würde, lassen Sie es mich wissen, in dem Maße, in dem ich helfen kann, die Forschung und Praxis des Deep Learning voranzutreiben, würde ich gerne helfen. Mein Unternehmen hat ein OpenCL-Back-End für TensorFlow entwickelt, das im Rahmen unserer Arbeit an der geräteinternen Inferenz auf eine Vielzahl von GPUs abgestimmt ist. Wir haben die wichtigsten GPU-Familien für Mobilgeräte und Desktops getestet, einschließlich gängiger Konfigurationen unter Windows und Mac. Wenn genügend Interesse besteht, können wir eine Art öffentlichen Vertrieb durchführen. Wir haben auch Metal (Apple GPU) und LLVM (CPU) zusammen mit einer Möglichkeit, eine Bereitstellung ohne Abhängigkeiten durchzuführen. Die Idee dabei ist, jedem Gerät eine großartige Unterstützung für Deep Learning zu geben.

@choongng - all das klingt unglaublich nützlich und hilfreich. Mein persönliches Projekt https://github.com/Synopsis/ würde stark von OpenCL auf OS X sowie von Metal für die iOS- und Desktop-Bereitstellung profitieren. Wenn es möglich wäre, dies in Tensorflow selbst einzuführen, wäre es meiner Meinung nach ein enormer Segen für jede Menge Entwickler.

Danke.

@choongng

Wenn Ihr Unternehmen eine OpenCL-Version oder, was interessanter ist, eine Metal-Version von TensorFlow veröffentlicht, denke ich, dass dies für viele Leute eine großartige Nachricht sein wird. Ich bin dabei, eine eGPU mit einer NVidia-Karte zu bauen, um TensorFlow zu erhalten / Keras läuft auf meinem MBP für meinen Job...

Für Interessierte ... gehen Sie zur eGPU.io-Community

@choongng

Ich wäre sehr daran interessiert, dies zu sehen, also wäre ich sehr dankbar, wenn Sie es verfolgen könnten! Vor allem, wenn es nicht die skizzenhaften Closed-Source-Compiler erfordert, die TF für die CL-Unterstützung ausgewählt hat.

Am 26. April 2017 03:33:51 GMT+01:00 schrieb Choong Ng [email protected] :

Wenn TensorFlow auf OpenCL Ihnen bei Ihrer Arbeit helfen würde, lassen Sie es mich wissen
Inwieweit ich dazu beitragen kann, die Forschung und Praxis des tiefen Lernens voranzutreiben, würde ich
gerne helfen. Mein Unternehmen hat ein OpenCL-Backend für TensorFlow erstellt
im Rahmen unserer Arbeit an geräteinterner Inferenz für eine Vielzahl von GPUs optimiert.
Wir haben die wichtigsten GPU-Familien für Mobilgeräte und Desktops einschließlich getestet
allgemeine Konfigurationen auf Windows & Mac. Bei genügend Interesse können wir
kann irgendeine Art von öffentlicher Verteilung tun. Wir haben auch Metal (Apple GPU)
und LLVM (CPU) sowie eine Möglichkeit zur Bereitstellung ohne Abhängigkeiten. Die
Die Idee dabei ist, jedem Gerät eine großartige Unterstützung für Deep Learning zu geben.

--
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297220160

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

Ich denke, das wäre revolutionär ;)

@choongng Vielleicht würde es helfen, wenn du dich mit diesen Jungs zusammenschließt
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey Was ist der Open-Source-Compiler, den Sie dann verwenden möchten? Es ist schwierig, eine Open-Source-OpenCL-kompatible Lösung zu finden, um viele Geräte in freier Wildbahn anzusprechen ...
Irgendwann müssen wir irgendwie eine Lösung finden ...

Ich habe nicht gesagt, dass es eine einfache Lösung ist. Aber OpenCL ist dort nicht das Problem. Schließlich ist CUDA vollständig proprietär, viel schlechter als selbst die OpenCL-Option, die TensorFlow gewählt hat.

Trotzdem gibt es Optionen für ein CL- oder Cuda-System, wenn Sie bei Null anfangen, einschließlich tragbarer Middleware-Laufzeiten oder Arrayfire usw. Tensorflow ist jedoch zu sehr an CUDA gebunden.

Ich finde es frustrierend, dass Leute bereit sind, Kernel in CUDA zu schreiben, sich aber dagegen sträuben, dies für CL zu tun, obwohl dies mehr Benutzer erreichen und das Marktökosystem ernsthaft erweitern würde. Eine offene Plattform für alle hat direkte und indirekte Vorteile und kann langfristig zu großen Kosteneinsparungen für alle führen.

Wenn SYSCL das ist, wie das schließlich passiert, großartig: Warum investieren dann nicht einige große Namen in eine offene SYSCL-Distribution, anstatt sich in proprietäre Optionen einzukaufen, die den Zweck eines offenen Standards zunichte machen?

Am 28. April 2017 09:13:06 GMT+01:00 schrieb Ronan Keryell [email protected] :

@cathalgarvey Was ist der Open-Source-Compiler, den Sie dann verwenden möchten?
Es ist schwierig, eine Open-Source-OpenCL-kompatible Lösung zu finden
Adressieren Sie viele Geräte in freier Wildbahn ...
Irgendwann müssen wir irgendwie eine Lösung finden ...

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297936468

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

Was ich in diesem Zusammenhang fragen möchte ist folgendes:

Daher untersuchen einige Deep-Learning-Frameworks wie Tensorflow etwas lauwarm die Verwendung von opencl als Alternative zu CUDA. Natürlich ist CUDA nur die "Sprache", auf der cuDNN entwickelt wurde, und das ist (wenn ich richtig verstehe) die meisten Deep-Learning-Sprachen tatsächlich verwenden. In diesem Zusammenhang bin ich mir nicht sicher, was die opencl-Version von cuDNN ist.

Auch AMD hat über Open-Source-Alternativen zu CUDA gesprochen, die sie kontinuierlich weiterentwickeln und rocM nennen. Sie sprechen auch von miOpen als cuDNN-Äquivalent (handgefertigte Assembler-Bibliotheken für gängige Deep-Learning-Funktionen), das jedoch noch nicht veröffentlicht wurde. Der AMD-Ansatz ist etwas ganzheitlicher: Wir exportieren nicht nur schwere Rechenleistung auf die GPU.

In diesem Zusammenhang bin ich wirklich verwirrt. Wie passen Opencl-Bemühungen wie die oben aufgeführten zusammen? Für NVIDIA-GPUs ist es einfach ... es gibt CUDA und es gibt cuDNN, das in CUDA geschrieben ist. Für Nicht-NVIDIA/oder in diesem Fall AMD scheint es so viel weniger klar zu sein. Wann wird HIP bevorzugt? Wann wird der HCC bevorzugt? Wann wird opencl bevorzugt? Irgendwelche Einblicke würden wirklich geschätzt!

@cathalgarvey hinter all diesen riesigen Software-/Hardware-Infrastrukturen steckt viel Politik ... :-(
Auch wenn wir nach rein wissenschaftlichen Kriterien von einer sauberen Lösung träumen können, denke ich, dass wir pragmatisch sein müssen.
Google will an der TensorFlow-Architektur nicht allzu viel ändern. Aus diesem Grund muss die OpenCL-basierte Architektur sehr ähnlich sein und Single-Source-C++ wie "CUDA Runtime" anstelle der OpenCL-C-Lösung auf niedrigerer Ebene ohne Single-Source erfordern. Im Khronos-Bereich heißt die Single-Source-C++-Version von OpenCL SYCL.
Lassen Sie uns das besprechen, wenn Sie zum Beispiel in Dublin vorbeischauen, da Sie auch in Irland ansässig sein möchten. :-)
In der Zwischenzeit können Sie gerne zu https://github.com/triSYCL/triSYCL und den Zweigen von TensorFlow & Eigen beitragen, die sich mit SYCL befassen ...

@keryell Weißt du, ob auch XLA:GPU :OpenCL auf SyCL geplant ist?

Hallo @benoitsteiner , bezüglich:

Dort in einem OpenCL-spezifischen Abschnitt in der gesamten TensorFlow-Dokumentation. Dies wird in Kürze auf der Website tensorflow.org veröffentlicht.

Ich habe auf tensorflow.org nach OpenCL gesucht und schien nichts Bedeutendes finden zu können, es scheint alles genau hierher zu verweisen. Mit "bald" meinst du vor ______? ( _hier lustigen Sarkasmus einfügen_ ).

Ich konnte Ihr Repo kompilieren (yay!), obwohl ich vermute, dass es etwas anderes braucht, um ein funktionierendes Tensorflow OpenCL für Mac zu erstellen; Ich habe versucht, den erwähnten Compiler triSYCL zu bauen, bin aber leider gescheitert.

@bhack Da ich nicht für Google arbeite, habe ich keine Ahnung von XLA-Details ...

@dylib leider ist das alles noch in Arbeit ...

@keryell Ja, ich weiß. Ich war nur neugierig, ob in einigen Meetings darüber gesprochen wurde.

OpenCL unterscheidet sich grundlegend von CUDA. Ich würde jedoch definitiv sehen, dass dies stattdessen auf HIP portiert wird.
Also +1 für alle, die es vorgeschlagen haben.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

HIP ermöglicht es Entwicklern, CUDA-Code in portables C++ zu konvertieren. Derselbe Quellcode kann für die Ausführung auf NVIDIA- oder AMD-GPUs kompiliert werden

HIP ist vielen nicht bekannt.
Weitere Informationen zu Tensorflow und HIP finden Sie hier:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
und
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Randnotiz:
Ich denke nicht, dass wir mit Nvidia vs. AMD streiten/prahlen sollten. Das sind respektable Unternehmen, die erstaunliche Hardware und Software herstellen. Wir sollten uns stattdessen darauf konzentrieren, Tensorflow einer größeren Benutzerbasis bereitzustellen.
Das Targeting vieler Sprachen durch Bindungen ist bereits ein guter Ausgangspunkt, aber wir müssen auch so viele Hardware wie möglich ansprechen. (Auch wenn Cloud-Lösungen erstaunlich sind, sind sie nicht immer die Antwort)

Wir haben Erfahrung mit HIP, hier bei Stream. Lass mich mal sehen.

Stimmen Sie dem „Meine Firma ist besser“-Argument zu. Ich würde gerne wissen, auf welche GPUs TensorFlow abzielen sollte. Es muss pragmatisch und nützlich sein. Zum Beispiel Intel GPUs oder Embedded GPUs (Qualcomm, ARM, Imagination), RaspBerry Pi – ja oder nein?

AMD Radeon Vega Frontier Edition

Wir arbeiten weiterhin aggressiv an der Verbesserung unserer offenen ROCm-Softwareplattform und unserer Bibliotheken für maschinelles Lernen. Wir unterstützen auch Open-Machine-Intelligence-Frameworks wie Caffe (veröffentlicht im April). Später in diesem Quartal planen wir, Unterstützung für Torch anzubieten, und Tensor Flow ist in Arbeit.

Sie haben Caffe bereits veröffentlicht und wären sehr daran interessiert, andere in diesem Thread zu hören, die ihre Erfahrungen mit dem Erstellen/Testen teilen:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Ich habe mit der Installation begonnen, bin aber auf eine Straßensperre gestoßen, bei der alles, was CL erfordert, einfach einfriert, sogar clinfo . Ich bin mir nicht sicher, ob dies an einem Softwareproblem liegt oder ob meine Karte (R9 390) von ROCm einfach nicht unterstützt wird.

Am 17. Mai 2017 15:18:32 GMT+01:00 schrieb Bryan Li [email protected] :

AMD Radeon Vega FrontierAuflage

Wir arbeiten weiterhin aggressiv an der Verbesserung unserer offenen ROCm-Softwareplattform
und Bibliotheken für maschinelles Lernen. Wir unterstützen auch offene Maschinen
Intelligence-Frameworks wie Caffe (veröffentlicht im April). Später dies
Quartal planen wir, Support für Torch anzubieten, und Tensor Flow ist da
die Werke.

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -302103815

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

@cathalgarvey Ich habe den Caffe OpenCL-Zweig auf AMDs GPUs verwendet und es funktioniert einwandfrei. make run test hat alle Tests bis auf einen bestanden

Gut zu hören; darf ich nach deinem HW/SW Setup fragen? ZB welche Karte du hast
verwenden, welche Distribution/Version von Linux usw.?

Ich hatte zuvor AMDGPU-pro, habe es aber bei der Installation von ROCm deinstalliert.
Es ist möglich, dass mich irgendetwas aus dem Erbe stört.

--
@onetruecathal / @cathal@ quitter.is

Am Mittwoch, den 17. Mai 2017 um 15:50 Uhr, Bryan Li [email protected]
schrieb:

@cathalgarvey Ich habe den Caffe OpenCL-Zweig auf AMDs GPUs verwendet und
es funktioniert gut. make run test hat alle Tests bis auf einen bestanden

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@cathalgarvey

• Caffe OpenCL-Zweig (getestetes Commit c61d48746b2df1d237c64abc7416342ce98f3251 )
• Betriebssystem: Ubuntu 16.04.2 LTS
• Getestet auf Polaris (RX460), Fiji (Fury X) und Tonga (W7100)
• Treiber: AMDGPU-Pro-Treiber für Linux 16.40 oder höher
• WienCL
• Allgemeine Abhängigkeiten: 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 ..

Ja, zusätzlich zum obigen OpenCL-Zweig wird naibaf7 (sehr bald) ein Buch über die Verwendung von OpenCL für Echtzeit-Inferenz auf handelsüblicher Hardware mit AMD- und HD-Grafik veröffentlichen.

Ah; Ich habe über hipCaffe gesprochen, nicht über den OpenCL-Zweig:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Die Installation von ROCm zum Erstellen/Testen von hipCaffe erforderte eine Deinstallation
AMDGPU-Profi, vielleicht versuche ich es noch einmal mit dem Vanilla-Zweig. Es ist schlecht
dokumentiert, leider.. Ich nehme an, ich werde ein blindes "make" versuchen und sehen.

Daher bin ich immer noch daran interessiert, die Erfahrungen anderer mit dem AMD zu hören
ROCm/HIP-Stapel; Wenn sie an einer Tensorflow-Gabel arbeiten, wäre das großartig,
Vorausgesetzt, es funktioniert tatsächlich auf mehr als 3/4 Modellen der AMD-Karte in der
wild.

--
@onetruecathal / @cathal@ quitter.is

Am Mittwoch, den 17. Mai 2017 um 16:09 Uhr, Bryan Li [email protected]
schrieb:

@cathalgarvey

Caffe OpenCL-Zweig (getestetes Commit
c61d48746b2df1d237c64abc7416342ce98f3251)
Betriebssystem: Ubuntu 16.04.2 LTS
Getestet auf Polaris (RX460), Fiji (Fury X) und Tonga (W7100)
Treiber: AMDGPU-Pro-Treiber für Linux 16.40 oder höher
WienCL
Allgemeine Abhängigkeiten: 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
—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@cathalgarvey Ich hoffe, sie arbeiten an einem hippen Backend, nicht an einer vollständigen Gabel. Das wäre schade und würde den Arbeitsaufwand nur teilen.
Es gibt bereits genug Werkzeuge :/

@YvanDaSilva Die Bemühungen von AMD sind im Moment etwas schlecht koordiniert (ja, alle Forks). Außerdem scheint es auf einer Vielzahl von Geräten noch nicht so gut zu funktionieren, anders als beispielsweise der OpenCL-Zweig von Caffe ...

@ naibaf7 Ich stimme absolut zu.
Um ehrlich zu sein, scheint es ihnen wirklich an Personal zu mangeln, sie arbeiten an allen Fronten.
Übrigens: Wusste nicht, dass die ETH eine Neuroinformatik hat ;) schön !

@cathalgarvey Können Sie den ROCm/HIP-Stack für einen Laien wie mich näher erläutern. Ich habe AMGPU-pro und AMDGPU mit meinen Sea Islands-Karten gespielt, daher bin ich mir sicher, dass ich einige nützliche Ergebnisse posten kann.

@YvanDaSilva
Sie haben mein ursprüngliches Caffe OpenCL-Projekt gesponsert und leider nicht gut koordiniert, also arbeiteten die AMD-Forschung und ein unabhängiger Typ bei AMD auch parallel an OpenCL-Portierungen - das ehemalige AMD-Forschungsteam ist jetzt aufgelöst und die meisten von ihnen arbeiten tatsächlich für Tesla ( selbstfahrendes Autoprojekt) jetzt ... also eine unglückliche Kette von Ereignissen.
Ich bin jedoch immer noch in Zusammenarbeit und Kontakt mit ihnen. Vega wird interessant :)

@naibaf7 Schön, Glück gehabt! Wünschte, es gäbe ein solches Studium, als ich am Heig-vd war, hätte es sicherlich zu einem MSc fortgesetzt.

Ja... Das habe ich mir gedacht. So viel Arbeit, so wenig Personal in diesen Bereichen.

All das hört sich großartig an, aber fokussieren wir die Diskussion darauf, dass TensorFlow mit OpenCL SYCL und nicht nur mit herstellerspezifischen Lösungen funktioniert ... :-)
Ich hoffe, RoC und andere HiP haben ihren eigenen GitHub, um ihre eigenen Probleme zu diskutieren ...
@naibaf7 : Zumindest bin ich immer noch im OpenCL-Bereich. Komm wieder in den Club! :-)

@keryell Ich denke, die Diskussion über HIP ist gültig, wenn ein HIP-Port für Tensorflow in Arbeit ist. Schließlich soll die offizielle Tensorflow-on-CL-Lösung ein proprietäres SYCL-Framework mit stark eingeschränkter Plattform- und Kernel-Unterstützung verwenden, ist also nicht wirklich besser als die "herstellerspezifischen" HIP-Lösungen, die einen neuen Ausweg aus CUDA bieten.

HIP mag im Moment hauptsächlich von AMD gemacht werden, aber AFAIK ist es ein offener Standard? Vielleicht irre ich mich. Wenn dies jedoch der Fall ist und AMD einen Tensorflow-on-HIP-Port liefern kann, wäre dieser sofort offener als der offizielle Tensorflow-on-SYCL-Port.

HIP ist eine Teilmenge von CUDA, also so offen wie CUDA.

Okay, gut; HIP-the-API ist eine Teilmenge von CUDA-the-API, aber wenn NVidia nicht mutig genug ist, Oracle zu kanalisieren, bezweifle ich, dass dies ein Problem sein wird. Ich bezog mich auf die Laufzeit/Compiler für HIP, von denen ich denke, dass AMDs ~offen sind.

Bearbeiten : Entschuldigung, wenn das Obige unhöflich klang; Ich versuche nur, meine Position oben zu verdeutlichen!

Werden Vulkan und Opencl fusioniert ?

Laut Reddit AMA von Raja wird Vega Tensorflow, Cafe2, Cafe, Torch7 und MxNet über MIOpen unterstützen.

@cathalgarvey die Diskussion ist eindeutig gültig, aber nicht hier ...
Sie befinden sich hier auf GitHub und diskutieren über die Portierung von TensorFlow & Eigen unter Verwendung der Standards der Khronos Group.
Dies ist nicht Twitter oder deine Facebook-Pinnwand... :-)
Tragen Sie also bitte mit einigen Commits zu diesen Projekten bei! :-)

Es gibt eine neue Version des Einrichtungsleitfadens zum Kompilieren von TensorFlow mit ComputeCpp, Codeplays Implementierung von SYCL, sodass OpenCL-Geräte verwendet werden können. Wir würden uns über jedes Feedback freuen, das Sie uns dazu geben können. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

Haben Sie eine Ahnung, wie hoch die Erfolgsquote ist, wenn Sie dies auf ungetesteten AMD-GPUs zum Laufen bringen? Ich bin speziell daran interessiert, ob es für AMD Radeon Pro 460 @rodburns getestet wurde. Ich würde gerne ein paar Stunden damit verbringen, Ubuntu auf meinem Macbook-Laptop zum Laufen zu bringen, wenn es Hoffnung mit einer ungetesteten GPU gibt

@samhains wir haben das nicht getestet, aber du könntest es versuchen. Sie müssen einige ältere AMD-Treiber mit Ubuntu verwenden, die die SPIR-Erweiterung unterstützen. Welche Treiber das sind, habe ich noch nicht herausgefunden.

@samhains Wenn die Codeplay-Route nicht funktioniert, verpassen Sie nicht tf-coriander , das endlich in einem Zustand der praktischen Verwendung auf Ubuntu/Mac ist.

Ich teste es derzeit auf Convnets, bidirektionalen RNNs usw. und alles scheint großartig zu funktionieren. Es läuft auf "Vanilla" OpenCL 1.2, was Tensorflow auf einer großen Auswahl relativ alter Hardware ermöglichen sollte.

Das Problem ist vorerst, dass es auf Tensorflow 0.11 basiert.

@rodburns. Ich habe versucht, die unter dem Link https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp aufgeführten Schritte zu befolgen
Ich bekomme folgenden Fehler:
FEHLER: /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD:609 :1: nicht deklarierte Einbindung(en) in Regel '@protobuf//:python/google/protobuf/internal/_api_implementation.so ':
Tatsächlich erhalte ich den gleichen Fehler, wenn ich versuche, Tensorflow aus der Quelle zu kompilieren. Ich habe es früher kompiliert, bin mir aber nicht sicher, was sich geändert hat.

@rahasayantan was ist das enthalten? Erhalten Sie es auch, wenn Sie ohne --config=sycl kompilieren?

@lukeiwanski : Soweit ich weiß, ist das Problem, dass Bazel versucht, Protobuf zu kompilieren und die Unterverzeichnisse nicht findet oder herunterlädt. Ich habe einen Pull mit rekursivem Submodul durchgeführt, es treten jedoch dieselben Probleme auf. Und es hat das gleiche Problem ohne --config = sycl. Tatsächlich stehe ich vor dem gleichen Problem, wenn ich einen Git-Pull aus dem Tensorflow-Hauptprojekt mache. Ich glaube nicht, dass dies mit openCL zusammenhängt, es sind einige Probleme mit der Art und Weise, wie ich den Pull mache. Wenn ich die Projekt-ZIP-Datei ohne Git manuell aus Ihrem Repo herunterlade und kompiliere, wird sie ordnungsgemäß kompiliert, aber dann erhalte ich einen Segmentierungsfehler. Ich habe dieses Problem bereits in Ihrem GIT-Projekt angesprochen und wir sprechen dort, ich werde die Aktualisierungen im Zusammenhang mit dem Segmentierungsfehler in diesem Thread geben (es hat keinen Sinn, Dinge zu duplizieren). Vielen Dank für Ihre Antwort.

Opensource triSYCL kommt. Siehe https://github.com/triSYCL/triSYCL/pull/45

Ich bin neu hier. Sehr daran interessiert, dass TF OpenCL unterstützt. Wie erhalte ich Updates von diesem Thread?

emmm...Interessant, aber warum? Ich meine, warum wählt Tensorflow am Anfang cuda, aber opencl? Irgendein kommerzieller Grund, denke ich?

Hallo @tensorflower-gardener,

@hughperkins hat Coriander erstellt, das NVIDIA® CUDA™-Code auf OpenCL 1.2-Geräten ausführen kann. Vielleicht möchten Sie einen Blick darauf werfen, ob dies Ihren Anforderungen entspricht, um TF mit OpenCL 1.2-Geräten zu verbinden. Geben Sie bitte seinen Namen und seinen Beitrag an, falls Sie vorhaben, seine Arbeit zu verwenden.

Es scheint, dass die Hoffnungen, jemals OpenCL Unterstützung für Mac zu sehen, von wenig auf tf.zero gestiegen sind. Ich habe gerade gelesen, dass TensorFlow Mac anscheinend KEINE GPU-Unterstützung mehr haben wird (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 wurde auf Mac getestet, also wenn/wenn es die Versionsparität erreicht, sollten Sie in der Lage sein, diese zu verwenden.

Am 22. Juni 2017 11:46:51 MESZ schrieb dylib [email protected] :

Es scheint, dass die Hoffnungen, jemals OpenCL Unterstützung für Mac zu sehen, geschwunden sind
wenig bis tf.zero . Ich habe gerade gelesen, dass es Macs nicht mehr zu haben gibt
JEDE GPU-Unterstützung anscheinend (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

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -310331281

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

Traurig, denn jetzt mit einer eGPU und einem Nvidia 980 Ti im Inneren bekommen wir den Treiber zum Laufen und Cuda zum Laufen

Ich hatte jetzt noch keine Zeit, Tensor Flow in meiner Konfiguration auszuprobieren.

Webdriver und Cuda-Toolkit auf meinem Computer installiert und die Cuda-Beispiele funktionieren gut

https://youtu.be/JN9fDmqf010

@cathalgarvey du hast gesagt, dass du convnets auf tf-coriander testest, aber es scheint, dass convnets noch nicht funktionieren. Können Sie bitte klarstellen, ob Sie es geschafft haben, Convnets mit tf-coriander auf der GPU zum Laufen zu bringen?

Zu Ihrer Information,
https://github.com/tensorflow/tensorflow/issues/10703

Warum unterstützt Tensorflow keine GPUs mehr unter OS X? Ich hatte vor, Tensorflow mit einem eGPU-Setup zu verwenden, das ich bestellt habe.

@justinrmiller sie behaupten, sie können es nicht mehr auf mac os testen und haben sich daher entschieden, den support einzustellen. allerdings fällt es mir schwer, das zu glauben. Mit der Werbung für egpus auf High Sierra und mit neuen NVIDIA-Treibern wird dies nicht mehr der Fall sein.

@scholak ja genau. Ich wollte mein neues egpu-Gehäuse verwenden, um meine Windows-Box für immer loszuwerden.

Denken Sie daran, dass, obwohl Nvidia-Karten in eGPU-Gehäusen funktionieren, Apple den RX580 nur offiziell in seinem Entwicklungskit unterstützen wird, sodass die Notwendigkeit von OpenCL nicht verschwinden wird.

OpenCL auf Mac ist 1.2, was bedeutet, dass es keinen aktiven Treiber zu geben scheint
Entwicklung. Ich denke, das Hinzufügen von Metal-Unterstützung zu TF ist ein mühsamer Prozess
(Aktivieren von Eigen und Stream Executor), aber machbar.

Am Sonntag, 16. Juli 2017 um 15:17 Uhr Ferdia McKeogh [email protected]
schrieb:

Denken Sie daran, dass Nvidia-Karten zwar in eGPU-Gehäusen funktionieren, Apple
wird den RX580 nur offiziell in ihrem Dev-Kit unterstützen, also die Notwendigkeit dafür
OpenCL wird nicht verschwinden.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Ich bin sehr traurig über die Aufgabe der GPU-Unterstützung für macOS.

Suchen Sie immer noch nach OpenCL-Unterstützung für GPUs unter macOS, da Apple offensichtlich in absehbarer Zeit nicht zu Nvidia-GPUs wechseln wird.

Tensorflow ist meine bevorzugte Engine. Die lokale Verwendung der GPU-Beschleunigung auf meinem MacBook Pro oder zukünftigen iMac Pro wäre großartig.

Für Microsoft wäre es sinnvoll, Apple zu sabotieren, aber da Google kein Desktop-Betriebssystem hat, schaden sie sich nur selbst.

Ehrlich gesagt sollte sich jemand, der schlauer ist als ich, mit der Integration der MPS - Metal Performance Shaders von Mac OS 10.13 befassen, die eine große Anzahl von neuronalen Netzwerkprimitiven standardmäßig unterstützen. Dies würde eine aktuelle Hochleistungs-GPU für mobile und Desktop-iOS- und macOS-Tensorflow-Inferenzbereitstellungen ermöglichen.

Sie können nicht mit Apples Primitiven trainieren, wie ich es verstehe (sie bieten nichts), aber mit Tensorflow-Unterstützung könnten Sie vielleicht? Ich stelle mir vor, dass es für die Leute auf der Apple-Plattform ein Segen wäre.

Ich glaube nicht, dass Google dies intern anbieten würde, und ich habe nicht annähernd die erforderlichen Fähigkeiten, um es selbst zu versuchen. Ich poste diese Idee, damit Leute, die talentierter sind als ich, sie übernehmen könnten.

:)

Apple zielt ausschließlich darauf ab, Apple-Geräte zu verkaufen. Google zielt darauf ab, Google massive Dienste zu mieten.

Wenn Sie bereit sind, KI (Lernen) mit einem einzigen Gerät wie einem Apple-Laptop durchzuführen, machen Sie „oberflächliches Lernen“ anstelle von „tiefem Lernen“, also geben Sie besser auf, alles andere als Tutorials zu machen. Inferenzergebnisse in einem trainierten Modell für einen einzelnen Benutzer, in einem einzelnen Gerät (sogar in einem nicht allzu vielen Multicore-Telefon), könnten durch GPUs ordentlich durchgeführt werden, sind aber nur mit CPUs perfekt machbar.

Auf der anderen Seite werden GPUs unbedingt benötigt, wenn Sie extrem große Datensätze zum Lernen füttern oder trainierte Inferenzen für extrem große gleichzeitige Kundengruppen bereitstellen möchten.

Auch wenn es aufgrund der Netzwerkprobleme nicht so einfach ist, dies in einem solchen Umfang zu tun. Schauen Sie sich einfach die physische Architektur der TPU-Pods an. Es ist das Gegenteil eines Laptops (mehrere GPUs pro speicherüberlastetem Multi-Core-Server mit dedizierter Glasfaser für die Kommunikation zwischen den Servern).

Ich habe ein MacBook Pro. Es ist ein nettes Terminal, um in die Cloud zu gelangen :-D

Ich sehe, dass TF on Metal auch auf iOS erweitert werden kann. Wenn jemand daran interessiert ist, es aufzunehmen, empfehle ich, zuerst Metal-Unterstützung zu Eigen hinzuzufügen (kann OpenCL als Referenz verwenden).

@rogerpasky Für die Schule musste ich Tensorflow zum Trainieren von Modellen verwenden, nicht nur zum Bewerten eines Modells. Und das muss ich in naher Zukunft noch einmal wiederholen. Für Studenten wie mich ist eine GPU-Schulung ein Muss und spart viel Zeit. Es geht nicht nur darum, mehrere gleichzeitige Benutzer zu bedienen.

@rogerpasky es geht um die Möglichkeit, Modelle und Lösungen lokal auf einem Mac zu entwickeln

@rogerpasky widerspricht respektvoll. Während Cloud-basierte Multi-GPU-Lösungen hervorragend für Internetdienste funktionieren, ziele ich auf professionelle Videoproduktionspipelines ab, bei denen Inferenzen auf Stunden und Stunden von Pro-Res- und unkomprimiertem HD-, 2K-, 4K-Material ausgeführt werden, was a) kein Produktionshaus ist in eine Cloud hochladen, b) sie nicht wollen, dass Google oder sonst jemand ihre Daten hat, c) sie Räume voller Multi-GPU-fähiger Systeme (Mac und Windows) lokal haben, die sie nutzen möchten, und d) während Inferenz auf ein einzelnes Bild ist für die CPU in Ordnung, das Ausführen ganzer Filme zur Inferenz durch mehrere Diagramme zu 100% sieht eine Leistungssteigerung mit etwas wie MPS vs. CPU. Da die Community sich geweigert hat, Standards zu unterstützen/anzunehmen und stattdessen nur Nvidia-Code verwendet, werden Anwendungsfälle aus der realen Welt in eine Schublade gesteckt, und das ist wirklich eine Schande.

Dies ist keine untätige Anfrage von jemandem, der ein Hobbyist ist, der Tutorials durchführt – GPU-Inferenz ist wichtig, ebenso wie die Unterstützung verschiedener GPU-/CPU-Familien für verschiedene Workloads auf realer Hardware. Ich hoffe wirklich, dass Google das ernst nimmt, denn es wäre großartig, bei einer einzigen Bibliothek wie TF bleiben zu können, was großartig ist.

Vielen Dank, dass Sie mir zugehört haben. Ich versuche nicht zu schimpfen, sondern der Community einen alternativen Standpunkt zu bieten.

@pldelisle , @tscholak , @vade bitte versteht mich nicht falsch. Ich hätte es gerne, und wenn Sie in diesem Thread suchen, bin ich als Unterstützer beigetreten, aber soweit ich ihn verfolgt habe, bin ich zu dem Schluss gekommen, den ich geschrieben habe, nicht nur, weil ich es so denke (ich denke, a MacBook würde zusammenbrechen, wenn es mit Tausenden von Videos trainiert würde :-D), aber mit den tatsächlichen Branchenfakten. Warten Sie nicht, bis es in kurzer Zeit gelöst ist (IMHO, es wird nie gelöst, weil Apple und Google sich seit dem iPhone/Android-Problem hassen).

@rogerpasky Es gab bereits Unterstützung für nvidia-GPUs unter Mac OS. Es wurde gerade in 1.2 entfernt.

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

Ich habe meine Bestellung für eine eGPU (Sonnet's) storniert und werde nur Linux auf meinem Gaming-Rig dual booten, aber das ist irgendwie schlecht, wenn man einfach aufhört, etwas zu unterstützen, das die Leute benutzen. Ich hatte wirklich gehofft, dies auf meinem Mac mit einer eGPU (Modelltraining) zu tun, aber ich denke, das wird jetzt nicht passieren: https://github.com/lengstrom/fast-style-transfer

@rogerpasky Ähm , wissen Sie, dass CoreML den Import von Tensor-Flow-Modellen über Keras unterstützt? Apple „hasst“ Google nicht, Geschäft ist Geschäft. Einer der Lieferanten von Apple ist Samsung. Lesen Sie sich das einen Moment lang durch. Google, Apple, Samsung sind Unternehmen und werden das tun, was Geld bringt. Als Randnotiz. Übrigens ist mein MacBook Pro nicht geschmolzen, nachdem ich Tausende von Filmen inferiert habe. Ich vermute, CUDA war super bequem zu übernehmen, und die fortgesetzte Unterstützung von Nvidia und verpasste Gelegenheiten von AMD haben uns dahin gebracht, wo wir jetzt sind. Ich denke nicht, dass es schändlich ist, nur die Kosten für eine Änderung im Vergleich zu den Leistungsunterschieden im Vergleich zu den Kosten, um den Kurs beizubehalten.

Ich vermute, dass irgendein Genie vorbeikommen wird, um zu helfen, das Problem zu lösen.

Ich habe eine Google-Gruppe für eine gemeinsame Diskussion darüber erstellt, wie Deep Learning an neue Orte wie OpenCL, Mac, iOS, CoreML, Vulkan usw. gebracht werden kann. Wenn Sie helfen möchten, dies zu verwirklichen, treten Sie bitte bei und posten Sie eine Notiz mit Ihrer Verwendung Fall oder an welchem ​​Teil des Problems Sie gerade arbeiten. Es gibt bereits Leute, die sehr hart daran arbeiten, TF auf mehr Plattformen zu bringen, darunter MIOpen, die Arbeit von Codeplay, TF-Coriander und ein internes Projekt in meiner Firma (Vertex.AI). Es wäre großartig, Entwickler und Benutzer an einem Ort zusammenzubringen, da diese Bemühungen alle eng miteinander verbunden sind.

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

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

@justinrmiller Ich habe eine eGPU auf Sierra (Titan Xp in einem Sonnet-Gehäuse), auf der Tensorflow 1.2.1 (CUDA 8, cuDNN 6) ausgeführt wird, was keine allzu großen Probleme bereitete, wenn es Ihnen nichts ausmacht, von Grund auf neu zu bauen. Wenn Sie irgendwelche Probleme haben, lassen Sie es mich wissen.

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 Das ist großartig! Danke für die Information!

@danbarnes333 wie hast du tf 1.2 dazu gebracht mit cuDNN 6 zu bauen? Hast du LLVM verwendet? GCC? Ich habe es nur geschafft, es mit cuDNN 5 zu bauen ...

FYI, https://machinelearning.apple.com/

@tscholak Ich werde es hier nicht posten, um dies auf OpenCL zu halten, aber ich fasse die Schritte hier zusammen.

@choongng Ich bin der Google-Gruppe beigetreten, aber es scheint ruhig zu sein. Also meckere ich hier ;-)

1. Machine Learning / High Performance / GPU Computing ist ein hart umkämpfter Markt. Ob es Ihnen gefällt oder nicht, NVidia dominiert den Markt und hält seine Karten und Software dicht an der Weste. Wenn Sie ein Budget und eine Frist haben, bleiben Sie vorerst mehr oder weniger bei NVidia hängen.

2. Ich habe eine alte AMD-Karte ("Bonaire") und kein Budget - Bastler. Ich habe caffe seit gestern mit der proprietären AMD OpenCL 2-Implementierung auf Arch Linux laufen lassen, und ich habe gerade AMDs Open Source MIOpen heute Morgen auf die gleiche Weise zum Laufen gebracht. Damit kann ich einige Modelle trainieren; die Bonaire-Spitzen um 1800 GFLOPS mit einfacher Genauigkeit. Wenn also TensorFlow nicht mit OpenCL auf dem Bonaire läuft, werde ich TensorFlow nicht verwenden.

3. Wenn ein Budget auf magische Weise erscheinen sollte, würde ich eine Intel-CPU und eine NVidia-Karte kaufen und vom Hersteller unterstützte proprietäre Software ausführen. Ich bin mit der unbezahlten Qualitätssicherung für Anbieter wie Google, Red Hat, Canonical und AMD fertig.

   Ich habe drei Monate (und drei Distributionen – Fedora 25, Ubuntu 16.04 LTS und Arch) gebraucht, um etwas aus einer GPU herauszuholen, die ich seit drei Jahren habe. Es gibt nicht behobene Fehler in Fedoras Fehlerverfolgung, auf denen mein Name steht. Gleiches gilt für Ubuntu und Freedesktop.org. Die meisten Leute, die sie reparieren würden, werden auch nicht bezahlt, oder sie werden dafür bezahlt, etwas anderes zu tun.

   Ja, die neuen CPUs von AMD sind beeindruckend, und ja, der Großteil ihrer Software ist Open Source, aber Budgets und Fristen ändern die Dinge. Unterstützung ist der Schlüssel. Unterstützung ist alles!

@znmeb Ich wusste nicht einmal, dass Sie Pre-GCN-Hardware für TF verwenden können.
Mit meinem Tahiti habe ich nur Unterstützung für eine Distribution (Ubuntu 14.01.x), da AMD-proprietäre Treiber nur mit älteren Linux-Kernels für GCN1 funktionieren. (Ich bekomme TF + openCL über SYCL (ungetestet auf 7970))

Wo ich arbeite, leitet die gesamte Forschungs- und Entwicklungsabteilung das grüne Team. Sie alle haben einen Doktortitel und alle, aber keiner hat auch nur eine Zeile cuda (noch OCL) geschrieben. Aber die Werkzeuge sind hier, um ihre Keras Arbeitslast zu beschleunigen. Ich bin irgendwie ein Sonderling mit meinen recycelten Mining-GPUs, die versuchen, ein zweites Leben aus ihnen herauszuquetschen.

tl;dr andere als grüne Teamunterstützung wird nur angezeigt, wenn der AMD-GPU-Marktanteil angezeigt wird.
Es ist ein Henne-Ei-Problem. Ich habe Hoffnungen auf Vega … aber ja … ist kein 1080Ti-Killer.

@acoye FWIW, hier ist der GitHub-Beitrag, der mich dieses Wochenende zum Laufen gebracht hat, nachdem ich seit April geprügelt und gegoogelt hatte: https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . Siehe auch https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . Das war mein ursprüngliches Problem - der Versuch, mein Bonaire zu verwenden, um die lineare Algebra auf R zu beschleunigen.

@acoye
Sie können zu den neuesten Linux-Distributionen wechseln und einen kürzlich benutzerdefinierten kompilierten Kernel wie 4.11/4.12 mit aktivierten AMDGPU-Treibern, deaktiviertem RADEON und mit CONFIG_DRM_AMDGPU_SI=Y und/oder CONFIG_DRM_AMDGPU_CIK=Y in der Kernelkonfiguration verwenden. plus AMD-Firmware für 7970 (Tahiti) im initramfs => neueste AMDGPU-PRO OpenCL funktioniert auf allen GCN-Karten. Vergessen Sie FGLRX (auf älteren Linux-Distributionen) und Clover über RADEON-Treiber, beide sind unterdurchschnittlich.
Vergessen Sie auch Pre-GCN-Karten. Ich habe sie mit OpenCL unter Windows für Caffe getestet, die Leistung ist es nicht wert, sich für so alte Karten anzustrengen. Da alle AMD-Karten nach 2012 sowieso GCN sein sollten.

@naibaf7 Ich habe gestern ein paar Stunden damit verbracht, AMDs Open-Source-Stack zum Laufen zu bringen. Ich habe MIOpen und seine Abhängigkeiten, aber hcc fehlen noch einige Teile. Möglicherweise muss ich einen benutzerdefinierten Kernel-Build erstellen, um alles zu erhalten. Es ist mir egal, CUDA-Code zu portieren oder kompiliertes C ++ auf der GPU auszuführen - ich möchte damit Zahlen knacken. ;-)

Ich habe auch etwas auf ihrer Website über die Programmierung in Assembler gesehen - das könnte mich interessieren, weil es einfach ist, von Assembler zu FORTH zu wechseln. ;-)

@znmeb Ja, ich versuche auch, einige MIOpen- und TensorFlow-Sachen auf meinem RX 480 zum Laufen zu bringen, aber ich möchte mein Hauptentwicklungs-Rig nicht zerstören, also verwende ich stattdessen die IOMMU-Virtualisierung und eine virtuelle Ubuntu 16.04-Maschine, die das verwenden kann RX 480. Die AMD-Treiber sind sehr virtualisierungsfreundlich (im Gegensatz zu nVidia-Treibern für Gaming-Karten – nur die Quadro-Treiber).

@znmeb Alles, was du tun musst, ist sudo apt-get install rocm miopen-hip

@adityaatluri Es befindet sich im Arch User Repository, wird aber nicht installiert - es wird auch nicht von der GitHub-Quelle installiert. Es sieht nach etwas Einfachem aus - es kann einige Abhängigkeiten nicht finden.

@znmeb Können Sie hier (https://github.com/RadeonOpenCompute/ROCm/issues) ein Problem erstellen, damit wir dort diskutieren können? Danke!

@adityaatluri Sicher - Ich gehe zum Abendessen, aber ich werde es einreichen, wenn ich zurückkomme

@ebrevdo Gibt es eine Möglichkeit, die Tensorflow-GPU auf einem Mac mit AMD-Prozessor zu verwenden?

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

Mein Unternehmen arbeitet seit einiger Zeit an OpenCL Deep Learning und wir können einige erste Ergebnisse vorweisen. Wir konzentrieren uns kurzfristig auf Keras, haben jedoch auch (sehr) experimentelle TensorFlow-Unterstützung aufgebaut und werden dies nach unserer ersten Veröffentlichung erneut überprüfen. Weitere Details hier, einschließlich anfänglicher Durchsatzzahlen auf AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl

Cool!

Kleiner Nitpick: AFAIK, MIOpen ist nicht AMD-spezifisch, da es sowohl mit OpenCL als auch mit ROCm verlinken kann. Letzteres ist wahrscheinlich schneller, aber immer noch; MIOpen ist ein großer Schritt nach vorne für den Shtick „Open Source Neural Networks On GPU“, und AMD verdient große Anerkennung dafür, wenn es auf OpenCL gut funktioniert.

14. August 2017, 17:19 Uhr, "Choong Ng" schrieb:
Mein Unternehmen arbeitet seit einiger Zeit an OpenCL Deep Learning und wir können einige erste Ergebnisse vorweisen. Wir konzentrieren uns kurzfristig auf Keras, haben jedoch auch (sehr) experimentelle TensorFlow-Unterstützung aufgebaut und werden dies nach unserer ersten Veröffentlichung erneut überprüfen. Weitere Details hier, einschließlich anfänglicher Durchsatzzahlen auf AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

—

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416) oder schalten Sie den Thread stumm (https://github.com/notifications/unsubscribe-auth /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Danke für die Korrektur, ich habe meinen Kommentar auf die Systemanforderungen in der MIOpen-Dokumentation (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#prerequisites) gestützt, aber gerne aktualisiert, wenn es eine gibt besser verlinken.

Warte, ich lese diesen Thread/diese Ausgabe jetzt seit 10 Minuten. Ich habe die Hälfte geschafft und den Rest übersprungen. Werden AMD GPUs schon unterstützt?

Verwenden eines kniffligen Closed-Source-Dings, das nur auf einer sehr alten Kombination von Kernel/OS (Codeplay) funktioniert: ja

Verwendung einer alten Version von Tensorflow und ohne Unterstützung für einige Nichtlinearitäten (tf-coriander): ja.

Wirklich: nicht offiziell. Obwohl AMD auf HIP portiert, würde ich Fortschritte innerhalb von etwa 3 Monaten erwarten. Andere Frameworks funktionieren aufgrund ihrer Bemühungen bereits gut.

Am 18. August 2017 02:09:55 GMT+01:00 schrieb abrad1212 [email protected] :

Warte, ich lese diesen Thread/diese Ausgabe jetzt seit 10 Minuten. Ich habe die Hälfte erreicht
durch und ich übersprang den Rest. Werden AMD GPUs schon unterstützt?

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -323233294

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

FWIW Ich glaube, dass die neueren Versionen von PyGpu entweder CUDA oder OpenCL verwenden können. Ich habe die gesamte Software auf meiner Arch-Box installiert, aber ich habe sie noch nicht getestet.

@abrad1212 Ja, dieses Problem gibt es schon seit einiger Zeit. Der Aufwand ist enorm und viele Leute versuchen, "es zum Laufen zu bringen", wie @cathalgarvey erwähnte.

Kleines Update von unserer Seite. Sie sollten ComputeCpp 0.3.0 auf dem AMDGPU-Pro-Treiber-Stack für Ubuntu 16.04 verwenden können. Die Anweisungen finden Sie hier: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 -04-lts/

Außerdem konzentrieren wir uns jetzt auf Leistungsverbesserungen für verschiedene Modelle – es gibt noch viel zu tun, aber wir kommen dorthin.

@lukeiwanski Was ist Ihr Benchmarking-Ansatz? Wir timen die in Keras enthaltenen Modelle und normalisieren sie gegen TF+cuDNN+K80, da dies eine gängige und gut optimierte Konfiguration ist. Unsere Methodik ähnelt der von Max Woolf (http://minimaxir.com/2017/06/keras-cntk/), es ist nicht viel Code, aber wir teilen ihn gerne. Wir haben einige Durchsatzzahlen auf unserer Website (http://vertex.ai), unser Code ist etwas schneller als TF 1.2 auf Xception-Inferenz und es wäre interessant, mehr Ansätze nebeneinander zu vergleichen.

Gibt es Windows-Lösungen? Ich würde Ubuntu auf meinem PC installieren, aber ich habe derzeit nicht genug Speicherplatz dafür.

Ubuntu 14.04
Tensorflow-Master-Zweig
Opencl-Unterstützung bauen und nur Opencl-Intel-CPU-Laufzeit installieren.
Python2.7
Folgen Sie https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow guide
Führen Sie python classify_image.py aus
Es scheint, dass der Opencl-Treiber nicht aufgerufen wurde. (Ich habe meinen opencl icd Wrapper hinzugefügt, nichts gesehen)
Muss in Python-Code eine Konfiguration hinzugefügt werden?
Wie sess.graph.device('/cpu0')

Aber wenn ich Eigen skcl guide verwende, kann es auf einer CPU mit OpenCL-Unterstützung ausgeführt werden. (Auch dieser Leitcode ist etwas veraltet, muss geändert werden)
https://developer.codeplay.com/computecppce/latest/getting-started-with-eigen

Jeder kann helfen zu prüfen, wie die Tensorflow-Python-Schnittstelle auch mit OpenCL-Unterstützung ausgeführt werden kann.

Und das Erstellen von Tensorflow mit diesem Opt-Set generiert nicht wirklich Tensorflow-Binärdateien. --config=sykl
Erstellen Sie einfach Tensorflow in diesem Befehl:
bazel build -c opt /tensorflow/tools/pip_package :build_pip_package

Vielleicht baue ich forget --config=sycl
Ich werde den Build-Befehl ausprobieren und überprüfen, ob er die OpenCL-Bibliothek aufrufen kann. Nachdem ich das Ergebnis erhalten habe, werde ich hier posten.
bazel build -c opt tensorflow/tools/pip_package :build_pip_package

@ joe8086 Wenn Sie die tf.Session-Erstellung mit dem Folgenden ändern, wird ein Protokoll im Terminal angezeigt. Wird hier irgendwo SYCL erwähnt?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Haben Sie für den Eigen-Leitfaden konkretes Feedback, wo er veraltet ist?

@rodburns Danke.
Mein Fehler ist Build Tensorflow Miss Config Option --config=sycl
Nachdem Sie diese Option mit diesem Branchencode hinzugefügt haben https://github.com/lukeiwanski/tensorflow.git
Ich kann sehen, dass Tensorflow mit OpenCL-Backend ausgeführt wird.

Für die Eigenführung liegt der Hauptfehler bei:
1, geben Sie keine korrekte Include-Datei an.
2, für Array, Tensor, TensorMap geben nicht den richtigen Template-Parameter an.
3, für static_cast keinen Datentyp angeben.

füge weitere Informationen hinzu, die diesem Diskussionsthema vielleicht helfen könnten.
1, Haupttensorflow kann Tensorflow nicht mit --config=sycl korrekt erstellen.
2, Mit CPU OpenCL beträgt die Geschwindigkeit etwa das 4- bis 8-fache der Ausgaben als bei einer normalen CPU-Implementierung in meiner Umgebung.

Zeit python classify_image.py
2017-09-07 16:56:29.076054: I tensorflow/core/platform/cpu_feature_guard.cc:137] Ihre CPU unterstützt Anweisungen, für deren Verwendung diese TensorFlow-Binärdatei nicht kompiliert wurde: SSE4.1 SSE4.2 AVX
2017-09-07 16:56:29.077967: W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] Keine OpenCL-GPU gefunden, die von ComputeCpp unterstützt wird, versucht OpenCL-CPU
07.09.2017 16:56:29.159775: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Folgende OpenCL-Geräte gefunden:
2017-09-07 16:56:29.159825: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] ID: 0, Typ: CPU, Name: Intel(R) Core(TM) i7-6700HQ CPU @ 2,60 GHz, Anbieter: Intel(R) Corporation, Profil: FULL_PROFILE
2017-09-07 16:56:30.213375: W ./tensorflow/core/framework/op_def_util.cc:333] Op BatchNormWithGlobalNormalization ist veraltet. Es funktioniert nicht mehr in GraphDef Version 9. Verwenden Sie tf.nn.batch_normalization().
Großer Panda, Panda, Pandabär, Waschbär, Ailuropoda melanoleuca (Punktzahl = 0,89107)
Indri, Indris, Indri Indri, Indri Brevicaudatus (Punktzahl = 0,00779)
Kleiner Panda, Roter Panda, Panda, Bärenkatze, Katzenbär, Ailurus fulgens (Punktzahl = 0,00296)
Zimtapfel (Punktzahl = 0,00147)
Erdstern (Punktzahl = 0,00117)

echte 1m44.473s
Benutzer 2m8.980s
sys 1m20.024s

Leute, ich werde nicht diesen ganzen Thread lesen, aber wenn jemand meine Frage beantworten könnte, wäre das großartig! Kann ich Tensorflow schon mit einer AMD-GPU verwenden? Wenn ja, in welchem ​​Betriebssystem und kann ich das mit RX Vega machen? Danke!

@M3L0NM4N Hmmm ... Ich habe den Thread nicht verfolgt, aber es sieht so aus, als ob es jetzt möglicherweise testbaren OpenCL-Code gibt, zumindest auf CPU OpenCL. Ich habe eine ältere AMD-GPU ("Bonaire") und OpenCL läuft sowohl auf der GPU als auch auf der CPU, damit ich das testen kann. Ich könnte es am Wochenende versuchen; Ich möchte wirklich OpenCL TensorFlow auf meiner GPU.

tf-coriander funktioniert https://github.com/hughperkins/tf-coriander

Irgendeine Tensorflow 1.3 GPU/Opencl-Unterstützung auf Macos?

Neueste Nachrichten: Ich habe erfolgreich TensorFlow 1.3.1 mit OpenCL aus der GitHub-Quelle erstellt. In der Dokumentation fehlen einige Teile, und ich habe noch nicht versucht, etwas in der GPU auszuführen, aber es funktioniert zumindest für Nicht-OpenCL-CPUs. Übrigens habe ich kein CPU OpenCL installiert, nur GPU OpenCL.

Hat jemand irgendwelche Testfälle für TensorFlow mit einer OpenCL-GPU? Irgendwann muss ich mir selbst einen bauen, aber ich hatte auf eine schnelle Überprüfung gehofft.

@znmeb Ja, es gibt eine Test-App, die ich gemeldet habe. https://github.com/hughperkins/tf-coriander/issues/64

Können Sie mir bitte mitteilen, ob es in Ihrem Fall funktioniert?

@unoexperto Ja - es funktioniert (stürzt nicht ab), aber es gibt keinen Hinweis darauf, ob es OpenCL gefunden hat oder nicht.

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

Ich denke, die beste Vorgehensweise hier ist, ein separates Problem einzureichen, um Dokumentation anzufordern, da es klar ist (wenn Sie ./configure Building aus dem Quellcode ausführen), dass es Code für OpenCL gibt. So fand ich es jedenfalls.

@znmeb Ich bezweifle, dass in Ihrem Fall ein GPU-Gerät gefunden wurde, da in meinem am Anfang Debug-Informationen zur Auswahl des GPU-Geräts gedruckt wurden. Vielleicht können Sie mit hinzugefügtem printf irgendwo in tensorflow/core/common_runtime/gpu/gpu_device.cc $ zur Konsole neu kompilieren.

@unoexperto Ich bin der Google-Diskussionsgruppe beigetreten und habe eine Dokumentationsanfrage gestellt. Ich werde abwarten, ob jemand antwortet, bevor ich mir mehr Mühe gebe.

@znmeb Welche Anweisungen befolgen Sie? Hast du clinfo ausgeführt? Hast du computecpp_info ausgeführt? Bedeutet das, dass Ihre OpenCL-Treiber wie erwartet installiert sind? Die Anweisungen für Ubuntu 14.04 finden Sie hier https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow und wenn Sie 16.04 verwenden, gibt es einige experimentelle Anweisungen hier http://deep-beta.co. de/tensorflow-1-3-on-ubuntu-16-04-lts/

@rodburns clinfo und clpeak laufen beide. Ich habe das in letzter Zeit nicht gemacht, aber wenn ich Caffe aus der Quelle baue und die Tests durchführe, trifft es definitiv die GPU. Ich bin mir also ziemlich sicher, dass die OpenCL-/GPU-Treiber/Bibliotheken funktionieren.

Ich bin auf Arch Linux - Kernel ist ihr LTS - linux-lts 4.9.52-1. Wenn es darauf ankommt, der „Bonaire“ erreicht im 32-Bit-Modus Spitzenwerte von etwa 1,7 TFLOPS und gehört zur „Sea Island“-Familie der AMD-GPUs.

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

Sammelt jemand Testprotokolle? Da steht, dass mein Gerät ungetestet ist, also werde ich es testen. ;-)

Unmöglich für mich, TensorFlow für Sycl/OpenCL zu bauen!

Konfig:
Ubuntu 16.04
Tensorflow r1.3
OpenCL 2.0
ComputeCpp CE 0.3.2 (computecpp_info OK)
Intel HD-Grafik 620
Basel 0.5.4

Installationsanweisung (OpenCL Intel / ComputeCpp build):
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

Fehler :

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 *)')

Das Training von Modellen auf meiner CPU dauert Ewigkeiten, ich brauche wirklich OpenCL/GPU-Beschleunigung ...

@ErwanGalline Wir sind dabei, Änderungen an Eigen ( https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None ) hochzuladen Beheben Sie das Problem, das Sie sehen.

Außerdem bereiten wir Leistungsverbesserungen für Eigen vor – das ist etwas knifflig und erfordert eine Koordination mit @benoitsteiner , um Zusammenführungskonflikte zu vermeiden – aber wir kommen dorthin.

Für AMD-Benutzer würde ich vorschlagen, meinen Fork auszuprobieren: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu
Eine Einrichtungsanleitung für Ubuntu 16.04 finden Sie hier: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Alle Änderungen werden dem Tensorflow vorgeschaltet, nachdem die erwähnten früheren Eigenänderungen vorhanden sind.

Ich hoffe, das hilft.

@lukeiwanski Unterstützt Ihre Gabel nur AMD R9 Nano / AMD FirePro GPU?

@lukeiwanski Gibt es einen Testfall, mit dem ich überprüfen kann, ob ich die GPU verwende? Ich kann es mit radeontop überwachen, aber ich hätte gerne etwas, das TensorFlow selbst verwendet.

@ZixuanLiang nein, nicht nur..
Wir testen derzeit auf AMD ( R9 380, R9 Nano, FirePro ). Wir wissen, dass die Intel-GPU einige Treiberfehler aufdeckt, aber es kommen Fixes. Und wir haben Renesas R-Car angekündigt und erwarten, dass weitere folgen werden.

Ich glaube, dass Xilinx die Unterstützung für triSYCL https://github.com/tensorflow/tensorflow/pull/12882 vorzieht – also sollte FPGs (?) – @keryell mehr darüber wissen

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test sollte eine faire Überprüfung sein. Die Ausgabe sollte ungefähr so ​​​​aussehen:
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 Danke, ich werde es auf AMD GPU versuchen

@lukeiwanski Der Build und der Test scheinen auf meinem Bonaire zu funktionieren. Ich verwende jedoch Python 3.6 und die Anweisungen verwenden Python 2.7. Muss ich 2.7 verwenden oder funktioniert 3.6?

@znmeb Nach https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647 scheint Python 3.6 zu funktionieren - ich habe es aber nicht ausprobiert

@lukeiwanski Ist das eine ComputeCpp-Version, die im Moment TF erstellen kann?
Ich habe verschiedene Versionen zwischen 0.3.2 und 0.1.4 ausprobiert und keine hat funktioniert. Sie endeten alle mit dem Fehler "mehrere Überladungen von 'global_ptr' instanziieren auf dieselbe Signatur".
Übrigens, ich kann die Datei TensorDeviceSycl.h in TF-Quellen nicht finden, ist das eine umbenannte? Ist es möglich, den Patch auf aktuelle Quellen anzuwenden?

Vielen Dank im Voraus.

@eLvErDe ComputeCpp 0.3.2 kann erstellt werden: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu

Upstream fehlt ein Patch für Eigen, der das Problem behebt. Siehe https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564

Irgendeine Idee, wie man diesen Eigen-Patch während des Bazel-Builds injiziert? Vielleicht sollten wir irgendwo eine eigene tgz-Version stoßen, um die gefixte zu bekommen?

Danke Adam.

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

Dieses Commit würde ausreichen, um es zu bauen?

ja, das solltest du dir aussuchen können

Leider reicht das eindeutig nicht aus, hier sind einige der nächsten Build-Fehler:

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 Es gibt nur wenige Commits, die Sie anwenden müssen, um es zu kompilieren.
Ich würde vorschlagen, den Tipp von dev/amd_gpu zu verwenden, oder wenn Sie Ihren aktuellen Zweig nicht ändern möchten, können Sie dev/amd_gpu damit zusammenführen.

Momentan arbeite ich an meinem inoffiziellen Debian/Ubuntu-Paket, also versuche ich nahe an der offiziellen Version 1.3.1 zu bleiben. Ich kann ohne OpenCL-Unterstützung leben, aber ich wäre bereit, sie zu aktivieren, sobald sie korrekt unterstützt wird. Vielleicht aktualisiere ich zu Testzwecken Pakete gegen Ihren Zweig, aber das reicht für heute ;)

Ich habe ungefähr zehn verschiedene Arten von AMD-GPUs in meinen Mining-Rigs. (von 7970 bis RX 480 mit ubuntu 16.04 und amdgpu-pro). Lassen Sie mich wissen, ob ich etwas beitragen kann, indem ich etwas teste.

Lassen Sie mich wissen, ob ich etwas beitragen kann, indem ich etwas teste.
Wie wäre es mit https://github.com/ROCmSoftwarePlatform/hipCaffe
https://github.com/ROCmSoftwarePlatform/hipeigen

Am Dienstag, den 17. Oktober 2017 um 10:54 Uhr schrieb slundell [email protected] :

Ich habe ungefähr zehn verschiedene Arten von AMD-GPUs in meinen Mining-Rigs. (von
7970 auf RX 480 mit Ubuntu 16.04 und amdgpu-pro). Lass es mich wissen, wenn ich kann
beitragen, indem Sie alles testen.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski Wird Ihr Fork auch AMD-GPUs unter macOS unterstützen?

Hallo,
Ich habe Tensorflow-APIs auf Ubuntu16.04 x64 für mein Android-Gerät mit aktivierter GPU (Mali-T720) erstellt.

Meine OS-Info:
Ubuntu 16.04 x64
Computer-GPU: NVIDIA 1080Ti
CUDA 8.0
CUDNN 5.1 (obwohl ich weder cuda noch cudnn zum Bauen verwende)
Bazel 0.5.2
ComputeCpp CE 0.3.2

meine build.sh ist:
'
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
'
vor dem Bau. Ich exportiere LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, Build ohne ' --config=sycl ' ist in Ordnung und ich habe die richtige libtensorflow_cc.so bekommen, aber mit ' --config=sycl ' stellte sich heraus, dass das Endergebnis fehlt -lComputeCpp ohne andere Fehler kompilieren

Vollständiges Protokoll wie folgt:

FEHLER: /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1: Verknüpfung der Regel „//tensorflow/contrib/android:libtensorflow.so“ fehlgeschlagen: link_dynamic_library.sh fehlgeschlagen: Fehler beim Ausführen des Befehls
(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: \
PATH=/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/ games:/usr/local/games:/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 nein ignoriert ignoriert ignoriert 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 / Arm-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, -ganz-Archiv bazel-out / Arm -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, -whole-archive 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 - no-canonical-prefixes '-march=armv7-a' -Wl,--fix-cortex-a8 '--sysroot=external/androidndk/ndk/platforms/android-14/arch-arm'): com.google.devtools.build.lib.shell.BadExitStatusException: Prozess beendet mit Zustand 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: Warnung: Überspringen von inkompatiblem bazel-out/arm-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/libComputeCpp.so während der Suche für 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: Fehler: kann -lComputeCpp nicht finden
collect2: Fehler: ld hat 1 Exit-Status zurückgegeben
Ziel //tensorflow/contrib/android:libtensorflow.so konnte nicht erstellt werden
INFO: Verstrichene Zeit: 617,736 s, kritischer Pfad: 54,66 s

ähm .... Ich möchte Tensorflow-APIs im Armbogen mit aktivierter GPU (Mali-T720) erstellen.
Würde mich freuen, wenn hier jemand Erfahrungen oder Anregungen hinterlassen könnte. Thx a loooot.

Kommen Sie zu meinem Vortrag nächste Woche auf der Arm TechCon, @laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Sie benötigen Mali-Treiber mit SPIR-V-Unterstützung, die wahrscheinlich noch nicht so einfach verfügbar ist. Und Sie benötigen eine ComputeCpp-Laufzeit für Android mit Arm-CPU-Unterstützung und SPIR-V-Unterstützung, die ebenfalls (noch) nicht verfügbar ist. Sie müssen also nur ein _kleines_ bisschen Geduld haben.

Wir (Vertex.AI) haben gerade PlaidML, unseren Deep-Learning-Stack mit Unterstützung für die Ausführung von Keras auf OpenCL, auf Open-Source-Basis bereitgestellt. TensorFlow-Support kommt, Hilfe dort wäre willkommen. Und ja, Mac-Unterstützung ist unterwegs (auch Windows). http://vertex.ai/blog/announcing-plaidml @ggaabe

@choongng Ich wollte es versuchen, bin aber gescheitert.
pip search plaidml kehrt zurück

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Aber pip install plaidml oder pip install plaidml==0.1.0rc3
kehrt zurück

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

@hy9be Ich denke, es wäre angemessener, ein Problem im plaidml-Repository statt hier zu machen, da es bei diesem Problem um die Unterstützung von OpenCL in Tensorflow geht. Wenn Sie sich die dortigen Installationsanweisungen ansehen, ist Ihr Pip-Installationsbefehl möglicherweise falsch.

Danke @andrewrichards für deine Aufmerksamkeit und deine Session-Rede.

Aber jetzt für mich (einen Doktoranden), um eine App mit Tensorflow auf einem Android-Gerät zu erstellen und eine GPU (Mali-T720) zu aktivieren, was erforderlich ist, um den Mali-Treiber mit SPIP-V-Unterstützung und ComputeCpp-Laufzeit für Android mit Arm-CPU zu erhalten Unterstützung und SPIR-V-Unterstützung.

Da ich ComputeCpp (Ubuntu16.04 x64 mit bin/doc/include/lib/) auf der CodePlay-Homepage heruntergeladen habe, führe ich gestern Folgendes aus:
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
Fehler sagten libComputeCpp.so incompatible , also denke ich, dass ich vielleicht ComputeCpp für Android mit Arm-CPU-Unterstützung und SPIR-V-Unterstützung brauche, aber ich konnte keinen Quellcode finden, um ein Android ComputeCpp zu erstellen, es gibt nur Beispiele bei github.

Und Sie haben gesagt, dass ComputeCpp für Android jetzt nicht verfügbar ist. Gibt es also Pläne, Android-Geräte zu unterstützen, oder wie kann ich es bekommen, wenn es unterstützt wird?

Für AMD-GPU- und Linux-Benutzer hat AMD kürzlich die HIP-Portierung von Tensorflow hier veröffentlicht. Du könntest interessiert sein.

Ich habe es aber nicht getestet.

Ich kann es testen - seid gespannt. Sieht aber so aus, als würde CI versagen.

Tatsächlich scheitert es. Noch in einem frühen Stadium, denke ich.

Ich habe es getestet und im MNIST-Beispiel sofort einen Segfault erhalten.
Weiß nicht was ich hier falsch mache.

$ 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 - stellen Sie sicher, dass Sie rocm 1.6.4 base installiert haben.

@bensander Danke, ich werde upgraden.

@bensander Benötige ich noch etwas vom AMD-Stack? Alles, was ich jetzt habe, ist die proprietäre Opencl-Bibliothek von AMD, die den Open-Source-Treiber "amdgpu" verwendet.

@masahi - wenn Sie rocm und rocm-libs installieren (dh "apt-get install rocm rocm-libs"), sollte das alles sein, was Sie brauchen. Die rocm_docs im Bericht enthalten vollständige Anweisungen einschließlich der erwarteten Ergebnisse.

@bensander woher weiß ich, ob ich rocm 1.6.4 korrekt ausführe (und nicht 1.6.3)?

@masahi nur eine Vermutung: Sie sollten die Frage an einem verwandteren Ort für Ihr Problem stellen, z. B. beim AMD- oder RoCM-Projekt, und nicht hier ...

@keryell richtig, ich komme vom Thema ab. Ich höre hier auf.
Wie auch immer, ich konnte Hiptensorflow nicht auf meinem System zum Laufen bringen. Ich werde es später mit einer sauberen Ubuntu-Installation versuchen.

@masahi – eröffne einfach dort drüben ein Problem und wir kümmern uns darum.

Hallo, ich möchte nur erwähnen, dass ich Hiptensorflow zum Laufen bringen konnte, dank @bensander und anderen Leuten bei AMD. Ich kann alle Beispiele in ihrer Schnellstartanleitung ausführen.

Danke

Für diejenigen, die TensorFlow auf AMD-Hardware mit ROCm ausprobieren möchten, habe ich einen Blog geschrieben, in dem beschrieben wird, wie Fast.ai-Notebooks mit AMD Fury Nano ausgeführt werden.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 Ich kann es kaum erwarten!

ROCm 1.7 ist auf dem Weg, mit dem, was sich nach richtiger Tensorflow-Unterstützung anhört!

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

Tensorflow-Portierung auf AMD-GPU:
https://github.com/ROCmSoftwarePlatform/hiptensorflow/blob/hip/README.ROCm.md

Es funktioniert großartig für mich. Meine Hardwareeinstellung:
Grafikkarte: AMD Radeon RX 480
Prozessor: Intel Xeon 2603 v3
MB: supermicro x10srl-f

Der Schlüssel ist, dass Motherboard und CPU PCIe v3 unterstützen müssen

Seine Leistung ist ähnlich wie bei Nvidia 980Ti

Ich kann nicht einmal die "unterstützten" AMD-Treiber auf meiner "unterstützten" Ubuntu 16.04 LTS-Installation zum Laufen bringen. Geplante Obsoleszenz?

znmeb, was ist deine AMD-GPU? Wenn Sie zwei GPUs haben, deaktivieren Sie die nicht unterstützte im BIOS.

Konnte nicht den ganzen Thread lesen ... wie ist der aktuelle Status für Tensorflow auf OpenCL auf MacOS (Sierra +)? Insbesondere habe ich eine Intell Iris-GPU und hatte gehofft, ich könnte aus der Quelle Tf + Open CL-Unterstützung dafür bauen.
Außerdem scheint tf corrainder in Version 1.2 gut zu laufen.

@varun19299 FWIW, es gibt ein Intel SDK für OpenCL - ich habe es auf meinem alten Sandy Bridge-Laptop, aber ich bin sicher, es wird auf Ihrem Computer funktionieren. https://software.intel.com/en-us/intel-opencl

Ist dies derzeit auf Nicht-Ubuntu-Linux-Systemen in einem verwendbaren Zustand? Die Roadmap-Seite verlinkt einfach hier.

@pfc Ist das, was derzeit auf Nicht-Ubuntu-Linux verwendbar ist? TensorFlow mit OpenCL im Allgemeinen? Oder TensorFlow mit OpenCL auf einer AMD-GPU? Ich gehe von letzterem aus, da dies der einzige Grund ist, warum Sie TensorFlow mit OpenCL ausführen möchten. Für eine NVidia-GPU würden Sie die NVidia-Treiber / -Bibliotheken verwenden, und für CPU-only gibt es nichts von OpenCL zu gewinnen.

Ich hatte dies vor ein paar Wochen unter Arch Linux unter Verwendung der proprietären ComputeCpp SYCL-Bibliothek und einer AMD "Bonaire" (Sea Islands-Architektur) GPU. Es gibt eine neue ComputeCpp-Version, die ich testen muss, aber ich vermute, dass sie funktionieren wird.

Es stellt sich heraus, dass die proprietären AMDGPU Pro-Bibliotheken, die Sie für diese Arbeit benötigen, nicht auf Ubuntu 16.04.3 ausgeführt werden. Das Upgrade von 16.04.2 brachte einen neueren Linux-Kernel und X Server, und AMD muss noch etwas liefern, das darauf funktioniert. Einzelheiten finden Sie unter http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-Compatibility-Advisory-with-Ubuntu-16.04.2-and-16.04.3.aspx . Ich konnte AMD OpenCL nicht unter Ubuntu zum Laufen bringen.

Es gibt eine experimentelle AMD-Version von TensorFlow, die einen Compiler verwendet, um CUDA-Code in OpenCL-Code zu übersetzen, aber ich habe das auch nicht getestet. In Ermangelung eines unterstützten Treibers ist es nutzlos.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs ist die offiziell unterstützte Methode zum Ausführen von Tensor Flow auf AMD-Hardware.

@bensander Funktioniert die ROCm-Laufzeit unter Ubuntu 16.04.3? Ich habe es nicht geschafft, es zum Laufen zu bringen.

PS: Haben Sie einen Einblick, ob / wann das AMDGPU-Pro-Setup auf Ubuntu 16.04.3 funktioniert? Ich brauche das für ein anderes Projekt.

Hmm, ich mache (und würde) nirgendwo Spaß mit Ubuntu, aber ich habe ein CentOS 7 mit Repos und einer GTX1080TI darin, auf dem Kernel 4.14.x und der neueste Beta-Treiber von Nvidia laufen, also könnte ich helfen, es zu testen irgendwann heute noch da, ob es hilft?

--
Sam McLeod

Am 7. Dezember 2017 um 07:28 schrieb M. Edward (Ed) Borasky [email protected] :

@bensander Funktioniert die ROCm-Laufzeit unter Ubuntu 16.04.3? Ich habe es nicht geschafft, es zum Laufen zu bringen.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@sammcj Warum sollten Sie eine NVidia-GPU mit OpenCL ausführen, wenn es dafür vollkommen gute CUDA-Bibliotheken gibt?

Nur um es für Sie zu testen!

Keine Sorge, wenn Sie keinen Handtest brauchen, dachte ich nur, ich würde es anbieten. Ich habe diese Maschine noch nicht einmal mit cuda TBH ausprobiert, ich habe sie nur unter MacOS ausprobiert, wo ich OpenCL im Moment nicht über Docker verwenden kann.

--
Sam McLeod

Am 7. Dezember 2017 um 08:16 Uhr schrieb M. Edward (Ed) Borasky [email protected] :

@sammcj Warum sollten Sie eine NVidia-GPU mit OpenCL ausführen, wenn es dafür vollkommen gute CUDA-Bibliotheken gibt?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@znmeb Ich wollte ComputeCpp SYCL ausprobieren, aber sie stellen nur das Ubuntu-Installationsprogramm bereit (ich bin auch auf Arch) und das Aur-Installationsskript ist defekt. Es ist gut zu hören, dass es funktionieren kann. Wenn ich verzweifelt genug bin, probiere ich es vielleicht aus.
@bensander Das sieht genau nach dem aus, was ich brauche, um ADM-Unterstützung zu erhalten, aber ich bin besorgt über die Tatsache, dass dieser Code nicht auf TF zurückportiert wurde und dass sein Code zuletzt vor über 2 Monaten aktualisiert wurde, da mein Code auf TF 1.4 abzielt. 0
Es scheint, als ob Tensorflow Sie im Moment im Grunde an Nvidia bindet, zumindest für uns "sterbliche" Programmierer. Fehlende Dokumentation/aktualisierte Roadmap hilft nicht. Ich hätte nichts dagegen, auf jede erdenkliche Weise zu helfen, aber ich hatte bisher wenig Erfolg damit, die Dinge zum Laufen zu bringen.

@pfc Ich habe das ComputeCpp SYCL auf Arch zum Laufen gebracht - es gab einen binären Tarball auf ihrer Website, als ich es tat.

In dieser Nachricht über die Veröffentlichung von SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
es sagt :
_Die neue Spezifikation enthält bedeutende Erfahrungen aus drei separaten Implementierungen und Feedback von Entwicklern von Frameworks für maschinelles Lernen wie TensorFlow, das jetzt SYCL neben dem ursprünglichen CUDA-Beschleuniger-Back-End unterstützt._

Bedeutet das, dass es jetzt möglich ist, TensorFlow „einfach“ auf AMD-GPUs auszuführen, die OpenCL 1.2 unterstützen, auf dem SYCL aufbaut?

"Leicht" in dem Sinne, dass einige Low-Level-Software / Treiber / Bibliotheken für die AMD-Hardware dort sind, wo die meisten kaputten Sachen sind, nicht in der Hardware oder TensorFlow oder den OpenCL-Standards oder SYCL. ;-) Wenn Sie funktionierende AMD-GPU-Treiber und funktionierende OpenCL-Bibliotheken haben, haben Sie TensorFlow auf AMD-GPUs.

Mein funktionierendes Setup für einen AMD Bonaire (Sea Islands-Architektur):

Arch Linux mit geladenem Kernelmodul amdgpu und Kernelmodul radeon der schwarzen Liste
Das Arch-Benutzer-Repository-Paket opencl-amd
Die ComputeCpp-Bibliothek
TensorFlow wurde aus dem Quellcode auf meiner Workstation mit @lukeiwanski 's Fork erstellt:

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

Ich bin etwas überrascht von dem, was Sie gesagt haben: "Wenn Sie funktionierende AMD-GPU-Treiber und funktionierende OpenCL-Bibliotheken haben, haben Sie TensorFlow auf AMD-GPUs". Ich hatte verstanden, dass die „offizielle“ Version von TensorFlow nicht auf OpenCL lief (nur CUDA). Scheint, als wäre ich verwirrt.
Ich war ziemlich froh, das PlaidML-Projekt zu finden, das zumindest einigen Keras-Code ermöglicht, auf meinem iMac mit AMD Redeon HD 6970 ausgeführt zu werden. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) AFAIK Sie haben auch dieses Framework ausprobiert.
Ich werde versuchen, TensorFlow auf der Ubuntu VirtualBox auszuführen, wo TensorFlow bereits läuft (nur CPU).

@PALYGAP Ich glaube nicht, dass VirtualBox OpenCL von einem Mac-Host in einen Linux-Gast exportiert, und Ubuntu 16.04.3 funktioniert derzeit nicht. Ich habe keinen Mac, also habe ich keine Möglichkeit, Dinge zu testen.

Hat jemand erfolgreich TensorFlow auf AMD über OpenCL ausprobiert und war erfolgreich?

@mohnkhan Ich habe die @lukeiwanski -Gabelfunktion (Arch Linux) - siehe https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . Ich warte auf weitere AMDGPU-Pro-Arbeiten, bevor ich einen Blogbeitrag veröffentliche – siehe https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Vielen Dank für die Beiträge

@mohnkhan Übrigens , AMD baut einen alternativen Pfad auf, der vollständig Open Source ist - die Übersetzung des CUDA-Codes in OpenCL-Code mit einer Compiler-Toolchain. Ich bin mir jedoch nicht sicher, wie der Status bei älteren Karten wie meiner ist.

Wenn Sie einen Artikel schreiben, würde es nicht schaden, ihn auch zu erklären (es dauerte 3 Stunden, um das ganze Bild zu bekommen):

• TF hat tatsächlich ein SYCL 1.2-Backend. Keine *tatsächliche* offene Kl.
• Im Gegenzug haben Sie zwei Implementierungen des Standards (trisycl sieht cool aus, ist aber begrenzt atm)
• Am Ende "hakt" ComputeCpp SPIR /SPIR-V (zusätzlich zu PTX, aber das ist wirklich eine andere Geschichte )

Und das bringt Sie schließlich direkt zu Ihrem verdammt ersehnten OpenCL 1.2 (mit cl_khr_spir ext)

HIP ist stattdessen ein weiteres Backend, sitzt gegenüber von SYCL und zielt nur und ausschließlich auf ROCm ab (oder gut, lol, sogar wiederum cuda, wenn Sie eine NVIDIA-GPU haben. Aber das ist wieder eine andere Geschichte).

AMD entwickelt einen alternativen Pfad, der vollständig Open Source ist – die Übersetzung des CUDA-Codes in OpenCL-Code mit einer Compiler-Toolchain.

Nö. Sie sprechen von HIP, und das ist es eigentlich, wozu Sie Ihren Code schließlich konvertieren. Was nicht OpenCL ist.
HIP läuft dann auf ROCm, wie ich schon sagte ...
ROCm, das auch OpenCL für Sie ausführt (auf unterstützten Karten ), aber bitte möchte ich alle betonen, dass sie bemerken, dass die Beziehungen von ROCm nur nach vorne gerichtet sind, niemals "intra-sub-layers".

Woran Sie vielleicht denken, könnte Koriander sein.

Ich bin mir jedoch nicht sicher, wie der Status bei älteren Karten wie meiner ist.

Zusammengefasst hier : vollwertiger AMDGPU-PRO, AMDGPU-Pro-Opencl-Only-Treiber, wie Sie es jetzt tun ... Oder weiterhin bis zum Ende des Jahrzehnts warten, bis jemand Clover endlich nutzbar macht.

Auch fglrx ... Aber wenn das für Pre-GCN-Karten schwer zu empfehlen ist, denke ich, dass es einfach besser ist, einen Schleier darüber zu ziehen.

@mirh

1. Ich mache mir keine Sorgen um Pre-GCN-Karten. Meine ist eine Sea Islands und ich habe nicht vor, etwas Älteres zu erwerben. Andererseits plane ich auch nicht, eine andere AMD-GPU zu erwerben. ;-)
2. Ich weiß nicht, ob ROCm auf meiner Workstation laufen wird - es gibt keinen Open-Source-Hardwaretester, der mir eine Ja-oder-Nein-Antwort geben kann. Ich habe dazu ein Thema eröffnet und keine Antwort erhalten.
3. SPIR-V ist ein Compiler-Target - ich habe es mir angesehen und die Hände hochgeworfen, da ich kein Budget hatte, um einen Compiler-Autor einzustellen.

Bleibt also SYCL ... oder meine anderen beiden Hände hochwerfen und alles mit Keras machen, das TensorFlow-, Theano- (das einfriert), CNTK- oder PlaidML-Backends hat. Aus rein ingenieurökonomischer Sicht ist Keras / PlaidML ein großer Gewinner, sofern ich TensorBoard irgendwie bekomme.

@mirh danke für die gute Zusammenfassung mit allen Links. Ich denke du hast deine 3 Stunden nicht verschwendet... :-)

Ich weiß nicht, ob ROCm auf meiner Workstation laufen wird - es gibt keinen Open-Source-Hardwaretester, der mir eine Ja-oder-Nein-Antwort geben kann. Ich habe dazu ein Thema eröffnet und keine Antwort erhalten.

Wie ich dir schon oft gesagt habe, nein, es wird nicht funktionieren.
Pre-GCN-GPUs der 3. Generation fehlt einfach die Hardware, damit ROCm entweder funktioniert oder überhaupt funktioniert.

SPIR(-V).. Ich bin mir nicht sicher, wovon Sie sprechen. Es ist nicht Ihre Aufgabe, sich darum zu kümmern. Computecpp macht es aus SYCL "Befehlen", und dann ist es alles (opencl) Treibergeschäft.

Sie haben das, was ich vorläufig nur amdgpu-pro-opencl-nenne, und ich bin mir nicht sicher, was dann das Problem ist.
BEARBEITEN: Es wäre auch cool, eine Art ETA für Lukes Code zu haben, um zu landen

@znmeb und alle

Ich habe (L)Ubuntu 17.10 inkl. Kernel 4.14.x und die OpenCL-Bibliotheksteile des AMDGPU Pro 17.40-Treibers laufen und können OpenCL-Anwendungen wie clinfo oder Boinc (z. B. Engima @Home , Milkyway@Home) ohne Probleme auf meiner AMD A12-9800E APU ausführen.

Ich kann auch die CPU-Version von Tensorflow (derzeit Version 1.4.1) erfolgreich kompilieren und verwenden. Aber ich kann die OpenCL-Version von Tensorflow nicht erfolgreich kompilieren. Ich verwende computecpp 0.5 (das aktuelle, das ich ohne Registrierung herunterladen kann) zusammen mit Vanilla Tensorflow 1.4.1 und mit dem Zweig "dev/amd_gpu" von @lukeiwanski 's Fork.

Könnte also bitte jemand, der die OpenCL-Version von Tensorflow erfolgreich kompiliert hat, einige Informationen bereitstellen, welche Version der computecpp-Bibliothek und welchen Zweig von welchem ​​Tensorflow-Git er / sie verwendet?

Danke

@AlphasCodes Ich habe nichts auf Ubuntu laufen - alle meine Arbeitssachen sind auf Arch. Ich habe die Maschine mit Ubuntu 16.04.3 doppelt gebootet, aber die proprietären AMD-Bibliotheken funktionieren dort noch nicht. Soweit ich weiß, werden sie auf 17.10 nicht unterstützt, aber wenn Sie das OpenCL-Stück auf 17.10 zum Laufen gebracht haben, füge ich möglicherweise einen dritten Start hinzu - ich habe viel Speicherplatz. ;-)

Welche Art von Fehlern erhalten Sie? Wenn es sich um Buildfehler handelt, liegt möglicherweise eine Bazel-Inkompatibilität vor. Bazel entwickelt sich ständig weiter wie TensorFlow und manchmal wird einer dem anderen voraus sein.

Was meinst du mit "nicht unterstützt"?

Dies .
Was Ubuntu betrifft, so soll nur 16.04.3 unterstützt werden (zumindest offiziell dann, wenn man bedenkt, dass selbst Arch es nach etwas Skriptmagie zum Laufen bringen kann).
BEARBEITEN: 'vollständiger' AMDGPU-PRO-Treiber erfordert Kernel 4.9, das war wahrscheinlich das Problem

Falls es jemanden interessiert, die Portierung von AMDGPU-Pro Driver 17.40 auf Arch ist im Gange und auf GitHub unter https://github.com/corngood/archlinux-amdgpu/pull/54 sehr aktiv.

Wir sollten dieses Thema wirklich schließen, da TensorFlow, wie @mirh betonte, SYCL und nicht OpenCL verwendet. Vielleicht sollten wir ein anderes öffnen, "TensorFlow auf AMD-Karten"??

Nein, es ist völlig legitim.
Sie möchten, dass Tensorflow irgendwann auf Opencl-Geräten ausgeführt wird, das ist das Ziel. Legitim und Ende.
Zu sagen, dass es tatsächlich SYCL verwendet, war nur ein technischer Trottel, den ich machte, weil mich all diese Akronyme für magisch zufällige Technologien verrückt machten.
EDIT: Ich möchte auch allen Codeplay-Jungs für ihre ungeheure Arbeit danken

Wenn Sie etwas ganz Spezielles für AMD wollen, würde ich empfehlen, ihren Hiptensorflow zu überprüfen. Nur ROCm. Und bitte lassen wir diese Argumentation hinter uns.

OK, ich weiß nicht, ob ich bis zum Wochenende genug Zeit habe, um den Build erneut durchzuführen und die Kompilierungsfehler bereitzustellen. Aber ich habe meine vorhandene Dokumentation zu meinem neuen Github-Repo hinzugefügt.

Siehe https://github.com/AlphasCodes/DeepLearning für Details (mein Hardware-/Software-Setup + AMD OpenCL-Setup + Tensorflow-Setup).

@mirh , um die "Akronyme magisch zufälliger Technologien [...] zu verdeutlichen, die [Sie] verrückt machen":

Im Reich der Khronos-Gruppe ist OpenCL die Non-Single- Source -API auf niedriger Ebene und SYCL die domänenspezifische eingebettete Sprache (DSeL) von C++ auf hoher Ebene. Es wird erwartet, dass SYCL auf OpenCL aufbaut, sodass Sie aufgrund der Transitivität bei der Verwendung von SYCL häufig OpenCL verwenden.

Da TensorFlow Eigen verwendet, das einen Single-Source- C++-Ansatz mit Single-Source- CUDA verwendet, wurde SYCL gewählt, als es später auf OpenCL portiert wurde, da es die Standardmethode der Khronos Group für Single-Source- C++ ist.

Aber wenn Sie an CUDA denken, ist es noch subtiler.

Fast jeder verwendet die High-Level- Single-Source- Version von CUDA, die eigentlich "CUDA Runtime API" heißt. Das ist irgendwie ähnlich wie SYCL.
Aber es gibt tatsächlich eine weniger bekannte Low-Level -Version von CUDA, die nicht aus einer einzigen Quelle stammt und als "CUDA Driver API" bezeichnet wird, ähnlich wie OpenCL, und beispielsweise von der "CUDA Runtime API"-Implementierung selbst verwendet wird.

Da es sich um eine Art FAQ handelt, habe ich https://en.wikipedia.org/wiki/SYCL und https://en.wikipedia.org/wiki/CUDA etwas präzisiert

ComputeCpp, die SYCL-Implementierung, die Sie mit TensorFlow verwenden, unterstützt Ubuntu 17.10 noch nicht. Sie müssten sich an Ubuntu 16.04 halten, das das aktuelle LTS ist. Anweisungen und Voraussetzungen finden Sie hier https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow

Abgesehen davon bedeutet die OpenCL-Unterstützung für TensorFlow nicht nur die Unterstützung von AMD-Geräten. Die SYCL-Integration aktiviert auch andere OpenCL-Geräte. Als Teil der Arbeit, die wir mit TensorFlow leisten, wird die Unterstützung für ARM- und Intel-GPUs verfügbar sein, sobald die neuesten Treiber dieser Unternehmen verfügbar sind. Wir arbeiten auch daran, die Unterstützung für Beschleunigerprozessoren von Renesas auch für die R-Car-Plattform zu ermöglichen.

@rodburns Danke! Ich habe dies unter Arch Linux (Kernel 4.14.4) mit der opencl-amd-Bibliothek aus dem Arch User Repository. Die Karte ist eine Bonaire (GCN 2.0). Ich werde die Tests auf dieser Seite ausführen, um zu überprüfen, ob sie das tut, was sie sollte.

GCN 2. Generation (alias 1.1) falls vorhanden, 2.0 existiert nicht.
(sollte sich bücken, um so pedantisch zu sein)

ERFOLG!

Die neuesten „dev/amd_gpu“-Zweig-Commits in @lukeiwanski- Fork haben mein Tensorflow-OpenCL-Kompilierungsproblem behoben. Ich nehme an, es waren die Commits im Zusammenhang mit SysCL 1.2.1.

Ich habe erfolgreich eine Tensorflow OpenCL-Version kompiliert und kann sie verwenden. Weitere Informationen finden Sie in meinen Tensorflow-Setup-Dokumenten .

Ich habe auch eine Benchmark-Seite hinzugefügt, auf der Sie in Zukunft einige Benchmarks meines Setups unter verschiedenen Tensorflow-Setups (nicht CPU-optimiert, CPU-optimiert, OpenCL) finden können.

Die AMDGPU Pro-Treiberversion 17.50 funktioniert auch bei mir. Ich habe das zugehörige AMD OpenCL Setup- Dokument aktualisiert.

Vielen Dank an alle Mitwirkenden.

Ich habe einige Benchmarks durchgeführt und es scheint, dass die iGPU langsamer ist als die 4 verfügbaren CPU-Threads, mit Ausnahme des matmul_bench.py- Benchmarks.

Die Initialisierung eines OpenCL-Tensorflow-Laufs ist auch viel langsamer als ein OpenCL-Tensorflow-Lauf nur mit CPU. Etwa 5 Sekunden für die CPU gegenüber 1-2 Minuten für OpenCL.

Kann jemand solche Ergebnisse bestätigen?

OK, ich habe noch mehr Fehlersuche gemacht.

• Ich habe das Tensorflow-MNIST-Beispiel verwendet, siehe das Dokument Validate a Tensorflow Setup
• Ich habe "sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info" verwendet, um die iGPU-Uhr/-Last zu überprüfen/überwachen, und "top", um die CPU-Last zu überprüfen
• Die Initialisierungsphase bis Step 0 dauerte etwa 6 Minuten, die iGPU-Last lag bei etwa 0 %, der iGPU-Takt bei 300 MHz (der minimal verfügbare Takt) und die CPU-Auslastung des Python-Prozesses betrug etwa 200 % (= 2 Threads).
• ab Step 0 betrug die iGPU-Last ca. 90 %, der iGPU-Takt wechselte immer von 654 MHz - 720 MHz - 800 MHz - 900 MHz (max. verfügbarer Takt) und zurück, die CPU-Auslastung des Python-Prozesses betrug ca. 100 % (= 1 CPU Gewinde)

Ich versuche immer noch, Dinge auf Arch zu kompilieren.

Was ich gestern benutzt habe .
Nach 14 Stunden (ja, meine Kartoffel ist sehr langsam) habe ich diese Binärdatei erhalten , wenn Sie es versuchen möchten.

Ich habe versucht herauszufinden, was passiert, aber leider konnte ich es nicht. Ich würde mich freuen, wenn jemand, der sich mit den folgenden Dingen auskennt, mir helfen kann, auf den neuesten Stand zu kommen!

Der größte Teil der obigen Diskussion bezog sich darauf, Tensorflow mit OpenCL-Beschleunigung auf AMD-Chips zum Laufen zu bringen. Bin ich richtig, wenn ich das sage? Wenn ich GPU-beschleunigten Tensorflow mit meiner integrierten Grafikkarte (Intel HD 5000) erhalten möchte, die OpenCL unterstützt, wie sollte ich vorgehen?

Vielen Dank im Voraus!

@znmeb Hallo Ed, danke für die Antwort. Ich habe OpenCL heruntergeladen und auf meinem System ausgeführt. Aber meine Frage war: Wie kann ich Tensorflow kompilieren, um die OpenCL-Bibliotheken tatsächlich zu verwenden?

https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
Und am wichtigsten für Intel https://github.com/codeplaysoftware/computecpp-sdk/issues/78#issuecomment -352411192

@AlphaCodes Vielen Dank für die Veröffentlichung Ihrer Ergebnisse. In Bezug auf die Initialisierungszeit funktioniert OpenCL so, dass der Code vor der Ausführung kompiliert wird, sodass die Startzeit der Kompilierungsprozess ist.

@brainwave Für Intel-Geräte gibt es hier einen Thread mit @mirh , der erklärt, wie man die Beschränkungen rund um laufende Geräte aufhebt. Wir haben Probleme mit Intel-Treibern festgestellt, weshalb diese Gerätetypen eingeschränkt sind, aber wir hoffen, dass bald aktualisierte Treiber für Intel-Geräte verfügbar sein werden, die die Unterstützung verbessern. In der Zwischenzeit können Sie TensorFlow mit der Änderung neu kompilieren, um Ihre eigene Intel-Hardware zu testen. Wir arbeiten daran, die Geräteeinschränkungen in der Codebasis zu entfernen.

@AlphasCodes Leute , ich entschuldige mich für die vielleicht naive Frage, aber warum ist dieser Build nur AMD GPU? Sollte OpenCL nicht Standard sein? Verstehe ich es richtig, dass es auf meinem Intel Carbon X1 mit installierten OpenCL 2.0-Treibern nicht funktioniert?

Wenn Sie die doppelt verlinkte Ausgabe lesen, werden Sie sehen, dass nichts über AMD gpu steht.
Intels ist derzeit ausgeschlossen, aber es hat nichts damit zu tun, Benutzer zwingen zu wollen, und es gibt eine vorübergehende Problemumgehung - diskutieren Sie dort, wenn es wirklich welche gibt.

Wenn ich den Zweig amd_gpu mit einem Jupyter-Notebook verwende, scheint ein Thread übrig zu bleiben. Python verwendet immer noch 100% einer CPU, auch nachdem die Berechnung abgeschlossen ist. Ein Neustart des Kernels beendet den streunenden Thread. Hat das noch jemand erlebt?

@brainwave @unoexperto
Leider kann ich bei Intel OpenCL nicht helfen, da ich nur AMD OpenCL-Hardware habe.

@desperadoduck
Jupyter verwende ich noch nicht. Ich verwende eine einfache Bash-Shell und eine virtuelle Python 3-Umgebung ( siehe mein Python 3 + Tensorflow-Setup ). Aber ich kann das Problem nicht reproduzieren. Es gibt keine CPU-Auslastung durch einen Python-Prozess, nachdem die Berechnung abgeschlossen wurde.

@rodburns
Danke für die Information. Ist es möglich, die anfängliche Kompilierzeit zu beschleunigen? zB Nutzung aller verfügbaren CPU-Threads statt nur 50%.

@brainwave @rodburns
Für die Intel-GPU (Gen9) unter Linux haben wir eine deutlich bessere DNN-Leistung mit Intels Open-Source-Beignet-Implementierung im Vergleich zur Closed-Source-Implementierung beim Benchmarking mit gemeinsamen Vision-Netzen auf PlaidML gesehen. Beignet ist auch einfacher zu installieren, was schön ist.

Unterstützt es Intel Graphics HD615 (CPU der 7. Generation) auf Ubuntu 17.10?

Der opencl-Treiber SRB5.0 für Linux64 läuft gut auf Ubuntu17.10.

Und es wurde lange nicht aktualisiert:
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Um Himmels willen, kannst du nicht einfach 2 (zwei!) Posts oben lesen?
Diskutieren Sie hier https://github.com/codeplaysoftware/computecpp-sdk/issues/78 über den Mangel an Intel-GPU- (oder AMD-CPU-) Unterstützung

@znmeb Es ist ein Ziel, verschiedene Rechenressourcen (z. B. CPU, GPU, DSP, andere Coprozessoren) voll auszunutzen.
Tatsächlich hängt es von der Unterstützung der Hardwareanbieter ab: Treiber und Betriebssystem.
Wie ich weiß, können Sie aufgrund der Einschränkung des Vedio-Treibers möglicherweise nicht gleichzeitig die Intel-GPU und die NVIDIA-GPU für Video aktivieren. (Möglicherweise können Sie zwischen ihnen wechseln).
Opencl kann sie jedoch gleichzeitig verwenden. Sie sind beide "Geräte" darin.

@choongng Das ist interessant zu wissen, wir haben einige Arbeit geleistet, um Beignet zu ermöglichen, aber die Aktivitäten in diesem Projekt scheinen etwas ruhig geworden zu sein.

@znmeb Ja, jede GPU wird bei einem kleinen Problem wahrscheinlich nicht viel besser abschneiden, aber ich bin froh, dass Sie einige Fortschritte machen!

@unoexperto ComputeCpp mit TensorFlow kann von jeder Hardware verwendet werden, die SPIR OpenCL-Zwischenanweisungen unterstützt, einschließlich Intel-GPUs, aber wie im Thread hier hatten wir die Ausführung absichtlich verhindert, weil wir nicht glaubten, dass die aktuellen Treiber im Moment funktionieren . Sie können diese Einschränkung entfernen, da es so klingt, als hätten einige Benutzer es mit verschiedenen Intel-Treibern zum Laufen gebracht. Wir arbeiten auch daran, dies für ARM- und Renesas -Prozessoren mit OpenCL-Treibern zu ermöglichen.

@ sxpc722 Das sollte dann funktionieren. Übrigens, die neue Maschine ist Windows 10 und ich habe nicht vor, sie mit Linux dual zu booten, bis ich es unbedingt tun muss! Ich habe es satt, Treiber- und Bibliotheksfehlern für Anbieter nachzujagen (ich sehe Sie an, AMD). Tatsächlich kann ich aus demselben AMD-Grund eine Windows-Partition auf meiner Workstation erstellen. ;-)

Es sind 14 Tage ohne Aktivität vergangen und dieses Problem hat einen Beauftragten. Bitte aktualisieren Sie das Label und/oder den Status entsprechend.

Die Leistung von Tensorflow AMD OpenCL ist meinen Tests zufolge sehr langsam. Also habe ich einige grundlegende Tests mit einem anderen Deep-Learning-Framework durchgeführt. Mein Setup und meine Benchmarks finden Sie hier auf meiner GitHub-Seite.

Um es kurz zu machen. Das andere Deep-Learning-Framework ist derzeit etwa zehnmal schneller als Tensorflow AMD OpenCL.

@AlphasCodes @znmeb Ich weiß, dass das TF-Team es vorzieht, den Thread nur für TF zu halten, wir freuen uns, die PlaidML-spezifische Konversation über das PlaidML-Projekt zu hosten. Wir hoffen jedoch, TensorFlow selbst sowie Nicht-OpenCL-Plattformen (z. B. Apples Metal für iOS, das derzeit als Prototyp existiert) letztendlich zu unterstützen.

https://github.com/plaidml/plaidml

@choongng Danke für die Informationen, ich habe meine Nachricht entsprechend bearbeitet.

@znmeb Die AMD A12-9800E iGPU sollte GCN v3 sein.

Der Haupt- und einzige Grund für mich, die Benchmarks/Tests durchzuführen, ist, eine Antwort auf meine Frage „Bleib bei AMD oder wechsle zu Nvidia für mein Deep-Learning-Abenteuer“ zu finden.

Und die Antwort ist. Ich mag den Open-Source-Ansatz von AMD sehr, aber ich werde wahrscheinlich aufgrund von 2 Faktoren zu Nvidia wechseln. Erstens ist der Deep-Learning-Software-Stack (z. B. Tensorflow) für Nvidia viel ausgereifter. Zweitens ist das Grafikkartenangebot für meine sehr speziellen Bedürfnisse (muss in ein Dan A4 SFX Gehäuse passen und unter Volllast über Stunden sehr sehr leise / nahezu geräuschlos sein) sehr begrenzt oder gar nicht vorhanden auf AMD-Seite.

Werden Intel-GPUs unterstützt? Ich denke, mein Iris Pro kann das ewige Training ein bisschen beschleunigen.

Diskutieren Sie den Mangel an Intel-GPU- (oder AMD-CPU-) Unterstützung hier codeplaysoftware/computecpp-sdk#78

https://github.com/codeplaysoftware/computecpp-sdk/issues/82

Ich versuche nur, ein Gefühl für den Stand dieses Problems zu bekommen. Habe ich Recht zu sagen, dass dieses Repo:

https://github.com/lukeiwanski/tensorflow

...mit ComputeCpp erstellt, ist die derzeit beste Option zum Erstellen von Tensorflow mit allgemeiner AMD-GPU-Unterstützung? Und wenn ja, gibt es Benchmark-Beweise dafür, dass dieser Build eine Beschleunigung gegenüber der CPU bietet?

Hängt davon ab, was Sie unter "allgemeiner AMD-GPU-Unterstützung" verstehen. Wenn Sie wirklich alte dGPU oder APUs meinen, weiß ich nicht. Aber wenn Sie ein neueres (GCN der 2. Generation oder neuer) haben, funktionierte hipTensorFlow (v1.0.1) auf ROCm ziemlich gut.

@briansp2020 Ah ja, ich habe AMDs Arbeit an ROCm gesehen. Leider unterstützen sie jedoch nur Linux, und es scheint nicht einmal so, als ob die Unterstützung für andere Betriebssysteme auf ihrer Roadmap steht. Ich hoffe auf etwas, das Windows unterstützt.

@mjmax Gibt es ein GPU-beschleunigtes Tensorflow-Paket für Windows? Ich dachte, wenn Sie GPU-beschleunigtes Deeplearning wollen, ist Linux die einzige Wahl. Wenn TensorFlow auf OpenCL portiert würde, würde das die Portierung auf Windows erleichtern? Ich bin mir nicht sicher, warum TensorFlow unter Windows mit GPU-Beschleunigung nicht verfügbar ist, wenn CUDA dort unterstützt wird.

Ich denke, das ist jetzt kein Thema mehr, aber wenn jemand TensorFlow und / oder PyTorch für Windows kennt, das GPU-beschleunigt ist, würde ich auch gerne davon wissen ...

@briansp2020 Soweit ich weiß, unterstützt Tensorflow bereits Nvidia-GPU-Beschleunigung unter Windows.

CL tensofrflow ist unter Linux bereits ein Chaos, erwarte nicht so schnell etwas.
Wenn Sie dort Sachen beschleunigen wollen, gibt es nur plaidML.
(und bitte, wir sind schon bei 500 Kommentaren.. versuchen wir, nur zu posten, wenn es wirklich, wirklich nötig ist)

@mirh OpenCL Caffe funktioniert unter Windows. Sicher, es ist nicht TensorFlow in Bezug auf die Funktionen, aber ziemlich solide für Software, die überall bereitgestellt werden muss.

Was ist mit dem Ersetzen des openCL-Ports durch den von AMD unterstützten HIP-Port?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

Haha! @LifeIsStrange Das Leben ist eigentlich sehr seltsam... Arbeitest du für das HiP-Marketingteam von AMD? :-)
Bitte schauen Sie sich das Thema dieser Ausgabe an: "OpenCL-Unterstützung".

Das heißt, es geht um den Khronos-Standard https://en.wikipedia.org/wiki/OpenCL (und der andere SYCL-Standard aus der OpenCL-Kronos-Arbeitsgruppe erscheint am Ende des Abschnitts „Überblick“).

Natürlich gibt es eine Welt außerhalb dieses Themas, aber sie ist... außerhalb ! :-)

Bitte versuchen Sie nicht, die Entropie des Universums rücksichtslos zu erhöhen, indem Sie einige zufällige Beiträge zu dieser ohnehin schon zu langen Diskussion posten ... :-)
Dieser Kommentar gilt übrigens für einige andere Poster hier, nicht nur für dich.
Dies ist ein GitHub-Problem, um ein technisches Problem zu lösen: TensorFlow auf Geräten laufen zu lassen, die den OpenCL-Standard unterstützen, keine FaceBook-Seite darüber, wie Leute Tool A oder B mögen oder nicht mögen. :-)
Aber zögern Sie nicht, einige Git-Commits zu diesem Problem zu senden, die wir uns ansehen können ...

Es gibt einen Fork von TensorFlow, der OpenCL unterstützt https://github.com/hughperkins/tf-coriander

Und natürlich die Arbeit von @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

IMHO ist es lächerlich, dass Mainstream TF ihre Arbeit immer noch nicht zusammengeführt hat.

Liegt der Fokus hier darauf, es so laufen zu lassen, wie es OpenCL ist, oder es tatsächlich schneller laufen zu lassen? Ich würde es vorziehen, dort keinen heiligen Krieg zu führen, sondern mich darauf zu konzentrieren, dass es auf mehreren GPUs schnell läuft. Der Fokus von LifeIsStrange liegt darauf, es auf AMD-GPUs zum Laufen zu bringen, und dann macht HIP Sinn. Für andere liegt der Fokus darauf, dass es auf Intel-GPUs oder Android funktioniert, und dann macht OpenCL viel mehr Sinn. GPU-Sprachen sind ein Chaos, also bleiben Sie bitte praktisch,

Wenn ich einige der Kommentare hier lese, ist die Leistung ein Problem mit den OpenCL-Portierungen. Aber leider kann ich nicht viele Benchmarks sehen. Gibt es noch mehr Benchmarks als diesen? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

So wie ich es verstehe, ist Benchmarking schwierig, wenn Sie CUDA mit OpenCL vergleichen, da Sie unterschiedliche Hardware verwenden müssen. Angeblich hat nVidia ihre OpenCL-Implementierung absichtlich etwas kaputt gemacht/zugelassen, sodass Benchmarks auf derselben Hardware immer dazu führen, dass CUDA großartig aussieht.

Am 12. Februar 2018 14:26:11 GMT+00:00 schrieb VincentSC [email protected] :

Liegt der Fokus hier darauf, es so zum Laufen zu bringen, wie es OpenCL ist, oder
damit es tatsächlich schneller läuft? Am liebsten wäre mir da kein heiliger Krieg, aber
Konzentrieren Sie sich darauf, es auf mehreren GPUs schnell laufen zu lassen. LifeIsStranges
Der Fokus liegt darauf, es auf AMD-GPUs zum Laufen zu bringen, und dann macht HIP es gut
Sinn. Für andere liegt der Fokus darauf, dass es auf Intel-GPUs funktioniert oder
Android und dann OpenCL macht viel mehr Sinn. GPU-Sprachen sind a
Chaos, also bleib bitte praktisch,

Wenn ich einige der Kommentare hier lese, ist die Leistung ein Problem mit der
OpenCL-Ports. Aber leider kann ich nicht viele Benchmarks sehen.
Gibt es noch mehr Benchmarks als diesen?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -364936498

--
Von meinem Android-Gerät mit K-9 Mail gesendet. Bitte entschuldigen Sie meine Kürze.

Der Vergleich von nur 2 Zahlen ist keine Information - wen interessiert es, ob OpenCL auf NVidia mit halber Geschwindigkeit läuft, wenn es auf anderen GPUs mit 4-facher Geschwindigkeit läuft?

Ich denke, wir bräuchten diese Benchmarks:

1. CUDA auf NV-GPUs (Referenz-Benchmarks)
2. https://github.com/hughperkins/tf-coriander auf AMD-, Nvidia- und Intel-GPUs
3. https://github.com/benoitsteiner/tensorflow-opencl auf AMD-, Nvidia- und Intel-GPUs
4. https://github.com/lukeiwanski/tensorflow auf AMD-, Nvidia- und Intel-GPUs

Die Referenzbenchmarks sind leicht zu finden. Wir haben hier einige High-End-GPUs, also brauchen wir nur einen Platz, um die Zahlen einzugeben (mit Links zu Gebäudedokumenten).

OpenCL-Unterstützung Es muss wahr werden.

cuda ist zu begrenzt und nvidia will es nicht teilen.
cuda funktioniert nur für Nv gpus.
das ist eine Sackgasse für TensorFlow,
wenn ein anderer "TensorFlow" rauskommt aber mehr Support als TensorFlow.
wenn TensorFlow immer noch nur cuda in Windows unterstützt.
Sie müssen TensorFlow nicht allein wählen.

Warum ist OpenCL besser als HIP? Ich denke, OpenCL hat es versäumt, Fuß zu fassen, und die Unterstützung von OpenCL zu diesem Zeitpunkt ist wahrscheinlich kontraproduktiv und eine Verschwendung von Ressourcen für die gesamte Community/Industrie. Ich würde lieber sehen, dass TensorFlow HIP direkt unterstützt und den Compiler/das Tool/die Bibliothek sich um die Portabilität kümmern lässt.

Ist es nicht besser für Software, 1 Sprache/Programmiermodell zu unterstützen?

Software muss unterstützen, was sie unterstützen muss, um jeden Anwendungsfall abzudecken.
HIP ist aller Schnickschnack (zumindest auf dem Papier), wenn Sie unterstützte Hardware haben. Aber es gibt nicht nur "neuere AMD- und NVIDIA-Karten" auf dieser Welt.

Jetzt bitte, um Himmels willen, beschweren Sie sich hier über jedes Problem damit.
Und hier für alle anderen Interessierten an der Fortsetzung dieser Ausgabe.

Ich dachte, dass SPIR-V CUDA als Hardware-übergreifende Alternative direkt ersetzen würde:
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

Warum setzt Google immer noch auf CUDA?

Können diese helfen?

Generierung von OpenCL-Zufallszahlen (von 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 SHA3-Hashing (vergessen, wer das geschrieben hat)

https://gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Bitte entfernen Sie den Beauftragten, da diese Ausgabe zu externen Beiträgen einlädt. Entfernen Sie andernfalls das Label contributions welcome . Danke.

Bitte entfernen Sie den Beauftragten, da diese Ausgabe zu externen Beiträgen einlädt. Entfernen Sie andernfalls das Label contributions welcome . Danke.

Es liegt im Interesse von Google, OpenCL zu unterstützen,
Indem Sie die spezifische Hardware einer bestimmten (Firma/Marke/Anbieter) als Abhängigkeit für Ihre Software haben, zwingen Sie sich dazu, mehr für Hardware zu bezahlen, der Marktwettbewerb senkt die Kosten.
Google hat sich von Anfang an immer um Commodity-Hardware gekümmert, was für den Erfolg von Google (Marktbeherrschung) entscheidend war und immer noch ist. Niedrigere Betriebskosten für Rechenzentren ermöglichten die revolutionär großzügigen, im Wesentlichen kostenlosen Dienstangebote wie Gmail (Speicherplatz) und Google Fotos (Speicherplatz). Leerzeichen und Auto-Tagging).

@wesamco Nein, es ist nicht unbedingt im Interesse von Google. Sie stellen ihre eigene Hardware her – ein sogenanntes „TensorBoard“, IIRC. Sie können OpenCL und CUDA / CUDnn umgehen und das Board dazu bringen, rohen TensorFlow-Code auszuführen.

roher TensorFlow-Code.

So etwas gibt es nicht – es ist nicht wie unverarbeitetes Essen. TPUs benötigen eine eigene DNN-Bibliothek, die die verschiedenen Arten von Anrufen verarbeitet.

Es scheint an der Zeit zu sein, die obige Diskussion wieder in einer Liste zusammenzufassen:

• CodePlay arbeitet an einem SYCL-Backend
• Hugh Perkins arbeitet an tf-Koriander
• AMD arbeitet an einem HIP-Backend
• PlaidML unterstützt derzeit nur CPUs.
• Der Status der Unterstützung für Intel-GPUs ist unklar.

Wählen Sie also ein Projekt, das Ihnen gefällt, und fangen Sie an, es zu unterstützen. Vielleicht kann jede der Gruppen ein Status-Update zu ihrem Projekt geben?

Verstehen Sie, dass OpenCL von einer vollständigen Sprache in eine Sprachdefinition/Hardwarespezifikation umgewandelt wurde, die in SPIRV (Kernel) dargestellt wird, die dann auf einer Plattform wie OpenCL-Treibern und später auch auf Vulkan-Treibern ausgeführt werden kann (Plattformen). Indem Sie also SYCL unterstützen, unterstützen Sie auch OpenCL.

Perfekte Zusammenfassung, aber plaidml läuft auch auf gpus.
Es ist nur so, dass sie im Moment ein Backend für Keras sind, nicht für Tensorflow. Es ist also irgendwie OT da.

Hallo alle,
@VincentSC danke für die großartige Zusammenfassung der verschiedenen Bemühungen!

Wählen Sie also ein Projekt, das Ihnen gefällt, und fangen Sie an, es zu unterstützen. Vielleicht kann jede der Gruppen ein Status-Update zu ihrem Projekt geben?

Der SYCL-Ansatz unterstützt jetzt eine Vielzahl von Plattformen/Geräten. Die, die ich nennen kann, sind:

• Anleitungen für AMD GPUs (FirePro W8100, R9 Nano und R9 380 Series) finden Sie hier oder hier
• ARM Mali (HiKey 960) Anleitung hier verfügbar
• Intel-GPU (SkyLake-Serie) mit Intel NEO OpenCL-Treiber

Bei AMD verwenden die oben genannten GPUs derzeit die AMDGPU-Pro-Treiber 17.40-xxx mit aktiviertem Legacy-OpenCL.
Ich sehe keinen offensichtlichen Grund, warum andere Serien nicht funktionieren würden (unter der Annahme, dass SPIR / SPIR-V unterstützt wird)

Die Hauptplattform, auf die wir uns konzentrieren, ist Linux – wir bemühen uns jedoch ständig, Windows in Zukunft zu ermöglichen. Wir haben keine Pläne, OSX in naher Zukunft zu unterstützen. Ich kenne trauriges Gesicht.

Unser Fokus liegt auf der Verbesserung der Leistung von CNNs. Die aktuelle Leistung ist nicht optimiert und bei weitem nicht dort, wo wir sie sehen. Allerdings schlagen wir bereits die CPU-Leistung für die meisten Modelle auf verschiedenen Zielen.

Um den Entwicklungszyklus zu beschleunigen und die Gesamtkompilierungszeit von TensorFlow zu verkürzen (sowie die Portabilität zu verbessern), arbeiten wir an Eigen-, BLAS- und DNN-Bibliotheken.
Diese Bibliotheken zielen darauf ab, das Leistungsproblem zu lösen und ein Ökosystem portabler Bibliotheken aufzubauen, die sich problemlos in komplexe Projekte wie TensorFlow integrieren lassen.

Unten sehen Sie Diagramme für die Leistung, die wir derzeit teilen können. Sie stammen von meinem Fork https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu unter 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
Der verwendete Benchmark ist https://github.com/tensorflow/benchmarks

Das Diagramm ist auf die Ergebnisse von Intel i7-4790K normalisiert.

Wir laden Änderungen an Eigen langsam hoch, sobald dies geschieht, werden wir mit TensorFlow folgen.

Ich hoffe, das hilft,
Lukas

Für Deep-Learning-Inferenz auf Mobilgeräten mit GPU/OpenCL-Unterstützung können Sie MACE ausprobieren , das für Adreno-, Mali- und PowerVR-GPUs optimiert ist. Hier sind einige Benchmark-Ergebnisse .

@keryell @benoitsteiner , welche Version von Tensorflow und Trisycl für die Integration erforderlich sind. Ich habe Probleme beim Erstellen von Tensorflow (1.9) mit der neuesten Trisycl-Version.

Leider verwendet der neueste TensorFlow fortschrittlichere Funktionen, als das aktuelle triSYCL bewältigen kann, sodass Sie ComputeCpp verwenden müssen, derzeit die einzige vollständig konforme SYCL-Implementierung ...

Tensorflow wird von Google Brain unterstützt, und Google hat eine Partnerschaft mit nVidia, ich denke, wir werden von Tensorflow nicht erwarten, OpenCL zu unterstützen
Große Anstrengungen der OpenCL-Community sind erforderlich

OpenCL-Unterstützung bitte!

OpenCL ist auch für uns besser geeignet.

@Makhaon Ich auch. Ich kann es mir nicht leisten, eine Maschine mit NVIDIA-Grafikkarte zu kaufen.

Neben den beiden obigen Beiträgen möchte ich hinzufügen, dass AMDs Vega-GPUs (einschließlich derer in Raven-Ridge-APUs) jetzt FP16 mit doppelter FLOPS ausführen können. Wenn TF sie also (über OpenCL) unterstützen könnte, würde es den Leuten wirklich helfen weniger Budget. Viele dieser Leute wären auch Studenten, und wenn wir sie dazu bringen würden, TF als Ausgangspunkt ihrer DNN-Reise zu verwenden, würden sie später wahrscheinlich bei TF bleiben und sogar anderen von TF erzählen; Es ist eine großartige Möglichkeit, dieses Projekt zu erweitern.

Ich denke, dieser Thread ist für Entwickler größtenteils bedeutungslos (zu viel Lärm - und ich werde noch mehr hinzufügen ;-), aber ich denke, viele Kommentare verfehlen das Wesentliche:
Wenn Sie Tensorflow mit AMD-Karten ausführen möchten, ist OpenCL NICHT das, wonach Sie suchen – gehen Sie bitte zu https://github.com/ROCmSoftwarePlatform/ und installieren Sie den ROCm-Stack. AFAIK Die aktuelle Strategie von AMD basiert auf ROCm anstelle von OpenCL für Tensorflow/pytorch .

Generisches OpenCL war zu wartungsintensiv/lieferte nicht genügend Leistungsvorteile, um sich für AMD zu lohnen. Daher ist dieses Ticket nur interessant, wenn Sie (zB) eine ARM-Plattform betreiben, die nur OpenCL verwendet.

(Haftungsausschluss: nur ein Außenseiter, kein wirklicher Einblick in die Tensorflow-Entwicklung, daher sind die obigen Informationen möglicherweise völlig falsch und irreführend. Fühlen Sie sich frei, mich zu verprügeln, wenn Sie es besser wissen.)

Nur ein Gedanke, was ist mit llvm mit dem neuen GPU-Offload? Das würde ein hohes Maß an Abstraktion zwischen Tensorflow und cuda-spezifischem Code bedeuten.

Was ist, wenn Sie alle nur 10 Posts oben lesen und feststellen, dass es bereits einen Fork von lukeiwanski/codeplaysoftware gibt, den Sie ausprobieren können?
(Auch Hut ab vor Xiaomi, weil ich einmal eine ernsthafte Art von Open-Source-Bemühungen beigesteuert habe)

@FelixSchwarz Nur damit Sie wissen, dass ROCm OpenCL verwendet, es ist AMDs Userspace OpenCL-Treiber unter Linux (deshalb unterstützt es Windows nicht). Wenn Sie also nicht wissen, wie AMDs Treiber-Ökosystem unter Linux funktioniert, haben sie es ihre Kernel-seitigen Treiber AMDGPU und AMDKFD (die jetzt in AMDGPU zusammengeführt werden), dann gibt es die Userspace-Treiber RadeonSI (für OpenGL), RadV/AMDVLK (für Vulkan) und ROCm (für OpenCL).

Gemessen an der Dynamik dieses Fehlers und anderer Gabeln hat Google kein Interesse daran und wird dies niemals im offiziellen Repository implementieren. Ich würde dafür stimmen, dieses Thema überhaupt zu schließen (oder zu sperren), um keine falschen Hoffnungen für alle zu wecken.

Das Problem sollte hier sein, um zumindest alle Leute darauf hinzuweisen, die es wollen
zwangsläufig wieder öffnen.

Am Sa, 15.09.2018, 09:45 schrieb Anton Kochkov [email protected] :

Gemessen an der Dynamik dieses Fehlers und anderer Gabeln hat Google null
Interesse daran und werde dies niemals in den Beamten umsetzen
Repository. Ich würde dafür stimmen, dieses Thema überhaupt zu schließen (oder zu sperren).
keine falschen Hoffnungen für alle wecken.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Es gibt einen TensorRT, der Movidius Pi Hat unterstützt. Und dieser Movidius Pi Hat ist Googles $45 „AIY Vision Kit“. Google verlinkt auf Target, um es zu kaufen.

Das hat keine Verbindungen zu CUDA oder Nvidia? Sagt, es verwendet einen Intel-Chip. Vielleicht ist der Chip im Kern ein FPGA? Weiß jemand mehr darüber?

Ich weiß ziemlich viel über die große Movidius-Einheit - es ist nur Inferenz und es führt entweder TensorFlow- oder Caffe-vorkompilierte Modelle aus. IIRC sind alle im 16-Bit-Modus.

Der Movidius-Chip selbst ist viel leistungsfähiger, aber Sie müssen ein qualifizierter Partner sein, um das SDK zu erhalten.

Haben Sie einen Link für andere, die versuchen, Tensor Opencl zu haben:

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 (Repository ist veraltet)
https://github.com/codeplaysoftware/tensorflow
Vielleicht lohnt es sich auch zu überprüfen:

https://documen.tician.de/pyopencl/
https://pypi.org/project/DeepCL/
https://www.khronos.org/sycl/

Fühlen Sie sich frei, Arbeitsprojekte hinzuzufügen.

Gibt es ein Update? Dieses Problem ist über 3 Jahre alt.

Ja, es gibt nur einen Blick auf die letzte Handvoll Beiträge.

@ filips123 nein, es gibt keine Updates und wird es in absehbarer Zeit auch nie geben - die Wahrscheinlichkeit dafür ist geringer als für eine Alien-Invasion und das Finden eines Weges, in die Vergangenheit zu reisen.

Diese Intel-Initiative PlaidML funktioniert recht gut, es lohnt sich, sie auszuprobieren.
https://github.com/plaidml/plaidml
Es läuft auf Opencl ODER Metal auf Mac. Es funktioniert mit Macbook Pro AMD gpus, wonach ich gesucht habe.
Könntet ihr in der Zwischenzeit helfen, für die Unterstützung von Pytorch in PlaidML zu stimmen? https://github.com/plaidml/plaidml/issues/63

PlaidML ist sicherlich alles nett und gut (ich könnte irgendwie mehr Leistung auf einer NVIDIA-GPU auf Opencl erzielen als mit cuda von tf selbst).
Aber es ist ein Backend für Keras? Als vollständiger Ersatz für Tensorflow, von dem Sie wissen, dass es das Repo ist, in dem wir darüber diskutieren?
(Soweit ich zu verstehen scheine, können die neuesten tf-Versionen Modelle direkt nach Keras exportieren? also gibt es das ...)

Wie auch immer, zum vierten verdammten Mal, wenn Sie eine aktuelle Lösung für opencl und etwas wollen, das noch aktiv entwickelt wird ( und auch die Sache mit den tatsächlichen Chancen, hier eines Tages wirklich zusammengeführt zu werden), gibt es nur Codeplay-Stack.
Aufs Neue:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

PlaidML ist sicherlich alles nett und gut (ich könnte irgendwie mehr Leistung auf einer NVIDIA-GPU auf Opencl erzielen als mit cuda von tf selbst).
Aber es ist ein Backend für Keras? Als vollständiger Ersatz für Tensorflow, von dem Sie wissen, dass es das Repo ist, in dem wir darüber diskutieren?
(Soweit ich zu verstehen scheine, können die neuesten tf-Versionen Modelle direkt nach Keras exportieren? also gibt es das ...)

Wie auch immer, zum vierten verdammten Mal, wenn Sie eine aktuelle Lösung für opencl und etwas wollen, das noch aktiv entwickelt wird (_und auch_ das Ding mit den tatsächlichen Chancen, hier eines Tages wirklich zusammengeführt zu werden), gibt es nur Codeplay-Stack.
Aufs Neue:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

Entschuldigung, ich hatte nicht bemerkt, dass es keine Tensorflow-Unterstützung gibt. Mein annehmendes Gehirn dachte, dass Keras-GPU-Unterstützung == Tensorflow-Unterstützung.

plaidML ist supercool. Funktioniert auf Keras.
Natürlich musste ich etwas tf-Code in reines Keras übertragen, um am plaidML-Backend zu arbeiten (z. B. tf.image.ssim).
Aber Ergebnis - mein Code funktioniert auf NVIDIA- und AMD-Karten.

Auch plaidML ist ein Paradies für Forscher. Es generiert automatisch Gradienten für jede Funktion, die Sie in der „Tile“-Sprache schreiben, und es funktioniert auf Ihrer GPU mit 80 % Tensorflow-Geschwindigkeit.

Ich kann also nicht verstehen, warum ML-Forscher immer noch PyTorch verwenden? Lassen Sie uns die ML-Wissenschaft mit Intels plaidML ankurbeln?

@iperov Möchten Sie wissen, warum praktisch niemand PlaidML verwendet?

1. Es läuft erbärmlich langsam auf AMDs OpenCL-Implementierungen im Vergleich zu Tensorflows CUDA-Backend, also gibt es mindestens den halben Grund, es zu verwenden. Die Leistung ist so schlecht, dass die Verwendung von Tensorflow mit CPUs konkurrenzfähig ist oder sogar ihre Hardware mit PlaidML übertrifft?

2. Niemand ist daran interessiert, seine spezialisierte Tile-Programmiersprache beizubehalten, in der nur jemand wie ein reiner Mathematikprofessor basteln würde, sodass die Codequalität von PlaidML einfach den Bach runtergeht und kein ernsthafter Programmierer bei klarem Verstand sich mit allzu cleverem Code befassen möchte ...

3. Das hängt ziemlich mit #2 zusammen, aber seit Intel Vertex.AI aufgekauft hat, kümmern sie sich nicht mehr um PlaidML. Intels Lösung für GPU-Computing-beschleunigtes maschinelles Lernen führt einen neuen Compiler speziell für Deep Learning ein, der jetzt als nGraph bekannt ist und auf Tensorflow, PyTorch oder andere Deep-Learning-Frameworks als Backend für sie abzielt. Kein Grund mehr, PlaidML als Vermittler weiterzuentwickeln, wenn sie nGraph haben ...

Die Leute verwenden PyTorch aus anderen Gründen wie der Wartbarkeit oder anderen Funktionen. Zusammenfassend lässt sich sagen, dass PlaidML Intels Tool ist, und sie beabsichtigen wahrscheinlich nicht, dass es in den letzten Teilen ihrer Pläne eine Rolle spielt. Das aktuelle Intel-GPU-Backend von nGraph basiert auf OpenCL 2.1, von dem nur Intel eine konforme Implementierung hat, sodass Intel nur für sich selbst und nicht nur für die Verbesserung des maschinellen Lernens da ist. Wenn Intel mit der Weiterentwicklung von nGraph fortfährt, kann ich nicht sehen, dass sie ihr GPU-Backend weiterhin allein auf OpenCL 2.1 stützen, da viele Deep-Learning-Frameworks Kernel mit Vorlagen haben, die nicht mit OpenCL, Metal oder den separaten Quellprogrammiermodellen von Vulkan kompatibel sind, also ist es wahrscheinlich nur zu Versuchszwecken. Intels endgültiges GPU-Backend wird wahrscheinlich entweder auf SYCL 2.2 oder etwas ganz anderem wie OpenMP basieren, und vielleicht bringen sie sogar eine herstellerspezifische Lösung ...

Was AMD betrifft, wen interessiert das? OpenCL ist für sie irrelevant und sie zeigen endlich einige Ergebnisse mit ihrer Arbeit an HIP ...

@iperov Möchten Sie wissen, warum praktisch niemand PlaidML verwendet?

1. Es läuft erbärmlich langsam auf AMDs OpenCL-Implementierungen im Vergleich zu Tensorflows CUDA-Backend, also gibt es mindestens den halben Grund, es zu verwenden. Die Leistung ist so schlecht, dass die Verwendung von Tensorflow mit CPUs konkurrenzfähig ist oder sogar ihre Hardware mit PlaidML übertrifft?
2. Niemand ist daran interessiert, seine spezialisierte Tile-Programmiersprache beizubehalten, in der nur jemand wie ein reiner Mathematikprofessor basteln würde, sodass die Codequalität von PlaidML einfach den Bach runtergeht und kein ernsthafter Programmierer bei klarem Verstand sich mit allzu cleverem Code befassen möchte ...
3. Das hängt ziemlich mit #2 zusammen, aber seit Intel Vertex.AI aufgekauft hat, kümmern sie sich nicht mehr um PlaidML. Intels Lösung für GPU-Computing-beschleunigtes maschinelles Lernen führt einen neuen Compiler speziell für Deep Learning ein, der jetzt als nGraph bekannt ist und auf Tensorflow, PyTorch oder andere Deep-Learning-Frameworks als Backend für sie abzielt. Kein Grund mehr, PlaidML als Vermittler weiterzuentwickeln, wenn sie nGraph haben ...

Die Leute verwenden PyTorch aus anderen Gründen wie der Wartbarkeit oder anderen Funktionen. Zusammenfassend lässt sich sagen, dass PlaidML Intels Tool ist, und sie beabsichtigen wahrscheinlich nicht, dass es in den letzten Teilen ihrer Pläne eine Rolle spielt. Das aktuelle Intel-GPU-Backend von nGraph basiert auf OpenCL 2.1, von dem nur Intel eine konforme Implementierung hat, sodass Intel nur für sich selbst und nicht nur für die Verbesserung des maschinellen Lernens da ist. Wenn Intel mit der Weiterentwicklung von nGraph fortfährt, kann ich nicht sehen, dass sie ihr GPU-Backend weiterhin allein auf OpenCL 2.1 stützen, da viele Deep-Learning-Frameworks Kernel mit Vorlagen haben, die nicht mit OpenCL, Metal oder den separaten Quellprogrammiermodellen von Vulkan kompatibel sind, also ist es wahrscheinlich nur zu Versuchszwecken. Intels endgültiges GPU-Backend wird wahrscheinlich entweder auf SYCL 2.2 oder etwas ganz anderem wie OpenMP basieren, und vielleicht bringen sie sogar eine herstellerspezifische Lösung ...

Was AMD betrifft, wen interessiert das? OpenCL ist für sie irrelevant und sie zeigen endlich einige Ergebnisse mit ihrer Arbeit an HIP ...

Was ist mit allen GPU-In-Arm-Maschinen wie Mobiltelefonen und Himbeer-Pi-Odroid usw.?
Sie unterstützen kein opencl?
Google sollte sich darum kümmern, Tensorflow auf GPU auf Android einzufügen.
Die größten Bibliotheken für neuronales Netzwerktraining laufen nur auf Nvidia-GPUs, sie machen Nvidia-GPUs nur immer teurer (weil sie von Menschen und Unternehmen nur für professionelles neuronales Netzwerktraining gekauft werden), dann verliert Google auf diese Weise mehr Geld.

@Degerz von welchem ​​Planeten kommst du?
Wie können Sie tf-CPU und AMD GPU vergleichen?
AMD GPU auf plaidML x30 schneller als tf-CPU

1. Es läuft erbärmlich langsam auf AMDs OpenCL-Implementierungen im Vergleich zu Tensorflows CUDA-Backend, also gibt es mindestens den halben Grund, es zu verwenden

In meinen Deepfakes-Tests ist OpenCL nur um 20 % langsamer, aber in einigen Mini-Netzwerken ist OpenCL 20 % SCHNELLER.

Mein Projekt DeepFaceLab hat viele Nutzer, die auf die Unterstützung von AMD gewartet haben. Wie viele Menschen haben sich gefreut, als Deepfakes endlich auf AMD-Karten trainiert werden können.
Außerdem ist plaidML das einzige Backend für Keras, das AMD/IntelHD standardmäßig unterstützt.
Wenn ein neues AMD-Backend für Keras erscheint, wird mein Projekt natürlich darauf umstellen.
PyTorch hat keine Zukunft.

Was ist in plaidML zu pflegen? Ops sind automatisch differenzierbar, es gibt nichts zu warten.

Eine Programmiersprache, die nur jemand wie ein reiner Mathematikprofessor aushecken würde

Maschinelles Lernen wurde von Mathematikprofessoren erfunden, nicht wahr?

@talregev Was ist mit ARM oder Broadcom? Ersteres hat wahrscheinlich eine unterdurchschnittliche OpenCL-Implementierung und letzteres bietet nicht einmal offiziell OpenCL-Treiber! Es liegt nicht in der Verantwortung von Google, einen kompetenten Compute-Stack für Hardwareanbieter zu erstellen und zu warten ...

@iperov Sie wissen, dass das Trainieren neuronaler Netze mit Einbettungsschichten in PlaidML schmerzhaft ist, oder? PlaidML hat auch eine Reihe anderer Einschränkungen, wie z. B. dass es nicht so gut für DenseNets geeignet ist oder die Tatsache, dass seine Berechnungsgraphen statisch sind und PlaidML sogar gut mit RNNs funktioniert?

Machen Sie sich bezüglich Ihres Projekts keine Sorgen. Sie werden zu etwas Besserem wie Tensorflow übergehen, da AMD bald ein natives GPU-Backend dafür anbieten wird, sobald MIOpen hochgeladen wird, das ihre GPU-beschleunigte Bibliothek von Grundelementen für tiefe neuronale Netze ist, ähnlich der cuDNN-Bibliothek ihres Konkurrenten, die beide PlaidML enthalten werden der Staub in Bezug auf die Leistung. Wer kümmert sich überhaupt um Intel iGPUs? Wenn Intel wirklich bestrebt ist, hochleistungsfähiges Deep Learning auf seiner zukünftigen diskreten Grafikhardware bereitzustellen, werden sie eine Single-Source-Option anbieten, genau wie die anderen (AMD/HIP und Nvidia/CUDA) vor ihnen ...

PyTorch hat keine Zukunft.

Neid viel? PyTorch ist etwa 10-mal beliebter als PlaidML, die neuesten Techniken in DL lassen sich problemlos auf PyTorch implementieren, es gibt unzählige verschiedene Mitwirkende und wird von Facebook aktiv weiterentwickelt, während Intel seit fast einem Monat nichts mehr zu PlaidML beigetragen hat.

Was ist in plaidML zu pflegen? Ops sind automatisch differenzierbar, es gibt nichts zu warten.

Ich nehme also an, dass PlaidML in Zukunft keine neuen Fixes oder neuen Funktionen erhalten sollte? Wenn Sie den Wert in der Verbesserung des Codes nicht sehen, hat es keinen Sinn, Sie davon zu überzeugen, die offensichtlichen Mängel von PlaidML anzuerkennen ...

Maschinelles Lernen wurde von Mathematikprofessoren erfunden, nicht wahr?

Das bedeutet nicht, dass wir die Programmiersprache übernehmen müssen, die sie ausmachen, insbesondere im Fall von Tile, wo Eleganz eindeutig der Lesbarkeit vorgezogen wird. Kein Wunder, dass so viele potenzielle Mitwirkende davor zurückschrecken, einen Beitrag zu leisten ...

Jesus, ich wünsche euch STFU und geht stattdessen zurück an die Arbeit. Ich muss das Ticket abbestellen, weil es unerträglich ist, E-Mails mit Flame Wars zu bekommen. Schade, dass die Betreuer den Thread nicht stumm schalten.

@gunan @caisq @sanjoy Könntest du bitte etwas dagegen tun?