É estranho que o Google tenha abandonado o OpenCL aberto para o CUDA proprietário.

No mínimo, a biblioteca Eigen teria que suportar OpenCL.

:+1:

:+1:

:+1:

polegares para cima e tudo isso.

Estarei interessado em expandir o Tensor Flow com OpenCL. Como já lançamos o OpenCL caffe. https://github.com/amd/OpenCL-caffe. Espero que possa ser integrado de forma leve? Alguém está interessado em trabalhar juntos nisso?

@gujunli É bom ver a AMD aqui. /cc @naibaf7 @lunochod

seria ótimo.

:+1:

/cc @lukeiwanski para Eigen/OpenCL/SYCL

@gujunli Certamente estaria interessado em contribuir. Por favor, deixe-me saber quando você planeja começar.

Olá a todos,

Aqui no Codeplay estamos analisando o tensor de Eigen rodando em GPU usando SYCL (uma camada C++ moderna em cima de OpenCL). Pelo que reunimos até agora, o design do tensor da GPU está intimamente ligado ao CUDA e exigirá alterações de interface para outro modelo de programação e particularmente uma versão SYCL e OpenCL 1.2.

Se alguém estiver interessado em aprofundar/ajudar, certamente estamos interessados ​​em contribuir.

Obrigado,
Lucas

@lukeiwanski Obrigado pelo feedback. Acho que @benoitsteiner trabalhou na parte de extensão do tensor de eigen.

:+1: Eu posso ajudar a codificar alguns OpenCL/SYCL se alguém fizer um plano, dividir o trabalho em tarefas etc. Eu recomendo usar Boost.Compute como um wrapper para OpenCL (facilita a execução de kernels, testes, modelagem).

+1

:+1:

Olá a todos,

Apenas para mantê-lo informado, ainda estamos investigando como podemos alterar a interface Eigen para melhor se adequar ao modelo de programação SYCL/OpenCL 1.2.
Assim que encontrarmos uma abordagem razoável que tenha como alvo modelos de programação heterogêneos (não apenas OpenCL/SYCL), criaremos uma proposta.

Obrigado,
Lucas

Pls me manter atualizado. Desenvolvi o opencl-caffe para a AMD. eu também estou olhando
fluxo tensorial.

Obrigado.
Junlu
Em 8 de dezembro de 2015 10h19, "Luke Iwanski" [email protected] escreveu:

Olá a todos,

Apenas para mantê-lo informado, ainda estamos investigando como podemos alterar o
Interface Eigen para melhor se adequar ao modelo de programação SYCL/OpenCL 1.2.
Assim que chegarmos a uma abordagem razoável, criaremos uma proposta.

Obrigado,
Lucas

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -162967662
.

/cc @ptillet @gongzg Existe algum interesse nisso por parte da Intel? Eu realmente espero que não fragmentemos o OPENCL aqui como em Caffe, onde temos um fork AMD, PRs não mesclados da Intel, outro PR semi-oficial da AMD e um PR de usuário de longa fase (mais dois antigos esforços Opencl abandonados). Se alguém estiver interessado na história pode dar uma olhada nos comentários https://github.com/BVLC/caffe/pull/2610 .

@bhack Temos interesse nisso. Obrigado por me avisar. Se houver uma proposta para a implementação do OpenCL/SYCL da Eigen, veremos o que podemos fazer do lado da Intel.

:+1:

Uma iniciativa interessante em https://github.com/ptillet/isaac também se aqui contarmos com a extensão do tensor Eigen.

Eu também gostaria de contribuir. @benoitsteiner você pode organizar?

Isso foi incluído no Roadmap, mas também marcado como contribuição para que uma direção/bootstrap pudesse ser realmente útil.

Posso contribuir para organizá-lo. quem é responsável pelo suporte OpenCL em
Fluxo tensor agora?

Muito obrigado.
Junli

Em terça-feira, 19 de janeiro de 2016 às 7h50, bhack [email protected] escreveu:

Isso foi incluído no Roteiro, mas também marcado como contribuição para que um
direction/bootstrap pode ser muito útil.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172894538
.

---

Junli Gu-谷俊丽
Laboratório de Ciências Coordenado
Universidade de Illinois em Urbana-Champaign

---

Eu apenas assumi Benoit porque ele auto-atribuiu o recurso, mas acho que você conseguiu Junli! Talvez começar com um e-mail ou tópico do fórum de partes interessadas?

@benoitsteiner sabe mais sobre as partes interessadas que podem não ter mostrado
neste tópico (ou nesta questão). Eu esperaria ele coordenar para fazer
certeza de que evitamos duplicar o trabalho.

Em terça-feira, 19 de janeiro de 2016 às 11h42 Dan McLaughlin [email protected]
escrevi:

Eu apenas assumi Benoit porque ele auto-atribuiu o recurso, mas acho que
você conseguiu Junli! Talvez comece com um e-mail ou tópico do fórum de
festas interessantes?

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

Estou interessado. Existe algum roteiro?

Em 19 de janeiro de 2016, às 11h46, Martin Wicke [email protected] escreveu:

@benoitsteiner sabe mais sobre as partes interessadas que podem não ter mostrado
neste tópico (ou nesta questão). Eu esperaria ele coordenar para fazer
certeza de que evitamos duplicar o trabalho.

Em terça-feira, 19 de janeiro de 2016 às 11h42 Dan McLaughlin [email protected]
escrevi:

Eu apenas assumi Benoit porque ele auto-atribuiu o recurso, mas acho que
você conseguiu Junli! Talvez comece com um e-mail ou tópico do fórum de
festas interessantes?

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub.

Existe uma lista de bibliotecas de dependência CUDA nas quais o Tensorflow confia?

Isso ajudaria a ver se poderíamos ter alternativas OpenCL imediatas.

@hsaputra
Existe clFFT, clBLAS (alternativamente ViennaCL). O gerador de números aleatórios é um pouco mais complicado (sem curand), use um gerador de CPU e transfira para a GPU ou use outro kernel existente para RNG.

A maior armadilha será novamente implementações de convolução eficientes (algo como cuDNN).

Há experiência sobre esses problemas aqui:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-caffe

Tensorflow usa extensão de tensor upstream para Eigen. Então eu acho que um suporte Opencl/Sycl para Eigen é necessário. Veja este tópico

Obrigado @naibaf7. Sim, não acho que haja uma alternativa viável para cuDNN para OpenCL agora.

O site http://opencl.org foi criado para dar suporte a projetos de portabilidade de código aberto como esses! No momento, estamos instalando todas as ferramentas necessárias no site e temos espaço para repositórios em https://github.com/OpenCL/ - mais tarde estamos adicionando servidores de compilação para testar vários tipos de hardware e podemos fornecer nossa experiência em como escrever código que roda a toda velocidade em vários hardwares.

Estamos lançando uma iniciativa de portabilidade para o GEGL na próxima semana, mas também estamos felizes em apoiá-lo.

@bhack desse tópico e aqui parece que @lukeiwanski está investigando. Acho que temos pessoas dispostas o suficiente para trabalhar nisso, só precisamos de @benoitsteiner , @lukeiwanski ou @gujunli para coordenar. Benoit está quieto, talvez esteja de férias.

Eu adoraria ajudar a contribuir com esta iniciativa.

Olá a todos,

vamos coordenar o esforço de portar o módulo tensor de Eigen para SYCL para OpenCL, pois já temos algo funcionando, mas ainda não está pronto para revisão.

Somos a favor dessa abordagem, pois introduzirá menos invasão à base de código. SYCL suporta o modelo de modelo C++ de fonte única que a eigen já usa.

O design do roteiro está em andamento, então não deve demorar muito agora.

Obrigado,
Lucas

@lukeiwanski Você está trabalhando ou em contato com upstream? Você acha que será aceito upstream em Eigen?

+1

Ótimas notícias @lukeiwanski , avise-nos de qualquer ajuda que precisar.

Acho que você está usando sua própria implementação do SYCL - isso estará disponível para desenvolvedores/pesquisadores? Em quais plataformas?

@lukeiwanski SYCL parece ser o caminho certo a seguir, dada a quantidade de metaprogramação de modelos envolvida com o Eigen. Eu sou um desenvolvedor c++ experiente com experiência OpenCL adquirida com o desenvolvimento de minhas próprias redes neurais e biblioteca de álgebra linear . Eu adoraria ajudar com esse esforço e começar a desenvolver com SYCL.

@bhack Estamos em contato com @benoitsteiner , mas discutiremos nossa proposta com os mantenedores upstream antes de investirmos muito esforço.

@DanMcLaughlin , @ville-k Estamos desenvolvendo nossa implementação de SYCL, ComputeCpp (https://www.codeplay.com/products/computecpp). Para mais informações, você pode entrar em contato comigo fora da lista através do endereço de e-mail no meu perfil?

@lukeiwanski existe alguma atualização/estimativa em relação aos planos?

+1.
Eu tenho uma GPU AMD e uma GPU Intel no laptop. Acho que ambos têm drivers OpenCL e o suporte da AMD parece ser muito melhor. Eu teria um desempenho maior, pois tenho 2 dispositivos OpenCL. Espero que você faça escala com dispositivos OpenCL.

Olá a todos,

Obrigado pelo interesse!
Neste ponto, estamos configurando nossa infraestrutura de teste para garantir que nada que façamos introduza regressão.
Estamos em contato com @benoitsteiner para garantir que estamos em sincronia com o que ele fez até agora.

Ainda estamos compilando um roteiro para o processo de integração - isso deve ser feito em algumas semanas, pois há alguns detalhes de negócios para esclarecer.

Nosso objetivo é trazer o OpenCL para o TensorFlow via Eigen até o final deste ano.

Obrigado,

interessado. adoraria contribuir.

Ok, na verdade parece que é um esforço de Codeplay com algum tipo de sincronização com o Google interno. Qual é o papel dos assinantes da AMD e da Intel aqui?

/cc @keryell se você tiver algum interesse sobre isso do universo SYCL/FPGA

Minhas desculpas por não contribuir mais para esta discussão recentemente, meu prato esteve mais do que cheio nas últimas 2 semanas.

Estarei coordenando o esforço do OpenCL no lado do TensorFlow. Nosso pensamento atual é:

• O TensorFlow depende do c++ 11 e adotou uma abordagem de "fonte única", então SYCL parece ser uma ótima opção.
• Não temos muita experiência em OpenCL internamente, então estamos colaborando de perto com a Codeplay para preencher essa lacuna. Em particular, o Codeplay está atualmente liderando o esforço para adicionar suporte para SYCL à biblioteca de tensores Eigen.
• O TensorFlow conta com a biblioteca cuDNN para calcular convoluções em GPUs NVidia. Se alguém estiver interessado em contribuir com um equivalente OpenCL, ficaremos felizes em ajudar.

Para ajudar a estruturar o esforço, criei uma lista de discussão: [email protected].

@bhack claro que tenho algum interesse em C++ de ponta em FPGA :-)
O TensorFlow também parece um bom caso de uso de validação para triSYCL.
Aliás, se algumas pessoas aqui estão procurando algum estágio nesse assunto, eu tenho algumas vagas. Parece que o Codeplay também está procurando por algumas pessoas, se eu confiar no site deles.

Estou muito interessado nas opiniões de @karlrupp e @hughperkins . Espero que eles queiram participar da discussão no novo grupo do Google.

@benoitsteiner Obrigado pela atualização. Seria maravilhoso se todos os parceiros envolvidos no @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx etc.) Uma espécie de esforço de padronização de visão computacional Khronos openvx , mas para aprendizado profundo.

@bhack Qual novo grupo do Google?

Fora isso, OpenCL e CUDA são abordagens de programação muito diferentes. CUDA funciona do jeito que é porque uma empresa tem controle total sobre tudo, então pode incorporar blobs binários e quem sabe o quê no executável final. Isso não pode ser feito com o OpenCL, a menos que alguém siga o caminho do SyCL (tenho minhas preocupações...) e o fornecedor do compilador SyCL tenha controle total sobre todas as arquiteturas de destino possíveis (improvável ou impossível na prática). No geral, minha opinião é que uma boa biblioteca habilitada para OpenCL precisa de mais do que apenas alguns ajustes aqui e ali. Provavelmente não é o que você queria ouvir, mas você pediu minha opinião :-)

@karlrupp Veja https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 no final para o grupo do google.
Pedi sua opinião porque você tem uma ótima experiência com o ViennaCL fazendo interface com uma biblioteca de álgebra com vários back-ends (CPU, GPU, MIC). O Tensorflow conta com a biblioteca Eigein e sua nova extensão de tensor contribuída pelo Google upstream (mas apenas com back-end CUDA). Eu acho que eles não experimentaram muito todas as armadilhas que você já encontrou com o ViennaCL nestes anos de desenvolvimento.

@bhack Estamos atualmente na reunião presencial em Seattle esta semana, mas é claro que não posso dizer se estamos falando de bibliotecas DNN ou não... :-)

@keryell Tente empurrar a causa em Seattle ;)

@karlrupp Você está certo, OpenCL e CUDA são abordagens de programação muito diferentes. O aspecto de fonte única encontrado, por exemplo, no CUDA e no OpenMP 4.5 é extremamente poderoso do ponto de vista da engenharia de software. É por isso que existe este padrão SYCL para os verdadeiros programadores C++. SYCL pode ser visto como CUDA em esteróides sem nenhuma extensão de linguagem e com alguns aspectos OpenMP (as tarefas). Espera-se que um compilador de dispositivo SYCL típico gere kernels SPIR-V.

Suas preocupações sobre a portabilidade são menos um problema com o padrão SPIR-V (tipo de equivalente portátil da nVidia PTX/AMDIL/... no mundo Vulkan e OpenCL) que é obrigatório aceitar no OpenCL 2.1 e Vulkan. Então a beleza é que se você tem um front-end que gera SPIR-V, você não precisa de conhecimento especial dos detalhes do hardware para rodar. Existe um tradutor bidirecional de código aberto Khronos entre LLVM IR e SPIR-V, então ele abre novos territórios.

@keryell Concordo que o SPIR-V é um passo à frente. No entanto, ele não aborda todas as questões de jitting exaustivo.

você não precisa de conhecimento especial dos detalhes do hardware para executar

Este é um copiar e colar do marketing do OpenCL 1.0, que reivindicou exatamente o mesmo? Você _sempre_ precisará ir aos detalhes do hardware subjacente se desejar obter o máximo desempenho. Este é especialmente o caso no contexto de contrações tensoras rápidas.

...como @scott-gray demonstrou com neon

@karlrupp

Este é um copiar e colar do marketing do OpenCL 1.0, que reivindicou exatamente o mesmo?

Haha. :-)

Você sempre precisará ir aos detalhes do hardware subjacente se quiser obter o máximo desempenho. Este é especialmente o caso no contexto de contrações tensoras rápidas.

Claro, mas antes de brincar com a otimização de segunda ordem, é útil ter a maior parte de todo o código C++ modelado rodando de alguma forma acelerada.

Para a otimização, você pode costurar seus kernels binários otimizados à la NervanaSys ou, como SYCL é C++ puro, você pode usar asm("...") nele com muito #ifdef para testar a arquitetura de destino. :-) Dito isso, o SPIR-V é extensível e não vejo por que não pudemos colocar VHDL ou Verilog embutido nele em algum momento. :-)

Mas, mais concretamente, a recente introdução de operações de subgrupo deve ajudar a obter um bom desempenho de maneira portátil e o uso de funções ad-hoc simples incorporadas pode ajudar.

O C++ adiciona recursos interessantes de metaprogramação que permitem substituir a maioria dos geradores de código usados, como em clBLAS ou outros frameworks, para gerar código mais adaptado ao hardware X ou Y.

Também o N4355 em c++17 pode entrar no jogo mais cedo ou mais tarde

@karlrupp , @bhack A abordagem do tensorflow é contar com uma abstração de hardware (o módulo tensor) para a maioria das operações necessárias em uma rede neural típica, enquanto conta com bibliotecas especializadas (como cudnn) para as poucas operações que são desempenho realmente crítico sábio. A abstração de hardware nos permite implementar a maioria das operações do TensorFlow uma vez e executá-las em um acelerador com desempenho mais do que suficiente.

@bhack Sim, eu amo matrizes multidimensionais. Também em nosso domínio de interesse, há o SG14 no comitê C++ que tenta fazer com que todas as pessoas interessadas nessas questões convirjam para o padrão.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Claro que a SYCL está nas discussões. :-)

@benoitsteiner Principalmente no cudnn para agrupamento e convolução. Acho que se cada fornecedor for produzir uma API com seu próprio hardware para essas operações com seu próprio assembly binário não será uma abordagem tão escalável. É por isso que acho que algumas chamadas de API cruciais para o desempenho seriam melhor padronizadas de alguma forma.

@keryell Existem tópicos realmente interessantes para Matrix/Tensor no novo SG14 c++ especialmente na agenda de chamadas vetoriais/SIMD. Mas parece que ninguém falou de convolução, pooling e outras interfaces de aprendizado profundo "estabilizadas" úteis. Também me parece que nestes subgrupos de padronização específicos existem pessoas da Nvidia, Intel, Amd, CodePlay etc., mas não do Google também se estiver em outros grupos.

:+1:

@bhack Sim, ainda não há uma proposta de estilo de aprendizado de máquina no SG14. Mas a participação é aberta, então você pode enviar algumas propostas. :-) Mas talvez o SG6 (tópicos numéricos) seja mais relevante. Eu não acho que eles tenham sua própria lista de discussão/fórum ainda.

@gujunli O OpenCL Caffe é executado no Android? Desculpe por perguntar isso aqui, mas não encontrei nenhum outro lugar para perguntar :) Seria ótimo com uma biblioteca de aprendizado profundo que rodasse em dispositivos Android _e_ poderia usar a GPU, mas parece que não há no momento. (Corrija-me se eu estiver errado!)

@krikru
O ramo oficial (mas experimental) do OpenCL Caffe pode ser executado em GPUs Android, mas o desempenho no momento está longe de ser o ideal. Consulte https://github.com/sh1r0/caffe-android-lib/issues/23 e https://github.com/BVLC/caffe/tree/opencl.

Uma alternativa real ao cudnn poderia ser a extensão de objetos padrão OpenVx com suporte aos operadores Tensor, NdConvolution, NdPooling e (provavelmente) algum outro operador que possa ser considerado padronizável.
Além disso, a equipe cudnn precisa fazer algumas escolhas sobre quais novas APIs e operadores serão introduzidas em cada versão. É claro que um padrão não pode se mover tão rápido quanto os lançamentos cudnn, mas acho que algumas operações e objetos têm "histórico de citações" suficiente para serem padronizados.

@hughperkins No momento, não experimentei nenhuma biblioteca de aprendizado profundo; Estou apenas fazendo uma pesquisa para ver qual biblioteca eu poderia usar. Você já tentou cltorch e DeepCL no Android? Eu apenas assumi que o cltorch funcionou no Android, já que existe uma implementação do Torch dedicada especificamente para o Android. E por que você teria essa implementação se já existisse uma que funcionasse no Android _e_ usasse OpenCL, certo? Mas talvez eu devesse saber melhor.

@hughperkins Por algum motivo, imaginei que o torch-android fosse uma implementação oficial do Torch para Android, o que significa que nenhuma outra implementação do Torch (pelo menos não oficial) provavelmente funcionaria sem problemas no Android, incluindo o cltorch. Não sei por que pensei isso, é claro que não faz nenhum sentido.

Bem... Soumith meio que coordena o desenvolvimento da tocha. Ele trabalha no Facebook AI Research. Então, como o repositório do Torch-android pertence à Soumith, eu diria que é bastante próximo do oficial. Mas talvez não faça parte do núcleo por algum motivo. Acho que você pode fazer a pergunta como um problema nesse repositório ou em https://groups.google.com/forum/#!forum/torch7 Na verdade, já que Soumith é a principal pessoa que lida com as solicitações em https: //groups.google.com/forum/#!forum/torch7 , acho que você provavelmente deseja postar sua pergunta lá.

significando que nenhuma outra implementação do Torch (pelo menos não oficial) provavelmente funcionaria sem problemas no Android, incluindo cltorch

Observe que cltorch não é um implementatino de torch. É um plugin, que fornece OpenCL. Você precisa de ambos.

Observe que cltorch não é um implementatino de torch. É um plugin, que fornece OpenCL. Você precisa de ambos.

Ah, obrigado pelo esclarecimento.

@naibaf7 A ramificação do OpenCL Caffe e a implementação do OpenCL Caffe da AMD têm algo mais em comum além do nome? Já comparou os dois ou sabe se há alguma diferença no desempenho? Você escreve que a ramificação OpenCL está longe do desempenho ideal. O que isso significa e o que seria necessário para melhorá-lo? Seria interessante experimentá-lo no Android.

Estamos saindo do tópico

@bhack Sim, desculpe por sequestrar este tópico. Só não sabia onde fazer a pergunta.

@krikru
por favor, levante um problema sobre isso no ramo Caffe, sinalize-o com Android e OpenCL. Então podemos discutir isso melhor. Obrigado.

@keryell Parece que a próxima reunião f2f SG14 em março será organizada pelo Google . Haverá algum tensorflow interno lá?

/cc @jfbastien

Talvez @benoitsteiner possa aparecer, já que ele é local.
Mas antes deste evento há o C++ F2F completo no final do mês em Jacksonville, Flórida.
https://isocpp.org/files/papers/N4568.pdf
Infelizmente não poderei comparecer a nenhum deles.

Não sei se o CppCon 2015 talk C++ Multi-dimensional Arrays for Computational Physics and Applied Mathematics gerou algum acompanhamento de papel.

+1

@bhack Obrigado por apontar a palestra sobre matrizes multidimensionais. É interessante e aborda os problemas reais, mas parece muito ad-hoc para ser ratificado em C++ como está. Pessoalmente eu uso Boost.MultiArray e estou mais confiante em uma versão polida do Boost.MultiArray.

Há também alguns trabalhos no WG21 . Como você pode ver, @jfbastien do Google tem alguma atividade no WG21 e também ajudou a sediar a reunião SG14 f2f no Google em março.

@bhack @keryell Acho que valeria a pena levar essa discussão para a lista de discussão SG14, pois os detalhes não estão relacionados ao OpenCL / tensorflow.

Sim, provavelmente não é mais tão estritamente confinado aqui com todos os detalhes. Além do suporte Eigen/sycl Existe um plano para as chamadas cudnn?

+1 tópico muito interessante. Espero que em breve.

Este tópico é muito interessante. Eu tenho tentado fazer o caffe funcionar no Android. Os resultados parecem ser surpreendentes: caffe rodando com Mali gpu parece ser 2-3 mais lento que cpu, mas cerca de 4-5x mais eficiente em termos de energia. O teste foi executado no Galaxy S6 (Mali T760, Peak Performance 200 GFlops).

Como o GEMM é o núcleo da convolução no caffe, decidi traçar o perfil de seu desempenho no Android. Parece que o ViennaCL não é tão eficiente quanto alguns kernels simples. Agora posso fazer com que a GPU funcione tão rápido quanto a CPU para matrizes grandes (2k x 2k). Isso ainda é contra-intuitivo, já que normalmente esperamos que as GPUs sejam muito mais rápidas.

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

As implementações do kernel podem ser encontradas aqui:

Kernels OpenCL para GEMM: https://github.com/strin/gemm-android

Alguma ideia?

@strin Você já seguiu este tópico https://community.arm.com/thread/4935?

@bhack obrigado por compartilhar. este tópico parece muito interessante. tentei desligar o DVFS como sugerido, mas nenhum desempenho significativo foi visto para sgemm em ViennaCL.

+1

@strin Você tentou a última versão do sgemm no MALI SDK?

Tensorflow está atrasado! ahah
https://gist.github.com/jarutis/ff28bca8cfb9ce0c8b1a

Isso terá impacto na estratégia: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
EDITAR:
"Atualmente, o StreamExecutor é usado como tempo de execução para a grande maioria dos aplicativos GPGPU internos do Google, e um instantâneo dele está incluído no projeto TensorFlow_ de código aberto, onde serve como tempo de execução GPGPU."

+1

Espero que as pessoas que trabalham nele consigam superar o problema alternativo CUDNN quando o tensorflow chegar perto de 1.0

@martinwicke por que esses problemas estão encerrados?

Eu não acho que seu commit corrige isso.

Você nem sempre pode usar os mesmos comentários de commit em repositórios diferentes ;) https://github.com/tensorflow/skflow/issues/22

Oh GitHub

@vrv Agora que você nos notificou, você pode dar algum feedback sobre a estratégia do executor de stream? ;)

Vou culpar o GitHub por tudo, incluindo a falta de suporte a OpenCL. ;)

@benoitsteiner pode comentar mais. Eu realmente não sei o que você quer dizer com estratégia de 'executor de fluxo'. Atualmente, usamos uma versão do executor de fluxo e CuDNN e Eigen e todos eles funcionam bem juntos, então não tenho certeza de como os planos mudaram para o lado OpenCL das coisas

Quero dizer:
"O que é StreamExecutor?
========================
StreamExecutor é um wrapper unificado em torno dos modelos de programação do lado do host CUDA e OpenCL (tempos de execução). Ele permite que o código do host seja direcionado a dispositivos CUDA ou OpenCL com kernels de dados paralelos de funcionamento idêntico."

Operações enlatadas
==================
O StreamExecutor fornece vários kernels predefinidos para operações comuns de dados paralelos.
As classes de operações suportadas são:

• BLAS: subprogramas básicos de álgebra linear,
• DNN: redes neurais profundas,
• FFT: transformadas rápidas de Fourier, e
• RNG: geração de números aleatórios.

@keryell Olá, também tenho interesse em implementar o TensorFlow em FPGA, usando linguagens de programação de alto nível como Xilinx C++ ou OpenCL. Tenho o prazer de contribuir se você tiver algum plano.

@henline Você pode explicar qual será o papel do StreamExecutor no Opencl e do Canned relevante
operações para Tensorflow. Ainda não consigo ver como isso se integrará aos planos SyCL em Eigen e cudnn (substituição?)

:+1: Eu gostaria de contribuir para isso também.

@bhack StreamExecutor fornece funcionalidade equivalente ao runtime CUDA e algumas das bibliotecas CUDA (como cublas ou cudnn). No entanto, você ainda precisa escrever seus kernels de GPU, para o que usamos o Eigen.

@benoitsteiner Então ainda é necessário escrever dois kernels, um para CUDA e outro para Opencl?

@benoitsteiner Então você ainda não tem uma contraparte tensorflow/tensorflow/stream_executor/opencl/ internamente? E quanto aos "Operadores enlatados"?

@bhack Eigen permite que você escreva uma expressão que descreva a computação que você deseja realizar uma vez e gere automaticamente um kernel (que chamamos de avaliador) para avaliar essa expressão na CPU e outro kernel para avaliar a expressão em um dispositivo CUDA. Assim que tivermos suporte para OpenCL no Eigen (estamos chegando perto), será possível também gerar o kernel OpenCL automaticamente.
Para algumas operações do TensorFlow que são críticas para o desempenho (como convolução), usamos kernels otimizados manualmente e/ou bibliotecas de terceiros. Nesses casos, precisaremos de uma boa implementação OpenCL dessas operações.

:+1:

Existe um plano para enviar mais código em https://bitbucket.org/benoitsteiner/eigen-opencl? E quanto ao compilador sycl? Parece que não há implementações de destino de GPU de código aberto lançadas.

@bhack @benoitsteiner
Em breve estou lançando uma substituição cuDNN (apenas a parte de convolução, pois é a mais crítica de desempenho e memória para fazer isso) para OpenCL no Caffe. Talvez também seja útil para a porta do Tensorflow.

@bhack : O codeplay fez muito progresso na frente do opencl. Fique atento para um grande empurrão para https://bitbucket.org/benoitsteiner/eigen-opencl nas próximas semanas.

@naibaf7 : Uma implementação rápida da operação de convolução seria extremamente útil no TensorFlow. Ansioso para isso.

@benoitsteiner Boa pegada, eles pegaram a cadeira

@benoitsteiner Como posso simplesmente remover a implementação do cuda? porque '#ifdef GOOGLE_CUDA' é muito complicado. Às vezes significa CUDA, às vezes significa GPU.

Como esse problema chegou ao roteiro (consulte _Platforms_): temos uma ideia aproximada de quando o suporte a OpenCL atingirá o TensorFlow? Gostou da versão 0.9/1.0? Q3/4 2016? Ou 2017 é mais realista?

@benoitsteiner O eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl está pronto o suficiente para suportar um desenvolvimento de fluxo de tensor opencl?

O tensorflow depende apenas de tensores Eigen ou existem outras dependências de Eigen?

@NEELMCW Codeplay acaba de lançar suporte parcial para OpenCL para Eigen Tensors. O código está disponível neste repositório bitbucket . Na maior parte, o TensorFlow depende dos tensores Eigen. Existem dependências adicionais no Eigen para as operações de álgebra linear, mas não precisamos fornecer uma implementação compatível com OpenCL dessas operações (pelo menos não inicialmente). Portanto, estamos em uma posição muito boa para começar a oferecer suporte ao OpenCL no TensorFlow.

Caso tenha interesse em contribuir, comecei a acompanhar o que precisa ser feito nesta planilha

@benoitsteiner Eu sou o autor de uma biblioteca C++11 OpenCL BLAS (https://github.com/CNugteren/CLBlast) e atualmente estou implementando suporte de meia precisão lá. Fico feliz em contribuir com a parte BLAS/GEMM deste projeto e/ou modificar o CLBlast para atender melhor às suas necessidades.

@CNugteren
O CLBlast agora também está disponível no OpenCL-Caffe, você já viu isso? :)
Você também teve a chance de ver as convoluções do libDNN?

@naibaf7 eu vi, sim! :) Eu não olhei para libDNN até agora, mas não tenho certeza do que você quer dizer exatamente. Presumo que a convolução seja implementada usando o GEMM?

@CNugteren
Sim, eu apenas pensei que seria bom se você pudesse dar uma olhada e talvez dar algumas dicas de melhoria ou ajuste no libdnn.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Ele está usando GEMM, mas implícito (não através de um BLAS, apenas pequenos GEMMs em um nível de grupo de trabalho) para que um nível mais alto de paralelismo seja possível, assim como nenhum buffer intermediário é necessário (para desenrolar os dados em um esquema GEMM).

Olá a todos,

@benoitsteiner obrigado por mencionar nosso empurrão! Espero que seja util!

Para compilar este código, você precisa de um compilador SYCL. Atualmente, o único compilador suportado é o ComputeCpp do Codeplay, que está disponível através de um programa de avaliação do Codeplay. O ComputeCpp será disponibilizado gratuitamente como uma versão beta pública aberta no final de 2016 e, em seguida, lançado com uma versão gratuita (o ComputeCpp Community Edition) em 2017. Isso permitirá que qualquer pessoa compile e desenvolva o TensorFlow em dispositivos OpenCL, como GPUs AMD ou Intel e CPUs.

por falar nisso. este problema não deveria ter o rótulo OpenCL? :)

Obrigado,
Lucas

Eu realmente espero que isso possa ser compilado também com uma ferramenta de código aberto. @keryell como está indo com sua nova ramificação Opencl

@bhack Seria bom ver se ele pode funcionar com triSYCL no modo de dispositivo host CPU OpenMP primeiro. Mas não tenho largura de banda para entrar no sistema de compilação TensorFlow/Eigen agora. :-( Se alguém quiser tentar, sinta-se à vontade para fazê-lo. :-)

https://github.com/keryell/triSYCL/commits/opencl deve permitir a execução de kernels OpenCL em breve no modo de interoperabilidade OpenCL, mas não no modo de fonte única SYCL com o qual todos sonhamos porque ainda não temos o delineador Clang/LLVM para extrair os kernels de SYCL. Mas a Khronos abriu recentemente os componentes da AMD e Intel para suportar OpenCL C++ 2.2 e SPIR-V que seriam a base disso. Então é "só" uma questão de tempo...

Alguém poderia fornecer estimativas de quando o Tensorflow poderá ser executado com OpenCL (GPUs AMD)? E como é a curva de desempenho/usabilidade ao longo do tempo? É difícil analisar todas as informações anteriores em informações de compra de hardware acionáveis. :)

Desde já, obrigado!

@djan92
Eu diria para dar um ano até que seja utilizável, infelizmente. Parece que será construído em bibliotecas e tecnologias de ponta, a maioria delas ainda não prontas.
Eu também só vou embarcar assim que a pilha de ferramentas completa estiver disponível como OpenSource e não antes.

@naibaf7

Eu diria para dar um ano até que seja utilizável, infelizmente. Parece que será construído em bibliotecas e tecnologias de ponta, a maioria delas ainda não prontas.
Eu também só vou embarcar assim que a pilha de ferramentas completa estiver disponível como OpenSource e não antes.

Por que não implementar uma versão CL primeiro enquanto espera que a porta SYCL esteja pronta? Imagino que haja algumas pessoas aqui dispostas a ajudar. Um ano soa muito longo.

@djan92
Sim, você está certo, o número 22 tem quase 8 meses e tem mais de 100 posts! A informação pode ficar inundada!

Alguém poderia fornecer estimativas de quando o Tensorflow poderá ser executado com OpenCL (GPUs AMD)?

O TensorFlow usa a biblioteca Eigen para computação de tensor (no módulo Tensor). Confirmamos uma implementação parcial para OpenCL 1.2 usando SYCL (https://bitbucket.org/benoitsteiner/opencl branch Codeplay). A razão pela qual usamos SYCL para este trabalho é que esta seção do TensorFlow usa árvores de expressão C++, o que é possível com SYCL para OpenCL, mas não é possível com OpenCL C diretamente. Outros componentes do TensorFlow, como convoluções ou BLAS, podem usar o OpenCL C diretamente.

Atualmente, estou trabalhando na integração do ComputeCpp (compilador SYCL da Codeplay) no sistema de compilação do bazel. Isso deve estar pronto em breve ( siga este repositório: https://github.com/benoitsteiner/tensorflow-opencl/ ). Feito isso, o TensorFlow deve ser acelerado em sistemas que suportem OpenCL SPIR (como AMD ou Intel) com ComputeCpp. O trabalho adicional continuará para acelerar mais o TensorFlow, além de oferecer suporte a mais implementações de OpenCL e o SYCL de código aberto triSYCL. SYCL e OpenCL são padrões abertos de vários fornecedores e isentos de royalties, portanto, há muitas plataformas e dispositivos que podem ser suportados usando essa abordagem (não apenas GPUs AMD).

O compilador ComputeCpp Community Edition estará disponível gratuitamente no final de 2016 (em forma beta: a conformidade total será liberada gratuitamente no início de 2017).

O trabalho de aceleração das partes não C++ do TensorFlow (por exemplo, BLAS e convoluções) pode ser feito sem SYCL e implementado separadamente. Diferentes fornecedores de hardware podem ter suas próprias bibliotecas otimizadas para esses recursos que podem ajudar na aceleração. Ou poderíamos usar Eigen com C++ para esses recursos.

E como é a curva de desempenho/usabilidade ao longo do tempo?

Acreditamos que o desempenho melhorará de forma constante. Para acelerar em uma ampla variedade de dispositivos, precisamos gerenciar os dados com mais eficiência, e é por isso que existe um item de trabalho "tensor gerenciado", para que a movimentação de dados possa ser gerenciada com mais eficiência entre o host e vários dispositivos. É difícil prever como o desempenho irá variar em uma ampla gama de dispositivos, agora. Atualmente, muito pouco é acelerado, mas estamos implantando a infraestrutura para permitir a aceleração de padrão aberto no TensorFlow.

@naibaf7

Eu diria para dar um ano até que seja utilizável, infelizmente.

As operações básicas devem estar aqui muito em breve. Estamos implementando a infraestrutura básica dentro do código para dar suporte à aceleração baseada em padrões abertos. Acreditamos que com o suporte da comunidade, uma versão acelerada e utilizável estará pronta em muito menos de um ano.

Eu também só vou embarcar assim que a pilha de ferramentas completa estiver disponível como OpenSource e não antes.

O ComputeCpp estará disponível publicamente, gratuitamente, em 2016. O suporte triSYCL de código aberto deve seguir atrás. OpenCL de código aberto já é suportado com pocl, Shamrock, Clover, Beignet.

@robertwgh
O código tensor C++ em Eigen não seria facilmente portátil para OpenCL C sem SYCL, mas existem outros recursos que funcionariam bem em OpenCL C. Dê uma olhada nesta planilha: https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 e preencha gratuitamente coloque seu nome nos recursos que devem usar OpenCL C normal (como BLAS e convoluções).

Estamos dando versão de avaliação para ComputeCpp antes do lançamento público. Se quiser, me mande um e-mail :)

@lukeiwanski Ótimo, obrigado pela atualização. Espero que você esteja certo sobre fazê-lo com todos os recursos em menos de um ano.

Outra etapa do Streamexecutor no LLVM

alguma chance de obter aceleração no rx 480?

@benoitsteiner
LibDNN autônomo estaria disponível para integração:
https://github.com/naibaf7/libdnn

Ótimo ler isso está sendo trabalhado. Ajudaria se o Beignet 2.0 fosse polido. Muito potencial com Skylake e Iris agora.

Uma solicitação de pull recente foi adicionada em https://github.com/benoitsteiner/tensorflow-opencl/pull/1 se alguém quiser dar uma olhada.

O SDK OpenCL da Imagination(GPU) precisa de NDA para ficar acessível, só temos a biblioteca compartilhada. É possível executar o tensorflow com base nessas bibliotecas?

@alephman
Você não precisa de arquivos de cabeçalho específicos do fornecedor para construir qualquer programa OpenCL. Experimente cl.hpp de https://www.khronos.org/registry/cl/api/1.2/cl.hpp e opencl.h/cl.h de qualquer outro SDK. Por exemplo - eu tenho pelo menos 3 plataformas OpenCL e tudo funciona com um compartilhado /usr/include/CL/cl.h

Ainda não oferecemos suporte ao TensorFlow em execução no OpenCL. É um trabalho em progresso. Atualmente estamos trabalhando em GPUs AMD. O suporte do PowerVR deve seguir. Se você quiser contribuir para o desenvolvimento, entre em contato conosco (Codeplay) diretamente. Se você deseja executar o TensorFlow no PowerVR, aguarde um pouco mais de progresso.

@inferrna obrigado, parece semelhante ao OpenGL que oculta a implementação do fornecedor específico.

@andrewrichards Adoro contribuir com o desenvolvimento, como entrar em contato com você?

O mais fácil é clicar em "registrar seu interesse" em nossa página aqui: https://www.codeplay.com/products/computecpp
Isso fará com que você entre em nosso programa de desenvolvedor e possamos trabalhar juntos neste @alephman

Se você quiser, pode contribuir também para deixar compilar com uma alternativa de código aberto. Consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment -221841173

Olá a todos!
Muito feliz em saber que o suporte do Tensorflow está sendo estendido para fora da Nvidia Cuda. Gostaria de saber se você também considera fazê-lo funcionar em APUs como este: http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
As APUs suportam OpenCL para a parte de CPU e GPU.
Isso deve funcionar muito bem quando o suporte a OpenCL estiver pronto.
Enquanto isso, se você já possui uma APU e deseja experimentar outro framework de ML, o BVLC OpenCL Caffe já funciona.

@naibaf7 Obrigado pelo esclarecimento. Estou procurando combinações de hardware/software econômicas para executar o Tensorflow localmente e definitivamente acompanharei o progresso do desenvolvimento do OpenCL.

@hughperkins
Sim, pode ser um problema, mas acho que partes como im2col/col2im e outras implementações de convolução também podem ser conectadas como APIs externas se for realmente um problema com o GCLA. Isso também pode ser melhor para os autores originais de tal trabalho.

@hughperkins Estamos trabalhando para trazer o OpenCL para o TensorFlow por meio do SYCL para OpenCL 1.2.
Consulte https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 para "todos" e progresso.
Recentemente, lançamos um compilador para SYCL https://www.codeplay.com/products/computesuite/computecpp chamado ComputeCpp Comunity Edition. As pessoas podem experimentar!
Além disso, estamos nos concentrando na biblioteca Eigen https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp - levando-a ao estágio exigido pelo MNIST do TensorFlow - restam algumas coisas.
Quanto às restrições, a versão atual do ComputeCpp CE foi testada para Intel (CPU, GPU) e AMD (CPU, GPU) quanto às plataformas que suportamos Ubuntu 14.04 64bit e CentOS 64bit.
O ComptuCpp pode ser baixado gratuitamente e pode ser usado em projetos comerciais e de código aberto.
Porque nós <3 comunidades abertas :)

@lukeiwanski Desculpe por discutir/perguntar isso aqui no tópico, mas acho que pode ser do interesse de outros também: eu entendo que a Codeplay está muito interessada na implementação do SYCL para OpenCL e já ouvi outros interessados ​​neste trabalho de você também. Eu li algum post de um funcionário da Movidius, por exemplo. No entanto, gostaria de perguntar qual é realmente a contribuição do Google para isso? Como a Movidius, além da AMD e outras, estão listadas como parceiras da Codeplay, posso entender que elas incentivam ou até apoiam SYCL para OpenCL, mas pelo que sei, o Google não é seu parceiro e não contribuiu até agora?!

Não me entenda mal, gosto muito do seu trabalho, mas não seria uma boa ideia consolidar seus esforços, reunir os recursos e tentar trabalhar em conjunto com o Google? Para mim, parece que muitas partes diferentes estão interessadas no OpenCL para TensorFlow, mas um potencial enorme não é usado, porque essas partes não se desenvolvem juntas?!

Posso estar errado e peço desculpas se isso foi discutido o suficiente, mas ainda não tenho conhecimento de nenhuma tentativa importante do Google (ou de outras partes) de trabalhar em conjunto sobre isso e, como resultado, ainda não tenho conhecimento de como a comunidade poderia ajudar ou apoiar (como indivíduos solteiros), seja por meio de contribuições diretas, testes ou outras coisas.

@ascenator Nós do Google estamos trabalhando em estreita colaboração com Luke e seus colegas do Codeplay neste projeto há quase 12 meses. A contribuição do Codeplay para esse esforço foi tremenda, então sentimos que deveríamos deixá-los assumir a liderança quando se trata de comunicar atualizações relacionadas ao OpenCL. É por isso que você não ouviu muito de nós sobre o assunto :)

Agora que o compilador ComputeCpp está amplamente disponível, estamos planejando mesclar o trabalho que foi feito até agora. Mas primeiro queremos montar uma infraestrutura de teste abrangente para garantir que não desestabilizemos a base de código existente.

Congratulamo-nos com todas as contribuições para este esforço, portanto, sinta-se à vontade para entrar em contato comigo se quiser ajudar. Estamos especialmente interessados ​​em kernels OpenCL de alto desempenho para multiplicação e convoluções de matrizes. Vários candidatos foram sugeridos, mas ainda não começamos a analisar os prós e os contras de cada um ou como integrá-los.

@benoitsteiner muito obrigado pelo esclarecimento e desculpe pela minha desinformação! Isso soa muito bom e promissor! Eu definitivamente vou dar uma olhada no ComputeCpp então. Estou realmente ansioso pelo suporte OpenCL para TensorFlow, porque isso oferece muitas novas possibilidades para robótica (que é o campo em que estou pesquisando e usando o TensorFlow para aplicativos de aprendizado profundo). Vou pelo menos dar uma olhada nas versões iniciais e tentar testar/depurar. Temos alguns chips Intel e vários processadores ARM que estão aguardando testes ;)

@hughperkins ... desculpe, mas isso não está completamente fora do tópico aqui? Não vejo como isso é relevante no OpenCL TF?

Estou mais interessado aqui em saber se será feita uma abordagem de ajuste para os kernels de multiplicação e convolução de matrizes e se será uma alternativa de código aberto válida ao CompiteCpp que produzirá o SPIR-V.

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

Dois novos padrões do Grupo Kronos são lançados em https://www.khronos.org/news/press/khronos-launches-dual-neural-network-standard-initiatives

Se isso ajudar, uma versão melhor do isaac está disponível: https://github.com/ptillet/isaac , e fornece acelerações significativas sobre clBLAS e cuBLAS em Maxwell, Pascal e Fiji. Também fornece kernels mais rápidos (com reconhecimento de entrada) do que o Tensorflow para reduções 1D e 2D.

@hughperkins parece que você tem mais chances de escrever o compilador CUDA para qualquer dispositivo OpenCL, em vez do tradutor CUDA-OpenCL.

@hughperkins Talvez o recurso SVM do OpenCL 2.0 possa resolver o problema do ponteiro? Como todos além da Nvidia (AMD, Intel, ARM, Qualcomm) estão começando a oferecer suporte ao OpenCL 2.0. Talvez seja uma boa solução?

@hughperkins é uma implementação blas em si. Ele implementa alguns dos símbolos nos cabeçalhos clblas e cublas para que não haja recompilação e modificação de código. é necessário. Eu também poderia implementar alguns dos símbolos para clblast.h, já que ele usa um cabeçalho diferente. Algumas vantagens de Isaac são:

• Totalmente dinâmico, para que possa usar CUDA ou OpenCL sem recompilação.
• Input-aware , ele não ajusta kernels para grandes matrizes quadradas. Ele deve ter um bom desempenho em todas as formas que você possa imaginar sem reajustar.
• API C++ semelhante a numpy/arrayfire. Alguma fusão para combinar operação elementar com reduções

@marty1885
Na verdade. A AMD voltou ao suporte 1.2 nos drivers AMDGPU-PRO. Pode demorar um pouco até que o suporte 2.0 completo seja generalizado. Definitivamente não é uma solução de curto prazo lá.

• sim
• Eu poderia hackear a compatibilidade para várias operações, se necessário (por exemplo, encaminhar **MV para GEMV). Suporte complexo será complicado. O suporte duplo já está aqui, mas nenhuma arquitetura está ajustada para isso.

@hughperkins

Parece que meu código não viola nenhuma regra OpenCL óbvia

Sim, passar claramente qualquer estrutura __global (como array ou struct) contendo ponteiros é incorreto apenas porque esses ponteiros podem apontar para a memória de outro dispositivo (OpenCL suporta o paradigma de vários dispositivos em que um dispositivo não pode acessar a memória de outro). Mas parece ser possível superar no nível IR, sem tradução intermediária para código OpenCL - foi o que eu assumi :)

@benoitsteiner , @henline , do https://github.com/henline/streamexecutordoc , sugere que o streamexecutor suporte a operação enlatada da versão CL (como DNN, BLAS) pronta para uso. Isso sugere que o google já tem a implementação clDNN, clBLAS pronta para o Tensorflow, mas ainda não é de código aberto?

Caso contrário, OpenCL 2.0+ e SYCL 2.2 suportam SVM, se você quiser manter a mesma arquitetura de software.
OpenCL 2.0+ é suportado por GPU AMD e Intel, por exemplo. No mundo incorporado, muitas vezes é suportado pelo efeito colateral mesmo com OpenCL 1.x, uma vez que as memórias do host e do dispositivo são geralmente as mesmas por motivos de custo.

@keryell
Mas as plataformas mais notáveis, Linux + as novas GPUs AMD (RX 480, vindoura Vega) só suportam OpenCL 1.2 por enquanto... e quem sabe quando isso vai mudar (minha aposta é daqui a um ano). Beignet (opensource Linux Intel) para OpenCL 2.0 também ainda é uma bagunça cheia de bugs; a versão estável tem 1.2.
Considerando também que todas as empresas menores que fabricam chips compatíveis com OpenCL mal estão recebendo suporte 1.2. Então, acho que qualquer coisa que dependa do OpenCL 2.0 verá taxas de adaptação muito ruins na prática.

Acho.. algum fornecedor de hardware tem a urgência de consumir SPIR-V? Eu acho que a pressão de Graphic/Shaders no Vulkan poderia ajudar o lado da Opencl..

@naibaf7 para voltar à discussão sobre OpenCL 2 ou não, em algum momento as coisas reais têm que ser entregues... Caso contrário já existe GPU nVidia e CUDA com TensorFlow rodando... :-)
Mas é claro que uma versão do TensorFlow sem SVM tem algum interesse.

@keryell Quanto do Vulkan SPIR-V funciona em drivers (que já têm uma boa cobertura de dispositivos) você acha que impulsionará as versões modernas do Opencl?

@naibaf7 A reunião do Khronos é na próxima semana em Seul com o pessoal da OpenCL e Vulkan, mas as discussões não são públicas. Mas parece uma boa ideia ter cada mundo para melhorar o outro e, em algum momento, beneficiar o TensorFlow. :-)

@keryell
Sim, espero que eles discutam algumas coisas benéficas do DeepLearning :)

Parabéns! Certifique-se de verificar o projeto HIP, pois eles tentaram resolver o mesmo problema. Eles escolheram criar uma nova linguagem chamada HIP, que define o que precisa ser convertido manualmente (como verificar o suporte de precisão dupla verificando o nível de computação). Enquanto o projeto avança, a quantidade de traduções manuais diminuiria. Veja: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

Minha sugestão para você é usar o HIP e corrigir alguns bugs que estão bloqueando o avanço do Tensorflow ou seus próprios objetivos, pois agora você tem o entendimento do LLVM para fazer isso. Dessa forma, você não precisa resolver os problemas que eles já corrigiram.

@hughperkins
não é possível compilar o módulo python com seu fork seguindo este 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.

Estou no Ubuntu 16.04, dirname é de coreutils-8.25-2ubuntu2

@hughperkins Acho que ajustar o dockerfile do TF em seu repositório com essas instruções pode facilitar a configuração para outras pessoas.

Sim, quando haverá algo mais funcional. Basicamente, é uma cópia e passado dessas instruções que você postou.

Estou experimentando construir isso no MacOS 10.10.5 em um MacBook no final de 2015 com ATI 6770M (OpenCL 1.2).

Instalei Xcode 8, Anaconda (Python 3.5) e MacPorts equivalentes de clang+llvm:

em vez de linhas apt-get, faça:

sudo port install clang-3.8 llvm-3.8

Em vez de usar /proc/cpuinfo, faça:

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

Em seguida, modifique o Makefile para usar macports e execute 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

atualização para diretórios Macos OpenCL; futuro: use /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' condicional

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

Isso é até onde eu recebo:

$ make -j ${NUM_PROCS}
mkdir -p compilação
mkdir -p compilação
mkdir -p compilação
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/hostside_opencl_funcs.o -std=c++11 -fPIC -g -O2 -I pwd /include -I pwd /src/EasyCL src/hostside_opencl_funcs.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/mutations.o -g -I/opt/local/libexec/llvm-3.8/include src/mutations.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/struct_clone.o -g -I/opt/local/libexec/llvm-3.8/include src/struct_clone.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -c -o build/readIR.o -g -I/opt/local/libexec/llvm-3.8/include src/readIR.cpp
No arquivo incluído em src/hostside_opencl_funcs.cpp:17:
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: aviso: atributo 'host' ignorado [-Wignored-attributes]
attribute ((host)) inline unsigned long long atomicExch(volatile unsigned long long _p, unsigned long long val) {
^
src/hostside_opencl_funcs.cpp:194:33: erro: a chamada para a função de membro 'in' é ambígua
launchConfiguration.kernel->in(offset);
~~~~~~~~ ^ ~ _ _
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15: nota: função candidata
CLKernel in(valor flutuante);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15: nota: função candidataCLKernel *in(int32_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15: nota: função candidataCLKernel *in(int64_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15: nota: função candidataCLKernel *in(uint64_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15: nota: função candidataCLKernel *in(uint32_t value);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15: nota: função candidata não viável: nenhuma conversão conhecida de 'size_t' (também conhecido como 'unsigned long ') para 'easycl::CLArray *'para 1º argumentoCLKernel *in(CLArray *clarray1d) { return input(clarray1d);



}^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36: nota: modelo de função candidato não viável: requer 2 argumentos, mas 1 foi fornecidomodeloCLKernel *in(int N, const T *dados);^1 aviso e 1 erro gerado.make: *_* [build/hostside_opencl_funcs.o] Erro 1fazer: * * Aguardando trabalhos inacabados....
src/struct_clone. cpp:245 :12: aviso: 11 valores de enumeração não manipulados no switch: 'HalfTyID', 'X86_FP80TyID', 'FP128TyID'... [-Wswitch]
switch(typeID) {
^
1 aviso gerado.

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

Este patch funcionou. Obrigada.

Depois de aplicar isso, continuar a compilação resultou em erros de namespace size_t:

$ make -j ${NUM_PROCS}
mkdir -p compilação
mkdir -p compilação
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/hostside_opencl_funcs.o -std=c++11 -fPIC -g -O2 -I pwd /include -I pwd /src/EasyCL src/hostside_opencl_funcs.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -o build/ir-to-opencl -g -I/opt/local/libexec/llvm-3.8/include src/ir-to-opencl.cpp build/struct_clone .o build/readIR.o src/ir-to-opencl-common.cpp build/mutations.o /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_events.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_events.cpp
/opt/local/libexec/llvm-3.8/bin/clang++ -I/usr/lib/llvm-3.8/include -fPIC -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fcxx-exceptions -o build/patch-hostside -g -I/opt/local/libexec/llvm-3.8/include src/patch-hostside.cpp build/readIR.o build/ mutações.o build/struct_clone.o src/ir-to-opencl-common.cpp /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
No arquivo incluído em src/hostside_opencl_funcs. cpp:17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: aviso: atributo 'host' ignorado [-Wignored-attributes]
attribute ((host)) inline unsigned long long atomicExch(volatile unsigned long long _p, unsigned long long val) {
^
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_blas.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_blas.cpp
1 aviso gerado.
/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_error.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_error.cpp
No arquivo incluído em src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:8:9: erro: nenhum tipo chamado 'size_t' no namespace 'std'; você quis dizer simplesmente 'size_t'?
typedef std::size_t cublasStatus_t;
^ ~~
tamanho_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aqui
typedef SIZE_TYPE size_t;
^
No arquivo incluído em src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:17:5: erro: nenhum tipo chamado 'size_t' no namespace 'std'; você quis dizer simplesmente 'size_t'?
std::size_t cublasCreate(cublasHandle_t phandle);^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^No arquivo incluído em src/cocl_blas.
você quis dizer simplesmente 'size_t'?std::size_t cublasDestroy(cublasHandle_t handle);^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^No arquivo incluído em src/cocl_blas.
você quis dizer simplesmente 'size_t'?std::size_t cublasSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^No arquivo incluído em src/cocl_blas.
você quis dizer simplesmente 'size_t'?std::size_t cublasSetPointerMode(cublasHandle_t handle, cublasPointerMode_t mode);^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^No arquivo incluído em src/cocl_blas.
você quis dizer simplesmente 'size_t'?std::size_t cublasGetPointerMode(cublasHandle_t handle, cublasPointerMode_t *mode);^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^No arquivo incluído em src/cocl_blas.
você quis dizer simplesmente 'size_t'?std::size_t cublasSetStream(cublasHandle_t handle, cudaStream_t streamId);^ ~~tamanho_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: nota: 'size_t' declarado aquitypedef SIZE_TYPE size_t;^/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_memory.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_memory.cpp/opt/local/libexec/llvm-3.8/bin/clang++ -c -o build/cocl_device.o -std=c++11 -fPIC -g -O2 -I pwd /src/CLBlast/include -I pwd /include -I pwd /src/EasyCL src/cocl_device.cpp7 erros gerados.make: *_* [build/cocl_blas.o] Erro 1make: * * Aguardando trabalhos inacabados....

Podemos empurrar o log longo no gist para deixar o thread ainda legível?

pergunta: como vocês estão resolvendo a questão dos espaços de endereço?

@hughperkins As especificações SYCL descrevem na seção 5.8 ("Dedução do espaço de endereço")
como uma implementação precisa lidar com diferentes tipos de memória. este
é semelhante ao trabalho anterior feito para PlayStation 3 e descrito em
este artigo: Offload – Automatizando a migração de código para heterogêneoSistemas multicore ou C++ em aceleradores: suportando modelos de programação SYCL e HSA de fonte única usando Clang

espero que ajude.

@hughperkins Posso compilar seu código de repositório tensorflow-opencl para aplicar minha placa ARM? Minha placa ARM tem GPU Imagination que suporta opencl 1.2 .

Eu tropecei neste tópico enquanto procurava por suporte tf/intel.

Tenho um MacBook Pro Intel, como posso ajudar? Eu não conheço c/c++, mas posso seguir as instruções de compilação/compilação/teste e retornar (pastebin) os resultados...

derek$ system_profiler SPDisplaysDataType
Gráficos/Exibições:

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 Obrigado por suas instruções!
Eu tento compilar seu cuda-on-cl na plataforma do braço. Seguindo o guia do seu cuda-on-cl:
Informações da minha placa ARM:
arm64, gcc 4.9 , clang e llvm 3.5, openCL 1.2

* Tenho que usar a versão clang++-3.8? *
git clone --recursive https://github.com/hughperkins/cuda-on-cl
fazer
erro:
clang++-3.8: Comando não encontrado
Eu edito o Makefile assim: CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
então faça novamente:
erro:
src/mutations.h:3:10: erro fatal: arquivo 'llvm/IR/Module.h' não encontrado

tente executar make run-test-cocl-cuda_sample:
make: cocl: Comando não encontrado

@hughperkins deixe-me tentar.

Erro ao testar keras com tensorflow

keras$ KERAS_BACKEND=tensorflow pytest3

Erros de saída:

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

oi a todos, meu nome é ricardo , sou um programador C++ com muitos anos de experiência em C++, e pouco em Cuda, ficarei feliz em contribuir para este esforço. Como posso contribuir para este trabalho?

Ok, eu tenho um Odroid Xu3 com um Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 e OpenCL 1.1 Full profile)
rodando no SO: LUbuntu 1404 64 bits
Farei uma instalação completa e postarei o resultado nesta plataforma.
Sobre bugs, existe uma lista de bugs (algo como Bugzilla?) ou uma planilha com uma lista de bugs?
Saúde!

Que tal usar o 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
"Seu desejo está sendo atendido, Eigen está sendo portado sobre GPU AMD via HIP. A segunda parte de sua solicitação é que podemos trazer uma ferramenta padronizada de suporte ao FLOAT16 que vem com todas as nossas GPUs GFX8, desejo concedido."
Nosso ramo de desenvolvimento do compilador AMDGPU agora suporta as instruções nativas Float16 e Int16, em vez de emular FP16/Int16 com instruções up convert e down convert para converter de FP16/Int16 para Float e vice-versa.

Este é o teste f16 em hardware de Fiji executando com sucesso uma multiplicação de matrizes com meios tipos com conversão e com instruções nativas."

Além disso, não relacionado, mas você deve usar syCL/openCL 2.0 em vez de 1.2, porque a nvidia já é suportada via CUDA. E o openCL 2.0 é compatível com os drivers AMD e Intel Windows. Além disso, a AMD disse que em breve abrirá o código aberto do driver openCL 2.0 para Linux (que pode ser usado pela Intel, magia de código aberto) (e a Intel já tem uma implementação Linux openCL 2.0 que só precisa de amadurecimento.) se você perguntar à Intel e AMD, talvez eles poderiam acelerar o trabalho, porque o tensorflow é importante para seus interesses econômicos. E eles já disseram nesta seção de comentários que queriam ajudar. Além disso, todos os principais fabricantes de ARM suportam o openCL 2.0. Isso pode abrir muitas oportunidades para o Android (que é do interesse econômico do Google), como framboesa, TVs inteligentes, etc.

E no médio prazo poderíamos desenvolver uma camada de fallback opencl 1.2 para hardware não suportado.
E a implementação deve usar também openVX (que agora é suportado por todos os principais fabricantes de hardware, e a AMD tem uma implementação de código aberto) e com https://www.khronos.org/news/press/khronos-launches-dual-neural-network -iniciativas-padrão
E tudo com Spir-V (que pode ser usado simultaneamente por Vulkan e openGL).
Pode-se dizer que estou fazendo uma duplicata do que já foi dito, mas sintetizar é importante.
E, finalmente, o tensorflow poderia usar o HSA?

http://www.hsafoundation.com
HSA seria incrível no Android.

Eu não sei se HIP seria útil ou não. Ele é suportado apenas em algumas placas AMD, então precisamos de uma implementação OpenCL de qualquer maneira se quisermos oferecer suporte a todos os dispositivos. Ainda pode valer a pena se a implementação do HIP for notavelmente mais rápida. Este pode ser o caso, mas ainda não vi muitos benchmarks (HIP vs. OpenCL). Outra razão pode ser o MLOpen (que está escrito em HC) como um substituto para cudnn, mas novamente não tenho ideia de quão rápido é ou quais recursos ele suporta.

O TensorFlow não usaria o HSA diretamente porque é de nível bastante baixo. Mas HC (e HIP) é implementado em cima dele e você também pode implementar OpenCL em cima de if (pocl faz isso).

O algoritmo do relooper seria útil aqui? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins É bom ver que você tem algum progresso com seu compilador, mas acho que fica fora do tópico para o TensorFlow. Você deve iniciar muitos tópicos de discussão menores na página do GitHub do seu projeto de compilador. Seria mais focado e produtivo, eu acho.

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

Há também https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Target/JSBackend/Relooper.cpp

Aqui está o artigo associado: https://github.com/kripken/emscripten/blob/master/docs/paper.pdf?raw=true

O suporte inicial a OpenCL/SyCL foi mesclado no master com https://github.com/tensorflow/tensorflow/pull/5267

Parabéns!

@keryell Aliás, o que aconteceu com o repositório triSYCL? Parece ter desaparecido e só consigo encontrar uma referência ao Gitlab de Khronos, que não é acessível publicamente.

EDIT: Encontrei seu clone privado, apenas o da amd desapareceu.

@bhack , o opencl-docker é compatível com a plataforma mac?

@alephman Eu não tenho uma plataforma OSX, mas acho que adaptar um pouco o comando de inicialização poderia funcionar.

@bhack @alephman : veja meu comentário sobre o mac acima, se você me indicar as instruções de compilação, tentarei

@olesalscheider : sim, triSYCL mudou da AMD para Xilinx https://github.com/Xilinx/triSYCL mas você está certo, a versão no meu espaço de trabalho GitHub também funciona em https://github.com/keryell/triSYCL

Ainda não testamos o triSYCL no TensorFlow. Já existe um grande trabalho de configuração de compilação para fazer apenas para tentar ...

@keryell Qual é o status triSYCL?

O suporte ao Intel beignet opencl 2.0 está quase pronto!
http://phoronix.com/scan.php?page=news_item&px=Beignet-Birthday-CL2

@bhack triSYCL é desenvolvido principalmente na Xilinx agora. Ainda adicionando mais e mais recursos. O compilador de estrutura de tópicos baseado em Clang/LLVM ainda está em desenvolvimento para ter uma experiência completa de fonte única em um dispositivo. Mas o modo de compatibilidade OpenCL, já implementado, tem algum valor também, simplificando as comunicações entre host e kernels com o runtime SYCL fazendo as transferências lentas de acordo com as dependências expressas pelos acessadores.

Meu mac é compatível com OpenCL, então como posso executar meu tensorflow com openCL? Acabei de descobrir que o opencl foi suportado no tensorflow, quando configuro os novos códigos.

@hughperkins não há instrução clinfo no meu mac, o que posso fazer por isso? Mas eu posso compilar o código de teste aqui para opencl com clang e resultar nas seguintes informações:
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

Obrigado @hughperkins , mas acho que tentei o computecpp ontem e parece que o sistema macbook ainda não é suportado pelo computecpp. Então, talvez ficar esperando por novas atualizações seja a única coisa que eu possa fazer (TT). BTW, meu Iris 6100 é de oito gerações, o que é bom para OpenCL 1.2.

@hughperkins sim SYCL 1.2 é a priori para OpenCL 1.2 e SYCL 2.2 é a priori para OpenCL 2.2.
Eu disse "a priori", pois, se você não usar nada que exija o modo de compatibilidade com OpenCL do SYCL, o SYCL realmente não exigirá o OpenCL. Na verdade, o SYCL é um modelo muito genérico para computação heterogênea e pode ser executado em cima de qualquer coisa. Mas é claro que uma implementação real pode exigir OpenCL também.

Olá,

Estou aprendendo/trabalhando com TensorFlow e Keras por enquanto e gostaria de ter o suporte OpenCL funcionando no macOS... Há alguma notícia sobre o trabalho feito no macOS?

Consegui compilar o TensorFlow, mas se eu tentar configurar para OpenCL, ele me pedirá o local do computeCpp 1.2, e não há ComputeCpp para macOS, parece-me.

Olá. De forma alguma um especialista em ML / Tensorflow / ou mesmo OpenCL, mas sou um desenvolvedor gráfico experiente para Mac que deseja desesperadamente um desempenho mais rápido do Tensorflow em sistemas com GPUs integradas e AMD usando bibliotecas integradas e dependências simples :)

Como posso ajudar?

Observando a última falha de compilação no OS X no log do travis @hughperkins - parece que executar 'xcode-select --install' pode resolver? Ele deve vincular novamente o diretório /usr/include. Eu mesmo tive esse problema ao atualizar o Xcode beta para lançamento e tive problemas ao compilar algum código C++.

Parece que o compilador XLA (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) fornecerá geração de código LLVM a partir de gráficos de fluxo de dados. Isso significa acesso muito fácil ao spir-v e, portanto, à API de computação do Vulkan. Com a geração de código resolvida, não consigo imaginar o Google não fornecendo compatibilidade com o Vulkan, devido ao alto número de GPUs integradas não utilizadas em execução no Android.

@hughperkins

Rapidamente: agora estou executando o Inception v3 em uma base de código C++/Object-C personalizada e passando quadros de vídeo decodificados para a rede. Eu não sei o suficiente sobre TF para conhecer necessidades de baixo nível, mas alto nível: carregar modelos, executar sessão, esperar que as coisas funcionem. Eu acho que isso significa 100% de compatibilidade para ser realmente honesto. Eu sei que isso não ajuda em priorizar. Basicamente, o Reconhecimento de Imagem C++ usando TF /InceptionV3 foi meu ponto de partida.

cuda-on-cl em execução no Mac: verifiquei o repositório e posso ajudar a depurar e executar compilações em meus sistemas e verificar os resultados em uma variedade de hardware: tenho acesso a AMD Mac Pros com Dual D700s, Nvidia Mac Laptops e Sistemas de mesa.

Obrigado pelo seu feedback detalhado. Vou monitorar o repositório, tentar acompanhar e tentar ajudar da melhor maneira possível.

Hugh, você pode querer dar uma olhada em http://chrec.cs.vt.edu/cu2cl/ para aprender como algumas funções são mapeadas.

Na minha empresa StreamComputing, temos várias GPUs para teste de construção e benchmarking, que usamos para nossos projetos de clientes. Eu poderia conectar seu Github em nosso Jenkins para fazer uma corrida semanal.

Obrigado pela resposta, vou voltar ao assunto no trabalho esta semana, com roteiros específicos.

Meus casos de uso são em torno da análise de correspondência de texto/sintaxe, usando Gensim e Keras/tensorflow em meus experimentos.

Estou disposto a ajudá-lo para o teste

Eu tenho um PC com Windows com uma placa AMD
Um MBP com uma placa AMD
Um MB com uma GPU integrada Intel

Ei @hughperkins - estou passando pelo teste acima, esta noite, em um AMD R9 390 8GB. Até agora já obtive um resultado diferente; logistic_regression.py treina e não retorna nan . Tão bom! Ele segfaults no final, então vou investigar se o script ou o código cl está com defeito.

Onde devo empurrar meus resultados, onde eles podem ser mais úteis para você?
Talvez possamos obter um "script de teste" padrão que gere um conjunto padrão de resultados que os voluntários possam enviar para você (ou configurar em ICs locais ou qualquer outra coisa)?

py.test é uma solução tão boa quanto qualquer outra; é apenas um pip de distância e isso é parte do processo de instalação de tensorflow qualquer maneira.

No entanto, descobri algumas coisas interessantes desde o início dos meus testes, e elas podem não ser depuráveis ​​usando apenas a saída do Python:

• Chamadas diferentes para o mesmo script podem travar cedo ou "travar" (sem saída, sem progresso, sem resposta a Ctrl-C , o processo precisa ser pkill -9 'd) ou pode travar tarde na parte de validação ou após a conclusão bem-sucedida do script. Falhas (segfaults) podem derrubar o Xorg.
• Os resultados variam aparentemente sem motivo: eu posso chamar um script e fazer com que ele segfault, depois chamá-lo novamente e ele funcionará.
• Travamentos podem ocorrer em partes do código que estavam funcionando literalmente momentos atrás, eu tive um travamento ocorrendo dentro ou após um lote de treinamento, depois que várias centenas de lotes aconteceram com sucesso.

Então, pode ser que haja coisas não resolvidas no lado da GPU e que um bom segfault seja necessário para eliminá-lo? Ainda não sei muito sobre o modelo de GPU ou OpenCL, então não posso contribuir muito aqui. Mas pode ser que a saída de depuração da GPU seja necessária para explorar adequadamente o que está acontecendo.

Além disso, pensei que você estivesse com a AMD do seu github, mas parece que você é um "agente desonesto" fazendo toda essa coisa de CUDA-on-CL em seu próprio tempo. Obrigado sinceramente por liderar isso! Existe alguma maneira que eu e outros podemos contribuir para seus esforços, talvez financiando uma GPU para você? Ou você pode criar um Patreon, fico feliz em me inscrever para uma contribuição mensal para o projeto?

No que diz respeito às GPUs AMD, somos parceiros da AMD. Veja minha mensagem de 8 dias atrás, que você pode ter perdido:

Na minha empresa StreamComputing, temos várias GPUs para teste de construção e benchmarking, que usamos para nossos projetos de clientes. Eu poderia conectar seu Github em nosso Jenkins para fazer uma corrida semanal.

Gostaria de saber se você teria a possibilidade de configurar um servidor CI, que roda em cada commit?

Sem problemas. Eu provavelmente preciso de acesso de gravação ao projeto, para que o Jenkins possa gravar o arquivo de log em um diretório de log de compilação. Acabei de enviar spam para você, para que possamos discutir.

Olá a todos,

Como você provavelmente já viu, um monte de coisas SYCL foram enviadas para o TensorFlow. Ainda não estamos completos e há muito o que fazer. Mas estamos progredindo para chegar lá.

Se você estiver interessado em contribuir ou apenas curioso sobre o estado atual, verifique o detalhamento abaixo.

A infraestrutura
O Google gentilmente doou duas máquinas que estão configuradas para testar o fork do TensorFlow de @benoitsteiner (https://github.com/benoitsteiner/tensorflow-opencl) periodicamente

Ambos têm GPUs AMD:

CL_DEVICE_NAME: Havaí
CL_DRIVER_VERSION: 1912,5 (VM)

e

CL_DEVICE_NAME: Fiji
CL_DRIVER_VERSION: 1912,5 (VM)

Nós da Codeplay estamos procurando dedicar a(s) máquina(s) no próximo ano também. Para melhorar a cobertura de diversidade de dispositivos OpenCL.

Estamos procurando colaboradores nessa frente se alguém estiver interessado em fornecer um servidor de compilação de teste para plataformas relevantes às quais oferecemos suporte.
Atualmente, os requisitos são:
- Ubuntu 14.04
- Drivers OpenCL que suportam SPIR ( Intel CPU / GPU ou AMD GPU )

@VincentSC talvez você possa ajudar com isso?

Testes
Na máquina Fiji ( https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull ) estamos enfrentando 164 falhas.

Na máquina do Havaí ( https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull ), temos 56 falhas.

Estamos analisando a correção dos testes de gradiente com falha e investigando as origens das falhas adicionais na máquina Fiji.

Eigen
Nos últimos meses, implementamos ativamente os recursos necessários ao TensorFlow, incluindo: Remodelagem, Fatiar, Redução Básica etc. Atualmente, estamos implementando a Contração. Uma análise detalhada pode ser encontrada na guia Tensor Eigen de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

TensorFlow
Muitas operações em termos de coeficientes foram implementadas, incluindo Abs, Floor, IsFinite, Log, Pow, Mul, etc., bem como Manipulações de tensores como Reshape, Shape, Identity, Fill etc.
Uma análise detalhada pode ser encontrada na guia TensorFlow Kernels de https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219

Organização
A planilha acima tem várias guias que categorizam os esforços do projeto como: Plano geral, Eigen Tensor, TensorFlow Kernels, Modelos.

Se você quiser se envolver, coloque seu nome ao lado do item em que está trabalhando ou adicione qualquer coisa importante que esteja faltando.
Obrigado,
Lucas

Este roteiro está ativo?

@lukeiwanski Sim, sem problemas. Contacte-nos através de [email protected]

Depois de ler tudo isso, acho que ainda não há uma solução sólida para usar o OpenCL no macOS/OS X? Tentei compilar o Tensorflow C++ com suporte a OpenCL (que suponho que requer ComputeCpp para SYCL 1.2 como alguém apontou).

Olhei em volta e não consegui localizar onde baixar, compilar ou construir a biblioteca SYCL. Está aqui https://www.codeplay.com/ ? Não tenho certeza de como proceder, obrigado...

@dylib Até onde eu sei, ainda não existe um ComputeCpp para macOS. Isso significa que o OpenCL para macOS não está pronto.

Ainda não consigo funcionar no Ubuntu 16.04 com placa AMD e driver de catalisador https://github.com/tensorflow/tensorflow/issues/6497. Existe algum como?

Eu tive que olhar para a saída /usr/local/computecpp/bin/computecpp_info antes de tentar usar o TF compilado com suporte a OpenCL. No meu caso está mostrando

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

agora há 2 opções para executar o TF na GPU:
bom trabalho em número limitado (por fornecedor) de dispositivos, mas CUDA proprietário
trabalho ruim em número limitado (por desenvolvedores do computecpp) de dispositivos e também o computecpp proprietário
Ainda sem suporte a OpenCL.

@inferrna Existe uma seção específica do OpenCL na documentação geral do TensorFlow. Isso será publicado no site tensorflow.org em breve.

@benoitsteiner Qual é o estado atual do suporte a convoluções opencl? Você está planejando aproveitar os kernels existentes diretamente? E as multiplicações de matrizes?

Algum ETA?

Que tal usar o HIP para portar o código CUDA para uma plataforma agnóstica? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Parece que a AMD está trabalhando nisso: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45#issuecomment -269827686

Os back-ends XLA LLVM IR podem ser convertidos em SPIR-V com https://github.com/KhronosGroup/SPIRV-LLVM?

Que tal agora? Eu acho que este pacote pode funcionar na GPU Radeon.

https://github.com/RadeonOpenCompute/ROCm

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

@lukeiwanski O XLA também afetará seu esforço?

As soluções XLA e SYCL são complementares para diferentes situações: SYCL é projetado para fornecer programação e personalização completas. XLA é para otimizar padrões bem definidos em gráficos.

Meu entendimento do XLA é que ele otimiza alguns gráficos TensorFlow existentes em tempo de execução usando o compilador LLVM. Requer que passos de otimização sejam implementados no compilador para cada algoritmo usado no gráfico.
A abordagem SYCL é a única abordagem que fornecerá um nível de programação CUDA - que é o que os desenvolvedores precisam.

Com o SYCL, nosso objetivo é fornecer suporte para todas as operações do TensorFlow e facilitar o desenvolvimento de novas operações.

Isso significa que o SYCL permite escrever novas operações de alto desempenho com muita facilidade, enquanto o XLA pode otimizar gráficos inteiros se suportar todas as operações no gráfico.

Os back-ends XLA LLVM IR podem ser convertidos em SPIR-V com https://github.com/KhronosGroup/SPIRV-LLVM?

Não vejo nenhuma razão para que isso não seja possível.

@lukeiwanski Obrigado, eu estava procurando especificamente https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend

@k-hashimoto: estamos discutindo aqui sobre a portabilidade do TensorFlow para OpenCL, um padrão do Khronos Group e, na verdade, mais OpenCL SYCL, o padrão de fonte única C++ pós-moderno do Khronos Group.
O ROCm parece mais uma solução não padrão de algum fornecedor.
Se você estiver interessado em soluções proprietárias, já existe uma versão CUDA do TensorFlow que parece funcionar bem. :-)

De acordo: mantenha a conversa/esforços no OpenCL e deixe os fornecedores implementarem o que quiserem em cima desse padrão aberto.

Em 17 de janeiro de 2017 10:01:32 GMT+00:00, Ronan Keryell [email protected] escreveu:

@k-hashimoto: estamos discutindo aqui sobre a portabilidade do TensorFlow para
OpenCL, um padrão do Khronos Group, e na verdade mais OpenCL SYCL,
o padrão de fonte única C++ pós-moderno do Khronos Group.
O ROCm parece mais uma solução não padrão de algum fornecedor.
Se você está interessado em soluções proprietárias, já existe um CUDA
versão do TensorFlow que parece funcionar bem. :-)

--
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -273076892

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

:+1:

👍

:+1:

Esta mensagem foi criada automaticamente pelo software de entrega de e-mail.

Uma mensagem que você enviou não pôde ser entregue a um ou mais de seus
destinatários. Este é um erro temporário. O(s) seguinte(s) endereço(s) diferido(s):

[email protected]
O domínio biomassiv.es excedeu o máximo permitido de emails por hora (111/100 (111%)). A mensagem será repetida mais tarde

------- Esta é uma cópia da mensagem, incluindo todos os cabeçalhos. ------
Recebido: 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 com esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exemplo 4.87)
(envelope-de [email protected] )
id 1cWmiQ-0032as-W9
para [email protected]; Qui, 26 de janeiro de 2017 10:16:03 -0600
Data: qua, 25 de janeiro de 2017 04:09:21 -0800
Assinatura DKIM: v=1; a=rsa-sha256; c=relaxado/relaxado; d=github.com;
s=pf2014; t=1485346161;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg=;
h= From:Reply-To :To:Cc:In-Reply-To:R eferences:Subject :List-ID:
Lista-Arquivo:Lista-Post :List-Un subscribe:From;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
De: Miguel Ángel [email protected]
Responder para: tensorflow/tensorflow [email protected]
Para: tensorflow/tensorflow [email protected]
Cc: Assinado [email protected]
ID da mensagem:
Em resposta a:
Referências:
Assunto: Re: [tensorflow/tensorflow] Suporte OpenCL (#22)
Versão Mime: 1.0
Tipo de conteúdo: multiparte/alternativa;
limite="--==_mimepart_5888957158d12_78b73ff902fe113c148134";
conjunto de caracteres=UTF-8
Codificação de transferência de conteúdo: 7 bits
Precedência: lista
X-GitHub-Sender: migpradel
X-GitHub-Recipient: biomassativos
X-GitHub-Motivo: inscrito
List-ID: tensorflow/tensorflow
List-Archive: https://github.com/tensorflow/tensorflow
Post da lista: [email protected]
Lista-Cancelar inscrição:,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Resposta-Supressão: Todos
X-GitHub-Recipient-Address: [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Tipo de conteúdo: texto/simples;
conjunto de caracteres=UTF-8
Codificação de transferência de conteúdo: 7 bits

--
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Tipo de conteúdo: texto/html;
conjunto de caracteres=UTF-8
Codificação de transferência de conteúdo: 7 bits

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa .

----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Novo aqui. Queria perguntar se haverá suporte a OpenCL no tensorflow no futuro, isso significaria que haverá suporte para executar o tensorflow no FPGA?
Obrigado

@atinzad : sim se a versão OpenCL ou SYCL e o código-fonte forem suportados pelo ambiente FPGA. Mas como o TensorFlow é talvez o framework mais portado com vários meios, ele já pode ter alguma parte rodando em um FPGA em algum lugar ...

OH MEU DEUS. https://www.youtube.com/watch?v=LqLyrl-agOw

Quais são as diferenças entre o esforço de desenvolvimento sycl e XLA visando SPIR-V diferente de PTX na visão de médio prazo?

Que ótima pergunta. Provavelmente - o número de pessoas envolvidas? Seria muito interessante saber!

Em 16 de fevereiro de 2017, às 13h35, bhack [email protected] escreveu:

Qual é a diferença entre o esforço de desenvolvimento sycl e XLA visando SPIR-V diferente de PTX na visão de médio prazo?

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

Qual é a diferença entre o esforço de desenvolvimento sycl e XLA visando SPIR-V diferente de PTX na visão de médio prazo?

@bhack Seria uma ótima discussão no TensorFlow Dev Summit de ontem

Você pergunta sobre os recursos disponíveis/tipo de programadores necessários para contribuir?

Se assim for, na abordagem OpenCL/SYCL, programadores C++ / programadores OpenCL C podem ser rapidamente atualizados e capazes de contribuir. A abordagem XLA requer uma experiência de compilador/llvm.

XLA é o projeto interno do Google por extensão, eles têm mais recursos associados a ele. Mas, por outro lado, a tarefa deles é muito maior também. Escrever um compilador não é uma tarefa fácil.

Caso contrário, se você estiver perguntando sobre o modelo:

Como mencionei anteriormente em https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870, estamos vendo os dois esforços como abordagens complementares e ambos com casos de uso diferentes. Eu ainda estou com essa afirmação.

Por exemplo, @tatatodd em sua apresentação mencionou que alguns dos Ops nunca terão o XLA como alvo. Acredito que podemos preencher essa lacuna.

Outras coisas a considerar são novas plataformas. Vou usar o ambiente móvel e incorporado por causa deste argumento, pois novos chips tendem a aparecer com mais frequência do que GPUs (o princípio é o mesmo).

Se o semicondutor suportar SYCL / OpenCL, você terá suporte TF pronto para uso (alguns ajustes de desempenho podem ser necessários).

Se a arquitetura for exótica e não houver backend LLVM para ela, o XLA precisará adicioná-la (isso pode não acontecer com muita frequência, mas ainda assim). O que acontece com mais frequência é que a arquitetura muda um pouco e, em seguida, novos passos de otimização precisam ser adicionados ou um existente deve ser modificado para obter o benefício. Ajustar o código do kernel é mais fácil.

Eu não olhei muito profundamente para o XLA, mas suponho que o XLA tenha que chamar a API CUDA de alguma forma para executar o código do kernel PTX, então teria que ser portado para OpenCL ou Vulkan para executar kernels SPIR-V - isso eu suponho passaria pelo StreamExecutor - outro framework para se familiarizar - provavelmente um grande esforço.

Em suma, estamos fornecendo uma plataforma unificada/estável em um ecossistema muito fragmentado/desviado que tanto as empresas de semicondutores quanto os desenvolvedores podem atingir. Onde como XLA teria que se comprometer com o suporte.

@benoitsteiner ou @drpngx podem fornecer mais conhecimento interno do XLA, pois estou trabalhando com muitas suposições / conclusões baseadas em conversas.

Ah, também criei o canal slack para facilitar a comunicação https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Edição:
O link do Slack não é mais válido. Por favor, ping-me se você quiser participar.

Acho que está correto e em parte dependerá em qual direção os produtores de semicondutores serão orientados.
"Esses back-ends emitem o LLVM IR necessário para representar a computação XLA HLO de maneira eficiente e, em seguida, invocam o LLVM para emitir o código nativo desse LLVM IR." Assim, o LLVM IR pode ser convertido em SPIR-V . Mas o dialeto Opencl SPIRV é diferente do Vulkan . Streamexecutor está sendo empurrado em LLVM parallel-lib e na descrição original @henline o plano original parece cobrir opencl.

/cc@dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
A Nvidia deve em breve suportar o opencl 2.0 no Linux e no Windows, isso é YUGE!

Em termos de desempenho, é provável que seja mais lento que o CUDA.

Lembre-se também que os caras da Noveau estão trabalhando independentemente no Opencl com SPIR-V . O status está um pouco desatualizado, mas há novos commits.

O Opencl não é inerentemente mais lento que o Cuda, é apenas a nvidia virtualmente travando o mercado ao paralisar seu driver opencl.
Mas a liderança da nvidia está finalmente chegando ao fim e mesmo suas práticas anticompetitivas imorais não vão salvá-los. Com o impressionante tradutor automático Cuda HIP ( https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
O próximo vega apus e dgpus e ARM chegando ao Windows, a Nvidia não tem futuro, é por isso que a indústria PRECISA dar suporte ao opencl/syCL/HIP/HSA muito em breve e massivamente.

E o slide 40 de https://autodiff-workshop.github.io/slides/JeffDean.pdf?

Olá, que estou planejando que o tensorflow suportará o novo AMD Radeon Instinct? (http://instinct.radeon.com/en-us/)

Oi, há algum progresso no suporte TF-OpenCL para FPGAs?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 foi removido há alguns meses e o roteiro do Streamexecutor não está claro.

@bhack obrigado pela resposta rápida
Então, isso significa que não há suporte ou que o funcionamento correto não é garantido?
Além disso, pelo que li neste tópico, vejo que os testes são principalmente em GPUs AMD ... alguém está treinando redes em GPUs Nvidia com esta porta OpenCL?

Streamexecutor foi renomeado em bibliotecas paralelas LLVM e agora é acxxel

Algum membro do Google pode explicar a diferença e os roteiros entre streamexecutor e https://reviews.llvm.org/rL285111?

CC @zheng-xq

@henline e @jlebar são os especialistas para responder a diferença entre streamexecutor e https://reviews.llvm.org/rL285111?

Axcell e StreamExecutor são projetos separados. Não há planos atuais para mesclá-los. Deixo para o pessoal do TensorFlow dizer se planejam ou não mudar.

Então também StreamExecutor e StreamExecutor llvm não eram os mesmos projetos?

Correto, eles não são o mesmo projeto.

Em qui, 16 de março de 2017 às 11:06, bhack [email protected] escreveu:

Então também StreamExecutor e StreamExecutor llvm não eram os mesmos projetos?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar Da próxima vez uma unidade criativa para nomeação ;) mas provavelmente não foi falta de motivação criativa, mas apenas um esforço de upstream de uma ferramenta interna que divergiu da mantida no TF..

@bhack , nós mudamos o nome, justamente quando percebemos que sim
acho que não fazia sentido mover o StreamExecutor para o atacado de LLVM. Isso é
agora chamado de "Acxxel".

Desculpe a confusão e agradeço o feedback.. Foi um
processo de aprendizagem com certeza.

Em qui, 16 de março de 2017 às 11h24, bhack [email protected] escreveu:

@jlebar https://github.com/jlebar Da próxima vez uma unidade criativa para nomear
;) mas provavelmente não foi uma falta de motivação criativa, mas apenas uma
esforço de upstreaming de uma ferramenta interna que divergia daquela mantida
em TF..

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Sim, ainda tenho um pouco de confusão entre StreamExecutor, SyCL em eigen, XLA (que na verdade possui apenas um backend CUDA, além de CPU e opencl em alguns slides)

Ressalto

Alguém no Google falou com a Apple ou AMD para facilitar isso? Acho que as pessoas da AMD estão tão perdidas que nem sabem que o problema está lá e ainda estão se perguntando por que a Nvidia tem uma participação de mercado tão grande. Acho que também a equipe de IA da Apple ficaria mais do que feliz em ajudar aqui... se o OpenCL não fosse um abandonware do lado deles desde 2013 e, pior ainda, seus chefes não ficariam bravos com o Google.

O que há de mais recente sobre isso?

De acordo com as notas de versão do TF 1.1 , o suporte à GPU Mac (somente Nvidia) foi preterido. Vamos esperar que isso ajude a melhorar a abordagem OpenCL (não muito confiante nisso).

Você pode acompanhar também o status do PR https://github.com/tensorflow/tensorflow/pull/9117

Obrigado! Estou acompanhando este problema durante os últimos meses. Não estou confiante sobre o compromisso do Apple OpenCL, já que eles estão presos ao OpenCL 1.2 desde 2013 (a Apple ainda não está fornecendo suporte ao SPIR 1.2).

Se o TensorFlow no OpenCL o ajudar em seu trabalho, avise-me, na medida em que posso ajudar a avançar na pesquisa e na prática de aprendizado profundo, gostaria de ajudar. Minha empresa construiu um back-end OpenCL para o TensorFlow ajustado para uma variedade de GPUs como parte de nosso trabalho de inferência no dispositivo. Testamos nas principais famílias de GPUs móveis e de desktop, incluindo configurações comuns no Windows e Mac. Se houver interesse suficiente, podemos fazer algum tipo de distribuição pública. Também temos Metal (Apple GPU) e LLVM (CPU), além de uma maneira de fazer uma implantação de dependência zero. A ideia aqui é dar a todos os dispositivos um ótimo suporte para aprendizado profundo.

@choongng - tudo isso parece incrivelmente útil e útil. Meu projeto pessoal https://github.com/Synopsis/ se beneficiaria muito do OpenCL no OS X, bem como da implantação do Metal para iOS e Desktop. Se for possível que isso seja introduzido no Tensorflow, acho que seria um tremendo benefício para muitos desenvolvedores.

Obrigada.

@choongng

Se sua empresa publicar uma versão OpenCL, ou mais interessante uma versão Metal do TensorFlow, acho que isso será uma ótima notícia para muitas pessoas, estou no processo de construir uma eGPU com placa NVidia para obter o TensorFlow / Keras rodando no meu MBP para o meu trabalho...

Para pessoas interessadas... acesse a comunidade eGPU.io

@choongng

Eu estaria muito interessado em ver isso, então eu ficaria muito grato se você pudesse prosseguir! Especialmente se não exigir os compiladores de código fechado esboçados que o TF escolheu para suporte a CL.

Em 26 de abril de 2017 03:33:51 GMT+01:00, Choong Ng [email protected] escreveu:

Se o TensorFlow no OpenCL o ajudar em seu trabalho, avise-me, para o
na medida em que posso ajudar a avançar na pesquisa e na prática de aprendizado profundo
gosta de ajudar. Minha empresa construiu um back-end OpenCL para o TensorFlow
ajustado para uma variedade de GPUs como parte de nosso trabalho de inferência no dispositivo.
Testamos nas principais famílias de GPUs móveis e de desktop, incluindo
configurações comuns no Windows e Mac. Se houver interesse suficiente nós
pode fazer algum tipo de distribuição pública. Também temos Metal (GPU Apple)
e LLVM (CPU), juntamente com uma maneira de fazer implantação de dependência zero. O
A ideia aqui é dar a todos os dispositivos um ótimo suporte para aprendizado profundo.

--
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297220160

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Acho que seria revolucionário ;)

@choongng Talvez ajude se você juntar forças com esses caras
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey qual é o compilador de código aberto que você propõe usar então? É difícil encontrar uma solução compatível com OpenCL de código aberto para lidar com muitos dispositivos à solta...
Precisamos inicializar uma solução em algum momento de alguma forma ...

Eu não disse que era uma solução fácil. Mas, OpenCL não é o problema. Afinal, o CUDA é totalmente proprietário, muito pior do que a opção OpenCL que o TensorFlow escolheu.

Dito isso, existem opções para um sistema CL-or-cuda se você estiver começando do zero, incluindo runtimes de middleware portáteis ou arrayfire, etc. No entanto, o Tensorflow está muito ligado ao CUDA.

Acho frustrante que as pessoas estejam dispostas a escrever kernels em CUDA, mas se recusem a fazê-lo para CL, mesmo que isso alcance mais usuários e aumente seriamente o ecossistema do mercado. Existem benefícios diretos e indiretos em uma plataforma aberta para todos, possivelmente levando a grandes economias de custos para todos a longo prazo.

Se SYSCL é como isso eventualmente acontece, ótimo: então por que alguns grandes nomes não estão investindo dinheiro em uma distribuição SYSCL aberta em vez de comprar opções proprietárias marginais, o que meio que anula o propósito de um padrão aberto?

Em 28 de abril de 2017 09:13:06 GMT+01:00, Ronan Keryell [email protected] escreveu:

@cathalgarvey qual é o compilador de código aberto que você propõe usar então?
É difícil encontrar uma solução compatível com OpenCL de código aberto para
endereçar um monte de dispositivos em estado selvagem ...
Precisamos inicializar uma solução em algum momento de alguma forma ...

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297936468

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

O que eu quero perguntar neste contexto é o seguinte:

Portanto, algumas estruturas de aprendizado profundo, como o Tensorflow, estão explorando um pouco o uso do opencl como uma alternativa ao CUDA. É claro que CUDA é apenas a "linguagem" na qual o cuDNN foi desenvolvido, e é isso (se meu entendimento estiver correto) é o que a maioria das linguagens de aprendizado profundo está realmente usando. Nesse contexto, não tenho certeza de qual é a versão opencl do cuDNN.

A AMD também tem falado sobre alternativas de código aberto ao CUDA, que estão continuamente desenvolvendo e estão chamando de rocM. Eles também estão falando sobre o miOpen como o equivalente ao cuDNN (bibliotecas assembler artesanais para funções comuns de aprendizado profundo), que, no entanto, ainda não foi lançado. A abordagem da AMD é um pouco mais holística: não estamos apenas exportando computação pesada para a GPU.

Neste contexto, estou genuinamente confuso. Como os esforços do opencl como os listados acima se encaixam? Para GPUs NVIDIA, é fácil... existe CUDA e existe cuDNN escrito em CUDA. Para não-NVIDIA/ou neste caso AMD, parece muito menos claro. Quando o HIP é preferido? Quando usar o HCC é preferível? Quando é preferível usar o opencl? Quaisquer insights seriam realmente apreciados!

@cathalgarvey há muita política por trás de todas essas enormes infraestruturas de software/hardware... :-(
Mesmo que possamos sonhar com uma solução rasa com base em critérios puramente científicos, acho que temos que ser pragmáticos.
O Google não quer mudar muito a arquitetura do TensorFlow. É por isso que a arquitetura baseada em OpenCL tem que ser muito semelhante, exigindo C++ de fonte única como "tempo de execução CUDA" em vez da solução OpenCL C de código não único de nível inferior. No reino Khronos, a versão C++ de fonte única do OpenCL é chamada SYCL.
Vamos discutir isso quando você passar por Dublin, por exemplo, já que você parece estar baseado na Irlanda também. :-)
Enquanto isso, sinta-se à vontade para contribuir com https://github.com/triSYCL/triSYCL e os ramos TensorFlow & Eigen que lidam com SYCL...

@keryell Você sabe se também XLA:GPU :OpenCL está planejado no SyCL?

Olá @benoitsteiner , sobre:

Há uma seção específica do OpenCL na documentação geral do TensorFlow. Isso será publicado no site tensorflow.org em breve.

Eu fiz uma pesquisa no tensorflow.org por OpenCL e não consegui encontrar nada significativo, tudo parece apontar de volta aqui. Por "em breve", você quer dizer antes de ______? ( _insira um sarcasmo engraçado aqui_ ).

Eu consegui compilar seu repositório (yay!), embora eu suponha que ele precise de algo mais para criar um Tensorflow OpenCL funcional para Mac; Eu tentei construir o compilador triSYCL mencionado, mas infelizmente falhei.

@bhack Como não trabalho para o Google, não tenho ideia dos detalhes do XLA...

@dylib infelizmente tudo isso é um trabalho em andamento...

@keryell Sim, eu sei .. Eu estava apenas curioso se foi discutido em algumas reuniões.

OpenCL é radicalmente diferente de CUDA. No entanto, eu definitivamente veria isso portado para o HIP.
Então, +1 para todos vocês que sugeriram.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

O HIP permite que os desenvolvedores convertam código CUDA em C++ portátil. O mesmo código-fonte pode ser compilado para rodar em GPUs NVIDIA ou AMD

Muitas pessoas não sabem sobre HIP.
Você pode encontrar mais informações sobre tensorflow e HIP aqui:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
e
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Nota:
Eu não acho que devemos brigar / nos gabar sobre Nvidia vs AMD. Essas são empresas respeitáveis ​​que fabricam hardware e software incríveis. Em vez disso, devemos nos concentrar em fornecer o tensorflow para uma base de usuários maior.
A segmentação de muitos idiomas por meio de associações já é um bom ponto de partida, mas também precisamos segmentar o máximo de hardware possível. (Mesmo que as soluções em nuvem sejam incríveis, elas nem sempre são a resposta)

Temos experiência com HIP, aqui na Stream. Deixe-me ver.

Concorde com o argumento "minha empresa é melhor". Gostaria de saber quais GPUs o TensorFlow deve ter como alvo. Tem que ser pragmático e útil. Por exemplo, GPUs Intel ou GPUs incorporadas (Qualcomm, ARM, Imagination), RaspBerry Pi - sim ou não?

Edição AMD Radeon Vega Frontier

Continuamos a melhorar agressivamente nossa plataforma de software aberto ROCm e bibliotecas de aprendizado de máquina. Também damos suporte a estruturas de inteligência de máquina abertas, como Caffe (lançada em abril). Ainda neste trimestre, planejamos oferecer suporte ao Torch, e o Tensor Flow está em andamento.

Eles já lançaram o Caffe, estariam muito interessados ​​em ouvir outros neste tópico compartilhando suas experiências com construção/teste:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Comecei a instalar, mas atingi um obstáculo em que qualquer coisa que exigisse CL simplesmente congela, até clinfo . Não tenho certeza se isso é devido a algum problema de software ou se meu cartão (R9 390) simplesmente não é suportado pelo ROCm.

Em 17 de maio de 2017 15:18:32 GMT+01:00, Bryan Li [email protected] escreveu:

Fronteira AMD Radeon VegaEdição

Continuamos a melhorar agressivamente nossa plataforma de software aberto ROCm
e bibliotecas de aprendizado de máquina. Também oferecemos suporte a máquinas abertas
estruturas de inteligência como Caffe (lançado em abril). Mais tarde isso
trimestre planejamos oferecer suporte para o Torch, e o Tensor Flow está em
os trabalhos.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -302103815

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

@cathalgarvey Eu tenho usado o ramo Caffe OpenCL nas GPUs da AMD e funciona muito bem. make run test passou em todos os testes, exceto um

Bom de se ouvir; posso perguntar sobre sua configuração de HW/SW? Por exemplo, qual cartão você está
usando, qual distro/versão do Linux, etc?

Eu já tinha o AMDGPU-pro, mas o desinstalei ao instalar o ROCm.
É possível que haja alguma coisa de legado interferindo em mim.

--
@onetruecathal / @ cathal @quitter.is

Na quarta-feira, 17 de maio de 2017 às 15h50, Bryan Li [email protected]
escrevi:

@cathalgarvey Eu tenho usado o branch Caffe OpenCL nas GPUs da AMD e
funciona muito bem. make run test passou em todos os testes, exceto um

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@cathalgarvey

• Ramo Caffe OpenCL (commit testado c61d48746b2df1d237c64abc7416342ce98f3251 )
• SO: Ubuntu 16.04.2 LTS
• Testado em Polaris (RX460), Fiji (Fury X) e Tonga (W7100)
• Driver: Driver AMDGPU-Pro para Linux 16.40 ou superior
• VienaCL
• Dependências gerais: libprotobuf-dev libleveldb-dev libsnappy-dev libopencv-dev libhdf5-serial-dev protobuf-compiler libatlas-base-dev libblas-dev libgflags-dev libgoogle-glog-dev liblmdb-dev libboost-all-dev cmake python-numpy
• cmake: cmake -DViennaCL_INCLUDE_DIR=<wherever you downloaded ViennaCL>/ViennaCL-<version> -DOPENCL_INCLUDE_DIRS=<wherever you downloaded ViennaCL>/ViennaCL-<version>/CL/ -DOPENCL_LIBRARIES=/opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1 ..

Sim, além do ramo OpenCL acima, o naibaf7 publicará um livro (muito em breve) sobre como usá-lo para inferência em tempo real em hardware comum usando gráficos amd e hd.

Ah; Eu estava falando sobre hipCaffe, não sobre o ramo OpenCL:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Instalar o ROCm para construir/testar o hipCaffe exigiu que eu desinstalasse
AMDGPU-pro, talvez eu tente o ramo vanilla novamente. Está mal
documentado, infelizmente.. Acho que vou tentar um "make" cego e ver.

Então, ainda estou interessado em ouvir as experiências de outras pessoas com a AMD
pilha ROCm/HIP; se eles estiverem trabalhando em um fork do Tensorflow, seria ótimo,
desde que realmente funcione em mais de 3/4 dos modelos de placa AMD no
selvagem.

--
@onetruecathal / @ cathal @quitter.is

Na quarta-feira, 17 de maio de 2017 às 16h09, Bryan Li [email protected]
escrevi:

@cathalgarvey

Ramo Caffe OpenCL (commit testado
c61d48746b2df1d237c64abc7416342ce98f3251)
SO: Ubuntu 16.04.2 LTS
Testado em Polaris (RX460), Fiji (Fury X) e Tonga (W7100)
Driver: Driver AMDGPU-Pro para Linux 16.40 ou superior
VienaCL
Dependências gerais: 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
—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@cathalgarvey Espero que eles estejam trabalhando em um back-end moderno, não em um fork completo. Isso seria triste e apenas dividiria o esforço de trabalho.
Já existem ferramentas suficientes :/

Os esforços da @YvanDaSilva AMD estão um pouco mal coordenados no momento (sim, todos os forks). Também não parece funcionar tão bem em uma grande variedade de dispositivos ainda, ao contrário do ramo OpenCL do Caffe, por exemplo ...

@naibaf7 concordo plenamente.
Para ser honesto, eles realmente parecem carecer de recursos humanos, estão trabalhando em todas as frentes.
A propósito: Não sabia que a ETH tinha Neuroinformática ;) legal !

@cathalgarvey Você pode elaborar a pilha ROCm/HIP para um leigo como eu. Eu tenho jogado AMGPU-pro e AMDGPU com minhas placas Sea Islands, então tenho certeza que posso postar alguns resultados úteis.

@YvanDaSilva
Eles patrocinaram meu projeto original do Caffe OpenCL e, infelizmente, não coordenaram bem, então a pesquisa da AMD e um cara independente da AMD também trabalharam em portas OpenCL em paralelo - a antiga equipe de pesquisa da AMD agora está extinta e a maioria deles realmente trabalha para a Tesla ( projeto de carro autônomo) agora... então uma infeliz cadeia de eventos.
Ainda estou em colaboração e contato com eles. Vega vai ser interessante :)

@naibaf7 Legal, sorte sua! Gostaria que houvesse tais estudos quando eu estava no Heig-vd teria continuado a um mestrado certamente.

Sim... Foi o que imaginei. Tanto trabalho, tão poucos recursos humanos disponíveis nestas áreas.

Tudo isso parece ótimo, mas vamos reorientar a discussão para que o TensorFlow trabalhe com OpenCL SYCL e não apenas soluções específicas do fornecedor... :-)
Espero que RoC e outros HiP tenham seu próprio GitHub para discutir seus próprios problemas...
@naibaf7 : pelo menos ainda estou no domínio OpenCL. Junte-se ao clube novamente! :-)

@keryell Acho que a discussão sobre HIP é válida, se houver uma porta HIP para Tensorflow em andamento. Afinal, a solução oficial do Tensorflow-on-CL é usar uma estrutura SYCL proprietária com plataforma e suporte ao kernel nitidamente limitados, portanto, não é realmente melhor do que as soluções HIP "específicas do fornecedor" que oferecem uma nova saída do CUDA.

O HIP pode ser principalmente da AMD agora, mas o AFAIK é um padrão aberto? Talvez eu esteja enganado. Se for, e se a AMD puder fornecer uma porta tensorflow-on-HIP, ela seria imediatamente mais aberta do que a porta tensorflow-on-SYCL oficial.

HIP é um subconjunto de CUDA, então é tão aberto quanto CUDA.

Tudo bem; HIP-the-API é um subconjunto de CUDA-the-API, mas a menos que a NVidia seja covarde o suficiente para começar a canalizar o Oracle, duvido que isso seja um problema. Eu estava me referindo ao tempo de execução/compiladores para HIP, dos quais acho que os AMDs são ~abertos.

edit : Desculpe se o acima saiu soando rude; apenas tentando esclarecer minha posição acima!

Vulkan e Opencl serão fundidos ?

De acordo com o Reddit AMA de Raja, Vega oferecerá suporte a Tensorflow, Cafe2, Cafe, Torch7 e MxNet via MIOpen.

@cathalgarvey a discussão é claramente válida, mas não aqui...
Você está no GitHub aqui, na pista discutindo o porte do TensorFlow & Eigen usando os padrões do Khronos Group.
Este não é o Twitter ou seu mural do Facebook... :-)
Então por favor contribua com alguns commits nestes projetos ! :-)

Há uma nova versão do guia de configuração para compilar o TensorFlow com ComputeCpp, a implementação do SYCL do Codeplay, para que os dispositivos OpenCL possam ser usados. Agradecemos qualquer feedback que você possa nos dar sobre isso. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

você tem alguma idéia de qual é a taxa de sucesso para fazer isso funcionar em gpus AMD não testada? Estou especificamente interessado se ele foi testado para AMD Radeon Pro 460 @rodburns. Eu ficaria feliz em passar algumas horas executando o Ubuntu no meu laptop Macbook se houver alguma esperança com uma GPU não testada

@samhains não testamos isso, mas você pode tentar. Você precisará usar alguns drivers AMD mais antigos com o Ubuntu que suportam a extensão SPIR. Ainda não consegui descobrir quais drivers são esses.

@samhains Se a rota de codeplay falhar, não perca tf-coriander , que finalmente está em um estado de uso prático no Ubuntu/Mac.

Atualmente estou testando em convnets, rnns bidirecionais, etc e tudo parece estar funcionando muito bem. Ele roda em "vanilla" OpenCL 1.2, então isso deve habilitar o Tensorflow em uma enorme variedade de hardware relativamente antigo.

O problema é que, por enquanto, é baseado no Tensorflow 0.11.

@rodburns. Eu tentei seguir as etapas listadas no link https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp
Estou tendo o erro a seguir:
ERRO: /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD:609 :1: inclusão(ões) não declarada(s) na regra '@protobuf//:python/google/protobuf/internal/_api_implementation.so ':
Na verdade, estou recebendo o mesmo erro se tento compilar o tensorflow da fonte. Eu o compilei anteriormente, mas não tenho certeza do que mudou.

@rahasayantan o que é isso incluído? Você também o obtém ao compilar sem --config=sycl ?

@lukeiwanski : O problema, pelo que entendi, é que o Bazel está tentando compilar o Protobuf e não encontra ou baixa os subdiretórios. Eu fiz um pull com o submódulo recursivo, mas ele ainda apresenta os mesmos problemas. E tem o mesmo problema sem --config = sycl. Na verdade, estou enfrentando o mesmo problema quando faço um git pull do projeto principal do tensorflow. Eu não acho que isso esteja relacionado ao openCL, são alguns problemas com a maneira como estou fazendo o pull. Quando eu baixo manualmente o zip do projeto do seu repositório sem git e compilar, ele compila corretamente, mas recebo uma falha de segmentação. Já levantei essa questão no seu projeto GIT e estamos conversando lá, darei as atualizações relacionadas à falha de segmentação nesse thread (não adianta duplicar as coisas). Obrigado pela sua resposta.

O triSYCL de código aberto está chegando. Veja https://github.com/triSYCL/triSYCL/pull/45

Eu sou novo aqui. Muito interessado em ver o suporte do TF OpenCL. Como faço para obter atualizações deste tópico?

emmm... Interessante, mas por quê? Quero dizer, por que o Tensorflow escolheu cuda, mas opencl no início? Algum motivo comercial, eu acho?

Olá @tensorflower-jardineiro,

@hughperkins criou o Coriander que pode executar o código NVIDIA® CUDA™ em dispositivos OpenCL 1.2. Você pode querer dar uma olhada se isso atende à sua necessidade de conectar o TF aos dispositivos OpenCL 1.2. Por favor, atribua seu nome e sua contribuição caso você pretenda usar seu trabalho.

Parece que as esperanças de ver o suporte OpenCL para Mac passaram de pouco para tf.zero . Acabei de ler que o TensorFlow Mac não terá mais suporte a QUALQUER 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

O TF-Coriander é testado no Mac, portanto, se/quando atingir a paridade de versão, você poderá usá-lo.

Em 22 de junho de 2017 11:46:51 CEST, dylib [email protected] escreveu:

Parece que as esperanças de ver o suporte OpenCL para Mac foram de
pouco a tf.zero . Acabei de ler que os Macs não terão mais
QUALQUER suporte a 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

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -310331281

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Triste porque agora com uma eGPU e n Nvidia 980 Ti dentro temos o driver funcionando e o Cuda funcionando

Ainda não tive tempo de experimentar o Tensor Flow na minha configuração.

webdriver e Cuda toolkit instalado no meu computador e as amostras Cuda funcionam bem

https://youtu.be/JN9fDmqf010

@cathalgarvey você disse que testa convnets no tf-coiander, mas parece que as convnets ainda não estão funcionando. Você pode esclarecer se conseguiu que as convnets fossem executadas na GPU usando o tf-coriander?

PARA SUA INFORMAÇÃO,
https://github.com/tensorflow/tensorflow/issues/10703

Por que o tensorflow não suporta mais GPUs no OS X? Eu estava planejando usar o Tensorflow com uma configuração de eGPU que encomendei.

@justinrmiller eles alegam que não podem mais testá-lo no mac os e, portanto, decidiram interromper o suporte. no entanto, estou tendo dificuldade em acreditar nisso. Avançando com o anúncio da egpus em high sierra e com novos drivers nvidia, isso não será mais o caso.

@tscholak sim exatamente. Eu ia usar meu novo gabinete egpu para abandonar minha caixa de janelas para sempre.

Tendo em mente que, embora as placas Nvidia funcionem em gabinetes eGPU, a Apple só oferecerá suporte oficial ao RX580 em seu kit de desenvolvimento, portanto, a necessidade de OpenCL não desaparecerá.

OpenCL no Mac é 1.2, o que significa que parece não haver driver ativo
desenvolvimento. Acho que adicionar suporte de Metal ao TF é um processo meticuloso
(habilitando Eigen e executor de fluxo), mas factível.

No domingo, 16 de julho de 2017 às 15h17 Ferdia McKeogh [email protected]
escrevi:

Lembrando que, embora as placas Nvidia funcionem em gabinetes eGPU, a Apple
suportará oficialmente o RX580 em seu kit de desenvolvimento, então a necessidade de
OpenCL não irá embora.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Estou muito triste com o abandono do suporte de GPU para macOS.

Ainda procurando suporte OpenCL para GPU no macOS porque a Apple, obviamente, não mudará para GPUs Nvidia tão cedo.

Tensorflow é o meu motor de escolha. Usar a aceleração de GPU localmente no meu MacBook Pro ou no futuro iMac Pro seria incrível.

Para a Microsoft, faria sentido sabotar a Apple, mas como o Google não tem um sistema operacional de desktop, eles estão apenas prejudicando a si mesmos.

Honestamente, alguém mais inteligente do que eu deveria procurar integrar o MPS - Metal Performance Shaders do Mac OS 10.13, que tem suporte para um grande conjunto de primitivas de rede neural prontas para uso. Isso permitiria uma GPU atualizada e de alto desempenho para dispositivos móveis e desktop iOS e implantação de inferência do macOS Tensorflow.

Você não pode treinar com os primitivos da Apple como eu entendo (eles não fornecem nada), mas com o suporte do Tensorflow talvez você possa? Imagino que para o pessoal da plataforma da Apple seria uma benção.

Eu não acho que o Google forneceria isso internamente, e eu não tenho as habilidades necessárias para tentar isso sozinho. Postando essa ideia para que as pessoas mais talentosas do que eu a aceitem.

:)

A Apple destina-se exclusivamente a vender dispositivos Apple. O Google tem como objetivo contratar serviços massivos do Google.

Se você estiver disposto a fazer IA (aprendizado) com um único dispositivo, como um laptop da Apple, fará "Aprendizado Superficial" em vez de "Aprendizado Profundo", então é melhor desistir de fazer qualquer coisa além de tutoriais. A inferência resulta em um modelo treinado para um único usuário, em um único dispositivo (mesmo em um telefone não muito multicore), pode ser feito por meio de GPUs, mas é perfeitamente possível apenas com CPUs.

Por outro lado, as GPUs são absolutamente necessárias se você for alimentar conjuntos de dados extremamente grandes para aprendizado ou fornecer inferência treinada para grupos de clientes simultâneos extremamente grandes.

Mesmo assim, fazê-lo em tal escala não é tão fácil devido aos problemas de rede. Basta dar uma olhada na arquitetura física dos TPU-Pods. Está no antípoda de um laptop (várias GPUs por servidor multi-core com sobrecarga de memória, com fibra óptica dedicada para comunicações entre servidores).

Eu tenho um MacBook Pro. É um bom terminal para chegar à nuvem :-D

Vejo que o TF on Metal também pode se estender ao iOS. Se alguém estiver interessado em pegá-lo, recomendo adicionar primeiro suporte ao Metal ao Eigen (pode usar o OpenCL como referência).

@rogerpasky Para a escola, tive que usar o Tensorflow para treinar modelos, não apenas para avaliar um modelo. E eu vou ter que repetir isso novamente no futuro próximo. Para estudantes como eu, ter treinamento em GPU é obrigatório, economizando muito tempo. Não é apenas uma questão de atender vários usuários simultâneos.

@rogerpasky é sobre a capacidade de desenvolver modelos e soluções localmente em um mac

@rogerpasky respeitosamente discordo. Embora as soluções multi-GPU baseadas em nuvem funcionem muito bem para serviços de Internet, estou visando pipelines de produção de vídeo profissional em que a inferência está sendo executada em horas e horas de pro-res e imagens HD, 2K, 4K não compactadas, que a) nenhuma casa de produção é vai fazer o upload para uma nuvem, b) eles não querem que o Google ou quem quer que tenha seus dados, c) eles têm salas cheias de sistemas com capacidade multi GPU (Mac e Windows) localmente que eles gostariam de aproveitar, e d) enquanto a inferência em uma única imagem é boa na CPU, executando filmes inteiros para inferência através de vários gráficos 100% vê um aumento no desempenho usando algo como MPS vs CPU. Como a comunidade se recusou a suportar / adotar os padrões e, em vez disso, usa apenas o código da Nvidia, os casos de uso do mundo real ficam encurralados e é realmente uma pena.

Esta não é uma solicitação ociosa de alguém que é um hobby executando tutoriais - a inferência de GPU é importante, pois oferece suporte a diversas famílias de GPU / CPU para diversas cargas de trabalho em hardware do mundo real. Eu realmente espero que o Google leve isso a sério, porque seria ótimo poder ficar com uma única biblioteca como o TF, o que é incrível.

Obrigado por me ouvir, não estou tentando reclamar, mas fornecer um ponto de vista alternativo para a comunidade.

@pldelisle , @tscholak , @vade por favor não me entenda mal. Eu adoraria tê-lo, e se você pesquisar neste tópico eu entrei como apoiador, mas pelo que tenho acompanhado cheguei à conclusão que escrevi, não apenas porque acho que sim (acho que um O MacBook derreteria se treinado com milhares de vídeos :-D), mas com os fatos reais da indústria. Não espere para resolvê-lo em um curto espaço de tempo (IMHO, não será resolvido nunca porque a Apple e o Google se odeiam desde o problema do iPhone / Android).

@rogerpasky Já havia suporte para GPUs nvidia no Mac OS. Ele acabou de ser removido em 1.2.

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

Eu cancelei meu pedido de uma eGPU (Sonnet's) e vou apenas inicializar o Linux em meu equipamento de jogos, mas é meio ruim parar de suportar algo que as pessoas estavam usando. Estava realmente esperando fazer isso no meu mac com uma eGPU (treinamento de modelo), mas acho que isso não acontecerá agora: https://github.com/lengstrom/fast-style-transfer

@rogerpasky Er, você sabe que o CoreML suporta a importação de modelos de fluxo de tensor por meio de Keras? A Apple não 'odeia' o Google, negócio é negócio, um dos fornecedores da Apple é a Samsung. Leia isso por um momento. Google, Apple, Samsung são empresas e farão o que dá dinheiro. Como uma nota rodapé. A propósito, meu MacBook Pro não derreteu ao executar inferências em milhares de filmes. Suspeito que o CUDA foi super conveniente de adotar e o suporte contínuo da Nvidia e as oportunidades perdidas da AMD nos levaram até onde estamos. Eu não acho que seja nefasto, apenas custo de fazer uma mudança versus deltas de desempenho versus custo de manter o curso.

Eu suspeito que algum gênio virá para ajudar a resolver o problema.

Criei um Grupo do Google para uma discussão colaborativa sobre como levar o aprendizado profundo para novos lugares, como OpenCL, Mac, iOS, CoreML, Vulkan etc. Se você quiser ajudar a fazer isso acontecer, participe e poste uma nota com seu uso caso ou em qual parte do problema você está trabalhando. Já existem pessoas trabalhando muito duro nos esforços para trazer o TF para mais plataformas, incluindo MIOpen, o trabalho do Codeplay, TF-Coriander e um projeto interno na minha empresa (Vertex.AI). Seria ótimo reunir desenvolvedores e usuários em um só lugar, pois esses esforços estão intimamente relacionados.

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

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

@justinrmiller Eu tenho uma eGPU no Sierra (Titan Xp em um gabinete Sonnet) executando o Tensorflow 1.2.1 (CUDA 8, cuDNN 6) que não foi muito problemático se você não se importa em construir do zero. Se tiver algum problema me avise.

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 Isso é incrível! Obrigado pela informação!

@danbarnes333 como você conseguiu que o tf 1.2 fosse construído com o cuDNN 6? Você usou o LLVM? GCC? Só consegui construir com cuDNN 5...

Para sua informação, https://machinelearning.apple.com/

@tscholak Eu não vou postar aqui para manter isso no OpenCL, mas vou resumir as etapas aqui .

@choongng Entrei no Grupo do Google, mas parece estar tranquilo. Então vou desabafar aqui ;-)

1. Aprendizado de máquina / alto desempenho / computação GPU é um mercado extremamente competitivo. A NVidia, goste ou não, domina o mercado e mantém seus cartões e softwares à mão. Se você tem um orçamento e um prazo, está mais ou menos preso à NVidia por enquanto.

2. Eu tenho uma placa AMD antiga ("Bonaire") e orçamento zero - amador. Eu tenho caffe rodando com a implementação proprietária AMD OpenCL 2 no Arch Linux a partir de ontem, e acabei de colocar o código aberto da AMD MIOpen rodando da mesma forma esta manhã. Isso me permitirá treinar alguns modelos; o Bonaire atinge o pico em torno de 1800 GFLOPS de precisão simples. Portanto, se o TensorFlow não for executado com OpenCL no Bonaire, não usarei o TensorFlow.

3. Se um orçamento aparecer magicamente, eu compraria uma CPU Intel e uma placa NVidia e executaria um software proprietário suportado pelo fornecedor. Terminei de fazer QA não pago para fornecedores como Google, Red Hat, Canonical e AMD.

   Levei três meses (e três distros - Fedora 25, Ubuntu 16.04 LTS e Arch) para obter algo de uma GPU que tenho há três anos. Existem bugs não corrigidos no rastreador de bugs do Fedora com meu nome neles. O mesmo vale para Ubuntu e Freedesktop.org. A maioria das pessoas que iria consertá-los também não está sendo paga, ou está sendo paga para fazer outra coisa.

   Sim, as novas CPUs da AMD são impressionantes e, sim, a maioria de seus softwares é de código aberto, mas orçamentos e prazos mudam as coisas. O suporte é fundamental. Apoio é tudo!

@znmeb Eu nem sabia que você poderia usar hardware pré-GCN para TF.
Com o meu Tahiti eu só tenho suporte para uma distro (ubuntu 14.01.x), pois os drivers proprietários da AMD só funcionam com kernels linux mais antigos para GCN1. (Recebo TF + openCL via SYCL (não testado em 7970))

Onde trabalho, todo o departamento de P&D administra a equipe verde. Todos eles têm PHDs e todos, exceto nenhum, escreveram uma única linha de cuda (nem OCL). Mas as ferramentas estão aqui para acelerar sua carga de trabalho Keras . Eu sou meio excêntrico com minhas GPUs de mineração recicladas tentando espremer uma segunda vida delas.

tl;dr, exceto o suporte da equipe verde, só aparecerá se a participação de mercado da GPU AMD aparecer.
É um problema de galinha e ovo. Eu tenho esperanças para vega... mas sim... não é um assassino 1080Ti.

@acoye FWIW aqui está o post do GitHub que me fez trabalhar neste fim de semana depois de bater e pesquisar no Google desde abril: https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . Consulte também https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . Esse foi o meu problema original - tentar usar meu Bonaire para acelerar a álgebra linear em R.

@acoye
Você pode passar para as distribuições Linux mais recentes e usar um kernel compilado personalizado recente como 4.11/4.12 com drivers AMDGPU ativados, RADEON desativado e com CONFIG_DRM_AMDGPU_SI=Y e/ou CONFIG_DRM_AMDGPU_CIK=Y definido na configuração do kernel, além de firmware AMD para 7970 (Tahiti) no initramfs => o mais novo AMDGPU-PRO OpenCL funcionará em qualquer placa GCN. Esqueça o FGLRX (em distribuições Linux mais antigas) e o Clover via drivers RADEON, ambos são inferiores.
Esqueça também os cartões pré-GCN. Eu os testei usando OpenCL no Windows for Caffe, o desempenho não vale a pena fazer um esforço para placas tão antigas. Como todas as placas AMD pós 2012 devem ser GCN de qualquer maneira.

@naibaf7 Passei algumas horas ontem tentando fazer a pilha de código aberto da AMD funcionar. Eu tenho MIOpen e suas dependências, mas hcc ainda está faltando alguns bits. Talvez eu precise fazer uma compilação de kernel personalizada para obter tudo. Não me importo muito em portar código CUDA ou executar C++ compilado na GPU - quero fazer cálculos numéricos nele. ;-)

Eu também vi algo no site deles sobre como programar em assembler - que pode me interessar, porque é fácil ir do assembler para o FORTH. ;-)

@znmeb Sim, também estou tentando fazer com que algumas coisas do MIOpen e do TensorFlow funcionem no meu RX 480, mas não quero destruir meu principal equipamento de desenvolvimento, então, em vez disso, uso a virtualização do IOMMU e uso uma máquina virtual Ubuntu 16.04 que pode usar o RX 480. Os drivers AMD são muito amigáveis ​​à virtualização (ao contrário dos drivers nVidia feitos para placas de jogos - apenas os drivers Quadro fazem).

@znmeb Tudo que você precisa fazer é sudo apt-get install rocm miopen-hip

@adityaatluri Está no repositório do usuário do Arch, mas não é instalado - também não é instalado a partir da fonte do GitHub. Parece algo simples - não consegue encontrar algumas dependências.

@znmeb Você pode criar um problema aqui (https://github.com/RadeonOpenCompute/ROCm/issues) para que possamos discutir lá? Obrigado!

@adityaatluri Claro - estou indo jantar, mas vou arquivar quando voltar

@ebrevdo Alguma maneira de usar a GPU tensorflow no Mac com processador AMD?

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

Minha empresa vem trabalhando no aprendizado profundo do OpenCL há algum tempo e temos alguns resultados iniciais para mostrar. Estamos nos concentrando no Keras no curto prazo, mas também criamos um suporte (muito) experimental ao TensorFlow e o revisaremos após nosso lançamento inicial. Mais detalhes aqui, incluindo números de rendimento iniciais na AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl

Frio!

Pequeno detalhe: AFAIK, MIOpen não é específico da AMD, pois pode se vincular ao OpenCL e ao ROCm. O último é provavelmente mais rápido, mas ainda assim; O MIOpen é um grande passo à frente para o shtick "Open Source Neural Networks On GPU", e a AMD merece enorme crédito por isso se funcionar bem em OpenCL.

14 de agosto de 2017 17:19, "Choong Ng" escreveu:
Minha empresa vem trabalhando no aprendizado profundo do OpenCL há algum tempo e temos alguns resultados iniciais para mostrar. Estamos nos concentrando no Keras no curto prazo, mas também criamos um suporte (muito) experimental ao TensorFlow e o revisaremos após nosso lançamento inicial. Mais detalhes aqui, incluindo números de rendimento inicial na AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

—

Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416) ou silencie o tópico (https://github.com/notifications/unsubscribe-auth /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Obrigado pela correção, baseei meu comentário nos requisitos do sistema na documentação do MIOpen (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#prerequisites), mas feliz em atualizar se houver um melhor ligação.

Espere, eu estive lendo este tópico/questão por 10 minutos agora. Cheguei na metade e pulei o resto. As GPUs AMD já são suportadas?

Usando uma coisa complicada de código fechado que só funciona em uma combinação muito antiga de Kernel/OS (codeplay): sim

Usando uma versão antiga do tensorflow e ainda sem suporte para algumas não linearidades (tf-coiander): sim.

Realmente: não oficialmente. Embora a AMD esteja migrando para o HIP, espero progresso dentro de 3 meses ou mais. Outros frameworks já funcionam bem devido aos seus esforços.

Em 18 de agosto de 2017 02:09:55 GMT+01:00, abrad1212 [email protected] escreveu:

Espere, eu estive lendo este tópico/questão por 10 minutos agora. cheguei na metade
e eu pulei o resto. As GPUs AMD já são suportadas?

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -323233294

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

FWIW Eu acredito que as versões recentes do PyGpu podem usar CUDA ou OpenCL. Eu tenho todo o software instalado na minha caixa Arch, mas ainda não testei.

@abrad1212 sim, esse problema já existe há algum tempo. O esforço é enorme e muitas pessoas estão tentando "fazer funcionar", como @cathalgarvey mencionou.

Um pouco de uma atualização do nosso lado. Você deve poder usar o ComputeCpp 0.3.0 na pilha de drivers AMDGPU-pro para Ubuntu 16.04, as instruções podem ser encontradas aqui: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 -04-lts/

Além disso, estamos nos concentrando agora em melhorias de desempenho para diferentes modelos - há muito o que fazer, mas estamos chegando lá.

@lukeiwanski Qual é a sua abordagem para benchmarking? Nós cronometramos os modelos incluídos com Keras e normalizamos contra TF+cuDNN+K80 porque essa é uma configuração comum e bem otimizada. Nossa metodologia é semelhante a Max Woolf (http://minimaxir.com/2017/06/keras-cntk/), não é muito código, mas ficaríamos felizes em compartilhá-lo. Temos alguns números de throughput em nosso site (http://vertex.ai), nosso código é um pouco mais rápido que o TF 1.2 na inferência Xception e seria interessante comparar mais abordagens lado a lado.

Existem soluções para Windows? Eu instalaria o Ubuntu no meu PC, mas atualmente não tenho espaço suficiente para fazê-lo.

Ubuntu 14.04
ramo mestre tensorflow
construa suporte a opencl e apenas o tempo de execução de cpu intel opencl instalado.
python2.7
siga https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow guide
execute python class_image.py
parece que não chamou o driver opencl. (Adicionei meu wrapper opencl icd, não vi nada)
Existe alguma configuração que precisa ser adicionada ao código python?
Como sess.graph.device('/cpu0')

Mas se eu usar o guia Eigen skcl pode ser executado em cpu com suporte a OpenCL. (Também este código de guia está um pouco desatualizado, precisa de algumas modificações)
https://developer.codeplay.com/computecppce/latest/getting-started-with-eigen

Qualquer pessoa pode ajudar a verificar como a interface python do tensorflow também pode ser executada com suporte a OpenCL.

E construir tensorflow com este conjunto opt não irá realmente gerar binário tensorflow. --config=sycl
Apenas construa o tensorflow neste comando:
bazel build -c opt /tensorflow/tools/pip_ package:build_pip_package

Talvez eu construa esqueça --config=sycl
Vou tentar o comando build e verificar se ele pode chamar a biblioteca OpenCL. Após obter o resultado, postarei aqui.
bazel build -c opt tensorflow/tools/pip_ package:build_pip_package

@ joe8086 Se você modificar a criação do tf.Session com o abaixo, ele mostrará um log no terminal, isso está mencionando o SYCL em algum lugar?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Para o guia Eigen, você tem algum feedback específico que esteja desatualizado?

@rodburns Obrigado.
Meu erro é build tensorflow miss config option --config=sycl
Depois de adicionar esta opção com este código de branch https://github.com/lukeiwanski/tensorflow.git
Eu posso ver o tensorflow rodar com o backend OpenCL.

Para o guia Eigen, o principal erro está em:
1, não forneça o arquivo de inclusão correto.
2, para array, Tensor, TensorMap não fornece o parâmetro de modelo correto.
3, para static_cast não forneça o tipo de dados.

adicione mais informações que talvez ajudem este tópico de discussão.
1, Main tensorflow não pode construir tensorflow com --config=sycl correto.
2, Com CPU OpenCL, a velocidade é cerca de 4x~8x vezes gasta do que a implementação normal da CPU no meu ambiente.

python de tempo class_image.py
2017-09-07 16:56:29.076054: I tensorflow/core/platform/cpu_feature_guard.cc:137] Sua CPU suporta instruções que este binário TensorFlow não foi compilado para usar: SSE4.1 SSE4.2 AVX
2017-09-07 16:56:29.077967: W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] Nenhuma GPU OpenCL encontrada compatível com ComputeCpp, tentando a CPU OpenCL
07-09-2017 16:56:29.159775: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Encontrado os seguintes dispositivos OpenCL:
2017-09-07 16:56:29.159825: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id: 0, type: CPU, name: Intel(R) Core(TM) i7-6700HQ CPU @ 2,60 GHz, fornecedor: 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á obsoleto. Ele deixará de funcionar no GraphDef versão 9. Use tf.nn.batch_normalization().
panda gigante, panda, urso panda, urso guaxinim, Ailuropoda melanoleuca (pontuação = 0,89107)
indri, indris, indri indri, indri brevicaudatus (pontuação = 0,00779)
panda menor, panda vermelho, panda, gato urso, urso gato, Ailurus fulgens (pontuação = 0,00296)
pinha (pontuação = 0,00147)
estrela da terra (pontuação = 0,00117)

1m44.473s reais
usuário 2m8.980s
sistema 1m20.024s

Pessoal, não vou ler este tópico inteiro, mas se alguém puder responder minha pergunta, seria ótimo! Posso usar o Tensorflow com uma GPU AMD ainda. Se sim, em qual sistema operacional, e posso fazer isso com o RX Vega? Obrigado!

@ M3L0NM4N Hmmm ... Eu não tenho seguido o tópico, mas parece que há código OpenCL possivelmente testável agora, pelo menos na CPU OpenCL. Eu tenho uma GPU AMD mais antiga ("Bonaire") e tenho OpenCL rodando tanto na GPU quanto na CPU, então posso testar isso. Eu poderia tentar no fim de semana; Eu realmente quero OpenCL TensorFlow na minha GPU.

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

Algum suporte a tensorflow 1.3 gpu/opencl por aí em macos?

Últimas notícias: Construí com sucesso o TensorFlow 1.3.1 com OpenCL a partir da fonte do GitHub. Há algumas peças faltando na documentação, e ainda não tentei executar nada na GPU, mas pelo menos está funcionando para CPU não OpenCL. BTW, não tenho CPU OpenCL instalada, apenas GPU OpenCL.

Alguém tem algum caso de teste para TensorFlow com uma GPU OpenCL? Eu vou ter que construir um para mim eventualmente, mas eu estava esperando por uma verificação rápida.

@znmeb Sim, há um aplicativo de teste com problema que relatei. https://github.com/hughperkins/tf-coriander/issues/64

Poderia me informar se funciona no seu caso?

@unoexperto Sim - funciona (não trava), mas não há indicação se encontrou ou não o OpenCL.

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

Eu acho que o melhor curso de ação aqui é arquivar um problema separado para solicitar a documentação, já que é claro (quando você executa ./configure construindo a partir da fonte) que existe código para OpenCL. Foi assim que eu encontrei, de qualquer maneira.

@znmeb Duvido que tenha encontrado o dispositivo GPU no seu caso, porque no meu ele imprimiu informações de depuração no início sobre a seleção do dispositivo GPU. Talvez você possa recompilar com printf adicionado ao console em algum lugar em tensorflow/core/common_runtime/gpu/gpu_device.cc .

@unoexperto Entrei no grupo de discussão do Google e postei um pedido de documentação. Vou esperar para ver se alguém responde antes de me esforçar mais nisso.

@znmeb Quais instruções você está seguindo? Você já correu clinfo? Você executou o computecpp_info? Isso indica que seus drivers OpenCL estão instalados conforme o esperado? As instruções para o Ubuntu 14.04 estão aqui https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow e se você estiver usando o 16.04, existem algumas instruções experimentais aqui http://deep-beta.co. uk/tensorflow-1-3-on-ubuntu-16-04-lts/

@rodburns clinfo e clpeak correm. Eu não fiz isso recentemente, mas quando crio o caffe da fonte e executo os testes, ele definitivamente atinge a GPU. Portanto, tenho certeza de que os drivers / bibliotecas OpenCL / GPU estão funcionando.

Estou no Arch Linux - kernel é o LTS deles - linux-lts 4.9.52-1. Se for importante, o "Bonaire" atinge o pico de cerca de 1,7 TFLOPS no modo de 32 bits e está na família "Sea Island" de GPUs AMD.

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

ComputeCpp Info (CE 0.3.2)

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

Toolchain information:

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

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


Device Info:

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

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

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

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

Alguém está coletando logs de teste? Diz que meu dispositivo não foi testado, então vou testá-lo. ;-)

Impossível para mim construir o TensorFlow para Sycl/OpenCL!

Configuração:
Ubuntu 16.04
Tensorflow r1.3
OpenCL 2.0
ComputeCpp CE 0.3.2 (computecpp_info OK)
Intel HD Graphics 620
Bazel 0.5.4

Instrução de instalação (compilação 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

Erro:

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

Treinar modelos na minha CPU leva muito tempo, eu realmente preciso de aceleração OpenCL/GPU...

@ErwanGalline Estamos em processo de upsreaming mudanças para Eigen ( https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None ) que irão corrigir o problema que você está vendo.

Também estamos nos preparando para melhorar o desempenho do Eigen - isso é um pouco complicado e precisa de coordenação com @benoitsteiner para evitar fluxo de conflitos de mesclagem - mas estamos chegando lá.

Para usuários da AMD, sugiro experimentar meu fork: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu
As instruções de configuração para o Ubuntu 16.04 podem ser encontradas aqui: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Todas as alterações serão upstream para o tensorflow depois que as alterações Eigen mencionadas anteriormente estiverem em vigor.

Espero que ajude.

@lukeiwanski Seu garfo suporta apenas GPU AMD R9 Nano / AMD FirePro?

@lukeiwanski Existe um caso de teste que eu possa usar para verificar se estou usando a GPU? Posso monitorá-lo com radeontop mas gostaria de algo que usa o próprio TensorFlow.

@ZixuanLiang não, não apenas ..
Atualmente, testamos em AMD ( R9 380, R9 Nano, FirePro ). Sabemos que a GPU Intel expõe alguns bugs de driver, mas há correções chegando. E anunciamos o Renesas R-Car e esperamos que mais venham a seguir.

Eu acredito que Xilinx está upstreaming suporte para triSYCL https://github.com/tensorflow/tensorflow/pull/12882 - então FPG (?) - @keryell deve saber mais sobre isso

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test deve ser uma verificação justa .. a saída deve ser algo assim:
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 Obrigado, vou tentar na GPU AMD

@lukeiwanski A construção e o teste parecem estar funcionando no meu Bonaire. Estou usando o Python 3.6, porém, e as instruções usam o Python 2.7. Preciso usar 2.7 ou 3.6 funcionará?

@znmeb Seguindo https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647 parece que o Python 3.6 deve estar funcionando - eu ainda não tentei

@lukeiwanski Essa é uma versão do ComputeCpp que pode compilar o TF no momento?
Tentei várias versões entre 0.3.2 e 0.1.4 e nenhuma funcionou. Todos eles acabaram com o erro "várias sobrecargas de 'global_ptr' instanciam para a mesma assinatura".
Btw, não consigo encontrar o arquivo TensorDeviceSycl.h em fontes TF, é um renomeado? É possível aplicar o patch às fontes atuais?

Desde já, obrigado.

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

O upstream está faltando um patch para o Eigen que o corrige. consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564

Alguma idéia de como injetar este patch Eigen durante a construção do bazel? Talvez devêssemos bater em algum lugar Eigen tgz version para obter o fixo?

Obrigado, Adão.

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

Este commit seria suficiente para construí-lo?

sim, você deve ser capaz de escolher isso

Bem, infelizmente, isso claramente não é suficiente, aqui estão algumas das próximas falhas de compilação:

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 existem alguns commits que você precisa aplicar para compilar.
Eu sugiro usar a dica de dev/amd_gpu ou se você não quiser alterar seu branch atual.. você pode mesclar dev/amd_gpu a ele.

Na verdade, estou trabalhando no meu pacote não oficial do Debian/Ubuntu, então estou tentando me manter próximo do lançamento oficial 1.3.1. Eu posso viver sem suporte OpenCL, mas eu deveria estar pronto para habilitá-lo assim que for suportado corretamente. Talvez eu atualize os pacotes no seu branch para fins de teste, mas isso é o suficiente por hoje ;)

Eu tenho cerca de dez variedades diferentes de GPUs AMD em minhas plataformas de mineração. (de 7970 a RX 480 rodando Ubuntu 16.04 e amdgpu-pro). Deixe-me saber se eu posso contribuir testando alguma coisa.

Deixe-me saber se eu posso contribuir testando alguma coisa.
Que tal https://github.com/ROCmSoftwarePlatform/hipCaffe
https://github.com/ROCmSoftwarePlatform/hipeigen

Em terça-feira, 17 de outubro de 2017 às 10h54, slundell [email protected] escreveu:

Eu tenho cerca de dez variedades diferentes de GPUs AMD em minhas plataformas de mineração. (a partir de
7970 para RX 480 rodando Ubuntu 16.04 e amdgpu-pro). Deixe-me saber se eu puder
contribuir testando qualquer coisa.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski Seu fork também suportará GPUs AMD no macOS?

Oi,
Eu estava construindo APIs de tensorflow no Ubuntu16.04 x64 para meu dispositivo Android com GPU (Mali-T720) habilitada,

Informações do meu SO:
Ubuntu 16.04x64
GPU do computador: NVIDIA 1080Ti
CUDA 8.0
CUDNN 5.1 (embora eu não use cuda ou cudnn para construção)
bazel 0.5.2
Calcular Cpp CE 0.3.2

meu build.sh é:
'
bazel build -c opt --config=sycl //tensorflow/contrib/android:libtensorflow_cc.so --cxxopt="-
std=c++11" --cxxopt="-DTENSORFLOW_DISABLE_META" --verbose_failures --
crosstool_top=//external:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --
cpu=armeabi-v7a
'
antes de construir. Eu exporto LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, construir sem ' --config=sycl ' está bom e eu obtive o libtensorflow_cc.so correto, mas com ' --config=sycl ', o resultado final acabou faltando -lComputeCpp sem nenhum outro erros de compilação

Log completo assim:

ERRO: /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1: A vinculação da regra '//tensorflow/contrib/android:libtensorflow.so' falhou: link_dynamic_library.sh falhou: erro ao executar o comando
(cd /home/e0024/.cache/bazel/_bazel_e0024/783dad02ec856015f56356584726dd10/execroot/org_tensorflow && \
exec env - \
COMPUTECPP_TOOLKIT_PATH=/home/e0024/workspace/source/computeCppForSYCL1.2 \
HOST_CXX_COMPILER=/usr/bin/g++ \
HOST_C_COMPILER=/usr/bin/gcc\
LD_LIBRARY_PATH=/home/e0024/workspace/source/computeCppForSYCL1.2/lib:/home/e0024/workspace/caffe/build/lib:/home/e0024/workspace/cudnn/lib64: \
PATH=/home/e0024/bin:/home/e0024/.local/bin:/home/e0024/workspace/Anaconda2/bin:/opt/cuda:/home/e0024/workspace/source/protoc-3.3.0- linux-x86_64/bin:/home/e0024/workspace/bazel/output:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ games:/usr/local/games:/snap/bin \
PWD=/proc/self/cwd \
PYTHON_BIN_PATH=/home/e0024/workspace/Anaconda2/bin/python \
PYTHON_LIB_PATH=/home/e0024/workspace/Anaconda2/lib/python2.7/site-packages \
TF_NEED_CUDA=0\
TF_NEED_OPENCL=1 \
external/bazel_tools/tools/cpp/link_dynamic_library.sh não ignorado ignorado ignorado external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -shared -o bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/contrib/android/libtensorflow.so '-Wl,-rpath,$ORIGIN/../../../ _solib_armeabi-v7a / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib '-Lbazel-out / braço em 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, -Todo-arquivo Bazel-out / braço -linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/c/libc_api.a -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi- 4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu -libstdcpp-opt/bin/tensorflow/core/kernels/libandr oid_tensorflow_kernels.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib_lite.lo -Wl ,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libprotos_all_cc.a -Wl,-no-whole -archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf.a -Wl,-no-whole-archive -Wl, -whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf_lite.a -Wl,-no-whole-archive -lComputeCpp external/androidndk/ndk/ sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libsupc++.a -landroid -llog -lm -z defs -s -Wl,--gc-sections '-Wl,-soname=libtensorflow.so' -Wl,--version-script tensorflow/c/version_script.lds -lz -static-libgcc - prefixos 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: Processo encerrado com estado 1.
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld: aviso: pulando incompatível 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 ao pesquisar para ComputeCpp
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /arm-linux-androideabi/bin/ld: erro: não é possível encontrar -lComputeCpp
collect2: erro: ld retornou 1 status de saída
Target //tensorflow/contrib/android:libtensorflow.so falhou ao compilar
INFO: Tempo decorrido: 617,736s, Caminho Crítico: 54,66s

uhm.... Eu quero construir APIs tensorflow no arco do braço com GPU (Mali-T720) habilitada,
Agradeço se alguém puder deixar algumas experiências ou sugestões aqui. Thx um looooot.

Venha para minha palestra na próxima semana no Arm TechCon, @laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Você precisará de drivers do Mali com suporte a SPIR-V, que provavelmente ainda não está disponível com facilidade. E você precisará de um tempo de execução ComputeCpp para Android com suporte para CPU Arm e suporte para SPIR-V, que também não está disponível (ainda). Então, você terá que ser apenas um pouco paciente.

Nós (Vertex.AI) acabamos de abrir o PlaidML, nossa pilha de aprendizado profundo com suporte para executar Keras em OpenCL. O suporte do TensorFlow está chegando, ajuda seria bem-vinda. E sim, o suporte para Mac está a caminho (também Windows). http://vertex.ai/blog/announcing-plaidml @ggaabe

@choongng Eu queria tentar, mas falhei.
pip search plaidml retornos

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Mas pip install plaidml ou pip install plaidml==0.1.0rc3
retorna

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

@hy9be Eu acho que seria mais apropriado fazer um problema no repositório plaidml em vez de aqui, já que esse problema é sobre suporte a OpenCL no tensorflow. Além disso, observando as instruções de instalação, seu comando de instalação do pip pode estar incorreto.

Obrigado @andrewrichards pela atenção e pelo discurso da sessão.

Mas, por enquanto, para mim (um estudante de pós-graduação), para criar um aplicativo usando Tensorflow no dispositivo Android e deseja ativar a GPU (Mali-T720), o que é necessário para obter o driver Mali com suporte a SPIP-V e tempo de execução ComputeCpp para Android com CPU Arm suporte e suporte SPIR-V.

Desde que baixei o ComputeCpp(Ubuntu16.04 x64 com bin/doc/include/lib/) na página inicial do CodePlay, ontem eu executei:
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
erros disseram libComputeCpp.so incompatible , então eu considero que talvez eu precise do ComputeCpp para Android com suporte para Arm CPU e suporte para SPIR-V, mas não consegui encontrar nenhum código-fonte para construir um ComputeCpp Android, existem apenas exemplos no github.

E você disse que o ComputeCpp para Android agora não está disponível, então existe algum plano para oferecer suporte a dispositivos Android ou como posso obtê-lo se houver suporte.

Para usuários de gpu e linux da AMD, a AMD lançou recentemente a porta HIP do tensorflow aqui . Você pode estar interessado.

Eu não testei, no entanto.

Eu posso testá-lo - fique atento. Parece que está falhando no CI.

Na verdade está falhando. Ainda em um estágio inicial, eu acho.

Eu testei, obtive segfault no exemplo MNIST imediatamente.
Não sei o que estou fazendo de errado aqui.

$ 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 - certifique-se de ter o rocm 1.6.4 base instalado.

@bensander Obrigado, vou atualizar.

@bensander Mais alguma coisa que eu preciso da pilha AMD? Tudo o que tenho agora é a biblioteca opencl proprietária da AMD que usa o driver "amdgpu" de código aberto.

@masahi - se você instalar o rocm e o rocm-libs (ou seja, "apt-get install rocm rocm-libs"), isso deve ser tudo o que você precisa. O rocm_docs no repositório tem instruções completas, incluindo os resultados esperados.

@bensander como sei se estou executando o rocm 1.6.4 corretamente (e não o 1.6.3)?

@masahi apenas um palpite: você deve fazer a pergunta em um local mais relacionado ao seu problema, como o projeto AMD ou RoCM, e não aqui ...

@keryell certo, estou fugindo do assunto. Eu paro aqui.
De qualquer forma, não consegui fazer o hiptensorflow funcionar no meu sistema. Vou tentar mais tarde com a instalação limpa do Ubuntu.

@masahi - basta abrir um problema por lá e nós o configuraremos.

Olá, só quero mencionar que consegui fazer o hiptensorflow funcionar, graças a @bensander e outras pessoas da AMD. Posso executar todos os exemplos em seu guia de início rápido.

Obrigado

Para aqueles que desejam experimentar o TensorFlow em hardware AMD usando ROCm, escrevi um blog descrevendo como executar notebooks Fast.ai usando AMD Fury Nano.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 mal posso esperar por isso!

O ROCm 1.7 está a caminho, com o que parece ser o suporte adequado ao Tensorflow!

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

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

Funciona muito bem para mim. Minha configuração de hardware:
GPU: AMD Radeon RX 480
Processador: Intel Xeon 2603 v3
MB: supermicro x10srl-f

A chave é placa mãe e CPU tem que suportar PCIe v3

Seu desempenho é semelhante ao da Nvidia 980Ti

Não consigo nem fazer com que os drivers AMD "suportados" funcionem na minha instalação "suportada" do Ubuntu 16.04 LTS. Obsolescência programada?

znmeb, qual é a sua GPU AMD? Se você tiver duas GPUs, desative a não suportada no BIOS.

Não foi possível ler todo o encadeamento... qual é o status atual do tensorflow no OpenCL no MacOS (sierra +)? Especificamente, eu tenho uma GPU Intell Iris e esperava poder construir a partir do suporte Tf + Open CL de origem para ela.
Além disso, o tf corrainder parece funcionar bem, na versão 1.2.

@ varun19299 FWIW há um Intel SDK para OpenCL - eu o tenho no meu antigo laptop Sandy Bridge, mas tenho certeza de que funcionará em sua máquina. https://software.intel.com/en-us/intel-opencl

Isso está atualmente em um estado utilizável em sistemas linux não-ubuntu? A página do roteiro simplesmente liga aqui.

@pfc O que atualmente é utilizável em Linux não Ubuntu? TensorFlow usando OpenCL em geral? Ou TensorFlow usando OpenCL em uma GPU AMD? Vou assumir o último, já que é o único motivo pelo qual você deseja executar o TensorFlow usando OpenCL. Para uma GPU NVidia, você usaria os drivers / bibliotecas da NVidia e, apenas para CPU, não há nada a ganhar com o OpenCL.

Eu tinha isso funcionando há algumas semanas no Arch Linux, usando a biblioteca proprietária ComputeCpp SYCL e uma GPU AMD "Bonaire" (arquitetura Sea Islands). Há uma nova versão do ComputeCpp que preciso testar, mas acho que funcionará.

Acontece que as bibliotecas proprietárias AMDGPU Pro que você precisa para fazer isso funcionar não rodam no Ubuntu 16.04.3. A atualização de 16.04.2 trouxe um kernel Linux mais recente e o X Server, e a AMD ainda não lançou algo que funcione nele. 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 obter detalhes. Não consegui fazer o AMD OpenCL funcionar no Ubuntu.

Há uma versão experimental AMD do TensorFlow que usa um compilador para traduzir código CUDA para código OpenCL, mas também não testei isso. Na ausência de um driver compatível, é inútil.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs é a maneira oficialmente suportada de executar o fluxo tensor no hardware AMD.

@bensander O runtime do ROCm funciona no Ubuntu 16.04.3? Não consegui fazer funcionar.

PS: Você tem alguma ideia se / quando a configuração AMDGPU-Pro funcionará no Ubuntu 16.04.3? Preciso disso para outro projeto.

Hmm, eu não gosto (e não iria) divertir o Ubuntu em qualquer lugar, mas eu tenho um CentOS 7 com repositórios e um GTX1080TI nele, rodando o kernel 4.14.xe o driver beta mais recente da Nvidia, então eu poderia ajudar a testá-lo lá em algum momento hoje se isso ajuda?

--
Sam McLeod

Em 7 de dezembro de 2017, às 07:28, M. Edward (Ed) Borasky [email protected] escreveu:

@bensander O runtime do ROCm funciona no Ubuntu 16.04.3? Não consegui fazer funcionar.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@sammcj Por que você executaria uma GPU NVidia com OpenCL quando existem bibliotecas CUDA perfeitamente boas para ela?

Apenas para ajudar a testá-lo para você!

Não se preocupe se você não precisar de um teste de mão, apenas pensei em oferecer. Eu nem tentei essa máquina com cuda TBH, só tentei no MacOS onde não posso usar o OpenCL através do Docker no momento.

--
Sam McLeod

Em 7 de dezembro de 2017, às 08:16, M. Edward (Ed) Borasky [email protected] escreveu:

@sammcj Por que você executaria uma GPU NVidia com OpenCL quando existem bibliotecas CUDA perfeitamente boas para ela?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@znmeb Eu ia tentar o ComputeCpp SYCL, mas eles fornecem apenas o instalador do ubuntu (também estou no arch) e o script de instalação do aur está quebrado. É bom saber que pode funcionar. Se eu ficar desesperado o suficiente, posso tentar.
@bensander Isso parece exatamente o que eu preciso para obter suporte ADM, mas estou preocupado com o fato de que esse código não foi portado para o TF e que seu código foi atualizado pela última vez há mais de 2 meses, pois meu código tem como alvo o TF 1.4. 0
Parece que no momento o tensorflow basicamente liga você à Nvidia, pelo menos para nós programadores "mortais". A falta de documentação/roteiro atualizado não ajuda. Eu não me importaria de ajudar de qualquer maneira que eu pudesse, no entanto, eu tive pouco sucesso em fazer as coisas funcionarem até agora.

@pfc Eu tenho o ComputeCpp SYCL trabalhando no Arch - havia um tarball binário em seu site quando eu fiz isso.

Nesta notícia sobre o lançamento do SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
diz :
_A nova especificação incorpora experiência significativa adquirida com três implementações separadas e feedback de desenvolvedores de estruturas de aprendizado de máquina, como TensorFlow, que agora oferece suporte a SYCL junto com o back-end original do acelerador CUDA._

Isso significa que agora é possível executar "facilmente" o TensorFlow na GPU AMD que suporta OpenCL 1.2 na qual o SYCL é construído?

"Facilmente" no sentido de que alguns softwares / drivers / bibliotecas de baixo nível para o hardware AMD estão onde a maioria das coisas quebradas está, não no hardware ou no TensorFlow ou nos padrões OpenCL ou SYCL. ;-) Se você tem drivers de GPU AMD funcionando e bibliotecas OpenCL funcionando, você tem TensorFlow em GPUs AMD.

Minha configuração de trabalho para um AMD Bonaire (arquitetura Sea Islands):

Arch Linux com o módulo de kernel amdgpu carregado e o módulo de kernel radeon lista negra
O pacote Arch User Repository opencl-amd
A biblioteca ComputeCpp
TensorFlow construído a partir da fonte na minha estação de trabalho usando o fork do @lukeiwanski :

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

Estou um pouco surpreso com o que você disse "Se você tem drivers de GPU AMD funcionando e bibliotecas OpenCL funcionando, você tem TensorFlow em GPUs AMD". Eu tinha entendido que a versão "Oficial" do TensorFlow não estava sendo executada no OpenCL (somente CUDA). Parece que me confundi.
Fiquei muito feliz em encontrar o projeto PlaidML que pelo menos permite que alguns códigos Keras sejam executados no meu iMac com AMD Redeon HD 6970. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) AFAIK você também tentou esse Framework.
Vou tentar rodar o TensorFlow no Ubuntu VirtualBox onde o Tensorflow já está rodando (somente CPU).

@PALYGAP Eu não acho que o VirtualBox exporte OpenCL de um host Mac para um convidado Linux, e o Ubuntu 16.04.3 não funciona no momento. Eu não tenho um Mac, então não tenho como testar as coisas.

Alguém experimentou com sucesso o TensorFlow na AMD via OpenCL e teve sucesso?.

@mohnkhan Eu tenho o fork @lukeiwanski funcionando (Arch Linux) - consulte https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . Estou esperando um pouco mais de trabalho AMDGPU-Pro antes de publicar uma postagem no blog - consulte https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Obrigado pelas contribuições

@mohnkhan BTW, a AMD está construindo um caminho alternativo totalmente de código aberto - traduzindo o código CUDA para código OpenCL com uma cadeia de ferramentas do compilador. Não tenho certeza de qual é o status disso para os cartões mais antigos como o meu.

Se você vai escrever um artigo, acho que não faria mal explicar também (demorou 3 horas para obter o quadro completo):

• O TF tem de fato um backend SYCL 1.2. Não *real* opencl.
• por sua vez, você tem duas implementações do padrão (trisycl parece legal, mas é limitado em atm)
• No final, o ComputeCpp 'engancha' o SPIR /SPIR-V (além do PTX, mas isso é outra história )

E é isso que eventualmente leva você direto ao seu maldito OpenCL 1.2 (com cl_khr_spir ext)

O HIP, em vez disso, é mais um back-end, fica em frente ao SYCL e visa apenas e exclusivamente o ROCm (ou bem, lol, mesmo por sua vez cuda se você tiver uma gpu nvidia .. mas isso é outra história)

A AMD está construindo um caminho alternativo totalmente de código aberto - traduzindo o código CUDA para código OpenCL com uma cadeia de ferramentas do compilador.

Não. Você está falando sobre HIP e, na verdade, é isso, o que você eventualmente converte seu código para . O que não é OpenCL.
HIP então roda no ROCm como eu estava dizendo...
ROCm, que também é o que executa o OpenCL para você (em placas suportadas ), mas, por favor, gostaria de enfatizar a todos que observem como as relações são apenas diretas do ROCm, nunca "intra-sub-camadas"

O que você talvez esteja pensando pode ser coentro .

Não tenho certeza de qual é o status disso para os cartões mais antigos como o meu.

Resumido aqui : driver AMDGPU-PRO de pleno direito, amdgpu-pro-opencl-only como você está fazendo agora ... Ou continuar esperando até o final da década para alguém finalmente tornar o trevo utilizável.

Além disso, fglrx... Mas se isso é difícil de recomendar para cartões pré-gcn, acho que é melhor desenhar um véu.

@mirh

1. Não estou preocupado com cartões pré-GCN. O meu é um Sea Islands e não pretendo adquirir nada mais antigo. Então, novamente, também não estou planejando adquirir outra GPU AMD. ;-)
2. Não sei se o ROCm será executado na minha estação de trabalho - não há testador de hardware de código aberto que possa me dar uma resposta sim ou não. Abri um problema para isso e não obtive resposta.
3. SPIR-V é um alvo de compilador - eu dei uma olhada nele e joguei minhas mãos para cima, não tendo um orçamento para contratar um escritor de compilador.

Então isso deixa SYCL ... ou jogando minhas outras duas mãos e fazendo tudo com Keras, que tem back-ends TensorFlow, Theano (que está ficando congelado), CNTK ou PlaidML. Do ponto de vista puramente da economia de engenharia, Keras / PlaidML é um grande vencedor, desde que eu obtenha o TensorBoard de alguma forma.

@mirh obrigado pelo bom resumo com todos os links. Acho que você não desperdiçou suas 3 horas... :-)

Não sei se o ROCm será executado na minha estação de trabalho - não há testador de hardware de código aberto que possa me dar uma resposta sim ou não. Abri um problema para isso e não obtive resposta.

Como eu já disse algumas vezes , não, não vai funcionar.
O gpus pré GCN de 3ª geração simplesmente não tem o hardware para o ROCm funcionar ou até mesmo funcionar.

SPIR(-V).. Não tenho certeza do que você está falando. Não é seu trabalho se preocupar com isso. Computecpp faz isso a partir de "comandos" SYCL, e então é tudo negócio de driver (opencl).

Você tem o que estou chamando provisoriamente de amdgpu-pro-opencl-only, e não tenho certeza de qual é o problema.
EDIT: também seria legal ter algum tipo de ETA para o código de Luke chegar

@znmeb e todos

Eu tenho (L) Ubuntu 17.10 incl. kernel 4.14.xe a biblioteca OpenCL faz parte do driver AMDGPU Pro 17.40 em execução e pode executar aplicativos OpenCL como clinfo ou Boinc (por exemplo, Engima @Home , Milkyway@Home) sem problemas na minha APU AMD A12-9800E.

Eu também posso compilar com sucesso e usar a versão da CPU tensorflow (atualmente versão 1.4.1). Mas não consigo compilar com sucesso a versão OpenCL do tensorflow. Eu uso o computecpp 0.5 (o atual eu posso baixar sem precisar me registrar) junto com o vanilla tensorflow 1.4.1 e com o branch "dev/amd_gpu" do fork do @lukeiwanski .

Então, alguém que compilou com sucesso a versão OpenCL do tensorflow poderia fornecer algumas informações sobre qual versão da biblioteca computecpp e qual ramificação de qual tensorflow git ele está usando?

Obrigado

@AlphasCodes Não tenho nada rodando no Ubuntu - todas as minhas coisas de trabalho estão no Arch. Eu tenho a máquina com inicialização dupla com o Ubuntu 16.04.3, mas as bibliotecas proprietárias da AMD ainda não funcionam lá. Até onde eu sei, eles não são suportados no 17.10, mas se você tiver o OpenCL funcionando no 17.10, posso adicionar uma terceira inicialização - tenho bastante espaço em disco. ;-)

Que tipo de erros você está recebendo? Se forem erros de compilação, você pode ter uma incompatibilidade do Bazel. O Bazel está avançando constantemente como o TensorFlow e, às vezes, um fica à frente do outro.

O que você quer dizer com "não suportado"?

Isso .
Quanto ao Ubuntu, diz-se que apenas 16.04.3 é suportado (pelo menos oficialmente, considerando que até o arch pode fazê-lo funcionar após alguma mágica de script)
EDIT: driver AMDGPU-PRO 'completo' requer kernel 4.9, esse provavelmente era o problema

Se alguém se importa, a porta do driver AMDGPU-Pro 17.40 para Arch está em andamento e está muito ativa no GitHub em https://github.com/corngood/archlinux-amdgpu/pull/54 ,

Nós realmente devemos fechar este problema, pois, como @mirh apontou, o TensorFlow usa SYCL, não OpenCL. Talvez devêssemos abrir outro, "TensorFlow em placas AMD"??

Não, é totalmente legítimo.
Você quer que o tensorflow seja executado eventualmente em dispositivos opencl, esse é o objetivo. Legal e fim.
Dizer que estava realmente usando SYCL foi apenas um detalhe técnico que fiz, porque todas essas siglas de tecnologias magicamente aleatórias estavam me deixando louco.
EDIT: Eu também gostaria de agradecer a todos os caras do codeplay por seu trabalho notório

Se você quiser algo especialmente criado para amd, recomendo verificar o hiptensorflow . ROCm-somente embora. E por favor, vamos deixar para trás esse argumento.

OK, não sei se tenho tempo suficiente para fazer a compilação novamente e fornecer os erros de compilação até o final de semana. Mas eu adicionei minha documentação existente ao meu novo repositório do github.

Consulte https://github.com/AlphasCodes/DeepLearning para obter detalhes (minha configuração de hardware/software + configuração do AMD OpenCL + configuração do Tensorflow).

@mirh para esclarecer as "acrônimos de tecnologias magicamente aleatórias [...] deixando [você] louco":

No reino do Khronos Group, OpenCL é a API de baixo nível não-fonte única e SYCL é a linguagem incorporada específica de domínio (DSeL) C++ de alto nível e fonte única . Espera-se que o SYCL seja construído em cima do OpenCL, portanto, por transitividade, quando você usa o SYCL, geralmente usa o OpenCL.

Como o TensorFlow usa o Eigen, que usa uma abordagem C++ de fonte única com CUDA de fonte única , quando foi posteriormente portado para OpenCL, SYCL foi escolhido porque é a maneira padrão do Khronos Group de ter C++ de fonte única .

Mas se você pensar em CUDA, é ainda mais sutil.

Quase todo mundo usa a versão de fonte única de alto nível do CUDA, que na verdade é chamada de "CUDA Runtime API". Isso é de alguma forma semelhante ao SYCL.
Mas na verdade existe uma versão menos conhecida de baixo nível e não de fonte única do CUDA que é chamada de "CUDA Driver API", semelhante ao OpenCL, e usada, por exemplo, pela própria implementação "CUDA Runtime API".

Como é uma espécie de FAQ, esclareci um pouco https://en.wikipedia.org/wiki/SYCL e https://en.wikipedia.org/wiki/CUDA

O ComputeCpp, que é a implementação SYCL que você está usando com o TensorFlow, ainda não é compatível com o Ubuntu 17.10. Você precisaria manter o Ubuntu 16.04, que é o LTS atual. Instruções e pré-requisitos estão aqui https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow

Além disso, o suporte OpenCL para TensorFlow não significa apenas suporte a dispositivos AMD. A integração SYCL também está habilitando outros dispositivos OpenCL. Como parte do trabalho que estamos fazendo com o TensorFlow, o suporte para GPUs ARM e Intel estará disponível quando os drivers mais recentes dessas empresas estiverem disponíveis. Também estamos trabalhando para habilitar o suporte para processadores aceleradores Renesas também para a plataforma R-Car.

@rodburns Obrigado! Eu tenho isso trabalhando no Arch Linux (kernel 4.14.4) com a biblioteca opencl-amd do Arch User Repository. O cartão é um Bonaire (GCN 2.0). Vou executar os testes nessa página para verificar se está fazendo o que deveria.

GCN 2nd gen (aka 1.1) se houver, 2.0 não existe.
(deveria se rebaixar para ser tão pedante)

SUCESSO!

Os commits de branch "dev/amd_gpu" mais recentes no fork @lukeiwanski corrigiram meu problema de compilação do Tensorflow OpenCL. Suponho que foram os commits relacionados ao SysCL 1.2.1.

Compilei com sucesso uma versão do Tensorflow OpenCL e posso usá-la. Consulte meus documentos de configuração do Tensorflow para obter detalhes.

Também adicionei uma página de benchmarks onde você pode encontrar alguns benchmarks da minha configuração em diferentes configurações do Tensorflow (não otimizado para CPU, otimizado para CPU, OpenCL) no futuro.

O driver AMDGPU Pro versão 17.50 também está funcionando para mim. Atualizei o documento de configuração do AMD OpenCL relacionado.

Obrigado a todos os contribuidores.

Fiz alguns benchmarks e parece que o iGPU é mais lento que os 4 threads de CPU disponíveis, exceto o benchmark matmul_bench.py .

A inicialização de uma execução do OpenCL Tensorflow também é muito mais lenta do que uma execução do OpenCL Tensorflow somente da CPU. Algo como 5 segundos para CPU vs 1-2 minutos para OpenCL.

Alguém pode confirmar tais resultados?

OK, eu fiz mais algumas soluções de problemas.

• usei o exemplo MNIST do Tensorflow, consulte o documento Validate a Tensorflow Setup
• eu usei "sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info" para verificar/assistir o clock/load da iGPU e "top" para verificar a carga da CPU
• a fase de inicialização até a etapa 0 levou cerca de 6 minutos, a carga da iGPU foi de cerca de 0%, o clock da iGPU em 300 MHz (o clock mínimo disponível) e o uso da CPU do processo python foi de cerca de 200% (= 2 threads)
• começando com o passo 0 a carga da iGPU foi de cerca de 90%, o clock da iGPU sempre mudou de 654 MHz - 720 MHz - 800 MHz - 900 MHz (relógio máximo disponível) e vice-versa, o uso da CPU do processo python foi de cerca de 100% (= 1 CPU fio)

Ainda estou tentando compilar as coisas no Arch.

O que usei ontem .
Depois de 14 horas (sim, minha batata está muito lenta) consegui esse binário , se quiser tentar.

Tentei descobrir o que está acontecendo, mas infelizmente não consegui. Eu apreciaria se alguém que sabe sobre o seguinte pode me ajudar a acelerar!

A maior parte da discussão acima dizia respeito à execução do Tensorflow com aceleração OpenCL em chips AMD. Estou correto em dizer isso? Se eu quiser obter o tensorflow acelerado por gpu usando minha placa gráfica integrada (intel HD 5000) que suporta opencl, qual deve ser minha abordagem?

Desde já, obrigado!

@znmeb Oi Ed, obrigado por responder. Eu baixei o OpenCL e executei no meu sistema. Mas minha pergunta era - como posso compilar o tensorflow para realmente usar as bibliotecas OpenCL?

https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow
E o mais importante para intel https://github.com/codeplaysoftware/computecpp-sdk/issues/78#issuecomment -352411192

@AlphaCodes Obrigado por publicar seus resultados. Com relação ao tempo de inicialização, a forma como o OpenCL funciona é que o código é compilado antes da execução, então o tempo de inicialização é o processo de compilação.

@brainwave Para dispositivos Intel, há um tópico com @mirh aqui que explica como remover as restrições em torno de dispositivos em execução. Temos visto problemas com drivers Intel e é por isso que esses tipos de dispositivos são restritos, mas esperamos que drivers atualizados estejam disponíveis em breve para dispositivos Intel que melhorem o suporte. Enquanto isso, você pode recompilar o TensorFlow com a alteração para testar seu próprio hardware Intel. Estamos analisando a remoção das restrições de dispositivo na base de código.

@AlphasCodes Pessoal, peço desculpas pela pergunta talvez ingênua, mas por que esta compilação é apenas uma GPU AMD? O OpenCL não deveria ser padrão? Entendi corretamente que não funcionará no meu Intel Carbon X1 com drivers OpenCL 2.0 instalados?

Se você ler o problema que foi vinculado duas vezes, verá que não há nada sobre amd gpu.
A Intel está atualmente excluída, mas não tem nada a ver com querer forçar os usuários, e há uma solução temporária - discuta lá se realmente houver.

Quando eu uso a ramificação amd_gpu com um notebook jupyter, parece haver um encadeamento restante. python ainda usa 100% de uma CPU, mesmo após a conclusão da computação. Reiniciar o kernel termina o thread perdido. Alguém mais experimenta isso?

@brainwave @unoexperto
Desculpe, não posso ajudar com o Intel OpenCL porque tenho apenas hardware AMD OpenCL.

@desperadoduck
Eu não uso jupyter ainda. Eu uso um shell bash simples e um ambiente virtual do Python 3 ( veja minha configuração do Python 3 + Tensorflow ). Mas não consigo reproduzir o problema. Não há uso de CPU por um processo python após a conclusão da computação.

@rodburns
Obrigado pela informação. É possível acelerar o tempo de compilação inicial? por exemplo, usando todos os threads de CPU disponíveis em vez de apenas 50%.

@brainwave @rodburns
Para a GPU Intel (Gen9) no Linux, vimos um desempenho DNN significativamente melhor com a implementação Beignet de código aberto da Intel versus a de código fechado ao fazer benchmarking com redes de visão comuns no PlaidML. Beignet também é mais fácil de instalar, o que é bom.

Ele suporta gráficos intel hd615 (cpu de 7ª geração) no ubuntu17.10?

O dirver opencl SRB5.0 para linux64 está rodando bem no ubuntu17.10.

E não foi atualizado por um longo tempo:
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Pelo amor de Deus, você não pode ler apenas 2 (dois!) posts acima?
Discuta a falta de suporte Intel gpu (ou amd cpu) aqui https://github.com/codeplaysoftware/computecpp-sdk/issues/78

@znmeb é um objetivo fazer uso total de vários recursos de computação (por exemplo, cpu, gpu, DSP, qualquer outro coprocessador).
Na verdade, depende do suporte dos fornecedores de hardware: dirver e OS.
Como eu sei, você não pode habilitar a GPU intel e a GPU nvida para vídeo durante o mesmo tempo, devido à limitação do driver vedio. (Você pode ser capaz de alternar entre eles).
No entanto, o opencl pode usá-los ao mesmo tempo. Ambos são "dispositivos" nele.

@choongng É interessante saber, fizemos algum trabalho para ajudar a habilitar o Beignet, mas a atividade neste projeto parece ter ficado um pouco quieta.

@znmeb Sim, qualquer GPU provavelmente não terá um desempenho muito melhor em um pequeno problema, ainda bem que você está fazendo algum progresso!

@unoexperto ComputeCpp com TensorFlow pode ser usado por qualquer hardware que suporte instruções intermediárias SPIR OpenCL que incluam GPUs Intel, no entanto, como no thread aqui , impedimos intencionalmente a execução porque não achamos que os drivers atuais estavam funcionando no momento . Você pode remover essa restrição, pois parece que alguns usuários o fizeram funcionar com diferentes drivers Intel. Também estamos trabalhando para habilitar isso para processadores ARM e Renesas que possuem drivers OpenCL.

@ sxpc722 Isso deve funcionar então. A propósito, a nova máquina é o Windows 10 e não estou planejando fazer o dual-boot com o Linux até que seja absolutamente necessário! Estou cansado de perseguir bugs de drivers e bibliotecas para fornecedores (olhando para você, AMD). Na verdade, posso colocar uma partição do Windows na minha estação de trabalho pelo mesmo motivo da AMD. ;-)

Já se passaram 14 dias sem atividade e este problema tem um responsável. Atualize o rótulo e/ou o status de acordo.

O desempenho do Tensorflow AMD OpenCL é muito lento de acordo com meus testes. Então eu fiz alguns testes básicos com outro framework de Deep Learning. Você encontrará minha configuração e benchmarks na minha página do GitHub aqui .

Longa história curta. A outra estrutura de Deep Learning é cerca de 10 vezes mais rápida que o Tensorflow AMD OpenCL atualmente.

@AlphasCodes @znmeb Eu sei que a equipe do TF prefere manter o thread somente TF, estamos felizes em hospedar a conversa específica do PlaidML no projeto PlaidML. Dito isso, esperamos eventualmente suportar o próprio TensorFlow, bem como plataformas não-OpenCL (por exemplo, Metal da Apple para iOS, que atualmente existe em forma de protótipo).

https://github.com/plaidml/plaidml

@choongng Obrigado pelas informações, editei minha mensagem de acordo.

@znmeb A iGPU AMD A12-9800E deve ser GCN v3.

A principal e única razão para eu fazer os benchmarks/testes é encontrar uma resposta para minha pergunta "Fique com a AMD ou mude para a Nvidia para minha aventura de Deep Learning".

E a resposta é. Eu realmente gosto da abordagem de código aberto da AMD, mas provavelmente mudarei para a Nvidia devido a 2 fatores. Primeiro, a pilha de software Deep Learning (por exemplo, Tensorflow) é muito mais madura para a Nvidia. Em segundo lugar, a placa de vídeo oferece para minhas necessidades muito específicas (deve caber em um gabinete Dan A4 SFX e deve ser muito, muito silenciosa / quase silenciosa sob carga total por horas) é muito limitada ou mesmo inexistente no lado da AMD.

As GPUs Intel são suportadas? Acho que meu Iris Pro pode acelerar um pouco o treinamento ao longo da idade.

Discuta a falta de suporte para Intel gpu (ou AMD CPU) aqui codeplaysoftware/computecpp-sdk#78

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

Apenas tentando ter uma noção do estado desta questão. Estou certo em dizer que este repositório:

https://github.com/lukeiwanski/tensorflow

...construído com ComputeCpp, é a melhor opção atual para construir o Tensorflow com suporte geral para GPU AMD? E em caso afirmativo, há alguma evidência de benchmark de que essa compilação forneça uma aceleração sobre a CPU?

Depende do que você quer dizer com "suporte geral de GPU AMD". Se você quer dizer dGPU ou APUs realmente antigos, eu não sei. Mas se você tiver mais recente (2ª geração GCN ou mais recente), o hipTensorFlow (v1.0.1) rodando no ROCm estava funcionando muito bem.

@briansp2020 Ah sim, eu vi o trabalho da AMD no ROCm. Infelizmente, eles só suportam Linux, e nem parece que o suporte para qualquer outro sistema operacional esteja em seu roteiro. Estou esperando por algo que suporte o Windows.

@mjmax Existe algum pacote tensorflow acelerado por GPU disponível para Windows? Eu pensei que, se você quer deeplearning acelerado por GPU, o Linux era a única escolha. Se o TensorFlow fosse portado para OpenCL, isso facilitaria a portabilidade para o Windows? Não sei por que o TensorFlow não está disponível no Windows com aceleração de GPU quando há suporte para CUDA.

Eu acho que isso agora está fora do tópico, mas se alguém souber do TensorFlow e/ou PyTorch para Windows que é acelerado por GPU, eu gostaria de saber sobre isso também...

@briansp2020 Até onde eu sei, o Tensorflow já suporta a aceleração de GPU Nvidia no Windows.

CL tensofrflow já está uma bagunça no linux, não espere nada em breve.
Se você quiser acelerar as coisas, há apenas plaidML.
(e por favor, já estamos com 500 comentários.. vamos tentar postar só se for muito, muito necessário)

@mirh OpenCL Caffe funciona no Windows. Claro que não é o TensorFlow em termos de recursos, mas bastante sólido para software que precisa ser implantado em todos os lugares.

Que tal substituir a porta openCL pela porta HIP suportada pela AMD?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

Haha! @LifeIsStrange A vida é muito estranha na verdade... Você está trabalhando para a equipe de marketing HiP da AMD? :-)
Por favor, veja o assunto desta edição: "Suporte OpenCL".

Isso significa que é sobre o padrão Khronos https://en.wikipedia.org/wiki/OpenCL (e o outro padrão SYCL do grupo de trabalho OpenCL Khronos aparece no final da seção "Visão geral").

Claro que existe um mundo fora desta questão, mas está... fora ! :-)

Por favor, tente não aumentar desconsideradamente a entropia do universo postando alguns posts aleatórios nesta discussão já muito longa... :-)
Este comentário se aplica a alguns outros pôsteres aqui, não apenas a você, a propósito.
Este é um problema do GitHub para resolver um problema técnico : ter o TensorFlow rodando em dispositivos que suportam o padrão OpenCL, não uma página do Facebook sobre como as pessoas gostam ou não da ferramenta A ou B. :-)
Mas sinta-se à vontade para enviar alguns commits do git relacionados a esse problema que podemos analisar...

Existe um fork do TensorFlow que suporta OpenCL https://github.com/hughperkins/tf-coriander

E claro o trabalho de @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

IMHO, é ridículo que o TF mainstream ainda não tenha mesclado seu trabalho.

O foco aqui é fazer com que funcione tão bem quanto o OpenCL, ou fazê-lo realmente rodar mais rápido? Eu preferiria não uma guerra santa, mas focar em fazê-lo rodar rápido em várias GPUs. O foco do LifeIsStrange é fazê-lo funcionar em GPUs AMD e então o HIP faz sentido. Para outros o foco é fazer funcionar em GPUs Intel ou Android, e aí o OpenCL faz muito mais sentido. As linguagens de GPU são uma bagunça, então, por favor, seja prático,

Se eu ler alguns dos comentários aqui, o desempenho é um problema com as portas OpenCL. Mas infelizmente não consigo ver muitos benchmarks por aí. Existem mais benchmarks do que este? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

Pelo que entendi, o benchmarking é difícil se você comparar CUDA com OpenCL, porque você precisa usar hardware diferente. Alegadamente, a nVidia deliberadamente fez/permitiu que sua implementação OpenCL fosse um pouco quebrada, então o benchmarking no mesmo hardware sempre resultará em CUDA com ótima aparência.

Em 12 de fevereiro de 2018 14:26:11 GMT+00:00, VincentSC [email protected] escreveu:

O foco aqui é fazer com que funcione como lomg-como-é-OpenCL, ou
tornando-o realmente mais rápido? Eu preferiria não uma guerra santa, mas
concentrando-se em fazê-lo rodar rapidamente em várias GPUs. LifeIs Strange's
o foco é fazê-lo funcionar em GPUs AMD e, em seguida, o HIP faz um bom
senso. Para outros, o foco é fazê-lo funcionar em GPUs Intel ou
Android e, em seguida, OpenCL faz muito mais sentido. As linguagens GPU são um
bagunça, então, por favor, seja prático,

Se eu ler alguns dos comentários aqui, o desempenho é um problema com o
Portas OpenCL. Mas infelizmente não consigo ver muitos benchmarks por aí.
Existem mais benchmarks do que este?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -364936498

--
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Comparar apenas 2 números não é informação - quem se importa se o OpenCL na NVidia roda na metade da velocidade se roda na velocidade 4x em outras GPUs?

Acho que precisaríamos desses benchmarks:

1. CUDA em GPUs NV (benchmarks de referência)
2. https://github.com/hughperkins/tf-coriander em GPUs AMD, Nvidia e Intel
3. https://github.com/benoitsteiner/tensorflow-opencl em GPUs AMD, Nvidia e Intel
4. https://github.com/lukeiwanski/tensorflow em GPUs AMD, Nvidia e Intel

Os benchmarks de referência são fáceis de serem encontrados. Temos algumas GPUs de ponta aqui, então só precisamos de um lugar para colocar os números (com links para documentos de construção).

Suporte OpenCL Deve se tornar verdade.

cuda muito limitado e a nvidia não quer compartilhá-lo.
cuda só funciona para gpus Nv.
que é um beco sem saída para o TensorFlow,
se outro "TensorFlow" sair, mas mais suporte que o TensorFlow.
se o TensorFlow ainda suportar apenas cuda no Windows.
você tem que perceber que o TensorFlow não é a única escolha.

Por que o OpenCL é melhor que o HIP? Eu acho que o OpenCL falhou em ganhar força e o suporte ao OpenCL neste momento provavelmente é contraproducente e perda de recursos para toda a comunidade/indústria. Prefiro ver o TensorFlow oferecer suporte direto ao HIP e deixar o compilador/ferramenta/biblioteca cuidar da portabilidade.

Não é melhor que o software suporte 1 modelo de linguagem/programação?

O software tem que suportar o que tem que suportar para cobrir todos os casos de uso.
HIP é tudo de sinos e assobios (pelo menos no papel) se você tiver hardware suportado. Mas não há apenas "placas amd e nvidia mais recentes" para este mundo.

Agora, por favor, pelo amor de deus, reclame aqui por qualquer problema com isso.
E aqui para todos os demais interessados ​​na continuação desta edição.

Eu pensei que o SPIR-V substituiria diretamente o CUDA como uma alternativa de hardware cruzado:
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

Por que o Google ainda depende do CUDA?

Estes podem ajudar?

Geração de números aleatórios OpenCL (Thomas Wang):

uint wang_hash(uint seed)
{
               seed = (seed ^ 61) ^ (seed >> 16);
               seed *= 9;
               seed = seed ^ (seed >> 4);
               seed *= 0x27d4eb2d;
               seed = seed ^ (seed >> 15);
               return seed;
}

void wang_rnd_0(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(id);
               intSeeds[id]=rndint;
}

float wang_rnd(__global unsigned int * intSeeds,int id)                
{
               uint maxint=0;
               maxint--;
               uint rndint=wang_hash(intSeeds[id]);
               intSeeds[id]=rndint;
               return ((float)rndint)/(float)maxint;
}


// initialize each thread's own random number seed
__kernel void rnd_0(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               wang_rnd_0(intSeeds,id);     
}

// get a new random value by each thread
__kernel void rnd_1(__global unsigned int * intSeeds)
{
               int id=get_global_id(0);
               float randomFloat=wang_rnd(intSeeds,id);
}

OpenCL SHA3hashing (esqueci quem escreveu isso)

https://gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Remova o responsável, pois este problema está convidando contribuições externas. Caso contrário, remova o rótulo contributions welcome . Obrigada.

Remova o responsável, pois este problema está convidando contribuições externas. Caso contrário, remova o rótulo contributions welcome . Obrigada.

É do interesse do Google oferecer suporte ao OpenCL,
ao ter um hardware específico de uma empresa/marca/fornecedor como uma dependência do seu software, você se obriga a pagar mais pelo hardware, a concorrência no mercado reduz os custos.
O Google sempre foi sobre hardware de commodities desde o início, o que foi e ainda é crucial para o sucesso do Google (domínio de mercado), tendo custos operacionais mais baixos de data center, permitindo as ofertas revolucionárias generosas de serviços essencialmente gratuitos, como Gmail (espaço de armazenamento) e Google Fotos (espaço de armazenamento espaço e marcação automática).

@wesamco Não, não é necessariamente do interesse do Google. Eles fazem seu próprio hardware - algo chamado "TensorBoard", IIRC. Eles podem ignorar OpenCL e CUDA / CUDnn e fazer com que a placa execute o código bruto do TensorFlow.

código bruto do TensorFlow.

Não existe tal coisa - não é como alimentos não processados. As TPUs precisam de sua própria biblioteca DNN que lida com os diferentes tipos de chamadas.

Parece que é hora de comprimir a discussão acima em uma lista novamente:

• CodePlay está trabalhando em um back-end SYCL
• Hugh Perkins está trabalhando em tf-coentro
• AMD está trabalhando em um back-end HIP
• PlaidML suporta apenas CPUs no momento.
• O status do suporte para GPUs Intel não é claro.

Então escolha um projeto que você goste e comece a apoiá-lo. Talvez cada um dos grupos possa dar uma atualização de status em seu projeto?

Entenda que o OpenCL foi transformado de um idioma completo para uma definição de idioma/especificação de hardware que é representada em SPIRV (kernels), que pode ser executado em uma plataforma como drivers OpenCL e, posteriormente, também em drivers Vulkan (plataformas). Então, ao suportar SYCL, você também suporta OpenCL.

Resumo perfeito, mas plaidml também roda em gpus.
É só que no momento eles são um backend para keras, não tensorflow. Então é meio OT lá.

Olá a todos,
@VincentSC obrigado pela grande soma dos diferentes esforços!

Então escolha um projeto que você goste e comece a apoiá-lo. Talvez cada um dos grupos possa dar uma atualização de status em seu projeto?

A abordagem SYCL suporta uma variedade de plataformas/dispositivos agora. Os que posso citar são:

• GPUs AMD (FirePro W8100, R9 Nano e R9 380 Series) Instruções disponíveis aqui ou aqui
• ARM Mali (HiKey 960) Instruções disponíveis aqui
• GPU Intel (série SkyLake) com driver Intel NEO OpenCL

Quando se trata de AMD, no momento as GPUs mencionadas acima estão usando os drivers AMDGPU-Pro 17.40-xxx com OpenCL legado habilitado.
Não vejo nenhuma razão óbvia para que outras séries não funcionem (com a suposição de que SPIR / SPIR-V é suportado)

A principal plataforma em que estamos focando é o Linux - no entanto, temos esforços contínuos para habilitar o Windows no futuro. Não temos planos de oferecer suporte ao OSX em um futuro próximo. Eu sei cara triste.

Nosso foco é melhorar o desempenho das CNNs. O desempenho atual não está otimizado e nem perto de onde o vemos terminar. Dito isso, já estamos superando o desempenho da CPU para a maioria dos modelos em diferentes alvos.

Para acelerar o ciclo de desenvolvimento e reduzir o tempo geral de compilação do TensorFlow (assim como melhorar a portabilidade), estamos trabalhando nas bibliotecas Eigen, BLAS e DNN.
Essas bibliotecas visam resolver o problema de desempenho, além de criar um ecossistema de bibliotecas portáteis que podem ser facilmente integradas a projetos complexos como o TensorFlow.

Abaixo, veja os gráficos de desempenho que podemos compartilhar no momento. Eles são retirados do meu fork https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu em 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
O benchmark usado é https://github.com/tensorflow/benchmarks

O gráfico é normalizado para os resultados do Intel i7-4790K.

Estamos atualizando lentamente as mudanças para o Eigen, uma vez que isso aconteça, seguiremos com o TensorFlow.

Espero que ajude,
Lucas

Para inferência de aprendizado profundo em dispositivos móveis com suporte a GPU/OpenCL, você pode verificar o MACE , que é otimizado para GPUs Adreno, Mali e PowerVR. Aqui estão alguns resultados de benchmark .

@keryell @benoitsteiner , qual versão do tensorflow e trisycl são necessárias para integração. Estou tendo problemas para construir o tensorflow (1.9) com a versão mais recente do trisycl.

Infelizmente, o TensorFlow mais recente está usando recursos mais avançados do que o triSYCL atual pode suportar, então você precisa usar o ComputeCpp, atualmente a única implementação SYCL totalmente compatível...

O Tensorflow é suportado pelo Google Brain, e o Google tem parceria com a nVidia, acho que não devemos esperar que o Tensorflow suporte OpenCL
É necessário um grande esforço da comunidade OpenCL

Suporte OpenCL por favor!

OpenCL é mais adequado para nós também.

@Makhaon Eu também. Eu não posso comprar uma máquina com placa gráfica NVIDIA.

Além dos 2 posts acima, gostaria de acrescentar que agora as GPUs Vega da AMD (incluindo as dentro das APUs Raven Ridge) podem fazer FP16 com o dobro do FLOPS, então se o TF pudesse suportá-las (através do OpenCL), isso realmente ajudaria as pessoas com menos orçamento. Além disso, muitas dessas pessoas seriam estudantes, e se conseguirmos que eles usem o TF como ponto de partida de sua jornada DNN, eles provavelmente continuariam com o TF no futuro e até falariam aos outros sobre o TF; é uma ótima maneira de ajudar a expandir este projeto.

Acho que esse tópico não tem sentido para os desenvolvedores (muito barulho - e adicionarei mais ;-), mas acho que muitos comentários estão perdendo o ponto:
Se você deseja executar o Tensorflow com placas AMD, o OpenCL NÃO É o que você está procurando - acesse https://github.com/ROCmSoftwarePlatform/ e instale a pilha ROCm. A estratégia atual da AFAIK AMD é baseada em ROCm em vez de OpenCL para Tensorflow/pytorch .

O OpenCL genérico era muita manutenção/não oferecia benefícios de desempenho suficientes para valer a pena para a AMD. Portanto , este ticket só é interessante se você estiver executando (por exemplo) uma plataforma ARM que usa apenas OpenCL.

(Isenção de responsabilidade: apenas uma pessoa de fora, sem real dentro do desenvolvimento do Tensorflow, então talvez as informações acima estejam completamente erradas e enganosas. Sinta-se à vontade para me criticar se você souber melhor.)

Apenas um pensamento, e quanto ao llvm com o novo descarregamento da GPU? Isso colocaria um grande nível de abstração entre tensorflow e código específico cuda.

E quanto a todos vocês lendo apenas 10 posts acima e percebendo que já existe um fork de lukeiwanski/codeplaysoftware que você pode tentar?
(também meu chapéu para xiaomi por, uma vez, contribuir com algum tipo sério de esforço de código aberto)

@FelixSchwarz Só para você saber que o ROCm usa OpenCL, é o driver OpenCL do espaço de usuário da AMD no Linux (é por isso que não suporta o Windows), então se você não sabe como o ecossistema de drivers da AMD no Linux funciona, eles têm seus drivers do lado do kernel AMDGPU e AMDKFD (que agora está sendo mesclado ao AMDGPU), existem os drivers de espaço do usuário RadeonSI (para OpenGL) RadV/AMDVLK (para Vulkan) e ROCm (para OpenCL).

A julgar pela dinâmica deste bug e de outros forks, o Google não tem interesse nisso e nunca implementará isso no repositório oficial. Eu votaria para fechar esta edição (ou bloqueá-la) para não dar falsas esperanças para todos.

A questão deveria estar aqui para pelo menos apontar aqui todas as pessoas que irão
inevitavelmente, abri-lo novamente.

No sábado, 15 de setembro de 2018, 09:45 Anton Kochkov [email protected] escreveu:

A julgar pela dinâmica deste bug e outros forks, o Google tem zero
interesse nisso e nunca implementará isso no
repositório. Eu votaria para encerrar esta questão (ou bloqueá-la) para
não dê falsas esperanças para todos.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Existe um TensorRT que suporta o Movidius Pi Hat. E esse Movidius Pi Hat é o "AIY ​​Vision Kit" de US $ 45 do Google. O Google vincula-se ao Target para comprá-lo.

Isso não tem nenhum vínculo com CUDA ou Nvidia? Diz que usa um chip Intel. No fundo, talvez o chip seja um FPGA? Alguém sabe mais alguma coisa sobre isso?

Eu sei um pouco sobre a grande unidade Movidius - é apenas inferência e executa modelos pré-compilados do TensorFlow ou Caffe. IIRC eles estão todos no modo de 16 bits.

O chip Movidius em si é muito mais poderoso, mas você precisa ser um parceiro qualificado para obter o SDK.

Tem algum link para outros que tentem ter o 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 (o repositório está desatualizado)
https://github.com/codeplaysoftware/tensorflow
Talvez valha a pena verificar também:

https://documen.tician.de/pyopencl/
https://pypi.org/project/DeepCL/
https://www.khronos.org/sycl/

Sinta-se à vontade para adicionar projetos de trabalho.

Existe alguma atualização? Esta questão tem mais de 3 anos.

SIM, É SÓ OLHAR PARA O ÚLTIMO PUNHADO DE POSTS.

@ filips123 não, não há atualizações e nunca haverá em nenhum futuro previsível - a probabilidade disso é menor do que a invasão alienígena e encontrar uma maneira de viajar no tempo.

Esta iniciativa Intel PlaidML funciona razoavelmente bem, vale a pena conferir.
https://github.com/plaidml/plaidml
Ele roda em opencl OR metal no mac. Funciona com o Macbook Pro AMD gpus, que é o que eu estava procurando.
Enquanto isso, vocês poderiam ajudar a votar no suporte do Pytorch no PlaidML? https://github.com/plaidml/plaidml/issues/63

PlaidML certamente é tudo de bom e elegante (eu, por exemplo, de alguma forma, poderia obter mais desempenho em uma gpu nvidia em opencl do que com o próprio cuda do tf).
Mas é um backend para keras? Em substituição completa ao tensorflow, que você sabe, é o repositório em que estamos discutindo isso?
(por mais que eu pareça entender que as versões mais recentes do tf podem exportar modelos diretamente para keras?

De qualquer forma, pela quarta maldita vez, se você quiser uma solução recente no opencl e algo ainda sendo desenvolvido ativamente ( e também a coisa com as chances reais de ser mesclada aqui de verdade um dia), há apenas uma pilha de codeplay.
Novamente:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

PlaidML certamente é tudo de bom e elegante (eu, por exemplo, de alguma forma, poderia obter mais desempenho em uma gpu nvidia em opencl do que com o próprio cuda do tf).
Mas é um backend para keras? Em substituição completa ao tensorflow, que você sabe, é o repositório em que estamos discutindo isso?
(por mais que eu pareça entender que as versões mais recentes do tf podem exportar modelos diretamente para keras?

De qualquer forma, pela quarta vez, se você quiser uma solução recente no opencl e algo ainda sendo desenvolvido ativamente (_e também_ a coisa com as chances reais de ser mesclada aqui de verdade um dia), há apenas uma pilha de codeplay.
Novamente:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/amd_gpu

Minhas desculpas, eu não tinha percebido que não havia suporte ao tensorflow. Meu cérebro presumido pensou que suporte gpu keras == suporte tensorflow.

plaidML é super legal. Funciona em keras.
Claro que tive que transferir algum código tf para keras puros para trabalhar no backend plaidML (por exemplo tf.image.ssim)
Mas resultado - meu código funciona em placas NVIDIA e AMD.

Também plaidML é o paraíso para os pesquisadores. Ele gera automaticamente gradiente para qualquer função que você escrever na linguagem "Tile" e funcionará em sua GPU com 80% de velocidade de tensorflow.

Então, não consigo entender por que os pesquisadores de ML ainda usam o PyTorch? Vamos impulsionar a ciência do ML com o plaidML da Intel?

@iperov Quer saber porque praticamente ninguém usa PlaidML ?

1. Ele roda lamentavelmente lento nas implementações OpenCL da AMD em comparação com o backend CUDA do Tensorflow, então há pelo menos metade do motivo para usá-lo. Desempenho tão ruim que usar o Tensorflow com CPUs é competitivo ou até mesmo supera seu hardware usando PlaidML?

2. Ninguém está interessado em manter sua linguagem de programação Tile especializada na qual apenas alguém como um professor de matemática pura inventaria, então a qualidade do código do PlaidML simplesmente vai pelo ralo e nenhum programador sério em sã consciência gostaria de lidar com código excessivamente inteligente ...

3. Isso se encaixa no número 2, mas desde que a Intel comprou a Vertex.AI, eles não se importam mais com o PlaidML. A solução da Intel para aprendizado de máquina acelerado por computação por GPU está introduzindo um novo compilador especificamente para aprendizado profundo, agora conhecido como nGraph , para direcionar Tensorflow, PyTorch ou outras estruturas de aprendizado profundo como back-end para eles. Não há razão para eles continuarem desenvolvendo o PlaidML como seu intermediário quando eles têm nGraph ...

As pessoas usam o PyTorch por outros motivos, como manutenção ou outros recursos, para resumir, o PlaidML é a ferramenta da Intel e provavelmente não pretende que ele desempenhe qualquer papel nas partes finais de seus planos. O atual backend de GPU da Intel da nGraph é baseado no OpenCL 2.1, do qual apenas a Intel tem uma implementação compatível, então a Intel existe apenas para cuidar de si mesma e não apenas para melhorar o aprendizado de máquina. Quando a Intel continua desenvolvendo o nGraph, não consigo vê-los continuar baseando seu back-end de GPU no OpenCL 2.1 sozinho, já que muitos frameworks de aprendizado profundo têm kernels modelados que não são compatíveis com os modelos de programação de origem separada do OpenCL, Metal ou Vulkan, então provavelmente é apenas para fins de experimentação. O back-end final da GPU da Intel provavelmente será baseado no SYCL 2.2 ou em algo totalmente diferente como o OpenMP e talvez eles até tragam uma solução específica do fornecedor ...

Quanto à AMD, quem se importa? OpenCL é irrelevante para eles e finalmente estão mostrando alguns resultados com seu trabalho no HIP...

@iperov Quer saber porque praticamente ninguém usa PlaidML ?

1. Ele roda lamentavelmente lento nas implementações OpenCL da AMD em comparação com o backend CUDA do Tensorflow, então há pelo menos metade do motivo para usá-lo. Desempenho tão ruim que usar o Tensorflow com CPUs é competitivo ou até mesmo supera seu hardware usando PlaidML?
2. Ninguém está interessado em manter sua linguagem de programação Tile especializada na qual apenas alguém como um professor de matemática pura inventaria, então a qualidade do código do PlaidML simplesmente vai pelo ralo e nenhum programador sério em sã consciência gostaria de lidar com código excessivamente inteligente ...
3. Isso se encaixa no número 2, mas desde que a Intel comprou a Vertex.AI, eles não se importam mais com o PlaidML. A solução da Intel para aprendizado de máquina acelerado por computação por GPU está introduzindo um novo compilador especificamente para aprendizado profundo, agora conhecido como nGraph , para direcionar Tensorflow, PyTorch ou outras estruturas de aprendizado profundo como back-end para eles. Não há razão para eles continuarem desenvolvendo o PlaidML como seu intermediário quando eles têm nGraph ...

As pessoas usam o PyTorch por outros motivos, como manutenção ou outros recursos, para resumir, o PlaidML é a ferramenta da Intel e provavelmente não pretende que ele desempenhe qualquer papel nas partes finais de seus planos. O atual backend de GPU da Intel da nGraph é baseado no OpenCL 2.1, do qual apenas a Intel tem uma implementação compatível, então a Intel existe apenas para cuidar de si mesma e não apenas para melhorar o aprendizado de máquina. Quando a Intel continua desenvolvendo o nGraph, não consigo vê-los continuar baseando seu back-end de GPU no OpenCL 2.1 sozinho, já que muitos frameworks de aprendizado profundo têm kernels modelados que não são compatíveis com os modelos de programação de origem separada do OpenCL, Metal ou Vulkan, então provavelmente é apenas para fins de experimentação. O back-end final da GPU da Intel provavelmente será baseado no SYCL 2.2 ou em algo totalmente diferente como o OpenMP e talvez eles até tragam uma solução específica do fornecedor ...

Quanto à AMD, quem se importa? OpenCL é irrelevante para eles e finalmente estão mostrando alguns resultados com seu trabalho no HIP...

E quanto a toda a GPU dentro da máquina do braço, como telefones celulares e framboesa pi odroid e etc?
Eles não suportam opencl?
O Google deve se preocupar em inserir o tensorflow na gpu no android.
As maiores bibliotecas de treinamento de redes neurais rodam apenas em gpu da Nvidia, apenas tornam a gpu da Nvidia cada vez mais cara (porque pessoas e empresas só a compram para treinamento de rede neural profissional), então o Google perderá mais dinheiro dessa maneira.

@Degerz de qual planeta você veio?
Como você pode comparar tf-CPU e GPU AMD?
GPU AMD em plaidML x30 mais rápido que tf-CPU

1. Ele roda lamentavelmente lento nas implementações OpenCL da AMD em comparação com o back-end CUDA do Tensorflow, então há pelo menos metade do motivo para usá-lo

nos meus testes de deepfakes o OpenCL é mais lento apenas 20%, mas em algumas mini redes o OpenCL é 20% MAIS RÁPIDO.

Meu projeto DeepFaceLab tem muitos usuários que estão esperando o suporte da AMD. Quantas pessoas ficaram encantadas quando os deepfakes finalmente podem ser treinados em placas AMD.
Além disso, plaidML é o único back-end para keras que suporta AMD/IntelHD pronto para uso.
Se um novo backend AMD para keras aparecer, é claro que meu projeto mudará para ele.
PyTorch não tem futuro.

O que manter no plaidML? As operações são auto diferenciáveis, não há nada para manter.

Linguagem de programação Tile na qual apenas alguém como um professor de matemática pura inventaria

O aprendizado de máquina é inventado por professores de matemática, não é?

@talregev E quanto ao ARM ou Broadcom? O primeiro provavelmente tem uma implementação de OpenCL abaixo da média e o último nem fornece oficialmente drivers OpenCL! Não é responsabilidade do Google criar e manter uma pilha de computação competente para fornecedores de hardware...

@iperov Você percebe que treinar redes neurais com camadas de incorporação no PlaidML é doloroso, certo? O PlaidML também tem várias outras limitações, como não ser tão adequado para DenseNets ou o fato de que seus gráficos de computação são estáticos e o PlaidML funciona bem com RNNs?

Quanto ao seu projeto, não se preocupe. Você passará para algo melhor como o Tensorflow, já que a AMD em breve oferecerá um back-end de GPU nativo para ele assim que o MIOpen for upstream, que é sua biblioteca de primitivas acelerada por GPU para redes neurais profundas semelhantes à biblioteca cuDNN do concorrente, que deixarão o PlaidML em a poeira em termos de desempenho. Quem se importa com as iGPUs da Intel? Se a Intel estiver realmente comprometida em fornecer aprendizado profundo de alto desempenho em seu futuro hardware gráfico discreto, eles oferecerão uma opção de fonte única, assim como os outros (AMD/HIP e Nvidia/CUDA) fizeram antes deles ...

PyTorch não tem futuro.

Inveja muito? O PyTorch é ~10x mais popular que o PlaidML, as técnicas mais recentes em DL são implementadas facilmente no PyTorch, toneladas de contribuidores diferentes e são desenvolvidas ativamente pelo Facebook enquanto a Intel não contribui para o PlaidML há quase um mês?

O que manter no plaidML? As operações são auto diferenciáveis, não há nada para manter.

Então, deduzo de você que o PlaidML não deve receber novas correções ou novos recursos no futuro? Se você não vê o valor em melhorar o código, não faz sentido convencê-lo a reconhecer as falhas gritantes do PlaidML ...

O aprendizado de máquina é inventado por professores de matemática, não é?

Não significa que temos que adotar qualquer linguagem de programação que eles componham, especialmente no caso do Tile, onde a elegância é claramente favorecida em relação à legibilidade. Não é de admirar por que tantos contribuidores em potencial estão com medo de contribuir ...

Jesus, desejo a vocês STFU e voltem ao trabalho. Vou ter que cancelar a assinatura do ticket porque é insuportável receber e-mails com flame wars. Os mantenedores ruins não silenciam o thread.

@gunan @caisq @sanjoy Você poderia fazer algo sobre isso?