Странно, что Google отказался от открытого OpenCL в пользу проприетарной CUDA.

По крайней мере, библиотека Eigen должна поддерживать OpenCL.

:+1:

:+1:

:+1:

палец вверх и все такое.

Я буду заинтересован в расширении Tensor Flow с помощью OpenCL. Так как мы уже выпустили OpenCL caffe. https://github.com/amd/OpenCL-кафе. Надеюсь, его можно будет интегрировать легким способом? Кто-нибудь заинтересован в совместной работе над этим?

@gujunli Приятно видеть здесь AMD. /cc @naibaf7 @lunochod

было бы замечательно.

:+1:

/cc @lukeiwanski для Eigen/OpenCL/SYCL

@gujunli Конечно, было бы интересно внести свой вклад. Пожалуйста, дайте мне знать, когда вы планируете начать.

Всем привет,

Здесь, в Codeplay, мы изучаем тензор Эйгена, работающий на графическом процессоре с использованием SYCL (современный уровень C++ поверх OpenCL). Из того, что мы собрали до сих пор, дизайн тензора графического процессора очень тесно связан с CUDA, и для него потребуются изменения интерфейса для другой модели программирования и, в частности, версии SYCL и OpenCL 1.2.

Если кто-то заинтересован в том, чтобы копнуть глубже / помочь, мы, безусловно, заинтересованы в том, чтобы внести свой вклад.

Спасибо,
Люк

@lukeiwanski Спасибо за отзыв. Я думаю, что @benoitsteiner работал над расширением тензора в eigen.

:+1: Я могу помочь кодировать OpenCL/SYCL, если кто-то составляет план, делит работу на задачи и т. д. Я рекомендую использовать Boost.Compute в качестве оболочки для OpenCL (это упрощает запуск ядер, тестирование, создание шаблонов).

+1

:+1:

Всем привет,

Просто чтобы держать вас в курсе, мы все еще изучаем, как мы можем изменить интерфейс Eigen, чтобы он лучше соответствовал модели программирования SYCL/OpenCL 1.2.
Как только мы придумаем разумный подход, нацеленный на гетерогенные модели программирования (не только OpenCL/SYCL), мы создадим предложение.

Спасибо,
Люк

Пожалуйста, держите меня в курсе. Я разработал opencl-caffe для AMD. я тоже смотрю
тензорное течение.

Спасибо.
Джунлу
8 декабря 2015 г., 10:19, «Люк Ивански» [email protected] написал:

Всем привет,

Просто чтобы держать вас в курсе, мы все еще изучаем, как мы можем изменить
Собственный интерфейс для лучшего соответствия модели программирования SYCL/OpenCL 1.2.
Как только мы придумаем разумный подход, мы создадим предложение.

Спасибо,
Люк

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-162967662
.

/cc @ptillet @gongzg Интересует ли это Intel? Я действительно надеюсь, что мы не будем фрагментировать OPENCL здесь, как в Caffe, где у нас есть форк AMD, необъединенные PR Intel, еще один полунеофициальный PR AMD и длинный промежуточный PR пользователя (плюс две старые заброшенные попытки Opencl). Если кого-то интересует история, можете посмотреть комментарии https://github.com/BVLC/caffe/pull/2610 .

@bhack У нас есть к этому интерес. Спасибо, что дал мне знать. Если будет предложение по реализации Eigen OpenCL/SYCL, мы посмотрим, что мы можем сделать со стороны Intel.

:+1:

Интересная инициатива на https://github.com/ptillet/isaac , также если здесь мы полагаемся на расширение тензора Eigen.

Я также хотел бы внести свой вклад. @benoitsteiner , ты можешь это организовать?

Это было включено в дорожную карту, но также помечено как вклад, поэтому направление/бутстрап может быть действительно полезным.

Я могу внести свой вклад в его организацию. кто отвечает за поддержку OpenCL в
Тензорный поток сейчас?

Большое спасибо.
Джунли

Во вторник, 19 января 2016 г., в 7:50, [email protected] написал:

Это было включено в дорожную карту, но также помечено как вклад, поэтому
direction/bootstrap может быть действительно полезным.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172894538
.

---

Цзюньли Гу -- 谷俊丽
Скоординированная научная лаборатория
Университет Иллинойса в Урбана-Шампейн

---

Я просто предположил Бенуа, потому что он сам назначил эту функцию, но я думаю, что у вас есть Джунли! Может быть, начать с электронной почты или ветки форума заинтересованных сторон?

@benoitsteiner знает больше о заинтересованных сторонах, которые, возможно, не показали
в этой теме (или в этом выпуске). Я бы подождал, пока он скоординирует, чтобы сделать
уверены, что мы избегаем дублирования работы.

Во вторник, 19 января 2016 г., в 11:42 Дэн Маклафлин, [email protected]
написал:

Я просто предположил Бенуа, потому что он сам назначил эту функцию, но я думаю
у тебя получилось, Джунли! Может быть, начать с электронной почты или ветки форума
заинтересованные стороны?

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172963537
.

Мне это интересно. Есть ли дорожная карта?

19 января 2016 г., в 11:46, Мартин Вике, [email protected] , написал:

@benoitsteiner знает больше о заинтересованных сторонах, которые, возможно, не показали
в этой теме (или в этом выпуске). Я бы подождал, пока он скоординирует, чтобы сделать
уверены, что мы избегаем дублирования работы.

Во вторник, 19 января 2016 г., в 11:42 Дэн Маклафлин, [email protected]
написал:

Я просто предположил Бенуа, потому что он сам назначил эту функцию, но я думаю
у тебя получилось, Джунли! Может быть, начать с электронной почты или ветки форума
заинтересованные стороны?

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172963537
.

—
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Есть ли список библиотек зависимостей CUDA, на которые опирается Tensorflow?

Это помогло бы увидеть, есть ли у нас немедленные альтернативы OpenCL.

@hsaputra
Есть clFFT, clBLAS (альтернативно ViennaCL). Генератор случайных чисел немного сложнее (без curand), либо используйте генератор ЦП и перенесите его на графический процессор, либо используйте другое существующее ядро ​​​​для ГСЧ.

Самой большой ловушкой снова будут эффективные реализации свертки (что-то вроде cuDNN).

Здесь есть опыт по таким вопросам:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-кафе

Tensorflow использует расширение тензора вверх по течению до Eigen. Поэтому я думаю, что необходима поддержка Opencl/Sycl для Eigen. См. эту тему

Спасибо @naibaf7. Да, я не думаю, что сейчас есть жизнеспособная альтернатива cuDNN для OpenCL.

Веб-сайт http://opencl.org создан для поддержки подобных проектов с открытым исходным кодом! В настоящее время мы устанавливаем все необходимые инструменты на веб-сайте и имеем место для репозиториев на https://github.com/OpenCL/ — позже мы добавим серверы сборки для тестирования нескольких типов оборудования и можем предоставить наш опыт в как написать код, который работает на полной скорости на множестве аппаратных средств.

На следующей неделе мы запускаем инициативу по переносу GEGL, но мы также рады поддержать вас.

@bhack из той ветки, и здесь, кажется, @lukeiwanski изучает это. Я думаю, у нас достаточно желающих поработать над этим, нам просто нужны @benoitsteiner , @lukeiwanski или @gujunli для координации. Бенуа молчит, может быть, он в отпуске.

Я хотел бы помочь внести свой вклад в эту инициативу.

всем привет,

мы будем координировать усилия по переносу тензорного модуля Eigen на SYCL для OpenCL, поскольку у нас уже есть что-то в основном работающее, но оно еще не готово для обзора.

Мы поддерживаем этот подход, так как он будет меньше вторгаться в кодовую базу. SYCL поддерживает шаблонную модель C++ с одним исходным кодом, которую уже использует eigen.

Разработка дорожной карты находится в стадии разработки, так что это не должно быть слишком долго.

Спасибо,
Люк

@lukeiwanski Вы работаете или поддерживаете связь с апстримом? Как вы думаете, будут ли приняты вверх по течению в Эйгене?

+1

Отличные новости @lukeiwanski , дайте нам знать о любой помощи, которая вам нужна.

Я предполагаю, что вы используете собственную реализацию SYCL — будет ли она доступна для разработчиков/исследователей? На каких платформах?

@lukeiwanski SYCL кажется правильным путем, учитывая количество метапрограммирования шаблонов, связанное с Eigen. Я опытный разработчик на С++ с опытом работы с OpenCL, полученным при разработке собственных нейронных сетей и библиотеки линейной алгебры . Я хотел бы помочь с этим усилием и начать разработку с SYCL.

@bhack Мы находимся в контакте с @benoitsteiner , но мы обсудим наше предложение с вышестоящими сопровождающими, прежде чем прикладывать слишком много усилий.

@DanMcLaughlin , @ville-k Мы разрабатываем нашу реализацию SYCL, ComputeCpp (https://www.codeplay.com/products/computecpp). Для получения дополнительной информации, не могли бы вы связаться со мной вне списка по адресу электронной почты, указанному в моем профиле?

@lukeiwanski есть какие-либо обновления/оценки относительно планов?

+1.
У меня есть графический процессор AMD и графический процессор Intel в ноутбуке. Я думаю, что у обоих есть драйверы OpenCL, и поддержка AMD кажется намного лучше. У меня была бы более высокая производительность, потому что у меня есть 2 устройства OpenCL. Я надеюсь, что вы сделаете это масштабируемым с устройствами OpenCL.

Всем привет,

Спасибо за интерес!
На данный момент мы настраиваем нашу инфраструктуру тестирования, чтобы убедиться, что ничто из того, что мы делаем, не приводит к регрессии.
Мы связались с @benoitsteiner , чтобы убедиться, что мы в курсе того, что он сделал до сих пор.

Мы все еще составляем дорожную карту для процесса интеграции - это должно быть сделано через пару недель, так как есть пара бизнес-деталей, которые нужно уточнить.

Наша цель — внедрить OpenCL в TensorFlow через Eigen к концу этого года.

Спасибо,

интересно. хотел бы внести свой вклад.

Итак, на самом деле кажется, что это попытка Codeplay с некоторой внутренней синхронизацией с Google. Какова здесь роль подписчиков AMD и Intel?

/cc @keryell , если вас это интересует из вселенной SYCL/FPGA

Приношу свои извинения за то, что в последнее время не участвовал в этом обсуждении, моя тарелка была более чем полна за последние 2 недели.

Я буду координировать усилия OpenCL на стороне TensorFlow. Наше текущее мышление таково:

• TensorFlow опирается на С++ 11 и использует подход «из одного источника», поэтому SYCL кажется отличным вариантом.
• У нас нет большого опыта работы с OpenCL, поэтому мы тесно сотрудничаем с Codeplay, чтобы восполнить этот пробел. В частности, Codeplay в настоящее время возглавляет усилия по добавлению поддержки SYCL в тензорную библиотеку Eigen.
• TensorFlow использует библиотеку cuDNN для вычисления сверток на графических процессорах NVidia. Если кто-то заинтересован в создании эквивалента OpenCL, мы будем рады помочь.

Чтобы структурировать усилия, я создал список рассылки: [email protected].

@bhack уверен, что меня интересует высокопроизводительный C++ на FPGA :-)
TensorFlow звучит как хороший вариант использования проверки для triSYCL.
Кстати, если кто-то здесь ищет стажировки по этой теме, у меня есть несколько вакансий. Похоже, что Codeplay тоже ищет людей, если я доверяю их веб-сайту.

Мне действительно интересно мнение @karlrupp и @hughperkins . Надеюсь, они захотят присоединиться к обсуждению новой группы Google.

@benoitsteiner Спасибо за обновление. Было бы замечательно, если бы все вовлеченные партнеры в @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx и т. д.) стандартизировали API, подобный cudnn. Что-то вроде усилий по стандартизации компьютерного зрения Khronos openvx , но для глубокого обучения.

@bhack Какая новая группа Google?

Кроме того, OpenCL и CUDA — слишком разные подходы к программированию. CUDA работает именно так, потому что одна компания имеет полный контроль над всем, поэтому она может встраивать бинарные BLOB-объекты и черт знает что в окончательный исполняемый файл. Это невозможно сделать с OpenCL, если только вы не пойдете по пути SyCL (у меня есть свои опасения ...), и поставщик компилятора SyCL имеет полный контроль над всеми возможными целевыми архитектурами (маловероятно или невозможно на практике). В целом, я считаю, что хорошей библиотеке с поддержкой OpenCL нужно больше, чем просто несколько настроек тут и там. Наверное, не то, что вы хотели услышать, но вы спросили мое мнение :-)

@karlrupp См. https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 в конце для группы Google.
Я спросил ваше мнение, потому что у вас есть большой опыт работы с ViennaCL, взаимодействующей с алгебраической библиотекой с несколькими серверными частями (ЦП, ГП, MIC). Tensorflow опирается на библиотеку Eigein и ее новое тензорное расширение, предоставленное Google upstream (но только с бэкендом CUDA). Я думаю, что они не столкнулись со всеми ловушками, с которыми вы уже столкнулись с ViennaCL за эти годы разработки.

@bhack В настоящее время мы находимся на личной встрече в Сиэтле на этой неделе, но, конечно, я не могу сказать, говорим ли мы о библиотеках DNN или нет... :-)

@keryell Попробуйте продвинуть дело в Сиэтле;)

@karlrupp Вы правы, OpenCL и CUDA - слишком разные подходы к программированию. Аспект единого источника, обнаруженный, например, в CUDA и OpenMP 4.5, чрезвычайно эффективен с точки зрения разработки программного обеспечения. Вот почему существует этот стандарт SYCL для настоящих программистов на C++. SYCL можно рассматривать как CUDA на стероидах без каких-либо языковых расширений и с некоторыми аспектами OpenMP (задачи). Ожидается, что типичный компилятор устройства SYCL будет генерировать ядра SPIR-V.

Ваши опасения по поводу переносимости меньше связаны со стандартом SPIR-V (своего рода портативный эквивалент nVidia PTX/AMDIL/... в мире Vulkan и OpenCL), который является обязательным для принятия в OpenCL 2.1 и Vulkan. Итак, прелесть в том, что если у вас есть внешний интерфейс, генерирующий SPIR-V, вам не нужны специальные знания о самых деталях аппаратного обеспечения, на котором он будет работать. Между LLVM IR и SPIR-V есть двунаправленный транслятор Khronos с открытым исходным кодом, поэтому он открывает совершенно новые территории.

@keryell Я согласен, что SPIR-V — это шаг вперед. Однако он не решает всех проблем исчерпывающего джиттинга.

вам не нужны специальные знания о самых деталях аппаратного обеспечения для запуска

Является ли это копией и вставкой из маркетинга OpenCL 1.0, который утверждал то же самое? Вам _всегда_ нужно будет углубляться в детали базового оборудования, если вы стремитесь к максимальной производительности. Особенно это касается быстрых тензорных сокращений.

...как продемонстрировал @scott-grey с неоновым светом

@карлруп

Является ли это копией и вставкой из маркетинга OpenCL 1.0, который утверждал то же самое?

Ха-ха. :-)

Вам всегда нужно будет углубляться в детали базового оборудования, если вы стремитесь к максимальной производительности. Особенно это касается быстрых тензорных сокращений.

Конечно, но прежде чем играться с оптимизацией второго порядка, полезно, чтобы огромная часть всего шаблонного кода C++ выполнялась каким-то ускоренным образом.

Для оптимизации либо вы прошиваете свои оптимизированные бинарные ядра а-ля NervanaSys, либо, поскольку SYCL — это чистый C++, вы можете использовать в нем asm("...") с большим количеством #ifdef для тестирования целевой архитектуры. :-) Тем не менее, SPIR-V сам по себе является расширяемым, и я не понимаю, почему мы не могли в какой-то момент добавить в него встроенный VHDL или Verilog. :-)

Но более конкретно, недавнее введение операций с подгруппами должно помочь достичь хорошей производительности переносимым способом, и может помочь использование простых встроенных специальных функций.

C++ добавляет интересные функции метапрограммирования, которые позволяют заменить большинство генераторов кода, используемых, например, в clBLAS или других фреймворках, для генерации кода, более адаптированного к оборудованию X или Y.

Также N4355 в c++17 может рано или поздно войти в игру.

@karlrupp , @bhack Подход тензорного потока заключается в том, чтобы полагаться на аппаратную абстракцию (тензорный модуль) для большинства операций, необходимых для типичной нейронной сети, и полагаться на специализированные библиотеки (такие как cudnn) для нескольких операций, которые действительно критическая производительность. Аппаратная абстракция позволяет нам реализовать большинство операций TensorFlow один раз и запустить их на ускорителе с более чем достаточной производительностью.

@bhack Да, я люблю многомерные массивы. Также в нашей сфере интересов есть SG14 в комитете C++, который пытается объединить всех людей, заинтересованных в этих вопросах, в стандарте.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Конечно, SYCL находится в обсуждениях. :-)

@benoitsteiner В основном на cudnn для объединения и свертки. Я думаю, что если каждый вендор будет выпускать API со своим железом, то для этих операций со своей бинарной сборкой не будет такого масштабируемого подхода. Вот почему я думаю, что некоторые вызовы API, важные для производительности, лучше было бы каким-то образом стандартизировать.

@keryell В новом SG14 c++ есть действительно интересные темы для Matrix/Tensor, особенно в программе векторных/SIMD-вызовов. Но, кажется, никто не говорил о свертках, пулах и других полезных «стабилизированных» интерфейсах глубокого обучения. Также мне кажется, что в этой конкретной подгруппе стандартизации есть люди из Nvidia, Intel, Amd, CodePlay и т. д., но не из Google, если они есть в других группах.

:+1:

@bhack Да, в SG14 пока нет предложения по стилю машинного обучения. Но участие открыто, так что вы можете присылать свои предложения. :-) Но, возможно, более актуальна SG6 (цифровые темы). Я не думаю, что у них есть свой собственный список рассылки/форум.

@gujunli Работает ли OpenCL Caffe на Android? Извините, что задаю этот вопрос здесь, но я не нашел, где еще спросить об этом :) Было бы здорово с библиотекой глубокого обучения, которая работала бы на устройствах Android _и_ могла бы использовать графический процессор, но, похоже, на данный момент их нет. (Поправьте меня если я ошибаюсь!)

@krikru
Официальная (но экспериментальная) ветка OpenCL Caffe может работать на графических процессорах Android, однако производительность на данный момент далека от оптимальной. См. https://github.com/sh1r0/caffe-android-lib/issues/23 и https://github.com/BVLC/caffe/tree/opencl.

Реальной альтернативой cudnn могло бы стать расширение стандартных объектов OpenVx с поддержкой операторов Tensor, NdConvolution, NdPooling и (вероятно) какого-то другого оператора, который можно было бы считать стандартизируемым.
Также команде cudnn нужно сделать выбор в отношении того, какие новые API и операторы они будут вводить в каждом выпуске. Конечно, стандарт не может двигаться так же быстро, как релизы cudnn, но я думаю, что некоторые операции и объекты имеют достаточную «историю цитирований», чтобы быть стандартизированными.

@hughperkins На данный момент я не пробовал какую-либо библиотеку глубокого обучения; Я просто занимаюсь разведкой, чтобы увидеть, какую библиотеку я потенциально мог бы использовать. Вы пробовали cltorch и DeepCL на Android? Я просто предположил, что cltorch работает на Android, поскольку существует реализация Torch, предназначенная специально для Android. И зачем вам такая реализация, если уже была одна, которая работала на Android _и_ использовала OpenCL, верно? Но, возможно, мне следовало знать лучше.

@hughperkins По какой-то причине я полагал, что torch-android является официальной реализацией Torch для Android, а это означает, что никакая другая реализация Torch (по крайней мере, не официальная) вряд ли будет гладко работать на Android, включая cltorch. Не знаю, почему я так подумал, это, конечно, не имеет никакого смысла.

Ну... Soumith как бы координирует разработку факела. Он работает в Facebook AI Research. Итак, поскольку репозиторий torch-android принадлежит Soumith, я бы сказал, что он довольно близок к официальному. Но это, возможно, не является частью ядра по какой-то причине. Я думаю, вы можете задать вопрос как проблему в этом репозитории или на https://groups.google.com/forum/#!forum/torch7 . На самом деле, поскольку Soumith является основным человеком, который обрабатывает запросы в https: //groups.google.com/forum/#!forum/torch7 , я думаю, вы, вероятно, захотите разместить свой вопрос там.

Это означает, что никакая другая реализация Torch (по крайней мере, не официальная), вероятно, не будет гладко работать на Android, включая cltorch.

Обратите внимание, что cltorch не является реализацией torch. Это плагин, который предоставляет OpenCL. Вам нужны оба.

Обратите внимание, что cltorch не является реализацией torch. Это плагин, который предоставляет OpenCL. Вам нужны оба.

Ах, спасибо за разъяснение.

@ naibaf7 Есть ли у ветки OpenCL Caffe и реализации OpenCL Caffe от AMD что-то общее, кроме названия? Вы сравнивали их или знаете, есть ли разница в производительности? Вы пишете, что ветка OpenCL далека от оптимальной производительности. Что это значит и что необходимо для его улучшения? Было бы интересно попробовать на Android.

мы уходим от темы

@bhack Да, извините за захват этой темы. Я просто не знал, куда задать вопрос.

@krikru
пожалуйста, поднимите вопрос об этом в ветке Caffe, отметьте его с помощью Android и OpenCL. Тогда мы можем обсудить это дальше. Спасибо.

@keryell Похоже, следующее заседание SG14 f2f в марте будет организовано Google . Будет ли там внутренний тензорный поток?

/cc @jfbastien

Возможно , @benoitsteiner мог бы зайти, так как он местный.
Но перед этим событием в конце месяца в Джексонвилле, штат Флорида, пройдет полноценная встреча C++ F2F.
https://isocpp.org/files/papers/N4568.pdf
К сожалению, я не смогу присутствовать ни на одном из них.

Я не знаю, вызвало ли выступление CppCon 2015 « Многомерные массивы C++ для вычислительной физики и прикладной математики » каких-либо дополнительных статей.

+1

@bhack Спасибо, что указали на разговор о многомерных массивах. Это интересно и решает реальные проблемы, но выглядит слишком случайным, чтобы его можно было ратифицировать в С++ как есть. Лично я использую Boost.MultiArray, и я более уверен в полированной версии Boost.MultiArray.

Есть также несколько документов на WG21 . Как вы видите , @jfbastien из Google проявляет некоторую активность на WG21, а также помог провести встречу SG14 f2f в Google в марте.

@bhack @keryell Я думаю, что стоит перенести это обсуждение в список рассылки SG14 , поскольку подробности не связаны с OpenCL/tensorflow.

Да, наверное, это уже не так строго ограничено здесь со всеми подробностями. Помимо поддержки Eigen/sycl Есть ли план для вызовов cudnn?

+1 очень интересная тема. Надеюсь, что скоро.

Эта ветка очень интересна. Я пытался заставить caffe работать на Android. Результаты кажутся удивительными: caffe, работающий с графическим процессором Mali, кажется в 2-3 раза медленнее, чем процессор, но примерно в 4-5 раз более энергоэффективным. Тест проводился на Galaxy S6 (Mali T760, пиковая производительность 200 GFlops).

Поскольку GEMM является ядром свертки в кафе, я решил профилировать его производительность на Android. Кажется, что ViennaCL не так эффективен, как некоторые простые ядра. Теперь я могу заставить GPU работать так же быстро, как CPU для больших матриц (2k x 2k). Это по-прежнему противоречит здравому смыслу, поскольку обычно мы ожидаем, что графические процессоры будут намного быстрее.

Видеть:
https://github.com/strin/мокко-профиль

Реализации ядра можно найти здесь:

Ядра OpenCL для GEMM: https://github.com/strin/gemm-android

Есть предположения?

@strin Вы уже подписались на эту тему https://community.arm.com/thread/4935?

@bhack спасибо, что поделились. эта ветка выглядит очень интересно. Я попытался включить DVFS, как было предложено, но для sgemm в ViennaCL не было замечено значительных результатов.

+1

@strin Вы пробовали последнюю версию sgemm в MALI SDK?

Tensorflow опаздывает! Ах ах
https://gist.github.com/jarutis/ff28bca8cfb9ce0c8b1a

Это повлияет на стратегию: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
РЕДАКТИРОВАТЬ:
«StreamExecutor в настоящее время используется в качестве среды выполнения для подавляющего большинства внутренних приложений GPGPU Google, и его снимок включен в проект TensorFlow_ с открытым исходным кодом, где он служит средой выполнения GPGPU».

+1

Надеюсь, что людям, работающим над этим, удастся преодолеть альтернативную проблему CUDNN к тому времени, когда tensorflow приблизится к версии 1.0.

@martinwicke , почему эта проблема закрыта?

Я не думаю, что ваша фиксация исправляет это.

Вы не можете всегда использовать одни и те же комментарии коммита в разных репозиториях;) https://github.com/tensorflow/skflow/issues/22

О GitHub

@vrv Теперь, когда вы гиперуведомили нас, не могли бы вы дать отзыв о стратегии исполнителя потока? ;)

Я просто буду обвинять GitHub во всем, включая отсутствие поддержки OpenCL. ;)

@benoitsteiner , возможно, сможет прокомментировать больше. Я действительно не знаю, что вы подразумеваете под стратегией «потокового исполнителя». В настоящее время мы используем версию потокового исполнителя, CuDNN и Eigen, и все они хорошо работают вместе, поэтому я не уверен, как изменились какие-либо планы в отношении OpenCL.

Я имею в виду:
"Что такое StreamExecutor?
========================
StreamExecutor — это унифицированная оболочка для моделей программирования на стороне хоста CUDA и OpenCL (среды выполнения). Это позволяет хост-коду ориентироваться либо на устройства CUDA, либо на устройства OpenCL с идентично функционирующими ядрами с параллельными данными».

Стандартные операции
==================
StreamExecutor предоставляет несколько предопределенных ядер для общих операций с параллельными данными.
Поддерживаемые классы операций:

• BLAS: основные подпрограммы линейной алгебры,
• DNN: глубокие нейронные сети,
• БПФ: быстрое преобразование Фурье и
• ГСЧ: генерация случайных чисел.

@keryell Привет, я также заинтересован в реализации TensorFlow на FPGA с использованием языков программирования высокого уровня, таких как Xilinx C++ или OpenCL. Я с удовольствием внесу свой вклад, если у вас есть какой-то план.

@henline Можете ли вы объяснить, какова будет роль StreamExecutor в Opencl и соответствующих Canned
операций для Tensorflow. Я до сих пор не понимаю, как это будет интегрироваться с планами SyCL на Eigen и cudnn (замена?)

:+1: Я тоже хотел бы внести свой вклад в это.

@bhack StreamExecutor предоставляет функциональные возможности, эквивалентные среде выполнения CUDA и некоторым библиотекам CUDA (таким как cublas или cudnn). Однако вам все еще нужно написать свои ядра графического процессора, для чего мы используем Eigen.

@benoitsteiner Итак, все еще нужно написать два ядра, одно для CUDA и одно для Opencl?

@benoitsteiner Итак, у вас все еще нет внутреннего аналога tensorflow/tensorflow/stream_executor/opencl/? Как насчет "Консервированных операторов"?

@bhack Eigen позволяет вам написать выражение, описывающее вычисление, которое вы хотите выполнить один раз, и автоматически сгенерировать ядро ​​(которое мы называем оценщиком) для оценки этого выражения на ЦП и другое ядро ​​для оценки выражения на устройстве CUDA. Как только мы получим поддержку OpenCL в Eigen (мы приближаемся к этому), можно будет также автоматически генерировать ядро ​​OpenCL.
Для нескольких операций TensorFlow, критически важных для производительности (например, свертки), мы используем оптимизированные вручную ядра и/или сторонние библиотеки. В этих случаях нам понадобится хорошая реализация этих операций в OpenCL.

:+1:

Есть ли план добавить больше кода на https://bitbucket.org/benoitsteiner/eigen-opencl? Как насчет компилятора sycl? Похоже, что нет выпущенных целевых реализаций GPU с открытым исходным кодом.

@bhack @benoitsteiner
Вскоре я выпущу замену cuDNN (только часть свертки, так как это наиболее критично для производительности и памяти) для OpenCL на Caffe. Возможно, это также будет полезно для порта Tensorflow.

@bhack : Codeplay добился большого прогресса на фронте opencl. Оставайтесь с нами, и в ближайшие несколько недель на https://bitbucket.org/benoitsteiner/eigen-opencl появится большой толчок.

@naibaf7 : быстрая реализация операции свертки была бы чрезвычайно полезна в TensorFlow. С нетерпением жду этого.

@benoitsteiner Хороший улов, они получили стул

@benoitsteiner Как я могу просто удалить реализацию cuda? потому что '#ifdef GOOGLE_CUDA' такой сложный. Иногда это означает CUDA, иногда означает GPU.

Поскольку эта проблема попала в дорожную карту (см. _Платформы_): есть ли у нас приблизительное представление о том, когда поддержка OpenCL появится в TensorFlow? Нравится версия 0.9/1.0? 3/4 кв. 2016 г.? Или 2017 более реалистичен?

@benoitsteiner Достаточно ли готов eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl для поддержки разработки тензорного потока opencl?

Зависит ли тензорный поток только от тензоров Eigen или есть какие-либо другие зависимости от Eigen?

@NEELMCW Codeplay только что выпустил частичную поддержку OpenCL для Eigen Tensors. Код доступен в этом репозитории bitbucket . По большей части TensorFlow зависит от собственных тензоров. Существуют дополнительные зависимости от Eigen для операций линейной алгебры, но нам не нужно предоставлять совместимую с OpenCL реализацию этих операций (по крайней мере, изначально). Поэтому у нас очень хорошая возможность начать поддержку OpenCL в TensorFlow.

Если вы заинтересованы в том, чтобы внести свой вклад, я начал отслеживать, что нужно сделать в этой таблице.

@benoitsteiner Я являюсь автором библиотеки OpenCL BLAS для С++ 11 (https://github.com/CNugteren/CLBlast) и в настоящее время реализую там поддержку половинной точности. Я рад внести свой вклад в часть этого проекта, посвященную BLAS/GEMM, и/или изменить CLBlast, чтобы он лучше соответствовал вашим потребностям.

@CNugteren
CLBlast теперь также доступен в OpenCL-Caffe, вы видели это? :)
У вас также была возможность взглянуть на свертки libDNN?

@naibaf7 Я видел это, да! :) До сих пор я вообще не смотрел на libDNN, но я не уверен, что именно вы имеете в виду. Я предполагаю, что свертка реализована с использованием GEMM?

@CNugteren
Да, я просто подумал, что было бы неплохо, если бы вы просмотрели его и, возможно, дали несколько советов по улучшению или настройке libdnn.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Он использует GEMM, но неявно (не через BLAS, только небольшие GEMM на уровне рабочей группы), так что возможен более высокий уровень параллелизма, а также не требуется промежуточный буфер (для развертывания данных в схему GEMM).

Всем привет,

@benoitsteiner, спасибо, что упомянули наш толчок! Надеюсь, это будет полезно!

Чтобы скомпилировать этот код, вам нужен компилятор SYCL. В настоящее время единственным поддерживаемым компилятором является ComputeCpp от Codeplay, который доступен через оценочную программу Codeplay. ComputeCpp будет доступен бесплатно в виде общедоступной открытой бета-версии позже в 2016 году, а затем выпущен в виде бесплатной версии (ComputeCpp Community Edition) в 2017 году. Это позволит любому компилировать и разрабатывать TensorFlow на устройствах OpenCL, таких как графические процессоры AMD или Intel. и ЦП.

Кстати. разве эта проблема не должна иметь метку OpenCL? :)

Спасибо,
Люк

Я очень надеюсь, что это можно будет скомпилировать с помощью инструмента с открытым исходным кодом. @keryell , как дела с вашей новой веткой Opencl

@bhack Было бы неплохо сначала посмотреть, сможет ли он работать с triSYCL в режиме хост-устройства CPU OpenMP. Но у меня нет пропускной способности, чтобы войти в систему сборки TensorFlow/Eigen прямо сейчас. :-( Если кто-то хочет попробовать, не стесняйтесь. :-)

https://github.com/keryell/triSYCL/commits/opencl вскоре должен позволить запускать ядра OpenCL в режиме совместимости OpenCL, но не в режиме единого источника SYCL, о котором мы все мечтаем, потому что у нас еще нет планировщика Clang/LLVM. для извлечения ядер из SYCL. Но Khronos недавно открыл исходный код компонентов от AMD и Intel для поддержки OpenCL C++ 2.2 и SPIR-V, которые должны были стать его основой. Так что это "просто" вопрос времени...

Может ли кто-нибудь дать оценки того, когда Tensorflow сможет работать с OpenCL (графические процессоры AMD)? И как выглядит кривая производительности/юзабилити с течением времени? Трудно преобразовать всю прошлую информацию в полезную информацию о покупке оборудования. :)

Заранее спасибо!

@djan92
Я бы сказал, дайте ему год, пока его можно будет использовать, к сожалению. Похоже, он будет построен на достаточно передовых библиотеках и технологиях, большинство из которых еще не совсем готовы.
Я также собираюсь перейти на борт только тогда, когда полный стек инструментов будет доступен как OpenSource, а не раньше.

@naibaf7

Я бы сказал, дайте ему год, пока его можно будет использовать, к сожалению. Похоже, он будет построен на достаточно передовых библиотеках и технологиях, большинство из которых еще не совсем готовы.
Я также собираюсь перейти на борт только тогда, когда полный стек инструментов будет доступен как OpenSource, а не раньше.

Почему бы сначала не реализовать версию CL, пока не будет готов порт SYCL? Я полагаю, здесь найдется немало людей, готовых помочь. Один год звучит слишком долго.

@djan92
Да, вы правы, #22 уже почти 8 месяцев и у него более 100 постов! Информация может быть завалена!

Может ли кто-нибудь дать оценки того, когда Tensorflow сможет работать с OpenCL (графические процессоры AMD)?

TensorFlow использует библиотеку Eigen для тензорных вычислений (в модуле Tensor). Мы выполнили частичную реализацию OpenCL 1.2 с использованием SYCL (https://bitbucket.org/benoitsteiner/opencl, ветвь Codeplay). Причина, по которой мы использовали SYCL для этой работы, заключается в том, что в этом разделе TensorFlow используются деревья выражений C++, что возможно с SYCL для OpenCL, но невозможно напрямую с OpenCL C. Другие компоненты TensorFlow, такие как свертки или BLAS, могут напрямую использовать OpenCL C.

В настоящее время я работаю над интеграцией ComputeCpp (компилятор SYCL от Codeplay) в систему сборки bazel. Это должно быть готово в ближайшее время (следуйте этому репозиторию: https://github.com/benoitsteiner/tensorflow-opencl/). После этого TensorFlow следует ускорить в системах, поддерживающих OpenCL SPIR (например, AMD или Intel) с помощью ComputeCpp. Дальнейшая работа будет продолжена по ускорению большего количества TensorFlow, а также по поддержке большего количества реализаций OpenCL и SYCL с открытым исходным кодом triSYCL. SYCL и OpenCL — это открытые стандарты, не требующие лицензионных отчислений от нескольких поставщиков, поэтому с помощью этого подхода можно поддерживать множество платформ и устройств (не только графические процессоры AMD).

Компилятор ComputeCpp Community Edition будет доступен бесплатно позже в 2016 г. (в бета-версии: полное соответствие будет выпущено бесплатно в начале 2017 г.).

Работа по ускорению частей TensorFlow, отличных от C++ (например, BLAS и свертки), может быть выполнена без SYCL и реализована отдельно. Различные поставщики оборудования могут иметь свои собственные оптимизированные библиотеки для этих функций, которые могут способствовать ускорению. Или мы могли бы использовать Eigen с C++ для этих функций.

И как выглядит кривая производительности/юзабилити с течением времени?

Мы считаем, что производительность будет постоянно улучшаться. Чтобы ускориться на самых разных устройствах, нам нужно более эффективно управлять данными, поэтому существует элемент работы «управляемый тензор», чтобы можно было более эффективно управлять перемещением данных между хостом и несколькими устройствами. Сейчас сложно предсказать, как будет меняться производительность на разных устройствах. В настоящее время ускорено очень мало, но мы создаем инфраструктуру, позволяющую использовать ускорение на основе открытых стандартов в TensorFlow.

@naibaf7

Я бы сказал, дайте ему год, пока его можно будет использовать, к сожалению.

Основные операции должны быть здесь очень скоро. Мы внедряем базовую инфраструктуру в код для поддержки ускорения на основе открытых стандартов. Мы считаем, что при поддержке сообщества ускоренная и удобная версия будет готова менее чем за год.

Я также собираюсь перейти на борт только тогда, когда полный стек инструментов будет доступен как OpenSource, а не раньше.

ComputeCpp будет доступен публично бесплатно в 2016 году. После этого должна появиться поддержка triSYCL с открытым исходным кодом. OpenCL с открытым исходным кодом уже поддерживается pocl, Shamrock, Clover, Beignet.

@robertwgh
Тензорный код C++ в Eigen было бы нелегко перенести в OpenCL C без SYCL, но есть и другие функции, которые хорошо работали бы в OpenCL C. Взгляните на эту таблицу: https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 и введите свое имя для функций, которые должны использовать обычный OpenCL C (например, BLAS и свертки).

Мы предоставляем ознакомительную версию для ComputeCpp перед публичным выпуском. Если вы хотите один, пожалуйста, напишите мне по электронной почте :)

@lukeiwanski Отлично, спасибо за обновление. Я надеюсь, что вы правы в том, чтобы сделать его полнофункциональным менее чем за год.

Еще один шаг Streamexecutor в LLVM

есть ли шанс получить ускорение на rx 480?

@benoitsteiner
Автономная версия LibDNN будет доступна для интеграции:
https://github.com/naibaf7/libdnn

Приятно читать, что над этим работают. Было бы лучше, если бы Beignet 2.0 был отполирован. У Skylake и Iris сейчас большой потенциал.

Недавний запрос на извлечение был добавлен на https://github.com/benoitsteiner/tensorflow-opencl/pull/1 , если кто-то хочет взглянуть.

Чтобы получить доступ к OpenCL SDK Imagination (GPU), требуется NDA, у нас есть только общая библиотека. Можно ли запустить тензорный поток на основе этих библиотек?

@алефман
Вам не нужны файлы заголовков, специфичные для поставщика, для создания любой программы OpenCL. Попробуйте cl.hpp из https://www.khronos.org/registry/cl/api/1.2/cl.hpp и opencl.h/cl.h из любого другого SDK. Например - у меня как минимум 3 платформы OpenCL и все работает с одним общим /usr/include/CL/cl.h

Мы пока не поддерживаем TensorFlow, работающий на OpenCL. Это незавершенная работа. В настоящее время мы работаем над графическими процессорами AMD. Поддержка PowerVR должна последовать. Если вы хотите внести свой вклад в разработку, вы должны связаться с нами (Codeplay) напрямую. Если вы хотите запустить TensorFlow на PowerVR, вам следует немного подождать.

@inferrna спасибо, это похоже на OpenGL, который скрывает реализацию конкретного поставщика.

@andrewrichards Я люблю вносить свой вклад в разработку, как с вами связаться?

Проще всего, если вы нажмете «зарегистрировать свой интерес» на нашей странице здесь: https://www.codeplay.com/products/computecpp .
Так вы попадете в нашу программу для разработчиков, и мы сможем работать вместе над этим @alephman.

Если вы хотите, вы также можете внести свой вклад в компиляцию с альтернативой с открытым исходным кодом. См. https://github.com/tensorflow/tensorflow/issues/22#issuecomment -221841173

Всем привет!
Очень рад слышать, что поддержка Tensorflow распространяется за пределы Nvidia Cuda. Интересно, не планируете ли вы также заставить его работать на APU следующим образом: http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
APU поддерживают OpenCL как для CPU, так и для GPU.
Это должно работать в значительной степени из коробки, когда поддержка OpenCL будет готова.
Между тем, если у вас уже есть APU и вы хотите попробовать другую платформу машинного обучения, BVLC OpenCL Caffe уже работает.

@naibaf7 Спасибо за разъяснение. Я ищу экономически эффективные комбинации аппаратного и программного обеспечения для локального запуска Tensorflow и обязательно буду следить за ходом разработки OpenCL.

@хуперкинс
Да, это может быть проблемой, но я думаю, что такие части, как im2col/col2im и другие реализации свертки, также могут быть подключены как внешние API, если это действительно проблема с GCLA. Это также может быть лучше для первоначальных авторов такой работы.

@hughperkins Мы работаем над переносом OpenCL в TensorFlow через SYCL для OpenCL 1.2.
Пожалуйста, взгляните на https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 для "todos" и прогресса.
Недавно мы выпустили компилятор для SYCL https://www.codeplay.com/products/computesuite/computecpp под названием ComputeCpp Comunity Edition. Люди могут попробовать!
Кроме того, мы сосредоточены на библиотеке Eigen https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp — доводим ее до стадии, требуемой MNIST TensorFlow — осталось еще несколько вещей.
Что касается ограничений, текущий выпуск ComputeCpp CE был протестирован для Intel (ЦП, ГП) и AMD (ЦП, ГП), а также для поддерживаемых платформ Ubuntu 14.04 64-бит и CentOS 64-бит.
ComptueCpp можно загрузить бесплатно и использовать в коммерческих проектах и ​​проектах с открытым исходным кодом.
Потому что мы <3 открытых сообщества :)

@lukeiwanski Извините за обсуждение/спрос об этом здесь, в ветке, но я думаю, что это может быть интересно и другим: я понимаю, что Codeplay очень заинтересован в реализации SYCL для OpenCL, и я уже слышал, что другие заинтересованы в этой работе ты тоже. Например, я прочитал какой-то пост официального представителя Movidius. Однако я хотел бы спросить, каков на самом деле вклад Google в это? Поскольку Movidius, помимо AMD и других, указан в качестве партнеров Codeplay, я могу понять, что они поощряют или даже поддерживают SYCL для OpenCL, но, насколько мне известно, Google не является вашим партнером и до сих пор не участвовал в этом?!

Не поймите меня неправильно, мне очень нравится ваша работа, но не лучше ли было бы объединить ваши усилия, объединить ресурсы и попробовать работать вместе с Google? Мне кажется, что многие разные стороны заинтересованы в OpenCL для TensorFlow, но огромный потенциал не используется, потому что эти стороны не развиваются вместе?!

Я могу ошибаться и, пожалуйста, извините себя, если это было достаточно обсуждено, но я до сих пор не знаю о каких-либо серьезных попытках Google (или других сторон) работать вместе над этим, и, как следствие, я до сих пор не знаю, как сообщество могут помочь или поддержать (например, отдельные лица) либо путем прямого вклада, тестирования или других вещей.

@ascenator Мы в Google тесно сотрудничаем с Люком и его коллегами по Codeplay над этим проектом уже почти 12 месяцев. Вклад Codeplay в эти усилия был огромен, поэтому мы решили, что должны позволить им взять на себя инициативу, когда дело доходит до сообщения обновлений, связанных с OpenCL. Вот почему вы так мало слышали от нас по этой теме :)

Теперь, когда компилятор ComputeCpp широко доступен, мы планируем объединить проделанную работу. Но сначала мы хотим собрать комплексную тестовую инфраструктуру, чтобы убедиться, что мы не дестабилизируем существующую кодовую базу.

Мы приветствуем любой вклад в это усилие, поэтому не стесняйтесь обращаться ко мне, если вы хотите помочь. Нас особенно интересуют высокопроизводительные ядра OpenCL для умножения матриц и сверток. Было предложено несколько вариантов, но мы еще не начали изучать плюсы и минусы каждого из них или способы их интеграции.

@benoitsteiner большое спасибо за разъяснения и извините за дезинформацию! Звучит очень хорошо и многообещающе! Тогда я обязательно посмотрю на ComputeCpp. Я действительно с нетерпением жду поддержки OpenCL для TensorFlow, потому что это предлагает много новых возможностей для робототехники (это область, в которой я исследую и использую TensorFlow для приложений глубокого обучения). По крайней мере, я посмотрю ранние выпуски и попробую протестировать/отладить. У нас есть несколько чипов Intel плюс несколько процессоров ARM, которые ждут испытаний;)

@hughperkins ... извините, но разве это здесь не совсем по теме? Я не понимаю, как это актуально в OpenCL TF?

Меня больше интересует, будет ли применяться подход к настройке ядра умножения матриц и свертки, и будет ли действующая альтернатива CompiteCpp с открытым исходным кодом, которая будет производить SPIR-V.

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

Два новых стандарта Kronos Group опубликованы на https://www.khronos.org/news/press/khronos-launches-dual-neural-network-standard-initiatives.

Если это поможет, выходит лучшая версия isaac: https://github.com/ptillet/isaac , которая обеспечивает значительное ускорение по сравнению с clBLAS и cuBLAS на Maxwell, Pascal и Fiji. Также предоставляет более быстрые (с учетом ввода) ядра, чем Tensorflow, для одномерных и двумерных сокращений.

@hughperkins кажется, у вас больше шансов написать компилятор CUDA для любого устройства OpenCL, а не транслятор CUDA-OpenCL.

@hughperkins Может быть, функция SVM в OpenCL 2.0 может решить проблему с указателем? Поскольку все, кроме Nvidia (AMD, Intel, ARM, Qualcomm), начинают поддерживать OpenCL 2.0. Может быть, это хорошее решение?

@hughperkins это сама реализация blas. Он реализует некоторые символы из заголовков clblas и cublas, поэтому не требует перекомпиляции и модификации кода. необходимо. Я мог бы также реализовать некоторые символы для clblast.h, так как он использует другой заголовок. Некоторые преимущества Исаака:

• Полностью динамический, так что он может использовать либо CUDA, либо OpenCL без перекомпиляции.
• С учетом ввода, он не настраивает ядра для больших квадратных матриц. Он должен хорошо работать на всех формах, о которых вы только можете подумать, без перенастройки.
• C++ API, аналогичный numpy/arrayfire. Некоторый сплав для объединения поэлементной операции с сокращениями

@marty1885
Не совсем. AMD вернулась к поддержке версии 1.2 в драйверах AMDGPU-PRO. Может пройти какое-то время, прежде чем полная поддержка 2.0 станет широко распространенной. Это определенно не краткосрочное решение.

• да
• При необходимости я мог бы взломать совместимость для множества операций (например, переслать **MV в GEMV). Комплексная поддержка будет сложной. Двойная поддержка уже есть, но ни одна архитектура не настроена на это.

@хуперкинс

Похоже, мой код не нарушает никаких очевидных правил OpenCL.

Да, прямая передача любой структуры __global (например, массива или структуры), содержащей указатели, неверна только потому, что эти указатели могут указывать на память другого устройства (OpenCL поддерживает парадигму с несколькими устройствами, когда одно устройство не может получить доступ к памяти другого). Но на уровне IR, без промежуточной трансляции в код OpenCL, вроде бы можно побороть - я так и предполагал :)

@benoitsteiner , @henline , из https://github.com/henline/streamexecutordoc , предполагается, что потоковый исполнитель поддерживает стандартную операцию версии CL (например, DNN, BLAS) из коробки. Означает ли это, что у Google уже есть реализация clDNN, clBLAS, готовая для Tensorflow, но она еще не открыта?

В противном случае OpenCL 2.0+ и SYCL 2.2 поддерживают SVM, если вы хотите сохранить ту же программную архитектуру.
Например, OpenCL 2.0+ поддерживается графическими процессорами AMD и Intel. Во встраиваемом мире это часто поддерживается побочным эффектом даже с OpenCL 1.x, поскольку память хоста и устройства часто одинакова по соображениям стоимости.

@keryell
Но самые известные платформы, Linux + новые графические процессоры AMD (RX 480, готовящаяся к выходу Vega) пока поддерживают только OpenCL 1.2... и кто знает, когда это изменится (уверен, что через год). Beignet (Linux Intel с открытым исходным кодом) для OpenCL 2.0 также все еще содержит множество ошибок; в стабильной версии 1.2.
Кроме того, учитывая, что все небольшие компании, которые производят чипы, совместимые с OpenCL, едва поддерживают 1.2. Поэтому я предполагаю, что все, что зависит от OpenCL 2.0, на практике будет иметь очень плохие показатели адаптации.

Я думаю... у любого поставщика аппаратного обеспечения есть потребность в срочном использовании SPIR-V? Я думаю, что давление графики/шейдеров на Vulkan может помочь стороне Opencl.

@naibaf7 чтобы вернуться к обсуждению OpenCL 2 или нет, в какой-то момент должны быть доставлены реальные вещи ... В противном случае уже есть nVidia GPU и CUDA с запущенным TensorFlow ... :-)
Но, конечно, некоторый интерес представляет версия TensorFlow без SVM.

@keryell Насколько Vulkan SPIR-V работает с драйверами (которые уже имеют хороший охват устройств), как вы думаете, будет продвигать современные версии Opencl?

@naibaf7 Встреча Khronos состоится на следующей неделе в Сеуле с представителями OpenCL и Vulkan, но обсуждения не являются публичными. Но это звучит как хорошая идея, чтобы каждый мир улучшал другой и в какой-то момент приносил пользу TensorFlow. :-)

@keryell
Да, я надеюсь, что они обсудят некоторые полезные вещи DeepLearning :)

Поздравляю! Обязательно проверьте проект HIP, так как они пытались решить ту же проблему. Они решили создать новый язык под названием HIP, который определяет, что нужно преобразовывать вручную (например, проверка поддержки двойной точности путем проверки уровня вычислений). По мере продвижения проекта количество ручных переводов будет уменьшаться. См.: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP .

Я предлагаю вам использовать HIP и исправить некоторые ошибки, которые блокируют продвижение Tensorflow или ваших собственных целей, поскольку теперь у вас есть понимание LLVM для этого. Таким образом, вам не нужно решать проблемы, которые они уже исправили.

@хуперкинс
не могу собрать модуль python с вашей вилкой после этого https://github.com/tensorflow/tensorflow/blob/master/tensorflow/g3doc/get_started/os_setup.md#create -the-pip-package-and-install

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

Я на Ubuntu 16.04, имя каталога от coreutils-8.25-2ubuntu2

@hughperkins Я думаю, что настройка файла докера TF в вашем репозитории с помощью этой инструкции может упростить настройку для других.

Да когда будет что-то более функциональное. По сути, это копия и прошлое этой инструкции, которую вы опубликовали.

Я экспериментирую с MacOS 10.10.5 на MacBook конца 2015 года с ATI 6770M (OpenCL 1.2).

Я установил Xcode 8, Anaconda (Python 3.5) и MacPorts эквиваленты clang+llvm:

вместо строк apt-get выполните:

sudo порт установить clang-3.8 llvm-3.8

Вместо использования /proc/cpuinfo выполните:

NUM_PROCS=$(system_profiler SPHardwareDataType | grep "Общее количество ядер" | cut -d ":" -f 2)

Затем измените Makefile для использования macports и запустите make

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

обновить каталоги Macos OpenCL; будущее: используйте /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' условно

grep -Rl 'включить "CL/" * | xargs perl -pi.bak -e 's|включить "CL/|включить "OpenCL/|g"
сделать -j ${NUM_PROCS}

Это насколько я понимаю:

$ сделать -j ${NUM_PROCS}
mkdir -p построить
mkdir -p построить
mkdir -p построить
/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-исключения -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-исключения -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-исключения -c -o build/readIR.o -g -I/opt/local/libexec/llvm-3.8/include src/readIR.cpp
В файле из src/hostside_opencl_funcs.cpp:17:
/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/include/cocl/cocl.h:91:16: предупреждение: атрибут 'host' игнорируется [-Wignored-attributes]
attribute ((host)) inline unsigned long long atomicExch (volatile unsigned long long _p, unsigned long long val) {
^
src/hostside_opencl_funcs.cpp:194:33: ошибка: вызов функции-члена 'in' неоднозначен
launchConfiguration.kernel->in(смещение);
~ ~ ~ ~ ~ ~~~^~
/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15: примечание: функция-кандидат
CLKernel in (значение с плавающей запятой);^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15: примечание: функция-кандидатCLKernel *in (значение int32_t);^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15: примечание: функция-кандидатCLKernel *in (значение int64_t);^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15: примечание: функция-кандидатCLKernel *in (значение uint64_t);^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15: примечание: функция-кандидатCLKernel *in (значение uint32_t);^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15: примечание: функция-кандидат нежизнеспособна: неизвестно преобразование из 'size_t' (он же 'unsigned long ') в 'easycl::CLArray *'для 1-го аргументаCLKernel *in(CLArray *clarray1d) { return input(clarray1d);



}^/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36: примечание: шаблон функции-кандидата нежизнеспособен: требуется 2 аргумента, но был предоставлен 1шаблонCLKernel *in(int N, const T *data);^Сгенерировано 1 предупреждение и 1 ошибка.make: *_* [build/hostside_opencl_funcs.o] Ошибка 1сделать: * * Ожидание незавершенных работ....
источник/struct_clone. cpp:245 :12: предупреждение: 11 значений перечисления не обрабатываются в коммутаторе: 'HalfTyID', 'X86_FP80TyID', 'FP128TyID'... [-Wswitch]
переключатель (идентификатор типа) {
^
Сгенерировано 1 предупреждение.

launchConfiguration.kernel->in((int64_t)смещение);

Этот патч сработал. Спасибо.

После применения этого продолжение сборки привело к ошибкам пространства имен size_t:

$ сделать -j ${NUM_PROCS}
mkdir -p построить
mkdir -p построить
/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
В файле из src/hostside_opencl_funcs. cpp:17 :
/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/include/cocl/cocl.h:91:16: предупреждение: атрибут 'host' игнорируется [-Wignored-attributes]
attribute ((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 предупреждение.
/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
В файле, включенном из src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/include/cocl/cocl_blas.h:8:9: ошибка: нет типа с именем 'size_t' в пространстве имен 'std'; вы имели в виду просто 'size_t'?
typedef std::size_t cublasStatus_t;
^ ~ ~
размер_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'
typedef SIZE_TYPE size_t;
^
В файле, включенном из src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/ Third_Party/cuda-on-cl/include/cocl/cocl_blas.h:17:5: ошибка: нет типа с именем 'size_t' в пространстве имен 'std'; вы имели в виду просто 'size_t'?
std::size_t cublasCreate(cublasHandle_t phandle);^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef SIZE_TYPE size_t;^В файле, включенном из src/cocl_blas.
вы имели в виду просто 'size_t'?std::size_t cublasDestroy(дескриптор cublasHandle_t);^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef SIZE_TYPE size_t;^В файле, включенном из src/cocl_blas.
вы имели в виду просто 'size_t'?std::size_t cublasSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef SIZE_TYPE size_t;^В файле, включенном из src/cocl_blas.
вы имели в виду просто 'size_t'?std::size_t cublasSetPointerMode (дескриптор cublasHandle_t, режим cublasPointerMode_t);^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef SIZE_TYPE size_t;^В файле, включенном из src/cocl_blas.
вы имели в виду просто 'size_t'?std::size_t cublasGetPointerMode (дескриптор cublasHandle_t, cublasPointerMode_t *mode);^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef SIZE_TYPE size_t;^В файле, включенном из src/cocl_blas.
вы имели в виду просто 'size_t'?std::size_t cublasSetStream(дескриптор cubasHandle_t, cudaStream_t streamId);^ ~ ~размер_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: примечание: здесь объявлен 'size_t'typedef 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.cppВыдало 7 ошибок.make: *_* [build/cocl_blas.o] Ошибка 1make: * * Ожидание незавершенных работ....

Можем ли мы отправить длинный журнал в gist, чтобы поток оставался читабельным?

вопрос: ребята, как вы решаете проблему с адресными пространствами?

@hughperkins Спецификации SYCL описаны в разделе 5.8 («Вывод адресного пространства»)
как реализация должна работать с различными типами памяти. Этот
аналогична предыдущей работе, проделанной для PlayStation 3 и описанной в
этот документ: Разгрузка — автоматизация миграции кода в гетерогенныйМногоядерные системы или C++ на ускорителях: поддержка моделей программирования SYCL и HSA с одним исходным кодом с использованием Clang

надеюсь, это поможет.

@hughperkins Могу ли я скомпилировать ваш код репозитория tensorflow-opencl, чтобы применить мою плату ARM? Моя плата ARM имеет графический процессор Imagination, который поддерживает opencl 1.2.

Я наткнулся на эту тему, когда искал поддержку tf/intel.

У меня Intel MacBook Pro, чем я могу помочь? Я не знаю c/c++, но я могу следовать инструкциям по сборке/компиляции/тестированию и возвращать результаты (pastebin)...

derek$ system_profiler SPDisplaysDataType
Графика/дисплеи:

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 Спасибо за ваши инструкции!
Я пытаюсь скомпилировать ваш cuda-on-cl на платформе Arm. Следуя руководству cuda-on-cl:
Информация о моей плате ARM:
arm64, gcc 4.9, clang и llvm 3.5, openCL 1.2

* Должен ли я использовать версию clang++-3.8? *
git clone --recursive https://github.com/hughperkins/cuda-on-cl
сделать
ошибка:
clang++-3.8: Команда не найдена
Я редактирую Makefile следующим образом: CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
затем сделайте снова:
ошибка:
src/mutations.h:3:10: фатальная ошибка: файл llvm/IR/Module.h не найден

попробуйте запустить make run-test-cocl-cuda_sample:
сделать: cocl: команда не найдена

@hughperkins позвольте мне попробовать.

Получил ошибку при тестировании keras с tensorflow

keras$ KERAS_BACKEND=tensorflow pytest3

Ошибки вывода:

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

Код:

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

привет всем, меня зовут рикардо, я программист на С++ с многолетним опытом работы на С++ и немного на Cuda, я буду рад внести свой вклад в эту работу. Как я могу внести свой вклад в эту работу?

Хорошо, у меня есть Odroid Xu3 с Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 и полный профиль OpenCL 1.1)
работает на ОС: LUbuntu 1404 64 бита
Сделаю полную установку и выложу результат на этой платформе.
Насчет багов, есть список багов (что-то вроде Bugzilla?) или таблица со списком багов?
Ваше здоровье!

Как насчет использования 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
«Ваше желание удовлетворено, Eigen переносится на AMD GPU через HIP. Вторая часть вашего запроса — можем ли мы предоставить стандартизированный инструмент, поддерживающий FLOAT16, который поставляется со всеми нашими графическими процессорами GFX8, желание удовлетворено».
Наша ветка разработки компилятора AMDGPU теперь поддерживает собственные инструкции Float16 и Int16 вместо эмуляции FP16/Int16 с инструкциями преобразования с повышением и понижением для преобразования из FP16/Int16 в Float и обратно.

Это тесты f16 на оборудовании Fiji, успешно выполняющие умножение матриц с половинными типами с преобразованием и с собственными инструкциями».

Кроме того, это не связано, но вы должны использовать syCL/openCL 2.0 вместо 1.2, потому что nvidia уже поддерживается через CUDA. А openCL 2.0 поддерживается драйверами AMD и Intel для Windows. Также AMD заявила, что скоро выпустит драйвер openCL 2.0 для Linux с открытым исходным кодом (который может быть использован Intel, магия открытого исходного кода) (и у Intel уже есть реализация Linux openCL 2.0, которая просто нуждается в доработке). Если вы спросите Intel и AMD, возможно, они могли бы ускорить работу, потому что тензорный поток важен для их экономических интересов. И они уже сказали в этом разделе комментариев, что хотят помочь. Также все основные производители ARM поддерживают openCL 2.0. Это может открыть много возможностей для Android (что отвечает экономическим интересам Google), малины, умных телевизоров и т. д.

И в среднесрочной перспективе мы могли бы в конечном итоге разработать резервный слой opencl 1.2 для неподдерживаемого оборудования.
И реализация должна также использовать openVX (который сейчас поддерживается всеми основными производителями оборудования, а у AMD есть реализация с открытым исходным кодом) и с https://www.khronos.org/news/press/khronos-launches-dual-neural-network .
И все это со Spir-V (который можно использовать одновременно с Vulkan и openGL).
Можно сказать, что я дублирую то, что уже было сказано, но важно синтезировать.
И, наконец, может ли tensorflow использовать HSA?

http://www.hsafoundation.com
HSA было бы здорово на Android.

Я не знаю, будет ли HIP полезен или нет. Он поддерживается только на некоторых картах AMD, поэтому нам в любом случае нужна реализация OpenCL, если мы хотим поддерживать все устройства. Возможно, оно того стоит, если реализация HIP заметно быстрее. Это может быть так, но я еще не видел много тестов (HIP против OpenCL). Другой причиной может быть MLOpen (который написан на HC) в качестве замены cudnn, но опять же, я понятия не имею, насколько это быстро и какие функции он поддерживает.

TensorFlow не будет использовать HSA напрямую, потому что он довольно низкоуровневый. Но HC (и HIP) реализованы поверх него, и вы также можете реализовать OpenCL поверх if (это делает pocl).

Будет ли здесь полезен алгоритм relooper? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins Приятно видеть, что у вас есть прогресс с вашим компилятором, но я думаю, что это уже не по теме TensorFlow. Вместо этого вам следует начать множество небольших обсуждений на странице GitHub вашего проекта компилятора. Думаю, это было бы более целенаправленно и продуктивно.

См. https://github.com/chihchun/opencl-docker

Также есть https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.cpp .

Вот соответствующий документ: https://github.com/kripken/emscripten/blob/master/docs/paper.pdf?raw=true

Первоначальная поддержка OpenCL/SyCL была объединена в master с https://github.com/tensorflow/tensorflow/pull/5267 .

Поздравляем!

@keryell Кстати, что случилось с репозиторием triSYCL? Кажется, его больше нет, и я могу найти только ссылку на Gitlab Khronos, которая не является общедоступной.

РЕДАКТИРОВАТЬ: я нашел ваш частный клон, только тот, что от amd, ушел.

@bhack , поддерживает ли opencl-docker платформу Mac?

@alephman У меня нет платформы OSX, но я думаю, что небольшая адаптация команды запуска может сработать.

@bhack @alephman : см. мой комментарий о Mac выше, если вы укажете мне на инструкции по сборке, я попробую

@olesalscheider : да, triSYCL перешел с AMD на Xilinx https://github.com/Xilinx/triSYCL , но вы правы, версия в моем рабочем пространстве GitHub тоже работает на https://github.com/keryell/triSYCL

Мы еще не пробовали triSYCL на TensorFlow. Уже есть большая работа по настройке сборки, чтобы просто попробовать...

@keryell Каков статус triSYCL?

Поддержка Intel beignet opencl 2.0 почти завершена!
http://phoronix.com/scan.php?page=news_item&px=Beignet-День рождения-CL2

@bhack triSYCL сейчас в основном разрабатывается в Xilinx. Все еще добавляя все больше и больше функций. Компилятор структуры на основе Clang/LLVM все еще находится в разработке, чтобы обеспечить полную работу с одним исходным кодом на устройстве. Но режим совместимости с OpenCL, уже реализованный, также имеет некоторую ценность, упрощая связь между хостом и ядром, при этом среда выполнения SYCL выполняет ленивую передачу в соответствии с зависимостями, выраженными средствами доступа.

Мой Mac совместим с OpenCL, так как я могу запустить свой тензорный поток с помощью openCL? Я только что обнаружил, что opencl поддерживается в тензорном потоке, когда я настраиваю новые коды.

@hughperkins в моем Mac нет инструкции clinfo , что я могу сделать для этого? Но я могу скомпилировать здесь тестовый код для opencl с clang и получить следующую информацию:
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

Спасибо, @hughperkins , но я думаю, что вчера попробовал computercpp, и кажется, что система macbook все еще не поддерживается с помощью computercpp. Так что, возможно, продолжать ждать новых обновлений — это единственное, что я могу сделать (ТТ). Кстати, у меня Iris 6100 восьмого поколения, что хорошо для OpenCL 1.2.

@hughperkins yes SYCL 1.2 априори для OpenCL 1.2, а SYCL 2.2 априори для OpenCL 2.2.
Я сказал «априори», поскольку, если вы не используете ничего, требующего режима совместимости с OpenCL SYCL, SYCL на самом деле вообще не требует OpenCL. На самом деле SYCL — это очень общая модель для гетерогенных вычислений, и она может работать поверх чего угодно. Но, конечно, реальная реализация может потребовать и OpenCL.

Привет,

В настоящее время я изучаю / работаю с TensorFlow и Keras, и мне было бы интересно получить поддержку OpenCL, работающую под macOS ... Есть ли какие-нибудь новости о работе, проделанной вокруг macOS?

Мне удалось скомпилировать TensorFlow, но если я попытаюсь настроить для OpenCL, он спросит у меня расположение ComputeCpp 1.2, а ComputeCpp для macOS, как мне кажется, отсутствует.

Привет. Ни в коем случае не эксперт в ML/Tensorflow/или даже в OpenCL, но я опытный разработчик графики для Mac, который отчаянно хочет более высокой производительности Tensorflow в системах со встроенными и AMD GPU, использующими встроенные библиотеки и простые зависимости :)

Чем могу помочь?

Глядя на последнюю ошибку компиляции в OS X в журнале travis @hughperkins - похоже, что запуск «xcode-select --install» может решить? Он должен повторно связать каталог /usr/include. У меня была эта проблема при обновлении бета-версии Xcode до выпуска, и у меня были проблемы с компиляцией некоторого кода C++.

Похоже, компилятор XLA (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) обеспечит генерацию кода LLVM из графов потока данных. Это означает очень легкий доступ к spir-v и, следовательно, к вычислительному API Vulkan. Разобравшись с генерацией кода, я не могу представить, чтобы Google не обеспечивал совместимость с Vulkan, учитывая большое количество неиспользуемых встроенных графических процессоров, работающих на Android.

@хуперкинс

Быстро: прямо сейчас я запускаю Inception v3 на пользовательской кодовой базе C++/Object-C и передаю декодированные видеокадры в сеть. Я недостаточно знаю о TF, чтобы знать потребности низкого уровня, но высокого уровня: загружать модели, запускать сеанс, ожидать, что все будет работать. Я думаю, что это означает 100% совместимость, если честно. Я знаю, что это не поможет в расстановке приоритетов. По сути, моей отправной точкой было распознавание изображений C++ с использованием TF/InceptionV3.

cuda-on-cl, работающий на Mac: я проверил репозиторий и могу помочь отлаживать и запускать сборки в своих системах и проверять результаты на различном оборудовании: у меня есть доступ к AMD Mac Pro с Dual D700, ноутбукам Nvidia Mac и Настольные системы.

Спасибо за ваш подробный отзыв. Я буду следить за репозиторием, постараюсь следить за ним и постараюсь помочь, чем смогу.

Хью, вы можете заглянуть на http://chrec.cs.vt.edu/cu2cl/ , чтобы узнать, как отображаются некоторые функции.

В моей компании StreamComputing у нас есть различные графические процессоры для тестирования сборки и бенчмаркинга, которые мы используем для наших клиентских проектов. Я мог бы подключить ваш Github к нашему Jenkins, чтобы делать еженедельные прогоны.

Спасибо за ответ, вернусь к теме на работе на этой неделе, с конкретными скриптами.

Мои варианты использования связаны с анализом соответствия текста/синтаксиса с использованием Gensim и Keras/tensorflow в моих экспериментах.

Я готов помочь вам в тестировании

У меня есть ПК с Windows с картой AMD
MBP с картой AMD
МБ со встроенным графическим процессором Intel

Привет , @hughperkins , сегодня вечером я прохожу набор тестов выше на AMD R9 390 8 ГБ. Пока у меня уже есть один другой результат; logistic_regression.py обучает и не возвращает nan . Очень хорошо! В конце он segfaults, поэтому я выясню, виноват ли скрипт или код cl.

Куда я должен отправить свои результаты, где они могут быть наиболее полезными для вас?
Возможно, мы могли бы получить стандартный «тестовый сценарий», который генерирует стандартный набор результатов, которые добровольцы могут отправить вам (или настроить на локальных ЭК или где-то еще)?

py.test — такое же хорошее решение, как и любое другое; это всего лишь pip , и в любом случае это часть процесса установки tensorflow .

С тех пор, как я начал свои тесты, я обнаружил несколько интересных вещей, и, возможно, их нельзя отлаживать, используя только вывод Python:

• Различные вызовы одного и того же скрипта могут завершиться преждевременно или могут «зависнуть» (нет вывода, нет прогресса, нет ответа на Ctrl-C , процесс должен быть pkill -9 'd) или может произойти сбой поздно либо в части проверки, либо после успешного завершения сценария. Сбои (segfaults) могут вывести из строя Xorg.
• Результаты различаются, казалось бы, без всякой причины: я могу вызвать скрипт и получить его segfault, затем вызвать его снова, и он заработает.
• Зависания могут возникать в частях кода, которые работали буквально несколько минут назад, у меня было одно зависание во время или после обучающего пакета, после того, как несколько сотен пакетов произошли успешно.

Итак, может быть, на стороне графического процессора есть неразрешенные вещи, и для их очистки требуется хороший segfault? Я пока мало знаю о модели графического процессора или OpenCL, поэтому не могу здесь многого рассказать. Но может случиться так, что выходные данные отладки графического процессора необходимы для правильного изучения того, что происходит.

Кроме того, я думал, что вы были с AMD из своего github, но, похоже, вы «агент-мошенник», делающий всю эту CUDA-on-CL в свое свободное время. Искренне благодарю за то, что возглавил это! Есть ли способ, которым я и другие могут внести свой вклад в ваши усилия, возможно, путем краудфандинга для вас GPU? Или вы могли бы создать Patreon, я буду рад подписаться на ежемесячный вклад в проект?

Что касается графических процессоров AMD, мы являемся партнером AMD. Смотрите мое сообщение 8-дневной давности, которое вы могли пропустить:

В моей компании StreamComputing у нас есть различные графические процессоры для тестирования сборки и бенчмаркинга, которые мы используем для наших клиентских проектов. Я мог бы подключить ваш Github к нашему Jenkins, чтобы делать еженедельные прогоны.

Интересно, есть ли у вас возможность настроить сервер CI, который запускается при каждом коммите?

Без проблем. Мне, вероятно, нужен доступ для записи к проекту, чтобы Дженкинс мог записать файл журнала в каталог журнала сборки. Я просто спамлю тебя, чтобы мы могли обсудить.

Всем привет,

Как вы, наверное, уже заметили, куча SYCL-материалов была перенесена в TensorFlow. Мы еще не закончили, и есть много дел. Но мы продвигаемся к этому.

Если вы заинтересованы в том, чтобы внести свой вклад или вам просто любопытно текущее состояние, проверьте разбивку ниже.

Инфраструктура
Google любезно предоставил две машины, настроенные для периодического тестирования форка TensorFlow @benoitsteiner (https://github.com/benoitsteiner/tensorflow-opencl).

Оба имеют графические процессоры AMD:

CL_DEVICE_NAME : Гавайи
CL_DRIVER_VERSION : 1912.5 (ВМ)

а также

CL_DEVICE_NAME : Фиджи
CL_DRIVER_VERSION : 1912.5 (ВМ)

Мы в Codeplay собираемся выделить машины и в следующем году. Улучшить охват разнообразия устройств OpenCL.

Мы ищем участников на этом фронте, если кто-то заинтересован в предоставлении сервера тестовой сборки для соответствующих платформ, которые мы поддерживаем.
В настоящее время требования следующие:
- Убунту 14.04
- Драйверы OpenCL, поддерживающие SPIR (Intel CPU/GPU или AMD GPU)

@VincentSC , возможно, вы могли бы помочь с этим?

Тесты
На машине Фиджи (https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull) мы столкнулись с 164 сбоями.

На машине Hawaii (https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull) у нас 56 ошибок.

Мы занимаемся исправлением сбойных тестов градиента и расследуем причины дополнительных сбоев на машине Fiji.

Эйген
В течение последних нескольких месяцев мы активно внедряли функции, необходимые для TensorFlow, в том числе: изменение формы, нарезку, базовое сокращение и т. д. В настоящее время мы реализуем сжатие. Подробную разбивку можно найти на вкладке Eigen Tensor https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

ТензорФлоу
Было реализовано множество операций с коэффициентами, включая Abs, Floor, IsFinite, Log, Pow, Mul и т. д., а также тензорные манипуляции, такие как Reshape, Shape, Identity, Fill и т. д.
Подробную разбивку можно найти на вкладке «Ядра TensorFlow» https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219.

Организация
В приведенной выше таблице есть несколько вкладок, которые классифицируют усилия проекта, такие как: общий план, собственный тензор, ядра TensorFlow, модели.

Если вы хотите принять участие, укажите свое имя рядом с вопросом, над которым вы работаете, или добавьте что-нибудь важное, чего не хватает.
Спасибо,
Люк

Эта дорожная карта активна?

@lukeiwanski Да, без проблем. Свяжитесь с нами по электронной почте [email protected]

Прочитав все это, я предполагаю, что еще нет надежного решения для использования OpenCL в macOS/OS X? Я попытался скомпилировать Tensorflow C++ с поддержкой OpenCL (что, как я полагаю, требует ComputeCpp для SYCL 1.2, как кто-то указал).

Я осмотрелся и не смог найти, где скачать, скомпилировать или собрать библиотеку SYCL. Это здесь https://www.codeplay.com/ ? Я действительно не знаю, как поступить, спасибо...

@dylib Насколько я знаю, для macOS до сих пор нет ComputeCpp. Это означает, что OpenCL для macOS не готов.

Все еще не могу заставить его работать на Ubuntu 16.04 с картой AMD и драйвером катализатора https://github.com/tensorflow/tensorflow/issues/6497. Есть ли какое-нибудь руководство?

Мне пришлось просмотреть вывод /usr/local/computecpp/bin/computecpp_info, прежде чем пытаться использовать TF, скомпилированный с поддержкой OpenCL. В моем случае это показывает

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

теперь есть 2 варианта запуска TF на GPU:
хорошо работает на ограниченном (вендором) количестве устройств, но проприетарный CUDA
плохая работа на ограниченном (разработчиками computercpp) количестве устройств, а также на проприетарном computercpp
По-прежнему нет поддержки OpenCL.

@inferrna В разделе, посвященном OpenCL, в общей документации TensorFlow. Это будет опубликовано на сайте tensorflow.org в ближайшее время.

@benoitsteiner Каково текущее состояние поддержки сверток opencl? Планируете ли вы напрямую использовать существующие ядра? А умножение матриц?

Расчетное время прибытия?

Как насчет использования HIP для переноса кода CUDA на платформенно-независимый? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Кажется, AMD работает над этим: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45#issuecomment -269827686.

Можно ли преобразовать бэкенды XLA LLVM IR в SPIR-V с помощью https://github.com/KhronosGroup/SPIRV-LLVM?

Как насчет этого? Я думаю, что этот пакет может работать на Radeon GPU.

https://github.com/RadeonOpenCompute/ROCm

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

@lukeiwanski Повлияет ли XLA на ваши усилия?

Решения XLA и SYCL дополняют друг друга в различных ситуациях: SYCL обеспечивает полную программируемость и настраиваемость. XLA предназначен для оптимизации четко определенных шаблонов на графиках.

Насколько я понимаю, XLA оптимизирует некоторые существующие графы TensorFlow во время выполнения с помощью компилятора LLVM. Это требует, чтобы проходы оптимизации были реализованы в компиляторе для каждого алгоритма, используемого в графе.
Подход SYCL — единственный подход, обеспечивающий уровень программирования CUDA, что и нужно разработчикам.

С помощью SYCL мы стремимся обеспечить поддержку всех операций TensorFlow и упростить разработку новых операций.

Это означает, что SYCL позволяет очень легко писать новые высокопроизводительные операции, в то время как XLA может оптимизировать целые графы, если он поддерживает все операции в графе.

Можно ли преобразовать бэкенды XLA LLVM IR в SPIR-V с помощью https://github.com/KhronosGroup/SPIRV-LLVM?

Не вижу причин, по которым это было бы невозможно.

@lukeiwanski Спасибо, я специально искал https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend .

@k-hashimoto: здесь мы обсуждаем портирование TensorFlow на OpenCL, стандарт от Khronos Group, и на самом деле больше OpenCL SYCL, постмодернистский стандарт C++ с единым исходным кодом от Khronos Group.
ROCm выглядит как еще одно нестандартное решение от какого-то производителя.
Если вас интересуют проприетарные решения, уже существует версия TensorFlow для CUDA, которая выглядит хорошо работающей. :-)

Согласен: продолжайте обсуждение и усилия по OpenCL и позвольте поставщикам реализовать все, что угодно, на основе этого открытого стандарта.

17 января 2017 г., 10:01:32 по Гринвичу +00:00, Ронан Кериелл ( [email protected] ) написал:

@k-hashimoto: мы обсуждаем здесь перенос TensorFlow на
OpenCL, стандарт от Khronos Group, и фактически больше OpenCL SYCL,
постмодернистский стандарт C++ с единым исходным кодом от Khronos Group.
ROCm выглядит как еще одно нестандартное решение от какого-то производителя.
Если вас интересуют проприетарные решения, уже есть CUDA
версия TensorFlow, которая выглядит хорошо работающей. :-)

--
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-273076892

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

:+1:

👍

:+1:

Это сообщение было создано автоматически программой доставки почты.

Сообщение, которое вы отправили, не может быть доставлено одному или нескольким адресатам.
получатели. Это временная ошибка. Следующие адреса отложены:

[email protected]
Домен biomassiv.es превысил разрешенное максимальное количество писем в час (111/100 (111%)). Сообщение будет повторено позже

------- Это копия сообщения, включая все заголовки. ------
Получено: от github-smtp2-ext6.iad.github.net ([192.30.252.197]:48606 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
от chi-server32.websitehostserver.net с esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Эксим 4.87)
(конверт от [email protected] )
идентификатор 1cWmiQ-0032as-W9
для [email protected]; Чт, 26 января 2017 г. 10:16:03 -06:00
Дата: Ср, 25 января 2017 г. 04:09:21 -08:00
DKIM-подпись: v=1; а=rsa-sha256; c=расслабленный/расслабленный; д=github.com;
с=pf2014; т=1485346161;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg=;
h= From:Reply-To :To:Cc:In-Reply-To: References:Subject :List-ID:
Список -Архив:Список-Пост :Список-Un подписка:От;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
От кого: Мигель Анхель[email protected]
Ответить на: tensorflow/tensorflow [email protected]
Кому: tensorflow/tensorflow [email protected]
Копия: подписано [email protected]
Идентификатор сообщения:
В ответ на:
Использованная литература:
Тема: Re: [tensorflow/tensorflow] Поддержка OpenCL (#22)
Mime-версия: 1.0
Content-Type: составной/альтернативный;
border="--==_mimepart_5888957158d12_78b73ff902fe113c148134";
кодировка = UTF-8
Контент-передача-кодирование: 7 бит
Приоритет: список
X-GitHub-Отправитель: migpradel
X-GitHub-Получатель: биомассы
X-GitHub-Причина: подписан
Идентификатор списка: тензорный поток/тензорный поток
Список-архив: https://github.com/tensorflow/tensorflow
Список сообщений: [email protected]
Список-Отписаться:,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Response-Suppress: Все
X-GitHub-Recipient-Address: [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Content-Type: текстовый/обычный;
кодировка = UTF-8
Контент-передача-кодирование: 7 бит

--
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Тип содержимого: текст/html;
кодировка = UTF-8
Контент-передача-кодирование: 7 бит

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение .

----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Новенький тут. Хотел спросить, будет ли в будущем поддержка OpenCL в tensorflow, будет ли это означать, что будет поддержка запуска tensorflow на FPGA?
Спасибо

@atinzad : да, если версия и исходный код OpenCL или SYCL поддерживаются средой FPGA. Но поскольку TensorFlow, пожалуй, самый портируемый фреймворк с различными средствами, возможно, какая-то его часть уже где-то работает на FPGA…

МОЙ БОГ. https://www.youtube.com/watch?v=LqLyrl-agOw

Каковы различия между усилиями по разработке sycl и XLA, нацеленными на SPIR-V, кроме PTX, в среднесрочной перспективе?

Какой отличный вопрос. Наверное - количество задействованных людей? Было бы очень интересно узнать!

16 февраля 2017 г., в 13:35, [email protected] написал:

В чем разница между усилиями по разработке sycl и XLA, нацеленными на SPIR-V, кроме PTX, в среднесрочной перспективе?

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

В чем разница между усилиями по разработке sycl и XLA, нацеленными на SPIR-V, кроме PTX, в среднесрочной перспективе?

@bhack Это было бы отличной дискуссией на вчерашнем саммите разработчиков TensorFlow.

Вы спрашиваете о доступных ресурсах / типах программистов, необходимых для участия?

Если да, то в подходе OpenCL/SYCL программисты C++/программисты OpenCL C могут быстро освоиться и внести свой вклад. Подход XLA требует опыта работы с компилятором/llvm.

XLA — это внутренний проект Google, поскольку с ним связано больше ресурсов. Но, с другой стороны, их задача намного больше. Написание компилятора — непростая задача.

В противном случае, если вы спрашиваете о модели:

Как я упоминал ранее в https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870, мы рассматриваем оба подхода как дополняющие подходы, и оба они имеют разные варианты использования. Я все еще придерживаюсь этого утверждения.

Например, @tatatodd в своей презентации упомянул, что некоторые оперативники никогда не будут использовать XLA в качестве цели. Я считаю, что мы можем восполнить этот пробел.

Другие вещи, которые следует учитывать, — это новые платформы. Ради этого аргумента я буду использовать мобильную и встроенную среду, поскольку новые чипы имеют тенденцию появляться чаще, чем графические процессоры (принцип тот же).

Если полупроводник поддерживает SYCL/OpenCL, вы получаете поддержку TF из коробки (могут потребоваться некоторые настройки производительности).

Если архитектура экзотическая и для нее нет бэкэнда LLVM, то XLA необходимо добавить его (это может происходить не слишком часто, но все же). Что чаще происходит, так это то, что архитектура немного меняется, а затем необходимо добавить новые проходы оптимизации или изменить существующий, чтобы получить преимущество. Настраивать код ядра проще.

Я не особо углублялся в XLA, но я предполагаю, что XLA должен каким-то образом вызывать API CUDA для запуска кода ядра PTX, поэтому его нужно будет портировать на OpenCL или Vulkan, чтобы вместо этого запускать ядра SPIR-V - что я предполагаю будет проходить через StreamExecutor - еще один фреймворк, с которым нужно ознакомиться - вероятно, довольно большие усилия.

Короче говоря, мы предоставляем единую / стабильную платформу в очень фрагментированной / разветвленной экосистеме, на которую могут ориентироваться как полупроводниковые компании, так и разработчики. В то время как XLA должна была бы взять на себя поддержку.

@benoitsteiner или @drpngx могли бы дать больше внутренних знаний о XLA, поскольку я работаю с множеством предположений/выводов, основанных на разговорах.

А еще я создал слабый канал для облегчения общения https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Эйдт:
Slack ссылка больше не действительна. Пожалуйста, пингуйте меня, если вы хотите присоединиться.

Я думаю, что это правильно и отчасти будет зависеть от того, в каком направлении будут ориентироваться производители полупроводников.
«Эти серверные части создают LLVM IR, необходимые для эффективного представления вычислений XLA HLO, а затем вызывают LLVM для создания собственного кода из этого LLVM IR». Таким образом , LLVM IR можно было преобразовать в SPIR-V . Но диалект Opencl SPIRV отличается от Vulkan . Streamexecutor помещается в параллельную библиотеку LLVM, и в исходном описании @henline первоначальный план, похоже, охватывает opencl.

/cc@dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
Nvidia скоро должна поддерживать opencl 2.0 как в Linux, так и в Windows, это ВАЖНО!

Однако с точки зрения производительности он, вероятно, будет медленнее, чем CUDA.

Помните также, что ребята из Noveau независимо работают над Opencl со SPIR-V . Статус немного устарел, но есть свежие коммиты.

Opencl по своей сути не медленнее, чем Cuda, просто nvidia фактически блокирует рынок, нанося вред своему драйверу opencl.
Но лидерство nvidia, наконец, подходит к концу, и даже их аморальная антиконкурентная практика их не спасет. С впечатляющим автопереводчиком Cuda HIP (https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
Грядущие vega apus, dgpus и ARM, которые появятся в Windows, у Nvidia нет будущего, поэтому отрасли НЕОБХОДИМО поддерживать opencl/syCL/HIP/HSA очень скоро и массово.

Как насчет слайда 40 из https://autodiff-workshop.github.io/slides/JeffDean.pdf?

Здравствуйте, я планирую, что тензорный поток будет поддерживать новый AMD Radeon Instinct? (http://instinct.radeon.com/en-us/)

Привет, есть ли прогресс в поддержке TF-OpenCL для ПЛИС?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 был удален несколько месяцев назад, и дорожная карта Streamexecutor не ясна.

@bhack спасибо за быстрый ответ
Значит ли это, что поддержки нет, или корректная работа не гарантируется?
Кроме того, из того, что я прочитал в этой теме, я вижу, что тесты в основном проводятся на графических процессорах AMD ... кто-нибудь тренирует сети на графических процессорах Nvidia с этим портом OpenCL?

Streamexecutor был переименован в LLVM parallel-libs и теперь называется acxxel.

Может ли кто-нибудь из участников Google объяснить разницу и планы действий между streamexecutor и https://reviews.llvm.org/rL285111?

CC @zheng-xq

@henline и @jlebar — эксперты, которые ответят на вопрос о разнице между streamexecutor и https://reviews.llvm.org/rL285111?

Axcell и StreamExecutor — это отдельные проекты. В настоящее время нет планов по их объединению. Я оставляю на усмотрение разработчиков TensorFlow решение о том, планируют ли они переходить на него.

Так что же, StreamExecutor и StreamExecutor llvm не были одними и теми же проектами?

Правильно, это не один и тот же проект.

В четверг, 16 марта 2017 г., в 11:06, [email protected] написал:

Так что же, StreamExecutor и StreamExecutor llvm не были одними и теми же проектами?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar В следующий раз творческая единица для именования;) но, вероятно, это было не отсутствие мотивации к творчеству, а просто восходящее усилие внутреннего инструмента, который расходился с тем, который поддерживается в TF ..

@bhack , мы изменили имя именно тогда, когда поняли, что изменили
не думаю, что имело смысл полностью перемещать StreamExecutor в LLVM. Это
теперь называется «Acxxel».

Прошу прощения за путаницу, и я ценю обратную связь.. Это было
процесс обучения однозначно.

В четверг, 16 марта 2017 г., в 11:24, [email protected] написал:

@jlebar https://github.com/jlebar В следующий раз креативный блок для именования
;) но, вероятно, это было не отсутствие мотивации к творчеству, а просто
восходящее усилие внутреннего инструмента, расходившегося на поддерживаемый
в ТФ..

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Да, у меня все еще есть небольшая путаница между StreamExecutor, SyCL в eigen, XLA (который на самом деле имеет только бэкэнд CUDA, кроме CPU и opencl на некоторых слайдах)

Удар

Кто-нибудь в Google говорил с Apple или AMD, чтобы облегчить это? Я предполагаю, что люди AMD настолько потеряны, что даже не знают, что проблема существует, и они все еще задаются вопросом, почему у Nvidia такая огромная доля рынка. Я также думаю, что команда Apple AI была бы более чем счастлива помочь здесь ... если бы OpenCL не был заброшенным программным обеспечением с их стороны с 2013 года и, что еще хуже, их боссы не злились бы на Google.

Что нового по этому поводу?

Согласно примечаниям к выпуску TF 1.1 , поддержка Mac GPU (только Nvidia) устарела. Будем надеяться, что это поможет улучшить подход OpenCL (не очень уверен в этом).

Вы также можете следить за статусом PR https://github.com/tensorflow/tensorflow/pull/9117 .

Спасибо! Я слежу за этой проблемой в течение последних месяцев. Я не уверен в приверженности Apple OpenCL, учитывая, что они застряли на OpenCL 1.2 с 2013 года (Apple пока не предоставляет поддержку SPIR 1.2).

Если TensorFlow на OpenCL поможет вам в вашей работе, дайте мне знать, насколько я могу помочь продвинуть исследования и практику глубокого обучения, в чем я хотел бы помочь. Моя компания создала серверную часть OpenCL для TensorFlow, настроенную для различных графических процессоров, в рамках нашей работы по логическому выводу на устройстве. Мы протестировали основные семейства графических процессоров для мобильных и настольных компьютеров, включая распространенные конфигурации для Windows и Mac. Если будет достаточный интерес, мы можем организовать публичное распространение. У нас также есть Metal (Apple GPU) и LLVM (CPU), а также способ развертывания с нулевой зависимостью. Идея здесь в том, чтобы дать каждому устройству отличную поддержку глубокого обучения.

@choongng - все это звучит невероятно полезно и полезно. Мой личный проект https://github.com/Synopsis/ значительно выиграл бы от OpenCL на OS X, а также от развертывания Metal для iOS и рабочего стола. Если это возможно, чтобы это было введено в Tensorflow, я думаю, это было бы огромным благом для множества разработчиков.

Спасибо.

@чуннг

Если ваша компания опубликует версию OpenCL или, что более интересно, версию TensorFlow для Metal, я думаю, что это станет отличной новостью для многих людей, я нахожусь в процессе создания eGPU с картой NVidia, чтобы получить TensorFlow. / Keras работает на моем MBP для моей работы...

Кому интересно... зайдите в сообщество eGPU.io

@чуннг

Мне было бы очень интересно это увидеть, поэтому я был бы очень признателен, если бы вы продолжили это! Особенно, если для этого не требуются схематичные компиляторы с закрытым исходным кодом, которые TF выбрала для поддержки CL.

26 апреля 2017 г., 03:33:51 по Гринвичу + 01:00, Чун Нг уведомления[email protected] написал:

Если TensorFlow на OpenCL поможет вам в вашей работе, дайте мне знать,
насколько я могу помочь продвинуть исследования и практику глубокого обучения, я бы
нравится помогать. Моя компания создала серверную часть OpenCL для TensorFlow.
настроены для различных графических процессоров в рамках нашей работы над инференсом на устройстве.
Мы протестировали основные семейства графических процессоров для мобильных и настольных ПК, включая
общие конфигурации на Windows и Mac. Если есть достаточный интерес, мы
может сделать какое-то публичное распространение. У нас также есть Metal (Apple GPU)
и LLVM (CPU), а также способ развертывания с нулевой зависимостью. То
Идея заключается в том, чтобы дать каждому устройству отличную поддержку глубокого обучения.

--
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-297220160

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

Я думаю, что это было бы революционно;)

@choongng Может быть, это поможет, если вы объедините усилия с этими парнями
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey , какой компилятор с открытым исходным кодом вы предлагаете использовать? Трудно найти решение с открытым исходным кодом, совместимое с OpenCL, для работы с большим количеством устройств в дикой природе...
В какой-то момент нам нужно как-то загрузить решение...

Я не говорил, что это легко исправить. Но проблема не в OpenCL. В конце концов, CUDA полностью проприетарна, намного хуже, чем даже вариант OpenCL, который выбрал TensorFlow.

Тем не менее, есть варианты для системы CL или cuda, если вы начинаете с нуля, включая переносимые среды выполнения промежуточного программного обеспечения или arrayfire и т. Д. Однако Tensorflow слишком привязан к CUDA.

Меня расстраивает, что люди хотят писать ядра на CUDA, но отказываются делать это для CL, даже если это охватит больше пользователей и серьезно расширит рыночную экосистему. У открытой платформы есть прямые и косвенные преимущества для всех, что в долгосрочной перспективе может привести к значительной экономии средств для всех.

Если SYSCL — это то, как это в конечном итоге происходит, отлично: так почему же некоторые громкие имена не вкладывают деньги в открытый дистрибутив SYSCL вместо того, чтобы покупать маргинальные проприетарные варианты, которые как бы противоречат цели открытого стандарта?

28 апреля 2017 г., 09:13:06 по Гринвичу + 01:00, Ронан Кериелл ( [email protected] ) написал:

@cathalgarvey , какой компилятор с открытым исходным кодом вы предлагаете использовать?
Трудно найти решение с открытым исходным кодом, совместимое с OpenCL, для
обращаться к множеству устройств в дикой природе...
В какой-то момент нам нужно как-то загрузить решение...

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-297936468

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

В связи с этим я хочу спросить следующее:

Поэтому некоторые фреймворки глубокого обучения, такие как Tensorflow, несколько вяло изучают использование opencl в качестве альтернативы CUDA. Конечно, CUDA — это просто «язык», на котором была разработана cuDNN, и это (если я правильно понимаю) то, что на самом деле использует большинство языков глубокого обучения. В этом контексте я не уверен, что такое opencl-версия cuDNN.

Также AMD говорит об альтернативах CUDA с открытым исходным кодом, которые они постоянно разрабатывают и называют rocM. Они также говорят о том, что miOpen будет эквивалентом cuDNN (библиотеки ассемблера ручной работы для общих функций глубокого обучения), которые, однако, еще не выпущены. Подход AMD несколько более целостный: мы не просто переносим тяжелые вычисления на GPU.

В этом контексте я искренне запутался. Как усилия opencl, подобные перечисленным выше, сочетаются друг с другом? Для графических процессоров NVIDIA это просто... есть CUDA, а есть cuDNN, написанный на CUDA. Для не-NVIDIA / или, в данном случае, AMD, это кажется гораздо менее ясным. Когда HIP предпочтительнее? Когда предпочтительнее использовать HCC? Когда предпочтительнее использовать opencl? Любые идеи будут действительно оценены!

@cathalgarvey за всеми этими огромными программно-аппаратными инфраструктурами стоит много политики... :-(
Даже если мы можем мечтать о решении с чистого листа, основанном на чисто научных критериях, я думаю, мы должны быть прагматичными.
Google не хочет слишком сильно менять архитектуру TensorFlow. Вот почему архитектура на основе OpenCL должна быть очень похожей, требуя C++ с одним исходным кодом, такого как «среда выполнения CUDA», вместо решения OpenCL C более низкого уровня без единого исходного кода. В сфере Khronos версия OpenCL для C++ с одним исходным кодом называется SYCL.
Давайте обсудим это, когда вы, например, заедете в Дублин, так как вы тоже собираетесь жить в Ирландии. :-)
А пока не стесняйтесь вносить свой вклад в https://github.com/triSYCL/triSYCL и ветки TensorFlow и Eigen, связанные с SYCL...

@keryell Знаете ли вы, планируется ли также XLA:GPU :OpenCL на SyCL?

Привет @benoitsteiner по поводу:

В специальном разделе OpenCL в общей документации TensorFlow. Это будет опубликовано на сайте tensorflow.org в ближайшее время.

Я выполнил поиск на tensorflow.org для OpenCL и, похоже, не смог найти ничего существенного, все это, кажется, указывает прямо здесь. Под "скоро" вы имеете в виду до ______? ( _вставьте сюда смешной сарказм_ ).

Мне удалось скомпилировать ваш репозиторий (ура!), хотя я предполагаю, что для создания рабочего Tensorflow OpenCL для Mac требуется что-то еще; Я попытался собрать упомянутый компилятор triSYCL , но, к сожалению, потерпел неудачу.

@bhack Поскольку я не работаю в Google, я понятия не имею о деталях XLA...

@dylib, к сожалению, все это находится в стадии разработки ...

@keryell Да, я знаю .. Мне просто любопытно, обсуждалось ли это на каких-то встречах.

OpenCL радикально отличается от CUDA. Однако я бы определенно хотел, чтобы это было перенесено на HIP.
Так что +1 Всем, кто это предложил.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

HIP позволяет разработчикам преобразовывать код CUDA в переносимый C++. Тот же исходный код может быть скомпилирован для работы на графических процессорах NVIDIA или AMD.

Мало кто знает о HIP.
Вы можете найти больше информации о tensorflow и HIP здесь:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
а также
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Примечание:
Я не думаю, что мы должны бороться / хвастаться Nvidia против AMD. Это респектабельные компании, которые производят потрясающее аппаратное и программное обеспечение. Вместо этого мы должны сосредоточиться на предоставлении tensorflow более широкой пользовательской базе.
Ориентация на множество языков с помощью привязок уже является хорошей отправной точкой, но нам также необходимо ориентироваться на как можно больше аппаратных средств. (Даже если облачные решения потрясающие, они не всегда являются решением)

У нас есть опыт работы с HIP здесь, в Stream. Разреши мне взглянуть.

Согласен с аргументом "моя компания лучше". Я хотел бы знать, на какие графические процессоры должен ориентироваться TensorFlow. Он должен быть прагматичным и полезным. Например, графические процессоры Intel или встроенные графические процессоры (Qualcomm, ARM, Imagination), RaspBerry Pi — да или нет?

AMD Radeon Vega Frontier Edition

Мы продолжаем активно улучшать нашу открытую программную платформу ROCm и библиотеки машинного обучения. Мы также поддерживаем открытые платформы искусственного интеллекта, такие как Caffe (выпущена в апреле). Позже в этом квартале мы планируем предложить поддержку Torch, а Tensor Flow находится в разработке.

Они уже выпустили Caffe, было бы очень интересно услышать, как другие в этой ветке делятся своим опытом сборки/тестирования:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Я начал установку, но столкнулся с препятствием, когда все, что требует CL, просто зависает, даже clinfo . Не уверен, что это из-за какой-то проблемы с программным обеспечением или моя карта (R9 390) просто не поддерживается ROCm.

17 мая 2017 г., 15:18:32 GMT+01:00, Брайан Ли, [email protected] , написал:

AMD Радеон Вега ФронтирВерсия

Мы продолжаем активно улучшать нашу открытую программную платформу ROCm.
и библиотеки машинного обучения. Мы также поддерживаем открытую машину
интеллектуальные фреймворки, такие как Caffe (выпущен в апреле). Позже это
квартале мы планируем предложить поддержку Torch, а Tensor Flow находится в
работы.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-302103815

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

@cathalgarvey Я использую ветку Caffe OpenCL на графических процессорах AMD, и она работает отлично. make run test прошли все тесты, кроме одного

Рад слышать; могу я спросить о вашей установке HW/SW? Например, какая у вас карта
с помощью, какой дистрибутив / версия Linux и т. д.?

Раньше у меня был AMDGPU-pro, но я удалил его при установке ROCm.
Возможно, мне мешает какая-то наследственная вещь.

--
@onetruecathal / @ [email protected]

В среду, 17 мая 2017 г., в 15:50, Брайан Ли, [email protected]
написал:

@cathalgarvey Я использую ветку Caffe OpenCL на графических процессорах AMD и
это работает просто отлично. make run test прошел все тесты, кроме одного

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@cathalgarvey

• Ветка Caffe OpenCL (протестированный коммит c61d48746b2df1d237c64abc7416342ce98f3251 )
• ОС: Ubuntu 16.04.2 LTS
• Протестировано на Polaris (RX460), Fiji (Fury X) и Tonga (W7100).
• Драйвер: Драйвер AMDGPU-Pro для Linux 16.40 или выше
• ВенаCL
• Общие зависимости: 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 ..

Да, в дополнение к ветке OpenCL, описанной выше, naibaf7 опубликует книгу (очень скоро) по ее использованию для логического вывода в реальном времени на обычном оборудовании с графикой AMD и HD.

Ах; Я говорил о hipCaffe, а не о ветке OpenCL:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Установка ROCm для сборки/тестирования hipCaffe потребовала удаления
AMDGPU-pro, пожалуй, еще раз попробую ванильную ветку. это плохо
задокументировано, к сожалению.. Попробую вслепую "сделать" и посмотреть.

Итак, мне все еще интересно узнать об опыте других пользователей с AMD.
стек ROCm/HIP; если они работают над форком Tensorflow, это было бы здорово,
при условии, что он действительно работает более чем на 3/4 моделей карт AMD в
дикий.

--
@onetruecathal / @ [email protected]

В среду, 17 мая 2017 г., в 16:09, Брайан Ли, [email protected]
написал:

@cathalgarvey

Ветка Caffe OpenCL (проверенная фиксация
c61d48746b2df1d237c64abc7416342ce98f3251)
ОС: Ubuntu 16.04.2 LTS
Протестировано на Polaris (RX460), Fiji (Fury X) и Tonga (W7100).
Драйвер: Драйвер AMDGPU-Pro для Linux 16.40 или выше
ВенаCL
Общие зависимости: libprotobuf-dev libleveldb-dev libsnappy-dev
libopencv-dev libhdf5-serial-dev компилятор protobuf libatlas-base-dev
libblas-dev libgflags-dev libgoogle-glog-dev liblmdb-dev
libboost-all-dev cmake git python-numpy cmake
—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@cathalgarvey Я надеюсь, что они работают над модным бэкендом, а не над полным форком. Это было бы грустно и только разделяло бы рабочие усилия.
Инструментов уже достаточно :/

@YvanDaSilva Усилия AMD на данный момент немного плохо скоординированы (да, все форки). Кроме того, похоже, что он пока не работает так хорошо на большом количестве устройств, в отличие, например, от ветки OpenCL Caffe...

@naibaf7 Я абсолютно согласен.
Честно говоря, кадров им действительно не хватает, они работают по всем фронтам.
Кстати: не знал, что в ETH есть нейроинформатика ;) здорово!

@cathalgarvey Можете ли вы рассказать о стеке ROCm / HIP для непрофессионала, такого как я. Я играл в AMGPU-pro и AMDGPU со своими картами Sea Island, поэтому уверен, что смогу опубликовать некоторые полезные результаты.

@ИванДаСильва
Они спонсировали мой первоначальный проект Caffe OpenCL и, к сожалению, плохо координировали свои действия, поэтому исследования AMD и независимый сотрудник AMD также параллельно работали над портами OpenCL — бывшая исследовательская группа AMD сейчас распущена, и большинство из них на самом деле работают на Tesla ( проект самоуправляемого автомобиля) теперь... так что неудачная цепь событий.
Я все еще сотрудничаю и контактирую с ними. Веге будет интересно :)

@naibaf7 Хорошо , тебе повезло! Жаль, что не было таких исследований, когда я был в Heig-vd, конечно, продолжил бы MSc.

Да... Я так и думал. Так много работы, так мало человеческих ресурсов в этих областях.

Все это звучит здорово, но давайте переориентируем обсуждение на то, чтобы TensorFlow работал с OpenCL SYCL, а не только с решениями для конкретных поставщиков... :-)
Я надеюсь, что у RoC и других HiP есть собственный GitHub для обсуждения своих проблем...
@naibaf7 : по крайней мере, я все еще в сфере OpenCL. Вступай в клуб снова! :-)

@keryell Я думаю, что обсуждение HIP уместно, если в разработке находится HIP-порт для Tensorflow. В конце концов, официальное решение Tensorflow-on-CL заключается в использовании проприетарного фреймворка SYCL с резко ограниченной поддержкой платформы и ядра, поэтому на самом деле оно ничем не лучше, чем решения HIP «от производителя», которые предлагают новый выход из CUDA.

HIP может быть в основном AMD делает прямо сейчас, но AFAIK это открытый стандарт? Возможно, я ошибаюсь. Если это так, и если AMD сможет предоставить порт tensorflow-on-HIP, он сразу же станет более открытым, чем официальный порт tensorflow-on-SYCL.

HIP — это подмножество CUDA, поэтому оно такое же открытое, как и CUDA.

Хорошо; HIP-the-API является подмножеством CUDA-the-API, но если NVidia не будет достаточно трусливой, чтобы начать направлять Oracle, я сомневаюсь, что это будет проблемой. Я имел в виду среду выполнения / компиляторы для HIP, из которых, я думаю, AMD ~ открыты.

edit : Извините, если вышеизложенное прозвучало грубо; просто пытаюсь прояснить мою позицию выше!

Будут ли объединены Vulkan и Opencl ?

Согласно Reddit AMA Раджи, Vega будет поддерживать Tensorflow, Cafe2, Cafe, Torch7 и MxNet через MIOpen.

@cathalgarvey обсуждение явно актуально, но не здесь ...
Вы здесь, на GitHub, обсуждаете перенос TensorFlow и Eigen с использованием стандартов Khronos Group.
Это не Твиттер и не ваша стена в Фейсбуке... :-)
Поэтому, пожалуйста, внесите свой вклад в эти проекты! :-)

Существует новая версия руководства по установке для компиляции TensorFlow с ComputeCpp, реализацией SYCL от Codeplay, чтобы можно было использовать устройства OpenCL. Мы будем признательны за любой отзыв, который вы можете дать нам по этому поводу. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

Вы хоть представляете, каков процент успеха, чтобы заставить это работать на непроверенном графическом процессоре AMD? Меня особенно интересует, тестировалось ли оно для AMD Radeon Pro 460 @rodburns. Я был бы рад потратить несколько часов на запуск Ubuntu на моем ноутбуке Macbook, если есть надежда на непроверенный графический процессор.

@samhains мы не проверяли это, но вы можете попробовать. Вам нужно будет использовать некоторые старые драйверы AMD с Ubuntu, которые поддерживают расширение SPIR. Я еще не смог выяснить, что это за драйверы.

@samhains Если маршрут кодового воспроизведения не работает, не пропустите tf-coriander , который, наконец, находится в состоянии практического использования в Ubuntu / Mac.

В настоящее время я тестирую его на консетях, двунаправленных rnns и т. д., и все работает отлично. Он работает на «ванильном» OpenCL 1.2, поэтому должен включить Tensorflow на огромном диапазоне относительно старого оборудования.

На данный момент загвоздка в том, что он основан на Tensorflow 0.11.

@родбернс. Я попытался выполнить шаги, перечисленные в ссылке https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp .
Я получаю следующую ошибку:
ОШИБКА: /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD: 609 : 1: необъявленные включения в правило '@protobuf//:python/google/protobuf/internal/_api_implementation.so ':
На самом деле я получаю ту же ошибку, если пытаюсь скомпилировать тензорный поток из исходного кода. Я скомпилировал его ранее, хотя не уверен, что изменилось.

@rahasayantan что это входит? А вы получаете это при компиляции без --config=sycl ?

@lukeiwanski : Насколько я понимаю, проблема в том, что Bazel пытается скомпилировать Protobuf, но не находит и не загружает подкаталоги. Я сделал тягу с рекурсивным подмодулем, но у него те же проблемы. И у него такая же проблема без --config = sycl. На самом деле я сталкиваюсь с той же проблемой, когда делаю git pull из основного проекта tensorflow. Я не думаю, что это связано с openCL, это некоторые проблемы с тем, как я делаю тягу. Когда я вручную загружаю zip-файл проекта из вашего репозитория без git и компилирую, он компилируется правильно, но затем я получаю ошибку сегментации. Я уже поднимал этот вопрос в вашем проекте GIT, и мы говорим там, я дам обновления, связанные с ошибкой сегментации в этом потоке (нет смысла дублировать вещи). Спасибо за ваш ответ.

Прибытие triSYCL с открытым исходным кодом. См. https://github.com/triSYCL/triSYCL/pull/45 .

Я здесь новенький. Очень заинтересован в том, чтобы TF поддерживал OpenCL. Как я могу получать обновления из этой темы?

эммм... Интересно, а зачем? Я имею в виду, почему Tensorflow сначала выбирает cuda, а opencl? Какая-то коммерческая причина, я думаю?

Привет @tensorflower-садовник,

@hughperkins создал Coriander , который может запускать код NVIDIA® CUDA™ на устройствах OpenCL 1.2. Возможно, вы захотите взглянуть, подходит ли вам это для подключения TF к устройствам OpenCL 1.2. Пожалуйста, укажите его имя и его вклад в случае, если вы планируете использовать его работу.

Кажется, что надежды когда-либо увидеть OpenCL поддержку Mac уменьшились с небольшой до tf.zero . Я только что прочитал, что TensorFlow Mac больше не будет поддерживать ЛЮБОЙ графический процессор (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 тестируется на Mac, поэтому, если/когда он достигнет паритета версий, вы сможете его использовать.

22 июня 2017 г., 11:46:51 по центральноевропейскому летнему времени, [email protected] написал:

Похоже, что надежды когда-либо увидеть поддержку OpenCL для Mac исчезли.
немного до tf.zero . Я только что прочитал, что Маков там больше не будет
Поддержка ЛЮБОГО графического процессора (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

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-310331281

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

Грустно, потому что теперь с eGPU и n Nvidia 980 Ti внутри у нас работают драйвер и Cuda.

У меня пока не было времени попробовать Tensor Flow в моей конфигурации.

webdriver и набор инструментов Cuda, установленные на моем компьютере, и образцы Cuda работают хорошо

https://youtu.be/JN9fDmqf010

@cathalgarvey , вы сказали, что тестируете коннеты на tf-coriander, но похоже, что коннеты пока не работают. Не могли бы вы уточнить, удалось ли вам запустить коннеты на графическом процессоре с помощью tf-coriander?

К вашему сведению,
https://github.com/tensorflow/tensorflow/issues/10703

Почему тензорный поток больше не поддерживает графические процессоры в OS X? Я планировал использовать Tensorflow с настройкой eGPU, которую я заказал.

@justinrmiller утверждают, что больше не могут тестировать его на mac os, и поэтому решили прекратить поддержку. однако, мне трудно в это поверить. В будущем с рекламой egpus на high sierra и с новыми драйверами nvidia этого больше не будет.

@tscholak да точно. Я собирался использовать свой новый корпус egpu, чтобы навсегда избавиться от оконной коробки.

Имея в виду, что, хотя карты Nvidia работают в корпусах eGPU, Apple будет официально поддерживать только RX580 в своем наборе для разработки, поэтому потребность в OpenCL не исчезнет.

OpenCL на Mac — 1.2, что означает отсутствие активного драйвера.
разработка. Я думаю, что добавление поддержки Metal в TF — это кропотливый процесс.
(включение Eigen и потокового исполнителя), но выполнимо.

Вс, 16 июля 2017 г., 15:17 Фердия МакКеог, [email protected]
написал:

Имея в виду, что, хотя карты Nvidia работают в корпусах eGPU, Apple
будет официально поддерживать только RX580 в своем комплекте разработчика, поэтому необходимость
OpenCL не исчезнет.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Мне очень грустно из-за отказа от поддержки GPU для macOS.

Все еще ищу поддержку OpenCL для графического процессора в macOS, потому что Apple, очевидно, не перейдет на графические процессоры Nvidia в ближайшее время.

Tensorflow — мой любимый движок. Использование GPU-ускорения локально на моем MacBook Pro или будущем iMac Pro было бы здорово.

Для Microsoft имело бы смысл саботировать Apple, но поскольку у Google нет десктопной ОС, они только вредят себе.

Честно говоря, кто-то более умный, чем я, должен изучить интеграцию Mac OS 10.13 MPS — Metal Performance Shaders, которые имеют поддержку большого набора примитивов нейронной сети из коробки. Это позволит использовать современные высокопроизводительные графические процессоры для мобильных и настольных iOS и macOS для развертывания логического вывода Tensorflow.

Вы не можете тренироваться с примитивами Apple, насколько я понимаю (они ничего не предоставляют), но с поддержкой Tensorflow, возможно, вы могли бы? Я думаю, что для людей на платформе Apple это было бы благом.

Я не думаю, что Google предоставит это внутри компании, и у меня нет необходимых навыков, чтобы попробовать это сделать самому. Публикую эту идею, чтобы ее могли реализовать более талантливые люди, чем я.

:)

Apple нацелена исключительно на продажу устройств Apple. Google нацелен на найм крупных сервисов Google.

Если вы хотите заниматься искусственным интеллектом (обучением) с помощью одного устройства, например, одного ноутбука Apple, вы будете заниматься «поверхностным обучением» вместо «глубокого обучения», поэтому вам лучше отказаться от всего, кроме учебных пособий. Вывод результатов в обученной модели для одного пользователя, на одном устройстве (даже на не слишком многоядерном телефоне) может быть аккуратно выполнен с помощью графических процессоров, но вполне выполним только с центральными процессорами.

С другой стороны, графические процессоры абсолютно необходимы, если вы собираетесь передавать очень большие наборы данных для обучения или вы собираетесь предоставлять обученный вывод чрезвычайно большим одновременным группам клиентов.

Хотя сделать это в таком масштабе не так просто из-за проблем с сетью. Просто взгляните на физическую архитектуру TPU-Pods. Это антипод ноутбука (несколько графических процессоров на перегруженный памятью многоядерный сервер с выделенным оптическим волокном для связи между серверами).

У меня Макбук Про. Это хороший терминал для доступа к облаку :-D

Я вижу, что TF on Metal можно распространить и на iOS. Если кто-то заинтересован в этом, я рекомендую сначала добавить поддержку Metal в Eigen (можно использовать OpenCL в качестве справки).

@rogerpasky В школе мне пришлось использовать Tensorflow для обучения моделей, а не только для оценки модели. И мне придется повторить это снова в ближайшее время. Для таких студентов, как я, обучение работе с графическим процессором является обязательным, что экономит много времени. Это не просто вопрос обслуживания нескольких одновременных пользователей.

@rogerpasky — это возможность разрабатывать модели и решения локально на Mac.

@rogerpasky с уважением не согласен. В то время как облачные решения с несколькими графическими процессорами отлично подходят для интернет-сервисов, я ориентируюсь на профессиональные конвейеры видеопроизводства, где логические выводы выполняются на часах и часах Pro-Res и несжатых кадров HD, 2K, 4K, что а) ни одна производственная компания собираются загрузить в облако, б) они не хотят, чтобы Google или кто-то еще имел их данные, в) у них есть комнаты, заполненные системами с поддержкой нескольких графических процессоров (Mac и Windows), которые они хотели бы использовать локально, и г) в то время как вывод на одном изображении в порядке на ЦП, запуск целых фильмов для вывода по нескольким графикам на 100% показывает увеличение производительности с использованием чего-то вроде MPS по сравнению с ЦП. Поскольку сообщество отказалось поддерживать/принимать стандарты и вместо этого использует только код Nvidia, примеры использования в реальном мире отсеиваются, и это действительно позор.

Это не праздный запрос от кого-то, кто является любителем, проводящим учебные пособия — вывод GPU важен, как и поддержка различных семейств GPU/CPU для различных рабочих нагрузок на реальном оборудовании. Я действительно надеюсь, что Google отнесется к этому серьезно, потому что было бы здорово иметь возможность придерживаться одной библиотеки, такой как TF, и это здорово.

Спасибо, что выслушали меня, я не пытаюсь разглагольствовать, а предлагаю альтернативную точку зрения сообществу.

@pldelisle , @tscholak , @vade пожалуйста, не поймите меня неправильно. Я хотел бы иметь его, и если вы будете искать в этой ветке, я присоединился как сторонник, но, насколько я следил за этим, я пришел к выводу, который я написал, не только потому, что я так думаю (я думаю, MacBook бы расплавился, если бы его обучали тысячам видеороликов :-D), но с реальными фактами из отрасли. Не ждите, что проблема будет решена в короткие сроки (ИМХО, она никогда не будет решена, потому что Apple и Google ненавидят друг друга с момента выпуска iPhone/Android).

@rogerpasky Уже была поддержка графических процессоров nvidia в Mac OS. Его просто убрали в 1.2.

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

Я отменил свой заказ на eGPU (Sonnet) и просто буду использовать Linux с двойной загрузкой на своей игровой машине, но это довольно плохо — просто прекратить поддержку того, что люди использовали. Я действительно надеялся сделать это на своем Mac с eGPU (обучение модели), но я думаю, что сейчас этого не произойдет: https://github.com/lengstrom/fast-style-transfer

@rogerpasky Э- э, вы знаете, что CoreML поддерживает импорт моделей тензорных потоков через Keras? Apple не «ненавидит» Google, бизнес есть бизнес. Одним из поставщиков Apple является Samsung. Прочтите это на мгновение. Google, Apple, Samsung — это компании, и они будут делать то, что приносит деньги. В качестве примечания. Между прочим, мой MacBook Pro не растаял после обработки тысяч фильмов. Я подозреваю, что CUDA было очень удобно внедрять, а постоянная поддержка со стороны Nvidia и упущенные возможности со стороны AMD привели нас туда, где мы есть. Я не думаю, что это гнусно, просто стоимость внесения изменений по сравнению с дельтами производительности по сравнению со стоимостью сохранения курса.

Я подозреваю, что какой-нибудь гений придет, чтобы помочь решить проблему.

Я создал группу Google для совместной дискуссии о внедрении глубокого обучения в новые места, такие как OpenCL, Mac, iOS, CoreML, Vulkan и т. д. Если вы хотите помочь в этом, присоединяйтесь и разместите заметку с вашим использованием. случай или над какой частью проблемы вы работаете. Уже есть люди, которые очень усердно работают над переносом TF на большее количество платформ, включая MIOpen, работу Codeplay, TF-Coriander и внутренний проект в моей компании (Vertex.AI). Было бы здорово собрать разработчиков и пользователей в одном месте, поскольку все эти усилия тесно связаны между собой.

https://groups.google.com/forum/#!forum/глубокое обучение-везде

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

@justinrmiller У меня есть eGPU на Sierra (Titan Xp в корпусе Sonnet), на котором работает Tensorflow 1.2.1 (CUDA 8, cuDNN 6), что не составило особых проблем, если вы не возражаете против сборки с нуля. Если у вас есть какие-либо проблемы, дайте мне знать.

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 Это потрясающе! Спасибо за информацию!

@danbarnes333 danbarnes333 как вы заставили tf 1.2 собраться с cuDNN 6? Вы использовали LLVM? ССЗ? Мне удалось собрать его только с помощью cuDNN 5...

К вашему сведению, https://machinelearning.apple.com/

@tscholak Я не буду публиковать это здесь, чтобы сохранить это в OpenCL, но я кратко изложу шаги здесь .

@choongng Я присоединился к группе Google, но там тихо. Так что я буду разглагольствовать здесь ;-)

1. Машинное обучение/высокая производительность/вычисления на GPU — это рынок с жесткой конкуренцией. NVidia, нравится вам это или нет, доминирует на рынке и держит свои карты и программное обеспечение близко к жилетке. Если у вас есть бюджет и крайний срок, вы более или менее привязаны к NVidia.

2. У меня есть старенькая карта AMD ("Bonaire") и нулевой бюджет - любитель. Вчера у меня caffe работало с проприетарной реализацией AMD OpenCL 2 в Arch Linux, и сегодня утром я получил MIOpen от AMD с открытым исходным кодом. Это позволит мне обучить несколько моделей; Bonaire достигает пика около 1800 GFLOPS с одинарной точностью. Поэтому, если TensorFlow не будет работать с OpenCL на Бонайре, я не буду использовать TensorFlow.

3. Если бы волшебным образом появился бюджет, я бы купил процессор Intel и карту NVidia и запускал проприетарное программное обеспечение, поддерживаемое поставщиком. Я закончил заниматься бесплатным контролем качества для таких поставщиков, как Google, Red Hat, Canonical и AMD.

   Мне потребовалось три месяца (и три дистрибутива — Fedora 25, Ubuntu 16.04 LTS и Arch), чтобы получить что-то от графического процессора, который у меня был в течение трех лет. В системе отслеживания ошибок Fedora есть неисправленные ошибки с моим именем. То же самое касается Ubuntu и Freedesktop.org. Большинству людей, которые бы их чинили, либо не платят, либо платят за что-то другое.

   Да, новые процессоры AMD впечатляют, и да, большая часть их программного обеспечения имеет открытый исходный код, но бюджеты и сроки меняют ситуацию. Поддержка имеет ключевое значение. Поддержка решает все!

@znmeb Я даже не знал, что вы можете использовать оборудование до GCN для TF.
С моим Tahiti у меня есть поддержка только одного дистрибутива (ubuntu 14.01.x), поскольку проприетарные драйверы AMD работают только со старыми ядрами Linux для GCN1. (Я получаю TF + openCL через SYCL (не проверено на 7970))

Там, где я работаю, весь отдел исследований и разработок возглавляет зеленую команду. У всех есть докторские степени, и все, кроме ни одного, не написали ни строчки cuda (ни OCL). Но инструменты здесь, чтобы ускорить их рабочую нагрузку Keras . Я немного чудак со своими переработанными графическими процессорами для майнинга, пытаясь выжать из них вторую жизнь.

tl; dr, кроме поддержки зеленой команды, появится только в том случае, если появится доля рынка графических процессоров AMD.
Это проблема курицы и яйца. Я возлагаю надежды на вегу… но да… не убийца 1080Ti.

@acoye FWIW, вот пост на GitHub, который заставил меня пойти в эти выходные после того, как я начал гуглить с апреля: https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . См. также https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . Это была моя первоначальная проблема — попытка использовать мой Bonaire для ускорения линейной алгебры на R.

@акойе
Вы можете перейти на последние дистрибутивы Linux и использовать свежее специально скомпилированное ядро, такое как 4.11/4.12, с включенными драйверами AMDGPU, отключенным RADEON и с установленными CONFIG_DRM_AMDGPU_SI=Y и/или CONFIG_DRM_AMDGPU_CIK=Y в конфигурации ядра, плюс прошивка AMD для 7970 (Tahiti) в initramfs => новейшая AMDGPU-PRO OpenCL будет работать на любых картах GCN. Забудьте о FGLRX (в старых дистрибутивах Linux) и Clover через драйверы RADEON, оба они не на должном уровне.
Забудьте также о картах до GCN. Я тестировал их с помощью OpenCL на Windows для Caffe, производительность не стоит усилий для таких старых карт. Поскольку все карты AMD после 2012 года в любом случае должны быть GCN.

@naibaf7 Вчера я потратил несколько часов, пытаясь заставить работать стек AMD с открытым исходным кодом. У меня есть MIOpen и его зависимости, но hcc все еще отсутствуют некоторые биты. Мне может понадобиться сделать собственную сборку ядра, чтобы получить все. Меня не очень волнует портирование кода CUDA или запуск скомпилированного C++ на графическом процессоре — я хочу обрабатывать его числами. ;-)

Я также видел на их веб-сайте кое-что о программировании на ассемблере , что может меня заинтересовать, потому что легко перейти с ассемблера на FORTH. ;-)

@znmeb Да, я также пытаюсь заставить некоторые вещи MIOpen и TensorFlow работать на моем RX 480, но я не хочу разрушать свою основную установку для разработки, поэтому вместо этого я использую виртуализацию IOMMU и использую виртуальную машину Ubuntu 16.04, которая может использовать RX 480. Драйверы AMD очень хорошо подходят для виртуализации (в отличие от драйверов nVidia для игровых карт - только драйверы Quadro).

@znmeb Все, что тебе нужно сделать, это sudo apt-get install rocm miopen-hip

@adityaatluri Он находится в пользовательском репозитории Arch, но не устанавливается — он также не устанавливается из исходного кода GitHub. Похоже на что-то простое - не может найти несколько зависимостей.

@znmeb Можете ли вы создать задачу здесь (https://github.com/RadeonOpenCompute/ROCm/issues), чтобы мы могли обсудить ее там? Спасибо!

@adityaatluri Конечно, я иду на ужин, но я зарегистрирую его, когда вернусь

@ebrevdo Есть ли способ использовать графический процессор tensorflow на Mac с процессором AMD?

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

Моя компания некоторое время работала над глубоким обучением OpenCL, и у нас есть первые результаты, которые можно показать. В ближайшем будущем мы сосредоточимся на Keras, однако мы также создали (очень) экспериментальную поддержку TensorFlow и вернемся к ней после нашего первоначального выпуска. Подробнее здесь, включая начальные показатели пропускной способности AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl

Прохладный!

Крошечная придирка: AFAIK, MIOpen не специфичен для AMD, так как он может ссылаться как на OpenCL, так и на ROCm. Последний, вероятно, быстрее, но все же; MIOpen — это огромный шаг вперед для фишки «Нейронные сети с открытым исходным кодом на графическом процессоре», и AMD заслуживает огромного доверия, если она хорошо работает на OpenCL.

14 августа 2017 г., 17:19, «Чунг Нг» написал:
Моя компания некоторое время работала над глубоким обучением OpenCL, и у нас есть первые результаты, которые можно показать. В ближайшем будущем мы сосредоточимся на Keras, однако мы также создали (очень) экспериментальную поддержку TensorFlow и вернемся к ней после нашего первоначального выпуска. Более подробная информация, включая исходные данные о пропускной способности AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

—

Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416) или отключите ветку (https://github.com/notifications/unsubscribe-auth). /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Спасибо за исправление, я основывал свой комментарий на системных требованиях в документации MIOpen (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#prerequisites), но буду рад обновить, если есть лучше ссылка.

Подождите, я читаю эту ветку/проблему уже 10 минут. Я прошел половину, а остальное пропустил. Поддерживаются ли графические процессоры AMD?

Использование привередливой штуки с закрытым исходным кодом, которая работает только с одной очень старой комбинацией ядра/ОС (кодплей): да

Используя старую версию tensorflow и пока без поддержки некоторых нелинейностей (tf-coriander): да.

Действительно: не официально. Хотя AMD переносит на HIP, поэтому я ожидаю прогресса в течение 3 месяцев или около того. Другие фреймворки уже хорошо работают благодаря их усилиям.

18 августа 2017 г., 02:09:55 GMT+01:00, [email protected] написал:

Подождите, я читаю эту ветку/проблему уже 10 минут. я на полпути
через и я пропустил через остальных. Поддерживаются ли графические процессоры AMD?

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-323233294

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

FWIW Я считаю, что последние версии PyGpu могут использовать либо CUDA, либо OpenCL. У меня установлено все программное обеспечение на моем Arch box, но я еще не тестировал его.

@ abrad1212 да, эта проблема существует уже некоторое время. Усилия огромные, и многие люди пытаются «заставить это работать», как упомянул @cathalgarvey .

Небольшое обновление с нашей стороны. Вы должны иметь возможность использовать ComputeCpp 0.3.0 в стеке драйверов AMDGPU-pro для Ubuntu 16.04. Инструкции можно найти здесь: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 .

Кроме того, сейчас мы сосредоточены на повышении производительности различных моделей — предстоит еще многое сделать, но мы к этому стремимся.

@lukeiwanski Каков ваш подход к бенчмаркингу? Мы синхронизируем модели, включенные в Keras, и нормализуем их по отношению к TF+cuDNN+K80, потому что это распространенная и хорошо оптимизированная конфигурация. Наша методология похожа на метод Макса Вульфа (http://minimaxir.com/2017/06/keras-cntk/), кода немного, но мы будем рады им поделиться. У нас есть некоторые данные о пропускной способности на нашем веб-сайте (http://vertex.ai), наш код немного быстрее, чем TF 1.2 на выводе Xception, и было бы интересно сравнить другие подходы бок о бок.

Есть ли решения для Windows? Я бы установил Ubuntu на свой компьютер, но сейчас у меня недостаточно места для этого.

убунту 14.04
основная ветвь tensorflow
построить поддержку opencl и установить только среду выполнения opencl intel cpu.
питон2.7
следуйте https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow руководству
выполнить python classify_image.py
кажется, не вызвал драйвер opencl. (Я добавил свою оболочку opencl icd, ничего не увидел)
Нужно ли добавить какую-либо конфигурацию в код Python?
Как sess.graph.device('/cpu0')

Но если я использую руководство Eigen skcl, оно может работать на процессоре с поддержкой OpenCL. (Кроме того, этот код руководства немного устарел, его нужно изменить)
https://developer.codeplay.com/computecppce/latest/начало работы с eigen

Любой человек может помочь проверить, как интерфейс tensorflow python также может работать с поддержкой OpenCL.

И сборка тензорного потока с этим набором опций на самом деле не будет генерировать двоичный файл тензорного потока. --config=sycl
Просто создайте тензорный поток в этой команде:
bazel build -c opt /tensorflow/tools/pip_package :build_pip_package

Может быть, я забыл построить --config=sycl
Я попробую команду сборки и проверю, может ли она вызывать библиотеку OpenCL. После получения результата отпишусь здесь.
bazel build -c opt tensorflow/tools/pip_package :build_pip_package

@joe8086 joe8086 Если вы измените создание tf.Session с помощью приведенного ниже, он покажет журнал в терминале, где-нибудь упоминается SYCL?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Что касается руководства Eigen, есть ли у вас какие-либо конкретные отзывы о том, где оно устарело?

@rodburns Спасибо.
Моя ошибка заключается в том, что сборка тензорного потока пропускает параметр конфигурации --config=sycl
После добавления этой опции с этим кодом ветки https://github.com/lukeiwanski/tensorflow.git
Я вижу, как тензорный поток работает с бэкэндом OpenCL.

Для руководства Eigen основная ошибка находится по адресу:
1, не дает правильный включаемый файл.
2, для массива Tensor, TensorMap не дают правильный параметр шаблона.
3, для static_cast не указывать тип данных.

добавьте дополнительную информацию, которая, возможно, поможет этой теме обсуждения.
1. Основной тензорный поток не может построить тензорный поток с правильным параметром --config=sycl.
2. С ЦП OpenCL скорость примерно в 4-8 раз больше, чем при использовании обычного ЦП в моей среде.

время python classify_image.py
07.09.2017 16:56:29.076054: I tensorflow/core/platform/cpu_feature_guard.cc:137] Ваш ЦП поддерживает инструкции, для использования которых этот двоичный файл TensorFlow не был скомпилирован: SSE4.1 SSE4.2 AVX
2017-09-07 16:56:29.077967: W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] Не найдено графического процессора OpenCL, который поддерживается ComputeCpp, пробуем ЦП OpenCL
07.09.2017 16:56:29.159775: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Найдены следующие устройства OpenCL:
2017-09-07 16:56:29.159825: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id: 0, тип: CPU, имя: Intel(R) Core(TM) i7-6700HQ CPU @ 2,60 ГГц, поставщик: Intel(R) Corporation, профиль: FULL_PROFILE
07.09.2017 16:56:30.213375: W ./tensorflow/core/framework/op_def_util.cc:333] Оп BatchNormWithGlobalNormalization устарела. Он перестанет работать в GraphDef версии 9. Используйте tf.nn.batch_normalization().
гигантская панда, панда, медведь-панда, медведь-енот, Ailuropoda melanoleuca (оценка = 0,89107)
индри, индри, индри индри, индри бревикаудатус (оценка = 0,00779)
малая панда, красная панда, панда, медведь-кот, кот-медведь, Ailurus fulgens (оценка = 0,00296)
заварное яблоко (балл = 0,00147)
земная звезда (оценка = 0,00117)

реальное 1м44.473с
пользователь 2м8.980с
система 1м20.024с

Ребята, я не собираюсь читать всю эту ветку, но если бы кто-то мог ответить на мой вопрос, это было бы здорово! Могу ли я использовать Tensorflow с графическим процессором AMD. Если да, то в какой операционной системе и можно ли это сделать с RX Vega? Спасибо!

@ M3L0NM4N Хммм ... Я не следил за веткой, но похоже, что теперь есть код OpenCL, который можно протестировать, по крайней мере, на CPU OpenCL. У меня более старый графический процессор AMD ("Bonaire"), и OpenCL работает как на графическом процессоре, так и на процессоре, поэтому я могу проверить это. Я мог бы попробовать это на выходных; Мне очень нужен OpenCL TensorFlow на моем графическом процессоре.

tf-кориандер работает https://github.com/hughperkins/tf-coriander

Есть ли поддержка tensorflow 1.3 gpu/opencl на macos?

Последние новости: я успешно собрал TensorFlow 1.3.1 с OpenCL из исходного кода GitHub. В документации довольно много недостающих частей, и я еще не пытался ничего запускать на графическом процессоре, но, по крайней мере, он работает для процессора, отличного от OpenCL. Кстати, у меня не установлен CPU OpenCL, только GPU OpenCL.

У кого-нибудь есть тестовые примеры для TensorFlow с графическим процессором OpenCL? В конце концов мне придется построить один для себя, но я надеялся на быструю проверку.

@znmeb Да, есть тестовое приложение, о котором я сообщил. https://github.com/hughperkins/tf-coriander/issues/64

Не могли бы вы сообщить мне, работает ли это в вашем случае?

@unoexperto Да, он работает (не падает), но нет никаких указаний, нашел ли он OpenCL.

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

Я думаю, что лучший способ действий здесь - подать отдельную проблему для запроса документации, поскольку ясно (когда вы запускаете сборку ./configure из исходного кода), что существует код для OpenCL. Во всяком случае, так я его нашел.

@znmeb Я сомневаюсь, что в вашем случае он нашел устройство GPU, потому что в моем случае он сначала распечатал отладочную информацию о выборе устройства GPU. Возможно, вы можете перекомпилировать с добавлением printf для консоли где-то в tensorflow/core/common_runtime/gpu/gpu_device.cc .

@unoexperto Я присоединился к обсуждению в группе Google и разместил запрос на документацию. Я подожду, чтобы увидеть, ответит ли кто-нибудь, прежде чем я приложу больше усилий к этому.

@znmeb Каким инструкциям вы следуете? Вы запускали clinfo? Вы запустили computercpp_info? Означает ли это, что ваши драйверы OpenCL установлены должным образом? Инструкции для Ubuntu 14.04 находятся здесь https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow , а если вы используете 16.04, здесь есть некоторые экспериментальные инструкции http://deep-beta.co. Великобритания/tensorflow-1-3-на-убунту-16-04-lts/

@rodburns clinfo и clpeak запускаются. Я не делал этого в последнее время, но когда я собираю caffe из исходного кода и запускаю тесты, он определенно поражает GPU. Так что я почти уверен, что драйверы/библиотеки OpenCL/GPU работают.

Я на Arch Linux — ядро ​​их LTS — linux-lts 4.9.52-1. Если это имеет значение, «Bonaire» достигает максимальной производительности около 1,7 TFLOPS в 32-битном режиме и относится к семейству графических процессоров AMD «Sea Island».

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

Кто-нибудь собирает журналы испытаний? Он говорит, что мое устройство не проверено, поэтому я буду его тестировать. ;-)

Я не могу собрать TensorFlow для Sycl/OpenCL!

Конфигурация:
Убунту 16.04
Тензорный поток r1.3
ОпенКЛ 2.0
ComputeCpp CE 0.3.2 (computecpp_info в порядке)
Intel HD Graphics 620
Базель 0.5.4

Инструкция по установке (сборка OpenCL Intel/ComputeCpp):
https://software.intel.com/en-us/articles/opencl-drivers#philinux
https://www.codeplay.com/portal/03-30-17-setting-up-tensorflow-with-opencl-using-sycl

Ошибка :

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

Обучение моделей на моем процессоре занимает много времени, мне действительно нужно ускорение OpenCL/GPU...

@ErwanGalline Мы находимся в процессе внесения изменений в Eigen ( https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None ), которые будут исправить проблему, которую вы видите.

Кроме того, мы готовимся к повышению производительности Eigen — это немного сложно и требует согласования с @benoitsteiner , чтобы избежать потоков слияния конфликтов — но мы к этому приближаемся.

Пользователям AMD я бы посоветовал попробовать мой форк: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu .
Инструкции по установке для Ubuntu 16.04 можно найти здесь: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Все изменения будут внесены в тензорный поток после того, как упомянутые ранее изменения Eigen будут внесены.

Надеюсь, это поможет.

@lukeiwanski Ваш форк поддерживает только GPU AMD R9 Nano / AMD FirePro?

@lukeiwanski Есть ли тестовый пример, который я могу использовать, чтобы убедиться, что я использую графический процессор? Я могу отслеживать его с помощью radeontop , но мне бы хотелось что-то, что использует сам TensorFlow.

@ZixuanLiang нет, не только ..
В настоящее время мы тестируем на AMD (R9 380, R9 Nano, FirePro). Мы знаем, что Intel GPU выявляет некоторые ошибки драйверов, но есть исправления. И мы анонсировали Renesas R-Car и ожидаем, что последуют и другие.

Я считаю, что Xilinx расширяет поддержку triSYCL https://github.com/tensorflow/tensorflow/pull/12882 — так что FPG (?) — @keryell должен знать об этом больше

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test должно быть честной проверкой .. вывод должен выглядеть примерно так:
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 Спасибо, попробую на AMD GPU.

@lukeiwanski Сборка и тестирование, похоже, работают на моем Бонайре. Однако я использую Python 3.6, а в инструкциях используется Python 2.7. Мне нужно использовать 2.7 или 3.6 будет работать?

@znmeb После https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647 кажется, что Python 3.6 должен работать - хотя я не пробовал

@lukeiwanski Это версия ComputeCpp, которая на данный момент может создавать TF?
Я пробовал различные версии между 0.3.2 и 0.1.4, и ни одна из них не работала. Все они закончились ошибкой «множественные перегрузки 'global_ptr', созданные для одной и той же подписи».
Кстати, я не могу найти файл TensorDeviceSycl.h в исходниках TF, он переименован? Можно ли применить патч к текущим источникам?

Заранее спасибо.

@eLvErDe ComputeCpp 0.3.2 может собрать: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu

В Upstream отсутствует патч для Eigen, который его исправляет. См. https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564.

Любая идея, как внедрить этот патч Eigen во время сборки bazel? Может быть, мы должны где-нибудь найти версию Eigen tgz, чтобы получить исправленную?

Спасибо, Адам.

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

Этой фиксации будет достаточно, чтобы построить его?

да, вы должны быть в состоянии выбрать это

К сожалению, этого явно недостаточно, вот некоторые из следующих ошибок сборки:

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 есть несколько коммитов, которые вы должны применить, чтобы его скомпилировать.
Я бы предложил использовать подсказку dev/amd_gpu или, если вы не хотите менять текущую ветку, вы можете объединить с ней dev/amd_gpu.

На самом деле я работаю над своим неофициальным пакетом Debian/Ubuntu, поэтому я стараюсь придерживаться официальной версии 1.3.1. Я могу жить без поддержки OpenCL, но я был бы готов включить ее, как только она будет правильно поддерживаться. Возможно, я обновлю пакеты для вашей ветки для тестирования, но на сегодня достаточно ;)

У меня есть около десяти различных вариантов графических процессоров AMD в моих установках для майнинга. (от 7970 до RX 480 под управлением Ubuntu 16.04 и amdgpu-pro). Дайте мне знать, если я могу внести свой вклад, протестировав что-нибудь.

Дайте мне знать, если я могу внести свой вклад, протестировав что-нибудь.
Как насчет https://github.com/ROCmSoftwarePlatform/hipCaffe
https://github.com/ROCmSoftwarePlatform/hipeigen

Во вторник, 17 октября 2017 г., в 10:54, [email protected] написал:

У меня есть около десяти различных вариантов графических процессоров AMD в моих установках для майнинга. (от
7970 до RX 480 под управлением Ubuntu 16.04 и amdgpu-pro). Дайте мне знать, если я могу
внести свой вклад, проверяя что-либо.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski Будет ли ваш форк поддерживать графические процессоры AMD на macOS?

Привет,
Я создавал API-интерфейсы тензорного потока на Ubuntu16.04 x64 для своего устройства Android с включенным графическим процессором (Mali-T720),

Информация о моей ОС:
Убунту 16.04 х64
Графический процессор компьютера: NVIDIA 1080Ti
КУДА 8.0
CUDNN 5.1 (хотя я не использую cuda или cudnn для сборки)
Базель 0.5.2
ComputeCpp CE 0.3.2

мой build.sh:
'
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 --
процессор = armeabi-v7a
'
перед постройкой. Я экспортирую LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, сборка без ' --config=sycl ' прошла нормально, и я получил правильный libtensorflow_cc.so, но с ' --config=sycl ' окончательный результат оказался отсутствующим -lComputeCpp без каких-либо других ошибки компиляции

Полный лог такой:

ОШИБКА: /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1: привязка правила '//tensorflow/contrib/android:libtensorflow.so' не удалась: link_dynamic_library.sh не удалось: ошибка при выполнении команды
(cd /home/e0024/.cache/bazel/_bazel_e0024/783dad02ec856015f56356584726dd10/execroot/org_tensorflow && \
исполняемая среда - \
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/ игры:/usr/местные/игры:/снап/бен \
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 нет игнорируется игнорируется игнорируется external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/предварительно собранный/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 выход / рычажного линукс-androideabi-4,9-v7a-гну-libstdcpp-OPT / бен / _solib_armeabi-v7a / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib -Wl, -whole-архив Базэл-аут / рука -linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/c/libc_api.a -Wl,-без-целого-архива -Wl,-весь-архив bazel-out/arm-linux-androideabi- 4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib.lo -Wl,-без-целого-архива -Wl,-весь-архив bazel-out/arm-linux-androideabi-4.9-v7a-gnu -libstdcpp-opt/bin/tensorflow/core/kernels/libandr oid_tensorflow_kernels.lo -Wl,-без-целого-архива -Wl,-целого-архива bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib_lite.lo -Wl ,-no-whole-archive -Wl,-целый-архив bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libprotos_all_cc.a -Wl,-no-whole -archive -Wl,-весь-архив bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf.a -Wl,-no-full-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/ источники/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 - без канонических префиксов '-march=armv7-a' -Wl,--fix-cortex-a8 '--sysroot=external/androidndk/ndk/platforms/android-14/arch-arm'): com.google.devtools.build.lib.shell.BadExitStatusException: Процесс завершен с статус 1.
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/предварительно собранный/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld: предупреждение: пропуск несовместимого 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/solibComputeCpp. для ComputeCpp
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/предварительно собранный/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld: ошибка: невозможно найти -lComputeCpp
collect2: ошибка: ld вернул 1 статус выхода
Цель //tensorflow/contrib/android:libtensorflow.so не удалось собрать
ИНФОРМАЦИЯ: Истекшее время: 617,736 с, критический путь: 54,66 с.

хм .... Я хочу создать API-интерфейсы тензорного потока в арке руки с включенным графическим процессором (Mali-T720),
Признателен, если кто-то может оставить здесь свой опыт или предложения. Спасибо большое.

Приходите на мою лекцию на Arm TechCon на следующей неделе, @laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Вам понадобятся драйверы Mali с поддержкой SPIR-V, которые, вероятно, пока недоступны. И вам понадобится среда выполнения ComputeCpp для Android с поддержкой процессора Arm и поддержкой SPIR-V, которая также недоступна (пока). Итак, вам придется быть немного терпеливым.

Мы (Vertex.AI) только что открыли исходный код PlaidML, нашего стека глубокого обучения с поддержкой запуска Keras на OpenCL. Поддержка TensorFlow приближается, помощь будет приветствоваться. И да, поддержка Mac уже на подходе (также Windows). http://vertex.ai/blog/announcing-plaidml @ggaabe

@choongng Я хотел попробовать, но не смог.
pip search plaidml возвращает

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Но pip install plaidml или pip install plaidml==0.1.0rc3
возвращается

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

@ hy9be Я думаю, что было бы более уместно создать проблему в репозитории plaidml , а не здесь, поскольку эта проблема касается поддержки OpenCL в тензорном потоке. Кроме того, просмотрев инструкции по установке, ваша команда установки pip может быть неправильной.

Спасибо @andrewrichards за внимание и сессионное выступление.

Но на данный момент для меня (аспиранта) создать приложение с использованием Tensorflow на устройстве Android и активировать графический процессор (Mali-T720), что требуется для получения драйвера Mali с поддержкой SPIP-V и среды выполнения ComputeCpp для Android с процессором Arm. поддержка и поддержка SPIR-V.

Поскольку я загрузил ComputeCpp (Ubuntu 16.04 x64 с bin/doc/include/lib/) на домашней странице CodePlay, вчера я запускаю:
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
ошибки говорят libComputeCpp.so incompatible , поэтому я думаю, что, возможно, мне нужен ComputeCpp для Android с поддержкой процессора Arm и поддержкой SPIR-V, но я не смог найти исходный код для сборки Android ComputeCpp, на github есть только образцы.

И вы сказали, что ComputeCpp для Android сейчас недоступен, поэтому есть ли какие-либо планы по поддержке устройств Android или как я могу получить его, если он поддерживается.

Для пользователей AMD gpu и linux AMD недавно выпустила HIP-порт tensorflow здесь . Вам может быть интересно.

Я не проверял это, хотя.

Я могу проверить это - следите за обновлениями. Однако похоже, что это не работает CI.

Действительно терпит неудачу. Все еще на ранней стадии, я думаю.

Я протестировал это, сразу же получил segfault в примере MNIST.
Не знаю, что я делаю неправильно здесь.

$ 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 - убедитесь, что у вас установлена ​​база rocm 1.6.4.

@bensander Спасибо, я обновлю.

@bensander Что-нибудь еще мне нужно из стека AMD? Все, что у меня есть сейчас, это проприетарная библиотека AMD opencl, которая использует драйвер amdgpu с открытым исходным кодом.

@masahi - если вы устанавливаете rocm и rocm-libs (то есть «apt-get install rocm rocm-libs»), это все, что вам нужно. rocm_docs в репозитории содержит полные инструкции, включая ожидаемые результаты.

@bensander как узнать, правильно ли я использую rocm 1.6.4 (а не 1.6.3)?

@masahi просто предположение: вам следует задать вопрос в более близком к вашей проблеме месте, например, в проекте AMD или RoCM, а не здесь ...

@keryell правильно, я ухожу от темы. Я останавливаюсь здесь.
Во всяком случае, я не мог заставить hiptensorflow работать в моей системе. Я попробую позже с чистой установкой Ubuntu.

@masahi - просто откройте вопрос там, и мы настроим вас.

Привет, я просто хочу отметить, что мне удалось заставить работать hiptensorflow благодаря @bensander и другим людям из AMD. Я могу запустить все примеры в их кратком руководстве.

Спасибо

Для тех, кто хочет попробовать TensorFlow на оборудовании AMD с помощью ROCm, я написал блог, в котором описал, как запускать ноутбуки Fast.ai с помощью AMD Fury Nano.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 не могу дождаться этого!

ROCm 1.7 уже в пути, и это звучит как правильная поддержка Tensorflow!

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

Порт Tensorflow на AMD GPU:
https://github.com/ROCmSoftwarePlatform/hiptensorflow/blob/hip/README.ROCm.md

Это отлично работает для меня. Мои аппаратные настройки:
Графический процессор: AMD Radeon RX 480
Процессор: Intel Xeon 2603 v3
МБ: супермикро x10srl-f

Ключом является материнская плата и процессор, которые должны поддерживать PCIe v3.

Его производительность аналогична Nvidia 980Ti.

Я даже не могу заставить «поддерживаемые» драйверы AMD работать с моей «поддерживаемой» установкой Ubuntu 16.04 LTS. Запланированное устаревание?

znmeb, какой у тебя графический процессор AMD? Если у вас два графических процессора, отключите неподдерживаемый из них в BIOS.

Не удалось прочитать всю ветку ... каково текущее состояние тензорного потока в OpenCL в MacOS (sierra +)? В частности, у меня есть графический процессор Intel Iris, и я надеялся, что смогу создать для него поддержку Tf+Open CL из исходного кода.
Кроме того, tf corrainder, кажется, работает нормально на версии 1.2.

@ varun19299 FWIW есть Intel SDK для OpenCL - он у меня есть на моем древнем ноутбуке Sandy Bridge, но я уверен, что он будет работать на вашей машине. https://software.intel.com/en-us/intel-opencl

Является ли это в настоящее время пригодным для использования в системах Linux, отличных от Ubuntu? Страница дорожной карты просто ссылается здесь.

@pfc Что в настоящее время можно использовать в Linux, отличном от Ubuntu? TensorFlow с использованием OpenCL в целом? Или TensorFlow с использованием OpenCL на графическом процессоре AMD? Я предполагаю последнее, так как это единственная причина, по которой вы захотите запустить TensorFlow с использованием OpenCL. Для графического процессора NVidia вы должны использовать драйверы/библиотеки NVidia, а только для ЦП нет никакой выгоды от OpenCL.

У меня это работало несколько недель назад в Arch Linux с использованием проприетарной библиотеки ComputeCpp SYCL и графического процессора AMD Bonaire (архитектура Sea Islands). Есть новый выпуск ComputeCpp, который мне нужно протестировать, но я предполагаю, что он будет работать.

Оказывается, проприетарные библиотеки AMDGPU Pro, необходимые для этой работы, не работают в Ubuntu 16.04.3. Обновление с 16.04.2 принесло более новое ядро ​​​​Linux и X Server, и AMD еще не выпустила что-то, что работает на нем. Подробнее см. http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-Compatibility-Advisory-with-Ubuntu-16.04.2-and-16.04.3.aspx . Мне не удалось заставить AMD OpenCL работать на Ubuntu.

Существует экспериментальная версия TensorFlow для AMD, в которой используется компилятор для перевода кода CUDA в код OpenCL, но я ее тоже не тестировал. При отсутствии поддерживаемого драйвера бесполезно.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs — это официально поддерживаемый способ запуска тензорного потока на оборудовании AMD.

@bensander Работает ли среда выполнения ROCm в Ubuntu 16.04.3? Я не смог заставить его работать.

PS: Есть ли у вас какие-либо сведения о том, будет ли и когда установка AMDGPU-Pro работать в Ubuntu 16.04.3? Мне это нужно для другого проекта.

Хм, я нигде не развлекаюсь с Ubuntu, но у меня есть CentOS 7 с репозиториями и GTX1080TI, ядро ​​4.14.x и последний бета-драйвер Nvidia, так что я мог бы помочь протестировать его. там в какой-то момент сегодня, если это поможет?

--
Сэм Маклеод

7 декабря 2017 г., в 07:28, М. Эдвард (Эд) Бораски, [email protected] написал:

@bensander Работает ли среда выполнения ROCm в Ubuntu 16.04.3? Я не смог заставить его работать.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@sammcj Зачем вам запускать графический процессор NVidia с OpenCL, если для него есть отличные библиотеки CUDA?

Просто чтобы помочь проверить это для вас!

Не беспокойтесь, если вам не нужно ручное тестирование, просто подумал, что я могу предложить. Я даже не пробовал эту машину с cuda TBH, я пробовал только на MacOS, где в данный момент я не могу использовать OpenCL через Docker.

--
Сэм Маклеод

7 декабря 2017 г., в 08:16, М. Эдвард (Эд) Бораски[email protected] написал:

@sammcj Зачем вам запускать графический процессор NVidia с OpenCL, если для него есть отличные библиотеки CUDA?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@znmeb Я собирался попробовать ComputeCpp SYCL, однако они предоставляют только установщик Ubuntu (я также использую Arch), а сценарий установки aur не работает. Приятно слышать, что это может работать. Если я буду достаточно отчаянным, я могу попробовать это.
@bensander Похоже, это именно то, что мне нужно для поддержки ADM, однако меня беспокоит тот факт, что этот код не был перенесен обратно в TF и ​​последний раз его код обновлялся более 2 месяцев назад, учитывая, что мой код нацелен на TF 1.4. 0
Похоже, что на данный момент тензорный поток в основном связывает вас с Nvidia, по крайней мере, для нас, «смертных» программистов. Отсутствие документации/обновленной дорожной карты не помогает. Я был бы не против помочь, чем мог, однако до сих пор у меня не было большого успеха в том, чтобы заставить все работать.

@pfc Я получил SYCL ComputeCpp, работающий над Arch - когда я это сделал, на их веб-сайте был бинарный архив.

В этой новости о выходе SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
он говорит:
_Новая спецификация включает в себя значительный опыт, полученный от трех отдельных реализаций, и отзывы разработчиков сред машинного обучения, таких как TensorFlow, которые теперь поддерживают SYCL вместе с исходной серверной частью ускорителя CUDA._

Означает ли это, что теперь можно «легко» запускать TensorFlow на графическом процессоре AMD, поддерживающем OpenCL 1.2, на котором построен SYCL?

«Легко» в том смысле, что некоторые низкоуровневые программы/драйверы/библиотеки для аппаратного обеспечения AMD находятся там, где находится большая часть сломанного материала, а не в аппаратном обеспечении, TensorFlow, стандартах OpenCL или SYCL. ;-) Если у вас есть работающие драйверы графических процессоров AMD и работающие библиотеки OpenCL, у вас есть TensorFlow на графических процессорах AMD.

Моя рабочая установка для AMD Bonaire (архитектура Sea Islands):

Arch Linux с загруженным модулем ядра amdgpu и модулем ядра radeon , занесенным в черный список
Пакет пользовательского репозитория Arch opencl-amd
Библиотека ComputeCpp
TensorFlow, созданный из исходного кода на моей рабочей станции с использованием форка @lukeiwanski :

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

Я немного удивлен тем, что вы сказали: «Если у вас есть работающие драйверы графического процессора AMD и работающие библиотеки OpenCL, у вас есть TensorFlow на графических процессорах AMD». Я понял, что «официальная» версия TensorFlow не работает на OpenCL (только CUDA). Кажется, я запутался.
Я был очень рад найти проект PlaidML, который, по крайней мере, позволяет запускать некоторый код Keras на моем iMac с AMD Redeon HD 6970. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) Насколько я знаю, вы также пробовали эту платформу.
Я попробую запустить TensorFlow на Ubuntu VirtualBox, где Tensorflow уже запущен (только ЦП).

@PALYGAP Я не думаю, что VirtualBox экспортирует OpenCL с хоста Mac в гостевую систему Linux, а Ubuntu 16.04.3 сейчас не работает. У меня нет Mac, поэтому я не могу ничего проверить.

Кто-нибудь успешно попробовал работать с TensorFlow на AMD через OpenCL и преуспел?

@mohnkhan У меня работает форк @lukeiwanski (Arch Linux) — см. https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . Я жду еще немного работы над AMDGPU-Pro, прежде чем опубликовать сообщение в блоге — см. https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Спасибо за участие

@mohnkhan Кстати, AMD разрабатывает альтернативный путь с полностью открытым исходным кодом - переводит код CUDA в код OpenCL с помощью цепочки инструментов компилятора. Я не уверен, каков статус этого для старых карт, таких как моя.

Если собираетесь писать статью, думаю, не мешало бы еще пояснить (ушло часа 3 на полную картину):

• На самом деле у TF есть бэкенд SYCL 1.2. Нет *фактического* opencl.
• в свою очередь, у вас есть две реализации стандарта (trisycl выглядит круто, но это ограниченный атм)
• В итоге ComputeCpp ‘перехватывает’ SPIR /SPIR-V (помимо PTX, но это уже совсем другая история )

И это то, что в конечном итоге приводит вас прямо к вашей чертовой жажде OpenCL 1.2 (с расширением cl_khr_spir)

HIP вместо этого является еще одним бэкэндом, расположенным напротив SYCL и нацеленным только и исключительно на ROCm (или, ну, лол, даже в свою очередь cuda, если у вас есть графический процессор nvidia ... но это снова другая история)

AMD разрабатывает альтернативный путь с полностью открытым исходным кодом — перевод кода CUDA в код OpenCL с помощью набора инструментов компилятора.

Неа. Вы говорите о HIP, и... на самом деле это то, во что вы в конечном итоге конвертируете свой код. Что не является OpenCL.
Затем HIP работает на ROCm, как я уже говорил...
ROCm, который также запускает OpenCL для вас (на поддерживаемых картах ), но, пожалуйста, я хотел бы обратить внимание всех на то, что отношения идут только вперед от ROCm, а не «внутри-подуровни».

То, о чем вы, возможно, думаете, может быть кориандром .

Я не уверен, каков статус этого для старых карт, таких как моя.

Подводя итог здесь : полноценный драйвер AMDGPU-PRO, amdgpu-pro-opencl-only, как вы делаете сейчас ... Или продолжайте ждать до конца десятилетия, пока кто-нибудь, наконец, не сделает клевер пригодным для использования.

Кроме того, fglrx... Но если это трудно порекомендовать для карт pre-gcn, я думаю, лучше просто закрыть завесу.

@mirh

1. Меня не интересуют карты pre-GCN. У меня Sea Islands, и я не планирую приобретать что-то более старое. Опять же, я не планирую приобретать еще один графический процессор AMD. ;-)
2. Я не знаю, будет ли ROCm работать на моей рабочей станции — нет тестера оборудования с открытым исходным кодом, который мог бы дать мне ответ «да» или «нет». Я открыл вопрос по этому поводу и не получил ответа.
3. SPIR-V - это цель компилятора - я взглянул на него и развел руками, не имея бюджета, чтобы нанять автора компилятора.

Итак, остается SYCL ... или я поднимаю две другие руки и делаю все с Keras, у которого есть TensorFlow, Theano (который зависает), CNTK или PlaidML. С чисто инженерно-экономической точки зрения, Keras/PlaidML является большим победителем, если я каким-то образом получу TensorBoard.

@mirh спасибо за хорошее резюме со всеми ссылками. Я думаю, вы не зря потратили свои 3 часа... :-)

Я не знаю, будет ли ROCm работать на моей рабочей станции — нет тестера оборудования с открытым исходным кодом, который мог бы дать мне ответ «да» или «нет». Я открыл вопрос по этому поводу и не получил ответа.

Как я уже говорил вам несколько раз , нет, это не сработает.
Графическим процессорам до GCN 3-го поколения просто не хватало аппаратного обеспечения для ROCm, чтобы либо работать, либо даже работать вообще.

СПИР(-V).. Я не уверен, о чем ты говоришь. Не твоя работа заботиться об этом. Computecpp делает это из "команд" SYCL, а затем все (opencl) дело драйвера.

У вас есть то, что я условно называю amdgpu-pro-opencl-only, и тогда я не уверен, в чем проблема.
РЕДАКТИРОВАТЬ: было бы также здорово иметь какое-то ETA для кода Люка, чтобы приземлиться

@znmeb и все

У меня (L)Ubuntu 17.10 вкл. Ядро 4.14.x и библиотека OpenCL являются частями работающего драйвера AMDGPU Pro 17.40 и могут без проблем запускать приложения OpenCL, такие как clinfo или Boinc (например, Engima @Home , Milkyway@Home) на моем гибридном процессоре AMD A12-9800E.

Я также могу успешно скомпилировать и использовать версию процессора tensorflow (в настоящее время версия 1.4.1). Но мне не удалось успешно скомпилировать версию tensorflow для OpenCL. Я использую computercpp 0.5 (текущий, который я могу скачать без регистрации) вместе с vanilla tensorflow 1.4.1 и с веткой «dev/amd_gpu» из форка @lukeiwanski .

Итак, не мог бы кто-нибудь, кто успешно скомпилировал версию tensorflow OpenCL, предоставить некоторую информацию, какую версию библиотеки computercpp и какую ветку какого git tensorflow он использует?

Спасибо

@AlphasCodes У меня ничего не работает в Ubuntu — все мои рабочие вещи находятся в Arch. У меня есть машина с двойной загрузкой Ubuntu 16.04.3, но проприетарные библиотеки AMD пока не работают. Насколько я знаю, они не поддерживаются в 17.10, но если у вас есть часть OpenCL, работающая в 17.10, я мог бы добавить третью загрузку - у меня много места на диске. ;-)

Какие ошибки вы получаете? Если это ошибки сборки, у вас может быть несовместимость с Bazel. Bazel постоянно движется вперед, как и TensorFlow, и иногда одно опережает другое.

Что вы имеете в виду под "не поддерживается"?

Это .
Что касается Ubuntu, говорят, что поддерживается только 16.04.3 (по крайней мере, тогда официально, учитывая, что даже Arch может заставить его работать после некоторой магии скрипта)
РЕДАКТИРОВАТЬ: для «полного» драйвера AMDGPU-PRO требуется ядро ​​​​4.9, вероятно, это и было проблемой.

Если кому интересно, перенос драйвера AMDGPU-Pro 17.40 на Arch продолжается и очень активен на GitHub по адресу https://github.com/corngood/archlinux-amdgpu/pull/54 ,

Нам действительно следует закрыть эту проблему, поскольку, как указал @mirh , TensorFlow использует SYCL, а не OpenCL. Может стоит открыть еще один, "TensorFlow на картах AMD"??

Нет, это абсолютно законно.
Вы хотите, чтобы тензорный поток в конечном итоге работал на устройствах opencl, это цель. Законно и конец.
Сказать, что на самом деле используется SYCL, было лишь технической придиркой, которую я сделал, потому что все эти аббревиатуры магически случайных технологий сводили меня с ума.
РЕДАКТИРОВАТЬ: я также хотел бы поблагодарить всех парней, играющих в код, за их вопиющую работу.

Если вам нужно что-то специально созданное для AMD, я бы порекомендовал проверить их hiptensorflow . ROCm-только однако. И, пожалуйста, давайте оставим этот аргумент позади.

Хорошо, я не знаю, есть ли у меня достаточно времени, чтобы снова сделать сборку и предоставить ошибки компиляции до выходных. Но я добавил свою существующую документацию в свой новый репозиторий github.

Подробнее см. https://github.com/AlphasCodes/DeepLearning (настройка моего оборудования/программного обеспечения + настройка AMD OpenCL + настройка Tensorflow).

@mirh , чтобы прояснить «аббревиатуры магически случайных технологий [...], которые сводят [вас] с ума»:

В сфере Khronos Group OpenCL — это низкоуровневый API-интерфейс без единого исходного кода, а SYCL — высокоуровневый предметно-ориентированный встроенный язык C++ с одним исходным кодом (DSeL). Ожидается, что SYCL будет построен поверх OpenCL, поэтому из-за транзитивности при использовании SYCL вы часто используете OpenCL.

Поскольку TensorFlow использует Eigen, который использует подход C++ с одним исходным кодом и CUDA с одним исходным кодом, когда позже он был перенесен на OpenCL, был выбран SYCL, поскольку это стандартный способ Khronos Group иметь C++ с одним исходным кодом .

Но если вы думаете о CUDA, это еще более тонко.

Почти все используют высокоуровневую версию CUDA с одним исходным кодом , которая на самом деле называется «CUDA Runtime API». Это чем-то похоже на SYCL.
Но на самом деле существует менее известная низкоуровневая версия CUDA без единого источника , которая называется «API драйвера CUDA», похожая на OpenCL, и используется, например, самой реализацией «CUDA Runtime API».

Так как это своего рода FAQ, я немного уточнил https://en.wikipedia.org/wiki/SYCL и https://en.wikipedia.org/wiki/CUDA

ComputeCpp, реализация SYCL, которую вы используете с TensorFlow, еще не поддерживает Ubuntu 17.10. Вам нужно будет придерживаться Ubuntu 16.04, которая является текущей LTS. Инструкции и предварительные требования находятся здесь https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow.

Кроме того, поддержка OpenCL для TensorFlow означает не только поддержку устройств AMD. Интеграция SYCL также позволяет использовать другие устройства OpenCL. В рамках работы, которую мы проводим с TensorFlow, поддержка графических процессоров ARM и Intel будет доступна, когда будут доступны последние версии драйверов от этих компаний. Мы также работаем над тем, чтобы обеспечить поддержку ускорителей Renesas для платформы R-Car.

@rodburns Спасибо! У меня это работает на Arch Linux (ядро 4.14.4) с библиотекой opencl-amd из пользовательского репозитория Arch. Это карта Bonaire (GCN 2.0). Я проведу тесты на этой странице, чтобы убедиться, что она делает то, что должна.

GCN 2-го поколения (он же 1.1), если таковой имеется, 2.0 не существует.
(надо опускаться до такой педантичности)

УСПЕХ!

Последняя фиксация ветки «dev/amd_gpu» в форке @lukeiwanski исправила мою проблему с компиляцией Tensorflow OpenCL. Я предполагаю, что это были коммиты, связанные с SysCL 1.2.1.

Я успешно скомпилировал версию Tensorflow OpenCL и могу ее использовать. Подробности смотрите в моих документах по настройке Tensorflow .

Я также добавил страницу тестов, где вы можете найти некоторые тесты моей установки при различных настройках Tensorflow (без оптимизации ЦП, с оптимизацией ЦП, OpenCL) в будущем.

Драйвер AMDGPU Pro версии 17.50 у меня тоже работает. Я обновил соответствующий документ по установке AMD OpenCL .

Спасибо всем участникам.

Я сделал несколько тестов, и оказалось, что iGPU работает медленнее, чем 4 доступных потока процессора, за исключением теста matmul_bench.py .

Инициализация запуска OpenCL Tensorflow также намного медленнее, чем запуск OpenCL Tensorflow только на ЦП. Что-то вроде 5 секунд для процессора против 1-2 минут для OpenCL.

Кто-нибудь может подтвердить такие результаты?

Хорошо, я сделал еще несколько действий по устранению неполадок.

• я использовал пример Tensorflow MNIST, см. документ Validate a Tensorflow Setup
• я использовал «sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info», чтобы проверить/просмотреть часы/загрузку iGPU и «top», чтобы проверить загрузку процессора
• фаза инициализации до шага 0 заняла около 6 минут, загрузка iGPU составляла около 0%, тактовая частота iGPU составляла 300 МГц (минимально доступная тактовая частота), а использование ЦП процессом python составляло около 200% (= 2 потока)
• начиная с шага 0 загрузка iGPU составляла около 90%, часы iGPU всегда переключались с 654 МГц - 720 МГц - 800 МГц - 900 МГц (максимально доступные часы) и обратно, использование ЦП процессом python составляло около 100% (= 1 ЦП). нить)

Я все еще пытаюсь заставить вещи компилироваться в Arch.

То, что я использовал вчера .
Через 14 часов (да, у меня картошка очень медленная) получил вот этот бинарник , если хотите попробуйте.

Я пытался выяснить, что происходит, но, к сожалению, не смог. Я был бы признателен, если кто-то, кто знает о следующем, может помочь мне ускориться!

Большая часть приведенного выше обсуждения относилась к запуску Tensorflow с ускорением OpenCL на чипах AMD. Я правильно говорю это? Если я хочу получить тензорный поток с ускорением графического процессора, используя мою встроенную графическую карту (intel HD 5000), которая поддерживает opencl, каким должен быть мой подход?

Заранее спасибо!

@znmeb Привет, Эд, спасибо за ответ. Я загрузил и запустил OpenCL в своей системе. Но мой вопрос заключался в том, как мне скомпилировать тензорный поток, чтобы он действительно использовал библиотеки OpenCL?

https://developer.codeplay.com/computecppce/latest/начало работы с tensflow
И самое главное для интел https://github.com/codeplaysoftware/computecpp-sdk/issues/78#issuecomment -352411192

@AlphaCodes Спасибо за публикацию ваших результатов. Что касается времени инициализации, принцип работы OpenCL заключается в том, что код компилируется перед выполнением, поэтому время запуска — это процесс компиляции.

@brainwave Для устройств Intel здесь есть ветка с @mirh , в которой объясняется, как снять ограничения на работающие устройства. Мы видели проблемы с драйверами Intel, поэтому эти типы устройств ограничены, но мы надеемся, что скоро будут доступны обновленные драйверы для устройств Intel, которые улучшат поддержку. Тем временем вы можете перекомпилировать TensorFlow с изменениями, чтобы протестировать собственное оборудование Intel. Мы смотрим на удаление ограничений устройства в кодовой базе.

@AlphasCodes Ребята, прошу прощения за, возможно, наивный вопрос, но почему эта сборка только для графического процессора AMD? Разве OpenCL не должен быть стандартным? Правильно ли я понимаю, что он не будет работать на моем Intel Carbon X1 с установленными драйверами OpenCL 2.0?

Если вы прочитаете проблему, на которую дважды ссылались, вы увидите, что там ничего нет о AMD GPU.
Intel в настоящее время исключен, но это не имеет ничего общего с желанием заставить пользователей, и есть временное обходное решение - обсудите там, если оно действительно есть.

Когда я использую ветку amd_gpu с блокнотом Jupyter, кажется, что остался лишний поток. python по-прежнему использует 100% одного процессора, даже после завершения вычислений. Перезапуск ядра завершает бродячий поток. Кто-нибудь еще испытывает это?

@brainwave @unoexperto
К сожалению, я не могу помочь с Intel OpenCL, потому что у меня есть только оборудование AMD OpenCL.

@отчаянный
Юпитером пока не пользуюсь. Я использую простую оболочку bash и виртуальную среду Python 3 ( см. мою настройку Python 3 + Tensorflow ). Но я не могу воспроизвести проблему. Процесс python не использует ЦП после завершения вычислений.

@родбернс
Спасибо за информацию. Можно ли ускорить начальное время компиляции? например, используя все доступные потоки ЦП вместо только 50%.

@brainwave @родбернс
Для графического процессора Intel (Gen9) под Linux мы наблюдали значительно лучшую производительность DNN с реализацией Intel Beignet с открытым исходным кодом по сравнению с реализацией с закрытым исходным кодом при сравнении с обычными сетями машинного зрения на PlaidML. Beignet также проще в установке, что приятно.

Поддерживает ли он графику Intel HD615 (процессор 7-го поколения) на Ubuntu 17.10?

Драйвер opencl SRB5.0 для linux64 хорошо работает на ubuntu17.10.

И давно не обновлялся:
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Ради Бога, вы не можете прочитать всего 2 (два!) поста выше?
Обсудите отсутствие поддержки Intel GPU (или AMD CPU) здесь https://github.com/codeplaysoftware/computecpp-sdk/issues/78

@znmeb - это цель полностью использовать различные вычислительные ресурсы (например, процессор, графический процессор, DSP, любой другой сопроцессор).
На самом деле это зависит от поддержки производителей оборудования: драйвера и ОС.
Насколько я знаю, вы не можете одновременно включить GPU Intel и nvida для видео из-за ограничения драйвера vedio. (Возможно, вы сможете переключаться между ними).
Однако opencl может использовать их одновременно. Они оба являются «устройствами» в нем.

@choongng Интересно знать, мы проделали некоторую работу, чтобы помочь включить Beignet, но активность в этом проекте, похоже, немного утихла.

@znmeb Да, любой графический процессор, вероятно, не будет работать намного лучше с небольшой проблемой, но рад, что вы добились определенного прогресса!

@unoexperto ComputeCpp с TensorFlow может использоваться любым оборудованием, которое поддерживает промежуточные инструкции SPIR OpenCL, включая графические процессоры Intel, однако, как и в этой ветке, мы намеренно предотвратили его запуск, потому что не думали, что текущие драйверы работают в данный момент. . Вы можете снять это ограничение, поскольку похоже, что у некоторых пользователей оно работает с другими драйверами Intel. Мы также работаем над тем, чтобы включить это для процессоров ARM и Renesas с драйверами OpenCL.

@ sxpc722 Тогда это должно сработать. Кстати, на новой машине установлена ​​Windows 10, и я не планирую выполнять двойную загрузку с Linux до тех пор, пока мне это не понадобится! Мне надоело выискивать ошибки драйверов и библиотек для поставщиков (смотрю на вас, AMD). На самом деле, я могу поставить раздел Windows на свою рабочую станцию ​​по той же причине, что и AMD. ;-)

Прошло 14 дней без активности, и у этой проблемы есть правопреемник. Пожалуйста, обновите метку и/или статус соответствующим образом.

Согласно моим тестам, производительность Tensorflow AMD OpenCL очень низкая. Поэтому я провел несколько базовых тестов с другой структурой глубокого обучения. Мои настройки и бенчмарки вы найдете на моей странице GitHub здесь .

Короче говоря. Другая инфраструктура глубокого обучения в настоящее время примерно в 10 раз быстрее, чем Tensorflow AMD OpenCL.

@AlphasCodes @znmeb Я знаю, что команда TF предпочитает оставить ветку только для TF, мы рады провести обсуждение, посвященное PlaidML, в проекте PlaidML. Тем не менее, мы надеемся в конечном итоге поддерживать сам TensorFlow, а также платформы, отличные от OpenCL (например, Metal от Apple для iOS, который в настоящее время существует в виде прототипа).

https://github.com/plaidml/plaidml

@choongng Спасибо за информацию, я соответствующим образом отредактировал свое сообщение.

@znmeb iGPU AMD A12-9800E должен быть GCN v3.

Основная и единственная причина, по которой я выполняю эталонные тесты/тесты, — найти ответ на мой вопрос «Оставаться с AMD или переключиться на Nvidia для моего приключения в области глубокого обучения».

И ответ есть. Мне очень нравится подход AMD с открытым исходным кодом, но я, скорее всего, перейду на Nvidia из-за двух факторов. Во-первых, стек программного обеспечения для глубокого обучения (например, Tensorflow) гораздо более зрелый для Nvidia. Во-вторых, графическая карта, предлагаемая для моих очень специфических потребностей (должна вписываться в корпус Dan A4 SFX и должна быть очень, очень тихой / почти бесшумной при полной нагрузке в течение нескольких часов), очень ограничена или даже не существует на стороне AMD.

Поддерживаются ли графические процессоры Intel? Я думаю, что мой Iris Pro может немного ускорить многовековую тренировку.

Обсудите отсутствие поддержки Intel GPU (или AMD CPU) здесь codeplaysoftware/computecpp-sdk#78

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

Просто пытаюсь понять состояние этого вопроса. Правильно ли я говорю, что это репо:

https://github.com/lukeiwanski/tensorflow

... созданный с помощью ComputeCpp, является ли на данный момент лучшим вариантом для создания Tensorflow с общей поддержкой графического процессора AMD? И если да, то есть ли какие-либо тестовые доказательства того, что эта сборка обеспечивает ускорение по сравнению с процессором?

Зависит от того, что вы подразумеваете под «общей поддержкой AMD GPU». Если вы имеете в виду действительно старые dGPU или APU, я не знаю. Но если у вас новее (GCN 2-го поколения или новее), то hipTensorFlow (v1.0.1), работающий на ROCm, работал довольно хорошо.

@briansp2020 А, да, я видел работу AMD над ROCm. К сожалению, они поддерживают только Linux, и даже не похоже, что поддержка какой-либо другой ОС включена в их дорожную карту. Я надеюсь на что-то, что поддерживает Windows.

@mjmax Есть ли какой-либо пакет tensorflow с ускорением на GPU для Windows? Я подумал, что если вы хотите углубленное обучение с GPU-ускорением, Linux — единственный выбор. Если бы TensorFlow был портирован на OpenCL, облегчил бы он перенос на Windows? Я не уверен, почему TensorFlow недоступен в Windows с ускорением GPU, когда там поддерживается CUDA.

Я думаю, что это уже не по теме, но если кто-нибудь знает о TensorFlow и/или PyTorch для Windows с ускорением на GPU, я бы тоже хотел об этом узнать...

@briansp2020 Насколько мне известно, Tensorflow уже поддерживает ускорение графического процессора Nvidia в Windows.

CL tensofrflow уже запутался в linux, не ждите ничего в ближайшее время.
Если вы хотите что-то там ускорить, есть только plaidML.
(и, пожалуйста, у нас уже 500 комментариев.. давайте постараемся публиковать только в случае действительной необходимости)

@mirh OpenCL Caffe работает в Windows. Конечно, это не TensorFlow с точки зрения функций, но довольно надежный для программного обеспечения, которое нужно развертывать повсюду.

Как насчет замены порта openCL на порт HIP, поддерживаемый AMD?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

Ха-ха! @LifeIsStrange Жизнь на самом деле очень странная... Вы работаете в маркетинговой команде AMD HiP? :-)
Пожалуйста, посмотрите тему этого выпуска: "Поддержка OpenCL".

Это означает, что речь идет о стандарте Khronos https://en.wikipedia.org/wiki/OpenCL (и другой стандарт SYCL от рабочей группы OpenCL Khronos появляется в конце раздела «Обзор»).

Конечно, есть мир за пределами этого номера, но он... снаружи ! :-)

Пожалуйста, постарайтесь не увеличивать бездумно энтропию вселенной, размещая несколько случайных постов в этом и без того слишком длинном обсуждении... :-)
Этот комментарий относится и к некоторым другим авторам здесь, не только к вам, кстати.
Это проблема GitHub для решения технической проблемы: запуск TensorFlow на устройствах, поддерживающих стандарт OpenCL, а не страница FaceBook о том, как людям нравятся или не нравятся инструменты A или B. :-)
Но, пожалуйста, не стесняйтесь присылать некоторые коммиты git, связанные с этой проблемой, которую мы можем посмотреть...

Существует форк TensorFlow с поддержкой OpenCL https://github.com/hughperkins/tf-coriander .

И, конечно же, работа @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

ИМХО, смешно, что мейнстримные ТФ до сих пор не слили свою работу.

Сосредоточено ли здесь на том, чтобы заставить его работать так, как он есть, OpenCL, или на том, чтобы заставить его работать быстрее? Я бы предпочел не священную войну, а сосредоточился на том, чтобы заставить ее работать быстро на нескольких графических процессорах. LifeIsStrange сосредоточен на том, чтобы заставить его работать на графических процессорах AMD, и тогда HIP имеет смысл. Для других основное внимание уделяется тому, чтобы заставить его работать на графических процессорах Intel или Android, и тогда OpenCL имеет гораздо больше смысла. GPU-языки - это беспорядок, поэтому, пожалуйста, будьте практичны,

Если я прочитал некоторые комментарии здесь, производительность - это проблема с портами OpenCL. Но, к сожалению, я не вижу много тестов вокруг. Есть ли другие тесты, кроме этого? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

Насколько я понимаю, бенчмаркинг сложен, если вы сравниваете CUDA с OpenCL, потому что вы должны использовать другое оборудование. Предположительно, nVidia намеренно сделала/допустила некоторую поломку своей реализации OpenCL, поэтому бенчмаркинг на одном и том же оборудовании всегда будет приводить к тому, что CUDA будет выглядеть великолепно.

12 февраля 2018 г., 14:26:11 GMT+00:00, [email protected] написал:

Сосредоточено ли здесь на том, чтобы заставить его работать так, как он есть, OpenCL, или
заставить его работать быстрее? Я бы предпочел там не священную войну, а
сосредоточившись на том, чтобы заставить его работать быстро на нескольких графических процессорах. LifeIsStrange's
основное внимание уделяется тому, чтобы заставить его работать на графических процессорах AMD, а затем HIP делает хорошо
смысл. Для других основное внимание уделяется тому, чтобы заставить его работать на графических процессорах Intel или
Android, а затем OpenCL имеет гораздо больше смысла. GPU-языки — это
беспорядок, поэтому, пожалуйста, будьте практичны,

Если я прочитаю некоторые комментарии здесь, производительность - это проблема с
Порты OpenCL. Но, к сожалению, я не вижу много тестов вокруг.
Есть ли другие тесты, кроме этого?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-364936498

--
Отправлено с моего устройства Android с помощью K-9 Mail. Пожалуйста, простите меня за краткость.

Сравнение только двух чисел не дает никакой информации — кого волнует, работает ли OpenCL на NVidia с половинной скоростью, если на других графических процессорах он работает с 4-кратной скоростью?

Я думаю, нам понадобятся эти тесты:

1. CUDA на графических процессорах NV (эталонные тесты)
2. https://github.com/hughperkins/tf-coriander на графических процессорах AMD, Nvidia и Intel
3. https://github.com/benoitsteiner/tensorflow-opencl на графических процессорах AMD, Nvidia и Intel
4. https://github.com/lukeiwanski/tensorflow на графических процессорах AMD, Nvidia и Intel

Референсные тесты легко найти. У нас есть несколько высокопроизводительных графических процессоров, поэтому нужно только место для ввода чисел (со ссылками на строительные документы).

Поддержка OpenCL Это должно стать правдой.

cuda слишком ограничен, и nvidia не хочет им делиться.
cuda работает только для Nv gpus.
это тупик для TensorFlow,
если выйдет другой «TensorFlow», но с большей поддержкой, чем TensorFlow.
если TensorFlow по-прежнему поддерживает только cuda в Windows.
вы должны понимать, что TensorFlow не единственный выбор.

Почему OpenCL лучше, чем HIP? Я думаю, что OpenCL не набрал обороты, и поддержка OpenCL на данный момент, вероятно, является контрпродуктивной и требует ресурсов для всего сообщества/индустрии. Я бы предпочел, чтобы TensorFlow напрямую поддерживал HIP и позволял компилятору/инструменту/библиотеке позаботиться о переносимости.

Не лучше ли, чтобы программное обеспечение поддерживало 1 язык/модель программирования?

Программное обеспечение должно поддерживать то, что оно должно поддерживать, чтобы охватить каждый вариант использования.
HIP — это все прибамбасы (по крайней мере, на бумаге), если у вас есть поддерживаемое оборудование. Но в этом мире есть не только «более новые карты AMD и nvidia».

Теперь, пожалуйста, ради бога, жалуйтесь сюда на любые проблемы с этим.
А вот для всех остальных интересующихся продолжение этого выпуска.

Я думал, что SPIR-V напрямую заменит CUDA в качестве кросс-аппаратной альтернативы:
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

Почему Google до сих пор использует CUDA?

Это может помочь?

Генерация случайных чисел OpenCL (Томас Ван):

uint wang_hash(uint seed)
{
               seed = (seed ^ 61) ^ (seed >> 16);
               seed *= 9;
               seed = seed ^ (seed >> 4);
               seed *= 0x27d4eb2d;
               seed = seed ^ (seed >> 15);
               return seed;
}

void wang_rnd_0(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(id);
               intSeeds[id]=rndint;
}

float wang_rnd(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(intSeeds[id]);
               intSeeds[id]=rndint;
               return ((float)rndint)/(float)maxint;
}


// initialize each thread's own random number seed
__kernel void rnd_0(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               wang_rnd_0(intSeeds,id);     
}

// get a new random value by each thread
__kernel void rnd_1(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               float randomFloat=wang_rnd(intSeeds,id);
}

OpenCL SHA3hashing (забыл, кто это написал)

https://gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Удалите правопреемника, так как для этого выпуска требуются сторонние дополнения. В противном случае удалите метку contributions welcome . Спасибо.

Удалите правопреемника, так как для этого выпуска требуются сторонние дополнения. В противном случае удалите метку contributions welcome . Спасибо.

В интересах Google поддерживать OpenCL,
имея конкретное аппаратное обеспечение (компании/бренда/поставщика) в качестве зависимости для вашего программного обеспечения, вы заставляете себя платить больше за оборудование, рыночная конкуренция снижает затраты.
Google всегда ориентировался на массовое оборудование с самого начала, которое было и по-прежнему имеет решающее значение для успеха Google (доминирование на рынке), имея более низкие эксплуатационные расходы центра обработки данных, позволив предлагать революционно щедрые практически бесплатные услуги, такие как Gmail (пространство для хранения) и Google Photos (хранилище). пробел и автоматическая пометка).

@wesamco Нет, это не обязательно в интересах Google. Они делают свое собственное оборудование — что-то под названием «TensorBoard», IIRC. Они могут обойти OpenCL и CUDA/CUDnn и заставить плату запускать необработанный код TensorFlow.

необработанный код TensorFlow.

Нет такого понятия – это не то же самое, что необработанная пища. TPU нуждаются в собственной DNN-библиотеке, которая обрабатывает различные типы вызовов.

Кажется, пришло время снова сжать приведенное выше обсуждение в один список:

• CodePlay работает над бэкендом SYCL
• Хью Перкинс работает над tf-кориандром
• AMD работает над серверной частью HIP
• PlaidML на данный момент поддерживает только процессоры.
• Статус поддержки графических процессоров Intel неясен.

Так что выбирайте понравившийся проект и начинайте его поддерживать. Может быть, каждая из групп может дать статус-апдейт по своему проекту?

Поймите, что OpenCL был преобразован из полноценного языка в определение языка/аппаратную спецификацию, которая представлена ​​в SPIRV (ядрах), которые затем могут быть запущены поверх платформы, такой как драйверы OpenCL, а позже также на драйверах Vulkan. (платформы). Таким образом, поддерживая SYCL, вы также поддерживаете OpenCL.

Идеальное резюме, но plaidml работает и на GPU.
Просто на данный момент они являются бэкендом для keras, а не для tensorflow. Так что это своего рода ОТ там.

Всем привет,
@VincentSC спасибо за отличный итог различных усилий!

Так что выбирайте понравившийся проект и начинайте его поддерживать. Может быть, каждая из групп может дать статус-апдейт по своему проекту?

Подход SYCL теперь поддерживает множество платформ/устройств. Из тех, что я могу отметить, это:

• Графические процессоры AMD (FirePro W8100, R9 Nano и R9 серии 380) Инструкции доступны здесь или здесь
• Инструкции для ARM Mali (HiKey 960) доступны здесь
• Графический процессор Intel (серия SkyLake) с драйвером Intel NEO OpenCL

Что касается AMD, то на данный момент упомянутые выше графические процессоры используют драйверы AMDGPU-Pro 17.40-xxx с включенным устаревшим OpenCL.
Я не вижу какой-либо очевидной причины, по которой другие серии не будут работать (при условии, что SPIR/SPIR-V поддерживается, т.е.)

Основной платформой, на которой мы сосредоточены, является Linux, однако мы продолжаем работать над поддержкой Windows в будущем. Мы не планируем поддерживать OSX в ближайшем будущем. Я знаю грустное лицо.

Мы сосредоточены на повышении производительности CNN. Текущая производительность неоптимизирована и далеко не там, где мы видим ее окончание. Тем не менее, мы уже превзошли производительность ЦП для большинства моделей на разных целях.

Чтобы ускорить цикл разработки и сократить общее время компиляции TensorFlow (а также улучшить переносимость), мы работаем над библиотеками Eigen, BLAS и DNN.
Эти библиотеки направлены на решение проблемы производительности, а также на создание экосистемы переносимых библиотек, которые можно легко интегрировать в сложные проекты, такие как TensorFlow.

Ниже приведены графики производительности, которыми мы можем поделиться в настоящее время. Они взяты из моего форка https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu по адресу 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
Используемый бенчмарк https://github.com/tensorflow/benchmarks .

График нормализован по результатам Intel i7-4790K.

Мы медленно вносим изменения в Eigen, как только это произойдет, мы будем следовать с TensorFlow.

Надеюсь, это поможет,
Люк

Для глубокого обучения на мобильных устройствах с поддержкой GPU/OpenCL вы можете проверить MACE , который оптимизирован для графических процессоров Adreno, Mali и PowerVR. Вот некоторые результаты тестов .

@keryell @benoitsteiner , какая версия tensorflow и trisycl требуется для интеграции. У меня возникли проблемы с созданием тензорного потока (1.9) с последней версией трицикла.

К сожалению, последний TensorFlow использует более продвинутые функции, чем текущий triSYCL, поэтому вам нужно использовать ComputeCpp, в настоящее время единственную полностью совместимую реализацию SYCL...

Tensorflow поддерживается Google Brain, а Google сотрудничает с nVidia, я думаю, что мы не будем ожидать от Tensorflow поддержки OpenCL.
Необходимы большие усилия сообщества OpenCL

Пожалуйста, поддержите OpenCL!

Нам тоже больше подходит OpenCL.

@Makhaon Я тоже. Я не могу позволить себе купить машину с графической картой NVIDIA.

Помимо двух вышеприведенных сообщений, я хотел бы добавить, что теперь графические процессоры AMD Vega (включая те, что внутри APU Raven Ridge) могут выполнять FP16 в два раза быстрее FLOPS, поэтому, если бы TF мог их поддерживать (через OpenCL), это действительно помогло бы людям с меньше бюджета. Кроме того, многие из этих людей будут студентами, и если мы заставим их использовать TF в качестве отправной точки их путешествия по DNN, они, вероятно, останутся с TF в будущем и даже расскажут другим о TF; это отличный способ помочь расширить этот проект.

Я думаю, что эта ветка в основном бессмысленна для разработчиков (слишком много шума - и я добавлю еще ;-), но я думаю, что многие комментарии упускают суть:
Если вы хотите запустить Tensorflow с картами AMD, OpenCL — это НЕ то, что вам нужно — перейдите на https://github.com/ROCmSoftwarePlatform/ и установите стек ROCm. Насколько я знаю, текущая стратегия AMD основана на ROCm вместо OpenCL для Tensorflow/pytorch .

Универсальный OpenCL требовал слишком много обслуживания/не давал достаточного прироста производительности, чтобы быть выгодным для AMD. Поэтому этот билет интересен только в том случае, если вы используете (например) платформу ARM, которая использует только OpenCL.

(Отказ от ответственности: просто посторонний, не имеющий реального отношения к разработке Tensorflow, поэтому, возможно, приведенная выше информация совершенно неверна и вводит в заблуждение. Не стесняйтесь бить меня, если вы знаете лучше.)

Просто мысль, а как насчет llvm с новой разгрузкой графического процессора? Это обеспечило бы высокий уровень абстракции между тензорным потоком и кодом, специфичным для cuda.

Как насчет всех вас, прочитавших всего 10 постов выше и заметивших, что уже есть форк от lukeiwanski/codeplaysoftware, который вы можете попробовать?
(также снимаю шляпу перед xiaomi за то, что однажды внесла серьезный вклад в работу с открытым исходным кодом)

@FelixSchwarz Просто чтобы вы знали, что ROCm использует OpenCL, это драйвер OpenCL пользовательского пространства AMD в Linux (именно поэтому он не поддерживает Windows), поэтому, если вы не знаете, как работает экосистема драйверов AMD в Linux, у них есть их драйверы на стороне ядра AMDGPU и AMDKFD (которые теперь объединяются в AMDGPU), затем есть драйверы пользовательского пространства RadeonSI (для OpenGL), RadV/AMDVLK (для Vulkan) и ROCm (для OpenCL).

Судя по динамике этого бага и других форков, Google не заинтересован в этом и никогда не будет реализовывать это в официальном репозитории. Я бы проголосовал за то, чтобы закрыть эту тему (или заблокировать) вообще, чтобы не давать никому ложных надежд.

Проблема должна быть здесь, чтобы хотя бы указать здесь всех людей, которые будут
неизбежно открыть его снова.

В сб, 15.09.2018, 09:45 Антон Кочков[email protected] написал:

Судя по динамике этого бага и других форков у гугла ноль
интерес к этому и никогда не будет реализовывать это в официальном
репозиторий. Я бы проголосовал за то, чтобы закрыть эту тему (или заблокировать ее) вообще, чтобы
не давать ложных надежд всем.

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Существует TensorRT, который поддерживает Movidius Pi Hat. И этот Movidius Pi Hat — это «AIY Vision Kit» от Google за 45 долларов. Google ссылается на Target, чтобы купить его.

Это не связано с CUDA или Nvidia? Говорит, что использует чип Intel. По своей сути, может быть, чип является FPGA? Кто-нибудь знает что-нибудь еще об этом?

Я довольно много знаю о большом модуле Movidius — он предназначен только для вывода и запускает предварительно скомпилированные модели TensorFlow или Caffe. IIRC они все в 16-битном режиме.

Чип Movidius сам по себе намного мощнее, но вы должны быть квалифицированным партнером, чтобы получить SDK.

Есть какая-то ссылка для других, которые пытаются иметь тензор opencl:

https://github.com/hughperkins/tf-кориандер
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 (репозиторий устарел)
https://github.com/codeplaysoftware/tensorflow
Возможно, стоит также проверить:

https://documen.tician.de/pyopencl/
https://pypi.org/project/DeepCL/
https://www.khronos.org/sycl/

Не стесняйтесь добавлять рабочие проекты.

Есть ли обновление? Этой проблеме более 3 лет.

ДА ЕСТЬ ПРОСТО ПОСМОТРИТЕ НА ПОСЛЕДНЮЮ ГРУСТКУ ПОСТОВ.

@filips123 нет, обновлений нет и не будет в обозримом будущем - вероятность этого ниже, чем вероятность вторжения инопланетян и поиска способа путешествовать во времени.

Эта инициатива Intel PlaidML работает достаточно хорошо, ее стоит проверить.
https://github.com/plaidml/plaidml
Он работает на opencl или металле на Mac. Он работает с графическим процессором AMD Macbook Pro, что я и искал.
Между тем, не могли бы вы, ребята, помочь проголосовать за поддержку Pytorch в PlaidML? https://github.com/plaidml/plaidml/issues/63

PlaidML, безусловно, хорош и денди (я, например, каким-то образом мог получить больше производительности на графическом процессоре nvidia на opencl, чем на самом tf cuda).
Но это бэкенд для keras? В полной замене тензорного потока, который вы знаете, это репо, в котором мы это обсуждаем?
(насколько я понимаю, последние версии tf могут экспортировать модели напрямую в keras? так вот что..)

В любом случае, в четвертый чертов раз, если вам нужно недавнее решение для opencl и что-то, что все еще активно разрабатывается ( а также вещь с реальными шансами быть объединенной здесь в один прекрасный день), есть просто стек кода.
Опять таки:
https://developer.codeplay.com/computecppce/latest/tensorflow-обзор
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

PlaidML, безусловно, хорош и денди (я, например, каким-то образом мог получить больше производительности на графическом процессоре nvidia на opencl, чем на самом tf cuda).
Но это бэкенд для keras? В полной замене тензорного потока, который вы знаете, это репо, в котором мы это обсуждаем?
(насколько я понимаю, последние версии tf могут экспортировать модели напрямую в keras? так вот что..)

Во всяком случае, в четвертый раз, если вам нужно свежее решение для opencl и что-то, что все еще активно разрабатывается (а также_ вещь с реальными шансами, что однажды ее объединят здесь по-настоящему), есть просто стек кода.
Опять таки:
https://developer.codeplay.com/computecppce/latest/tensorflow-обзор
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

Мои извинения, я не понял, что нет поддержки тензорного потока. Мой предполагаемый мозг думал, что поддержка keras gpu == поддержка tensorflow.

PlaidML очень крутой. Работает на Керасе.
Конечно, мне пришлось перенести некоторый код tf в чистый keras, чтобы работать с бэкэндом plaidML (например, tf.image.ssim)
Но результат - мой код работает на картах NVIDIA и AMD.

Кроме того, plaidML — это рай для исследователей. Он автоматически генерирует градиент для любой функции, которую вы напишете на языке «Tile», и будет работать на вашем графическом процессоре со скоростью тензорного потока 80%.

Поэтому я не могу понять, почему исследователи машинного обучения до сих пор используют PyTorch? Давайте поднимем науку о машинном обучении с помощью plaidML от Intel?

@iperov Хотите знать, почему практически никто не использует PlaidML?

1. Он работает ужасно медленно на реализациях AMD OpenCL по сравнению с бэкэндом Tensorflow CUDA, поэтому есть как минимум половина причин для его использования. Производительность настолько плоха, что использование Tensorflow с процессорами конкурентоспособно или даже превосходит их оборудование с использованием PlaidML?

2. Никто не заинтересован в поддержке своего специализированного языка программирования Tile, который мог бы придумывать только кто-то вроде профессора чистой математики, поэтому качество кода PlaidML просто летит насмарку, и ни один серьезный программист в здравом уме не захочет иметь дело с чрезмерно умным кодом...

3. Это в значительной степени связано с # 2, но с тех пор, как Intel выкупила Vertex.AI, они больше не заботятся о PlaidML. Решение Intel для машинного обучения с ускорением вычислений на GPU представляет новый компилятор специально для глубокого обучения, теперь известный как nGraph , для использования Tensorflow, PyTorch или других сред глубокого обучения в качестве серверной части для них. У них больше нет причин продолжать разработку PlaidML в качестве своего посредника, когда у них есть nGraph...

Люди используют PyTorch по другим причинам, таким как ремонтопригодность или другие функции, поэтому, подводя итог, PlaidML — это инструмент Intel, и они, вероятно, не намерены использовать его в каких-либо заключительных частях своих планов. Текущая серверная часть nGraph для графического процессора Intel основана на OpenCL 2.1, совместимую реализацию которой имеет только Intel, поэтому Intel существует только для того, чтобы заботиться о себе, а не исключительно для улучшения машинного обучения. Когда Intel продолжит разработку nGraph, я не вижу, чтобы они продолжали основывать свои серверные части GPU только на OpenCL 2.1, поскольку многие фреймворки глубокого обучения имеют шаблонные ядра, которые несовместимы с моделями программирования с отдельными исходными кодами OpenCL, Metal или Vulkan, так что, вероятно, только в целях эксперимента. Окончательный бэкэнд Intel для графического процессора, вероятно, будет основан на SYCL 2.2 или на чем-то совершенно другом, таком как OpenMP, и, возможно, они даже предложат решение для конкретного поставщика ...

Что касается AMD, кого это волнует? OpenCL для них не имеет значения, и они, наконец, показывают некоторые результаты своей работы над HIP...

@iperov Хотите знать, почему практически никто не использует PlaidML?

1. Он работает ужасно медленно на реализациях AMD OpenCL по сравнению с бэкэндом Tensorflow CUDA, поэтому есть как минимум половина причин для его использования. Производительность настолько плоха, что использование Tensorflow с процессорами конкурентоспособно или даже превосходит их оборудование с использованием PlaidML?
2. Никто не заинтересован в поддержке своего специализированного языка программирования Tile, который мог бы придумывать только кто-то вроде профессора чистой математики, поэтому качество кода PlaidML просто летит насмарку, и ни один серьезный программист в здравом уме не захочет иметь дело с чрезмерно умным кодом...
3. Это в значительной степени связано с # 2, но с тех пор, как Intel выкупила Vertex.AI, они больше не заботятся о PlaidML. Решение Intel для машинного обучения с ускорением вычислений на GPU представляет новый компилятор специально для глубокого обучения, теперь известный как nGraph , для использования Tensorflow, PyTorch или других сред глубокого обучения в качестве серверной части для них. У них больше нет причин продолжать разработку PlaidML в качестве своего посредника, когда у них есть nGraph...

Люди используют PyTorch по другим причинам, таким как ремонтопригодность или другие функции, поэтому, подводя итог, PlaidML — это инструмент Intel, и они, вероятно, не намерены использовать его в каких-либо заключительных частях своих планов. Текущая серверная часть nGraph для графического процессора Intel основана на OpenCL 2.1, совместимую реализацию которой имеет только Intel, поэтому Intel существует только для того, чтобы заботиться о себе, а не исключительно для улучшения машинного обучения. Когда Intel продолжит разработку nGraph, я не вижу, чтобы они продолжали основывать свои серверные части GPU только на OpenCL 2.1, поскольку многие фреймворки глубокого обучения имеют шаблонные ядра, которые несовместимы с моделями программирования с отдельными исходными кодами OpenCL, Metal или Vulkan, так что, вероятно, только в целях эксперимента. Окончательный бэкэнд Intel для графического процессора, вероятно, будет основан на SYCL 2.2 или на чем-то совершенно другом, таком как OpenMP, и, возможно, они даже предложат решение для конкретного поставщика ...

Что касается AMD, кого это волнует? OpenCL для них не имеет значения, и они, наконец, показывают некоторые результаты своей работы над HIP...

Как насчет всех графических процессоров внутри ручных машин, таких как мобильные телефоны, Raspberry Pi Odroid и т. Д.?
Они не поддерживают opencl?
Google должен позаботиться о вставке тензорного потока на GPU на Android.
Самые большие библиотеки для обучения нейронных сетей работают только на графическом процессоре Nvidia, это просто делает графический процессор Nvidia все более и более дорогим (потому что люди и компании покупают его только для профессионального обучения нейронных сетей), тогда Google потеряет больше денег таким образом.

@Degerz, с какой ты планеты?
Как вы можете сравнить tf-CPU и AMD GPU?
AMD GPU на plaidML x30 быстрее, чем tf-CPU

1. Он работает ужасно медленно на реализациях AMD OpenCL по сравнению с бэкэндом Tensorflow CUDA, поэтому есть как минимум половина причин для его использования.

в моих тестах дипфейков OpenCL медленнее всего на 20%, но в некоторых мини-сетях OpenCL на 20% БЫСТРЕЕ.

У моего проекта DeepFaceLab много пользователей, которые ждали поддержки AMD. Сколько людей обрадовались, когда дипфейки наконец-то можно будет обучать на картах AMD.
Также plaidML — единственный бэкенд для keras, который поддерживает AMD/IntelHD из коробки.
Если появится новый бэкенд AMD для keras, конечно мой проект перейдет на него.
У PyTorch нет будущего.

Что поддерживать в plaidML? Операции автодифференцируемы, обслуживать нечего.

Язык программирования плитки, на котором мог бы состряпать только кто-то вроде профессора чистой математики

Машинное обучение придумали профессора математики, не так ли?

@talregev А как насчет ARM или Broadcom? Первый, вероятно, имеет некачественную реализацию OpenCL, а последний даже официально не предоставляет драйверы OpenCL! В обязанности Google не входит создание и поддержка компетентного вычислительного стека для поставщиков оборудования...

@iparov Вы понимаете, что обучение нейронных сетей с встраиванием слоев в PlaidML болезненно, верно? PlaidML также имеет множество других ограничений, таких как не совсем подходит для DenseNets или тот факт, что его графики вычислений являются статическими, и хорошо ли PlaidML работает с RNN?

Что касается вашего проекта, не беспокойтесь об этом. Вы перейдете к чему-то лучшему, например, Tensorflow, поскольку AMD вскоре предложит для него собственный бэкэнд GPU, как только MIOpen получит восходящий поток, который представляет собой их ускоренную графическим процессором библиотеку примитивов для глубоких нейронных сетей, аналогичную библиотеке cuDNN их конкурента, обе из которых оставят PlaidML в пыль с точки зрения производительности. Кого вообще интересуют iGPU Intel? Если Intel действительно стремится обеспечить высокопроизводительное глубокое обучение на своем будущем дискретном графическом оборудовании, тогда они предложат вариант с одним источником, как это делали другие (AMD/HIP и Nvidia/CUDA) до них...

У PyTorch нет будущего.

сильно завидуете? PyTorch примерно в 10 раз популярнее, чем PlaidML, новейшие методы DL легко реализуются на PyTorch, множество разных участников и активно разрабатывается Facebook, в то время как Intel не вносила вклад в PlaidML почти месяц?

Что поддерживать в plaidML? Операции автодифференцируемы, обслуживать нечего.

Я так понимаю, PlaidML не должен получать никаких новых исправлений или новых функций в будущем? Если вы не видите смысла в улучшении кода, то нет смысла убеждать вас признать вопиющие недостатки PlaidML...

Машинное обучение придумали профессора математики, не так ли?

Это не означает, что мы должны использовать любой язык программирования, который они составляют, особенно в случае с Tile, где элегантность явно предпочтительнее читабельности. Неудивительно, почему так много потенциальных участников боятся вносить свой вклад...

Господи, я желаю вам, ребята, STFU и вместо этого вернуться к работе. Придется отписаться от тикета, так как невыносимо получать письма с флейм варами. Жаль, что мейнтейнеры не заглушают ветку.

@gunan @caisq @sanjoy Не могли бы вы что-нибудь с этим сделать?