Es extraño que Google abandonó OpenCL abierto por CUDA patentado.

Como mínimo, la biblioteca Eigen tendría que ser compatible con OpenCL.

:+1:

:+1:

:+1:

pulgar arriba y todo eso.

Estaré interesado en expandir Tensor Flow con OpenCL. Como ya hemos lanzado OpenCL caffe. https://github.com/amd/OpenCL-caffe. ¿Es de esperar que pueda integrarse de manera ligera? ¿Hay alguien interesado en trabajar juntos en esto?

@gujunli Es bueno ver a AMD aquí. /cc @naibaf7 @lunochod

sería genial.

:+1:

/cc @lukeiwanski para Eigen/OpenCL/SYCL

@gujunli Ciertamente estaría interesado en contribuir. Por favor, avíseme cuando planea comenzar.

Hola a todos,

Aquí en Codeplay estamos analizando el tensor de Eigen que se ejecuta en GPU usando SYCL (una capa moderna de C++ sobre OpenCL). Por lo que hemos recopilado hasta ahora, el diseño del tensor de GPU está muy relacionado con CUDA y requerirá cambios de interfaz para otro modelo de programación y, en particular, una versión SYCL y OpenCL 1.2.

Si alguien está interesado en profundizar/ayudar, ciertamente estamos interesados ​​en contribuir.

Gracias,
Lucas

@lukeiwanski Gracias por los comentarios. Creo que @benoitsteiner trabajó en la parte de extensión de tensor de eigen.

:+1: Puedo ayudar a codificar algunos OpenCL/SYCL si alguien hace un plan, divide el trabajo en tareas, etc. Recomiendo usar Boost.Compute como contenedor para OpenCL (facilita la ejecución de kernels, las pruebas y las plantillas).

+1

:+1:

Hola a todos,

Solo para mantenerlo informado, todavía estamos investigando cómo podemos cambiar la interfaz Eigen para que se ajuste mejor al modelo de programación SYCL/OpenCL 1.2.
Una vez que tengamos un enfoque razonable que apunte a modelos de programación heterogéneos (no solo OpenCL/SYCL), crearemos una propuesta.

Gracias,
Lucas

Por favor, mantenme actualizado. Desarrollé opencl-caffe para AMD. yo tambien estoy mirando
flujo tensor.

Gracias.
Junlú
El 8 de diciembre de 2015 a las 10:19 a. m., "Luke Iwanski" [email protected] escribió:

Hola a todos,

Solo para mantenerlo informado, todavía estamos investigando cómo podemos cambiar el
Interfaz Eigen para adaptarse mejor al modelo de programación SYCL/OpenCL 1.2.
Una vez que tengamos un enfoque razonable, crearemos una propuesta.

Gracias,
Lucas

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-162967662
.

/cc @ptillet @gongzg ¿Hay algún interés en esto por parte de Intel? Realmente espero que no fragmentemos OPENCL aquí como en Caffe, donde tenemos una bifurcación de AMD, relaciones públicas no fusionadas de Intel, otra relación pública semi-no oficial de AMD y una relación pública de usuario de etapa larga (más dos viejos esfuerzos de Opencl abandonados). Si alguien está interesado en la historia, puede echar un vistazo a los comentarios de https://github.com/BVLC/caffe/pull/2610 .

@bhack Tenemos interés en esto. Gracias por hacérmelo saber. Si hay una propuesta para la implementación de OpenCL/SYCL de Eigen, veremos qué podemos hacer desde el lado de Intel.

:+1:

Una iniciativa interesante en https://github.com/ptillet/isaac también si aquí confiamos en la extensión del tensor Eigen.

También me gustaría contribuir. @benoitsteiner puedes organizarlo?

Esto se incluyó en la hoja de ruta, pero también se etiquetó como contribución, por lo que una dirección/arranque podría ser realmente útil.

Puedo contribuir a organizarlo. quién es responsable del soporte de OpenCL en
¿Flujo tensor ahora?

Muchas gracias.
junli

El martes 19 de enero de 2016 a las 7:50 a. m., bhack [email protected] escribió:

Esto se incluyó en la hoja de ruta, pero también se etiquetó como contribución, por lo que un
direction/bootstrap podría ser realmente útil.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172894538
.

---

Junli Gu--谷俊丽
Laboratorio de Ciencias Coordinado
Universidad de Illinois en Urbana-Champaign

---

Simplemente asumí a Benoit porque él mismo asignó la función, ¡pero creo que lo tienes, Junli! ¿Quizás comenzar con un correo electrónico o un foro de partes interesadas?

@benoitsteiner sabe más sobre las partes interesadas que pueden no haber mostrado
en este hilo (o este problema). Esperaría a que se coordine para hacer
Seguro que evitamos duplicar el trabajo.

El martes 19 de enero de 2016 a las 11:42 a. m. Dan McLaughlin [email protected]
escribió:

Simplemente asumí a Benoit porque él mismo asignó la función, pero creo
lo tienes Junli! Tal vez comience con un correo electrónico o un foro de
¿partes interesadas?

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172963537
.

Estoy interesado. ¿Hay alguna hoja de ruta?

El 19 de enero de 2016, a las 11:46 a. m., Martin Wicke [email protected] escribió:

@benoitsteiner sabe más sobre las partes interesadas que pueden no haber mostrado
en este hilo (o este problema). Esperaría a que se coordine para hacer
Seguro que evitamos duplicar el trabajo.

El martes 19 de enero de 2016 a las 11:42 a. m. Dan McLaughlin [email protected]
escribió:

Simplemente asumí a Benoit porque él mismo asignó la función, pero creo
lo tienes Junli! Tal vez comience con un correo electrónico o un foro de
¿partes interesadas?

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-172963537
.

—
Responda a este correo electrónico directamente o véalo en GitHub.

¿Hay una lista de bibliotecas de dependencia de CUDA en las que se basa Tensorflow?

Esto ayudaría a ver si podemos tener alternativas inmediatas de OpenCL.

@hsaputra
Hay clFFT, clBLAS (alternativamente ViennaCL). El generador de números aleatorios es un poco más complicado (sin curand), use un generador de CPU y transfiéralo a GPU o use otro kernel existente para RNG.

El mayor escollo volverá a ser implementaciones de convolución eficientes (algo así como cuDNN).

Hay experiencia sobre tales temas aquí:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-café

Tensorflow usa la extensión de tensor aguas arriba de Eigen. Entonces creo que se necesita un soporte Opencl/Sycl para Eigen. ver este hilo

Gracias @naibaf7. Sí, no creo que haya una alternativa viable para cuDNN para OpenCL en este momento.

El sitio web http://opencl.org se creó para apoyar proyectos de portabilidad de código abierto como estos. Actualmente estamos instalando todas las herramientas necesarias en el sitio web y tenemos espacio para repositorios en https://github.com/OpenCL/ ; más adelante agregaremos servidores de compilación para probar varios tipos de hardware y podemos brindar nuestra experiencia en cómo escribir código que se ejecuta a toda velocidad en numerosos hardware.

Estamos lanzando una iniciativa de portabilidad para GEGL la próxima semana, pero también nos complace apoyarlo.

@bhack de ese hilo y aquí parece que @lukeiwanski lo está investigando. Creo que tenemos suficientes personas dispuestas a trabajar en ello, solo necesitamos a @benoitsteiner , @lukeiwanski o @gujunli para coordinar. Benoit ha estado callado, tal vez esté de vacaciones.

Me encantaría ayudar a contribuir con esta iniciativa.

Hola a todos,

Coordinaremos el esfuerzo de migrar el módulo tensor de Eigen a SYCL para OpenCL, ya que tenemos algo que funciona principalmente, pero aún no está listo para su revisión.

Estamos a favor de este enfoque, ya que introducirá menos invasión en el código base. SYCL es compatible con el modelo de plantilla de C++ de fuente única que ya utiliza Eigen.

El diseño de la hoja de ruta está en progreso, por lo que no debería tardar demasiado.

Gracias,
Lucas

@lukeiwanski ¿Estás trabajando o en contacto con upstream? ¿Crees que será aceptado aguas arriba en Eigen?

+1

Buenas noticias @lukeiwanski , háganos saber cualquier ayuda que necesite.

Supongo que está utilizando su propia implementación de SYCL. ¿Estará disponible para desarrolladores/investigadores? ¿En qué plataformas?

@lukeiwanski SYCL parece ser el camino correcto dada la cantidad de metaprogramación de plantilla involucrada con Eigen. Soy un desarrollador experimentado de C++ con experiencia en OpenCL obtenida al desarrollar mis propias redes neuronales y biblioteca de álgebra lineal . Me encantaría ayudar con este esfuerzo y comenzar a desarrollar con SYCL.

@bhack Estamos en contacto con @benoitsteiner , pero discutiremos nuestra propuesta con los mantenedores aguas arriba antes de invertir demasiado esfuerzo.

@DanMcLaughlin , @ville-k Estamos desarrollando nuestra implementación de SYCL, ComputeCpp (https://www.codeplay.com/products/computecpp). Para obtener más información, ¿puede ponerse en contacto conmigo fuera de la lista a través de la dirección de correo electrónico en mi perfil?

@lukeiwanski , ¿hay alguna actualización/estimación con respecto a los planes?

+1.
Tengo una GPU AMD y una GPU Intel en la computadora portátil. Creo que ambos tienen controladores OpenCL y el soporte de AMD parece ser mucho mejor. Tendría un mayor rendimiento, porque tengo 2 dispositivos OpenCL. Espero que lo haga escalar con dispositivos OpenCL.

Hola a todos,

¡Gracias por el interés!
En este punto, estamos configurando nuestra infraestructura de prueba para asegurarnos de que nada de lo que hagamos introduzca una regresión.
Estamos en contacto con @benoitsteiner para asegurarnos de que estamos sincronizados con lo que ha hecho hasta ahora.

Todavía estamos compilando una hoja de ruta para el proceso de integración; debe hacerse en un par de semanas, ya que hay un par de detalles comerciales que aclarar.

Nuestro objetivo es llevar OpenCL a TensorFlow a través de Eigen para fines de este año.

Gracias,

interesado. me encantaría contribuir.

Ok, en realidad parece que es un esfuerzo de Codeplay con algún tipo de sincronización interna de Google. ¿Cuál es el papel de los suscriptores de AMD e Intel aquí?

/cc @keryell si tiene algún interés en esto del universo SYCL/FPGA

Mis disculpas por no contribuir más a esta discusión recientemente, mi plato ha estado más que lleno en las últimas 2 semanas.

Estaré coordinando el esfuerzo de OpenCL en el lado de TensorFlow. Nuestro pensamiento actual es:

• TensorFlow se basa en c ++ 11 y ha adoptado un enfoque de "fuente única", por lo que SYCL parece encajar perfectamente.
• No tenemos mucha experiencia en OpenCL internamente, por lo que estamos colaborando estrechamente con Codeplay para cerrar esta brecha. En particular, Codeplay actualmente lidera el esfuerzo para agregar soporte para SYCL a la biblioteca de tensores Eigen.
• TensorFlow se basa en la biblioteca cuDNN para calcular convoluciones en GPU NVidia. Si alguien está interesado en contribuir con un equivalente de OpenCL, estaremos encantados de ayudar.

Para ayudar a estructurar el esfuerzo, creé una lista de correo: [email protected].

@bhack estoy seguro de que tengo cierto interés en C++ de gama alta en FPGA :-)
TensorFlow también suena como un buen caso de uso de validación para triSYCL.
Por cierto, si algunas personas aquí están buscando pasantías sobre este tema, tengo algunos puestos. Parece que Codeplay también está buscando a algunas personas, si confío en su sitio web.

Estoy realmente interesado en las opiniones de @karlrupp y @hughperkins . Espero que quieran unirse a la discusión sobre el nuevo grupo de Google.

@benoitsteiner Gracias por la actualización. Sería maravilloso si todos los socios involucrados en @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx, etc.) promovieran una API similar a cudnn de manera estandarizada. Una especie de esfuerzo de estandarización de visión por computadora Khronos openvx pero para aprendizaje profundo.

@bhack ¿Qué nuevo grupo de Google?

Aparte de eso, OpenCL y CUDA son enfoques de programación muy diferentes. CUDA funciona así porque una empresa tiene control total sobre todo, por lo que puede incrustar blobs binarios y quién sabe qué en el ejecutable final. Esto no se puede hacer con OpenCL, a menos que uno siga la ruta de SyCL (tengo mis preocupaciones...) y el proveedor del compilador de SyCL tiene control total sobre todas las arquitecturas de destino posibles (improbable o imposible en la práctica). En general, mi opinión es que una buena biblioteca habilitada para OpenCL necesita más que algunos ajustes aquí y allá. Probablemente no sea lo que querías escuchar, pero me pediste mi opinión :-)

@karlrupp Consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 al final para el grupo de Google.
Le pedí su opinión porque tiene una gran experiencia con ViennaCL interactuando una biblioteca de álgebra con múltiples backends (CPU, GPU, MIC). Tensorflow se basa en la biblioteca Eigein y su nueva extensión de tensor aportada por Google upstream (pero solo con el backend de CUDA). Creo que no han experimentado mucho el escollo que ya has encontrado con ViennaCL en estos años de desarrollo.

@bhack Actualmente estamos en la reunión cara a cara en Seattle esta semana pero, por supuesto, no puedo decir si estamos hablando de bibliotecas DNN o no... :-)

@keryell Intenta impulsar la causa en Seattle ;)

@karlrupp Tiene razón, OpenCL y CUDA son enfoques de programación demasiado diferentes. El aspecto de fuente única que se encuentra, por ejemplo, en CUDA y OpenMP 4.5 es extremadamente poderoso desde la perspectiva de la ingeniería de software. Es por eso que existe este estándar SYCL para los verdaderos programadores de C++. SYCL se puede ver como CUDA con esteroides sin ninguna extensión de idioma y con algunos aspectos de OpenMP (las tareas). Se espera que un compilador de dispositivo SYCL típico genere núcleos SPIR-V.

Sus preocupaciones sobre la portabilidad son un problema menor con el estándar SPIR-V (una especie de equivalente portátil de nVidia PTX/AMDIL/... en el mundo de Vulkan y OpenCL) que es obligatorio aceptar en OpenCL 2.1 y Vulkan. Entonces, la belleza es que si tiene un front-end que genera SPIR-V, no necesita un conocimiento especial de los detalles del hardware para ejecutarlo. Hay un traductor bidireccional de código abierto de Khronos entre LLVM IR y SPIR-V, por lo que abre territorios bastante nuevos.

@keryell Estoy de acuerdo en que SPIR-V es un paso adelante. Sin embargo, no aborda todos los problemas de jitting exhaustivo.

no necesita un conocimiento especial de los detalles del hardware para ejecutar

¿Es esto un copiar y pegar del marketing de OpenCL 1.0, que afirmaba exactamente lo mismo? _siempre_ tendrá que ir a los detalles del hardware subyacente si desea obtener el máximo rendimiento. Este es especialmente el caso en el contexto de contracciones de tensor rápido.

...como @scott-gray demostró con neón

@karlrupp

¿Es esto un copiar y pegar del marketing de OpenCL 1.0, que afirmaba exactamente lo mismo?

Ja ja. :-)

Siempre tendrá que ir a los detalles del hardware subyacente si desea obtener el máximo rendimiento. Este es especialmente el caso en el contexto de contracciones de tensor rápido.

Por supuesto, pero antes de jugar con la optimización de segundo orden, es útil tener la mayor parte del código C++ con plantilla ejecutándose de forma acelerada.

Para la optimización, une sus núcleos binarios optimizados a la NervanaSys o, dado que SYCL es C ++ puro, puede usar asm ("...") con mucho #ifdef para probar la arquitectura de destino. :-) Dicho esto, SPIR-V es en sí mismo extensible y no veo por qué no pudimos poner VHDL o Verilog en línea en algún momento. :-)

Pero más concretamente, la reciente introducción de operaciones de subgrupos debería ayudar a lograr un buen rendimiento de una manera portátil y el uso de funciones ad-hoc integradas simples puede ayudar.

C++ agrega características interesantes de metaprogramación que permiten reemplazar la mayoría de los generadores de código utilizados, como clBLAS u otros marcos, para generar código más adaptado al hardware X o Y.

También N4355 en c ++ 17 podría ingresar al juego tarde o temprano

@karlrupp , @bhack El enfoque de tensorflow es confiar en una abstracción de hardware (el módulo tensor) para la mayoría de las operaciones que necesita una red neuronal típica, mientras que depende de bibliotecas especializadas (como cudnn) para las pocas operaciones que son rendimiento realmente crítico sabio. La abstracción de hardware nos permite implementar la mayoría de las operaciones de TensorFlow una vez y hacer que se ejecuten en un acelerador con un rendimiento más que suficiente.

@bhack Sí, me encantan las matrices multidimensionales. También en nuestro dominio de interés, está el SG14 en el comité de C++ que intenta que todas las personas interesadas en estos temas converjan en el estándar.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Por supuesto, SYCL está en las discusiones. :-)

@benoitsteiner Principalmente en cudnn para agrupación y convolución. Creo que si cada proveedor produce una API con su propio hardware para estas operaciones con su propio ensamblaje binario, no será un enfoque tan escalable. Es por eso que creo que sería mejor estandarizar de alguna manera algunas llamadas API cruciales para el rendimiento.

@keryell Hay temas realmente interesantes para Matrix/Tensor en el nuevo SG14 c ++, especialmente en la agenda de llamadas vectoriales/SIMD. Pero parece que nadie habló de convolución, agrupación y otras interfaces útiles de aprendizaje profundo "estabilizadas". También me parece que en este subgrupo de normalización en concreto hay gente de Nvidia, Intel, Amd, CodePlay etc.. pero no de Google también si está en otros grupos.

:+1:

@bhack Sí, todavía no hay una propuesta de estilo de aprendizaje automático en SG14. Pero la participación es abierta, por lo que puedes enviar algunas propuestas. :-) Pero quizás SG6 (temas numéricos) es más relevante. No creo que tengan su propia lista de correo/foro todavía.

@gujunli ¿OpenCL Caffe se ejecuta en Android? Perdón por preguntar esto aquí, pero no encontré ningún otro lugar para preguntar :) Sería genial con una biblioteca de aprendizaje profundo que se ejecutara en dispositivos Android _y_ podría usar la GPU, pero parece que no hay en este momento. (¡Corrígeme si me equivoco!)

@krikru
La rama oficial (pero experimental) de OpenCL Caffe se puede ejecutar en GPU de Android, sin embargo, el rendimiento en este momento está lejos de ser óptimo. Consulte https://github.com/sh1r0/caffe-android-lib/issues/23 y https://github.com/BVLC/caffe/tree/opencl.

Una alternativa real a cudnn podría ser la extensión de los objetos estándar de OpenVx con soporte para los operadores Tensor, NdConvolution, NdPooling y (probablemente) algún otro operador que podría considerarse estandarizable.
Además, el equipo de cudnn debe elegir qué nuevas API y operadores introducirán en cada versión. Por supuesto, un estándar no puede moverse tan rápido como los lanzamientos de cudnn, pero creo que algunas operaciones y objetos tienen suficiente "historial de citas" para ser estandarizados.

@hughperkins Por el momento, no he probado ninguna biblioteca de aprendizaje profundo; Solo estoy explorando un poco para ver qué biblioteca podría usar potencialmente. ¿Has probado cltorch y DeepCL en Android? Asumí que cltorch funcionó en Android, ya que hay una implementación de Torch que está dedicada específicamente para Android. ¿Y por qué tendría una implementación de este tipo si ya había una que funcionaba en Android _y_ usaba OpenCL, verdad? Pero tal vez debería haberlo sabido mejor.

@hughperkins Por alguna razón, imaginé que torch-android era una implementación oficial de Torch para Android, lo que significa que ninguna otra implementación de Torch (al menos no oficial) probablemente funcionaría sin problemas en Android, incluido cltorch. No sé por qué pensé eso, por supuesto que no tiene ningún sentido.

Bueno... Soumith coordina el desarrollo de la antorcha. Trabaja en Facebook AI Research. Entonces, dado que el repositorio de torch-android pertenece a Soumith, diría que está bastante cerca de ser oficial. Pero tal vez no sea parte del núcleo por alguna razón. Supongo que puede hacer la pregunta como un problema en ese repositorio, o en https://groups.google.com/forum/#!forum/torch7 En realidad, dado que Soumith es la persona principal que maneja las solicitudes en https: //groups.google.com/forum/#!forum/torch7 , creo que probablemente quieras publicar tu pregunta allí.

lo que significa que es probable que ninguna otra implementación de Torch (al menos no oficial) funcione sin problemas en Android, incluido cltorch

Tenga en cuenta que cltorch no es una implementación de torch. Es un complemento, que proporciona OpenCL. Necesitas ambos.

Tenga en cuenta que cltorch no es una implementación de torch. Es un complemento, que proporciona OpenCL. Necesitas ambos.

Ah, gracias por la aclaración.

@naibaf7 ¿La rama de OpenCL Caffe y la implementación de OpenCL Caffe de AMD tienen algo más en común además del nombre? ¿Has comparado los dos o sabes si hay alguna diferencia en el rendimiento? Escribes que la rama OpenCL está lejos de tener un rendimiento óptimo. ¿Qué significa eso y qué sería necesario para mejorarlo? Sería interesante probarlo en Android.

nos estamos saliendo del tema

@bhack Sí, lo siento por secuestrar este hilo. Simplemente no sabía dónde hacer la pregunta.

@krikru
plantee un problema al respecto en la sucursal de Caffe, márquelo con Android y OpenCL. Entonces podemos discutir esto más a fondo. Gracias.

@keryell Parece que la próxima reunión f2f SG14 en marzo será organizada por Google . ¿Habrá algún tensorflow interno allí?

/cc @jfbastien

Quizás @benoitsteiner podría pasar, ya que es local.
Pero antes de este evento está el C++ F2F completo a fin de mes en Jacksonville, Florida.
https://isocpp.org/files/papers/N4568.pdf
Lamentablemente no podré asistir a ninguno de ellos.

No sé si la charla CppCon 2015 sobre matrices multidimensionales de C++ para física computacional y matemáticas aplicadas generó algún seguimiento en papel.

+1

@bhack Gracias por señalar la charla sobre matrices multidimensionales. Es interesante y aborda los problemas reales, pero parece demasiado ad-hoc para ser ratificado en C++ tal como está. Personalmente, uso Boost.MultiArray y confío más en una versión pulida de Boost.MultiArray.

También hay algunos documentos en WG21 . Como puede ver, @jfbastien en Google tiene alguna actividad en WG21 y también ayudó a organizar la reunión SG14 f2f en Google en marzo.

@bhack @keryell Creo que valdría la pena llevar esta discusión a la lista de correo SG14 ya que los detalles no están relacionados con OpenCL/tensorflow.

Sí, probablemente ya no esté tan estrictamente confinado aquí con todos los detalles. Aparte del soporte Eigen/sycl ¿Existe un plan para las llamadas cudnn?

+1 tema muy interesante. Espero que llegue pronto.

Este hilo es muy interesante. He estado tratando de hacer que Caffe funcione en Android. Los resultados parecen ser sorprendentes: el café que se ejecuta con Mali gpu parece ser 2-3 más lento que la cpu, pero aproximadamente 4-5 veces más eficiente energéticamente. La prueba se realizó en Galaxy S6 (Mali T760, Peak Performance 200 GFlops).

Dado que GEMM es el núcleo de la convolución en café, decidí perfilar su desempeño en Android. Parece que ViennaCL no es tan eficiente como algunos núcleos simples. Ahora puedo hacer que la GPU funcione tan rápido como la CPU para matrices grandes (2k x 2k). Esto sigue siendo contraintuitivo, ya que normalmente esperamos que las GPU sean mucho más rápidas.

Ver:
https://github.com/strin/mocha-perfil

Las implementaciones del kernel se pueden encontrar aquí:

Núcleos OpenCL para GEMM: https://github.com/strin/gemm-android

¿Alguna idea?

@strin ¿Ya siguió este hilo https://community.arm.com/thread/4935?

@bhack gracias por compartir. este hilo se ve muy interesante Traté de apagar el DVFS como se sugirió, pero no se observó un rendimiento significativo para sgemm en ViennaCL.

+1

@strin ¿Ha probado la última versión de sgemm en MALI SDK?

¡Tensorflow llega tarde! Ah ah
https://gist.github.com/jarutis/ff28bca8cfb9ce0c8b1a

Esto tendrá un impacto en la estrategia: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
EDITAR:
"StreamExecutor se usa actualmente como tiempo de ejecución para la gran mayoría de las aplicaciones GPGPU internas de Google, y se incluye una instantánea en el proyecto TensorFlow_ de código abierto, donde sirve como tiempo de ejecución GPGPU".

+1

Espero que las personas que trabajan en él logren superar el problema alternativo de CUDNN para cuando tensorflow se acerque a 1.0

@martinwicke ¿por qué está cerrado este problema?

No creo que tu compromiso arregle esto.

No siempre puede usar los mismos comentarios de confirmación en un repositorio diferente;) https://github.com/tensorflow/skflow/issues/22

Oh GitHub

@vrv Ahora que nos ha hipernotificado, ¿puede darnos algún comentario sobre la estrategia del ejecutor de transmisiones? ;)

Solo voy a culpar a GitHub por todo, incluida la falta de compatibilidad con OpenCL. ;)

Sin embargo, @benoitsteiner podría comentar más. Realmente no sé a qué te refieres con la estrategia de 'ejecutor de flujo'. Actualmente usamos una versión de stream executor y CuDNN y Eigen y todos funcionan bien juntos, por lo que no estoy seguro de cómo han cambiado los planes para el lado de OpenCL.

Quiero decir:
"¿Qué es StreamExecutor?
========================
StreamExecutor es un contenedor unificado en torno a los modelos de programación del lado del host CUDA y OpenCL (tiempos de ejecución). Permite que el código host se dirija a dispositivos CUDA u OpenCL con kernels paralelos de datos que funcionan de manera idéntica".

operaciones enlatadas
==================
StreamExecutor proporciona varios núcleos predefinidos para operaciones paralelas de datos comunes.
Las clases de operaciones soportadas son:

• BLAS: subprogramas básicos de álgebra lineal,
• DNN: redes neuronales profundas,
• FFT: transformadas rápidas de Fourier, y
• RNG: generación de números aleatorios.

@keryell Hola, también tengo interés en implementar TensorFlow en FPGA, usando lenguajes de programación de alto nivel como Xilinx C++ u OpenCL. Con mucho gusto puedo contribuir si tienes algún plan.

@henline ¿Puede explicar cuál será el papel de StreamExecutor en Opencl y de Canned relevante?
operaciones para Tensorflow. Todavía no puedo ver cómo se integrará esto con los planes SyCL en Eigen y cudnn (¿reemplazo?)

:+1: Me gustaría contribuir a esto también.

@bhack StreamExecutor proporciona una funcionalidad equivalente a la del tiempo de ejecución de CUDA y algunas de las bibliotecas de CUDA (como cublas o cudnn). Sin embargo, aún necesita escribir sus núcleos de GPU, que es para lo que usamos Eigen.

@benoitsteiner Entonces, ¿sigue siendo necesario escribir dos núcleos, uno para CUDA y otro para Opencl?

@benoitsteiner Entonces, ¿todavía no tienes una contraparte interna de tensorflow/tensorflow/stream_executor/opencl/? ¿Qué pasa con los "operadores enlatados"?

@bhack Eigen le permite escribir una expresión que describa el cálculo que desea realizar una vez y generar automáticamente un kernel (al que llamamos evaluador) para evaluar esa expresión en la CPU y otro kernel para evaluar la expresión en un dispositivo CUDA. Una vez que tengamos soporte para OpenCL en Eigen (nos estamos acercando), también será posible generar el kernel de OpenCL automáticamente.
Para algunas operaciones de TensorFlow que son críticas para el rendimiento (como la convolución), usamos kernels optimizados a mano o bibliotecas de terceros. En estos casos, necesitaremos una buena implementación OpenCL de estas operaciones.

:+1:

¿Existe un plan para impulsar más código en https://bitbucket.org/benoitsteiner/eigen-opencl? ¿Qué pasa con el compilador sycl? Parece que no se han lanzado implementaciones de destino de GPU de código abierto.

@bhack @benoitsteiner
Pronto lanzaré un reemplazo de cuDNN (solo la parte de convolución, ya que es la más crítica para el rendimiento y la memoria) para OpenCL en Caffe. Tal vez también sea útil para el puerto Tensorflow.

@bhack : Codeplay ha progresado mucho en el frente de opencl. Estén atentos para un gran impulso en https://bitbucket.org/benoitsteiner/eigen-opencl en las próximas semanas.

@naibaf7 : una implementación rápida de la operación de convolución sería extremadamente útil en TensorFlow. Estoy deseando que llegue.

@benoitsteiner Buena captura, consiguieron la silla

@benoitsteiner ¿Cómo puedo simplemente eliminar la implementación de cuda? porque '#ifdef GOOGLE_CUDA' es muy complicado. A veces significa CUDA, a veces significa GPU.

Dado que este problema llegó a la hoja de ruta (ver _Platforms_): ¿tenemos una idea aproximada de cuándo llegará la compatibilidad con OpenCL a TensorFlow? ¿Te gusta la versión 0.9 / 1.0? Q3/4 2016? ¿O es 2017 más realista?

@benoitsteiner ¿Está el eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl lo suficientemente listo para admitir un desarrollo de flujo de tensor opencl?

¿Tensorflow depende solo de los tensores Eigen o hay otras dependencias de Eigen?

@NEELMCW Codeplay acaba de lanzar soporte parcial para OpenCL a Eigen Tensors. El código está disponible en este repositorio de bitbucket . En su mayor parte, TensorFlow depende de los tensores propios. Hay dependencias adicionales en Eigen para las operaciones de álgebra lineal, pero no tenemos que proporcionar una implementación compatible con OpenCL de estas operaciones (al menos no inicialmente). Por lo tanto, estamos en una muy buena posición para comenzar a admitir OpenCL en TensorFlow.

Si está interesado en contribuir, comencé a rastrear lo que se debe hacer en esta hoja de cálculo .

@benoitsteiner Soy el autor de una biblioteca C++ 11 OpenCL BLAS (https://github.com/CNugteren/CLBlast) y actualmente estoy implementando soporte de media precisión allí. Estoy feliz de contribuir en la parte BLAS/GEMM de este proyecto y/o modificar CLBlast para que se ajuste mejor a sus necesidades.

@CNugteren
CLBlast ahora también está disponible en OpenCL-Caffe, ¿lo has visto? :)
¿Tuviste también la oportunidad de ver las circunvoluciones de libDNN?

@naibaf7 ¡Lo vi, sí! :) No he mirado libDNN hasta ahora, pero no estoy seguro de lo que quieres decir exactamente. ¿Supongo que la convolución se implementa usando GEMM?

@CNugteren
Sí, solo pensé que sería bueno si pudiera revisarlo y tal vez dar algunas mejoras o consejos de ajuste en libdnn.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Está utilizando GEMM, pero implícito (no a través de un BLAS, solo pequeños GEMM en un nivel de grupo de trabajo) para que sea posible un mayor nivel de paralelismo, así como no se necesita un búfer intermedio (para desenrollar los datos en un esquema GEMM).

Oigan todos,

@benoitsteiner gracias por mencionar nuestro impulso! ¡Espero que sea útil!

Para compilar este código, necesita un compilador SYCL. Actualmente, el único compilador compatible es ComputeCpp de Codeplay, que está disponible a través del programa de evaluación de Codeplay. ComputeCpp estará disponible de forma gratuita como una versión beta abierta pública, más adelante en 2016 y luego se lanzará con una versión gratuita (la ComputeCpp Community Edition) en 2017. Esto permitirá que cualquier persona compile y desarrolle TensorFlow en dispositivos OpenCL, como GPU AMD o Intel. y CPU.

por cierto. ¿Este problema no debería tener la etiqueta OpenCL? :)

Gracias,
Lucas

Realmente espero que pueda compilarse también con una herramienta de código abierto. @keryell cómo te va con tu nueva rama de Opencl

@bhack Sería bueno ver si puede funcionar primero con triSYCL en el modo de dispositivo host CPU OpenMP. Pero no tengo el ancho de banda para ingresar al sistema de compilación TensorFlow/Eigen ahora. :-( Si alguien quiere intentarlo, siéntase libre de hacerlo. :-)

https://github.com/keryell/triSYCL/commits/opencl debería permitir ejecutar núcleos OpenCL pronto en el modo de interoperabilidad OpenCL, pero no en el modo de fuente única SYCL con el que todos soñamos porque aún no tenemos el perfilador Clang/LLVM para extraer los núcleos de SYCL. Pero Khronos abrió recientemente los componentes de AMD e Intel para admitir OpenCL C ++ 2.2 y SPIR-V, que serían la base. Así que es "sólo" una cuestión de tiempo...

¿Alguien podría proporcionar estimaciones sobre cuándo Tensorflow podría ejecutarse con OpenCL (GPU AMD)? ¿Y cómo se ve la curva de rendimiento/usabilidad con el tiempo? Es difícil analizar toda la información anterior en información procesable de compra de hardware. :)

¡Gracias por adelantado!

@djan92
Yo diría que le demos un año hasta que sea utilizable, desafortunadamente. Parece que se basará en bibliotecas y tecnologías bastante punteras, la mayoría de las cuales aún no están listas.
También me incorporaré tan pronto como la pila completa de herramientas esté disponible como OpenSource y no antes.

@naibaf7

Yo diría que le demos un año hasta que sea utilizable, desafortunadamente. Parece que se basará en bibliotecas y tecnologías bastante punteras, la mayoría de las cuales aún no están listas.
También me incorporaré tan pronto como la pila completa de herramientas esté disponible como OpenSource y no antes.

¿Por qué no implementar una versión CL primero mientras espera que el puerto SYCL esté listo? Supongo que hay bastantes personas aquí dispuestas a ayudar. Un año suena demasiado largo.

@djan92
¡Sí, tienes razón, el #22 tiene casi 8 meses y tiene más de 100 publicaciones! ¡La información se puede inundar!

¿Alguien podría proporcionar estimaciones sobre cuándo Tensorflow podría ejecutarse con OpenCL (GPU AMD)?

TensorFlow usa la biblioteca Eigen para el cálculo de tensores (en el módulo Tensor). Hemos comprometido una implementación parcial para OpenCL 1.2 usando SYCL (https://bitbucket.org/benoitsteiner/opencl branch Codeplay). La razón por la que usamos SYCL para este trabajo es que esta sección de TensorFlow usa árboles de expresión de C++, lo cual es posible con SYCL para OpenCL, pero no con OpenCL C directamente. Otros componentes de TensorFlow, como convoluciones o BLAS, podrían usar OpenCL C directamente.

Actualmente, estoy trabajando en la integración de ComputeCpp (compilador SYCL de Codeplay) en el sistema de compilación bazel. Esto debería estar listo pronto (siga este repositorio: https://github.com/benoitsteiner/tensorflow-opencl/). Una vez hecho esto, TensorFlow debe acelerarse en sistemas compatibles con OpenCL SPIR (como AMD o Intel) con ComputeCpp. Se seguirá trabajando para acelerar más TensorFlow, así como para admitir más implementaciones de OpenCL y el SYCL de código abierto triSYCL. SYCL y OpenCL son estándares abiertos de múltiples proveedores y libres de regalías, por lo que hay muchas plataformas y dispositivos compatibles con este enfoque (no solo las GPU de AMD).

El compilador ComputeCpp Community Edition estará disponible de forma gratuita más adelante en 2016 (en forma beta: la conformidad completa se lanzará de forma gratuita a principios de 2017).

El trabajo de aceleración de las partes de TensorFlow que no son de C++ (p. ej., BLAS y convoluciones) podría realizarse sin SYCL e implementarse por separado. Diferentes proveedores de hardware pueden tener sus propias bibliotecas optimizadas para estas funciones que podrían ayudar a la aceleración. O bien, podríamos usar Eigen con C++ para estas funciones.

¿Y cómo se ve la curva de rendimiento/usabilidad con el tiempo?

Creemos que el rendimiento mejorará constantemente. Para acelerar en una amplia variedad de dispositivos, necesitamos administrar los datos de manera más eficiente, por lo que existe un elemento de trabajo de "tensor administrado", para que el movimiento de datos se pueda administrar de manera más eficiente entre el host y varios dispositivos. Es difícil predecir cómo variará el rendimiento en una amplia gama de dispositivos, en este momento. Actualmente, se acelera muy poco, pero estamos implementando la infraestructura para permitir la aceleración de estándar abierto en TensorFlow.

@naibaf7

Yo diría que le demos un año hasta que sea utilizable, desafortunadamente.

Las operaciones básicas deberían estar aquí muy pronto. Estamos implementando la infraestructura básica dentro del código para admitir la aceleración basada en estándares abiertos. Creemos que con el apoyo de la comunidad, una versión acelerada y utilizable estará lista en mucho menos de un año.

También me incorporaré tan pronto como la pila completa de herramientas esté disponible como OpenSource y no antes.

ComputeCpp estará disponible públicamente, de forma gratuita, en 2016. El soporte triSYCL de código abierto debería seguirlo. OpenCL de código abierto ya es compatible con pocl, Shamrock, Clover, Beignet.

@robertwgh
El código de tensor de C++ en Eigen no sería fácilmente portátil a OpenCL C sin SYCL, pero hay otras características que funcionarían bien en OpenCL C. Eche un vistazo a esta hoja de cálculo: https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 y llene gratis, escriba su nombre en las funciones que deberían usar OpenCL C normal (como BLAS y convoluciones).

Estamos dando una versión de evaluación para ComputeCpp antes del lanzamiento público. Si desea uno, por favor envíeme un correo electrónico :)

@lukeiwanski Genial, gracias por la actualización. Espero que tengas razón acerca de hacerlo con todas las funciones en menos de un año.

Otro paso de Streamexecutor en LLVM

alguna posibilidad de obtener aceleración en el rx 480?

@benoitsteiner
LibDNN independiente estaría disponible para la integración:
https://github.com/naibaf7/libdnn

Es genial leer que se está trabajando en esto. Ayudaría si se puliera Beignet 2.0. Mucho potencial con Skylake e Iris en este momento.

Se agregó una solicitud de extracción reciente en https://github.com/benoitsteiner/tensorflow-opencl/pull/1 si alguien quiere echar un vistazo.

OpenCL SDK de Imagination (GPU) necesita NDA para ser accesible, solo tenemos la biblioteca compartida. ¿Es posible ejecutar tensorflow basado en estas librerías?

@alephman
No necesita archivos de encabezado específicos del proveedor para crear ningún programa OpenCL. Pruebe cl.hpp desde https://www.khronos.org/registry/cl/api/1.2/cl.hpp y opencl.h/cl.h desde cualquier otro SDK. Por ejemplo, tengo al menos 3 plataformas OpenCL y todo funciona con una /usr/include/CL/cl.h compartida

Todavía no admitimos la ejecución de TensorFlow en OpenCL. Es un trabajo en progreso. Actualmente estamos trabajando en las GPU de AMD. El soporte de PowerVR debería seguir. Si desea contribuir al desarrollo, debe contactarnos (Codeplay) directamente. Si desea ejecutar TensorFlow en PowerVR, debe esperar un poco más de progreso.

@inferrna gracias, se parece al OpenGL que oculta la implementación específica del proveedor.

@andrewrichards Me encanta contribuir al desarrollo, ¿cómo contactar contigo?

Lo más fácil es si hace clic en "registrar su interés" en nuestra página aquí: https://www.codeplay.com/products/computecpp
Eso lo llevará a nuestro programa de desarrolladores y podemos trabajar juntos en este @alephman

Si quieres puedes colaborar también para permitir compilar con una alternativa de código abierto. Consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment-221841173

¡Hola a todos!
Muy feliz de escuchar que el soporte de Tensorflow se está extendiendo fuera de Nvidia Cuda. Me pregunto si también considera hacer que funcione en APU como esta: http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
Las APU admiten OpenCL tanto para la CPU como para la GPU.
Esto debería funcionar prácticamente de forma inmediata cuando el soporte de OpenCL esté listo.
Mientras tanto, si ya tiene una APU y quiere probar otro marco de ML, BVLC OpenCL Caffe ya funciona.

@ naibaf7 Gracias por la aclaración. Estoy buscando combinaciones rentables de hardware/software para ejecutar localmente Tensorflow y definitivamente seguiré el progreso del desarrollo de OpenCL.

@hughperkins
Sí, puede ser un problema, pero creo que partes como im2col/col2im y otras implementaciones de convolución también podrían conectarse como API externas si es realmente un problema con GCLA. Esto también puede ser mejor para los autores originales de dicho trabajo.

@hughperkins Estamos trabajando para llevar OpenCL a TensorFlow a través de SYCL para OpenCL 1.2.
Eche un vistazo a https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 para "todos" y progreso.
Recientemente lanzamos un compilador para SYCL https://www.codeplay.com/products/computesuite/computecpp llamado ComputeCpp Comunity Edition. ¡La gente puede probarlo!
Además, nos estamos enfocando en la biblioteca Eigen https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp , llevándola a la etapa requerida por MNIST de TensorFlow, hay un par de cosas pendientes.
En cuanto a las limitaciones, la versión CE de ComputeCpp actual ha sido probada para Intel (CPU, GPU) y AMD (CPU, GPU) en cuanto a las plataformas compatibles con Ubuntu 14.04 de 64 bits y CentOS de 64 bits.
ComptueCpp se puede descargar de forma gratuita y se puede utilizar en proyectos comerciales y de código abierto.
Porque abrimos <3 comunidades :)

@lukeiwanski Perdón por discutir/preguntar esto aquí en el hilo, pero creo que también puede ser de interés para otros: entiendo que Codeplay está muy interesado en SYCL para la implementación de OpenCL y ya escuché que otros están interesados ​​en este trabajo de tú también. Leí una publicación de un funcionario de Movidius, por ejemplo. Sin embargo, me gustaría preguntar cuál es realmente la contribución de Google a esto. Dado que Movidius, además de AMD y otros, figuran como socios de Codeplay, puedo entender que fomentan o incluso admiten SYCL para OpenCL, pero que yo sepa, Google no es su socio y no ha contribuido hasta ahora.

No me malinterpreten, me gusta mucho su trabajo, pero ¿no sería una buena idea consolidar sus esfuerzos, juntar los recursos e intentar trabajar junto con Google? Para mí, parece que muchas partes diferentes están interesadas en OpenCL para TensorFlow, pero no se utiliza un gran potencial, ¡¿porque estas partes no se desarrollan juntas?!

Puede que me equivoque y me disculpo si esto se ha discutido lo suficiente, pero todavía no estoy al tanto de ningún intento importante por parte de Google (u otras partes) para trabajar juntos en esto y, como resultado, todavía no estoy al tanto de cómo la comunidad podría ayudar o apoyar (como individuos solteros), ya sea a través de contribuciones directas, pruebas u otras cosas.

@ascenator En Google hemos estado trabajando en estrecha colaboración con Luke y sus colegas de Codeplay en este proyecto durante casi 12 meses. La contribución de Codeplay a este esfuerzo ha sido tremenda, por lo que sentimos que deberíamos dejarles tomar la iniciativa cuando se trata de comunicar actualizaciones relacionadas con OpenCL. Es por eso que no ha escuchado mucho de nosotros sobre el tema :)

Ahora que el compilador ComputeCpp está ampliamente disponible, planeamos fusionar el trabajo que se ha realizado hasta ahora. Pero primero queremos armar una infraestructura de prueba integral para asegurarnos de no desestabilizar el código base existente.

Damos la bienvenida a todas las contribuciones a este esfuerzo, así que no dude en ponerse en contacto conmigo si desea ayudar. Estamos especialmente interesados ​​en núcleos OpenCL de alto rendimiento para la multiplicación de matrices y convoluciones. Se han sugerido varios candidatos, pero no hemos comenzado a investigar los pros y los contras de cada uno o cómo integrarlos.

@benoitsteiner muchas gracias por la aclaración y perdón por mi información errónea. ¡Esto suena muy bueno y prometedor! Definitivamente echaré un vistazo a ComputeCpp entonces. Tengo muchas ganas de que OpenCL admita TensorFlow, porque ofrece muchas posibilidades nuevas para la robótica (que es el campo en el que estoy investigando y usando TensorFlow para aplicaciones de aprendizaje profundo). Al menos echaré un vistazo a los primeros lanzamientos e intentaré probar/depurar. Tenemos algunos chips Intel más una cantidad de CPU ARM que están esperando pruebas;)

@hughperkins... lo siento, pero ¿no está completamente fuera de tema aquí? No veo cómo esto es relevante en OpenCL TF.

Estoy más interesado aquí para saber si se adoptará un enfoque de ajuste para la multiplicación de matrices y los núcleos de convolución y si será una alternativa válida de código abierto a CompiteCpp que producirá SPIR-V.

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

Se publican dos nuevos estándares del Grupo Kronos en https://www.khronos.org/news/press/khronos-launches-dual-neural-network-standard-initiatives

Si ayuda, está disponible una mejor versión de isaac: https://github.com/ptillet/isaac , y proporciona aceleraciones significativas sobre clBLAS y cuBLAS en Maxwell, Pascal y Fiji. También proporciona kernels más rápidos (con reconocimiento de entrada) que Tensorflow para reducciones 1D y 2D.

@hughperkins parece que tiene más posibilidades de escribir el compilador CUDA para cualquier dispositivo OpenCL, en lugar del traductor CUDA-OpenCL.

@hughperkins ¿ Tal vez la función SVM de OpenCL 2.0 podría resolver el problema del puntero? Dado que todos, además de Nvidia (AMD, Intel, ARM, Qualcomm) están comenzando a admitir OpenCL 2.0. ¿Quizás es una buena solución?

@hughperkins es una implementación de blas en sí misma. Implementa algunos de los símbolos en los encabezados de clblas y cublas, por lo que no hay que volver a compilar ni modificar el código. es necesario. También podría implementar algunos de los símbolos para clblast.h, ya que usa un encabezado diferente. Algunas ventajas de Isaac son:

• Completamente dinámico, por lo que puede usar CUDA o OpenCL sin recompilación.
• Con reconocimiento de entrada, no ajusta los núcleos para matrices cuadradas grandes. Debería funcionar bien en todas las formas que se te ocurran sin tener que volver a sintonizar.
• API de C++ similar a numpy/arrayfire. Cierta fusión para combinar la operación por elementos con reducciones

@marty1885
Realmente no. AMD volvió al soporte 1.2 en los controladores AMDGPU-PRO. Puede pasar un tiempo hasta que se generalice el soporte completo de 2.0. Definitivamente no es una solución a corto plazo allí.

• sí
• Podría piratear la compatibilidad para un montón de operaciones si fuera necesario (por ejemplo, reenviar **MV a GEMV). El soporte complejo será complicado. El soporte doble ya está aquí, pero no se ha ajustado ninguna arquitectura para ello.

@hughperkins

Parece que mi código no viola ninguna regla obvia de OpenCL

Sí, simplemente pasar cualquier estructura __global (como matriz o estructura) que contenga punteros es incorrecto solo porque esos punteros pueden apuntar a la memoria de otro dispositivo (OpenCL admite el paradigma de dispositivos múltiples donde un dispositivo no puede acceder a la memoria de otro). Pero parece ser posible superar el nivel IR, sin traducción intermedia al código OpenCL, eso es lo que asumí :)

@benoitsteiner , @henline , de https://github.com/henline/streamexecutordoc , sugiere que streamexecutor admitió la operación enlatada de la versión CL (como DNN, BLAS) lista para usar. ¿Sugiere que Google ya tiene la implementación clDNN, clBLAS lista para Tensorflow, pero aún no la ha abierto?

De lo contrario, OpenCL 2.0+ y SYCL 2.2 son compatibles con SVM, si desea mantener la misma arquitectura de software.
OpenCL 2.0+ es compatible con GPU AMD e Intel, por ejemplo. En el mundo integrado, a menudo es compatible con efectos secundarios incluso con OpenCL 1.x, ya que las memorias del host y del dispositivo suelen ser las mismas por razones de costo.

@keryell
Pero las plataformas más notables, Linux + las nuevas GPU AMD (RX 480, próximo Vega) solo admiten OpenCL 1.2 por ahora... y quién sabe cuándo cambiará eso (mi apuesta es en un año). Beignet (intel de Linux de código abierto) para OpenCL 2.0 también sigue siendo un desastre; la versión estable tiene 1.2.
Además, teniendo en cuenta que todas las empresas más pequeñas que fabrican chips compatibles con OpenCL apenas obtienen soporte 1.2. Así que supongo que cualquier cosa que dependa de OpenCL 2.0 tendrá muy malas tasas de adaptación en la práctica.

Creo.. algun proveedor de hardware tiene la urgencia de consumir SPIR-V? Creo que la presión de Graphic/Shaders sobre Vulkan podría ayudar al lado de Opencl.

@naibaf7 para volver a la discusión sobre OpenCL 2 o no, en algún momento se deben entregar cosas reales... De lo contrario, ya hay GPU nVidia y CUDA con TensorFlow ejecutándose... :-)
Pero, por supuesto, una versión de TensorFlow sin SVM tiene cierto interés.

@keryell ¿Cuánto del trabajo de Vulkan SPIR-V en los controladores (que ya tiene una buena cobertura de dispositivos) cree que impulsará las versiones modernas de Opencl?

@ naibaf7 La reunión de Khronos es la próxima semana en Seúl con personas de OpenCL y Vulkan, pero las discusiones no son públicas. Pero suena como una buena idea que cada mundo mejore al otro, y en algún momento beneficia a TensorFlow. :-)

@keryell
Sí, espero que discutan algunas cosas beneficiosas de DeepLearning :)

¡Felicitaciones! Asegúrese de consultar el proyecto HIP, ya que intentaron resolver el mismo problema. Eligieron crear un nuevo lenguaje llamado HIP, que define lo que debe convertirse manualmente (como verificar el soporte de doble precisión al verificar el nivel de cómputo). Mientras el proyecto avanza, la cantidad de traducciones manuales disminuiría. Consulte: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

Mi sugerencia para usted es usar HIP y corregir algunos errores que bloquean el avance de Tensorflow o sus propios objetivos, ya que ahora tiene la comprensión de LLVM para hacerlo. De esta manera, no tiene que resolver los problemas que ya solucionaron.

@hughperkins
no puede construir el módulo de python con su bifurcación siguiendo esto 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.

Estoy en ubuntu 16.04, dirname es de coreutils-8.25-2ubuntu2

@hughperkins Creo que ajustar el archivo acoplable TF en su repositorio con estas instrucciones podría facilitar la configuración para otros.

Sí, cuando habrá algo más funcional. Básicamente, es una copia y un pasado de estas instrucciones que ha publicado.

Estoy experimentando con MacOS 10.10.5 en una MacBook de finales de 2015 con ATI 6770M (OpenCL 1.2).

Instalé Xcode 8, Anaconda (Python 3.5) y MacPorts equivalentes de clang+llvm:

en lugar de líneas apt-get, haz lo siguiente:

puerto sudo instalar clang-3.8 llvm-3.8

En lugar de usar /proc/cpuinfo, haz lo siguiente:

NUM_PROCS=$(system_profiler SPHardwareDataType | grep "Número total de núcleos" | cut -d ":" -f 2)

Luego modifique Makefile para usar macports y ejecute 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

actualizar los directorios OpenCL de Macos; futuro: use /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' condicional

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

Esto es hasta donde llego:

$ hacer -j ${NUM_PROCS}
mkdir -p construir
mkdir -p construir
mkdir -p construir
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/hostside_opencl_funcs.o -std=c++11 -fPIC -g -O2 -I pwd /include -I pwd /src/EasyCL src/hostside_opencl_funcs.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/mutations.o -g -I/opt/local/libexec/llvm-3.8/include src/mutations.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-excepciones -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-excepciones -c -o build/readIR.o -g -I/opt/local/libexec/llvm-3.8/include src/readIR.cpp
En el archivo incluido desde src/hostside_opencl_funcs.cpp:17:
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: advertencia: atributo 'host' ignorado [-Wignored-attributes]
atributo ((host)) en línea sin firmar largo largo atomicExch (volátil sin firmar largo largo _p, sin firmar largo largo val) {
^
src/hostside_opencl_funcs.cpp:194:33: error: la llamada a la función miembro 'in' es ambigua
launchConfiguration.kernel->in(desplazamiento);
~~~~~~~~ ^ ~ _ _
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15: nota: función candidata
CLKernel en (valor flotante);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15: nota: función candidataCLKernel *in(valor int32_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15: nota: función candidataCLKernel *in(valor int64_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15: nota: función candidataCLKernel *in(valor uint64_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15: nota: función candidataCLKernel *in(valor uint32_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15: nota: la función candidata no es viable: ninguna conversión conocida de 'size_t' (también conocido como 'largo sin firmar ') a 'easycl::CLArray *'para el 1er argumentoCLKernel *in(CLArray *clarray1d) { return input(clarray1d);



}^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36: nota: la plantilla de función candidata no es viable: requiere 2 argumentos, pero se proporcionó 1plantillaCLKernel *in(int N, const T *datos);^1 advertencia y 1 error generado.hacer: *_* [build/hostside_opencl_funcs.o] Error 1hacer: * * Esperando trabajos sin terminar....
src/struct_clone. cpp:245 :12: advertencia: 11 valores de enumeración no manejados en el conmutador: 'HalfTyID', 'X86_FP80TyID', 'FP128TyID'... [-Wswitch]
cambiar (ID de tipo) {
^
1 advertencia generada.

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

Este parche funcionó. Gracias.

Después de aplicar esto, continuar con la compilación resultó en errores de espacio de nombres size_t:

$ hacer -j ${NUM_PROCS}
mkdir -p construir
mkdir -p construir
/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 /incluir -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/ mutaciones.o build/struct_clone.o src/ir-to-opencl-common.cpp /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
En archivo incluido desde src/hostside_opencl_funcs. cpp: 17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: advertencia: atributo 'host' ignorado [-Wignored-attributes]
atributo ((host)) en línea sin firmar largo largo atomicExch (volátil sin firmar largo largo _p, sin firmar largo largo 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 /incluir -I pwd /src/EasyCL src/cocl_blas.cpp
1 advertencia generada.
/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 /incluir -I pwd /src/EasyCL src/cocl_error.cpp
En archivo incluido desde src/cocl_blas. cpp: 15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:8:9: error: ningún tipo llamado 'size_t' en el espacio de nombres 'std'; ¿Quiso decir simplemente 'size_t'?
typedef std::size_t cubosStatus_t;
^ ~ ~
talla_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquí
typedef TAMAÑO_TIPO tamaño_t ;
^
En archivo incluido desde src/cocl_blas. cpp: 15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:17:5: error: ningún tipo llamado 'size_t' en el espacio de nombres 'std'; ¿Quiso decir simplemente 'size_t'?
std::size_t cubosCreate(cublasHandle_t phandle);^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_t ;^En archivo incluido desde src/cocl_blas.
¿Quiso decir simplemente 'size_t'?std::size_t cubosDestroy(cublasHandle_t handle);^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_t ;^En archivo incluido desde src/cocl_blas.
¿Quiso decir simplemente 'size_t'?std::size_t cubosSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_t ;^En archivo incluido desde src/cocl_blas.
¿Quiso decir simplemente 'size_t'?std::size_t cublasSetPointerMode(cublasHandle_t manejador, cublasPointerMode_t modo);^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_t ;^En archivo incluido desde src/cocl_blas.
¿Quiso decir simplemente 'size_t'?std::size_t cublasGetPointerMode(cublasHandle_t handle, cublasPointerMode_t *mode);^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_t ;^En archivo incluido desde src/cocl_blas.
¿Quiso decir simplemente 'size_t'?std::size_t cublasSetStream(cublasHandle_t handle, cudaStream_t streamId);^ ~ ~talla_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquítypedef TAMAÑO_TIPO tamaño_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 /incluir -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 /incluir -I pwd /src/EasyCL src/cocl_device.cpp7 errores generados.hacer: *_* [build/cocl_blas.o] Error 1hacer: * * Esperando trabajos sin terminar....

¿Podemos presionar el inicio de sesión largo en esencia para permitir que el hilo aún sea legible?

pregunta: ¿cómo están resolviendo el problema de los espacios de direcciones?

@hughperkins Las especificaciones SYCL se describen en la sección 5.8 ("Deducción del espacio de direcciones")
cómo una implementación necesita lidiar con diferentes tipos de memoria. Esta
es similar al trabajo anterior realizado para PlayStation 3 y descrito en
este documento: Descarga: automatización de la migración de código a heterogéneoSistemas multinúcleo o C++ en aceleradores: compatibilidad con modelos de programación SYCL y HSA de fuente única mediante Clang

Espero que ayude.

@hughperkins ¿Puedo compilar su código de repositorio tensorflow-opencl para aplicar mi placa ARM? Mi placa ARM tiene GPU Imagination que admite opencl 1.2.

Me topé con este hilo mientras buscaba soporte tf/intel.

Tengo un Intel MacBook Pro, ¿cómo puedo ayudar? No sé c/c++, pero puedo seguir las instrucciones de compilación/compilación/prueba y devolver los resultados (pastebin)...

derek$ system_profiler SPDisplaysDataType
Gráficos/Pantallas:

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 ¡ Gracias por tus instrucciones!
Trato de compilar su cuda-on-cl en la plataforma del brazo. Siguiendo la guía de cuda-on-cl:
Información de mi placa ARM:
arm64, gcc 4.9, clang y llvm 3.5, openCL 1.2

* ¿Tengo que usar la versión clang++-3.8? *
clon de git --recursivo https://github.com/hughperkins/cuda-on-cl
hacer
error:
clang++-3.8: Comando no encontrado
Edito el Makefile así: CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
luego vuelve a hacer:
error:
src/mutations.h:3:10: error fatal: archivo 'llvm/IR/Module.h' no encontrado

intente ejecutar make run-test-cocl-cuda_sample:
hacer: cocl: Comando no encontrado

@hughperkins déjame intentarlo.

Obtuve un error al probar keras con tensorflow

keras$ KERAS_BACKEND=tensorflow pytest3

Errores de salida:

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

Código:

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

hola a todos, mi nombre es ricardo, soy un programador de C++ con muchos años de experiencia en C++, y poco en Cuda, estaré dispuesto a contribuir con este esfuerzo. ¿Cómo puedo contribuir a este trabajo?

Vale, tengo un Odroid Xu3 con un Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 y OpenCL 1.1 Full profile)
ejecutándose en el sistema operativo: LUbuntu 1404 64 bits
Haré una instalación completa y publicaré el resultado en esta plataforma.
Acerca de los errores, hay una lista de errores (¿algo así como Bugzilla?) o una hoja de cálculo con una lista de errores.
¡Salud!

¿Qué pasa con el uso de HIP?
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_faq.md#how-does-hip-compare-with-opencl
https://github.com/RadeonOpenCompute/hcc
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45
"Su deseo se está cumpliendo, Eigen se está transfiriendo a GPU AMD a través de HIP. La segunda parte de su solicitud es si podemos traer una herramienta estandarizada compatible con FLOAT16 que se envía con todas nuestras GPU GFX8, deseo concedido".
Nuestra rama de desarrollo del compilador AMDGPU ahora es compatible con las instrucciones nativas Float16 e Int16, en lugar de emular FP16/Int16 con instrucciones de conversión ascendente y descendente para convertir de FP16/Int16 a Float y viceversa.

Se trata de pruebas f16 en hardware de Fiji que ejecutan con éxito una multiplicación de matriz con medios tipos con conversión y con instrucciones nativas".

Además, no está relacionado, pero debe usar syCL/openCL 2.0 en lugar de 1.2, porque nvidia ya es compatible a través de CUDA. Y openCL 2.0 es compatible con los controladores AMD e Intel Windows. También AMD ha dicho que pronto abrirán un controlador openCL 2.0 de código abierto para Linux (que podría ser utilizado por Intel, magia de código abierto) (e Intel ya tiene una implementación de Linux openCL 2.0 que solo necesita madurar). Si le pregunta a Intel y AMD, tal vez podrían acelerar el trabajo, porque tensorflow es importante para sus intereses económicos. Y ya han dicho en esta sección de comentarios que querían ayudar. Además, todos los principales fabricantes de ARM admiten openCL 2.0. Esto podría abrir muchas oportunidades para Android (que es de interés económico para Google), como frambuesa, televisores inteligentes, etc.

Y, a mediano plazo, eventualmente podríamos desarrollar una capa alternativa de OpenCL 1.2 para hardware no compatible.
Y la implementación también debe usar openVX (que ahora es compatible con todos los principales fabricantes de hardware, y AMD tiene una implementación de código abierto) y con https://www.khronos.org/news/press/khronos-launches-dual-neural-network -iniciativas-estándar
Y todo con Spir-V (que puede ser usado simultáneamente por Vulkan y openGL).
Se podría decir que estoy haciendo un duplicado de lo que ya se dijo, pero la síntesis es importante.
Y finalmente, ¿podría tensorflow usar HSA?

http://www.hsafoundation.com
HSA sería increíble en Android.

No sé si HIP sería útil o no. Solo es compatible con algunas tarjetas AMD, por lo que necesitamos una implementación de OpenCL de todos modos si queremos admitir todos los dispositivos. Todavía podría valer la pena si la implementación de HIP es notablemente más rápida. Este podría ser el caso, pero aún no he visto muchos puntos de referencia (HIP vs. OpenCL). Otra razón podría ser MLOpen (que está escrito en HC) como reemplazo de cudnn, pero nuevamente, no tengo idea de qué tan rápido es o qué funciones admite.

TensorFlow no usaría HSA directamente porque tiene un nivel bastante bajo. Pero HC (y HIP) se implementan encima y también puede implementar OpenCL encima de if (pocl hace eso).

¿Sería útil aquí el algoritmo relooper? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins Es bueno ver que tiene algún progreso con su compilador, pero creo que se vuelve fuera de tema para TensorFlow. En su lugar, debe iniciar muchos hilos de discusión más pequeños en la página de GitHub de su proyecto de compilador. Sería más centrado y productivo, supongo.

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

También hay https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.cpp

Aquí está el documento asociado: https://github.com/kripken/emscripten/blob/master/docs/paper.pdf?raw=true

La compatibilidad inicial con OpenCL/SyCL se fusionó en maestro con https://github.com/tensorflow/tensorflow/pull/5267

¡Felicidades!

@keryell Por cierto , ¿qué pasó con el repositorio triSYCL? Parece que se ha ido y solo puedo encontrar una referencia al Gitlab de Khronos que no es de acceso público.

EDITAR: Encontré tu clon privado, solo el de amd se ha ido.

@bhack , ¿opencl-docker es compatible con la plataforma mac?

@alephman No tengo una plataforma OSX, pero creo que adaptar un poco el comando de lanzamiento podría funcionar.

@bhack @alephman : vea mi comentario sobre mac arriba, si me indica las instrucciones de compilación, intentaré

@olesalscheider : sí, triSYCL pasó de AMD a Xilinx https://github.com/Xilinx/triSYCL pero tiene razón, la versión en mi espacio de trabajo de GitHub también funciona en https://github.com/keryell/triSYCL

Todavía no hemos probado triSYCL en TensorFlow. Ya hay un gran trabajo de configuración de compilación que hacer solo para intentarlo...

@keryell ¿Cuál es el estado de triSYCL?

¡La compatibilidad con Intel beignet opencl 2.0 está casi terminada!
http://phoronix.com/scan.php?page=news_item&px=Beignet-Cumpleaños-CL2

@bhack triSYCL se desarrolla principalmente en Xilinx ahora. Todavía agregando más y más características. El compilador de esquemas basado en Clang/LLVM todavía está en desarrollo para tener una experiencia completa de fuente única en un dispositivo. Pero el modo de compatibilidad de OpenCL, ya implementado, también tiene algún valor, al simplificar las comunicaciones entre el host y los kernels con el tiempo de ejecución de SYCL que realiza las transferencias perezosas de acuerdo con las dependencias expresadas por los usuarios.

Mi mac es compatible con OpenCL, entonces, ¿cómo puedo ejecutar mi tensorflow con openCL? Acabo de descubrir que opencl había sido compatible con tensorflow, cuando configuré los nuevos códigos.

@hughperkins no hay instrucciones de clinfo en mi mac, ¿qué puedo hacer para solucionarlo? Pero puedo compilar el código de prueba aquí para opencl con sonido metálico y dar como resultado la siguiente información:
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

Gracias @hughperkins , pero creo que ayer probé la computadora y parece que el sistema macbook aún no es compatible con la computadora. Entonces, tal vez seguir esperando nuevas actualizaciones es lo único que puedo hacer (TT). Por cierto, mi Iris 6100 es de octava generación, lo cual es bueno para OpenCL 1.2.

@hughperkins sí, SYCL 1.2 es a priori para OpenCL 1.2 y SYCL 2.2 es a priori para OpenCL 2.2.
Dije "a priori" ya que, si no usa nada que requiera el modo de compatibilidad con OpenCL de SYCL, SYCL realmente no requiere OpenCL en absoluto. En realidad, SYCL es un modelo muy genérico para computación heterogénea y puede ejecutarse sobre cualquier cosa. Pero, por supuesto, una implementación real también puede requerir OpenCL.

Hola,

Estoy aprendiendo/trabajando con TensorFlow y Keras por el momento y me interesaría que la compatibilidad con OpenCL funcione en macOS... ¿Hay alguna noticia sobre el trabajo realizado en macOS?

Logré compilar TensorFlow, pero si trato de configurar para OpenCL, me pide la ubicación de computeCpp 1.2, y me parece que no hay ComputeCpp para macOS.

Hola. De ninguna manera soy un experto en ML / Tensorflow / o incluso OpenCL, pero soy un desarrollador de gráficos de Mac experimentado que desea desesperadamente un rendimiento más rápido de Tensorflow en sistemas con GPU integradas y AMD que usan bibliotecas integradas y dependencias simples :)

¿Cómo puedo ayudar?

Mirando la última falla de compilación en OS X en el registro de travis @hughperkins , ¿parece que ejecutar 'xcode-select --install' podría resolverlo? Debería volver a vincular el directorio /usr/include. Yo mismo tuve este problema al actualizar Xcode beta para su lanzamiento y tuve problemas para compilar código C++.

Parece que el compilador XLA (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) proporcionará la generación de código LLVM a partir de gráficos de flujo de datos. Esto significa un acceso muy fácil a spir-v y, por lo tanto, a la API de cómputo de Vulkan. Con la generación de código resuelta, no puedo imaginar que Google no brinde compatibilidad con Vulkan dada la gran cantidad de GPU integradas sin usar que se ejecutan en Android.

@hughperkins

Rápidamente: en este momento estoy ejecutando Inception v3 en un código base C++ / Object-C personalizado y pasando fotogramas de video decodificados a la red. No sé lo suficiente sobre TF para conocer las necesidades de bajo nivel, pero de alto nivel: cargar modelos, ejecutar sesiones, esperar que las cosas funcionen. Creo que eso significa 100% de compatibilidad para ser realmente honesto. Sé que eso no ayuda a priorizar. Básicamente, el reconocimiento de imágenes de C++ mediante TF/InceptionV3 fue mi punto de partida.

cuda-on-cl ejecutándose en Mac: revisé el repositorio y puedo ayudar a depurar y ejecutar compilaciones en mis sistemas y verificar los resultados en una variedad de hardware: tengo acceso a AMD Mac Pros con Dual D700s, Nvidia Mac Laptops y Sistemas de escritorio.

Gracias por sus comentarios detallados. Supervisaré el repositorio, intentaré seguirlo e intentaré ayudar lo mejor que pueda.

Hugh, es posible que desee ver http://chrec.cs.vt.edu/cu2cl/ para aprender cómo se asignan algunas funciones.

En mi empresa, StreamComputing, tenemos varias GPU para pruebas de compilación y evaluación comparativa, que usamos para los proyectos de nuestros clientes. Podría conectar su Github a nuestro Jenkins para hacer una ejecución semanal.

Gracias por la respuesta, volveré sobre el tema en el trabajo esta semana, con guiones específicos.

Mis casos de uso están relacionados con el análisis de coincidencia sintáctica/de texto, utilizando Gensim y Keras/tensorflow en mis experimentos.

Estoy dispuesto a ayudarle para la prueba

Tengo una PC con Windows con una tarjeta AMD
Un MBP con una tarjeta AMD
Un MB con una GPU integrada Intel

Hola, @hughperkins : esta noche estoy realizando la prueba anterior en un AMD R9 390 de 8 GB. Hasta ahora ya tengo un resultado diferente; logistic_regression.py trenes y no regresa nan . ¡Tan bueno! Se produce un error de segmentación al final, así que investigaré si la secuencia de comandos o el código cl tienen la culpa.

¿Dónde debo empujar mis resultados, donde pueden ser más útiles para usted?
¿Quizás podríamos obtener un "guión de prueba" estándar que genere un conjunto estándar de resultados que los voluntarios puedan enviarle (o configurar en CI locales o lo que sea)?

py.test es una solución tan buena como cualquier otra; está a solo pip distancia y eso es parte del proceso para instalar tensorflow todos modos.

Descubrí algunas cosas interesantes desde que comencé mis pruebas, y es posible que no se puedan depurar usando solo la salida de Python, sin embargo:

• Diferentes llamadas a la misma secuencia de comandos pueden bloquearse antes de tiempo, o pueden "colgarse" (sin salida, sin progreso, sin respuesta a Ctrl-C , el proceso debe ser pkill -9 'd), o pueden bloquearse tarde ya sea en la parte de validación o después de que el script se complete con éxito. Los bloqueos (fallos de segmento) pueden derribar Xorg.
• Los resultados varían aparentemente sin ninguna razón: puedo llamar a un script y hacer que segfault, luego llamarlo de nuevo y funcionará.
• Los bloqueos pueden ocurrir en porciones de código que estaban funcionando literalmente hace unos momentos, tuve un bloqueo dentro o después de un lote de entrenamiento, después de que varios cientos de lotes acabaron de suceder con éxito.

Entonces, ¿podría ser que hay cosas sin resolver en el lado de la GPU y que se necesita una buena falla de segmento para solucionarlo? Todavía no sé mucho sobre el modelo de GPU o OpenCL, así que no puedo contribuir mucho aquí. Pero, puede ser que se necesite la salida de depuración de la GPU para explorar correctamente lo que está sucediendo.

Además, pensé que estabas con AMD desde tu github, pero parece que eres un "agente deshonesto" haciendo todo esto de CUDA-on-CL en tu propio tiempo. ¡Gracias sinceramente por encabezar esto! ¿Hay alguna manera en que otros y yo podamos contribuir a sus esfuerzos, tal vez financiando colectivamente una GPU? O podrías configurar un Patreon, ¿estoy feliz de registrarme para una contribución mensual al proyecto?

En cuanto a las GPU de AMD, somos socios de AMD. Mira mi mensaje de hace 8 días, que quizás te hayas perdido:

En mi empresa, StreamComputing, tenemos varias GPU para pruebas de compilación y evaluación comparativa, que usamos para los proyectos de nuestros clientes. Podría conectar su Github a nuestro Jenkins para hacer una ejecución semanal.

Me pregunto si podría tener la posibilidad de configurar un servidor CI, que se ejecute en cada confirmación.

No hay problema. Probablemente necesite acceso de escritura al proyecto, para que Jenkins pueda escribir el archivo de registro en un directorio de registro de compilación. Solo te envío spam para que podamos discutir.

Hola a todos,

Como probablemente ya haya visto, un montón de cosas de SYCL se han enviado a TensorFlow. Todavía no estamos completos, y hay mucho por hacer. Pero estamos progresando para llegar allí.

Si está interesado en contribuir o simplemente tiene curiosidad sobre el estado actual, consulte el desglose a continuación.

Infraestructura
Google amablemente donó dos máquinas que están configuradas para probar la bifurcación de TensorFlow de @benoitsteiner (https://github.com/benoitsteiner/tensorflow-opencl) periódicamente

Ambos tienen GPU AMD:

CL_DEVICE_NAME: Hawái
CL_DRIVER_VERSION: 1912.5 (VM)

y

CL_DEVICE_NAME: Fiyi
CL_DRIVER_VERSION: 1912.5 (VM)

En Codeplay también estamos buscando dedicar máquinas el próximo año. Para mejorar la cobertura de diversidad de dispositivos OpenCL.

Estamos buscando colaboradores en ese frente si alguien está interesado en proporcionar un servidor de compilación de prueba para las plataformas relevantes que admitimos.
Actualmente, los requisitos son:
-Ubuntu 14.04
- Controladores OpenCL que admiten SPIR ( Intel CPU / GPU o AMD GPU )

@VincentSC , ¿tal vez podrías ayudar con eso?

Pruebas
En la máquina Fiji (https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull) enfrentamos 164 fallas.

En la máquina Hawaii (https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull) tenemos 56 errores.

Estamos investigando cómo corregir las pruebas de gradiente fallidas e investigar los orígenes de las fallas adicionales en la máquina de Fiji.

propio
Durante los últimos meses, hemos estado implementando activamente las características que necesita TensorFlow, que incluyen: remodelación, división, reducción básica, etc. Actualmente estamos implementando la contracción. Se puede encontrar un desglose detallado en la pestaña Eigen Tensor de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

TensorFlow
Se han implementado muchas operaciones de coeficiente, incluidas Abs, Floor, IsFinite, Log, Pow, Mul, etc., así como manipulaciones de tensor como reformar, dar forma, identidad, relleno, etc.
Se puede encontrar un desglose detallado en la pestaña TensorFlow Kernels de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219

Organización
La hoja de cálculo anterior tiene varias pestañas que clasifican los esfuerzos del proyecto como: plan general, tensor propio, núcleos de TensorFlow, modelos.

Si desea participar, escriba su nombre junto al elemento en el que está trabajando o agregue algo importante que falte.
Gracias,
Lucas

¿Está activa esta hoja de ruta?

@lukeiwanski Sí, no hay problema. Póngase en contacto con nosotros a través de [email protected]

Después de leer todo esto, supongo que todavía no hay una solución sólida para usar OpenCL en macOS/OS X. Traté de compilar Tensorflow C ++ con soporte para OpenCL (que supongo requiere ComputeCpp para SYCL 1.2 como alguien señaló).

Miré a mi alrededor y no pude ubicar dónde descargar, compilar o construir la biblioteca SYCL. ¿Está aquí https://www.codeplay.com/ ? No estoy seguro de cómo proceder, gracias...

@dylib Por lo que sé, todavía no hay un ComputeCpp para macOS. Eso significa que OpenCL para macOS no está listo.

Todavía no puedo hacer que funcione en Ubuntu 16.04 con tarjeta AMD y controlador de catalizador https://github.com/tensorflow/tensorflow/issues/6497. ¿Hay algún cómo?

Tuve que mirar la salida de /usr/local/computecpp/bin/computecpp_info antes de intentar usar TF compilado con soporte OpenCL. En mi caso se muestra

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

ahora hay 2 opciones para ejecutar TF en GPU:
buen trabajo en un número limitado (por proveedor) de dispositivos, pero CUDA patentado
mal funcionamiento en un número limitado (por parte de los desarrolladores de computecpp) de dispositivos y también en computecpp propietario
Todavía no hay soporte para OpenCL.

@inferrna Allí, en una sección específica de OpenCL en la documentación general de TensorFlow. Esto se publicará pronto en el sitio tensorflow.org.

@benoitsteiner ¿Cuál es el estado actual del soporte de convoluciones opencl? ¿Está planeando aprovechar los núcleos existentes directamente? ¿Qué pasa con las multiplicaciones de matrices?

¿Algún ETA?

¿Qué tal usar HIP para portar el código CUDA a una plataforma independiente? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Parece que AMD está trabajando en eso: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45#issuecomment -269827686

¿Se pueden convertir los backends LLVM IR de XLA a SPIR-V con https://github.com/KhronosGroup/SPIRV-LLVM?

¿Qué tal esto? Creo que este paquete puede funcionar en Radeon GPU.

https://github.com/RadeonOpenCompute/ROCm

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

@lukeiwanski ¿XLA impactará también en tu esfuerzo?

Las soluciones XLA y SYCL son complementarias para diferentes situaciones: SYCL está diseñado para proporcionar programabilidad y personalización completas. XLA es para optimizar patrones bien definidos en gráficos.

Mi entendimiento de XLA es que optimiza algunos gráficos TensorFlow existentes en tiempo de ejecución usando el compilador LLVM. Requiere que se implementen pases de optimización en el compilador para cada algoritmo utilizado en el gráfico.
El enfoque SYCL es el único enfoque que ofrecerá un nivel de programación CUDA, que es lo que necesitan los desarrolladores.

Con SYCL, nuestro objetivo es brindar soporte para todas las operaciones de TensorFlow y facilitar el desarrollo de nuevas operaciones.

Esto significa que SYCL le permite escribir nuevas operaciones de alto rendimiento muy fácilmente, mientras que XLA puede optimizar gráficos completos si admite todas las operaciones en el gráfico.

¿Se pueden convertir los backends LLVM IR de XLA a SPIR-V con https://github.com/KhronosGroup/SPIRV-LLVM?

No veo ninguna razón por la que eso no sería posible.

@lukeiwanski Gracias, buscaba específicamente https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend

@k-hashimoto: estamos discutiendo aquí sobre la migración de TensorFlow a OpenCL, un estándar de Khronos Group, y en realidad más OpenCL SYCL, el estándar posmoderno de fuente única de C++ de Khronos Group.
ROCm parece otra solución no estándar de algún proveedor.
Si está interesado en soluciones propietarias, ya existe una versión CUDA de TensorFlow que parece funcionar bien. :-)

De acuerdo: mantenga la conversación/esfuerzos en OpenCL y deje que los proveedores implementen lo que sea sobre ese estándar abierto.

El 17 de enero de 2017 a las 10:01:32 GMT+00:00, Ronan Keryell [email protected] escribió:

@k-hashimoto: estamos discutiendo aquí sobre la migración de TensorFlow a
OpenCL, un estándar de Khronos Group, y en realidad más OpenCL SYCL,
el estándar posmoderno C++ de fuente única de Khronos Group.
ROCm parece otra solución no estándar de algún proveedor.
Si te interesan las soluciones propietarias, ya existe un CUDA
versión de TensorFlow que parece funcionar bien. :-)

--
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-273076892

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

:+1:

👍

:+1:

Este mensaje fue creado automáticamente por el software de entrega de correo.

Un mensaje que envió no se pudo entregar a uno o más de sus
destinatarios Este es un error temporal. La(s) siguiente(s) dirección(es) diferida(s):

[email protected]
El dominio biomasaiv.es ha superado el máximo de correos electrónicos por hora (111/100 (111%)) permitidos. El mensaje se volverá a intentar más tarde

------- Esta es una copia del mensaje, incluyendo todos los encabezados. ------
Recibido: de github-smtp2-ext6.iad.github.net ([192.30.252.197]:48606 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
por chi-server32.websitehostserver.net con esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Éxodo 4.87)
(sobre-de [email protected] )
identificación 1cWmiQ-0032as-W9
para [email protected]; jueves, 26 de enero de 2017 10:16:03 -0600
Fecha: miércoles, 25 de enero de 2017 04:09:21 -0800
Firma DKIM: v=1; a=rsa-sha256; c=relajado/relajado; d=github.com;
s=pf2014; t=1485346161;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg=;
h= De:Responder-a :Para:CC:En-respuesta-a: Referencias:Asunto :Lista-ID:
List- Archive:List-Post :List-Un subscribe:From;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
De: Miguel Ángel [email protected]
Responder a: tensorflow/tensorflow [email protected]
Para: tensorflow/tensorflow [email protected]
CC: Suscrito [email protected]
ID de mensaje:
En respuesta a:
Referencias:
Asunto: Re: [tensorflow/tensorflow] Compatibilidad con OpenCL (#22)
Versión Mime: 1.0
Tipo de contenido: multiparte/alternativo;
límite="--==_mimepart_5888957158d12_78b73ff902fe113c148134";
conjunto de caracteres = UTF-8
Codificación de transferencia de contenido: 7 bits
Precedencia: lista
X-GitHub-Remitente: migpradel
X-GitHub-Destinatario: biomasaives
X-GitHub-Razón: suscrito
ID de lista: tensorflow/tensorflow
Archivo de lista: https://github.com/tensorflow/tensorflow
Publicación de lista: [email protected]
Lista-Darse de baja:,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Response-Suppress: Todo
X-GitHub-Recipient-Address: [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Tipo de contenido: texto/simple;
conjunto de caracteres = UTF-8
Codificación de transferencia de contenido: 7 bits

--
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Tipo de contenido: texto/html;
conjunto de caracteres = UTF-8
Codificación de transferencia de contenido: 7 bits

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo .

----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Nuevo aquí. Quería preguntar si habrá compatibilidad con OpenCL en tensorflow en el futuro, ¿eso significaría que habrá compatibilidad para ejecutar tensorflow en FPGA?
Gracias

@atinzad : sí, si la versión y el código fuente de OpenCL o SYCL son compatibles con el entorno FPGA. Pero dado que TensorFlow es quizás el marco más portado con varios medios, es posible que ya tenga alguna parte ejecutándose en un FPGA en algún lugar...

DIOS MÍO. https://www.youtube.com/watch?v=LqLyrl-agOw

¿Cuáles son las diferencias entre el esfuerzo de desarrollo de sycl y XLA dirigido a SPIR-V que no sea PTX en una visión a mediano plazo?

Qué gran pregunta. Probablemente, ¿el número de personas involucradas? Sería muy interesante saber!

El 16 de febrero de 2017, a la 1:35 p. m., bhack [email protected] escribió:

¿Cuál es la diferencia entre el esfuerzo de desarrollo de sycl y XLA dirigido a SPIR-V que no sea PTX en una visión a mediano plazo?

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

¿Cuál es la diferencia entre el esfuerzo de desarrollo de sycl y XLA dirigido a SPIR-V que no sea PTX en una visión a mediano plazo?

@bhack Esa sería una gran discusión en la Cumbre de desarrollo de TensorFlow de ayer

¿Pregunta sobre los recursos disponibles / tipo de programadores necesarios para contribuir?

Si es así, en el enfoque de OpenCL/SYCL, los programadores de C++/OpenCL C pueden ponerse al día rápidamente y ser capaces de contribuir. El enfoque XLA requiere una experiencia de compilador/llvm.

XLA es el proyecto interno de Google, por extensión, tienen más recursos asociados. Pero, por otro lado, su tarea también es mucho más grande... Escribir un compilador no es una tarea fácil.

De lo contrario, si está preguntando por el modelo:

Como mencioné anteriormente en https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870, vemos ambos esfuerzos como enfoques complementarios y ambos tienen diferentes casos de uso. Todavía estoy con esa declaración.

Por ejemplo, @tatatodd en su presentación mencionó que algunos de los Ops nunca tendrán a XLA como objetivo. Creo que es posible llenar ese vacío.

Otras cosas a considerar son las nuevas plataformas. Usaré un entorno móvil e integrado por el bien de este argumento, ya que los nuevos chips tienden a aparecer con más frecuencia que las GPU (el principio es el mismo).

Si el semiconductor es compatible con SYCL / OpenCL, obtiene soporte TF listo para usar (es posible que se requieran algunos ajustes de rendimiento).

Si la arquitectura es exótica y aún no hay un backend LLVM para ella, XLA necesita agregarla (es posible que no suceda con demasiada frecuencia, pero aun así). Lo que sucede con más frecuencia es que la arquitectura cambia un poco y luego se deben agregar nuevos pases de optimización o se debe modificar uno existente para obtener el beneficio. Ajustar el código del kernel es más fácil.

No he buscado mucho en XLA, pero supongo que XLA tiene que llamar a la API de CUDA de alguna manera para ejecutar el código del kernel PTX, por lo que tendría que ser portado a OpenCL o Vulkan para ejecutar kernels SPIR-V en su lugar, eso supongo. pasaría por StreamExecutor, otro marco con el que familiarizarse, probablemente un gran esfuerzo.

En resumen, proporcionamos una plataforma unificada/estable en un ecosistema muy fragmentado/desviado al que pueden apuntar tanto las empresas de semiconductores como los desarrolladores. Donde como XLA tendría que comprometerse a apoyar.

@benoitsteiner o @drpngx podrían brindar más conocimiento interno de XLA, ya que estoy trabajando con muchas suposiciones/conclusiones basadas en conversaciones.

Ah, también he creado un canal de holgura para facilitar la comunicación https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Eidt:
El enlace de Slack ya no es válido. Por favor, hágame un ping si desea unirse.

Creo que eso es correcto y en parte dependerá en qué dirección se orientarán los productores de semiconductores.
"Estos backends emiten el LLVM IR necesario para representar el cálculo de XLA HLO de manera eficiente y luego invocan LLVM para emitir código nativo desde este LLVM IR". Entonces LLVM IR podría convertirse en SPIR-V . Pero el dialecto Opencl SPIRV es diferente de Vulkan . Streamexecutor se está insertando en LLVM paralelo-lib y en la descripción original de @henline , el plan original parece cubrir opencl.

/ cc @ dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
Nvidia pronto debería admitir opencl 2.0 tanto en Linux como en Windows, ¡esto es YUGE!

Sin embargo, en cuanto al rendimiento, es probable que sea más lento que CUDA.

Recuerde también que los chicos de Noveau están trabajando de forma independiente en Opencl con SPIR-V . El estado está un poco desactualizado, pero hay confirmaciones nuevas.

Opencl no es intrínsecamente más lento que Cuda, es simplemente nvidia prácticamente bloqueando el mercado al paralizar su controlador opencl.
Pero el liderazgo de nvidia finalmente está llegando a su fin e incluso sus prácticas inmorales anticompetitivas no los salvarán. Con el impresionante traductor automático Cuda HIP ( https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
Los próximos vega apus y dgpus y ARM llegarán a Windows, Nvidia no tiene futuro, es por eso que la industria NECESITA admitir opencl/syCL/HIP/HSA muy pronto y de forma masiva.

¿Qué pasa con la diapositiva 40 de https://autodiff-workshop.github.io/slides/JeffDean.pdf?

Hola, ¿estoy planeando que tensorflow sea compatible con el nuevo AMD Radeon Instinct? (http://instinct.radeon.com/en-us/)

Hola, ¿hay algún progreso en el soporte de TF-OpenCL para FPGA?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 se eliminó hace algunos meses y la hoja de ruta de Streamexecutor no está clara.

@bhack gracias por la rápida respuesta
Entonces, ¿significa esto que no hay soporte, o que no se garantiza el correcto funcionamiento?
Además, por lo que leí en este hilo, veo que las pruebas son principalmente en GPU AMD... ¿alguien está entrenando redes en GPU Nvidia con este puerto OpenCL?

Se cambió el nombre de Streamexecutor en LLVM paralelo-libs y ahora es acxxel

¿Algún miembro de Google puede explicar la diferencia y las hojas de ruta entre streamexecutor y https://reviews.llvm.org/rL285111?

CC @zheng-xq

@henline y @jlebar son los expertos en responder la diferencia entre streamexecutor y https://reviews.llvm.org/rL285111?

Axcell y StreamExecutor son proyectos separados. No hay planes actuales para fusionarlos. Dejo que la gente de TensorFlow diga si planean cambiar o no.

Entonces, ¿también StreamExecutor y StreamExecutor llvm no eran los mismos proyectos?

Correcto, no son el mismo proyecto.

El jueves 16 de marzo de 2017 a las 11:06 a.m., bhack [email protected] escribió:

Entonces, ¿también StreamExecutor y StreamExecutor llvm no eran los mismos proyectos?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar La próxima vez, una unidad creativa para nombrar;) pero probablemente no fue una falta de motivación creativa, sino solo un esfuerzo ascendente de una herramienta interna que divergió de la mantenida en TF.

@bhack , cambiamos el nombre, precisamente cuando nos dimos cuenta de que lo hicimos
No creo que tenga sentido mover StreamExecutor a LLVM al por mayor. Es
ahora llamado "Acxxel".

Lo siento por la confusión y agradezco los comentarios... Fue un
proceso de aprendizaje seguro.

El jueves 16 de marzo de 2017 a las 11:24 a. m., bhack [email protected] escribió:

@jlebar https://github.com/jlebar La próxima vez, una unidad creativa para nombrar
;) pero probablemente no fue una falta de motivación creativa, sino solo una
esfuerzo ascendente de una herramienta interna que divergió a la mantenida
en TF..

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Sí, todavía tengo un poco de confusión entre StreamExecutor, SyCL en eigen, XLA (que en realidad solo tiene un backend CUDA, además de CPU y opencl en algunas diapositivas)

Protuberancia

¿Alguien en Google ha hablado con Apple o AMD para aliviar esto? Supongo que la gente de AMD está tan perdida que ni siquiera saben que el problema está ahí y todavía se preguntan por qué Nvidia tiene una cuota de mercado tan grande. Supongo que el equipo de inteligencia artificial de Apple también estaría más que feliz de ayudar aquí... si OpenCL no fuera un abandonware de su lado desde 2013 y, lo que es peor, sus jefes no se enfadaran con Google.

¿Qué es lo último sobre esto?

De acuerdo con las notas de la versión de TF 1.1 , la compatibilidad con Mac GPU (solo Nvidia) ha quedado obsoleta. Esperemos que esto ayude a mejorar el enfoque de OpenCL (no estoy muy seguro de esto).

También puede seguir el estado del PR https://github.com/tensorflow/tensorflow/pull/9117

¡Gracias! Estoy siguiendo este tema durante los últimos meses. No estoy seguro del compromiso de Apple con OpenCL, dado que están atascados en OpenCL 1.2 desde 2013 (Apple aún no brinda soporte para SPIR 1.2).

Si TensorFlow en OpenCL lo ayudaría en su trabajo, hágamelo saber, en la medida en que pueda ayudar a avanzar en la investigación y la práctica del aprendizaje profundo, me gustaría ayudar. Mi empresa ha creado un back-end OpenCL para TensorFlow ajustado para una variedad de GPU como parte de nuestro trabajo en la inferencia en el dispositivo. Hemos probado en las principales familias de GPU móviles y de escritorio, incluidas las configuraciones comunes en Windows y Mac. Si hay suficiente interés, podemos hacer algún tipo de distribución pública. También tenemos Metal (GPU de Apple) y LLVM (CPU), junto con una forma de realizar una implementación de dependencia cero. La idea aquí es dar a cada dispositivo un gran soporte para el aprendizaje profundo.

@choongng : todo eso suena increíblemente útil y útil. Mi proyecto personal https://github.com/Synopsis/ se beneficiaría enormemente de OpenCL en OS X, así como de la implementación de Metal para iOS y escritorio. Si es posible que esto se introduzca en Tensorflow propiamente dicho, creo que sería una gran ayuda para muchos desarrolladores.

Gracias.

@choongng

Si su empresa publica una versión OpenCL, o más interesante una versión Metal de TensorFlow, creo que esto será una gran noticia para mucha gente, estoy en el proceso de construir una eGPU con una tarjeta NVidia para obtener TensorFlow / Keras corriendo en mi MBP por mi trabajo...

Para las personas interesadas... vaya a la comunidad eGPU.io

@choongng

¡Estaría muy interesado en ver esto, así que estaría muy agradecido de que pudieras seguirlo! Especialmente si no requiere los compiladores de código cerrado incompletos que TF ha elegido para el soporte de CL.

El 26 de abril de 2017 a las 03:33:51 GMT+01:00, Choong Ng [email protected] escribió:

Si TensorFlow en OpenCL lo ayudaría en su trabajo, hágamelo saber, al
medida en que puedo ayudar a avanzar en la investigación y la práctica del aprendizaje profundo, me gustaría
gusta ayudar Mi empresa ha creado un back-end OpenCL para TensorFlow
ajustado para una variedad de GPU como parte de nuestro trabajo en la inferencia en el dispositivo.
Hemos probado en las principales familias de GPU móviles y de escritorio, incluidas
configuraciones comunes en Windows y Mac. Si hay suficiente interés,
puede hacer algún tipo de distribución pública. También tenemos Metal (GPU de Apple)
y LLVM (CPU), junto con una forma de realizar una implementación de dependencia cero. los
La idea aquí es darle a cada dispositivo un gran soporte para el aprendizaje profundo.

--
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-297220160

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

Creo que sería revolucionario ;)

@choongng Tal vez ayudaría si unieras fuerzas con estos muchachos
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey, ¿cuál es el compilador de código abierto que propone usar entonces? Es difícil encontrar una solución compatible con OpenCL de código abierto para abordar una gran cantidad de dispositivos en la naturaleza...
Necesitamos arrancar una solución en algún momento de alguna manera...

No dije que fuera una solución fácil. Pero, OpenCL no es el problema, allí. Después de todo, CUDA es totalmente propietario, mucho peor incluso que la opción OpenCL que eligió TensorFlow.

Dicho todo esto, hay opciones para un sistema CL-o-cuda si está comenzando desde cero, incluidos tiempos de ejecución de middleware portátiles o arrayfire, etc. Sin embargo, Tensorflow está demasiado vinculado a CUDA.

Encuentro frustrante que las personas estén dispuestas a escribir kernels en CUDA pero se resistan a hacerlo para CL, a pesar de que llegaría a más usuarios y haría crecer seriamente el ecosistema del mercado. Hay beneficios directos e indirectos en una plataforma abierta para todos, lo que posiblemente genere grandes ahorros de costos para todos a largo plazo.

Si SYSCL es la forma en que eso finalmente sucede, genial: entonces, ¿por qué algunos grandes nombres no están poniendo dinero en una distribución abierta de SYSCL en lugar de comprar opciones propietarias marginales, que de alguna manera anulan el propósito de un estándar abierto?

El 28 de abril de 2017 a las 09:13:06 GMT+01:00, Ronan Keryell [email protected] escribió:

@cathalgarvey, ¿cuál es el compilador de código abierto que propone usar entonces?
Es difícil encontrar una solución compatible con OpenCL de código abierto para
abordar una gran cantidad de dispositivos en la naturaleza...
Necesitamos arrancar una solución en algún momento de alguna manera...

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-297936468

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

Lo que quiero preguntar en este contexto es esto:

Por lo tanto, algunos marcos de trabajo de aprendizaje profundo como Tensorflow están explorando con tibieza el uso de opencl como alternativa a CUDA. Por supuesto, CUDA es solo el "lenguaje" en el que se desarrolló cuDNN, y eso (si mi entendimiento es correcto) es lo que la mayoría de los lenguajes de aprendizaje profundo están usando en realidad. En este contexto, no estoy seguro de cuál es la versión opencl de cuDNN.

Además, AMD ha estado hablando de alternativas de código abierto a CUDA que están desarrollando continuamente y que llaman rocM. También están hablando de que miOpen sea el equivalente de cuDNN (bibliotecas ensambladoras hechas a mano para funciones comunes de aprendizaje profundo), que, sin embargo, aún no se ha lanzado. El enfoque de AMD es algo más holístico: no solo estamos exportando cómputo pesado a la GPU.

En este contexto, estoy genuinamente confundido. ¿Cómo encajan los esfuerzos de opencl como los enumerados anteriormente? Para las GPU NVIDIA, es fácil... existe CUDA y cuDNN está escrito en CUDA. Para no-NVIDIA/o en este caso AMD, parece mucho menos claro. ¿Cuándo se prefiere HIP? ¿Cuándo se prefiere usar el HCC? ¿Cuándo se prefiere usar opencl? ¡Cualquier idea sería realmente apreciada!

@cathalgarvey hay mucha política detrás de todas estas enormes infraestructuras de software/hardware... :-(
Incluso si podemos soñar con una solución de borrón y cuenta nueva basada en criterios científicos puros, creo que tenemos que ser pragmáticos.
Google no quiere cambiar demasiado la arquitectura de TensorFlow. Esta es la razón por la cual la arquitectura basada en OpenCL tiene que ser muy similar, requiriendo C ++ de fuente única como "tiempo de ejecución CUDA" en lugar de la solución OpenCL C de fuente única de nivel inferior. En el reino de Khronos, la versión C++ de fuente única de OpenCL se llama SYCL.
Hablemos de esto cuando pases por Dublín, por ejemplo, ya que también pareces tener tu sede en Irlanda. :-)
Mientras tanto, no dude en contribuir a https://github.com/triSYCL/triSYCL y las ramas de TensorFlow y Eigen que se ocupan de SYCL...

@keryell ¿Sabe si también XLA: GPU : OpenCL está planeado en SyCL?

Hola @benoitsteiner , con respecto a:

Allí, en una sección específica de OpenCL en la documentación general de TensorFlow. Esto se publicará pronto en el sitio tensorflow.org.

Hice una búsqueda en tensorflow.org para OpenCL y no parecía ser capaz de encontrar nada significativo, todo parece apuntar aquí. Por "pronto", ¿quieres decir antes de ______? (_inserte sarcasmo gracioso aquí_).

Pude compilar su repositorio (¡sí!), aunque supongo que necesita algo más para crear un Tensorflow OpenCL funcional para Mac; Intenté construir el compilador triSYCL mencionado pero lamentablemente fallé.

@bhack Dado que no trabajo para Google, no tengo idea de los detalles de XLA...

@dylib lamentablemente todo esto es un trabajo en progreso...

@keryell Sí, lo sé... Tenía curiosidad por saber si se discutió en algunas reuniones.

OpenCL es radicalmente diferente de CUDA. Sin embargo, definitivamente vería esto portado a HIP en su lugar.
Así que +1 para todos los que lo sugirieron.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

HIP permite a los desarrolladores convertir código CUDA a C++ portátil. El mismo código fuente se puede compilar para ejecutarse en GPU NVIDIA o AMD

No mucha gente sabe acerca de HIP.
Puede encontrar más información sobre tensorflow y HIP aquí:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
y
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Nota al margen:
No creo que debamos pelear/presumir sobre Nvidia vs AMD. Esas son compañías respetables que hacen un punto de hardware y software increíble. En su lugar, deberíamos centrarnos en ofrecer tensorflow a una base de usuarios más grande.
Apuntar a muchos idiomas a través de enlaces ya es un buen punto de partida, pero también debemos apuntar a la mayor cantidad de hardware posible. (Incluso si las soluciones en la nube son increíbles, no siempre son la respuesta)

Tenemos experiencia con HIP, aquí en Stream. Déjame ver.

De acuerdo con el argumento de "mi empresa es mejor". Me gustaría saber a qué GPU debería apuntar TensorFlow. Tiene que ser pragmático y útil. Por ejemplo, GPU Intel o GPU integradas (Qualcomm, ARM, Imagination), RaspBerry Pi, ¿sí o no?

Edición AMD Radeon Vega Frontier

Continuamos mejorando agresivamente nuestra plataforma de software abierto ROCm y las bibliotecas de aprendizaje automático. También admitimos marcos abiertos de inteligencia artificial como Caffe (lanzado en abril). Más adelante en este trimestre, planeamos ofrecer soporte para Torch, y Tensor Flow está en proceso.

Ya lanzaron Caffe, estarían muy interesados ​​en escuchar a otros en este hilo compartir sus experiencias con la construcción/prueba:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Comencé a instalar, pero encontré un obstáculo donde cualquier cosa que requiera CL simplemente se congela, incluso clinfo . No estoy seguro si esto se debe a algún problema de software o si mi tarjeta (R9 390) simplemente no es compatible con ROCm.

El 17 de mayo de 2017 a las 15:18:32 GMT+01:00, Bryan Li [email protected] escribió:

Frontera de AMD Radeon VegaEdición

Continuamos mejorando agresivamente nuestra plataforma de software abierto ROCm
y bibliotecas de aprendizaje automático. También estamos apoyando la máquina abierta
marcos de inteligencia como Caffe (lanzado en abril). Más tarde esto
trimestre planeamos ofrecer soporte para Torch, y Tensor Flow está en
los trabajos.

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-302103815

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

@cathalgarvey He estado usando la rama Caffe OpenCL en las GPU de AMD y funciona bien. make run test pasó todas las pruebas excepto una

bueno escuchar; ¿Puedo preguntarle acerca de su configuración de HW/SW? Por ejemplo, qué tarjeta eres
usando, ¿qué distribución/versión de Linux, etc.?

Anteriormente tenía AMDGPU-pro, pero la desinstalé al instalar ROCm.
Es posible que haya algo heredado interfiriendo conmigo.

--
@onetruecathal / @ [email protected]

El miércoles 17 de mayo de 2017 a las 3:50 p. m., Bryan Li [email protected]
escribió:

@cathalgarvey He estado usando la rama Caffe OpenCL en las GPU de AMD y
funciona bien make run test pasó todas las pruebas excepto una

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@cathalgarvey

• Rama Caffe OpenCL (compromiso probado c61d48746b2df1d237c64abc7416342ce98f3251 )
• SO: Ubuntu 16.04.2 LTS
• Probado en Polaris (RX460), Fiji (Fury X) y Tonga (W7100)
• Controlador: controlador AMDGPU-Pro para Linux 16.40 o superior
• VienaCL
• Dependencias generales: 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
• hacer: 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 ..

Sí, además de la rama de OpenCL anterior, naibaf7 publicará un libro (muy pronto) sobre su uso para la inferencia en tiempo real en hardware básico con gráficos amd y hd.

Ah; Estaba hablando de hipCaffe, no de la rama OpenCL:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Instalar ROCm para compilar/probar hipCaffe me obligó a desinstalarlo
AMDGPU-pro, tal vez vuelva a probar la rama vainilla. esta mal
documentado, desafortunadamente ... Supongo que intentaré un "make" ciego y veré.

Entonces, todavía estoy interesado en escuchar las experiencias de otros con AMD.
pila ROCm/HIP; si están trabajando en una bifurcación de Tensorflow, sería genial,
siempre que realmente funcione en más de 3/4 modelos de tarjeta AMD en el
salvaje.

--
@onetruecathal / @ [email protected]

El miércoles 17 de mayo de 2017 a las 4:09 p. m., Bryan Li [email protected]
escribió:

@cathalgarvey

Rama Caffe OpenCL (compromiso probado
c61d48746b2df1d237c64abc7416342ce98f3251)
SO: Ubuntu 16.04.2 LTS
Probado en Polaris (RX460), Fiji (Fury X) y Tonga (W7100)
Controlador: controlador AMDGPU-Pro para Linux 16.40 o superior
VienaCL
Dependencias generales: libprotobuf-dev libleveldb-dev libsnappy-dev
libopencv-dev libhdf5-serial-dev protobuf-compiler libatlas-base-dev
libblas-dev libgflags-dev libgoogle-glog-dev liblmdb-dev
libboost-all-dev cmake git python-numpy cmake
—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@cathalgarvey Espero que estén trabajando en un backend moderno, no en una bifurcación completa. Eso sería triste y solo dividiría el esfuerzo de trabajo.
Ya hay suficientes herramientas :/

Los esfuerzos de @YvanDaSilva AMD están un poco mal coordinados en este momento (sí, todas las bifurcaciones). Además, todavía no parece funcionar tan bien en una gran variedad de dispositivos, a diferencia de la rama OpenCL de Caffe, por ejemplo...

@naibaf7 Estoy absolutamente de acuerdo.
Para ser honesto, realmente parece que les falta recursos humanos, están trabajando en todos los frentes.
Por cierto: no sabía que ETH tenía Neuroinformática;) ¡bien!

@cathalgarvey ¿Puede dar más detalles sobre la pila ROCm/HIP para un lego como yo? He estado jugando AMGPU-pro y AMDGPU con mis tarjetas Sea Islands, así que estoy seguro de que podría publicar algunos resultados útiles.

@YvanDaSilva
Patrocinaron mi proyecto Caffe OpenCL original y, desafortunadamente, no se coordinaron bien, por lo que la investigación de AMD y un tipo independiente de AMD también trabajaron en puertos OpenCL en paralelo: el antiguo equipo de investigación de AMD ahora está disuelto y la mayoría de ellos trabajan para Tesla ( proyecto de automóvil autónomo) ahora... así que una desafortunada cadena de eventos.
Sin embargo, sigo colaborando y en contacto con ellos. Vega va a ser interesante :)

@naibaf7 ¡Bien, qué suerte! Ojalá hubiera habido tales estudios cuando estaba en Heig-vd, ciertamente hubiera continuado con una maestría.

Sí... Eso es lo que pensé. Tanto trabajo, tan pocos recursos humanos disponibles en estos campos.

Todo eso suena genial, pero volvamos a centrar la discusión en tener TensorFlow trabajando con OpenCL SYCL y no solo con soluciones específicas del proveedor... :-)
Espero que RoC y otros HiP tengan su propio GitHub para discutir sus propios problemas...
@naibaf7 : al menos todavía estoy en el ámbito de OpenCL. ¡Únete al club de nuevo! :-)

@keryell Creo que la discusión sobre HIP es válida, si hay un puerto HIP para Tensorflow en proceso. Después de todo, la solución oficial de Tensorflow-on-CL es utilizar un marco SYCL patentado con una plataforma muy limitada y compatibilidad con kernel, por lo que no es mejor que las soluciones HIP "específicas del proveedor" que ofrecen una nueva forma de salir de CUDA.

HIP puede ser principalmente lo que hace AMD en este momento, pero AFAIK es un estándar abierto. Quizás me equivoque. Sin embargo, si es así, y si AMD puede ofrecer un puerto tensorflow-on-HIP, inmediatamente sería más abierto que el tensorflow-on-SYCL oficial.

HIP es un subconjunto de CUDA, por lo que es tan abierto como CUDA.

Está bien; HIP-the-API es un subconjunto de CUDA-the-API, pero a menos que NVidia sea lo suficientemente cobarde como para comenzar a canalizar Oracle, dudo que eso sea un problema. Me refería al tiempo de ejecución/compiladores para HIP, de los cuales creo que los AMD están ~abiertos.

editar : Lo siento si lo anterior sonó grosero; ¡Solo trato de aclarar mi posición anterior!

¿ Se fusionarán Vulkan y Opencl ?

según Reddit AMA de Raja, Vega admitirá Tensorflow, Cafe2, Cafe, Torch7 y MxNet a través de MIOpen.

@cathalgarvey la discusión es claramente válida, pero no aquí...
Está en GitHub aquí, en la pista que analiza el puerto de TensorFlow y Eigen usando los estándares de Khronos Group.
Esto no es Twitter ni tu muro de Facebook... :-)
¡Así que por favor contribuya con algunos compromisos en estos proyectos! :-)

Hay una nueva versión de la guía de configuración para compilar TensorFlow con ComputeCpp, la implementación de SYCL de Codeplay, para que se puedan usar dispositivos OpenCL. Agradeceríamos cualquier comentario que nos pueda dar al respecto. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

¿Tiene alguna idea de cuál es la tasa de éxito para hacer que esto funcione en AMD gpus no probado? Me interesa específicamente si se ha probado para AMD Radeon Pro 460 @rodburns. Estaría feliz de pasar unas horas ejecutando ubuntu en mi computadora portátil Macbook si hay alguna esperanza con una GPU no probada

@samhains no hemos probado esto, pero podría intentarlo. Deberá usar algunos controladores AMD más antiguos con Ubuntu que admitan la extensión SPIR. Todavía no he podido averiguar qué controladores son esos todavía.

@samhains Si la ruta del juego de código no funciona, no se pierda tf-coriander , que finalmente se encuentra en un estado de uso práctico en Ubuntu/Mac.

Actualmente lo estoy probando en convnets, rnns bidireccionales, etcétera y todo parece estar funcionando muy bien. Se ejecuta en OpenCL 1.2 "vainilla", por lo que debería habilitar Tensorflow en una amplia gama de hardware relativamente antiguo.

El problema es, por ahora, que está basado en Tensorflow 0.11.

@rodburns. Intenté seguir los pasos enumerados en el enlace https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp
Obtuve el siguiente error:
ERROR: /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD:609 :1: inclusiones no declaradas en la regla '@protobuf//:python/google/protobuf/internal/_api_implementation.so ':
En realidad, recibo el mismo error si intento compilar tensorflow desde la fuente. Lo he compilado antes, aunque no estoy seguro de qué ha cambiado.

@rahasayantan, ¿qué es lo que se incluye? ¿También lo obtienes al compilar sin --config=sycl ?

@lukeiwanski : Según tengo entendido, el problema es que Bazel está tratando de compilar Protobuf y no encuentra ni descarga los subdirectorios. Hice una extracción con el submódulo recursivo y todavía tiene los mismos problemas. Y tiene el mismo problema sin --config = sycl. De hecho, me enfrento al mismo problema cuando hago una extracción de git del proyecto principal de tensorflow. No creo que esto esté relacionado con openCL, son algunos problemas con la forma en que estoy haciendo el tirón. Cuando descargo manualmente el zip del proyecto de su repositorio sin git y compila, se compila correctamente, pero luego aparece una falla de segmentación. Ya planteé este problema en su proyecto GIT y estamos hablando allí, daré las actualizaciones relacionadas con la falla de segmentación en ese hilo (no tiene sentido duplicar cosas). Gracias por su respuesta.

TriSYCL de código abierto está llegando. Consulte https://github.com/triSYCL/triSYCL/pull/45

Soy nuevo aqui. Muy interesado en ver que TF admita OpenCL. ¿Cómo obtengo actualizaciones de este hilo?

emmm... Interesante, pero ¿por qué? Quiero decir, ¿por qué Tensorflow eligió cuda pero opencl al principio? ¿Algún motivo comercial, supongo?

Hola @tensorflower-gardener,

@hughperkins ha creado Coriander que podría ejecutar código NVIDIA® CUDA™ en dispositivos OpenCL 1.2. Es posible que desee echar un vistazo si eso se adapta a su necesidad de conectar TF a dispositivos OpenCL 1.2. Atribuya amablemente su nombre y su contribución en caso de que planee utilizar su trabajo.

Parece que las esperanzas de ver alguna vez soporte de OpenCL para Mac han pasado de ser pequeñas a tf.zero . Acabo de leer que TensorFlow Mac aparentemente ya no tendrá NINGÚN soporte para GPU (1.2+):

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

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

TF-Coriander se prueba en Mac, por lo que si alcanza la paridad de versión, debería poder usarlo.

El 22 de junio de 2017 a las 11:46:51 CEST, dylib [email protected] escribió:

Parece que las esperanzas de ver alguna vez soporte de OpenCL para Mac han pasado de
poco a tf.zero . Acabo de leer que las Mac ya no tendrán
CUALQUIER soporte de GPU aparentemente (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

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-310331281

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

Triste porque ahora con una eGPU y n Nvidia 980 Ti adentro, tenemos el controlador funcionando y Cuda funcionando

Todavía no tuve tiempo de probar Tensor Flow en mi configuración.

webdriver y Cuda toolkit instalados en mi computadora y las muestras de Cuda funcionan bien

https://youtu.be/JN9fDmqf010

@cathalgarvey dijiste que probaste convnets en tf-coriander, pero parece que los convnets todavía no funcionan. ¿Puede aclarar si logró que las convnets se ejecutaran en la GPU usando tf-coriander?

para tu información,
https://github.com/tensorflow/tensorflow/issues/10703

¿Por qué tensorflow ya no admite GPU en OS X? Planeaba usar Tensorflow con una configuración de eGPU que tengo en orden.

@justinrmiller afirman que ya no pueden probarlo en Mac OS y, por lo tanto, decidieron detener el soporte. sin embargo, me cuesta creer eso. En el futuro con el anuncio de egpus en high sierra y con los nuevos controladores nvidia, este ya no será el caso.

@tscholak sí exactamente. Iba a usar mi nuevo gabinete egpu para deshacerme de mi caja de ventanas para siempre.

Teniendo en cuenta que aunque las tarjetas Nvidia funcionan en gabinetes eGPU, Apple solo admitirá oficialmente el RX580 en su kit de desarrollo, por lo que la necesidad de OpenCL no desaparecerá.

OpenCL en Mac es 1.2, lo que significa que parece que no hay un controlador activo
desarrollo. Creo que agregar soporte Metal a TF es un proceso laborioso.
(habilitando Eigen y stream ejecutor) pero factible.

El domingo 16 de julio de 2017 a las 3:17 p. m. Ferdia McKeogh [email protected]
escribió:

Teniendo en cuenta que aunque las tarjetas Nvidia funcionan en gabinetes eGPU, Apple
solo admitirá oficialmente el RX580 en su kit de desarrollo, por lo que la necesidad de
OpenCL no desaparecerá.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Estoy muy triste por el abandono de la compatibilidad con GPU para macOS.

Sigo buscando compatibilidad con OpenCL para GPU en macOS porque Apple, obviamente, no cambiará a GPU Nvidia en el corto plazo.

Tensorflow es mi motor preferido. Usar la aceleración de GPU localmente en mi MacBook Pro o en el futuro iMac Pro sería increíble.

Para Microsoft tendría sentido sabotear a Apple, pero dado que Google no tiene un sistema operativo de escritorio, solo se están lastimando a sí mismos.

Honestamente, alguien más inteligente que yo debería considerar la integración de MPS - Metal Performance Shaders de Mac OS 10.13 que tienen soporte para un gran conjunto de primitivos de red neuronal listos para usar. Esto permitiría una GPU actualizada y de alto rendimiento para iOS móvil y de escritorio y la implementación de inferencia de macOS Tensorflow.

Según tengo entendido, no puedes entrenar con las primitivas de Apple (no proporcionan nada), pero con el soporte de Tensorflow, ¿tal vez podrías? Me imagino que para la gente de la plataforma de Apple sería una bendición.

No creo que Google proporcione esto internamente, y no tengo las habilidades necesarias para intentarlo yo mismo. Publicar esta idea para que la gente con más talento que yo pueda asumirla.

:)

Apple tiene como único objetivo vender dispositivos Apple. Google tiene como objetivo contratar los servicios masivos de Google.

Si está dispuesto a hacer IA (aprendizaje) con un solo dispositivo, como una computadora portátil Apple, hará "Aprendizaje superficial" en lugar de "Aprendizaje profundo", por lo que será mejor que deje de hacer cualquier cosa que no sean tutoriales. La inferencia da como resultado un modelo entrenado para un solo usuario, en un solo dispositivo (incluso en un teléfono con varios núcleos y no demasiados), podría ser bueno hacerlo a través de GPU, pero es perfectamente factible solo con CPU.

Por otro lado, las GPU son absolutamente necesarias si va a alimentar conjuntos de datos extremadamente grandes para el aprendizaje o si va a ofrecer inferencias entrenadas a grupos de clientes simultáneos extremadamente grandes.

Aunque, hacerlo a tal escala, no es tan fácil debido a problemas de red. Solo eche un vistazo a la arquitectura física de TPU-Pods. Está en la antípoda de una computadora portátil (varias GPU por servidor multinúcleo sobrecargado de memoria, con fibra óptica dedicada para comunicaciones entre servidores).

Tengo un macbook pro. Es un lindo terminal para llegar a la nube :-D

Veo que TF on Metal también puede extenderse a iOS. Si alguien está interesado en retomarlo, recomiendo agregar soporte de Metal a Eigen primero (puede usar OpenCL como referencia).

@rogerpasky Para la escuela tuve que usar Tensorflow para entrenar modelos, no solo para evaluar un modelo. Y tendré que repetir esto nuevamente en un futuro cercano. Para estudiantes como yo, tener formación en GPU es imprescindible, ahorrando mucho tiempo. No es solo una cuestión de servir a múltiples usuarios concurrentes.

@rogerpasky se trata de la capacidad de desarrollar modelos y soluciones localmente en una Mac

@rogerpasky respetuosamente en desacuerdo. Si bien las soluciones multi-GPU basadas en la nube funcionan muy bien para los servicios de Internet, estoy apuntando a canalizaciones de producción de video profesional donde la inferencia se ejecuta en horas y horas de material de archivo HD, 2K, 4K sin comprimir y pro-res, que a) ninguna casa de producción es van a subir a una nube, b) no quieren que Google o quien sea tenga sus datos, c) tienen salas llenas de sistemas con capacidad de múltiples GPU (Mac y Windows) localmente que les gustaría aprovechar, y d) mientras la inferencia en una sola imagen está bien en la CPU, ejecutar películas completas para la inferencia a través de múltiples gráficos 100% ve un aumento en el rendimiento usando algo como MPS vs CPU. Debido a que la comunidad se ha negado a apoyar/adoptar los estándares y, en su lugar, usa solo el código de Nvidia, los casos de uso del mundo real se encasillan y es realmente una pena.

Esta no es una solicitud inactiva de alguien que es un aficionado que ejecuta tutoriales: la inferencia de GPU es importante, ya que es compatible con diversas familias de GPU / CPU para diversas cargas de trabajo en hardware del mundo real. Realmente espero que Google se tome esto en serio, porque sería genial poder quedarse con una sola biblioteca como TF, que es increíble.

Gracias por escucharme, no intento despotricar, sino brindar un punto de vista alternativo a la comunidad.

@pldelisle , @tscholak , @vade , no me malinterpreten. Me encantaría tenerlo, y si buscas en este hilo me uní como seguidor, pero por lo que he estado siguiendo llegué a la conclusión que escribí, no solo porque lo creo (supongo que un MacBook se derrumbaría si se entrenara con miles de videos :-D), pero con los hechos reales de la industria. No espere a que se resuelva en un corto período de tiempo (en mi humilde opinión, nunca se resolverá porque Apple y Google se odian desde el problema de iPhone/Android).

@rogerpasky Ya había soporte para GPU nvidia en Mac OS. Se acaba de eliminar en 1.2.

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

Cancelé mi pedido de una eGPU (Sonnet) y solo iniciaré Linux de forma dual en mi plataforma de juego, pero es un poco malo dejar de admitir algo que la gente estaba usando. Realmente esperaba hacer esto en mi Mac con una eGPU (entrenamiento de modelos), pero supongo que eso no sucederá ahora: https://github.com/lengstrom/fast-style-transfer

@rogerpasky Er, ¿sabe que CoreML admite la importación de modelos de flujo de tensor a través de Keras? Apple no 'odia' a Google, los negocios son los negocios. Uno de los proveedores de Apple es Samsung. Lea eso por un momento. Google, Apple, Samsung son negocios y harán lo que genere dinero. Como nota al margen. Por cierto, mi MacBook Pro no se ha derretido por ejecutar inferencias en miles de películas. Sospecho que CUDA fue muy conveniente para adoptar y el apoyo continuo de Nvidia y las oportunidades perdidas de AMD nos llevaron a donde estamos. No creo que sea nefasto, solo el costo de hacer un cambio frente a los deltas de rendimiento frente al costo de mantener el rumbo.

Sospecho que algún genio vendrá para ayudar a resolver el problema.

Creé un grupo de Google para una discusión colaborativa sobre cómo llevar el aprendizaje profundo a nuevos lugares como OpenCL, Mac, iOS, CoreML, Vulkan, etc. Si desea ayudar a que esto suceda, únase y publique una nota con su uso. caso o en qué parte del problema está trabajando. Ya hay personas trabajando muy duro para llevar TF a más plataformas, incluidas MIOpen, el trabajo de Codeplay, TF-Coriander y un proyecto interno en mi empresa (Vertex.AI). Sería genial reunir a los desarrolladores y usuarios en un solo lugar, ya que todos estos esfuerzos están estrechamente relacionados.

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

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

@justinrmiller Tengo una eGPU en Sierra (Titan Xp en una carcasa Sonnet) que ejecuta Tensorflow 1.2.1 (CUDA 8, cuDNN 6), lo que no fue demasiado problema si no te importa construir desde cero. Si tienes algún problema, házmelo saber.

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 ¡Es increíble! Gracias por la info!

@ danbarnes333 ¿cómo conseguiste que tf 1.2 se compilara con cuDNN 6? ¿Usaste LLVM? CCG? Solo logré que se construyera con cuDNN 5...

Para tu información, https://machinelearning.apple.com/

@tscholak No lo publicaré aquí para mantener esto en OpenCL, pero resumiré los pasos aquí .

@choongng Me uní al grupo de Google pero parece estar tranquilo. Así que voy a despotricar aquí ;-)

1. El aprendizaje automático/alto rendimiento/la computación GPU es un mercado ferozmente competitivo. NVidia, nos guste o no, domina el mercado y mantiene sus tarjetas y software bajo control. Si tiene un presupuesto y una fecha límite, por ahora está más o menos atascado con NVidia.

2. Tengo una tarjeta AMD antigua ("Bonaire") y cero presupuesto: aficionado. Tengo caffe ejecutándose con la implementación patentada de AMD OpenCL 2 en Arch Linux a partir de ayer, y acabo de ejecutar el código abierto de AMD MIOpen de la misma manera esta mañana. Eso me permitirá entrenar algunos modelos; el Bonaire alcanza un máximo de alrededor de 1800 GFLOPS de precisión simple. Entonces, si TensorFlow no se ejecuta con OpenCL en Bonaire, no usaré TensorFlow.

3. Si por arte de magia apareciera un presupuesto, compraría una CPU Intel y una tarjeta NVidia y ejecutaría un software patentado respaldado por el proveedor. He terminado de hacer control de calidad gratuito para proveedores como Google, Red Hat, Canonical y AMD.

   Me tomó tres meses (y tres distribuciones: Fedora 25, Ubuntu 16.04 LTS y Arch) sacar algo de una GPU que tuve durante tres años. Hay errores no corregidos en el rastreador de errores de Fedora con mi nombre en ellos. Lo mismo ocurre con Ubuntu y Freedesktop.org. A la mayoría de las personas que los arreglarían tampoco se les paga, o se les paga por hacer otra cosa.

   Sí, las nuevas CPU de AMD son impresionantes y sí, la mayor parte de su software es de código abierto, pero los presupuestos y los plazos cambian las cosas. El apoyo es clave. ¡El apoyo lo es todo!

@znmeb Ni siquiera sabía que podía usar hardware anterior a GCN para TF.
Con mi Tahiti, solo tengo soporte para una distribución (ubuntu 14.01.x), ya que los controladores propietarios de AMD solo funcionan con kernels de Linux más antiguos para GCN1. (Obtengo TF + openCL a través de SYCL (no probado en 7970))

Donde trabajo, todo el departamento de I+D dirige un equipo ecológico. Todos tienen doctorados y todos menos ninguno escribieron una sola línea de cuda (ni OCL). Pero las herramientas están aquí para acelerar su carga de trabajo Keras . Soy un poco raro con mis GPU de minería recicladas tratando de sacarles una segunda vida.

tl; dr, que no sea el soporte del equipo verde, solo aparecerá si aparece la participación de mercado de GPU AMD.
Es un problema del huevo y la gallina. Tengo esperanzas para Vega... pero sí... no es un asesino 1080Ti.

@acoye FWIW aquí está la publicación de GitHub que me puso en marcha este fin de semana después de buscar en Google desde abril: https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . Consulte también https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . Ese fue mi problema original: tratar de usar mi Bonaire para acelerar el álgebra lineal en R.

@acoye
Puede pasar a las últimas distribuciones de Linux y usar un kernel compilado personalizado reciente como 4.11/4.12 con controladores AMDGPU habilitados, RADEON deshabilitado y con CONFIG_DRM_AMDGPU_SI=Y y/o CONFIG_DRM_AMDGPU_CIK=Y establecidos en la configuración del kernel, más el firmware de AMD para 7970 (Tahití) en initramfs => el último AMDGPU-PRO OpenCL funcionará en cualquier tarjeta GCN. Olvídese de FGLRX (en distribuciones de Linux más antiguas) y Clover a través de controladores RADEON, ambos están por debajo de la media.
Olvídate también de las tarjetas pre-GCN. Los probé usando OpenCL en Windows para Caffe, el rendimiento no vale la pena hacer un esfuerzo para tarjetas tan antiguas. Como todas las tarjetas AMD posteriores a 2012 deberían ser GCN de todos modos.

@naibaf7 Pasé algunas horas ayer tratando de hacer funcionar la pila de código abierto de AMD. Obtuve MIOpen y sus dependencias, pero a hcc todavía le faltan algunos bits. Es posible que deba hacer una compilación de kernel personalizada para obtener todo. No me importa mucho migrar el código CUDA o ejecutar C ++ compilado en la GPU; quiero hacer cálculos numéricos en él. ;-)

También vi algo en su sitio web sobre cómo programarlo en ensamblador, que podría interesarme, porque es fácil pasar de ensamblador a FORTH. ;-)

@znmeb Sí, también estoy tratando de hacer que algunas cosas de MIOpen y TensorFlow funcionen en mi RX 480, pero no quiero destruir mi plataforma de desarrollo principal, así que en su lugar uso la virtualización IOMMU y uso una máquina virtual Ubuntu 16.04 que puede usar el RX 480. Los controladores AMD son muy amigables con la virtualización (a diferencia de los controladores nVidia creados para las tarjetas de juego, solo los controladores Quadro lo hacen).

@znmeb Todo lo que tienes que hacer es sudo apt-get install rocm miopen-hip

@adityaatluri Está en el repositorio de usuarios de Arch pero no se instala, tampoco se instala desde la fuente de GitHub. Parece algo simple: no puede encontrar algunas dependencias.

@znmeb ¿Puede crear un problema aquí (https://github.com/RadeonOpenCompute/ROCm/issues) para que podamos discutirlo allí? ¡Gracias!

@adityaatluri Seguro - Me dirijo a cenar pero lo archivaré cuando regrese

@ebrevdo ¿ Alguna forma de usar GPU tensorflow en Mac con procesador AMD?

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

Mi empresa ha estado trabajando en el aprendizaje profundo de OpenCL durante un tiempo y tenemos algunos resultados preliminares para mostrar. Nos estamos enfocando en Keras a corto plazo, sin embargo, también hemos creado un soporte TensorFlow (muy) experimental y lo revisaremos después de nuestro lanzamiento inicial. Más detalles aquí, incluidos los números de rendimiento inicial en AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl

¡Frio!

Pequeño detalle: AFAIK, MIOpen no es específico de AMD, ya que puede vincularse a OpenCL y a ROCm. Este último es probablemente más rápido, pero aún así; MIOpen es un gran paso adelante para el truco de "Redes neuronales de código abierto en GPU", y AMD merece una gran credibilidad si funciona bien en OpenCL.

14 de agosto de 2017 5:19 p. m., "Choong Ng" escribió:
Mi empresa ha estado trabajando en el aprendizaje profundo de OpenCL durante un tiempo y tenemos algunos resultados preliminares para mostrar. Nos estamos enfocando en Keras a corto plazo, sin embargo, también hemos creado un soporte TensorFlow (muy) experimental y lo revisaremos después de nuestro lanzamiento inicial. Más detalles aquí, incluidas las cifras de rendimiento inicial en AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

—

Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416) o silencie el hilo (https://github.com/notifications/unsubscribe-auth /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Gracias por la corrección, basé mi comentario en los requisitos del sistema en la documentación de MIOpen (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#prerequisites) pero feliz de actualizar si hay un mejor enlace.

Espera, he estado leyendo este hilo/problema durante 10 minutos. Llegué a la mitad y me salté el resto. ¿Ya son compatibles las GPU de AMD?

Usando una cosa de código cerrado meticuloso que solo funciona en una combinación muy antigua de Kernel/OS (codeplay): sí

Usando una versión antigua de tensorflow y sin soporte para algunas no linealidades todavía (tf-coriander): sí.

Realmente: no oficialmente. Aunque AMD está migrando a HIP, espero un progreso dentro de 3 meses más o menos. Otros marcos ya funcionan bien debido a sus esfuerzos.

El 18 de agosto de 2017 a las 02:09:55 GMT+01:00, abrad1212 [email protected] escribió:

Espera, he estado leyendo este hilo/problema durante 10 minutos. llegué a la mitad
y me salté el resto. ¿Ya son compatibles las GPU de AMD?

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-323233294

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

FWIW Creo que las versiones recientes de PyGpu pueden usar CUDA u OpenCL. Tengo todo el software instalado en mi caja Arch pero aún no lo he probado.

@ abrad1212 sí, este problema existe desde hace un tiempo. El esfuerzo es enorme y mucha gente está tratando de "hacer que funcione", como mencionó @cathalgarvey .

Un poco de una actualización de nuestro lado. Debería poder usar ComputeCpp 0.3.0 en la pila de controladores AMDGPU-pro para Ubuntu 16.04. Las instrucciones se pueden encontrar aquí: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 -04-lts/

Además, ahora nos estamos enfocando en mejoras de rendimiento para diferentes modelos; hay mucho por hacer, pero lo estamos consiguiendo.

@lukeiwanski ¿Cuál es su enfoque para la evaluación comparativa? Programamos los modelos incluidos con Keras y los normalizamos contra TF+cuDNN+K80 porque es una configuración común y bien optimizada. Nuestra metodología es similar a la de Max Woolf (http://minimaxir.com/2017/06/keras-cntk/), no es mucho código, pero estaremos encantados de compartirlo. Tenemos algunos números de rendimiento en nuestro sitio web (http://vertex.ai), nuestro código es ligeramente más rápido que TF 1.2 en la inferencia de Xception y sería interesante comparar más enfoques uno al lado del otro.

¿Hay alguna solución de Windows? Instalaría Ubuntu en mi PC pero actualmente no tengo suficiente espacio para hacerlo.

Ubuntu 14.04
rama maestra de tensorflow
compilar compatibilidad con opencl y solo se instaló opencl intel cpu runtime.
pitón2.7
siga la guía https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
ejecutar python classify_image.py
parece que no llamó al controlador opencl. (Agregué mi envoltorio opencl icd, no vi nada)
¿Hay alguna configuración que deba agregarse en el código python?
Como sess.graph.device('/cpu0')

Pero si uso la guía Eigen skcl, puede ejecutarse en la CPU con soporte OpenCL. (Además, este código de guía está un poco desactualizado, necesita algunas modificaciones)
https://developer.codeplay.com/computecppce/latest/getting-started-with-eigen

Cualquier persona puede ayudar a verificar cómo la interfaz de Python de tensorflow también se puede ejecutar con soporte para OpenCL.

Y construir tensorflow con este conjunto de opciones realmente no generará tensorflow binario. --config=sycl
Simplemente construye tensorflow en este comando:
bazel build -c opt /tensorflow/tools/pip_paquete :build_pip_paquete

Tal vez construyo olvidar --config=sycl
Intentaré construir el comando y verificaré si puede llamar a la biblioteca OpenCL. Después de obtener el resultado, lo publicaré aquí.
bazel build -c opt tensorflow/tools/pip_paquete :build_pip_paquete

@ joe8086 Si modifica la creación de tf.Session con lo siguiente, se mostrará un registro en la terminal, ¿esto menciona SYCL en alguna parte?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Para la guía Eigen, ¿tiene algún comentario específico donde esté desactualizado?

@rodburns Gracias.
Mi error es construir la opción de configuración miss tensorflow --config=sycl
Después de agregar esta opción con este código de rama https://github.com/lukeiwanski/tensorflow.git
Puedo ver que tensorflow se ejecuta con el backend de OpenCL.

Para la guía Eigen, el error principal está en:
1, no proporciona el archivo de inclusión correcto.
2, para matriz, Tensor, TensorMap no proporciona el parámetro de plantilla correcto.
3, para static_cast no dar tipo de datos.

agregue más información que tal vez le brinde ayuda a este tema de discusión.
1, Main tensorflow no puede construir tensorflow con --config=sycl correcto.
2, con CPU OpenCL, la velocidad es aproximadamente 4x~8x veces mayor que la implementación normal de CPU en mi entorno.

hora python classify_image.py
2017-09-07 16:56:29.076054: I tensorflow/core/platform/cpu_feature_guard.cc:137] Su CPU admite instrucciones que este binario de TensorFlow no se compiló para usar: SSE4.1 SSE4.2 AVX
2017-09-07 16:56:29.077967: W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] No se encontró GPU OpenCL compatible con ComputeCpp, probando CPU OpenCL
2017-09-07 16:56:29.159775: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Se encontraron los siguientes dispositivos OpenCL:
2017-09-07 16:56:29.159825: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id: 0, tipo: CPU, nombre: Intel(R) Core(TM) i7-6700HQ CPU a 2,60 GHz, proveedor: Intel(R) Corporation, perfil: FULL_PROFILE
2017-09-07 16:56:30.213375: W ./tensorflow/core/framework/op_def_util.cc:333] Op BatchNormWithGlobalNormalization está en desuso. Dejará de funcionar en GraphDef versión 9. Utilice tf.nn.batch_normalization().
panda gigante, panda, oso panda, oso mapache, Ailuropoda melanoleuca (puntuación = 0,89107)
indri, indris, Indri indri, Indri brevicaudatus (puntuación = 0,00779)
panda menor, panda rojo, panda, oso gato, oso gato, Ailurus fulgens (puntuación = 0,00296)
chirimoya (puntuación = 0,00147)
estrella terrestre (puntuación = 0,00117)

1m44.473s reales
usuario 2m8.980s
sistema 1m20.024s

Chicos, no voy a leer este hilo completo, pero si alguien pudiera responder a mi pregunta, ¡sería genial! ¿Ya puedo usar Tensorflow con una GPU AMD? Si es así en qué sistema operativo, y puedo hacerlo con RX Vega? ¡Gracias!

@ M3L0NM4N Hmmm ... No he estado siguiendo el hilo, pero parece que ahora hay un código OpenCL comprobable, al menos en CPU OpenCL. Tengo una GPU AMD más antigua ("Bonaire") y tengo OpenCL ejecutándose tanto en la GPU como en la CPU, así que puedo probar esto. Podría intentarlo durante el fin de semana; Realmente quiero OpenCL TensorFlow en mi GPU.

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

¿Algún soporte de tensorflow 1.3 gpu/opencl disponible en macos?

Últimas noticias: Compilé con éxito TensorFlow 1.3.1 con OpenCL desde la fuente de GitHub. Faltan bastantes piezas en la documentación, y aún no he intentado ejecutar nada en la GPU, pero al menos funciona para CPU que no son OpenCL. Por cierto, no tengo CPU OpenCL instalada, solo GPU OpenCL.

¿Alguien tiene algún caso de prueba para TensorFlow con una GPU OpenCL? Eventualmente tendré que construir uno para mí, pero esperaba una revisión rápida.

@znmeb Sí, hay una aplicación de prueba en cuestión que informé. https://github.com/hughperkins/tf-coriander/issues/64

¿Podrías decirme si funciona en tu caso?

@unoexperto Sí, funciona (no falla) pero no hay indicios de si encontró OpenCL o no.

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

Creo que el mejor curso de acción aquí es presentar un problema por separado para solicitar documentación, ya que está claro (cuando ejecuta ./configure construyendo desde la fuente) que hay un código para OpenCL. Así es como lo encontré, de todos modos.

@znmeb Dudo que haya encontrado el dispositivo GPU en su caso porque en el mío imprimió información de depuración al principio sobre la selección del dispositivo GPU. Tal vez pueda volver a compilar con printf agregados a la consola en algún lugar en tensorflow/core/common_runtime/gpu/gpu_device.cc .

@unoexperto Me uní a la discusión del Grupo de Google y publiqué una solicitud de documentación. Voy a esperar a ver si alguien responde antes de poner más esfuerzo en esto.

@znmeb ¿Qué instrucciones estás siguiendo? ¿Has ejecutado clinfo? ¿Has ejecutado computecpp_info? ¿Eso indica que sus controladores OpenCL están instalados como se esperaba? Las instrucciones para Ubuntu 14.04 están aquí https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow y si está usando 16.04 hay algunas instrucciones experimentales aquí http://deep-beta.co. es/tensorflow-1-3-en-ubuntu-16-04-lts/

@rodburns clinfo y clpeak se ejecutan. No he hecho esto recientemente, pero cuando construyo café desde la fuente y ejecuto las pruebas, definitivamente golpea la GPU. Así que estoy bastante seguro de que los controladores / bibliotecas OpenCL / GPU están funcionando.

Estoy en Arch Linux - kernel es su LTS - linux-lts 4.9.52-1. Si importa, el "Bonaire" alcanza un máximo de 1,7 TFLOPS en modo de 32 bits y pertenece a la familia de GPU 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

¿Alguien recopila registros de prueba? Dice que mi dispositivo no está probado, así que lo probaré. ;-)

¡Me es imposible construir TensorFlow para Sycl/OpenCL!

Configuración:
Ubuntu 16.04
Tensorflow r1.3
OpenCL 2.0
ComputeCpp CE 0.3.2 (computecpp_info OK)
Gráficos Intel HD 620
bazel 0.5.4

Instrucciones de instalación (compilación 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 :

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

El entrenamiento de modelos en mi CPU lleva mucho tiempo, realmente necesito aceleración OpenCL/GPU...

@ErwanGalline Estamos en proceso de actualizar los cambios a Eigen (https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None) que solucione el problema que está viendo.

También nos estamos preparando para mejorar el rendimiento de Eigen en sentido ascendente; esto es un poco complicado y necesita coordinación con @benoitsteiner para evitar la corriente de conflictos de fusión, pero estamos llegando allí.

Para los usuarios de AMD, sugeriría probar mi bifurcación: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu
Las instrucciones de configuración para Ubuntu 16.04 se pueden encontrar aquí: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Todos los cambios se realizarán aguas arriba de tensorflow después de que se hayan implementado los cambios de Eigen mencionados anteriormente.

Espero que ayude.

@lukeiwanski ¿Su bifurcación solo admite GPU AMD R9 Nano / AMD FirePro?

@lukeiwanski ¿Hay algún caso de prueba que pueda usar para verificar que estoy usando la GPU? Puedo monitorearlo con radeontop pero me gustaría algo que use TensorFlow.

@ZixuanLiang no, no solo...
Actualmente probamos en AMD (R9 380, R9 Nano, FirePro). Sabemos que la GPU Intel expone algunos errores de controlador, pero se avecinan correcciones. Y hemos anunciado Renesas R-Car y esperamos que sigan más.

Creo que Xilinx está transmitiendo soporte para triSYCL https://github.com/tensorflow/tensorflow/pull/12882 - entonces FPG (?) - @keryell debería saber más sobre eso

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test debería ser una verificación justa... la salida debería verse así:
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 Gracias, lo probaré en GPU AMD

@lukeiwanski La compilación y la prueba parecen estar funcionando en mi Bonaire. Sin embargo, estoy usando Python 3.6 y las instrucciones usan Python 2.7. ¿Necesito usar 2.7 o funcionará 3.6?

@znmeb Siguiendo https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647 parece que Python 3.6 debería estar funcionando, aunque no lo he probado

@lukeiwanski ¿Es esa una versión ComputeCpp que puede construir TF en este momento?
Probé varias versiones entre 0.3.2 y 0.1.4 y ninguna funcionó. Todos terminaron con el error "múltiples sobrecargas de instancias 'global_ptr' en la misma firma".
Por cierto, no puedo encontrar el archivo TensorDeviceSycl.h en las fuentes de TF, ¿tiene un nombre nuevo? ¿Es posible aplicar el parche a las fuentes actuales?

Gracias por adelantado.

@eLvErDe ComputeCpp 0.3.2 puede compilar: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu

A Upstream le falta un parche para Eigen que lo soluciona. Consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564

¿Alguna idea de cómo inyectar este parche Eigen durante la compilación de bazel? ¿Tal vez deberíamos buscar en algún lugar la versión Eigen tgz para obtener la versión reparada?

Gracias, Adán.

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

¿Este compromiso sería suficiente para construirlo?

sí, deberías poder elegir eso

Bueno, lamentablemente, eso claramente no es suficiente, estas son algunas de las próximas fallas de compilación:

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 hay algunas confirmaciones que debe aplicar para que se compile.
Sugeriría usar la punta de dev/amd_gpu o si no desea cambiar su rama actual... puede fusionar dev/amd_gpu con ella.

En realidad, estoy trabajando en mi paquete no oficial de Debian/Ubuntu, así que trato de mantenerme cerca de la versión oficial 1.3.1. Puedo vivir sin el soporte de OpenCL, pero debo estar listo para habilitarlo tan pronto como sea compatible correctamente. Tal vez actualice los paquetes en su sucursal con fines de prueba, pero eso es suficiente por hoy;)

Tengo alrededor de diez variedades diferentes de GPU AMD en mis equipos de minería. (de 7970 a RX 480 con ubuntu 16.04 y amdgpu-pro). Avíseme si puedo contribuir probando algo.

Avíseme si puedo contribuir probando algo.
¿Qué tal https://github.com/ROCmSoftwarePlatform/hipCaffe?
https://github.com/ROCmSoftwarePlatform/hipeigen

El martes 17 de octubre de 2017 a las 10:54 a. m., slundell [email protected] escribió:

Tengo alrededor de diez variedades diferentes de GPU AMD en mis equipos de minería. (desde
7970 a RX 480 con ubuntu 16.04 y amdgpu-pro). Avísame si puedo
contribuir probando cualquier cosa.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski ¿Su bifurcación también admitirá GPU AMD en macOS?

Hola,
Estaba creando API de tensorflow en Ubuntu16.04 x64 para mi dispositivo Android con GPU (Mali-T720) habilitada,

Información de mi sistema operativo:
Ubuntu 16.04 x64
GPU de la computadora: NVIDIA 1080Ti
CUDA 8.0
CUDNN 5.1 (aunque no uso cuda o cudnn para construir)
bazel 0.5.2
Calcular Cpp CE 0.3.2

mi build.sh es:
'
bazel build -c opt --config=sycl //tensorflow/contrib/android:libtensorflow_cc.so --cxxopt="-
std=c++11" --cxxopt="-DTENSORFLOW_DISABLE_META" --verbose_failures --
crosstool_top=//externo:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --
cpu=armabi-v7a
'
antes de construir Exporto LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, compilar sin ' --config=sycl ' está bien y obtuve el libtensorflow_cc.so correcto, pero con ' --config=sycl ', el resultado final resultó faltar -lComputeCpp sin ningún otro compilar errores

Registro completo como este:

ERROR: /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1: Falló la vinculación de la regla '//tensorflow/contrib/android:libtensorflow.so': falló link_dynamic_library.sh: error al ejecutar el comando
(cd /home/e0024/.cache/bazel/_bazel_e0024/783dad02ec856015f56356584726dd10/execroot/org_tensorflow && \
entorno ejecutivo - \
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: \
RUTA=/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/espacio de trabajo/bazel/salida:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ juegos:/usr/local/juegos:/snap/bin \
PWD=/proc/self/cwd \
PYTHON_BIN_PATH=/home/e0024/espacio de trabajo/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 no ignorado ignorado ignorado external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/preconstruido/linux-x86_64/bin/arm-linux-androideabi-gcc -shared -o bazel-out/arm-linux-androidabi-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 de salida / brazo-linux-androideabi-4,9-v7a-gnu-libstdcpp-opt / bin / _solib_armeabi-v7a / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib -Wl, -whole-archivo bazel de salida / brazo -linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/c/libc_api.a -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi- 4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androidabi-4.9-v7a-gnu -libstdcpp-opt/bin/tensorflow/core/kernels/libandr oid_tensorflow_kernels.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib_lite.lo -Wl ,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libprotos_all_cc.a -Wl,-no-whole -archivo -Wl,-archivo completo bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf.a -Wl,-no-archivo completo -Wl, -archivo completo bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf_lite.a -Wl,-no-archivo completo -lComputeCpp external/androidndk/ndk/ fuentes/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a externo/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 - prefijos no canónicos '-march=armv7-a' -Wl,--fix-cortex-a8 '--sysroot=external/androidndk/ndk/platforms/android-14/arch-arm'): com.google.devtools.build.lib.shell.BadExitStatusException: Proceso finalizado con estado 1.
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/preconstruido/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld: advertencia: omisión de bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/_solib_armeabi-v7a/_U@local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib/libComputeCpp.so incompatibles para ComputeCpp
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/preconstruido/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androidabi/bin/ld: error: no se puede encontrar -lComputeCpp
collect2: error: ld devolvió 1 estado de salida
Target //tensorflow/contrib/android:libtensorflow.so no se pudo compilar
INFO: Tiempo transcurrido: 617,736 s, ruta crítica: 54,66 s

uhm.... Quiero construir API de tensorflow en el arco del brazo con GPU (Mali-T720) habilitada,
Agradecería si alguien pudiera dejar algunas experiencias o sugerencias aquí. Muchas gracias.

¡Ven a mi charla la próxima semana en Arm TechCon, @laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Necesitará controladores Mali compatibles con SPIR-V, que probablemente todavía no estén fácilmente disponibles. Y necesitará un tiempo de ejecución de ComputeCpp para Android compatible con Arm CPU y SPIR-V, que tampoco está disponible (todavía). Entonces, tendrás que ser un poco paciente.

Nosotros (Vertex.AI) acabamos de abrir PlaidML, nuestra pila de aprendizaje profundo con soporte para ejecutar Keras en OpenCL. El soporte de TensorFlow está llegando, la ayuda sería bienvenida. Y sí, el soporte para Mac está en camino (también para Windows). http://vertex.ai/blog/annunciando-plaidml @ggaabe

@choongng Quería intentarlo pero fallé.
pip search plaidml devoluciones

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Pero pip install plaidml o pip install plaidml==0.1.0rc3
devoluciones

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

@ hy9be Creo que sería más apropiado crear un problema en el repositorio plaidml en lugar de aquí, ya que este problema se trata de admitir OpenCL en tensorflow. Además, al mirar las instrucciones de instalación, su comando de instalación de pip puede ser incorrecto.

Gracias @andrewrichards por tu atención y tu discurso de sesión.

Pero por ahora, para mí (un estudiante de posgrado), para crear una aplicación usando Tensorflow en un dispositivo Android y quiero que GPU (Mali-T720) esté activada, ¿qué se requiere para obtener el controlador Mali con soporte SPIP-V y el tiempo de ejecución ComputeCpp para Android con Arm CPU? soporte y soporte SPIR-V.

Desde que descargué ComputeCpp (Ubuntu16.04 x64 con bin/ doc/ include/ lib/) en la página de inicio de CodePlay, ayer ejecuté:
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
los errores decían libComputeCpp.so incompatible , por lo que considero que tal vez necesito ComputeCpp para Android con compatibilidad con Arm CPU y SPIR-V, pero no pude encontrar ningún código fuente para compilar una ComputeCpp de Android, solo hay ejemplos en github.

Y ha dicho que ComputeCpp para Android ahora no está disponible, entonces, ¿hay algún plan para admitir dispositivos Android o cómo puedo obtenerlo si es compatible?

Para los usuarios de GPU y Linux de AMD, AMD lanzó recientemente el puerto HIP de tensorflow aquí . Tú podrías estar interesado.

Aunque no lo he probado.

Puedo probarlo, estad atentos. Sin embargo, parece que está fallando CI.

Efectivamente está fallando. Todavía en una etapa temprana, supongo.

Lo probé, obtuve una falla de segmento en el ejemplo MNIST inmediatamente.
No sé qué estoy haciendo mal aquí.

$ 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 : asegúrese de tener instalada la base rocm 1.6.4.

@bensander Gracias, actualizaré.

@bensander ¿ Algo más que necesite de la pila de AMD? Todo lo que tengo ahora es la biblioteca opencl propiedad de AMD que utiliza el controlador de código abierto "amdgpu".

@masahi : si instala rocm y rocm-libs (es decir, "apt-get install rocm rocm-libs"), eso debería ser todo lo que necesita. El rocm_docs en el informe tiene instrucciones completas que incluyen los resultados esperados.

@bensander , ¿cómo sé si estoy ejecutando rocm 1.6.4 correctamente (y no 1.6.3)?

@masahi solo una suposición: debe hacer la pregunta en un lugar más relacionado con su problema, como el proyecto AMD o RoCM en lugar de aquí ...

@keryell cierto, me estoy saliendo del tema. Me detengo aquí.
De todos modos, no pude hacer funcionar hiptensorflow en mi sistema. Lo intentaré más tarde con una instalación limpia de Ubuntu.

@masahi : simplemente abra un problema allí y lo configuraremos.

Hola, solo quiero mencionar que pude hacer funcionar hiptensorflow, gracias a @bensander y otras personas en AMD. Puedo ejecutar todos los ejemplos en su guía de inicio rápido.

Gracias

Para aquellos que quieran probar TensorFlow en hardware AMD usando ROCm, escribí un blog que describe cómo ejecutar portátiles Fast.ai usando AMD Fury Nano.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 no puedo esperar por esto!

¡ROCm 1.7 está en camino, con lo que parece ser el soporte adecuado de Tensorflow!

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

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

Funciona muy bien para mí. Mi configuración de hardware:
GPU: AMD Radeon RX 480
CPU: Intel Xeon 2603 v3
MB: supermicro x10srl-f

La clave es la placa base y la CPU deben ser compatibles con PCIe v3

Su rendimiento es similar a Nvidia 980Ti

Ni siquiera puedo hacer que los controladores AMD "compatibles" funcionen en mi instalación Ubuntu 16.04 LTS "compatible". ¿Obsolescencia programada?

znmeb, ¿cuál es su GPU AMD? Si tiene dos GPU, deshabilite la que no es compatible desde el BIOS.

No pude leer todo el hilo... ¿cuál es el estado actual de tensorflow en OpenCL en MacOS (sierra +)? Específicamente, tengo una GPU Intell Iris y esperaba poder construir desde la fuente soporte Tf+Open CL para ella.
Además, tf corrainder parece funcionar bien, en la versión 1.2.

@varun19299 FWIW hay un Intel SDK para OpenCL: lo tengo en mi antigua computadora portátil Sandy Bridge, pero estoy seguro de que funcionará en su máquina. https://software.intel.com/en-us/intel-opencl

¿Está esto actualmente en un estado utilizable en sistemas Linux que no son ubuntu? La página de la hoja de ruta simplemente enlaza aquí.

@pfc ¿Se puede usar actualmente lo que no es Ubuntu Linux? ¿TensorFlow usando OpenCL en general? ¿O TensorFlow usando OpenCL en una GPU AMD? Asumiré lo último, ya que es la única razón por la que querrías ejecutar TensorFlow usando OpenCL. Para una GPU NVidia, usaría los controladores/bibliotecas de NVidia y solo para la CPU no hay nada que ganar con OpenCL.

Tuve esto funcionando hace unas semanas en Arch Linux, usando la biblioteca patentada ComputeCpp SYCL y una GPU AMD "Bonaire" (arquitectura Sea Islands). Hay una nueva versión de ComputeCpp que necesito probar, pero supongo que funcionará.

Resulta que las bibliotecas propietarias de AMDGPU Pro que necesita para que esto funcione no se ejecutan en Ubuntu 16.04.3. La actualización de 16.04.2 trajo un kernel de Linux y un servidor X más nuevos, y AMD aún tiene que enviar algo que funcione en él. Consulte http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-Compatibility-Advisory-with-Ubuntu-16.04.2-and-16.04.3.aspx para obtener más detalles. No he podido hacer que AMD OpenCL funcione en Ubuntu.

Hay una versión AMD experimental de TensorFlow que usa un compilador para traducir el código CUDA al código OpenCL, pero tampoco lo he probado. En ausencia de un controlador compatible, es inútil.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs es la forma oficial de ejecutar Tensor Flow en hardware AMD.

@bensander ¿Funciona el tiempo de ejecución de ROCm en Ubuntu 16.04.3? No he podido hacerlo funcionar.

PD: ¿Tiene alguna idea de si / cuándo la configuración de AMDGPU-Pro funcionará en Ubuntu 16.04.3? Lo necesito para otro proyecto.

Hmm, no me divierto (y no lo haría) con Ubuntu en ninguna parte, pero tengo un CentOS 7 con repositorios y una GTX1080TI, ejecutando kernel 4.14.x y el último controlador beta de Nvidia, así que podría ayudar a probarlo. allí en algún momento hoy si ayuda?

--
Sam McLeod

El 7 de diciembre de 2017, a las 07:28, M. Edward (Ed) Borasky [email protected] escribió:

@bensander ¿Funciona el tiempo de ejecución de ROCm en Ubuntu 16.04.3? No he podido hacerlo funcionar.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@sammcj ¿Por qué ejecutaría una GPU NVidia con OpenCL cuando existen bibliotecas CUDA perfectamente buenas para ella?

¡Solo para ayudar a probarlo por ti!

No se preocupe si no necesita una prueba manual, solo pensé en ofrecer. Ni siquiera he probado esa máquina con cuda TBH, solo la he probado en MacOS donde no puedo usar OpenCL a través de Docker en este momento.

--
Sam McLeod

El 7 de diciembre de 2017, a las 08:16, M. Edward (Ed) Borasky [email protected] escribió:

@sammcj ¿Por qué ejecutaría una GPU NVidia con OpenCL cuando existen bibliotecas CUDA perfectamente buenas para ella?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@znmeb Iba a probar ComputeCpp SYCL, sin embargo, solo proporcionan el instalador de ubuntu (también estoy en arch) y el script de instalación de aur está roto. Es bueno saber que puede funcionar. Si me desespero lo suficiente, puedo probarlo.
@bensander Eso parece exactamente lo que necesito para obtener soporte de ADM, sin embargo, me preocupa el hecho de que este código no se haya transferido a TF y que su código se actualizó por última vez hace más de 2 meses dado que mi código apunta a TF 1.4. 0
Parece que, en este momento, tensorflow básicamente lo vincula a Nvidia, al menos para nosotros, los programadores "mortales". La falta de documentación/hoja de ruta actualizada no ayuda. No me importaría ayudar de cualquier manera que pueda, sin embargo, hasta ahora he tenido poco éxito en hacer que las cosas funcionen.

@pfc Obtuve ComputeCpp SYCL trabajando en Arch: había un tarball binario en su sitio web cuando lo hice.

En esta noticia sobre el lanzamiento de SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
dice :
_La nueva especificación incorpora experiencia significativa obtenida de tres implementaciones separadas y comentarios de desarrolladores de marcos de aprendizaje automático como TensorFlow, que ahora es compatible con SYCL junto con el back-end del acelerador CUDA original._

¿Eso significa que ahora es posible ejecutar "fácilmente" TensorFlow en GPU AMD que admita OpenCL 1.2 en el que se basa SYCL?

"Fácilmente" en el sentido de que algunos software/controladores/bibliotecas de bajo nivel para el hardware AMD están donde está la mayoría de las cosas rotas, no en el hardware o TensorFlow o los estándares OpenCL o SYCL. ;-) Si tiene controladores de GPU AMD en funcionamiento y bibliotecas OpenCL en funcionamiento, tiene TensorFlow en GPU AMD.

Mi configuración de trabajo para AMD Bonaire (arquitectura Sea Islands):

Arch Linux con el módulo kernel amdgpu cargado y el módulo kernel radeon en la lista negra
El paquete Arch User Repository opencl-amd
La biblioteca ComputeCpp
TensorFlow creado a partir de la fuente en mi estación de trabajo usando la bifurcación de @lukeiwanski :

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

Estoy un poco sorprendido por lo que dijo: "Si tiene controladores de GPU AMD en funcionamiento y bibliotecas OpenCL en funcionamiento, tiene TensorFlow en GPU AMD". Entendí que la versión "oficial" de TensorFlow no se estaba ejecutando en OpenCL (solo CUDA). Parece que me confundí.
Me alegró mucho encontrar el proyecto PlaidML que al menos permite que se ejecute algún código Keras en mi iMac con AMD Redeon HD 6970. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) AFAIK, también has probado ese Framework.
Intentaré ejecutar TensorFlow en Ubuntu VirtualBox donde Tensorflow ya se está ejecutando (solo CPU).

@PALYGAP No creo que VirtualBox exporte OpenCL desde un host Mac a un invitado Linux, y Ubuntu 16.04.3 no funciona en este momento. No tengo una Mac, así que no tengo ninguna forma de probar las cosas.

¿Alguien probó con éxito el funcionamiento de TensorFlow en AMD a través de OpenCL y tuvo éxito?

@mohnkhan Tengo la bifurcación @lukeiwanski funcionando (Arch Linux): consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . Estoy esperando un poco más de trabajo con AMDGPU-Pro antes de publicar una publicación en el blog; consulte https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Gracias por los aportes

@mohnkhan Por cierto, AMD está construyendo una ruta alternativa que es completamente de código abierto: traducir el código CUDA al código OpenCL con una cadena de herramientas de compilación. Sin embargo, no estoy seguro de cuál es el estado de eso para las tarjetas más antiguas como la mía.

Si va a escribir un artículo, supongo que no estaría de más explicar también (tomó 3 horas obtener una imagen completa):

• TF tiene, de hecho, un backend SYCL 1.2. No *real* opencl.
• a su vez, tiene dos implementaciones del estándar (trisycl se ve bien, pero es un cajero automático limitado )
• Al final, ComputeCpp 'engancha' SPIR /SPIR-V (además de PTX, pero esto es realmente otra historia )

Y esto es lo que finalmente te lleva directamente a tu anhelado OpenCL 1.2 (con cl_khr_spir ext)

En cambio, HIP es otro backend, se encuentra frente a SYCL y se dirige solo y exclusivamente a ROCm (o bueno, jajaja, incluso a su vez cuda si tiene una GPU nvidia ... pero esta es otra historia)

AMD está construyendo una ruta alternativa que es completamente de código abierto: traducir el código CUDA al código OpenCL con una cadena de herramientas de compilación.

No. Estás hablando de HIP, y... eso es en realidad, en lo que eventualmente conviertes tu código. Que no es OpenCL.
HIP luego se ejecuta en ROCm como estaba diciendo ...
ROCm, que también ejecuta OpenCL para usted (en tarjetas compatibles ), pero les pido a todos que se den cuenta de que las relaciones solo se transmiten desde ROCm, nunca "intra-sub-capas"

Lo que quizás estés pensando podría ser el cilantro .

Sin embargo, no estoy seguro de cuál es el estado de eso para las tarjetas más antiguas como la mía.

Resumido aquí : controlador completo AMDGPU-PRO, amdgpu-pro-opencl-only como lo está haciendo ahora ... O continuar esperando hasta el final de la década para que alguien finalmente haga que Clover sea utilizable.

Además, fglrx... Pero si eso es difícil de recomendar para cartas anteriores a gcn, supongo que es mejor cubrirlo con un velo.

@mirh

1. No me preocupan las tarjetas anteriores a GCN. El mío es un Sea Islands y no planeo adquirir nada más antiguo. Por otra parte, tampoco planeo adquirir otra GPU AMD. ;-)
2. No sé si ROCm se ejecutará en mi estación de trabajo; no hay un probador de hardware de código abierto que pueda darme una respuesta de sí o no. He abierto un tema para eso y no he recibido respuesta.
3. SPIR-V es un objetivo de compilador: lo miré y levanté las manos, no tenía presupuesto para contratar a un escritor de compilador.

Así que eso deja SYCL... o levantando mis otras dos manos y haciendo todo con Keras, que tiene back-ends de TensorFlow, Theano (que se está congelando), CNTK o PlaidML. Desde un punto de vista puramente económico de la ingeniería, Keras / PlaidML es un gran ganador siempre que obtenga TensorBoard de alguna manera.

@mirh gracias por el buen resumen con todos los enlaces. Creo que no has desperdiciado tus 3 horas... :-)

No sé si ROCm se ejecutará en mi estación de trabajo; no hay un probador de hardware de código abierto que pueda darme una respuesta de sí o no. He abierto un tema para eso y no he recibido respuesta.

Como te dije varias veces , no, no funcionará.
Pre GCN 3rd gen gpus simplemente carece del hardware para que ROCm funcione o incluso funcione.

SPIR(-V).. No estoy seguro de lo que estás hablando. No es tu trabajo preocuparte por eso. Computecpp lo hace a partir de "comandos" SYCL, y luego todo es negocio de controladores (opencl).

Tiene lo que tentativamente llamo amdgpu-pro-opencl-only, y no estoy seguro de cuál es el problema entonces.
EDITAR: también sería genial tener algún tipo de ETA para que el código de Luke aterrice

@znmeb y todos

Tengo (L)Ubuntu 17.10 incluido. kernel 4.14.x y las partes de la biblioteca OpenCL del controlador AMDGPU Pro 17.40 en ejecución y pueden ejecutar aplicaciones OpenCL como clinfo o Boinc (por ejemplo, Engima @Home , Milkyway@Home) sin problemas en mi APU AMD A12-9800E.

También puedo compilar y usar con éxito la versión de CPU de tensorflow (actualmente versión 1.4.1). Pero no puedo compilar con éxito la versión OpenCL de tensorflow. Uso computecpp 0.5 (el actual que puedo descargar sin necesidad de registrarme) junto con vanilla tensorflow 1.4.1 y con la rama "dev/amd_gpu" del fork de @lukeiwanski .

Entonces, ¿podría complacer a alguien que compiló con éxito la versión OpenCL de tensorflow proporcionar información sobre qué versión de la biblioteca de computación y qué rama de qué tensorflow git está usando?

Gracias

@AlphasCodes No tengo nada ejecutándose en Ubuntu; todo lo que funciona está en Arch. Tengo la máquina con arranque dual con Ubuntu 16.04.3, pero las bibliotecas propietarias de AMD aún no funcionan allí. Por lo que sé, no son compatibles con 17.10, pero si tiene la pieza de OpenCL funcionando en 17.10, podría agregar un tercer arranque: tengo mucho espacio en disco. ;-)

¿Qué tipo de errores estás recibiendo? Si son errores de compilación, es posible que tenga una incompatibilidad con Bazel. Bazel avanza constantemente como TensorFlow y, a veces, uno se adelanta al otro.

¿Qué quieres decir con "no compatible"?

esto
En cuanto a ubuntu, solo se dice que 16.04.3 es compatible (al menos oficialmente entonces, considerando que incluso arch puede hacer que funcione después de un poco de magia de script)
EDITAR: el controlador AMDGPU-PRO 'completo' requiere kernel 4.9, ese fue probablemente el problema

Si a alguien le importa, el puerto de AMDGPU-Pro Driver 17.40 a Arch está en curso y está muy activo en GitHub en https://github.com/corngood/archlinux-amdgpu/pull/54 ,

Realmente deberíamos cerrar este problema, ya que, como señaló @mirh , TensorFlow usa SYCL, no OpenCL. ¿Quizás deberíamos abrir otro, "TensorFlow en tarjetas AMD"?

No, es totalmente legítimo.
Desea que tensorflow se ejecute eventualmente en dispositivos opencl, ese es el objetivo. Legítimo y fin.
Decir que en realidad estaba usando SYCL fue solo un detalle técnico que hice, porque todos estos acrónimos de tecnologías mágicamente aleatorias me estaban volviendo loco.
EDITAR: También me gustaría agradecer a todos los chicos de Codeplay por su trabajo atroz

Si desea algo diseñado específicamente para AMD, le recomiendo que consulte su hiptensorflow . Sin embargo, solo ROCm. Y por favor, dejemos atrás este argumento.

OK, no sé si tengo suficiente tiempo para hacer la compilación nuevamente y proporcionar los errores de compilación hasta el fin de semana. Pero agregué mi documentación existente a mi nuevo repositorio de github.

Consulte https://github.com/AlphasCodes/DeepLearning para obtener detalles (mi configuración de hardware/software + configuración de AMD OpenCL + configuración de Tensorflow).

@mirh para aclarar las "acrónimos de tecnologías mágicamente aleatorias [...] que [lo] vuelven loco":

En el ámbito del Grupo Khronos, OpenCL es la API de origen no único de bajo nivel y SYCL es el lenguaje integrado específico de dominio (DSeL) de C++ de origen único y alto nivel. Se espera que SYCL se construya sobre OpenCL, por lo que, por transitividad, cuando usa SYCL, a menudo usa OpenCL.

Dado que TensorFlow usa Eigen, que utiliza un enfoque de C++ de fuente única con CUDA de fuente única , cuando más tarde se transfirió a OpenCL, se eligió SYCL porque es la forma estándar de Khronos Group de tener C++ de fuente única .

Pero si piensas en CUDA, es aún más sutil.

Casi todo el mundo utiliza la versión de fuente única de alto nivel de CUDA, que en realidad se denomina "API de tiempo de ejecución de CUDA". Esto es de alguna manera similar a SYCL.
Pero en realidad hay una versión de CUDA de bajo nivel que no es de una sola fuente menos conocida que se llama "CUDA Driver API", similar a OpenCL, y utilizada, por ejemplo, por la propia implementación de "CUDA Runtime API".

Como es una especie de FAQ, aclaré un poco https://en.wikipedia.org/wiki/SYCL y https://en.wikipedia.org/wiki/CUDA

ComputeCpp, que es la implementación de SYCL que está utilizando con TensorFlow, aún no es compatible con Ubuntu 17.10. Debería apegarse a Ubuntu 16.04, que es el LTS actual. Las instrucciones y los requisitos previos están aquí https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow

Aparte, la compatibilidad con OpenCL para TensorFlow no significa solo la compatibilidad con dispositivos AMD. La integración SYCL también está habilitando otros dispositivos OpenCL. Como parte del trabajo que estamos realizando con TensorFlow, la compatibilidad con GPU ARM e Intel estará disponible cuando estén disponibles los controladores más recientes de estas empresas. También estamos trabajando para habilitar la compatibilidad con los procesadores aceleradores Renesas para la plataforma R-Car.

@rodburns ¡Gracias! Tengo esto funcionando en Arch Linux (kernel 4.14.4) con la biblioteca opencl-amd del Arch User Repository. La tarjeta es una Bonaire (GCN 2.0). Ejecutaré las pruebas en esa página para verificar que esté haciendo lo que debería.

GCN 2nd gen (también conocido como 1.1), si corresponde, 2.0 no existe.
(debería rebajarse a ser tan pedante)

¡ÉXITO!

Las últimas confirmaciones de rama "dev/amd_gpu" en la bifurcación @lukeiwanski solucionaron mi problema de compilación Tensorflow OpenCL. Supongo que fueron las confirmaciones relacionadas con SysCL 1.2.1.

Compilé con éxito una versión de Tensorflow OpenCL y puedo usarla. Consulte mis documentos de configuración de Tensorflow para obtener más detalles.

También agregué una página de puntos de referencia donde puede encontrar algunos puntos de referencia de mi configuración en diferentes configuraciones de Tensorflow (no optimizado para CPU, optimizado para CPU, OpenCL) en el futuro.

La versión 17.50 del controlador AMDGPU Pro también funciona para mí. Actualicé el documento de configuración de AMD OpenCL relacionado.

Gracias a todos los contribuyentes.

Hice algunos puntos de referencia y parece que la iGPU es más lenta que los 4 subprocesos de CPU disponibles, excepto el punto de referencia matmul_bench.py .

La inicialización de una ejecución de OpenCL Tensorflow también es mucho más lenta que una ejecución de OpenCL Tensorflow solo de CPU. Algo así como 5 segundos para CPU frente a 1-2 minutos para OpenCL.

¿Alguien puede confirmar tales resultados?

OK hice un poco más de solución de problemas.

• Usé el ejemplo de Tensorflow MNIST, consulte el documento Validar una configuración de Tensorflow
• Usé "sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info" para verificar/ver el reloj/carga de la iGPU y "top" para verificar la carga de la CPU
• la fase de inicialización hasta el paso 0 tomó alrededor de 6 minutos, la carga de iGPU fue de aproximadamente 0 %, el reloj de iGPU a 300 MHz (el reloj mínimo disponible) y el uso de CPU del proceso de Python fue de aproximadamente 200 % (= 2 subprocesos)
• comenzando con el paso 0, la carga de la iGPU fue de aproximadamente el 90 %, el reloj de la iGPU cambió siempre de 654 MHz - 720 MHz - 800 MHz - 900 MHz (reloj máximo disponible) y viceversa, el uso de la CPU del proceso de Python fue de aproximadamente el 100 % (= 1 CPU hilo)

Todavía estoy tratando de hacer que las cosas se compilen en Arch.

Lo que usé ayer .
Después de 14 horas (sí, mi papa es muy lenta) obtuve este binario , si quieres probar.

He intentado averiguar qué está pasando, pero desafortunadamente no pude. ¡Agradecería si alguien que sabe sobre lo siguiente puede ayudarme a ponerme al día!

La mayor parte de la discusión anterior se refería a hacer que Tensorflow se ejecutara con aceleración OpenCL en chips AMD. ¿Estoy en lo cierto al decir esto? Si quiero obtener un tensorflow acelerado por gpu usando mi tarjeta gráfica integrada (intel HD 5000) que admite opencl, ¿cuál debería ser mi enfoque?

¡Gracias por adelantado!

@znmeb Hola Ed, gracias por responder. He descargado y ejecutado OpenCL en mi sistema. Pero mi pregunta era: ¿cómo puedo compilar tensorflow para usar las bibliotecas de OpenCL?

https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
Y lo más importante para Intel https://github.com/codeplaysoftware/computecpp-sdk/issues/78#issuecomment -352411192

@AlphaCodes Gracias por publicar sus resultados. Con respecto al tiempo de inicialización, la forma en que funciona OpenCL es que el código se compila antes de la ejecución, por lo que el tiempo de inicio es el proceso de compilación.

@brainwave Para dispositivos Intel, hay un hilo con @mirh aquí que explica cómo eliminar las restricciones en torno a los dispositivos en ejecución. Hemos visto problemas con los controladores Intel, por lo que estos tipos de dispositivos están restringidos, pero esperamos que los controladores actualizados estén disponibles pronto para dispositivos Intel que mejoren el soporte. Mientras tanto, puede volver a compilar TensorFlow con el cambio para probar su propio hardware Intel. Estamos buscando eliminar las restricciones de dispositivos en el código base.

@AlphasCodes Chicos, me disculpo por la pregunta quizás ingenua, pero ¿por qué esta compilación de GPU AMD es solo? ¿No se supone que OpenCL es estándar? ¿Entiendo correctamente que no funcionará en mi Intel Carbon X1 con los controladores OpenCL 2.0 instalados?

Si lee el problema que se vinculó dos veces, verá que no hay nada sobre amd gpu.
Actualmente, Intel está excluido, pero no tiene nada que ver con querer forzar a los usuarios, y hay una solución temporal: discuta allí si realmente hay alguna.

Cuando uso la rama amd_gpu con un cuaderno jupyter, parece haber un hilo sobrante. python todavía usa el 100% de una CPU, incluso después de que finaliza el cálculo. Reiniciar el kernel finaliza el hilo perdido. ¿Alguien más experimenta esto?

@brainwave @unoexperto
Lo siento, no puedo ayudar con Intel OpenCL porque solo tengo hardware AMD OpenCL.

@desperadoduck
Todavía no uso jupyter. Utilizo un shell de bash simple y un entorno virtual de Python 3 ( consulte mi configuración de Python 3 + Tensorflow ). Pero no puedo reproducir el problema. No hay uso de CPU por parte de un proceso de python una vez que se ha completado el cálculo.

@rodburns
Gracias por la información. ¿Es posible acelerar el tiempo de compilación inicial? por ejemplo, usar todos los subprocesos de CPU disponibles en lugar de solo el 50%.

@brainwave @rodburns
Para Intel GPU (Gen9) bajo Linux, hemos visto un rendimiento de DNN significativamente mejor con la implementación de Beignet de código abierto de Intel en comparación con la de código cerrado cuando se compara con redes de visión comunes en PlaidML. Beignet también es más fácil de instalar, lo cual es bueno.

¿Es compatible con Intel Graphics HD615 (CPU de 7.ª generación) en ubuntu17.10?

El controlador opencl SRB5.0 para linux64 funciona bien en ubuntu17.10.

Y hace mucho tiempo que no se actualiza:
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Por el amor de Dios, ¿no puedes leer solo las 2 (¡dos!) publicaciones anteriores?
Discuta la falta de compatibilidad con intel gpu (o amd cpu) aquí https://github.com/codeplaysoftware/computecpp-sdk/issues/78

@znmeb es un objetivo hacer un uso completo de varios recursos informáticos (por ejemplo, cpu, gpu, DSP, cualquier otro coprocesador).
De hecho, depende del soporte de los proveedores de hardware: controlador y sistema operativo.
Como sé, es posible que no pueda habilitar la GPU intel y la GPU nvida para video durante el mismo tiempo, debido a la limitación del controlador de video. (Es posible que pueda cambiar entre ellos).
Sin embargo, opencl puede usarlos al mismo tiempo. Ambos son "dispositivos" en él.

@choongng Es interesante saberlo, trabajamos un poco para ayudar a habilitar Beignet, pero la actividad en este proyecto parece haberse calmado un poco.

@znmeb Sí, cualquier GPU probablemente no funcionará mucho mejor en un pequeño problema, ¡aunque me alegro de que estés progresando!

@unoexperto ComputeCpp con TensorFlow puede ser utilizado por cualquier hardware que admita las instrucciones intermedias de SPIR OpenCL que incluyen GPU Intel. . Puede eliminar esa restricción, ya que parece que algunos usuarios lo tienen funcionando con diferentes controladores Intel. También estamos trabajando para habilitar esto para los procesadores ARM y Renesas que tienen controladores OpenCL.

@ sxpc722 Eso debería funcionar entonces. Por cierto, la nueva máquina es Windows 10 y no estoy planeando un arranque dual con Linux hasta que tenga que hacerlo. Estoy harto de buscar errores de controladores y bibliotecas para los proveedores (te miro a ti, AMD). De hecho, puedo poner una partición de Windows en mi estación de trabajo por la misma razón de AMD. ;-)

Han pasado 14 días sin actividad y este problema tiene un responsable. Actualice la etiqueta o el estado según corresponda.

El rendimiento de Tensorflow AMD OpenCL es muy lento según mis pruebas. Así que hice algunas pruebas básicas con otro marco de aprendizaje profundo. Encontrará mi configuración y puntos de referencia en mi página de GitHub aquí .

Larga historia corta. El otro marco de Deep Learning es aproximadamente 10 veces más rápido que Tensorflow AMD OpenCL actualmente.

@AlphasCodes @znmeb Sé que el equipo de TF prefiere mantener el hilo solo para TF, estamos felices de presentar la conversación específica de PlaidML sobre el proyecto PlaidML. Dicho esto, esperamos eventualmente admitir el propio TensorFlow, así como plataformas que no sean OpenCL (por ejemplo, Metal de Apple para iOS, que actualmente existe en forma de prototipo).

https://github.com/plaidml/plaidml

@choongng Gracias por la información, edité mi mensaje en consecuencia.

@znmeb La iGPU AMD A12-9800E debe ser GCN v3.

La principal y única razón por la que hago los puntos de referencia/pruebas es encontrar una respuesta a mi pregunta "Quédate con AMD o cámbiate a Nvidia para mi aventura de aprendizaje profundo".

Y la respuesta es. Me gusta mucho el enfoque de código abierto de AMD, pero probablemente cambiaré a Nvidia debido a 2 factores. Primero, la pila de software de aprendizaje profundo (por ejemplo, Tensorflow) es mucho más madura para Nvidia. En segundo lugar, las ofertas de tarjetas gráficas para mis necesidades muy específicas (deben caber en una carcasa Dan A4 SFX y deben ser muy, muy silenciosas/casi silenciosas bajo carga completa durante horas) son muy limitadas o incluso inexistentes en el lado de AMD.

¿Son compatibles las GPU Intel? Creo que mi Iris Pro puede acelerar un poco el entrenamiento de toda la vida.

Analice la falta de compatibilidad con intel gpu (o amd cpu) aquí codeplaysoftware/computecpp-sdk#78

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

Solo trato de tener una idea del estado de este problema. ¿Tengo razón al decir que este repositorio:

https://github.com/lukeiwanski/tensorflow

... construido con ComputeCpp, ¿es la mejor opción actual para construir Tensorflow con soporte general de GPU AMD? Y si es así, ¿hay alguna evidencia de referencia de que esta compilación proporcione una aceleración sobre la CPU?

Depende de lo que quiera decir con "soporte general de GPU AMD". Si te refieres a dGPU o APU realmente antiguas, no lo sé. Pero si tiene una versión más nueva (GCN de segunda generación o más nueva), hipTensorFlow (v1.0.1) ejecutándose en ROCm funcionó bastante bien.

@briansp2020 Ah, sí, he visto el trabajo de AMD en ROCm. Desafortunadamente, solo son compatibles con Linux, y ni siquiera parece que el soporte para ningún otro sistema operativo esté en su hoja de ruta. Espero algo que sea compatible con Windows.

@mjmax ¿Hay algún paquete de tensorflow acelerado por GPU disponible para Windows? Pensé, si quieres un aprendizaje profundo acelerado por GPU, Linux era la única opción. Si TensorFlow se transfiriera a OpenCL, ¿facilitaría eso la migración a Windows? No estoy seguro de por qué TensorFlow no está disponible en Windows con aceleración de GPU cuando CUDA es compatible allí.

Supongo que esto ahora está fuera de tema, pero si alguien sabe de TensorFlow y/o PyTorch para Windows acelerado por GPU, me gustaría saberlo también...

@briansp2020 Hasta donde yo sé, Tensorflow ya es compatible con la aceleración de GPU de Nvidia en Windows.

CL tensofrflow ya es un desastre en Linux, no esperes nada pronto.
Si quieres acelerar las cosas allí, solo hay plaidML.
(y por favor, ya llegamos a los 500 comentarios... tratemos de publicar solo si es realmente, realmente necesario)

@mirh OpenCL Caffe funciona en Windows. Claro que no es TensorFlow en términos de características, pero es bastante sólido para el software que debe implementarse en todas partes.

¿Qué hay de reemplazar el puerto openCL con el puerto HIP respaldado por AMD?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

¡Ja ja! @LifeIsStrange La vida es muy extraña en realidad... ¿Trabajas para el equipo de marketing HiP de AMD? :-)
Mire el tema de este problema: "Soporte de OpenCL".

Esto significa que se trata del estándar Khronos https://en.wikipedia.org/wiki/OpenCL (y el otro estándar SYCL del grupo de trabajo de OpenCL Khronos aparece al final de la sección "Descripción general").

Por supuesto que hay un mundo fuera de este tema, pero es... ¡ fuera ! :-)

Por favor, trate de no aumentar desconsideradamente la entropía del universo publicando algunas publicaciones al azar en esta discusión que ya es demasiado larga... :-)
Este comentario se aplica a algunos otros carteles aquí, no solo a ti, por cierto.
Este es un problema de GitHub para resolver un problema técnico : tener TensorFlow ejecutándose en dispositivos compatibles con el estándar OpenCL, no una página de FaceBook sobre cómo a las personas les gusta o no la herramienta A o B. :-)
Pero no dude en enviar algunos compromisos de git relacionados con este problema que podemos ver...

Hay una bifurcación de TensorFlow compatible con OpenCL https://github.com/hughperkins/tf-coriander

Y por supuesto el trabajo de @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

En mi humilde opinión, es ridículo que la corriente principal de TF aún no haya fusionado su trabajo.

¿El enfoque aquí es hacer que funcione como OpenCL o hacer que funcione más rápido? Preferiría que no haya una guerra santa, sino que me concentre en hacer que funcione rápido en varias GPU. El enfoque de LifeIsStrange es hacer que funcione en GPU AMD y luego HIP tiene sentido. Para otros, el enfoque es hacer que funcione en GPU Intel o Android, y luego OpenCL tiene mucho más sentido. Los lenguajes GPU son un desastre, así que sea práctico,

Si leo algunos de los comentarios aquí, el rendimiento es un problema con los puertos OpenCL. Pero desafortunadamente no puedo ver muchos puntos de referencia alrededor. ¿Hay más puntos de referencia que este? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

Según tengo entendido, la evaluación comparativa es difícil si compara CUDA con OpenCL, porque tiene que usar un hardware diferente. Supuestamente, nVidia hizo/permitió deliberadamente que su implementación de OpenCL se rompiera un poco, por lo que la evaluación comparativa en el mismo hardware siempre dará como resultado que CUDA se vea genial.

El 12 de febrero de 2018 a las 14:26:11 GMT+00:00, VincentSC [email protected] escribió:

¿El enfoque aquí es hacer que funcione como OpenCL, o
haciendo que realmente funcione más rápido? Preferiría que no hubiera una guerra santa, pero
centrándose en hacer que funcione rápido en varias GPU. La vida es extraña
el enfoque es hacer que funcione en las GPU AMD y luego HIP lo hace bien
sentido. Para otros, el objetivo es hacer que funcione en GPU Intel o
Android, y luego OpenCL tiene mucho más sentido. Los lenguajes GPU son un
desorden, así que por favor sea práctico,

Si leo algunos de los comentarios aquí, el rendimiento es un problema con el
Puertos OpenCL. Pero desafortunadamente no puedo ver muchos puntos de referencia alrededor.
¿Hay más puntos de referencia que este?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-364936498

--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

Comparar solo 2 números no es información: ¿a quién le importa si OpenCL en NVidia se ejecuta a la mitad de la velocidad si se ejecuta a una velocidad 4x en otras GPU?

Creo que necesitaríamos estos puntos de referencia:

1. CUDA en GPU NV (puntos de referencia de referencia)
2. https://github.com/hughperkins/tf-coriander en GPU AMD, Nvidia e Intel
3. https://github.com/benoitsteiner/tensorflow-opencl en GPU AMD, Nvidia e Intel
4. https://github.com/lukeiwanski/tensorflow en GPU AMD, Nvidia e Intel

Los puntos de referencia de referencia son fáciles de encontrar. Aquí tenemos algunas GPU de gama alta, por lo que solo necesitamos un lugar para poner los números (con enlaces a documentos de construcción).

Soporte OpenCL Debe hacerse realidad.

cuda es demasiado limitado y nvidia no quiere compartirlo.
cuda solo funciona para Nv gpus.
ese es un callejón sin salida para TensorFlow,
si sale otro "TensorFlow" pero mas soporte que TensorFlow.
si TensorFlow aún solo admite cuda en Windows.
debe darse cuenta de que TensorFlow no es la única opción.

¿Por qué OpenCL es mejor que HIP? Creo que OpenCL no ha logrado ganar tracción y apoyar a OpenCL en este momento probablemente sea contraproducente y una pérdida de recursos para toda la comunidad/industria. Prefiero ver que TensorFlow admita HIP directamente y deje que el compilador/herramienta/biblioteca se encargue de la portabilidad.

¿No es mejor que el software admita 1 lenguaje/modelo de programación?

El software tiene que soportar lo que tiene que soportar para cubrir cada caso de uso.
HIP es todo campanas y silbatos (al menos en el papel) si tiene hardware compatible. Pero no solo hay "tarjetas amd y nvidia más nuevas" en este mundo.

Ahora, por favor, por el amor de Dios, quéjese aquí por cualquier problema con eso.
Y aquí para todos los demás interesados ​​en la continuación de este número.

Pensé que SPIR-V reemplazaría directamente a CUDA como una alternativa de hardware cruzado:
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

¿Por qué Google sigue confiando en CUDA?

¿Estos pueden ayudar?

Generación de números aleatorios de OpenCL (de Thomas Wang):

uint wang_hash(uint seed)
{
               seed = (seed ^ 61) ^ (seed >> 16);
               seed *= 9;
               seed = seed ^ (seed >> 4);
               seed *= 0x27d4eb2d;
               seed = seed ^ (seed >> 15);
               return seed;
}

void wang_rnd_0(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(id);
               intSeeds[id]=rndint;
}

float wang_rnd(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(intSeeds[id]);
               intSeeds[id]=rndint;
               return ((float)rndint)/(float)maxint;
}


// initialize each thread's own random number seed
__kernel void rnd_0(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               wang_rnd_0(intSeeds,id);     
}

// get a new random value by each thread
__kernel void rnd_1(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               float randomFloat=wang_rnd(intSeeds,id);
}

OpenCL SHA3hashing (olvidé quién escribió esto)

https://gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Elimine al asignado, ya que este problema invita a contribuciones externas. De lo contrario, elimine la etiqueta contributions welcome . Gracias.

Elimine al asignado, ya que este problema invita a contribuciones externas. De lo contrario, elimine la etiqueta contributions welcome . Gracias.

A Google le interesa admitir OpenCL,
al tener un hardware específico de (empresa/marca/proveedor) como dependencia para su software, se obliga a pagar más por el hardware, la competencia en el mercado reduce los costos.
Google siempre se ha centrado en el hardware de productos básicos desde el principio, lo que fue y sigue siendo crucial para el éxito de Google (dominio del mercado), al tener costos operativos de centro de datos más bajos, permitió las revolucionarias y generosas ofertas de servicios esencialmente gratuitos como Gmail (espacio de almacenamiento) y Google Photos (espacio de almacenamiento). espacio y etiquetado automático).

@wesamco No, no es necesariamente del interés de Google. Hacen su propio hardware, algo llamado "TensorBoard", IIRC. Pueden omitir OpenCL y CUDA/CUDnn y hacer que la placa ejecute código TensorFlow sin procesar.

código sin procesar de TensorFlow.

No existe tal cosa, no es como la comida sin procesar. Las TPU necesitan su propia biblioteca DNN que maneje los diferentes tipos de llamadas.

Parece que es hora de comprimir la discusión anterior en una lista nuevamente:

• CodePlay está trabajando en un backend SYCL
• Hugh Perkins está trabajando en tf-cilantro
• AMD está trabajando en un backend HIP
• PlaidML solo admite CPU en este momento.
• El estado del soporte para las GPU Intel no está claro.

Así que elige un proyecto que te guste y empieza a apoyarlo. ¿Quizás cada uno de los grupos pueda dar una actualización del estado de su proyecto?

Comprenda que OpenCL se ha transformado de un idioma completo a una definición de idioma/especificación de hardware que se representa en SPIRV (núcleos), que luego se puede ejecutar sobre una plataforma como controladores OpenCL y más tarde también en controladores Vulkan. (plataformas). Entonces, al admitir SYCL, también admite OpenCL.

Resumen perfecto, pero plaidml también se ejecuta en GPU.
Es solo que por el momento son un backend para keras, no tensorflow. Así que es un poco OT allí.

Hola a todos,
¡@VincentSC gracias por el gran resumen de los diferentes esfuerzos!

Así que elige un proyecto que te guste y empieza a apoyarlo. ¿Quizás cada uno de los grupos pueda dar una actualización del estado de su proyecto?

El enfoque SYCL ahora es compatible con una variedad de plataformas/dispositivos. Los que puedo mencionar son:

• GPU AMD (FirePro W8100, R9 Nano y R9 380 Series) Instrucciones disponibles aquí o aquí
• ARM Mali (HiKey 960) Instrucciones disponibles aquí
• GPU Intel (serie SkyLake) con controlador Intel NEO OpenCL

En lo que respecta a AMD, en este momento las GPU mencionadas anteriormente utilizan los controladores AMDGPU-Pro 17.40-xxx con OpenCL heredado habilitado.
No veo ninguna razón obvia por la que otras series no funcionen (asumiendo que SPIR / SPIR-V es compatible, es decir)

La plataforma principal en la que nos estamos enfocando es Linux; sin embargo, tenemos esfuerzos continuos para habilitar Windows en el futuro. No tenemos planes de admitir OSX en un futuro próximo. Conozco cara triste.

Nuestro enfoque es mejorar el rendimiento de las CNN. El rendimiento actual no está optimizado y no está cerca de donde lo vemos terminar. Dicho esto, ya estamos superando el rendimiento de la CPU para la mayoría de los modelos en diferentes objetivos.

Para acelerar el ciclo de desarrollo y reducir el tiempo de compilación general de TensorFlow (además de mejorar la portabilidad), estamos trabajando en las bibliotecas Eigen, BLAS y DNN.
Estas bibliotecas tienen como objetivo resolver el problema de rendimiento y construir un ecosistema de bibliotecas portátiles que se puedan integrar fácilmente con proyectos complejos como TensorFlow.

A continuación, vea los gráficos de rendimiento que podemos compartir en la actualidad. Están tomados de mi bifurcación https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu en 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
El punto de referencia utilizado es https://github.com/tensorflow/benchmarks

El gráfico se normaliza a los resultados de Intel i7-4790K.

Estamos actualizando lentamente los cambios a Eigen una vez que eso suceda, seguiremos con TensorFlow.

Espero que ayude,
Lucas

Para la inferencia de aprendizaje profundo en dispositivos móviles compatibles con GPU/OpenCL, puede consultar MACE , que está optimizado para GPU Adreno, Mali y PowerVR. Aquí hay algunos resultados de referencia .

@keryell @benoitsteiner , qué versión de tensorflow y trisycl se requieren para la integración. Tengo problemas para construir tensorflow (1.9) con la última versión de trisycl.

Lamentablemente, el último TensorFlow utiliza funciones más avanzadas de las que puede hacer frente el triSYCL actual, por lo que debe usar ComputeCpp, actualmente la única implementación de SYCL totalmente compatible...

Tensorflow es compatible con Google Brain, y Google tiene una asociación con nVidia, supongo que no debemos esperar que Tensorflow admita OpenCL.
Se necesita un gran esfuerzo de la comunidad de OpenCL

Soporte OpenCL por favor!

OpenCL también es más adecuado para nosotros.

@Makhaon Yo también. No puedo permitirme comprar una máquina con tarjeta gráfica NVIDIA.

Además de las 2 publicaciones anteriores, me gustaría agregar que ahora las GPU Vega de AMD (incluidas las que están dentro de las APU Raven Ridge) pueden hacer FP16 al doble de FLOPS, por lo que si TF pudiera admitirlas (a través de OpenCL) realmente ayudaría a las personas con menos presupuesto Además, muchas de estas personas serían estudiantes, y si conseguimos que usen TF como punto de partida de su viaje a DNN, probablemente se queden con TF en el futuro, e incluso les hablarán a otros sobre TF; es una gran manera de ayudar a expandir este proyecto.

Creo que este hilo no tiene sentido para los desarrolladores (demasiado ruido, y agregaré algo más ;-) pero creo que muchos comentarios no entienden el punto:
Si desea ejecutar Tensorflow con tarjetas AMD, OpenCL NO ES lo que está buscando , diríjase a https://github.com/ROCmSoftwarePlatform/ e instale la pila ROCm. AFAIK La estrategia actual de AMD se basa en ROCm en lugar de OpenCL para Tensorflow/pytorch .

OpenCL genérico requería demasiado mantenimiento/no brindaba suficientes beneficios de rendimiento para que AMD valiera la pena. Por lo tanto , este ticket solo es interesante si está ejecutando (por ejemplo) una plataforma ARM que solo usa OpenCL.

(Descargo de responsabilidad: solo un extraño, no hay información real sobre el desarrollo de Tensorflow, por lo que tal vez la información anterior sea completamente incorrecta y engañosa. Siéntase libre de criticarme si sabe mejor).

Solo un pensamiento, ¿qué pasa con llvm con la nueva descarga de GPU? Eso pondría un gran nivel de abstracción entre tensorflow y el código específico de cuda.

¿Qué pasa con todos ustedes que leen solo 10 publicaciones anteriores y se dan cuenta de que ya hay una bifurcación de lukeiwanski/codeplaysoftware que pueden probar?
(también me quito el sombrero ante xiaomi por, una vez, contribuir con un tipo serio de esfuerzo de código abierto)

@FelixSchwarz Solo para que sepa que ROCm usa OpenCL, es el controlador OpenCL del espacio de usuario de AMD en Linux (es por eso que no es compatible con Windows), por lo que si no sabe cómo funciona el ecosistema de controladores de AMD en Linux, tienen sus controladores del lado del kernel AMDGPU y AMDKFD (que ahora se fusionan en AMDGPU), luego están los controladores de espacio de usuario RadeonSI (para OpenGL) RadV/AMDVLK (para Vulkan) y ROCm (para OpenCL).

A juzgar por la dinámica de este error y otras bifurcaciones, Google no tiene ningún interés en esto y nunca lo implementará en el repositorio oficial. Votaría por cerrar este problema (o bloquearlo) para no dar falsas esperanzas a todos.

El problema debería estar aquí para al menos señalar aquí a todas las personas que
inevitablemente abrirlo de nuevo.

El sábado 15 de septiembre de 2018 a las 09:45, Anton Kochkov [email protected] escribió:

A juzgar por la dinámica de este error y otras bifurcaciones, Google tiene cero
interés en esto y nunca implementará esto en el oficial
repositorio. Votaría por cerrar este problema (o bloquearlo) para
No dar falsas esperanzas a todos.

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Hay un TensorRT que admite Movidius Pi Hat. Y ese Movidius Pi Hat es el “AIY Vision Kit” de Google de $45. Google enlaza con Target para comprarlo.

¿Esto no tiene ningún vínculo con CUDA o Nvidia? Dice que usa un chip Intel. En el fondo, ¿tal vez el chip sea un FPGA? ¿Alguien sabe algo más al respecto?

Sé bastante sobre la gran unidad Movidius: es solo de inferencia y ejecuta modelos precompilados de TensorFlow o Caffe. IIRC están todos en modo de 16 bits.

El chip Movidius en sí es mucho más potente, pero debe ser un socio calificado para obtener el SDK.

Tenga algún enlace para otros que intenten tener tensor opencl:

https://github.com/hughperkins/tf-coriander
https://github.com/ChiahungTai/tensorflow-cl
https://github.com/guoyejun/tensorflow-cl
https://github.com/honggui/tensorflow-cl
https://github.com/benoitsteiner/tensorflow-opencl
https://github.com/lukeiwanski/tensorflow (el repositorio está desactualizado)
https://github.com/codeplaysoftware/tensorflow
Tal vez vale la pena comprobar también:

https://documen.tician.de/pyopencl/
https://pypi.org/project/DeepCL/
https://www.khronos.org/sycl/

Siéntase libre de agregar proyectos de trabajo.

¿Hay alguna actualización? Este problema tiene más de 3 años.

SÍ, SOLO MIRA LAS ÚLTIMAS PUBLICACIONES.

@ filips123 no, no hay actualizaciones y nunca las habrá en un futuro previsible; la probabilidad de eso es menor que la de una invasión extraterrestre y encontrar una manera de viajar en el tiempo.

Esta iniciativa de inteligencia, PlaidML, funciona razonablemente bien, vale la pena echarle un vistazo.
https://github.com/plaidml/plaidml
Se ejecuta en opencl O metal en mac. Funciona con Macbook Pro AMD gpus, que es lo que estaba buscando.
Mientras tanto, ¿podrían ayudar a votar por la compatibilidad con Pytorch en PlaidML? https://github.com/plaidml/plaidml/issues/63

PlaidML es ciertamente agradable y elegante (yo, por mi parte, de alguna manera podría obtener más rendimiento en una nvidia gpu en opencl que con la propia cuda de tf).
¿Pero es un backend para keras? En reemplazo completo de tensorflow, que ya sabes, ¿es el repositorio en el que estamos discutiendo esto?
(por lo que parece entender, las últimas versiones de tf pueden exportar modelos directamente a keras, así que eso es...)

De todos modos, por cuarta vez, si quieres una solución reciente en opencl y algo que aún se está desarrollando activamente ( y también la posibilidad real de fusionarse aquí algún día), solo hay una pila de código.
Otra vez:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

PlaidML es ciertamente agradable y elegante (yo, por mi parte, de alguna manera podría obtener más rendimiento en una nvidia gpu en opencl que con la propia cuda de tf).
¿Pero es un backend para keras? En reemplazo completo de tensorflow, que ya sabes, ¿es el repositorio en el que estamos discutiendo esto?
(por lo que parece entender, las últimas versiones de tf pueden exportar modelos directamente a keras, así que eso es...)

De todos modos, por cuarta maldita vez, si quieres una solución reciente en opencl y algo que aún se está desarrollando activamente (_y también_ la cosa con las posibilidades reales de fusionarse aquí algún día), solo hay una pila de código.
Otra vez:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

Mis disculpas, no me había dado cuenta de que no había soporte para tensorflow. Mi supuesto cerebro pensó que keras gpu support == tensorflow support.

plaidML es genial. Funciona en Keras.
Por supuesto, tuve que transferir algo de código tf a keras puros para poder trabajar en el backend plaidML (por ejemplo, tf.image.ssim)
Pero resultado: mi código funciona en tarjetas NVIDIA y AMD.

También plaidML es el paraíso para los investigadores. Genera automáticamente un gradiente para cualquier función que escriba en el lenguaje "Mosaico" y funcionará en su GPU con un 80% de velocidad de tensorflow.

Entonces, no puedo entender por qué los investigadores de ML todavía usan PyTorch. ¿Impulsemos la ciencia de ML con plaidML de Intel?

@iperov ¿Le importa saber por qué prácticamente nadie usa PlaidML?

1. Funciona lamentablemente lento en las implementaciones de OpenCL de AMD en comparación con el backend CUDA de Tensorflow, por lo que hay al menos la mitad de la razón para usarlo. ¿El rendimiento es tan malo que usar Tensorflow con CPU es competitivo o incluso supera por completo a su hardware usando PlaidML?

2. Nadie está interesado en mantener su lenguaje de programación Tile especializado en el que solo alguien como un profesor de matemáticas puras inventaría, por lo que la calidad del código de PlaidML simplemente se va por el desagüe y ningún programador serio en su sano juicio querría lidiar con un código demasiado inteligente...

3. Esto se relaciona bastante con el n. ° 2, pero desde que Intel compró Vertex.AI, ya no les importa PlaidML. La solución de Intel para el aprendizaje automático acelerado por cómputo GPU presenta un nuevo compilador específicamente para el aprendizaje profundo ahora conocido como nGraph para apuntar a Tensorflow, PyTorch u otros marcos de aprendizaje profundo como backend para ellos. No hay motivo para que sigan desarrollando PlaidML como su intermediario cuando tienen nGraph...

La gente usa PyTorch por otras razones, como la capacidad de mantenimiento u otras funciones, por lo que, para resumir, PlaidML es la herramienta de Intel y probablemente no tengan la intención de que desempeñe ningún papel en las partes finales de sus planes. El backend de GPU Intel actual de nGraph se basa en OpenCL 2.1, del cual solo Intel tiene una implementación conforme, por lo que Intel solo existe para cuidarse a sí mismo y no solo para mejorar el aprendizaje automático. Cuando Intel prosiga con el desarrollo de nGraph, no veo que sigan basando su backend de GPU en OpenCL 2.1 solo, ya que muchos marcos de trabajo de aprendizaje profundo tienen núcleos con plantillas que no son compatibles con los modelos de programación de fuentes separadas de OpenCL, Metal o Vulkan, por lo que probablemente sea sólo con fines de experimentación. El backend de GPU final de Intel probablemente se basará en SYCL 2.2 o en algo completamente diferente como OpenMP y tal vez incluso traigan una solución específica del proveedor...

En cuanto a AMD, ¿a quién le importa? OpenCL es irrelevante para ellos y finalmente están mostrando algunos resultados con su trabajo en HIP...

@iperov ¿Le importa saber por qué prácticamente nadie usa PlaidML?

1. Funciona lamentablemente lento en las implementaciones de OpenCL de AMD en comparación con el backend CUDA de Tensorflow, por lo que hay al menos la mitad de la razón para usarlo. ¿El rendimiento es tan malo que usar Tensorflow con CPU es competitivo o incluso supera por completo a su hardware usando PlaidML?
2. Nadie está interesado en mantener su lenguaje de programación Tile especializado en el que solo alguien como un profesor de matemáticas puras inventaría, por lo que la calidad del código de PlaidML simplemente se va por el desagüe y ningún programador serio en su sano juicio querría lidiar con un código demasiado inteligente...
3. Esto se relaciona bastante con el n. ° 2, pero desde que Intel compró Vertex.AI, ya no les importa PlaidML. La solución de Intel para el aprendizaje automático acelerado por cómputo GPU presenta un nuevo compilador específicamente para el aprendizaje profundo ahora conocido como nGraph para apuntar a Tensorflow, PyTorch u otros marcos de aprendizaje profundo como backend para ellos. No hay motivo para que sigan desarrollando PlaidML como su intermediario cuando tienen nGraph...

La gente usa PyTorch por otras razones, como la capacidad de mantenimiento u otras funciones, por lo que, para resumir, PlaidML es la herramienta de Intel y probablemente no tengan la intención de que desempeñe ningún papel en las partes finales de sus planes. El backend de GPU Intel actual de nGraph se basa en OpenCL 2.1, del cual solo Intel tiene una implementación conforme, por lo que Intel solo existe para cuidarse a sí mismo y no solo para mejorar el aprendizaje automático. Cuando Intel prosiga con el desarrollo de nGraph, no veo que sigan basando su backend de GPU en OpenCL 2.1 solo, ya que muchos marcos de trabajo de aprendizaje profundo tienen núcleos con plantillas que no son compatibles con los modelos de programación de fuentes separadas de OpenCL, Metal o Vulkan, por lo que probablemente sea sólo con fines de experimentación. El backend de GPU final de Intel probablemente se basará en SYCL 2.2 o en algo completamente diferente como OpenMP y tal vez incluso traigan una solución específica del proveedor...

En cuanto a AMD, ¿a quién le importa? OpenCL es irrelevante para ellos y finalmente están mostrando algunos resultados con su trabajo en HIP...

¿Qué pasa con todas las GPU dentro de la máquina del brazo, como teléfonos móviles y raspberry pi odroid, etc.?
¿No son compatibles con opencl?
Google debería preocuparse por insertar tensorflow en gpu en android.
Las bibliotecas más grandes de entrenamiento de redes neuronales se ejecutan solo en Nvidia gpu, solo hace que Nvidia gpu sea cada vez más cara (porque las personas y las empresas solo lo compran para el entrenamiento profesional de redes neuronales), entonces Google perderá más dinero de esa manera.

@Degerz, ¿ de qué planeta vienes?
¿Cómo se puede comparar tf-CPU y AMD GPU?
GPU AMD en plaidML x30 más rápido que tf-CPU

1. Funciona lamentablemente lento en las implementaciones OpenCL de AMD en comparación con el backend CUDA de Tensorflow, por lo que hay al menos la mitad de la razón para usarlo.

en mis pruebas de deepfakes, OpenCL es más lento solo un 20 %, pero en algunas mini redes, OpenCL es un 20 % MÁS RÁPIDO.

Mi proyecto DeepFaceLab tiene muchos usuarios que han estado esperando el apoyo de AMD. Cuántas personas quedaron encantadas cuando finalmente se pueden entrenar deepfakes en tarjetas AMD.
Además, plaidML es el único backend para keras que admite AMD/IntelHD listo para usar.
Si aparece un nuevo backend de AMD para keras, por supuesto, mi proyecto cambiará a él.
PyTorch no tiene futuro.

¿Qué mantener en plaidML? Las operaciones son diferenciables automáticamente, no hay nada que mantener.

Lenguaje de programación de mosaicos en el que solo alguien como un profesor de matemáticas puras inventaría

El aprendizaje automático lo inventaron los profesores de matemáticas, ¿no?

@talregev ¿Qué pasa con ARM o Broadcom? ¡El primero probablemente tiene una implementación de OpenCL deficiente y el segundo ni siquiera proporciona oficialmente controladores OpenCL! No es responsabilidad de Google crear y mantener una pila de cómputo competente para los proveedores de hardware...

@iperov Te das cuenta de que entrenar redes neuronales con capas incrustadas en PlaidML es doloroso, ¿verdad? PlaidML también tiene muchas otras limitaciones, como no ser tan adecuado para DenseNets o el hecho de que sus gráficos de cálculo son estáticos y PlaidML incluso funciona bien con RNN.

En cuanto a tu proyecto, no te preocupes. Pasará a algo mejor como Tensorflow, ya que AMD pronto ofrecerá un backend de GPU nativo una vez que MIOpen se actualice, que es su biblioteca acelerada de GPU de primitivas para redes neuronales profundas similar a la biblioteca cuDNN de su competidor, las cuales dejarán PlaidML en el polvo en términos de rendimiento. ¿A quién le importan las Intel iGPU de todos modos? Si Intel está realmente comprometida con la entrega de aprendizaje profundo de alto rendimiento en su futuro hardware de gráficos discretos, entonces ofrecerá una opción de fuente única, tal como lo hicieron los demás (AMD/HIP y Nvidia/CUDA) antes que ellos...

PyTorch no tiene futuro.

envidia mucho? PyTorch es ~ 10 veces más popular que PlaidML, las técnicas más nuevas en DL se implementan fácilmente en PyTorch, muchos contribuyentes diferentes y Facebook lo desarrolla activamente, mientras que Intel no ha contribuido a PlaidML en casi un mes.

¿Qué mantener en plaidML? Las operaciones son diferenciables automáticamente, no hay nada que mantener.

Entonces, supongo que PlaidML no debería recibir nuevas correcciones o nuevas funciones en el futuro. Si no ve el valor de mejorar el código, entonces no tiene sentido convencerlo de que reconozca los defectos evidentes de PlaidML...

El aprendizaje automático lo inventaron los profesores de matemáticas, ¿no?

No significa que tengamos que adoptar el lenguaje de programación que componen, especialmente en el caso de Tile, donde se favorece claramente la elegancia sobre la legibilidad. No es de extrañar por qué tantos contribuyentes potenciales tienen miedo de contribuir...

Jesús, les deseo STFU y que vuelvan al trabajo. Tendré que darme de baja del ticket porque es insoportable recibir emails con flame wars. Lástima que los mantenedores no silencien el hilo.

@gunan @caisq @sanjoy ¿Podría hacer algo al respecto?