Tensorflow: Dukungan OpenCL

Dibuat pada 9 Nov 2015  ·  541Komentar  ·  Sumber: tensorflow/tensorflow

Saya mengerti TensorFlow hanya mendukung CUDA. Apa yang perlu dilakukan untuk menambahkan dukungan OpenCL?

contributions welcome

Komentar yang paling membantu

Aneh bahwa Google membuang OpenCL terbuka untuk CUDA berpemilik.
im-just-saying

Semua 541 komentar

Aneh bahwa Google membuang OpenCL terbuka untuk CUDA berpemilik.
im-just-saying

Paling tidak, perpustakaan Eigen harus mendukung OpenCL.

:+1:

:+1:

:+1:

acungan jempol dan semua itu.

Saya akan tertarik untuk memperluas Tensor Flow dengan OpenCL. Seperti yang telah kami rilis OpenCL caffe. https://github.com/amd/OpenCL-caffe. Semoga bisa terintegrasi dengan cara yang ringan? Adakah yang tertarik untuk bekerja sama dalam hal ini?

@gujunli Senang melihat AMD di sini. /cc @naibaf7 @lunochod

akan sangat bagus.

:+1:

/cc @lukeiwanski untuk Eigen/OpenCL/SYCL

@gujunli Pasti akan tertarik untuk berkontribusi. Tolong beri tahu saya kapan Anda berencana untuk memulai.

Halo semua,

Di sini, di Codeplay, kita melihat tensor Eigen yang berjalan di GPU menggunakan SYCL (lapisan C++ modern di atas OpenCL). Dari apa yang telah kami kumpulkan sejauh ini, desain tensor GPU sangat erat digabungkan dengan CUDA dan akan memerlukan perubahan antarmuka untuk model pemrograman lain dan khususnya versi SYCL dan OpenCL 1.2.

Jika ada yang tertarik untuk menggali lebih dalam / membantu, kami pasti tertarik untuk berkontribusi.

Terima kasih,
Lukas

@lukeiwanski Terima kasih atas umpan baliknya. Saya pikir @benoitsteiner bekerja di bagian ekstensi tensor eigen.

:+1: Saya dapat membantu mengkodekan beberapa OpenCL/SYCL jika seseorang membuat rencana, membagi pekerjaan menjadi tugas, dll. Saya sarankan menggunakan Boost.Compute sebagai pembungkus untuk OpenCL (itu membuat menjalankan kernel, pengujian, templating lebih mudah).

+1

:+1:

Halo semua,

Sekadar informasi, kami masih menyelidiki bagaimana kami dapat mengubah antarmuka Eigen agar lebih sesuai dengan model pemrograman SYCL/OpenCL 1.2.
Setelah kami menemukan pendekatan yang masuk akal yang menargetkan model pemrograman heterogen ( tidak hanya OpenCL / SYCL ) kami akan membuat proposal.

Terima kasih,
Lukas

Tolong terus perbarui saya. Saya mengembangkan opencl-caffe untuk AMD. Saya juga melihat
aliran tensor.

Terima kasih.
Junlu
Pada 8 Desember 2015 10:19, "Luke Iwanski" [email protected] menulis:

Halo semua,

Hanya untuk memberi tahu Anda, kami masih menyelidiki bagaimana kami dapat mengubah
Antarmuka Eigen agar lebih sesuai dengan model pemrograman SYCL/OpenCL 1.2.
Setelah kami menemukan pendekatan yang masuk akal, kami akan membuat proposal.

Terima kasih,
Lukas


Balas email ini secara langsung atau lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -162967662
.

/cc @ptillet @gongzg Apakah ada minat dari Intel? Saya sangat berharap bahwa kami tidak memecah OPENCL di sini seperti di Caffe di mana kami memiliki garpu AMD, PR Intel yang tidak digabungkan, PR AMD semi-tidak resmi lainnya, dan PR pengguna yang lama (ditambah dua upaya Opencl lama yang ditinggalkan). Jika seseorang tertarik dengan sejarah dapat melihat https://github.com/BVLC/caffe/pull/2610 komentar.

@bhack Kami memiliki minat dalam hal ini. Terima kasih telah memberi tahu saya. Jika ada proposal untuk implementasi OpenCL/SYCL Eigen, kami akan melihat apa yang bisa kami lakukan dari sisi Intel.

:+1:

Inisiatif yang menarik di https://github.com/ptillet/isaac juga jika di sini kita mengandalkan ekstensi tensor Eigen.

Saya juga ingin berkontribusi. @benoitsteiner dapatkah Anda mengaturnya?

Ini termasuk dalam Roadmap tetapi juga ditandai sebagai kontribusi sehingga arahan/bootstrap bisa sangat berguna.

Saya dapat berkontribusi untuk mengaturnya. siapa yang bertanggung jawab atas dukungan OpenCL di
Aliran tensor sekarang?

Terima kasih banyak.
Junli

Pada Selasa, 19 Januari 2016 pukul 07:50, bhack [email protected] menulis:

Ini termasuk dalam Roadmap tetapi juga ditandai sebagai kontribusi jadi
arah/bootstrap bisa sangat berguna.


Balas email ini secara langsung atau lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172894538
.


Junli Gu--谷俊丽
Lab Sains Terkoordinasi
Universitas Illinois di Urbana-Champaign


Saya hanya berasumsi Benoit karena dia sendiri yang menetapkan fitur tersebut, tetapi saya pikir Anda sudah mendapatkannya Junli! Mungkin mulai dengan email atau utas forum dari pihak yang berkepentingan?

@benoitsteiner tahu lebih banyak tentang pihak yang berkepentingan yang mungkin tidak muncul
di utas ini (atau masalah ini). Saya akan menunggu dia berkoordinasi untuk membuat
yakin kami menghindari duplikasi pekerjaan.

Pada Selasa, 19 Jan 2016 pukul 11:42 Dan McLaughlin [email protected]
menulis:

Saya hanya berasumsi Benoit karena dia menetapkan sendiri fitur itu, tapi saya pikir
Anda punya itu Junli! Mungkin mulai dengan email atau utas forum
pihak yang berkepentingan?


Balas email ini secara langsung atau lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.

Saya tertarik. Apakah ada peta jalan?

Pada 19 Januari 2016, pukul 11:46, Martin Wicke [email protected] menulis:

@benoitsteiner tahu lebih banyak tentang pihak yang berkepentingan yang mungkin tidak muncul
di utas ini (atau masalah ini). Saya akan menunggu dia berkoordinasi untuk membuat
yakin kami menghindari duplikasi pekerjaan.

Pada Selasa, 19 Jan 2016 pukul 11:42 Dan McLaughlin [email protected]
menulis:

Saya hanya berasumsi Benoit karena dia menetapkan sendiri fitur itu, tapi saya pikir
Anda punya itu Junli! Mungkin mulai dengan email atau utas forum
pihak yang berkepentingan?


Balas email ini secara langsung atau lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -172963537
.


Balas email ini secara langsung atau lihat di GitHub.

Apakah ada daftar pustaka ketergantungan CUDA yang diandalkan Tensorflow?

Ini akan membantu untuk melihat apakah kita dapat memiliki alternatif OpenCL segera.

@hsaputra
Ada clFFT, clBLAS (atau ViennaCL). Generator angka acak sedikit lebih rumit (tidak ada curand), baik menggunakan generator CPU dan mentransfer ke GPU atau menggunakan kernel lain yang ada untuk RNG.

Perangkap terbesar lagi-lagi adalah implementasi konvolusi yang efisien (seperti cuDNN).

Ada pengalaman tentang masalah seperti itu di sini:
https://github.com/BVLC/caffe/pull/2610
https://github.com/BVLC/caffe/pull/2195
https://github.com/amd/OpenCL-caffe

Tensorflow menggunakan ekstensi tensor yang di-upstream ke Eigen. Jadi saya pikir dukungan Opencl/Sycl untuk Eigen diperlukan. Lihat utas ini

Terima kasih @naibaf7. Ya, saya tidak berpikir ada alternatif yang layak untuk cuDNN untuk OpenCL sekarang.

Situs web http://opencl.org dibuat untuk mendukung proyek porting sumber terbuka seperti ini! Kami sedang menginstal semua alat yang diperlukan di situs web dan memiliki ruang untuk repositori di https://github.com/OpenCL/ - nanti kami menambahkan server build untuk menguji beberapa jenis perangkat keras dan dapat memberikan keahlian kami dalam cara menulis kode yang berjalan dengan kecepatan penuh di berbagai perangkat keras.

Kami meluncurkan inisiatif porting untuk GEGL minggu depan, tetapi kami juga senang mendukung Anda.

@bhack dari utas itu dan di sini sepertinya @lukeiwanski sedang menyelidikinya. Saya pikir kami memiliki cukup banyak orang yang bersedia untuk mengerjakannya, kami hanya perlu @benoitsteiner , @lukeiwanski atau @gujunli untuk berkoordinasi. Benoit sudah diam, mungkin dia sedang berlibur.

Saya akan senang untuk membantu berkontribusi dengan inisiatif ini.

Halo semua,

kami akan mengoordinasikan upaya porting modul tensor Eigen ke SYCL untuk OpenCL karena kami sudah memiliki sesuatu yang sebagian besar berfungsi, tetapi belum siap untuk ditinjau.

Kami mendukung pendekatan ini karena akan memperkenalkan lebih sedikit invasi ke basis kode. SYCL mendukung model template C++ sumber tunggal yang sudah digunakan eigen.

Desain peta jalan sedang dalam proses jadi seharusnya tidak terlalu lama sekarang.

Terima kasih,
Lukas

@lukeiwanski Apakah Anda bekerja atau berhubungan dengan hulu? Apakah menurut Anda akan diterima di hulu di Eigen?

+1

Berita bagus @lukeiwanski , beri tahu kami bantuan yang Anda butuhkan.

Saya kira Anda menggunakan implementasi SYCL Anda sendiri - apakah itu akan tersedia untuk pengembang/peneliti? Pada platform apa?

@lukeiwanski SYCL sepertinya cara yang tepat mengingat jumlah metaprogramming template yang terlibat dengan Eigen. Saya seorang pengembang c ++ berpengalaman dengan pengalaman OpenCL yang diperoleh dari mengembangkan jaringan saraf dan perpustakaan aljabar linier saya sendiri. Saya ingin membantu upaya ini dan mulai mengembangkan dengan SYCL.

@bhack Kami berhubungan dengan @benoitsteiner , tetapi kami akan mendiskusikan proposal kami dengan pengelola hulu sebelum kami menginvestasikan terlalu banyak upaya.

@DanMcLaughlin , @ville-k Kami sedang mengembangkan implementasi SYCL kami, ComputeCpp (https://www.codeplay.com/products/computecpp). Untuk informasi lebih lanjut, bisakah Anda menghubungi saya di luar daftar melalui alamat email di profil saya?

@lukeiwanski apakah ada pembaruan/perkiraan mengenai rencana?

+1.
Saya memiliki GPU AMD dan GPU Intel di laptop. Saya pikir keduanya memiliki driver OpenCL dan dukungan AMD tampaknya jauh lebih baik. Saya akan memiliki kinerja yang lebih tinggi, karena saya memiliki 2 perangkat OpenCL. Saya harap Anda membuatnya berskala dengan perangkat OpenCL.

Halo semua,

Terima kasih atas minatnya!
Pada titik ini kami menyiapkan infrastruktur pengujian kami untuk memastikan bahwa tidak ada yang kami lakukan yang menyebabkan regresi.
Kami menghubungi @benoitsteiner untuk memastikan kami selaras dengan apa yang telah dia lakukan sejauh ini.

Kami masih menyusun peta jalan untuk proses integrasi - ini harus dilakukan dalam waktu beberapa minggu, karena ada beberapa detail bisnis yang harus diklarifikasi.

Tujuan kami adalah menghadirkan OpenCL ke TensorFlow melalui Eigen pada akhir tahun ini.

Terima kasih,

tertarik. akan senang untuk berkontribusi.

Ok jadi sepertinya ini adalah upaya Codeplay dengan semacam sinkronisasi ke internal Google. Apa peran pelanggan AMD dan Intel di sini?

/cc @keryell jika Anda tertarik dengan ini dari alam semesta SYCL/FPGA

Saya minta maaf karena tidak berkontribusi lebih banyak untuk diskusi ini baru-baru ini, piring saya sudah lebih dari penuh selama 2 minggu terakhir ini.

Saya akan mengoordinasikan upaya OpenCL di sisi TensorFlow. Pemikiran kita saat ini adalah:

  • TensorFlow bergantung pada c++11 dan telah mengambil pendekatan "sumber tunggal", jadi SYCL sepertinya sangat cocok.
  • Kami tidak memiliki banyak pengalaman OpenCL di rumah, jadi kami berkolaborasi erat dengan Codeplay untuk menjembatani kesenjangan ini. Secara khusus, Codeplay saat ini memimpin upaya untuk menambahkan dukungan untuk SYCL ke library tensor Eigen.
  • TensorFlow mengandalkan library cuDNN untuk menghitung konvolusi pada GPU NVidia. Jika seseorang tertarik untuk berkontribusi setara dengan OpenCL, kami akan dengan senang hati membantu.

Untuk membantu menyusun upaya, saya membuat milis: [email protected].

@bhack yakin saya tertarik dengan C++ kelas atas di FPGA :-)
TensorFlow terdengar seperti kasus penggunaan validasi yang baik untuk triSYCL juga.
Omong-omong, jika beberapa orang di sini mencari beberapa magang tentang hal ini, saya memiliki beberapa posisi. Sepertinya Codeplay juga mencari beberapa orang, jika saya mempercayai situs web mereka.

Saya sangat tertarik dengan pendapat @karlrupp dan @hughperkins . Saya berharap mereka ingin bergabung dalam diskusi di grup google baru.

@benoitsteiner Terima kasih atas pembaruannya. Akan sangat bagus jika semua mitra yang terlibat di @KhronosGroup (Google, Nvidia, Amd, Intel, Codeplay, Xilinx dll.) akan mempromosikan cudnn seperti API dengan cara yang terstandarisasi. Semacam upaya standarisasi visi komputer Khronos openvx tetapi untuk pembelajaran mendalam.

@bhack Grup Google baru yang mana?

Selain itu, OpenCL dan CUDA adalah pendekatan pemrograman yang terlalu berbeda. CUDA bekerja seperti itu karena satu perusahaan memiliki kendali penuh atas segalanya, sehingga dapat menyematkan gumpalan biner dan siapa yang tahu apa yang dapat dieksekusi akhir. Ini tidak dapat dilakukan dengan OpenCL, kecuali jika ada yang mengikuti jalur SyCL (saya memiliki kekhawatiran ...) dan vendor kompiler SyCL memiliki kontrol penuh atas semua kemungkinan arsitektur target (tidak mungkin atau tidak mungkin dalam praktiknya). Secara keseluruhan, pendapat saya adalah bahwa perpustakaan berkemampuan OpenCL yang baik membutuhkan lebih dari sekadar beberapa penyesuaian di sana-sini. Mungkin bukan yang ingin Anda dengar, tetapi Anda meminta pendapat saya :-)

@karlrupp Lihat https://github.com/tensorflow/tensorflow/issues/22#issuecomment -176406416 di akhir untuk grup google.
Saya meminta pendapat Anda karena Anda memiliki pengalaman hebat dengan ViennaCL menghubungkan perpustakaan aljabar dengan banyak backend (CPU, GPU, MIC). Tensorflow mengandalkan perpustakaan Eigein dan ekstensi tensor barunya yang disumbangkan oleh Google upstream (tetapi hanya dengan backend CUDA). Saya pikir mereka tidak mengalami banyak kesulitan yang telah Anda temui dengan ViennaCL dalam tahun-tahun pengembangan ini.

@bhack Kami sedang dalam pertemuan tatap muka di Seattle minggu ini tapi tentu saja saya tidak bisa mengatakan apakah kita berbicara tentang perpustakaan DNN atau tidak... :-)

@keryell Cobalah untuk mendorong penyebabnya di Seattle ;)

@karlrupp Anda benar, OpenCL dan CUDA adalah pendekatan pemrograman yang terlalu berbeda. Aspek sumber tunggal yang ditemukan misalnya di CUDA dan OpenMP 4.5 sangat kuat dari perspektif rekayasa perangkat lunak. Inilah sebabnya mengapa ada standar SYCL untuk programmer C++ yang sebenarnya. SYCL dapat dilihat sebagai CUDA pada steroid tanpa ekstensi bahasa apa pun dan dengan beberapa aspek OpenMP (tugas). Kompiler perangkat SYCL tipikal diharapkan menghasilkan kernel SPIR-V.

Kekhawatiran Anda tentang portabilitas bukanlah masalah dengan standar SPIR-V (sejenis portabel yang setara dengan nVidia PTX/AMDIL/... di dunia Vulkan & OpenCL) yang wajib diterima di OpenCL 2.1 dan Vulkan. Jadi keindahannya adalah jika Anda memiliki front-end yang menghasilkan SPIR-V, Anda tidak memerlukan pengetahuan khusus tentang detail perangkat keras untuk menjalankannya. Ada penerjemah dua arah sumber terbuka Khronos antara LLVM IR dan SPIR-V, sehingga membuka wilayah yang cukup baru.

@keryell Saya setuju bahwa SPIR-V adalah langkah maju. Namun, itu tidak mengatasi semua masalah jitting lengkap.

Anda tidak memerlukan pengetahuan khusus tentang detail perangkat keras untuk dijalankan

Apakah ini copy&paste dari pemasaran OpenCL 1.0, yang diklaim sama persis? Anda akan _selalu_ perlu melihat detail perangkat keras yang mendasarinya jika Anda menginginkan kinerja maksimum. Hal ini terutama terjadi dalam konteks kontraksi tensor cepat.

...seperti yang ditunjukkan @scott-gray dengan neon

@karlrupp

Apakah ini copy&paste dari pemasaran OpenCL 1.0, yang diklaim sama persis?

Ha ha. :-)

Anda akan selalu perlu melihat detail perangkat keras yang mendasarinya jika Anda menginginkan kinerja maksimum. Hal ini terutama terjadi dalam konteks kontraksi tensor cepat.

Tentu saja, tetapi sebelum bermain dengan optimasi orde kedua, akan sangat berguna jika sebagian besar dari seluruh kode C++ yang ditemplat berjalan dalam beberapa cara yang dipercepat.

Untuk pengoptimalan, Anda dapat menggabungkan kernel biner yang dioptimalkan la NervanaSys atau, karena SYCL adalah C++ murni, Anda dapat menggunakan asm("...") di dalamnya dengan banyak #ifdef untuk menguji arsitektur target. :-) Yang mengatakan, SPIR-V itu sendiri dapat diperluas dan saya tidak dapat melihat mengapa kami tidak dapat memasukkan VHDL atau Verilog sebaris ke dalamnya di beberapa titik. :-)

Namun secara lebih konkret, pengenalan operasi sub-grup baru-baru ini akan membantu mencapai kinerja yang baik dengan cara yang portabel dan menggunakan fungsi ad-hoc bawaan yang sederhana dapat membantu.

C++ menambahkan fitur metaprogramming menarik yang memungkinkan untuk mengganti sebagian besar pembuat kode yang digunakan seperti di clBLAS atau kerangka kerja lain untuk menghasilkan kode yang lebih disesuaikan dengan perangkat keras X atau Y.

Juga N4355 di c++17 bisa masuk ke dalam game cepat atau lambat

@karlrupp , @bhack Pendekatan tensorflow adalah mengandalkan abstraksi perangkat keras (modul tensor) untuk sebagian besar operasi yang diperlukan oleh jaringan saraf biasa, sambil mengandalkan pustaka khusus (seperti cudnn) untuk beberapa operasi yang kinerja benar-benar kritis bijaksana. Abstraksi perangkat keras memungkinkan kami untuk mengimplementasikan sebagian besar operasi TensorFlow satu kali dan menjalankannya pada akselerator dengan kinerja yang lebih dari cukup.

@bhack Ya saya suka array multidimensi. Juga dalam domain minat kami, ada SG14 di komite C++ yang mencoba membuat semua orang yang tertarik dengan masalah ini menyatu ke dalam standar.
https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
Tentu saja SYCL sedang dalam diskusi. :-)

@benoitsteiner Terutama pada cudnn untuk pengumpulan dan konvolusi. Saya pikir jika setiap vendor akan menghasilkan API dengan perangkat kerasnya sendiri untuk operasi ini dengan perakitan binernya sendiri tidak akan menjadi pendekatan yang begitu skalabel. Itulah mengapa saya pikir beberapa panggilan API penting kinerja akan lebih baik untuk distandarisasi dalam beberapa cara.

@keryell Ada topik yang sangat menarik untuk Matrix/Tensor di SG14 c++ baru khususnya dalam agenda panggilan vektor/SIMD. Tetapi tampaknya tidak ada yang berbicara tentang konvolusi, penyatuan, dan antarmuka pembelajaran mendalam "stabil" lainnya yang berguna. Sepertinya saya juga bahwa dalam subkelompok standardisasi khusus ini ada orang-orang dari Nvidia, Intel, Amd, CodePlay dll. tetapi tidak dari Google juga jika ada di grup lain.

:+1:

@bhack Ya, belum ada proposal gaya pembelajaran mesin di SG14. Tetapi partisipasi terbuka, sehingga Anda dapat mengirim beberapa proposal. :-) Tapi mungkin SG6 (topik numerik) lebih relevan. Saya rasa mereka belum memiliki milis/forum sendiri.

@gujunli Apakah OpenCL Caffe berjalan di Android? Maaf untuk menanyakan ini di sini, tetapi saya tidak menemukan tempat lain untuk menanyakannya :) Akan lebih bagus dengan perpustakaan pembelajaran mendalam yang berjalan di perangkat Android _dan_ dapat menggunakan GPU tetapi sepertinya tidak ada saat ini. (Koreksi saya jika saya salah!)

@krikru
Cabang OpenCL Caffe resmi (tetapi eksperimental) dapat dibuat untuk berjalan di GPU Android, namun kinerjanya saat ini jauh dari optimal. Lihat https://github.com/sh1r0/caffe-android-lib/issues/23 dan https://github.com/BVLC/caffe/tree/opencl.

Alternatif nyata untuk cudnn dapat berupa ekstensi objek standar OpenVx dengan dukungan untuk operator Tensor, NdConvolution, NdPooling dan (mungkin) beberapa operator lain yang dapat dianggap dapat distandardisasi.
Tim cudnn juga perlu membuat beberapa pilihan tentang API dan operator baru apa yang akan mereka perkenalkan di setiap rilis. Tentu saja standar tidak dapat bergerak secepat rilis cudnn tetapi saya pikir beberapa operasi dan objek memiliki "riwayat kutipan" yang cukup untuk distandarisasi.

@hughperkins Saat ini, saya belum mencoba perpustakaan pembelajaran mendalam; Saya hanya melakukan pengintaian untuk melihat perpustakaan mana yang berpotensi saya gunakan. Sudahkah Anda mencoba cltorch dan DeepCL di Android? Saya hanya berasumsi cltorch berfungsi di Android, karena ada implementasi Torch yang didedikasikan khusus untuk Android. Dan mengapa Anda memiliki implementasi seperti itu jika sudah ada yang keduanya bekerja di Android _dan_ menggunakan OpenCL, bukan? Tapi mungkin aku seharusnya tahu lebih baik.

@hughperkins Untuk beberapa alasan saya membayangkan bahwa torch-android adalah implementasi Torch resmi untuk Android, artinya tidak ada implementasi Torch lainnya (setidaknya tidak resmi) yang mungkin berjalan dengan lancar di Android, termasuk cltorch. Saya tidak tahu mengapa saya berpikir demikian, tentu saja itu tidak masuk akal.

Yah... Soumith mengoordinasikan pengembangan obor. Dia bekerja di Facebook AI Research. Jadi, karena repo obor-android milik Soumith, saya akan mengatakan itu cukup dekat dengan resmi. Tapi itu mungkin bukan bagian dari inti untuk beberapa alasan. Saya kira Anda dapat mengajukan pertanyaan sebagai masalah di repo itu, atau di https://groups.google.com/forum/#!forum/torch7 Sebenarnya, karena Soumith adalah tipe orang utama yang menangani permintaan di https: //groups.google.com/forum/#!forum/torch7 , saya rasa Anda mungkin ingin memposting pertanyaan Anda di sana.

artinya tidak ada implementasi Torch lain (setidaknya tidak resmi) yang mungkin berjalan dengan lancar di Android, termasuk cltorch

Perhatikan bahwa cltorch bukan merupakan implementatino dari obor. Ini adalah plugin, yang menyediakan OpenCL. Anda membutuhkan keduanya.

Perhatikan bahwa cltorch bukan merupakan implementatino dari obor. Ini adalah plugin, yang menyediakan OpenCL. Anda membutuhkan keduanya.

Ah, terima kasih atas klarifikasinya.

@naibaf7 Apakah cabang OpenCL Caffe dan implementasi OpenCL Caffe oleh AMD memiliki kesamaan selain namanya? Sudahkah Anda membandingkan keduanya atau apakah Anda tahu jika ada perbedaan kinerja? Anda menulis bahwa cabang OpenCL jauh dari kinerja optimal. Apa artinya itu dan apa yang diperlukan untuk memperbaikinya? Akan menarik untuk mencobanya di Android.

Kita keluar topik

@bhack Ya, maaf telah membajak utas ini. Aku hanya tidak tahu harus bertanya kemana.

@krikru
tolong angkat masalah tentang itu di cabang Caffe, tandai dengan Android dan OpenCL. Kemudian kita bisa mendiskusikan ini lebih lanjut. Terima kasih.

@keryell Sepertinya pertemuan f2f SG14 berikutnya di bulan Maret akan diselenggarakan oleh Google . Akankah ada tensorflow internal di sana?

/cc @jfbastien

Mungkin @benoitsteiner bisa mampir, karena dia orang lokal.
Tapi sebelum acara ini ada full C++ F2F di akhir bulan di Jacksonville, Florida.
https://isocpp.org/files/papers/N4568.pdf
Sayangnya saya tidak akan bisa menghadiri salah satu dari mereka.

Saya tidak tahu apakah CppCon 2015 talk C++ Array Multi-dimensi untuk Fisika Komputasi dan Matematika Terapan menghasilkan beberapa tindak lanjut kertas.

+1

@bhack Terima kasih telah mengarahkan pembicaraan tentang array multi-dimensi. Ini menarik dan membahas masalah sebenarnya tetapi terlihat terlalu ad-hoc untuk diratifikasi dalam C++ apa adanya. Secara pribadi saya menggunakan Boost.MultiArray dan saya lebih percaya diri dalam versi Boost.MultiArray yang dipoles.

Ada juga beberapa makalah di WG21 . Seperti yang Anda lihat @jfbastien di Google memiliki beberapa aktivitas di WG21 dan juga membantu menjadi tuan rumah pertemuan SG14 f2f di Google pada bulan Maret.

@bhack @keryell Saya pikir diskusi ini layak dibawa ke milis SG14 karena detailnya tidak terkait dengan OpenCL / tensorflow.

Ya, mungkin tidak lagi dibatasi secara ketat di sini dengan semua detailnya. Selain dukungan Eigen/sycl Apakah ada rencana untuk panggilan cudnn?

+1 topik yang sangat menarik. Semoga segera datang.

Benang ini sangat menarik. Saya sudah mencoba membuat caffe berfungsi di Android. Hasilnya tampaknya mengejutkan: caffe yang berjalan dengan GPU Mali tampaknya 2-3 lebih lambat dari cpu, tetapi sekitar 4-5x lebih hemat energi. Tes dijalankan pada Galaxy S6 (Mali T760, Peak Performance 200 GFlops).

Karena GEMM adalah inti dari konvolusi di caffe, saya memutuskan untuk membuat profil kinerjanya di Android. Tampaknya ViennaCL tidak seefisien beberapa kernel sederhana. Sekarang saya bisa menjalankan GPU secepat CPU untuk matriks besar (2k x 2k). Ini masih kontra-intuitif, karena biasanya kami mengharapkan GPU menjadi jauh lebih cepat.

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

Implementasi kernel dapat ditemukan di sini:

Kernel OpenCL untuk GEMM: https://github.com/strin/gemm-android

Ada pikiran?

@strin Sudahkah Anda mengikuti utas ini https://community.arm.com/thread/4935?

@bhack terima kasih telah berbagi. utas ini terlihat sangat menarik. saya mencoba mematikan DVFS seperti yang disarankan, tetapi tidak ada kinerja signifikan yang terlihat untuk sgemm di ViennaCL.

+1

@strin Sudahkah Anda mencoba versi sgemm terakhir di MALI SDK?

Ini akan berdampak pada strategi: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html?
EDIT:
"StreamExecutor saat ini digunakan sebagai runtime untuk sebagian besar aplikasi GPGPU internal Google, dan cuplikannya disertakan dalam proyek TensorFlow_ open-source, yang berfungsi sebagai runtime GPGPU."

+1

Semoga orang yang mengerjakannya berhasil mengatasi masalah alternatif CUDNN pada saat tensorflow mendekati 1,0

@martinwicke mengapa masalah ini ditutup?

Saya tidak berpikir komit Anda memperbaiki ini.

Anda tidak dapat selalu menggunakan komentar komit yang sama di repositori yang berbeda ;) https://github.com/tensorflow/skflow/issues/22

Oh GitHub

@vrv Sekarang setelah Anda memberi tahu kami, bisakah Anda memberikan umpan balik tentang strategi pelaksana streaming? ;)

Saya hanya akan menyalahkan GitHub untuk semuanya, termasuk kurangnya dukungan OpenCL. ;)

@benoitsteiner mungkin bisa berkomentar lebih banyak. Saya tidak begitu tahu apa yang Anda maksud dengan strategi 'aliran pelaksana'. Kami saat ini menggunakan versi stream executor dan CuDNN dan Eigen dan mereka semua bermain bersama dengan baik, jadi saya tidak yakin bagaimana rencana telah berubah untuk sisi OpenCL.

Maksudku:
"Apa itu StreamExecutor?
==========================
StreamExecutor adalah pembungkus terpadu di sekitar model pemrograman sisi host CUDA dan OpenCL (runtimes). Ini memungkinkan kode host menargetkan perangkat CUDA atau OpenCL dengan kernel paralel data yang berfungsi identik."

Operasi kalengan
====================
StreamExecutor menyediakan beberapa kernel yang telah ditentukan sebelumnya untuk operasi paralel data umum.
Kelas operasi yang didukung adalah:

  • BLAS: subprogram aljabar linier dasar,
  • DNN: jaringan saraf dalam,
  • FFT: transformasi Fourier cepat, dan
  • RNG: generasi nomor acak.

@keryell Hai, Saya juga tertarik untuk mengimplementasikan TensorFlow di FPGA, menggunakan bahasa pemrograman tingkat tinggi seperti Xilinx C++ atau OpenCL. Saya dengan senang hati berkontribusi jika Anda memiliki beberapa rencana.

@henline Bisakah Anda menjelaskan apa yang akan menjadi peran StreamExecutor di Opencl dan Canned yang relevan?
operasi untuk Tensorflow. Saya masih tidak dapat melihat bagaimana ini akan terintegrasi dengan rencana SyCL di Eigen dan cudnn (pengganti?)

:+1: Saya juga ingin berkontribusi untuk ini.

@bhack StreamExecutor menyediakan fungsionalitas yang setara dengan runtime CUDA dan beberapa pustaka CUDA (seperti cublas atau cudnn). Namun Anda masih perlu menulis kernel GPU Anda, untuk itulah kami menggunakan Eigen.

@benoitsteiner Jadi masih perlu menulis dua kernel, satu untuk CUDA dan satu untuk Opencl?

@benoitsteiner Jadi, apakah Anda masih memiliki mitra tensorflow/tensorflow/stream_executor/opencl/ secara internal? Bagaimana dengan "Operator Kalengan"?

@bhack Eigen memungkinkan Anda untuk menulis ekspresi yang menjelaskan komputasi yang ingin Anda lakukan sekali, dan secara otomatis menghasilkan kernel (yang kami sebut evaluator) untuk mengevaluasi ekspresi itu pada CPU dan kernel lain untuk mengevaluasi ekspresi pada perangkat CUDA. Setelah kami memiliki dukungan untuk OpenCL di Eigen (kami semakin dekat), kernel OpenCL juga dapat dibuat secara otomatis.
Untuk beberapa operasi TensorFlow yang kinerjanya kritis (seperti konvolusi), kami menggunakan kernel yang dioptimalkan secara manual dan/atau library pihak ketiga. Dalam kasus ini, kita memerlukan implementasi OpenCL yang baik untuk operasi ini.

:+1:

Apakah ada rencana untuk mendorong lebih banyak kode di https://bitbucket.org/benoitsteiner/eigen-opencl? Bagaimana dengan sycl compiler? Tampaknya tidak ada implementasi target GPU opensource yang dirilis.

@bhack @benoitsteiner
Saya segera merilis pengganti cuDNN (hanya bagian konvolusi, karena ini adalah kinerja dan memori yang paling penting untuk menyelesaikan ini) untuk OpenCL di Caffe. Mungkin juga akan berguna untuk port Tensorflow.

@bhack : Codeplay telah membuat banyak kemajuan di depan opencl. Nantikan dorongan besar untuk https://bitbucket.org/benoitsteiner/eigen-opencl dalam beberapa minggu ke depan.

@naibaf7 : Implementasi cepat dari operasi konvolusi akan sangat membantu di TensorFlow. Menantikannya.

@benoitsteiner Tangkapan yang bagus, mereka mendapat kursi

@benoitsteiner Bagaimana saya bisa menghapus implementasi cuda? karena '#ifdef GOOGLE_CUDA' sangat rumit. Terkadang berarti CUDA, terkadang berarti GPU.

Karena masalah ini telah mencapai peta jalan (lihat _Platforms_): apakah kita secara kasar mengetahui kapan dukungan OpenCL akan mencapai TensorFlow? Suka versi 0.9 / 1.0? Q3/4 2016? Atau 2017 lebih realistis?

@benoitsteiner Apakah eigen-opencl https://bitbucket.org/benoitsteiner/eigen-opencl cukup siap untuk mendukung pengembangan aliran tensor opencl?

Apakah tensorflow hanya bergantung pada tensor Eigen atau adakah ketergantungan lain dari Eigen?

@NEELMCW Codeplay baru saja merilis dukungan parsial untuk OpenCL ke Eigen Tensors. Kode tersedia di repositori bitbucket ini. Untuk sebagian besar, TensorFlow bergantung pada tensor Eigen. Ada dependensi tambahan pada Eigen untuk operasi aljabar linier, tetapi kita tidak harus menyediakan implementasi yang kompatibel dengan OpenCL untuk operasi ini (setidaknya pada awalnya tidak). Oleh karena itu, kami berada dalam posisi yang sangat baik untuk mulai mendukung OpenCL di TensorFlow.

Jika Anda tertarik untuk berkontribusi, saya sudah mulai melacak apa yang perlu dilakukan dalam spreadsheet ini

@benoitsteiner Saya penulis perpustakaan C++11 OpenCL BLAS (https://github.com/CNugteren/CLBlast) dan saat ini saya menerapkan dukungan setengah presisi di sana. Saya senang berkontribusi pada bagian BLAS/GEMM dari proyek ini dan/atau memodifikasi CLBlast agar lebih sesuai dengan kebutuhan Anda.

@CNugteren
CLBlast sekarang juga tersedia di OpenCL-Caffe, pernahkah Anda melihatnya? :)
Apakah Anda juga memiliki kesempatan untuk melihat konvolusi libDNN?

@naibaf7 Saya melihatnya, ya! :) Saya belum melihat libDNN sama sekali sejauh ini, tapi saya tidak yakin apa yang Anda maksud. Saya berasumsi konvolusi diimplementasikan menggunakan GEMM?

@CNugteren
Ya, saya hanya berpikir akan lebih baik jika Anda dapat memeriksanya dan mungkin memberikan beberapa tip perbaikan atau penyetelan di libdnn.
(https://github.com/naibaf7/caffe/blob/master/src/caffe/greentea/libdnn.cpp).
Itu menggunakan GEMM, tetapi implisit (tidak melalui BLAS, hanya GEMM kecil di tingkat kelompok kerja) sehingga tingkat paralelisme yang lebih tinggi dimungkinkan, serta tidak diperlukan buffer perantara (untuk membuka gulungan data ke dalam skema GEMM).

Hai semua,

@benoitsteiner terima kasih telah menyebutkan dorongan kami! Semoga bermanfaat!

Untuk mengkompilasi kode ini, Anda memerlukan kompiler SYCL. Saat ini, satu-satunya kompiler yang didukung adalah ComputeCpp Codeplay, yang tersedia melalui program evaluasi Codeplay. ComputeCpp akan tersedia secara gratis sebagai beta terbuka publik, kemudian pada tahun 2016 dan kemudian dirilis dengan versi gratis (Edisi Komunitas ComputeCpp) pada tahun 2017. Ini akan memungkinkan siapa saja mengkompilasi dan mengembangkan TensorFlow pada perangkat OpenCL, seperti AMD atau Intel GPU dan CPU.

Omong-omong. bukankah seharusnya masalah ini memiliki label OpenCL? :)

Terima kasih,
Lukas

Saya sangat berharap itu bisa dikompilasi juga dengan alat opensource. @keryell bagaimana dengan cabang Opencl baru Anda

@bhack Akan menyenangkan untuk melihat apakah itu dapat bekerja dengan triSYCL dalam mode perangkat host CPU OpenMP terlebih dahulu. Tapi saya tidak punya bandwidth untuk masuk ke sistem build TensorFlow/Eigen rnow. :-( Jika seseorang ingin mencoba, jangan ragu untuk melakukannya. :-)

https://github.com/keryell/triSYCL/commits/opencl harus memungkinkan untuk menjalankan kernel OpenCL segera dalam mode interoperabilitas OpenCL, tetapi tidak dalam mode sumber tunggal SYCL yang kita semua impikan karena kita belum memiliki kerangka Clang/LLVM untuk mengekstrak kernel dari SYCL. Tapi Khronos baru-baru ini membuka sumber komponen dari AMD & Intel untuk mendukung OpenCL C++ 2.2 & SPIR-V yang akan menjadi dasarnya. Jadi ini "hanya" masalah waktu...

Bisakah seseorang memberikan perkiraan kapan Tensorflow mungkin dapat berjalan dengan OpenCL (AMD GPU)? Dan seperti apa kurva kinerja/kegunaan dari waktu ke waktu? Sulit untuk menguraikan semua informasi masa lalu menjadi informasi pembelian perangkat keras yang dapat ditindaklanjuti. :)

Terima kasih sebelumnya!

@djan92
Saya akan mengatakan beri waktu satu tahun sampai dapat digunakan, sayangnya. Sepertinya itu akan dibangun di atas perpustakaan dan teknologi yang cukup mutakhir, kebanyakan dari mereka belum siap.
Saya juga hanya akan langsung bergabung segera setelah tumpukan alat lengkap tersedia sebagai OpenSource dan bukan sebelumnya.

@naibaf7

Saya akan mengatakan beri waktu satu tahun sampai dapat digunakan, sayangnya. Sepertinya itu akan dibangun di atas perpustakaan dan teknologi yang cukup mutakhir, kebanyakan dari mereka belum siap.
Saya juga hanya akan langsung bergabung segera setelah tumpukan alat lengkap tersedia sebagai OpenSource dan bukan sebelumnya.

Mengapa tidak mengimplementasikan versi CL terlebih dahulu sambil menunggu port SYCL siap? Saya berasumsi ada beberapa orang di sini yang bersedia membantu. Satu tahun terdengar terlalu lama.

@djan92
Ya, Anda benar, #22 hampir berusia 8 bulan dan memiliki lebih dari 100 postingan! Informasi bisa dibanjiri!

Bisakah seseorang memberikan perkiraan kapan Tensorflow mungkin dapat berjalan dengan OpenCL (AMD GPU)?

TensorFlow menggunakan library Eigen untuk komputasi tensor (dalam modul Tensor). Kami telah melakukan implementasi parsial untuk OpenCL 1.2 menggunakan SYCL (https://bitbucket.org/benoitsteiner/opencl branch Codeplay). Alasan kami menggunakan SYCL untuk pekerjaan ini adalah karena bagian TensorFlow ini menggunakan pohon ekspresi C++, yang dimungkinkan dengan SYCL untuk OpenCL, tetapi tidak mungkin dengan OpenCL C secara langsung. Komponen TensorFlow lainnya, seperti konvolusi atau BLAS, dapat menggunakan OpenCL C secara langsung.

Saat ini, saya sedang bekerja untuk mengintegrasikan ComputeCpp (kompiler SYCL Codeplay) ke dalam sistem pembuatan bazel. Ini akan segera siap ( ikuti repo ini: https://github.com/benoitsteiner/tensorflow-opencl/ ). Setelah itu selesai, TensorFlow harus dipercepat pada sistem yang mendukung OpenCL SPIR (seperti AMD atau Intel) dengan ComputeCpp. Pekerjaan lebih lanjut akan dilanjutkan untuk mempercepat lebih banyak TensorFlow, serta mendukung lebih banyak implementasi OpenCL dan SYCL open-source triSYCL. SYCL dan OpenCL adalah standar terbuka multi-vendor, bebas royalti, jadi ada banyak platform dan perangkat yang dapat didukung menggunakan pendekatan ini (bukan hanya GPU AMD).

Kompiler ComputeCpp Community Edition akan tersedia secara gratis nanti di tahun 2016 (dalam bentuk beta: kesesuaian penuh akan dirilis secara gratis awal 2017).

Pekerjaan untuk mempercepat bagian non-C++ dari TensorFlow (misalnya BLAS dan konvolusi) dapat dilakukan tanpa SYCL dan diimplementasikan secara terpisah. Vendor perangkat keras yang berbeda mungkin memiliki pustaka mereka sendiri yang dioptimalkan untuk fitur-fitur ini yang dapat membantu akselerasi. Atau, kita bisa menggunakan Eigen dengan C++ untuk fitur-fitur ini.

Dan seperti apa kurva kinerja/kegunaan dari waktu ke waktu?

Kami yakin kinerjanya akan terus meningkat. Untuk mempercepat di berbagai perangkat, kita perlu mengelola data dengan lebih efisien, itulah sebabnya ada item pekerjaan "tensor terkelola", sehingga perpindahan data dapat dikelola secara lebih efisien antara host dan beberapa perangkat. Sulit untuk memprediksi bagaimana kinerja akan bervariasi di berbagai perangkat, saat ini. Saat ini, sangat sedikit yang dipercepat, tetapi kami menyiapkan infrastruktur untuk memungkinkan akselerasi standar terbuka di TensorFlow.

@naibaf7

Saya akan mengatakan beri waktu satu tahun sampai dapat digunakan, sayangnya.

Operasi dasar harus segera tiba. Kami menempatkan infrastruktur dasar di dalam kode untuk mendukung akselerasi berbasis standar terbuka. Kami percaya bahwa dengan dukungan komunitas, versi yang dipercepat dan dapat digunakan akan siap dalam waktu kurang dari setahun.

Saya juga hanya akan langsung bergabung segera setelah tumpukan alat lengkap tersedia sebagai OpenSource dan bukan sebelumnya.

ComputeCpp akan tersedia untuk umum, gratis, pada tahun 2016. Dukungan triSYCL open-source harus mengikuti di belakang. Open-source OpenCL sudah didukung dengan pocl, Shamrock, Clover, Beignet.

@robertwgh
Kode tensor C++ di Eigen tidak akan mudah dibawa-bawa ke OpenCL C tanpa SYCL, tetapi ada fitur lain yang akan bekerja dengan baik di OpenCL C. Lihat spreadsheet ini: https://docs.google.com/spreadsheets/d /1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0 dan isi bebas tuliskan nama Anda pada fitur-fitur yang seharusnya menggunakan OpenCL C normal (seperti BLAS dan konvolusi).

Kami memberikan versi evaluasi untuk ComputeCpp sebelum rilis publik. Jika Anda menginginkannya, kirimkan saya email :)

@lukeiwanski Bagus, terima kasih atas pembaruannya. Saya harap Anda benar tentang menyelesaikannya dengan fitur lengkap dalam waktu kurang dari setahun.

Langkah lain dari Streamexecutor di LLVM

ada peluang untuk mendapatkan akselerasi di rx 480?

@benoitsteiner
LibDNN mandiri akan tersedia untuk integrasi:
https://github.com/naibaf7/libdnn

Senang membaca ini sedang dikerjakan. Akan membantu jika Beignet 2.0 dipoles. Banyak potensi dengan Skylake dan Iris sekarang.

Permintaan tarik baru-baru ini ditambahkan di https://github.com/benoitsteiner/tensorflow-opencl/pull/1 jika seseorang ingin melihatnya.

OpenCL SDK Imagination(GPU) membutuhkan NDA agar dapat diakses, kami hanya memiliki perpustakaan bersama. Apakah mungkin menjalankan tensorflow berdasarkan lib ini?

@alefman
Anda tidak memerlukan file header khusus vendor untuk membangun program OpenCL apa pun. Coba cl.hpp dari https://www.khronos.org/registry/cl/api/1.2/cl.hpp dan opencl.h/cl.h dari SDK lain. Misalnya - Saya memiliki setidaknya 3 platform OpenCL dan semuanya berfungsi dengan satu /usr/include/CL/cl.h yang dibagikan

Kami belum mendukung TensorFlow yang berjalan di OpenCL. Ini adalah pekerjaan yang sedang berjalan. Saat ini kami sedang mengerjakan GPU AMD. Dukungan PowerVR harus mengikuti. Jika Anda ingin berkontribusi pada pengembangan, Anda harus menghubungi kami (Codeplay) secara langsung. Jika Anda ingin menjalankan TensorFlow di PowerVR, Anda harus menunggu sedikit kemajuan lagi.

@inferrna terima kasih, sepertinya OpenGL yang menyembunyikan implementasi khusus vendor.

@andrerichards Saya senang berkontribusi dalam pengembangan, bagaimana cara menghubungi Anda?

Yang paling mudah adalah jika Anda mengklik "daftarkan minat Anda" di halaman kami di sini: https://www.codeplay.com/products/computecpp
Itu akan membawa Anda ke program pengembang kami dan kami dapat bekerja sama dalam @alephman ini

Jika mau, Anda dapat berkontribusi juga untuk membiarkan kompilasi dengan alternatif opensource. Lihat https://github.com/tensorflow/tensorflow/issues/22#issuecomment -221841173

Halo semuanya!
Sangat senang mendengar dukungan Tensorflow diperluas di luar Nvidia Cuda. Saya ingin tahu apakah Anda juga mempertimbangkan untuk membuatnya berfungsi pada APU seperti ini: http://www.amd.com/en-us/products/processors/laptop-processors#sectionOne ?

@kgocheva
APU mendukung OpenCL untuk bagian CPU dan GPU.
Ini akan bekerja cukup banyak di luar kotak ketika dukungan OpenCL sudah siap.
Sedangkan jika Anda sudah memiliki APU dan ingin mencoba framework ML lainnya, BVLC OpenCL Caffe sudah berfungsi.

@naibaf7 Terima kasih atas klarifikasinya. Saya sedang melihat kombinasi perangkat keras/lunak yang hemat biaya untuk menjalankan Tensorflow secara lokal dan pasti akan mengikuti kemajuan pengembangan OpenCL.

@hughperkins
Ya bisa menjadi masalah, tapi saya pikir bagian seperti im2col/col2im dan implementasi konvolusi lainnya juga bisa dicolokkan sebagai API eksternal jika itu benar-benar masalah dengan GCLA. Ini mungkin juga lebih baik bagi penulis asli dari karya semacam itu.

@hughperkins Kami sedang berupaya membawa OpenCL ke TensorFlow melalui SYCL untuk OpenCL 1.2.
Silakan lihat di https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1625897530 untuk "todos" dan kemajuan.
Baru-baru ini kami merilis kompiler untuk SYCL https://www.codeplay.com/products/computesuite/computecpp yang disebut ComputeCpp Comunity Edition. Orang bisa mencobanya!
Selain itu, kami berfokus pada perpustakaan Eigen https://bitbucket.org/benoitsteiner/opencl/branch/ComputeCpp - membawanya ke tahap yang diperlukan oleh MNIST TensorFlow - ada beberapa hal yang tersisa.
Adapun kendala, rilis ComputeCpp CE saat ini telah diuji untuk Intel (CPU, GPU) dan AMD (CPU, GPU) sedangkan untuk platform kami mendukung Ubuntu 14.04 64bit dan CentOS 64bit.
ComptueCpp dapat diunduh secara gratis dan dapat digunakan dalam proyek komersial dan sumber terbuka.
Karena kami <3 membuka komunitas :)

@lukeiwanski Maaf untuk mendiskusikan/meminta ini di sini di utas, tapi saya pikir ini mungkin menarik bagi orang lain juga: Saya mengerti bahwa Codeplay sangat tertarik dengan SYCL untuk implementasi OpenCL dan saya sudah mendengar orang lain tertarik dengan karya ini kamu juga. Saya membaca beberapa posting oleh pejabat Movidius misalnya. Namun, saya ingin bertanya apa sebenarnya kontribusi Google terhadap hal ini? Karena Movidius, selain AMD dan lainnya, terdaftar sebagai mitra Codeplay, saya dapat memahami bahwa mereka mendorong atau bahkan mendukung SYCL untuk OpenCL, tetapi sejauh yang saya ketahui, Google bukan mitra Anda dan belum berkontribusi sejauh ini?!

Jangan salah paham, saya sangat menyukai pekerjaan Anda, tetapi bukankah ide yang baik untuk menggabungkan upaya Anda, mengumpulkan sumber daya, dan mencoba bekerja sama dengan Google? Bagi saya sepertinya banyak pihak yang berbeda tertarik dengan OpenCL untuk TensorFlow, tetapi potensi yang sangat besar tidak digunakan, karena pihak-pihak ini tidak berkembang bersama?!

Saya mungkin salah dan mohon maaf kepada diri saya sendiri jika ini sudah cukup dibahas, tetapi saya masih tidak mengetahui adanya upaya besar dari Google (atau pihak lain) untuk bekerja sama dalam hal ini dan, sebagai akibatnya, saya masih tidak mengetahui bagaimana komunitas bisa membantu atau mendukung (seperti individu lajang), baik melalui kontribusi langsung, pengujian atau hal lainnya.

@ascenator Kami di Google telah bekerja sama dengan Luke dan rekan Codeplay-nya dalam proyek ini selama hampir 12 bulan sekarang. Kontribusi Codeplay untuk upaya ini sangat luar biasa, jadi kami merasa bahwa kami harus membiarkan mereka memimpin dalam hal mengomunikasikan pembaruan yang terkait dengan OpenCL. Inilah sebabnya mengapa Anda belum mendengar banyak dari kami tentang topik ini :)

Sekarang kompiler ComputeCpp tersedia secara luas, kami berencana untuk menggabungkan pekerjaan yang telah dilakukan sejauh ini. Tetapi pertama-tama kami ingin menyusun infrastruktur pengujian yang komprehensif untuk memastikan bahwa kami tidak mengacaukan basis kode yang ada.

Kami menyambut semua kontribusi untuk upaya ini, jadi jangan ragu untuk menghubungi saya jika Anda ingin membantu. Kami sangat tertarik dengan kernel OpenCL performa tinggi untuk perkalian matriks dan konvolusi. Beberapa kandidat telah diusulkan, tetapi kami belum mulai melihat pro dan kontra dari masing-masing kandidat atau bagaimana mengintegrasikannya.

@benoitsteiner terima kasih banyak atas klarifikasinya & maaf atas kesalahan informasi saya! Ini terdengar sangat bagus & menjanjikan! Saya pasti akan melihat ComputeCpp. Saya sangat menantikan dukungan OpenCL untuk TensorFlow, karena ini menawarkan banyak kemungkinan baru untuk robotika (yang merupakan bidang tempat saya meneliti dan menggunakan TensorFlow untuk aplikasi pembelajaran mendalam). Saya setidaknya akan melihat rilis awal dan mencoba menguji / men-debug. Kami memiliki beberapa Chip Intel ditambah sejumlah CPU ARM yang sedang menunggu tes ;)

@hughperkins... maaf tapi bukankah ini benar-benar di luar topik? Saya tidak melihat bagaimana ini relevan di OpenCL TF?

Saya lebih tertarik di sini untuk mengetahui apakah akan diambil pendekatan penyetelan untuk perkalian matriks dan kernel konvolusi dan apakah akan menjadi alternatif sumber terbuka yang valid untuk CompiteCpp yang akan menghasilkan SPIR-V.

Jika itu membantu, versi isaac yang lebih baik telah dirilis: https://github.com/ptillet/isaac , dan memberikan peningkatan signifikan pada clBLAS dan cuBLAS di Maxwell, Pascal, dan Fiji. Juga menyediakan kernel (input-aware) yang lebih cepat daripada Tensorflow untuk pengurangan 1D dan 2D.

@hughperkins tampaknya Anda memiliki lebih banyak peluang untuk menulis kompiler CUDA untuk perangkat OpenCL apa pun, daripada penerjemah CUDA-OpenCL.

@hughperkins Mungkin fitur SVM OpenCL 2.0 dapat menyelesaikan masalah penunjuk? Karena semua orang selain Nvidia (AMD, Intel, ARM, Qualcomm) mulai mendukung OpenCL 2.0. Mungkin itu solusi yang bagus?

@hughperkins ini adalah implementasi blas itu sendiri. Ini mengimplementasikan beberapa simbol di header clblas dan cublas sehingga tidak ada kompilasi ulang dan modifikasi kode. diperlukan. Saya juga bisa mengimplementasikan beberapa simbol untuk clblast.h, karena menggunakan header yang berbeda. Beberapa kelebihan Ishak adalah:

  • Sepenuhnya dinamis, sehingga dapat menggunakan salah satu/keduanya CUDA atau OpenCL tanpa kompilasi ulang.
  • Input-aware , itu tidak menyetel kernel untuk matriks persegi besar. Ini harus berkinerja baik pada semua bentuk yang dapat Anda pikirkan tanpa menyetel ulang.
  • C++ API mirip dengan numpy/arrayfire. Beberapa fusi untuk menggabungkan operasi elemen dengan reduksi

@marty1885
Tidak juga. AMD kembali ke dukungan 1.2 pada driver AMDGPU-PRO. Mungkin perlu beberapa saat hingga dukungan penuh 2.0 tersebar luas. Jelas bukan solusi jangka pendek di sana.

  • Ya
  • Saya dapat meretas kompatibilitas untuk banyak operasi jika diperlukan (misalnya, meneruskan **MV ke GEMV). Dukungan kompleks akan rumit. Dukungan ganda sudah ada di sini tetapi tidak ada arsitektur yang disetel untuk itu.

@hughperkins

Sepertinya kode saya tidak melanggar aturan OpenCL yang jelas

Ya, dengan jelas melewatkan struktur __global (seperti array atau struct) yang berisi pointer tidak benar hanya karena pointer tersebut dapat menunjuk ke memori perangkat lain (OpenCL mendukung paradigma multi-perangkat di mana satu perangkat tidak dapat mengakses memori perangkat lain). Tetapi tampaknya mungkin untuk mengatasi pada level IR, tanpa terjemahan menengah ke kode OpenCL - itulah yang saya asumsikan :)

@benoitsteiner , @henline , dari https://github.com/henline/streamexecutordoc , ini menunjukkan streamexecutor telah mendukung operasi kaleng versi CL (seperti DNN, BLAS) di luar kotak. Apakah itu menyarankan google sudah memiliki clDNN, implementasi clBLAS siap untuk Tensorflow, tetapi belum membukanya?

Jika tidak, OpenCL 2.0+ dan SYCL 2.2 mendukung SVM, jika Anda ingin mempertahankan arsitektur perangkat lunak yang sama.
OpenCL 2.0+ didukung oleh AMD dan Intel GPU misalnya. Di dunia tertanam, sering didukung oleh efek samping bahkan dengan OpenCL 1.x, karena memori host dan perangkat seringkali sama karena alasan biaya.

@keryell
Tetapi platform yang paling terkenal, Linux + GPU AMD baru (RX 480, Vega mendatang) hanya mendukung OpenCL 1.2 untuk saat ini... dan siapa yang tahu kapan itu akan berubah (taruhan saya dalam setahun). Beignet (Intel Linux opensource) untuk OpenCL 2.0 juga masih berantakan; versi stabil memiliki 1.2.
Juga mempertimbangkan semua perusahaan kecil yang membuat chip yang kompatibel dengan OpenCL hampir tidak menarik dukungan 1.2. Jadi saya kira apa pun yang mengandalkan OpenCL 2.0 akan melihat tingkat adaptasi yang sangat buruk dalam praktiknya.

Saya pikir.. ada vendor perangkat keras yang memiliki urgensi untuk mengkonsumsi SPIR-V? Saya pikir tekanan Grafik/Shaders pada Vulkan dapat membantu sisi Opencl..

@naibaf7 untuk kembali ke diskusi tentang OpenCL 2 atau tidak, pada titik tertentu hal-hal nyata harus disampaikan... Jika tidak, sudah ada nVidia GPU dan CUDA dengan TensorFlow berjalan... :-)
Tapi tentu saja, versi TensorFlow tanpa SVM memiliki beberapa kepentingan.

@keryell Berapa banyak Vulkan SPIR-V bekerja pada driver (yang sudah memiliki cakupan perangkat yang baik) menurut Anda akan mendorong versi Opencl modern?

@naibaf7 Pertemuan Khronos minggu depan di Seoul dengan orang-orang OpenCL dan Vulkan, tetapi diskusi tidak bersifat publik. Tapi itu terdengar seperti ide yang bagus untuk membuat setiap dunia meningkatkan yang lain, dan pada titik tertentu menguntungkan TensorFlow. :-)

@keryell
Ya, saya harap mereka membahas beberapa hal bermanfaat DeepLearning :)

Selamat! Pastikan untuk memeriksa proyek HIP, karena mereka mencoba memecahkan masalah yang sama. Mereka memilih untuk membuat bahasa baru yang disebut HIP, yang mendefinisikan apa yang perlu dikonversi secara manual (seperti memeriksa dukungan presisi ganda dengan memeriksa tingkat komputasi). Sementara proyek berjalan, jumlah terjemahan manual akan berkurang. Lihat: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

Saran saya untuk Anda adalah menggunakan HIP dan memperbaiki beberapa bug yang menghalangi untuk memajukan Tensorflow atau tujuan Anda sendiri, karena Anda sekarang memiliki pemahaman tentang LLVM untuk melakukannya. Dengan cara ini Anda tidak perlu memecahkan masalah yang sudah mereka perbaiki.

@hughperkins
tidak dapat membuat modul python dengan garpu Anda mengikuti ini 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.

Saya menggunakan ubuntu 16.04, dirname berasal dari coreutils-8.25-2ubuntu2

@hughperkins Saya pikir mengutak-atik TF dockerfile di repositori Anda dengan instruksi ini dapat memudahkan pengaturan untuk orang lain.

Ya, ketika akan ada sesuatu yang lebih fungsional. Pada dasarnya ini adalah salinan dan masa lalu dari instruksi yang telah Anda posting.

Saya bereksperimen membangun ini di MacOS 10.10.5 di MacBook akhir 2015 dengan ATI 6770M (OpenCL 1.2).

Saya telah menginstal Xcode 8, Anaconda (Python 3.5), dan MacPorts setara dengan dentang+llvm:

alih-alih baris apt-get, lakukan:

sudo port instal dentang-3.8 llvm-3.8

Alih-alih menggunakan /proc/cpuinfo, lakukan:

NUM_PROCS=$(system_profiler SPHardwareDataType | grep "Jumlah Total Core" | cut -d ":" -f 2)

Kemudian ubah Makefile untuk menggunakan macports dan jalankan 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

perbarui ke direktori OpenCL Macos; masa depan: gunakan /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers/cl.h '#ifdef APPLE ' bersyarat

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

Ini sejauh yang saya dapatkan:

$ buat -j ${NUM_PROCS}
mkdir -p build
mkdir -p build
mkdir -p build
/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_MACROSFORMAT__MASTDC_ -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_MACROSFORMAT__MASTDC_ -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_MACROSFORMAT__MASTDC_ -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
Dalam file yang disertakan dari src/hostside_opencl_funcs.cpp:17:
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: peringatan: atribut 'host' diabaikan [-Wignored-attributes]
atribut ((host)) sebaris unsigned long long atomicExch(volatil unsigned long long _p, unsigned long long val) {
^
src/hostside_opencl_funcs.cpp:194:33: kesalahan: panggilan ke fungsi anggota 'dalam' ambigu
launchConfiguration.kernel->in(offset);
~ ~ ~ ~ ~ ~~~^~
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:101:15: catatan: fungsi kandidat
CLKernel in (nilai mengambang);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:104:15: catatan: fungsi kandidatCLKernel *in(nilai int32_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:106:15: catatan: fungsi kandidatCLKernel *in(nilai int64_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:108:15: catatan: fungsi kandidatCLKernel *in(nilai uint64_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:110:15: catatan: fungsi kandidatCLKernel *in(nilai uint32_t);^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:73:15: catatan: fungsi kandidat tidak dapat dijalankan: tidak ada konversi yang diketahui dari 'size_t' (alias 'unsigned long ') menjadi 'easycl::CLArray *'untuk argumen pertamaCLKernel *in(CLArray *clarray1d) { kembali input(clarray1d);



}^/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/src/EasyCL/CLKernel.h:91:36: catatan: templat fungsi kandidat tidak dapat dijalankan: memerlukan 2 argumen, tetapi 1 disediakantemplatCLKernel *in(int N, const T *data);^1 peringatan dan 1 kesalahan dihasilkan.buat: *_* [build/hostside_opencl_funcs.o] Kesalahan 1membuat: * * Menunggu pekerjaan yang belum selesai ....
src/struct_clone. cpp:245 :12: peringatan: 11 nilai enumerasi tidak ditangani di sakelar: 'HalfTyID', 'X86_FP80TyID', 'FP128TyID'... [-Wswitch]
sakelar(jenisID) {
^
1 peringatan dibuat.

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

Tambalan ini berhasil. Terima kasih.

Setelah menerapkan ini, melanjutkan pembangunan menghasilkan kesalahan namespace size_t:

$ buat -j ${NUM_PROCS}
mkdir -p build
mkdir -p build
/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_MACROSFORMAT__MASTDC_ -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 -Saya pwd /include -Saya 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_MACROSFORMAT__MASTDC_ -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/ mutasi.o build/struct_clone.o src/ir-to-opencl-common.cpp /opt/local/bin/llvm-config-mp-3.8 --ldflags --system-libs --libs all
Dalam file yang disertakan dari src/hostside_opencl_funcs. cpp:17 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl.h:91:16: peringatan: atribut 'host' diabaikan [-Wignored-attributes]
atribut ((host)) sebaris unsigned long long atomicExch(volatil 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 -Saya pwd /include -Saya pwd /src/EasyCL src/cocl_blas.cpp
1 peringatan dibuat.
/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 -Saya pwd /include -Saya pwd /src/EasyCL src/cocl_error.cpp
Dalam file yang disertakan dari src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:8:9: error: tidak ada tipe bernama 'size_t' di namespace 'std'; maksud Anda hanya 'size_t'?
typedef std::size_t cublasStatus_t;
^ ~ ~
ukuran_t
/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sini
typedef SIZE_TYPE size_t;
^
Dalam file yang disertakan dari src/cocl_blas. cpp:15 :
/Users/erybski/git/tensorflow-cl/third_party/cuda-on-cl/include/cocl/cocl_blas.h:17:5: error: tidak ada tipe bernama 'size_t' di namespace 'std'; maksud Anda hanya 'size_t'?
std::size_t cublasCreate(cublasHandle_t gagang);^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef SIZE_TYPE size_t;^Dalam file yang disertakan dari src/cocl_blas.
maksud Anda hanya 'size_t'?std::size_t cublasDestroy(cublasHandle_t menangani);^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef SIZE_TYPE size_t;^Dalam file yang disertakan dari src/cocl_blas.
maksud Anda hanya 'size_t'?std::size_t cublasSgemm(cublasHandle_t blas, int transA, int transB, int M, int N, int K,^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef SIZE_TYPE size_t;^Dalam file yang disertakan dari src/cocl_blas.
maksud Anda hanya 'size_t'?std::size_t cublasSetPointerMode(cublasHandle_t menangani, cublasPointerMode_t mode);^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef SIZE_TYPE size_t;^Dalam file yang disertakan dari src/cocl_blas.
maksud Anda hanya 'size_t'?std::size_t cublasGetPointerMode(cublasHandle_t menangani, cublasPointerMode_t *mode);^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef SIZE_TYPE size_t;^Dalam file yang disertakan dari src/cocl_blas.
maksud Anda hanya 'size_t'?std::size_t cublasSetStream(cublasHandle_t menangani, cudaStream_t streamId);^ ~ ~ukuran_t/opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include/stddef.h:62:23: catatan: 'size_t' dideklarasikan di sinitypedef 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 -Saya pwd /include -Saya 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 -Saya pwd /include -Saya pwd /src/EasyCL src/cocl_device.cpp7 kesalahan yang dihasilkan.make: *_* [build/cocl_blas.o] Kesalahan 1make: * * Menunggu pekerjaan yang belum selesai....

Bisakah kita mendorong inti log panjang agar utasnya masih dapat dibaca?

pertanyaan: bagaimana kalian memecahkan masalah ruang alamat?

@hughperkins Spesifikasi SYCL dijelaskan di bagian 5.8 ("Pengurangan ruang alamat")
bagaimana implementasi perlu menangani tipe memori yang berbeda. Ini
mirip dengan pekerjaan sebelumnya yang dilakukan untuk PlayStation 3 dan dijelaskan dalam
makalah ini: Offload – Mengotomatiskan Migrasi Kode ke HeterogenSistem Multicore atau C++ pada Akselerator: Mendukung Model Pemrograman SYCL dan HSA Sumber Tunggal Menggunakan Dentang

semoga membantu.

@hughperkins Bisakah saya mengkompilasi kode repo tensorflow-opencl Anda untuk menerapkan papan ARM saya? Papan ARM saya memiliki GPU Imajinasi yang mendukung opencl 1.2 .

Saya menemukan utas ini saat mencari dukungan tf/intel.

Saya memiliki intel MacBook Pro, bagaimana saya bisa membantu? Saya tidak tahu c/c++, tetapi saya dapat mengikuti instruksi build/compile/test dan mengembalikan hasil (pastebin)...

derek$ system_profiler SPDisplaysDataType
Grafik/Tampilan:

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 Terima kasih atas instruksi Anda!
Saya mencoba mengkompilasi cuda-on-cl Anda di platform lengan. Mengikuti panduan cuda-on-cl Anda:
Info papan ARM saya:
arm64, gcc 4.9 , dentang dan llvm 3.5, openCL 1.2

* Apakah saya harus menggunakan versi dentang++-3.8? *
git clone --recursive https://github.com/hughperkins/cuda-on-cl
membuat
kesalahan:
dentang++-3.8: Perintah tidak ditemukan
Saya mengedit Makefile seperti ini: CLANG=clang++ LLVM_CONFIG=llvm-config LLVM_INCLUDE=/usr/include/llvm
lalu buat lagi:
kesalahan:
src/mutations.h:3:10: kesalahan fatal: file 'llvm/IR/Module.h' tidak ditemukan

coba jalankan make run-test-cocl-cuda_sample:
make: cocl: Perintah tidak ditemukan

@hughperkins izinkan saya mencobanya.

Mendapat kesalahan saat menguji keras dengan tensorflow

keras$ KERAS_BACKEND=tensorflow pytest3

Kesalahan keluaran:

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

Kode:

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

hai semuanya, nama saya ricardo, saya seorang programmer C++ dengan pengalaman bertahun-tahun dalam C++, dan sedikit tentang Cuda, saya akan dengan senang hati berkontribusi pada upaya ini. Bagaimana saya bisa berkontribusi untuk pekerjaan ini?

Oke, saya punya Odroid Xu3 dengan Mali-T628 MP6 (OpenGL ES 3.0/2.0/1.1 dan OpenCL 1.1 Profil lengkap)
berjalan di OS: LUbuntu 1404 64 bit
Saya akan melakukan instalasi lengkap dan memposting hasilnya di platform ini.
Tentang bug, ada daftar bug (seperti Bugzilla?) atau spreadsheet dengan daftar bug?
Bersulang!

Bagaimana dengan menggunakan 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
"Keinginan Anda dikabulkan, Eigen sedang di-porting melalui GPU AMD melalui HIP. Bagian kedua dari permintaan Anda adalah bisakah kami membawa alat standar yang mendukung FLOAT16 yang dikirimkan dengan semua GPU GFX8 kami, semoga dikabulkan."
Cabang pengembangan kompiler AMDGPU kami sekarang mendukung instruksi asli Float16 dan Int16, alih-alih meniru FP16/Int16 dengan instruksi konversi naik & turun untuk mengonversi dari FP16/Int16 ke Float dan sebaliknya.

Ini adalah tes f16 pada perangkat keras Fiji yang berhasil mengeksekusi perkalian matriks dengan setengah jenis dengan konversi dan dengan instruksi Asli."

Juga, tidak terkait tetapi Anda harus menggunakan syCL/openCL 2.0 alih-alih 1.2, karena nvidia sudah didukung melalui CUDA. Dan openCL 2.0 didukung pada driver AMD dan Intel Windows. AMD juga telah mengatakan bahwa mereka akan segera opensource un openCL 2.0 driver untuk Linux (yang dapat digunakan oleh Intel, opensource magic) (dan Intel sudah memiliki implementasi Linux openCL 2.0 yang Hanya perlu pematangan.) jika Anda bertanya kepada Intel dan AMD, mungkin mereka bisa mempercepat pekerjaan, karena tensorflow penting untuk kepentingan ekonomi mereka. Dan mereka sudah mengatakan di bagian komentar ini bahwa mereka ingin membantu. Juga semua pembuat ARM utama mendukung openCL 2.0. Ini bisa membuka banyak peluang untuk Android (yang untuk kepentingan ekonomi Google), raspberry like, smart TV, dll

Dan dalam jangka menengah kami akhirnya dapat mengembangkan lapisan fallback opencl 1.2 untuk perangkat keras yang tidak didukung.
Dan implementasinya juga harus menggunakan openVX (yang sekarang didukung oleh semua pembuat perangkat keras utama, dan AMD memiliki implementasi opensource) dan dengan https://www.khronos.org/news/press/khronos-launches-dual-neural-network -inisiatif-standar
Dan semuanya dengan Spir-V (yang dapat digunakan secara bersamaan oleh Vulkan dan openGL).
Anda dapat mengatakan bahwa saya membuat duplikat dari apa yang telah dikatakan, tetapi mensintesis itu penting.
Dan akhirnya, bisakah tensorflow menggunakan HSA ?

http://www.hsafoundation.com
HSA akan luar biasa di Android.

Saya tidak tahu apakah HIP akan berguna atau tidak. Ini hanya didukung pada beberapa kartu AMD sehingga kita tetap memerlukan implementasi OpenCL jika kita ingin mendukung semua perangkat. Mungkin masih layak jika implementasi HIP lebih cepat. Ini mungkin masalahnya, tetapi saya belum melihat banyak tolok ukur (HIP vs. OpenCL). Alasan lain mungkin MLOpen (yang ditulis dalam HC) sebagai pengganti cudnn tetapi sekali lagi saya tidak tahu seberapa cepat itu atau fitur mana yang didukungnya.

TensorFlow tidak akan menggunakan HSA secara langsung karena levelnya cukup rendah. Tetapi HC (dan HIP) diimplementasikan di atasnya dan Anda juga dapat mengimplementasikan OpenCL di atas if (pocl melakukan itu).

Apakah algoritma relooper akan membantu di sini? http://mozakai.blogspot.ca/2012/05/reloop-all-blocks.html

@hughperkins Senang melihat Anda memiliki beberapa kemajuan dengan kompiler Anda, tapi saya pikir itu menjadi di luar topik untuk TensorFlow. Anda harus memulai banyak utas diskusi yang lebih kecil di halaman GitHub dari proyek kompiler Anda. Itu akan lebih fokus dan produktif saya kira.

Dukungan OpenCL/SyCL awal digabungkan dalam master dengan https://github.com/tensorflow/tensorflow/pull/5267

Selamat!

@keryell Btw, apa yang terjadi dengan repositori triSYCL? Tampaknya hilang dan saya hanya dapat menemukan referensi ke Gitlab Khronos yang tidak dapat diakses publik.

EDIT: Saya menemukan klon pribadi Anda, hanya satu dari amd yang hilang.

@bhack , apakah opencl-docker mendukung di platform mac?

@alephman Saya tidak memiliki platform OSX tapi saya pikir mengadaptasi sedikit perintah peluncuran bisa berhasil.

@bhack @alephman : lihat komentar saya tentang mac di atas, jika Anda mengarahkan saya ke instruksi pembuatan, saya akan mencobanya

@olesalscheider : ya, triSYCL dipindahkan dari AMD ke Xilinx https://github.com/Xilinx/triSYCL tetapi Anda benar, versi di ruang kerja GitHub saya juga berfungsi di https://github.com/keryell/triSYCL

Kami belum mencoba triSYCL di TensorFlow. Sudah ada pekerjaan konfigurasi build besar yang harus dilakukan hanya untuk mencoba ...

@keryell Apa status triSYCL?

Dukungan Intel beignet opencl 2.0 hampir selesai!
http://phoronix.com/scan.php?page=news_item&px=Beignet-Birthday-CL2

@bhack triSYCL terutama dikembangkan di Xilinx sekarang. Masih menambahkan lebih banyak dan lebih banyak fitur. Kompiler garis besar berbasis Dentang/LLVM masih dalam pengembangan untuk memiliki pengalaman sumber tunggal penuh pada perangkat. Tetapi mode kompatibilitas OpenCL, yang sudah diimplementasikan, memiliki beberapa nilai juga, dengan menyederhanakan komunikasi antara host dan kernel dengan runtime SYCL yang melakukan lazy transfer sesuai dengan dependensi yang diekspresikan oleh pengakses.

Mac saya kompatibel dengan OpenCL, jadi bagaimana cara menjalankan tensorflow dengan openCL? Saya baru saja menemukan bahwa opencl telah didukung di tensorflow, ketika saya mengonfigurasi kode baru.

@hughperkins tidak ada instruksi clinfo di mac saya, apa yang bisa saya lakukan untuk itu? Tapi saya bisa mengkompilasi kode tes di sini untuk opencl dengan dentang dan menghasilkan info berikut:
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

Terima kasih @hughperkins , tapi saya rasa saya sudah mencoba computecpp kemarin, dan sepertinya sistem macbook masih belum didukung dengan computecpp. Jadi, mungkin tetap menunggu pembaruan baru adalah satu-satunya hal yang bisa saya lakukan (TT). BTW, Iris 6100 saya adalah delapan generasi, yang bagus untuk OpenCL 1.2.

@hughperkins ya SYCL 1.2 adalah apriori untuk OpenCL 1.2 dan SYCL 2.2 adalah apriori untuk OpenCL 2.2.
Saya mengatakan "apriori" karena, jika Anda tidak menggunakan apa pun yang memerlukan mode kompatibilitas OpenCL dari SYCL, SYCL tidak benar-benar membutuhkan OpenCL sama sekali. Sebenarnya SYCL adalah model yang sangat umum untuk komputasi heterogen dan dapat berjalan di atas apa pun. Tapi tentu saja implementasi nyata mungkin memerlukan OpenCL juga.

Halo,

Saya sedang belajar/bekerja dengan TensorFlow dan Keras untuk saat ini dan saya akan tertarik untuk mendapatkan dukungan OpenCL yang bekerja di bawah macOS ... Apakah ada berita tentang pekerjaan yang dilakukan di sekitar macOS?

Saya berhasil mengkompilasi TensorFlow tetapi jika saya mencoba mengonfigurasi untuk OpenCL, ia meminta saya untuk lokasi computeCpp 1.2, dan menurut saya tidak ada ComputeCpp untuk macOS.

Halo. Sama sekali bukan ahli dalam ML / Tensorflow / atau bahkan OpenCL, tetapi saya adalah pengembang grafis Mac berpengalaman yang sangat menginginkan kinerja Tensorflow yang lebih cepat pada sistem dengan terintegrasi dan GPU AMD menggunakan perpustakaan bawaan dan dependensi sederhana :)

Bagaimana saya bisa membantu?

Melihat kegagalan kompilasi terakhir pada OS X di travis log @hughperkins - sepertinya menjalankan 'xcode-select --install' mungkin menjadi solusi? Itu harus menautkan ulang direktori /usr/include. Saya sendiri mengalami masalah ini ketika memperbarui Xcode beta untuk dirilis dan mengalami masalah saat mengkompilasi beberapa kode C++.

Sepertinya kompiler XLA (https://www.tensorflow.org/versions/master/resources/xla_prerelease.html) akan menyediakan pembuatan kode LLVM dari grafik aliran data. Ini berarti akses yang sangat mudah ke spir-v dan oleh karena itu API komputasi Vulkan. Dengan pembuatan kode yang diselesaikan, saya tidak dapat membayangkan Google tidak menyediakan kompatibilitas Vulkan mengingat tingginya jumlah GPU terintegrasi yang tidak digunakan yang berjalan di Android.

@hughperkins

Cepat: Saat ini saya menjalankan Inception v3 pada basis kode C++ / Object-C khusus dan meneruskan bingkai video yang didekodekan ke jaringan. Saya tidak cukup tahu tentang TF untuk mengetahui kebutuhan tingkat rendah, tetapi tingkat tinggi: memuat model, menjalankan sesi, mengharapkan barang berfungsi. Saya pikir itu berarti kompatibilitas 100% untuk benar-benar jujur. Saya tahu itu tidak membantu dalam memprioritaskan. Pada dasarnya Pengenalan Gambar C++ menggunakan TF /InceptionV3 adalah titik awal saya.

cuda-on-cl yang berjalan di Mac: Saya telah memeriksa repo dan dapat membantu men-debug dan menjalankan build pada sistem saya dan memverifikasi hasil pada berbagai perangkat keras: Saya memiliki akses ke AMD Mac Pro dengan Dual D700, Laptop Nvidia Mac dan Sistem desktop.

Terima kasih atas umpan balik terperinci Anda. Saya akan memantau repo, mencoba mengikuti, dan mencoba membantu sebaik mungkin.

Hugh, Anda mungkin ingin melihat http://chrec.cs.vt.edu/cu2cl/ untuk mempelajari bagaimana beberapa fungsi dipetakan.

Di perusahaan saya, StreamComputing, kami memiliki berbagai GPU untuk pengujian build dan benchmarking, yang kami gunakan untuk proyek pelanggan kami. Saya bisa menghubungkan Github Anda ke Jenkins kami untuk melakukan lari mingguan.

Terima kasih atas jawabannya, saya akan kembali pada subjek di tempat kerja minggu ini, dengan skrip khusus.

Kasus penggunaan saya adalah seputar analisis pencocokan teks/sintaks, menggunakan Gensim dan Keras/tensorflow dalam eksperimen saya.

Saya bersedia membantu Anda untuk pengujian

Saya memiliki PC Windows dengan kartu AMD
MBP dengan kartu AMD
MB dengan GPU terintegrasi Intel

Hai @hughperkins - Saya akan melalui set tes di atas, malam ini, pada AMD R9 390 8GB. Sejauh ini saya sudah mendapatkan satu hasil yang berbeda; logistic_regression.py melatih dan tidak mengembalikan nan . Sangat baik! Ini segfault di akhir, jadi saya akan menyelidiki apakah skrip atau kode cl yang salah.

Di mana saya harus mendorong hasil saya, di mana mereka dapat paling berguna bagi Anda?
Mungkin kita bisa mendapatkan "skrip tes" standar yang menghasilkan serangkaian hasil standar yang dapat didorong oleh sukarelawan kepada Anda (atau disiapkan di CI lokal atau apa pun)?

py.test adalah solusi yang baik; itu hanya pip dan itu adalah bagian dari proses untuk menginstal tensorflow .

Saya telah menemukan beberapa hal menarik sejak memulai pengujian saya, dan itu mungkin tidak dapat di-debug menggunakan keluaran Python saja, namun:

  • Panggilan berbeda ke skrip yang sama mungkin macet lebih awal, atau mungkin "hang" (tidak ada keluaran, tidak ada kemajuan, tidak ada respons ke Ctrl-C , proses perlu pkill -9 'd), atau mungkin macet terlambat baik di bagian validasi atau setelah skrip berhasil diselesaikan. Kerusakan (segfaults) dapat menghapus Xorg.
  • Hasilnya bervariasi tanpa alasan: Saya dapat memanggil skrip dan membuatnya segfault, lalu memanggilnya lagi dan itu akan berfungsi.
  • Hang dapat terjadi di bagian kode yang bekerja secara harfiah beberapa saat yang lalu, saya pernah mengalami satu hang terjadi di dalam atau setelah batch pelatihan, setelah beberapa ratus batch baru saja terjadi dengan sukses.

Jadi, mungkin ada hal-hal yang belum terselesaikan di sisi GPU, dan bahwa segfault yang baik diperlukan untuk menghapusnya? Saya belum tahu banyak tentang model GPU atau OpenCL, jadi saya tidak bisa berkontribusi banyak di sini. Tapi, mungkin output debugging GPU diperlukan untuk mengeksplorasi dengan benar apa yang terjadi.

Juga, saya pikir Anda menggunakan AMD dari github Anda, tetapi tampaknya Anda adalah "agen nakal" yang melakukan seluruh hal CUDA-on-CL ini pada waktu Anda sendiri. Terima kasih dengan tulus untuk mempelopori ini! Apakah ada cara agar saya dan orang lain dapat berkontribusi untuk upaya Anda, mungkin dengan melakukan crowdfunding untuk GPU? Atau Anda dapat membuat Patreon, saya senang untuk mendaftar untuk kontribusi bulanan untuk proyek?

Mengenai GPU AMD, kami adalah mitra AMD. Lihat pesan saya 8 hari yang lalu, yang mungkin Anda lewatkan:

Di perusahaan saya, StreamComputing, kami memiliki berbagai GPU untuk pengujian build dan benchmarking, yang kami gunakan untuk proyek pelanggan kami. Saya bisa menghubungkan Github Anda ke Jenkins kami untuk melakukan lari mingguan.

Saya ingin tahu apakah Anda mungkin memiliki kemungkinan menyiapkan server CI, yang berjalan pada setiap komit?

Tidak masalah. Saya mungkin memerlukan akses tulis ke proyek, sehingga Jenkins dapat menulis file log ke direktori build-log. Saya hanya mengirim spam, jadi kita bisa berdiskusi.

Halo semua,

Seperti yang mungkin sudah Anda lihat, banyak hal SYCL telah didorong ke TensorFlow. Kami belum selesai, dan masih banyak yang harus dilakukan. Tapi kami sedang berkembang untuk sampai ke sana.

Jika Anda tertarik untuk berkontribusi atau hanya ingin tahu tentang keadaan saat ini, periksa rinciannya di bawah ini.

Infrastruktur
Google dengan baik hati menyumbangkan dua mesin yang disiapkan untuk menguji garpu TensorFlow @benoitsteiner (https://github.com/benoitsteiner/tensorflow-opencl) secara berkala

Keduanya memiliki GPU AMD:

CL_DEVICE_NAME : Hawaii
CL_DRIVER_VERSION : 1912.5 (VM)

dan

CL_DEVICE_NAME : Fiji
CL_DRIVER_VERSION : 1912.5 (VM)

Kami di Codeplay juga ingin mendedikasikan mesin tahun depan. Untuk meningkatkan cakupan keragaman perangkat OpenCL.

Kami mencari kontributor di bagian depan itu jika ada yang tertarik untuk menyediakan server build uji untuk platform relevan yang kami dukung.
Saat ini, persyaratannya adalah:
- Ubuntu 14.04
- Driver OpenCL yang mendukung SPIR ( Intel CPU / GPU atau AMD GPU )

@VincentSC mungkin Anda bisa membantu?

tes
Di mesin Fiji ( https://ci.tensorflow.org/job/tensorflow-opencl/127/consoleFull ) kami menghadapi 164 kegagalan.

Di mesin Hawaii ( https://ci.tensorflow.org/job/tensorflow-opencl/129/consoleFull ) kami gagal mencapai 56.

Kami sedang mencari cara untuk memperbaiki tes gradien yang gagal dan menyelidiki asal-usul kegagalan tambahan pada mesin Fiji.

Eigen
Selama beberapa bulan terakhir kami telah aktif mengimplementasikan fitur-fitur yang dibutuhkan oleh TensorFlow termasuk: Reshaping, Slicing, Basic Reduction dll. Saat ini kami sedang mengimplementasikan Contraction. Rincian rinci dapat ditemukan di tab Eigen Tensor https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =0.

TensorFlow
Banyak operasi Koefisien-bijaksana telah diterapkan termasuk Abs, Floor, IsFinite, Log, Pow, Mul, dll., serta Manipulasi Tensor seperti Reshape, Shape, Identity, Fill, dll.
Perincian terperinci dapat ditemukan di tab Kernel TensorFlow di https://docs.google.com/spreadsheets/d/1YbHn7dAFPPG_PgTtgCJlWhMGorUPYsF681TsZ4Y4LP0/edit#gid =1719702219

Organisasi
Spreadsheed di atas memiliki beberapa tab yang mengkategorikan upaya proyek seperti: Rencana Keseluruhan, Eigen Tensor, Kernel TensorFlow, Model.

Jika Anda ingin terlibat, silakan cantumkan nama Anda di sebelah item yang sedang Anda kerjakan atau tambahkan hal penting yang kurang.
Terima kasih,
Lukas

Apakah peta jalan ini aktif?

@lukeiwanski Ya, tidak masalah. Hubungi kami melalui [email protected]

Setelah membaca semua ini, saya kira belum ada solusi yang solid untuk menggunakan OpenCL di macOS/OS X? Saya mencoba mengkompilasi Tensorflow C++ dengan dukungan OpenCL (yang saya asumsikan membutuhkan ComputeCpp untuk SYCL 1.2 seperti yang ditunjukkan seseorang).

Saya melihat sekeliling dan sepertinya tidak dapat menemukan tempat untuk mengunduh, mengkompilasi, atau membangun perpustakaan SYCL. Apakah di sini https://www.codeplay.com/ ? Saya tidak yakin bagaimana untuk melanjutkan, terima kasih...

@dylib Sejauh yang saya tahu bahwa masih belum ada ComputeCpp untuk macOS. Jadi itu berarti OpenCL untuk macOS belum siap.

Masih tidak dapat membuatnya bekerja di Ubuntu 16.04 dengan kartu AMD dan driver katalis https://github.com/tensorflow/tensorflow/issues/6497 . Apakah ada caranya?

Saya harus melihat output /usr/local/computecpp/bin/computecpp_info sebelum mencoba menggunakan TF yang dikompilasi dengan dukungan OpenCL. Dalam kasus saya itu menunjukkan

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

sekarang ada 2 pilihan untuk menjalankan TF di GPU:
bekerja dengan baik pada jumlah perangkat yang terbatas (oleh vendor), tetapi CUDA milik
buruk bekerja pada jumlah perangkat yang terbatas (oleh pengembang computecpp) dan juga milik computecpp
Masih tidak ada dukungan OpenCL.

@inferrna Ada di bagian khusus OpenCL di keseluruhan dokumentasi TensorFlow. Ini akan segera dipublikasikan di situs tensorflow.org.

@benoitsteiner Apa status saat ini pada dukungan konvolusi opencl? Apakah Anda berencana memanfaatkan kernel yang keluar secara langsung? Bagaimana dengan perkalian matriks?

Ada ETA?

Bagaimana dengan menggunakan HIP untuk mem-port kode CUDA ke platform agnostik? https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_porting_guide.md

Bisakah XLA backend LLVM IR dikonversi ke SPIR-V dengan https://github.com/KhronosGroup/SPIRV-LLVM?

Bagaimana dengan ini? Saya pikir paket ini dapat bekerja pada GPU Radeon.

https://github.com/RadeonOpenCompute/ROCm

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

@lukeiwanski Akankah XLA berdampak juga pada usaha Anda?

Solusi XLA dan SYCL saling melengkapi untuk situasi yang berbeda: SYCL dirancang untuk memberikan kemampuan program dan penyesuaian penuh. XLA adalah untuk mengoptimalkan pola yang terdefinisi dengan baik dalam grafik.

Pemahaman saya tentang XLA adalah bahwa ia mengoptimalkan beberapa grafik TensorFlow yang ada saat runtime menggunakan kompiler LLVM. Ini membutuhkan pass optimasi untuk diimplementasikan dalam kompiler untuk setiap algoritma yang digunakan dalam grafik.
Pendekatan SYCL adalah satu-satunya pendekatan yang akan memberikan tingkat pemrograman CUDA - yang dibutuhkan pengembang.

Dengan SYCL, kami bertujuan untuk memberikan dukungan untuk semua Operasi TensorFlow dan memudahkan pengembangan operasi baru.

Ini berarti SYCL memungkinkan Anda menulis operasi kinerja tinggi baru dengan sangat mudah, sementara XLA dapat mengoptimalkan seluruh grafik jika mendukung semua operasi dalam grafik.

Bisakah XLA backend LLVM IR dikonversi ke SPIR-V dengan https://github.com/KhronosGroup/SPIRV-LLVM?

Saya tidak melihat alasan mengapa itu tidak mungkin.

@lukeiwanski Terima kasih, saya secara khusus mencari https://www.tensorflow.org/versions/master/experimental/xla/developing_new_backend

@k-hashimoto: kita membahas di sini tentang porting TensorFlow ke OpenCL, standar dari Khronos Group, dan sebenarnya lebih banyak lagi OpenCL SYCL, standar sumber tunggal C++ post-modern dari Khronos Group.
ROCm terlihat seperti solusi-non-standar-lain-dari-beberapa-vendor.
Jika Anda tertarik dengan solusi berpemilik, sudah ada versi CUDA dari TensorFlow yang terlihat berfungsi dengan baik. :-)

Setuju: pertahankan percakapan / upaya di OpenCL, dan biarkan vendor menerapkan apa pun mereka di atas standar terbuka itu.

Pada 17 Januari 2017 10:01:32 GMT+00:00, Ronan Keryell [email protected] menulis:

@k-hashimoto: kami membahas di sini tentang porting TensorFlow ke
OpenCL, standar dari Khronos Group, dan sebenarnya lebih banyak OpenCL SYCL,
standar sumber tunggal C++ post-modern dari Khronos Group.
ROCm terlihat seperti solusi-non-standar-lain-dari-beberapa-vendor.
Jika Anda tertarik dengan solusi eksklusif, sudah ada CUDA
versi TensorFlow yang terlihat berfungsi dengan baik. :-)

--
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -273076892

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

:+1:

👍

:+1:

Pesan ini dibuat secara otomatis oleh perangkat lunak pengiriman surat.

Pesan yang Anda kirim tidak dapat dikirim ke satu atau lebih darinya
penerima. Ini adalah kesalahan sementara. Alamat yang ditangguhkan berikut ini:

[email protected]
Biomassiv.es domain telah melampaui email maksimum per jam (111/100 (111%)) yang diizinkan. Pesan akan dicoba lagi nanti

------- Ini adalah salinan pesan, termasuk semua header. ------
Diterima: dari github-smtp2-ext6.iad.github.net ([192.30.252.197]:48606 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
oleh chi-server32.websitehostserver.net dengan esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Contoh 4.87)
(amplop-dari [email protected] )
id 1cWmiQ-0032as-W9
untuk [email protected]; Kam, 26 Jan 2017 10:16:03 -0600
Tanggal: Rab, 25 Jan 2017 04:09:21 -0800
DKIM-Tanda Tangan: v=1; a=rsa-sha256; c=santai/santai; d=github.com;
s=pf2014; t=1485346161;
bh=N1Pjga2Q9PtEE8ncEMXBtSJzd3kd6HAkJRnj6H2dDEg=;
h= From:Reply-To :To:Cc:In-Reply-To:R referensi:Subjek :Daftar-ID:
Daftar- Arsip:Daftar-Posting :Daftar-Tidak berlangganan:Dari;
b=e5r+VKm/UtpLYj0OCnfEPSYlL6a7xCOd9bN+jS3gify2mRv/g4kofW7ZrEeDyeJT+
GvddVV/w5htZFUbHy9+92pYUHGEYEn2XrmFqc6ZFVoPqBsPW5Cxk31O3Kvi1cwuSPI
g8J4X/qvl1DT+yKrh1es7CeXkr23c8mFNgWkG5qk=
Dari: Miguel ngel [email protected]
Balas-Ke: tensorflow/tensorflow [email protected]
Kepada: tensorflow/tensorflow [email protected]
Cc: Berlangganan [email protected]
ID-Pesan:
Di-Balasan-Ke:
Referensi:
Subjek: Re: [tensorflow/tensorflow] Dukungan OpenCL (#22)
Versi Mime: 1.0
Tipe-Konten: multibagian/alternatif;
batas="--==_mimepart_5888957158d12_78b73ff902fe113c148134";
rangkaian karakter = UTF-8
Konten-Transfer-Encoding: 7bit
Prioritas: daftar
X-GitHub-Pengirim: migpradel
Penerima X-GitHub: biomassa
X-GitHub-Alasan: berlangganan
Daftar-ID: tensorflow/tensorflow
Daftar-Arsip: https://github.com/tensorflow/tensorflow
Daftar-Posting: [email protected]
Daftar-Berhenti Berlangganan:,
https://github.com/notifications/unsubscribe/AELU4lfFKxIqjh4jaQkUHuRKD7zj_eKCks5rVztxgaJpZM4Gex3i
X-Auto-Response-Suppress: Semua
X-GitHub-Recipient-Address: [email protected]

----==_mimepart_5888957158d12_78b73ff902fe113c148134
Content-Type: teks/polos;
rangkaian karakter = UTF-8
Konten-Transfer-Encoding: 7bit

image

--
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -275092277
----==_mimepart_5888957158d12_78b73ff902fe113c148134
Tipe-Konten: teks/html;
rangkaian karakter = UTF-8
Konten-Transfer-Encoding: 7bit

image


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub , atau nonaktifkan utasnya .


----==_mimepart_5888957158d12_78b73ff902fe113c148134--

Baru disini. Ingin bertanya apakah akan ada dukungan OpenCL di tensorflow di masa depan, apakah itu berarti akan ada dukungan untuk menjalankan tensorflow di FPGA?
Terima kasih

@atinzad : ya jika versi & kode sumber OpenCL atau SYCL didukung oleh lingkungan FPGA. Tetapi karena TensorFlow mungkin merupakan kerangka kerja yang paling banyak di-porting dengan berbagai cara, itu mungkin sudah memiliki beberapa bagian yang berjalan pada FPGA di suatu tempat ...

Apa perbedaan antara upaya pengembangan sycl dan penargetan XLA SPIR-V selain PTX dalam visi jangka menengah?

Apa pertanyaan yang bagus. Mungkin - jumlah orang yang terlibat? Akan sangat menarik untuk diketahui!

Pada 16 Februari 2017, pukul 13.35, bhack [email protected] menulis:

Apa perbedaan antara upaya pengembangan sycl dan XLA yang menargetkan SPIR-V selain PTX dalam visi jangka menengah?


Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Apa perbedaan antara upaya pengembangan sycl dan XLA yang menargetkan SPIR-V selain PTX dalam visi jangka menengah?

@bhack Itu akan menjadi diskusi yang bagus untuk dilakukan di TensorFlow Dev Summit kemarin

Apakah Anda bertanya tentang sumber daya yang tersedia / jenis programmer yang dibutuhkan untuk berkontribusi?

Jika demikian, dalam pendekatan OpenCL/SYCL pemrogram C++ / pemrogram OpenCL C dapat dengan cepat ditingkatkan dan dapat berkontribusi. Pendekatan XLA membutuhkan pengalaman kompiler / llvm.

XLA adalah proyek internal Google dengan ekstensi mereka memiliki lebih banyak sumber daya yang terkait dengannya. Tapi, di sisi lain tugas mereka juga jauh lebih besar.. Menulis compiler bukanlah tugas yang mudah.

Jika tidak, jika Anda bertanya tentang modelnya:

Seperti yang saya sebutkan sebelumnya di https://github.com/tensorflow/tensorflow/issues/22#issuecomment -272908870 kami melihat kedua upaya sebagai pendekatan pelengkap dan keduanya memiliki kasus penggunaan yang berbeda. Saya masih bertahan dengan pernyataan itu.

Misalnya @tatatodd dalam presentasinya menyebutkan bahwa beberapa Ops tidak akan pernah memiliki XLA sebagai target. Saya percaya bahwa kita mungkin untuk mengisi celah itu.

Hal lain yang perlu dipertimbangkan adalah platform baru. Saya akan menggunakan lingkungan seluler dan tertanam demi argumen ini karena chip baru cenderung lebih sering muncul daripada GPU (prinsipnya sama).

Jika semikonduktor mendukung SYCL / OpenCL Anda mendapatkan dukungan TF di luar kotak (beberapa penyesuaian kinerja mungkin diperlukan).

Jika arsitekturnya eksotis dan tidak ada backend LLVM untuknya, XLA perlu menambahkannya (itu mungkin tidak terlalu sering terjadi tetapi tetap saja). Apa yang lebih sering terjadi adalah arsitektur berubah sedikit dan kemudian optimasi baru perlu ditambahkan atau yang sudah ada harus dimodifikasi untuk mendapatkan keuntungan. Tweak kode kernel lebih mudah.

Saya belum melihat terlalu dalam ke XLA tetapi saya berasumsi bahwa XLA harus memanggil ke CUDA API entah bagaimana untuk menjalankan kode kernel PTX, jadi harus porting ke OpenCL atau Vulkan untuk menjalankan kernel SPIR-V - yang saya asumsikan akan melalui StreamExecutor - kerangka kerja lain untuk mengenal - mungkin upaya yang cukup besar.

Singkatnya, kami menyediakan platform terpadu / stabil dalam ekosistem yang sangat terfragmentasi / dialihkan yang dapat ditargetkan oleh perusahaan semikonduktor dan pengembang. Sedangkan XLA harus berkomitmen untuk mendukung.

@benoitsteiner atau @drpngx mungkin dapat memberikan lebih banyak pengetahuan orang dalam tentang XLA karena saya bekerja dengan banyak asumsi/kesimpulan berdasarkan percakapan.

Oh, saya juga telah membuat saluran kendur untuk memudahkan komunikasi https://tensorflowopencl.slack.com/shared_invite/MTQzNDQ0NzgzNzAyLTE0ODcyOTE1NjctMDZhM2RkODRlYg

Idul Fitri:
Tautan kendur tidak lagi valid. Silakan ping saya jika Anda ingin bergabung.

Saya pikir itu benar dan sebagian akan tergantung ke arah mana produsen semikonduktor akan berorientasi.
"Backend ini memancarkan LLVM IR yang diperlukan untuk mewakili komputasi XLA HLO secara efisien, dan kemudian memanggil LLVM untuk memancarkan kode asli dari LLVM IR ini." Jadi LLVM IR dapat dikonversi ke SPIR-V . Tapi dialek Opencl SPIRV berbeda dengan Vulkan . Streamexecutor sedang didorong di LLVM parallel-lib dan dalam deskripsi @henline asli, rencana aslinya tampaknya mencakup opencl.

/ cc @ dneto0

http://phoronix.com/scan.php?page=news_item&px=OpenCL-2.0-NVIDIA-Preps
Nvidia akan segera mendukung opencl 2.0 di Linux dan Windows, ini YUGE !

Dari segi kinerja, kemungkinan akan lebih lambat dari CUDA.

Ingat juga bahwa orang-orang Noveau bekerja secara independen di Opencl dengan SPIR-V . Statusnya sedikit ketinggalan jaman tetapi ada komitmen baru.

Opencl tidak secara inheren lebih lambat dari Cuda, itu Hanya nvidia yang secara virtual mengunci pasar dengan melumpuhkan driver opencl-nya.
Tetapi kepemimpinan nvidia akhirnya akan segera berakhir dan bahkan praktik anti persaingan amoral mereka tidak akan menyelamatkan mereka. Dengan HIP autotranslator Cuda yang mengesankan ( https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP)
Vega apus dan dgpus dan ARM yang akan datang datang ke Windows, Nvidia tidak memiliki masa depan, inilah mengapa industri PERLU mendukung opencl/syCL/HIP/HSA segera dan secara besar-besaran.

Halo, saya berencana bahwa tensorflow akan mendukung AMD Radeon Instinct yang baru? (http://instinct.radeon.com/en-us/)

Hai, apakah ada kemajuan dalam dukungan TF-OpenCL untuk FPGA?

@alexivia https://github.com/iteong/tensorflow/blob/master/tensorflow/stream_executor/platform.h#L30 telah dihapus beberapa bulan yang lalu dan peta jalan Streamexecutor tidak jelas.

@bhack terima kasih atas respon cepatnya
Jadi, apakah ini berarti tidak ada dukungan, atau operasi yang benar tidak dijamin?
Juga, dari apa yang saya baca di utas ini, saya melihat bahwa pengujiannya terutama pada GPU AMD ... adakah yang melatih jaring pada GPU Nvidia dengan port OpenCL ini?

Streamexecutor diubah namanya menjadi LLVM parallel-libs dan sekarang menjadi acxxel

Adakah anggota Google yang dapat menjelaskan perbedaan dan peta jalan antara streamexecutor dan https://reviews.llvm.org/rL285111?

CC @zheng-xq

@henline dan @jlebar adalah pakar untuk menjawab perbedaan antara streamexecutor dan https://reviews.llvm.org/rL285111?

Axcell dan StreamExecutor adalah proyek terpisah. Tidak ada rencana saat ini untuk menggabungkannya. Saya serahkan kepada orang-orang TensorFlow untuk mengatakan apakah mereka berencana untuk beralih atau tidak.

Begitu juga StreamExecutor dan StreamExecutor llvm bukan proyek yang sama?

Benar, mereka bukan proyek yang sama.

Pada Kam, 16 Mar 2017 pukul 11:06, bhack [email protected] menulis:

Begitu juga StreamExecutor dan StreamExecutor llvm bukan proyek yang sama?


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287143104 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAJMh_4ODoCVglGRbFBs8UmtSEm6D47_ks5rmXoUgaJpZM4Gex3i
.

@jlebar Lain kali unit kreatif untuk penamaan ;) tapi mungkin bukan kurangnya motivasi kreativitas tetapi hanya upaya upstreaming dari alat internal yang menyimpang dari yang dipertahankan di TF..

@bhack , kami memang mengubah nama, tepatnya ketika kami menyadari bahwa kami melakukannya
tidak masuk akal untuk memindahkan StreamExecutor ke grosir LLVM. Dia
sekarang disebut "Acxxel".

Saya minta maaf atas kebingungan dan saya menghargai umpan baliknya .. Itu a
proses belajar pastinya.

Pada Kam, 16 Mar 2017 pukul 11:24, bhack [email protected] menulis:

@jlebar https://github.com/jlebar Lain kali unit kreatif untuk penamaan
;) tapi mungkin bukan kurangnya motivasi kreativitas tetapi hanya sebuah
upaya hulu dari alat internal yang menyimpang dari yang dipertahankan
di TF..


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-287148247 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAJMh0MMZvdTJ-bUoa71FBrEqHqFpDjvks5rmX5IgaJpZM4Gex3i
.

Ya, saya masih memiliki sedikit kebingungan antara StreamExecutor, SyCL di eigen, XLA (yang sebenarnya hanya memiliki backend CUDA, selain CPU dan opencl di beberapa slide)

Menabrak

Adakah orang di Google yang berbicara dengan Apple atau AMD untuk memudahkan ini? Saya kira orang- orang AMD sangat tersesat sehingga mereka bahkan tidak tahu masalahnya ada di sana dan mereka masih bertanya-tanya mengapa Nvidia memiliki pangsa pasar yang begitu besar. Saya rasa tim AI Apple juga akan dengan senang hati membantu di sini... jika OpenCL tidak ditinggalkan oleh pihak mereka sejak 2013 dan, lebih buruk lagi, bos mereka tidak akan marah pada Google.

Apa yang terbaru tentang ini?

Menurut Catatan Rilis TF 1.1 , dukungan GPU Mac (khusus Nvidia) tidak digunakan lagi. Mari berharap ini akan membantu meningkatkan pendekatan OpenCL (tidak terlalu percaya diri dalam hal ini).

Terima kasih! Saya mengikuti masalah ini selama beberapa bulan terakhir. Saya tidak yakin dengan komitmen Apple OpenCL, mengingat mereka terjebak pada OpenCL 1.2 sejak 2013 (Apple belum menyediakan dukungan SPIR 1.2).

Jika TensorFlow di OpenCL akan membantu Anda dalam pekerjaan Anda, beri tahu saya, sejauh saya dapat membantu memajukan penelitian dan praktik pembelajaran mendalam, saya ingin membantu. Perusahaan saya telah membangun back end OpenCL untuk TensorFlow yang disesuaikan untuk berbagai GPU sebagai bagian dari pekerjaan kami dalam inferensi pada perangkat. Kami telah menguji pada keluarga GPU seluler & desktop utama termasuk konfigurasi umum pada Windows & Mac. Jika ada cukup minat kami dapat melakukan semacam distribusi publik. Kami juga memiliki Metal (Apple GPU) dan LLVM (CPU), bersama dengan cara untuk melakukan penerapan tanpa ketergantungan. Idenya di sini adalah untuk memberi setiap perangkat dukungan hebat untuk pembelajaran mendalam.

@choongng - semua itu terdengar sangat berguna dan membantu. Proyek pribadi saya https://github.com/Synopsis/ akan sangat diuntungkan dari OpenCL di OS X, serta Metal untuk penyebaran iOS dan Desktop. Jika ini memungkinkan untuk diperkenalkan ke Tensorflow, saya pikir ini akan menjadi keuntungan besar bagi banyak pengembang.

Terima kasih.

@choongng

Jika perusahaan Anda menerbitkan versi OpenCL, atau yang lebih menarik, versi Metal dari TensorFlow, saya pikir ini akan menjadi berita bagus bagi banyak orang, saya sedang dalam proses membangun eGPU dengan kartu NVidia untuk mendapatkan TensorFlow / Keras berjalan di MBP saya untuk pekerjaan saya...

Bagi yang tertarik ... buka komunitas eGPU.io

@choongng

Saya akan sangat tertarik melihat ini, jadi saya akan sangat berterima kasih jika Anda bisa mengejarnya! Terutama jika tidak memerlukan kompiler sumber tertutup samar yang telah dipilih TF untuk dukungan CL..

Pada 26 April 2017 03:33:51 GMT+01:00, Choong [email protected] menulis:

Jika TensorFlow di OpenCL akan membantu Anda dalam pekerjaan Anda, beri tahu saya, ke
sejauh saya dapat membantu memajukan penelitian dan praktik pembelajaran mendalam, saya akan
suka membantu. Perusahaan saya telah membangun back end OpenCL untuk TensorFlow
disetel untuk berbagai GPU sebagai bagian dari pekerjaan kami dalam inferensi pada perangkat.
Kami telah menguji pada keluarga GPU seluler & desktop utama termasuk
konfigurasi umum pada Windows & Mac. Jika ada cukup minat kami
mungkin melakukan semacam distribusi publik. Kami juga memiliki Logam (Apple GPU)
dan LLVM (CPU), bersama dengan cara untuk melakukan penerapan tanpa ketergantungan. Itu
ide di sini adalah untuk memberikan setiap perangkat dukungan yang besar untuk pembelajaran yang mendalam.

--
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -2972201660

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Saya pikir itu akan menjadi revolusioner ;)

@choongng Mungkin akan membantu jika Anda bergabung dengan orang-orang ini
https://github.com/benoitsteiner/tensorflow-opencl

@cathalgarvey apa kompiler open source yang Anda usulkan untuk digunakan? Sulit untuk menemukan solusi open source yang sesuai dengan OpenCL untuk mengatasi banyak perangkat di alam liar...
Kita perlu bootstrap solusi di beberapa titik entah bagaimana ...

Saya tidak mengatakan itu adalah perbaikan yang mudah. Tapi, OpenCL bukan masalahnya, di sana. Lagi pula, CUDA sepenuhnya berpemilik, jauh lebih buruk daripada opsi OpenCL yang dipilih TensorFlow.

Itu semua mengatakan, ada opsi untuk sistem CL-atau-cuda jika Anda memulai dari awal, termasuk runtime middleware portabel atau arrayfire, dll. Tensorflow terlalu terikat dengan CUDA.

Saya merasa frustrasi bahwa orang bersedia untuk menulis kernel di CUDA tetapi menolak melakukannya untuk CL, meskipun itu akan menjangkau lebih banyak pengguna dan secara serius mengembangkan ekosistem pasar. Ada manfaat langsung dan tidak langsung dari platform terbuka untuk semua orang, yang mungkin mengarah pada penghematan biaya yang besar untuk semua orang dalam jangka panjang.

Jika SYSCL adalah bagaimana itu akhirnya terjadi, bagus: jadi mengapa beberapa nama besar tidak menaruh uang pada distribusi SYSCL terbuka alih-alih membeli ke opsi kepemilikan pinggiran, yang mengalahkan tujuan standar terbuka?

Pada 28 April 2017 09:13:06 GMT+01:00, Ronan Keryell [email protected] menulis:

@cathalgarvey apa kompiler open source yang Anda usulkan untuk digunakan?
Sulit untuk menemukan solusi open source yang sesuai dengan OpenCL untuk
mengatasi banyak perangkat di alam liar...
Kita perlu bootstrap solusi di beberapa titik entah bagaimana ...

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -297936468

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Yang ingin saya tanyakan dalam konteks ini adalah ini:

Jadi, beberapa kerangka kerja pembelajaran mendalam seperti Tensorflow dengan hangat mengeksplorasi penggunaan opencl sebagai alternatif CUDA. Tentu saja CUDA hanyalah "bahasa" tempat cuDNN dikembangkan, dan itu (jika pemahaman saya benar) adalah apa yang sebenarnya digunakan oleh sebagian besar bahasa pembelajaran mendalam. Dalam konteks ini, saya tidak yakin apa versi opencl dari cuDNN.

Juga AMD telah berbicara tentang alternatif sumber terbuka untuk CUDA yang terus mereka kembangkan dan sebut rocM. Mereka juga berbicara tentang miOpen untuk menjadi setara dengan cuDNN (perpustakaan assembler buatan tangan untuk fungsi pembelajaran mendalam umum), yang bagaimanapun belum dirilis. Pendekatan AMD agak lebih holistik: Kami tidak hanya mengekspor komputasi berat ke GPU.

Dalam konteks ini, saya benar-benar bingung. Bagaimana upaya opencl seperti yang tercantum di atas cocok bersama? Untuk GPU NVIDIA, mudah.... ada CUDA, dan ada cuDNN yang ditulis dalam CUDA. Untuk non-NVIDIA/atau dalam hal ini AMD, sepertinya kurang jelas. Kapan HIP lebih disukai? Kapan menggunakan HCC lebih disukai? Kapan menggunakan opencl lebih disukai? Wawasan apa pun akan sangat dihargai!

@cathalgarvey ada banyak politik di balik semua infrastruktur perangkat lunak/perangkat keras yang besar ini... :-(
Bahkan jika kita dapat memimpikan solusi yang bersih berdasarkan kriteria ilmiah murni, saya pikir kita harus pragmatis.
Google tidak ingin mengubah terlalu banyak arsitektur TensorFlow. Inilah sebabnya mengapa arsitektur berbasis OpenCL harus sangat mirip, membutuhkan C++ sumber tunggal seperti "CUDA runtime" alih-alih solusi OpenCL C non-sumber tunggal tingkat rendah. Di ranah Khronos, versi OpenCL C++ sumber tunggal disebut SYCL.
Mari kita bahas ini ketika Anda mampir ke Dublin, misalnya, karena Anda tampaknya juga berbasis di Irlandia. :-)
Sementara itu, jangan ragu untuk berkontribusi ke https://github.com/triSYCL/triSYCL dan cabang TensorFlow & Eigen yang menangani SYCL...

@keryell Tahukah Anda jika juga XLA:GPU :OpenCL direncanakan di SyCL?

Hai @benoitsteiner , mengenai:

Ada di bagian khusus OpenCL dalam dokumentasi TensorFlow secara keseluruhan. Ini akan segera dipublikasikan di situs tensorflow.org.

Saya melakukan pencarian di tensorflow.org untuk OpenCL dan sepertinya tidak dapat menemukan sesuatu yang signifikan, semuanya tampaknya mengarah ke sini. Dengan "segera", maksud Anda sebelum ______? ( _masukkan sarkasme lucu di sini_ ).

Saya dapat mengkompilasi repo Anda (yay!), meskipun saya menduga perlu sesuatu yang lain untuk membuat Tensorflow OpenCL yang berfungsi untuk Mac; Saya mencoba membangun kompiler triSYCL yang disebutkan tetapi sayangnya gagal.

@bhack Karena saya tidak bekerja untuk Google, saya tidak tahu tentang detail XLA...

@dylib sayangnya semua ini masih dalam proses...

@keryell Ya saya tahu.. Saya hanya ingin tahu apakah itu dibahas dalam beberapa pertemuan.

OpenCL sangat berbeda dari CUDA. Namun saya akan secara definitif melihat ini porting ke HIP sebagai gantinya.
Jadi +1 Untuk Anda semua yang menyarankannya.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

HIP memungkinkan pengembang untuk mengonversi kode CUDA ke C++ portabel. Kode sumber yang sama dapat dikompilasi untuk dijalankan pada GPU NVIDIA atau AMD

Tidak banyak orang yang tahu tentang HIP.
Anda dapat menemukan informasi lebih lanjut tentang tensorflow dan HIP di sini:
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/37
dan
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/45

Catatan samping:
Saya tidak berpikir kita harus melawan / membual tentang Nvidia vs AMD. Mereka adalah perusahaan terhormat yang membuat periode perangkat keras dan perangkat lunak yang luar biasa. Sebagai gantinya, kita harus fokus pada pengiriman tensorflow ke basis pengguna yang lebih besar.
Menargetkan banyak bahasa melalui binding sudah merupakan titik awal yang baik, tetapi kita juga perlu menargetkan hardware sebanyak mungkin. (Bahkan jika solusi cloud luar biasa, itu tidak selalu jawabannya)

Kami memiliki pengalaman dengan HIP, di sini di Stream. Mari saya lihat.

Setuju dengan argumen "perusahaan saya lebih baik". Saya ingin tahu GPU mana yang harus ditargetkan TensorFlow. Itu harus pragmatis dan bermanfaat. Misalnya GPU Intel atau GPU tertanam (Qualcomm, ARM, Imagination), RaspBerry Pi - ya atau tidak?

AMD Radeon Vega Frontier Edition

Kami terus secara agresif meningkatkan platform perangkat lunak terbuka ROCm dan perpustakaan pembelajaran mesin kami. Kami juga mendukung kerangka kerja kecerdasan mesin terbuka seperti Caffe (dirilis pada bulan April). Nanti di kuartal ini kami berencana menawarkan dukungan untuk Torch, dan Tensor Flow sedang dalam pengerjaan.

Mereka telah merilis Caffe, akan sangat tertarik untuk mendengar orang lain di utas ini berbagi pengalaman mereka dengan pembangunan/pengujian:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Saya sudah mulai menginstal tetapi menemui hambatan di mana apa pun yang membutuhkan CL hanya membeku, bahkan clinfo . Tidak yakin apakah ini karena beberapa masalah perangkat lunak, atau jika kartu saya (R9 390) tidak didukung oleh ROCm.

Pada 17 Mei 2017 15:18:32 GMT+01:00, Bryan Li [email protected] menulis:

Perbatasan AMD Radeon VegaEdisi

Kami terus secara agresif meningkatkan platform perangkat lunak terbuka ROCm kami
dan perpustakaan pembelajaran mesin. Kami juga mendukung mesin terbuka
kerangka kerja intelijen seperti Caffe (dirilis pada bulan April). Nanti ini
kuartal kami berencana untuk menawarkan dukungan untuk Torch, dan Tensor Flow masuk
pekerjaan.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -302103815

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

@cathalgarvey Saya telah menggunakan cabang Caffe OpenCL pada GPU AMD dan berfungsi dengan baik. make run test lulus semua tes kecuali satu

Senang mendengarnya; bolehkah saya bertanya tentang pengaturan HW/SW Anda? Misalnya, kartu apa Anda?
pakai, distro/versi Linux apa, dll?

Saya sebelumnya memiliki AMDGPU-pro, tetapi menghapusnya saat menginstal ROCm.
Mungkin ada beberapa hal warisan yang mengganggu saya.

--
@onetruecathal / @ [email protected]

Pada hari Rabu, 17 Mei 2017 jam 15:50, Bryan [email protected]
menulis:

@cathalgarvey Saya telah menggunakan cabang Caffe OpenCL pada GPU AMD dan
itu bekerja dengan baik. buat uji coba lulus semua tes kecuali satu


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@cathalgarvey

  • Cabang Caffe OpenCL (komit yang diuji c61d48746b2df1d237c64abc7416342ce98f3251 )
  • OS: Ubuntu 16.04.2 LTS
  • Diuji pada Polaris (RX460), Fiji (Fury X) dan Tonga (W7100)
  • Driver: Driver AMDGPU-Pro untuk Linux 16.40 atau lebih tinggi
  • ViennaCL
  • Dependensi umum: 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 ..

Ya selain cabang OpenCL di atas, naibaf7 akan menerbitkan buku (segera) tentang menggunakannya untuk inferensi real-time pada perangkat keras komoditas menggunakan grafis amd dan hd.

Ah; Saya berbicara tentang hipCaffe, bukan cabang OpenCL:

https://github.com/ROCmSoftwarePlatform/hipCaffe

Menginstal ROCm untuk membangun/menguji hipCaffe mengharuskan saya untuk mencopot pemasangan
AMDGPU-pro, mungkin saya akan mencoba cabang vanilla lagi. Ini buruk
didokumentasikan, sayangnya .. Saya kira saya akan mencoba "membuat" buta dan melihat.

Jadi, saya masih tertarik untuk mendengar pengalaman orang lain dengan AMD
tumpukan ROCm/HIP; jika mereka sedang mengerjakan garpu Tensorflow, itu akan bagus,
asalkan benar-benar berfungsi pada lebih dari 3/4 model kartu AMD di
liar.

--
@onetruecathal / @ [email protected]

Pada hari Rabu, 17 Mei 2017 jam 16.09, Bryan [email protected]
menulis:

@cathalgarvey

Cabang Caffe OpenCL (komit yang diuji
c61d48746b2df1d237c64abc7416342ce98f3251)
OS: Ubuntu 16.04.2 LTS
Diuji pada Polaris (RX460), Fiji (Fury X) dan Tonga (W7100)
Driver: Driver AMDGPU-Pro untuk Linux 16.40 atau lebih tinggi
ViennaCL
Dependensi umum: 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

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@cathalgarvey Saya berharap mereka bekerja pada backend yang keren, bukan garpu penuh. Itu akan menyedihkan dan hanya membagi upaya kerja.
Sudah ada alat yang cukup :/

@YvanDaSilva Upaya AMD agak kurang terkoordinasi saat ini (ya, semua garpu). Juga tampaknya belum berfungsi dengan baik pada berbagai macam perangkat, tidak seperti cabang OpenCL dari Caffe, misalnya...

@naibaf7 Saya sangat setuju.
Sejujurnya, mereka tampaknya benar-benar kekurangan sumber daya manusia, mereka bekerja di semua lini.
Omong-omong: Tidak tahu ETH memiliki Neuroinformatika ;) bagus !

@cathalgarvey Bisakah Anda menguraikan tumpukan ROCm/HIP untuk orang awam seperti saya. Saya telah memainkan AMGPU-pro dan AMDGPU dengan kartu Kepulauan Laut saya, jadi saya yakin saya dapat memposting beberapa hasil yang bermanfaat.

@YvanDaSilva
Mereka mensponsori proyek OpenCL Caffe asli saya, dan sayangnya tidak terkoordinasi dengan baik, jadi penelitian AMD dan orang independen di AMD juga bekerja pada port OpenCL secara paralel - mantan tim peneliti AMD sekarang tidak berfungsi dan kebanyakan dari mereka benar-benar bekerja untuk Tesla ( proyek mobil mengemudi sendiri) sekarang ... jadi rangkaian peristiwa yang tidak menguntungkan.
Saya masih bekerja sama & berhubungan dengan mereka. Vega akan menarik :)

@naibaf7 Bagus, kamu beruntung! Berharap ada studi seperti itu ketika saya berada di Heig-vd pasti akan melanjutkan ke MSc.

Ya... Itu yang kupikirkan. Begitu banyak pekerjaan, begitu sedikit sumber daya manusia yang tersedia di bidang ini.

Semua hal itu terdengar hebat, tetapi mari kita fokuskan kembali pada diskusi agar TensorFlow bekerja dengan OpenCL SYCL dan tidak hanya solusi khusus vendor... :-)
Saya harap RoC dan HiP lainnya memiliki GitHub mereka sendiri untuk mendiskusikan masalah mereka sendiri...
@naibaf7 : setidaknya saya masih di ranah OpenCL. Bergabunglah dengan klub lagi! :-)

@keryell Saya pikir diskusi tentang HIP valid, jika ada port HIP untuk Tensorflow sedang bekerja. Lagi pula, solusi Tensorflow-on-CL resmi adalah menggunakan kerangka kerja SYCL berpemilik dengan platform dan dukungan kernel yang sangat terbatas, jadi ini tidak lebih baik daripada solusi HIP "khusus vendor" yang menawarkan jalan keluar baru dari CUDA.

HIP mungkin sebagian besar dilakukan AMD saat ini, tetapi AFAIK itu standar terbuka? Mungkin saya salah. Jika ya, dan jika AMD dapat mengirimkan port tensorflow-on-HIP, port tersebut akan segera lebih terbuka daripada port tensorflow-on-SYCL resmi.

HIP adalah bagian dari CUDA, jadi sama terbukanya dengan CUDA.

Baiklah; HIP-the-API adalah bagian dari CUDA-the-API, tetapi kecuali NVidia cukup membutuhkan untuk mulai menyalurkan Oracle, saya ragu itu akan menjadi masalah. Saya mengacu pada runtime/kompiler untuk HIP, yang menurut saya AMD ~ terbuka.

sunting : Maaf jika hal di atas terdengar kasar; hanya mencoba untuk memperjelas posisi saya di atas!

Apakah Vulkan dan Opencl akan menyatu ?

@cathalgarvey diskusinya jelas valid, tapi tidak di sini...
Anda berada di GitHub di sini, di jalur yang membahas port TensorFlow & Eigen menggunakan standar Khronos Group.
Ini bukan Twitter atau dinding Facebook Anda... :-)
Jadi tolong berkontribusi dengan beberapa komitmen pada proyek-proyek ini! :-)

Ada versi baru panduan penyiapan untuk mengkompilasi TensorFlow dengan ComputeCpp, implementasi Codeplay dari SYCL, sehingga perangkat OpenCL dapat digunakan. Kami akan sangat menghargai umpan balik yang dapat Anda berikan kepada kami. https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp

apakah Anda tahu berapa tingkat keberhasilannya agar ini berfungsi pada GPU AMD yang belum diuji? Saya secara khusus tertarik jika sudah diuji untuk AMD Radeon Pro 460 @rodburns. Saya akan dengan senang hati menghabiskan beberapa jam menjalankan ubuntu di laptop Macbook saya jika ada harapan dengan GPU yang belum teruji

@samhains kami belum menguji ini tetapi Anda bisa mencobanya. Anda perlu menggunakan beberapa driver AMD lama dengan Ubuntu yang mendukung ekstensi SPIR. Saya belum bisa mengetahui driver apa itu.

@samhains Jika rute codeplay gagal terkirim, jangan lewatkan tf-coriander , yang akhirnya dapat digunakan secara praktis di Ubuntu/Mac.

Saat ini saya sedang mengujinya di convnets, rnns dua arah, dan sebagainya dan semuanya tampak berfungsi dengan baik. Ini berjalan pada "vanilla" OpenCL 1.2 sehingga seharusnya mengaktifkan Tensorflow pada sejumlah besar perangkat keras yang relatif lama.

Masalahnya, untuk saat ini, ini didasarkan pada Tensorflow 0.11.

@rodburns. Saya mencoba mengikuti langkah-langkah yang tercantum pada tautan https://www.codeplay.com/products/computesuite/computecpp/guides/how-to-setup-tensorflow-with-computecpp
Saya mendapatkan kesalahan berikut:
GALAT: /home/sayantan/.cache/bazel/_bazel_sayantan/6f05f78a1e215999d72e42c1e87a8c1d/external/protobuf/ BUILD:609 :1: penyertaan yang tidak dideklarasikan dalam aturan '@protobuf//:python/google/protobuf_internal/_soapif ':
Sebenarnya saya mendapatkan kesalahan yang sama jika saya mencoba mengkompilasi tensorflow dari sumber. Saya telah mengkompilasinya sebelumnya, tidak yakin apa yang telah berubah.

@rahasayantan apa itu termasuk? Anda juga mendapatkannya saat kompilasi tanpa --config=sycl ?

@lukeiwanski : Masalah yang saya pahami adalah Bazel mencoba mengkompilasi Protobuf dan tidak menemukan atau mengunduh sub direktori. Saya melakukan tarik dengan submodule rekursif masih memiliki masalah yang sama. Dan memiliki masalah yang sama tanpa --config = sycl. Sebenarnya saya menghadapi masalah yang sama ketika saya melakukan git pull dari proyek utama tensorflow. Saya tidak berpikir ini terkait dengan openCL, ini beberapa masalah dengan cara saya melakukan tarikan. Ketika saya mengunduh Zip proyek secara manual dari repo Anda tanpa git dan kompilasi, itu dikompilasi dengan benar, tetapi kemudian saya mendapatkan kesalahan segmentasi. Saya telah mengangkat masalah ini pada proyek GIT Anda dan kita berbicara di sana, saya akan memberikan pembaruan terkait dengan kesalahan segmentasi pada utas itu (tidak ada gunanya menduplikasi). Terimakasih atas tanggapan Anda.

triSYCL opensource akan tiba. Lihat https://github.com/triSYCL/triSYCL/pull/45

Saya baru disini. Sangat tertarik melihat TF mendukung OpenCL. Bagaimana cara mendapatkan pembaruan dari utas ini?

emmm...Menarik, tapi kenapa? Maksud saya mengapa Tensorflow memilih cuda tetapi opencl di awal? Beberapa alasan komersial saya kira?

Hai @tensorflower-gardener,

@hughperkins telah membuat Coriander yang dapat menjalankan kode NVIDIA® CUDA™ pada perangkat OpenCL 1.2. Anda mungkin ingin melihat apakah itu sesuai dengan kebutuhan Anda untuk menghubungkan TF ke perangkat OpenCL 1.2. Mohon cantumkan nama dan kontribusinya jika Anda berencana untuk menggunakan karyanya.

Tampaknya harapan untuk melihat dukungan OpenCL untuk Mac telah berubah dari sedikit menjadi tf.zero . Saya baru saja membaca bahwa TensorFlow Mac tampaknya tidak lagi memiliki dukungan GPU APAPUN (1.2+):

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

wtf

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

TF-Coriander diuji pada Mac, jadi jika/ketika mencapai paritas versi, Anda harus dapat menggunakannya.

Pada 22 Juni 2017 11:46:51 CEST, dylib [email protected] menulis:

Tampaknya harapan untuk melihat dukungan OpenCL untuk Mac telah hilang
sedikit menjadi tf.zero . Saya baru saja membaca bahwa Mac tidak akan ada lagi
Dukungan GPU APAPUN rupanya (1.2+):

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

wtf

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

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -310331281

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Sedih karena sekarang dengan eGPU dan n Nvidia 980 Ti di dalamnya, kami membuat driver berfungsi dan Cuda berfungsi

Saya belum punya waktu untuk mencoba Tensor Flow dalam konfigurasi saya.

webdriver dan toolkit Cuda terinstal di komputer saya dan sampel Cuda berfungsi dengan baik

https://youtu.be/JN9fDmqf010

@cathalgarvey Anda mengatakan bahwa Anda menguji convnets pada tf-coriander, tetapi sepertinya convnets belum berfungsi. Bisakah Anda menjelaskan jika Anda berhasil menjalankan konvnet di GPU menggunakan tf-coriander?

Mengapa tensorflow tidak lagi mendukung GPU di OS X? Saya berencana menggunakan Tensorflow dengan pengaturan eGPU yang saya pesan.

@justinrmiller mereka mengklaim bahwa mereka tidak dapat mengujinya lagi di mac os, dan karena itu memutuskan untuk menghentikan dukungan. namun, aku sulit mempercayainya. Ke depan dengan iklan egpus di sierra tinggi dan dengan driver nvidia baru, ini tidak akan lagi terjadi.

@tscholak ya persis. Saya akan menggunakan enklosur egpu baru saya untuk membuang kotak windows saya untuk selamanya.

Perlu diingat bahwa meskipun kartu Nvidia berfungsi di enklosur eGPU, Apple hanya akan secara resmi mendukung RX580 dalam kit dev mereka, sehingga kebutuhan akan OpenCL tidak akan hilang.

OpenCL di Mac adalah 1.2 yang berarti sepertinya tidak ada driver yang aktif
perkembangan. Saya pikir menambahkan dukungan Metal ke TF adalah proses yang melelahkan
(mengaktifkan Eigen dan pelaksana streaming) tetapi bisa dilakukan.

Pada Minggu, 16 Juli 2017 pukul 15:17 Ferdia [email protected]
menulis:

Ingatlah bahwa meskipun kartu Nvidia berfungsi di enklosur eGPU, Apple
hanya akan secara resmi mendukung RX580 dalam kit dev mereka, jadi perlu untuk
OpenCL tidak akan hilang.


Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-315634166 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACFkv3bmDr_KFSydC-QW_xbuR008pvLXks5sOm_kgaJpZM4Gex3i
.

Saya sangat sedih dengan ditinggalkannya dukungan GPU untuk macOS.

Masih mencari dukungan OpenCL untuk GPU di macOS karena Apple jelas tidak akan mengubah ke GPU Nvidia dalam waktu dekat.

Tensorflow adalah mesin pilihan saya. Menggunakan akselerasi GPU secara lokal di MacBook Pro saya atau iMac Pro masa depan akan luar biasa.

Bagi Microsoft, masuk akal untuk menyabotase Apple, tetapi karena Google tidak memiliki OS desktop, mereka hanya merugikan diri mereka sendiri.

Jujur saja, seseorang yang lebih pintar dari saya harus melihat ke dalam mengintegrasikan MPS Mac OS 10.13 - Metal Performance Shaders yang memiliki dukungan untuk sekumpulan besar jaringan saraf primitif di luar kotak. Ini akan memungkinkan penerapan inferensi terkini, GPU performa tinggi untuk seluler dan Desktop iOS dan macOS Tensorflow.

Anda tidak dapat berlatih dengan primitif Apel seperti yang saya pahami (mereka tidak memberikan apa pun), tetapi dengan dukungan Tensorflow mungkin Anda bisa? Saya membayangkannya untuk orang-orang di platform Apple yang akan menjadi keuntungan.

Saya tidak berpikir Google akan menyediakan ini secara internal, dan saya hampir tidak memiliki keterampilan yang diperlukan untuk mencobanya sendiri. Memposting ide ini agar orang-orang lebih berbakat daripada yang mungkin saya ambil.

:)

Apple semata-mata bertujuan untuk menjual perangkat Apple. Google bertujuan untuk menyewa layanan besar-besaran Google.

Jika Anda ingin melakukan AI (belajar) dengan satu perangkat, seperti satu Laptop Apple, Anda akan melakukan "Pembelajaran Superfisial" daripada "Pembelajaran Mendalam", jadi sebaiknya Anda berhenti melakukan apa pun selain tutorial. Hasil inferensi dalam model terlatih untuk satu pengguna tunggal, dalam satu perangkat (bahkan di telepon multicore yang tidak terlalu banyak), dapat dilakukan dengan baik melalui GPU, tetapi hanya dapat dilakukan dengan CPU.

Di sisi lain, GPU mutlak diperlukan jika Anda akan memberi makan kumpulan data yang sangat besar untuk pembelajaran atau Anda akan menyajikan inferensi terlatih ke grup pelanggan bersamaan yang sangat besar.

Meskipun melakukannya dalam skala seperti itu, tidak semudah itu karena masalah jaringan. Lihat saja arsitektur fisik TPU-Pods. Itu ada di antipode laptop (beberapa GPU per server multi-core yang kelebihan memori, dengan serat optik khusus untuk komunikasi antar-server).

Saya memiliki MacBook Pro. Ini terminal yang bagus untuk sampai ke cloud :-D

Saya melihat TF di Metal dapat diperluas ke iOS juga. Jika ada yang tertarik untuk mengambilnya, saya sarankan untuk menambahkan dukungan Metal ke Eigen terlebih dahulu (bisa menggunakan OpenCL sebagai referensi).

@rogerpasky Untuk sekolah saya harus menggunakan Tensorflow untuk model pelatihan, bukan hanya untuk mengevaluasi model. Dan saya harus mengulangi ini lagi dalam waktu dekat. Bagi siswa seperti saya, pelatihan GPU adalah suatu keharusan, menghemat banyak waktu. Ini bukan hanya masalah untuk melayani beberapa pengguna secara bersamaan.

@rogerpasky ini tentang kemampuan untuk mengembangkan model dan solusi secara lokal di mac

@rogerpasky dengan hormat tidak setuju. Sementara solusi multi-GPU berbasis cloud bekerja sangat baik untuk layanan internet, saya menargetkan saluran produksi video profesional di mana inferensi dijalankan pada jam dan jam pro-res dan rekaman HD, 2K, 4K yang tidak terkompresi, yang a) tidak ada rumah produksi akan mengunggah ke cloud, b) mereka tidak ingin google atau siapa pun memiliki data mereka, c) mereka memiliki ruangan yang penuh dengan sistem berkemampuan multi GPU (Mac dan Windows) secara lokal yang ingin mereka manfaatkan, dan d) sementara inferensi pada satu gambar baik-baik saja di CPU, menjalankan seluruh film untuk inferensi melalui beberapa grafik 100% melihat peningkatan perf menggunakan sesuatu seperti MPS vs CPU. Karena komunitas telah menolak untuk mendukung/menerima standar dan sebagai gantinya menggunakan kode Nvidia saja, kasus penggunaan di dunia nyata menjadi kacau balau dan itu benar-benar memalukan.

Ini bukan permintaan kosong dari seseorang yang hobi menjalankan tutorial - inferensi GPU penting karena mendukung beragam keluarga GPU / CPU untuk beban kerja yang beragam pada perangkat keras dunia nyata. Saya sangat berharap Google menganggap ini serius, karena akan sangat bagus untuk tetap menggunakan satu perpustakaan seperti TF, yang luar biasa.

Terima kasih telah mendengarkan saya, saya tidak mencoba untuk mengoceh, tetapi untuk memberikan sudut pandang alternatif kepada komunitas.

@pldelisle , @tscholak , @vade tolong jangan salah paham. Saya ingin memilikinya, dan jika Anda mencari di utas ini, saya bergabung sebagai pendukung, tetapi sejauh yang saya ikuti, saya sampai pada kesimpulan yang saya tulis, bukan hanya karena saya pikir begitu (saya kira a MacBook akan meleleh jika dilatih dengan ribuan video :-D), tetapi dengan fakta industri yang sebenarnya. Jangan menunggu untuk menyelesaikannya dalam jangka waktu yang singkat (IMHO, itu tidak akan pernah terpecahkan karena Apple dan Google saling membenci sejak masalah iPhone/Android).

@rogerpasky Sudah ada dukungan untuk GPU nvidia di Mac OS. Itu baru saja dihapus di 1.2.

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

Saya telah membatalkan pesanan saya untuk eGPU (Sonnet) dan hanya akan melakukan dual boot Linux pada rig game saya, tetapi ini agak buruk untuk berhenti mendukung sesuatu yang digunakan orang. Sangat berharap untuk melakukan ini di mac saya dengan eGPU (pelatihan model), tapi saya rasa itu tidak akan terjadi sekarang: https://github.com/lengstrom/fast-style-transfer

@rogerpasky Er, Anda tahu CoreML mendukung pengimporan model aliran tensor melalui Keras? Apple tidak 'membenci' Google, bisnis adalah bisnis, Salah satu pemasok Apel adalah Samsung. Bacalah itu sejenak. Google, Apple, Samsung adalah bisnis dan akan melakukan apa yang menghasilkan uang. Sebagai catatan sampingan. MacBook Pro saya belum meleleh karena menjalankan inferensi pada ribuan film. Saya menduga CUDA sangat nyaman untuk mengadopsi dan melanjutkan dukungan dari Nvidia dan melewatkan peluang dari AMD membawa kami ke tempat kami sekarang. Saya tidak berpikir itu jahat, hanya biaya membuat perubahan vs delta kinerja vs biaya tetap kursus.

Saya menduga beberapa jenius akan datang untuk membantu memecahkan masalah ini.

Saya telah membuat Grup Google untuk diskusi kolaboratif tentang membawa pembelajaran mendalam ke tempat-tempat baru seperti OpenCL, Mac, iOS, CoreML, Vulkan, dll. Jika Anda ingin membantu mewujudkannya, silakan bergabung dan kirim catatan dengan penggunaan Anda kasus atau bagian mana dari masalah yang sedang Anda kerjakan. Sudah ada orang yang bekerja sangat keras dalam upaya membawa TF ke lebih banyak platform termasuk MIOpen, pekerjaan Codeplay, TF-Coriander, dan proyek internal di perusahaan saya (Vertex.AI). Akan sangat bagus untuk mendapatkan pengembang & pengguna di satu tempat karena semua upaya ini terkait erat.

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

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

@justinrmiller Saya memiliki eGPU di Sierra (Titan Xp dalam selungkup Soneta) yang menjalankan Tensorflow 1.2.1 (CUDA 8, cuDNN 6) yang tidak terlalu merepotkan jika Anda tidak keberatan membangun dari awal. Jika Anda memiliki masalah, beri tahu saya.

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 Luar biasa! Terimakasih atas infonya!

@danbarnes333 bagaimana Anda mendapatkan tf 1.2 untuk dibangun dengan cuDNN 6? Apakah Anda menggunakan LLVM? GCC? Saya hanya berhasil membuatnya dibangun dengan cuDNN 5 ...

@tscholak Saya tidak akan mempostingnya di sini untuk menyimpan ini di OpenCL tetapi saya tidak akan merangkum langkah-langkahnya di sini .

@choongng Saya bergabung dengan Grup Google tetapi tampaknya sepi. Jadi saya akan mengoceh di sini ;-)

  1. Pembelajaran mesin / komputasi kinerja tinggi / GPU adalah pasar yang sangat kompetitif. NVidia, suka atau tidak, mendominasi pasar dan menjaga kartu dan perangkat lunak mereka tetap dekat dengan rompi. Jika Anda memiliki anggaran dan tenggat waktu, Anda kurang lebih terjebak dengan NVidia untuk saat ini.

  2. Saya punya kartu AMD kuno ("Bonaire") dan anggaran nol - penghobi. Saya menjalankan caffe dengan implementasi AMD OpenCL 2 berpemilik di Arch Linux mulai kemarin, dan saya baru saja menjalankan MIOpen open source AMD dengan cara yang sama pagi ini. Itu akan membiarkan saya melatih beberapa model; puncak Bonaire sekitar 1800 GFLOPS presisi tunggal. Jadi jika TensorFlow tidak berjalan dengan OpenCL di Bonaire, saya tidak akan menggunakan TensorFlow.

  3. Jika anggaran muncul secara ajaib, saya akan membeli CPU Intel dan kartu NVidia dan menjalankan perangkat lunak berpemilik yang didukung vendor. Saya sudah selesai melakukan QA tidak berbayar untuk vendor seperti Google, Red Hat, Canonical, dan AMD.

    Saya membutuhkan waktu tiga bulan (dan tiga distro - Fedora 25, Ubuntu 16.04 LTS dan Arch) untuk mendapatkan sesuatu dari GPU yang saya miliki selama tiga tahun. Ada bug yang belum diperbaiki di pelacak bug Fedora dengan nama saya di atasnya. Hal yang sama berlaku untuk Ubuntu dan Freedesktop.org. Sebagian besar orang yang akan memperbaikinya juga tidak dibayar, atau mereka dibayar untuk melakukan sesuatu yang lain.

    Ya, CPU baru AMD sangat mengesankan, dan ya, sebagian besar perangkat lunak mereka adalah open source, tetapi anggaran dan tenggat waktu mengubah banyak hal. Dukungan adalah kuncinya. Dukungan adalah segalanya!

@znmeb Saya bahkan tidak tahu Anda bisa menggunakan perangkat keras pra-GCN untuk TF.
Dengan Tahiti saya, saya hanya memiliki dukungan melemparkan satu distro (ubuntu 14.01.x) karena driver berpemilik AMD hanya berfungsi dengan kernel linux yang lebih lama untuk GCN1. (Saya mendapatkan TF + openCL melalui SYCL (belum diuji pada 7970))

Di tempat saya bekerja, seluruh departemen R&D menjalankan tim hijau. Mereka semua memiliki PHD dan semua kecuali tidak ada yang menulis satu baris cuda (atau OCL). Namun alat ini hadir untuk mempercepat beban kerja Keras mereka. Saya agak aneh dengan GPU penambangan daur ulang saya yang mencoba memeras kehidupan kedua dari mereka.

tl;dr selain dukungan tim hijau hanya akan muncul jika pangsa pasar GPU AMD muncul.
Ini masalah ayam dan telur. Saya memiliki harapan untuk vega ... tapi ya ... bukan pembunuh 1080Ti.

@acoye FWIW inilah pos GitHub yang membuat saya pergi akhir pekan ini setelah meronta-ronta dan Googling sejak April: https://github.com/BVLC/caffe/issues/5804#issuecomment-318789942 . Lihat juga https://github.com/cdeterman/gpuR/issues/77#issuecomment-318814154 . Itu adalah masalah awal saya - mencoba menggunakan Bonaire saya untuk mempercepat aljabar linier pada R.

@acoy
Anda dapat beralih ke distro Linux terbaru & menggunakan kernel terkompilasi khusus terbaru seperti 4.11/4.12 dengan driver AMDGPU diaktifkan, RADEON dinonaktifkan dan dengan CONFIG_DRM_AMDGPU_SI=Y dan/atau CONFIG_DRM_AMDGPU_CIK=Y diatur dalam konfigurasi kernel, ditambah firmware AMD untuk 7970 (Tahiti) di initramfs => AMDGPU-PRO OpenCL terbaru akan bekerja pada kartu GCN apa pun. Lupakan FGLRX (pada distro Linux yang lebih lama) dan Clover melalui driver RADEON, keduanya di bawah standar.
Lupakan juga kartu pra-GCN. Saya mengujinya menggunakan OpenCL pada Windows untuk Caffe, kinerjanya tidak sebanding dengan upaya untuk kartu lama seperti itu. Karena semua kartu AMD pasca 2012 harus GCN.

@ naibaf7 Saya menghabiskan beberapa jam kemarin mencoba membuat tumpukan sumber terbuka AMD berfungsi. Saya mendapatkan MIOpen dan dependensinya tetapi hcc masih kehilangan beberapa bit. Saya mungkin perlu melakukan pembuatan kernel khusus untuk mendapatkan semuanya. Saya tidak terlalu peduli tentang mem-porting kode CUDA atau menjalankan C++ yang dikompilasi pada GPU - saya ingin melakukan penghitungan angka di atasnya. ;-)

Saya juga melihat sesuatu di situs web mereka tentang memprogramnya dalam assembler - yang mungkin menarik bagi saya, karena mudah untuk beralih dari assembler ke FORTH. ;-)

@znmeb Ya, saya juga mencoba untuk membuat beberapa MIOpen dan TensorFlow bekerja pada RX 480 saya, tetapi saya tidak ingin menghancurkan rig pengembangan utama saya, jadi saya menggunakan virtualisasi IOMMU dan menggunakan mesin virtual Ubuntu 16.04 yang dapat menggunakan RX 480. Driver AMD sangat ramah terhadap virtualisasi (tidak seperti driver nVidia yang dibuat untuk kartu game - hanya driver Quadro yang melakukannya).

@znmeb Yang harus Anda lakukan adalah sudo apt-get install rocm miopen-hip

@adityaatluri Ada di Arch User Repository tetapi tidak diinstal - juga tidak diinstal dari sumber GitHub. Sepertinya sesuatu yang sederhana - tidak dapat menemukan beberapa dependensi.

@znmeb Bisakah Anda membuat masalah di sini (https://github.com/RadeonOpenCompute/ROCm/issues) sehingga kita bisa berdiskusi di sana? Terima kasih!

@adityaatluri Tentu - Saya akan makan malam tetapi saya akan mengajukannya ketika saya kembali

@ebrevdo Adakah cara untuk menggunakan GPU tensorflow di Mac dengan prosesor AMD?

Perusahaan saya telah mengerjakan pembelajaran mendalam OpenCL untuk sementara waktu dan kami memiliki beberapa hasil awal untuk ditunjukkan. Kami berfokus pada Keras dalam waktu dekat, namun kami juga telah membangun dukungan TensorFlow (sangat) eksperimental dan akan meninjaunya kembali setelah rilis awal kami. Detail lebih lanjut di sini termasuk nomor throughput awal pada AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl

Dingin!

Nitpick kecil: AFAIK, MIOpen tidak spesifik untuk AMD, karena dapat ditautkan ke OpenCL dan juga ke ROCm. Yang terakhir mungkin lebih cepat, tapi tetap saja; MIOpen adalah langkah maju yang besar untuk shtick "Open Source Neural Networks On GPU", dan AMD layak mendapat kepercayaan besar untuk itu jika bekerja dengan baik di OpenCL.

14 Agustus 2017 17:19, "Choong Ng" menulis:
Perusahaan saya telah mengerjakan pembelajaran mendalam OpenCL untuk sementara waktu dan kami memiliki beberapa hasil awal untuk ditunjukkan. Kami berfokus pada Keras dalam waktu dekat, namun kami juga telah membangun dukungan TensorFlow (sangat) eksperimental dan akan meninjaunya kembali setelah rilis awal kami. Detail lebih lanjut di sini termasuk nomor throughput awal pada AMD: http://vertex.ai/blog/bringing-deep-learning-to-opencl (http://vertex.ai/blog/bringing-deep-learning-to-opencl)

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub (https://github.com/tensorflow/tensorflow/issues/22#issuecomment-322235416), atau nonaktifkan utas (https://github.com/notifications/unsubscribe-auth /ABHR3VYHXFDEX0gPHTGLSbFeHjPfEfsXks5sYHOGgaJpZM4Gex3i).

@cathalgarvey Terima kasih atas koreksinya, saya mendasarkan komentar saya dari persyaratan sistem dalam dokumentasi MIOpen (https://rocmsoftwareplatform.github.io/MIOpen/doc/html/install.html#presyarats) tetapi senang memperbarui jika ada tautan yang lebih baik.

Tunggu, saya sudah membaca utas/masalah ini selama 10 menit sekarang. Saya melewati setengah jalan dan saya melewatkan sisanya. Apakah GPU AMD sudah didukung?

Menggunakan hal sumber tertutup yang rewel yang hanya berfungsi pada satu kombinasi Kernel/OS yang sangat lama (permainan kode): ya

Menggunakan versi lama tensorflow dan tanpa dukungan untuk beberapa nonlinier (tf-ketumbar): ya.

Sungguh: tidak secara resmi. Meskipun AMD porting ke HIP, jadi saya mengharapkan kemajuan dalam 3 bulan atau lebih. Kerangka kerja lain sudah bekerja dengan baik karena upaya mereka.

Pada 18 Agustus 2017 02:09:55 GMT+01:00, abrad1212 [email protected] menulis:

Tunggu, saya sudah membaca utas/masalah ini selama 10 menit sekarang. aku sudah setengah jalan
melalui dan saya melewatkan sisanya. Apakah GPU AMD sudah didukung?

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -323233294

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

FWIW Saya percaya versi terbaru dari PyGpu dapat menggunakan CUDA atau OpenCL. Saya memiliki semua perangkat lunak yang diinstal pada kotak Arch saya tetapi saya belum mengujinya.

@abrad1212 ya, masalah ini sudah ada sejak lama. Upayanya sangat besar dan banyak orang mencoba "membuatnya berfungsi" seperti yang disebutkan @cathalgarvey .

Sedikit update dari kami. Anda harus dapat menggunakan ComputeCpp 0.3.0 pada tumpukan driver AMDGPU-pro untuk Ubuntu 16.04, petunjuknya dapat ditemukan di sini: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16 -04-lts/

Selain itu, kami sekarang berfokus pada peningkatan kinerja untuk model yang berbeda - ada banyak hal yang harus dilakukan tetapi kami sedang menuju ke sana.

@lukeiwanski Apa pendekatan Anda terhadap pembandingan? Kami mengatur waktu model yang disertakan dengan Keras dan menormalkan terhadap TF+cuDNN+K80 karena itu adalah konfigurasi yang umum dan dioptimalkan dengan baik. Metodologi kami mirip dengan Max Woolf (http://minimaxir.com/2017/06/keras-cntk/), tidak banyak kode tetapi kami akan dengan senang hati membagikannya. Kami memiliki beberapa nomor throughput di situs web kami (http://vertex.ai), kode kami sedikit lebih cepat daripada TF 1.2 pada inferensi Xception dan akan menarik untuk membandingkan lebih banyak pendekatan secara berdampingan.

Apakah ada solusi Windows? Saya akan menginstal Ubuntu di PC saya tetapi saat ini saya tidak memiliki cukup ruang untuk melakukannya.

ubuntu 14.04
cabang master tensorflow
membangun dukungan opencl, dan hanya runtime opencl intel cpu yang diinstal.
python2.7
ikuti https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow panduan
jalankan python class_image.py
sepertinya tidak memanggil driver opencl. (Saya menambahkan pembungkus icd opencl saya, tidak melihat apa-apa)
Apakah ada konfigurasi yang perlu ditambahkan dalam kode python?
Seperti sess.graph.device('/cpu0')

Tetapi jika saya menggunakan panduan skcl Eigen dapat berjalan di cpu dengan dukungan OpenCL. (Juga kode panduan ini sedikit ketinggalan zaman, perlu beberapa modifikasi)
https://developer.codeplay.com/computecppce/latest/getting-started-with-eigen

Siapa pun dapat membantu memeriksa bagaimana antarmuka python tensorflow juga dapat berjalan dengan dukungan OpenCL.

Dan membangun tensorflow dengan set opt ​​ini tidak akan benar-benar menghasilkan biner tensorflow. --config=sycl
Cukup buat tensorflow dalam perintah ini:
bazel build -c opt /tensorflow/tools/pip_ package:build_pip_package

Mungkin saya membangun lupa --config=sycl
Saya akan mencoba membangun perintah dan memverifikasi apakah itu dapat memanggil perpustakaan OpenCL. Setelah mendapatkan hasil, saya akan posting di sini.
bazel build -c opt tensorflow/tools/pip_ package:build_pip_package

@ joe8086 Jika Anda memodifikasi pembuatan tf.Session dengan di bawah ini, ini akan menampilkan log di terminal, apakah ini menyebutkan SYCL di mana saja?
tf.Session(config=tf.ConfigProto(log_device_placement=True))

Untuk panduan Eigen, apakah Anda memiliki umpan balik khusus jika sudah ketinggalan zaman?

@rodburns Terima kasih.
Kesalahan saya adalah build tensorflow miss config option --config=sycl
Setelah menambahkan opsi ini dengan kode cabang ini https://github.com/lukeiwanski/tensorflow.git
Saya dapat melihat tensorflow berjalan dengan backend OpenCL.

Untuk panduan Eigen, kesalahan utama ada di:
1, tidak memberikan file sertakan yang benar.
2, untuk array, Tensor, TensorMap tidak memberikan parameter templet yang benar.
3, untuk static_cast tidak memberikan tipe data.

tambahkan lebih banyak informasi yang mungkin membantu topik diskusi ini.
1, Tensorflow utama tidak dapat membangun tensorflow dengan --config=sycl benar.
2, Dengan CPU OpenCL, kecepatannya sekitar 4x~8x kali lebih banyak daripada implementasi CPU biasa di lingkungan saya.

waktu python classclass_image.py
07-09-2017 16:56:29.076054: I tensorflow/core/platform/cpu_feature_guard.cc:137] CPU Anda mendukung instruksi bahwa biner TensorFlow ini tidak dikompilasi untuk digunakan: SSE4.1 SSE4.2 AVX
07-09-2017 16:56:29.077967: W ./tensorflow/core/common_runtime/sycl/sycl_device.h:49] Tidak ditemukan GPU OpenCL yang didukung oleh ComputeCpp, mencoba CPU OpenCL
07-09-2017 16:56:29.159775: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:66] Ditemukan perangkat OpenCL berikut:
07-09-2017 16:56:29.159825: I ./tensorflow/core/common_runtime/sycl/sycl_device.h:68] id: 0, ketik: CPU, nama: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz, vendor: Intel(R) Corporation, profil: FULL_PROFILE
07-09-2017 16:56:30.213375: W ./tensorflow/core/framework/op_def_util.cc:333] Op BatchNormWithGlobalNormalization tidak digunakan lagi. Ini akan berhenti bekerja di GraphDef versi 9. Gunakan tf.nn.batch_normalization().
panda raksasa, panda, beruang panda, beruang coon, Ailuropoda melanoleuca (skor = 0,89107)
indri, indris, Indri indri, Indri brevicaudatus (skor = 0,00779)
panda kecil, panda merah, panda, kucing beruang, kucing beruang, Ailurus fulgens (skor = 0,00296)
puding apel (skor = 0,00147)
bintang bumi (skor = 0,00117)

nyata 1m44.473s
pengguna 2m8.980s
sys 1m20.024s

Teman-teman, saya tidak akan membaca seluruh utas ini, tetapi jika seseorang dapat menjawab pertanyaan saya, itu bagus! Bisakah saya menggunakan Tensorflow dengan GPU AMD. Jika demikian di sistem operasi apa, dan dapatkah saya melakukannya dengan RX Vega? Terima kasih!

@M3L0NM4N Hmmm ... Saya belum mengikuti utas tetapi sepertinya ada kode OpenCL yang mungkin dapat diuji sekarang, setidaknya pada CPU OpenCL. Saya memiliki GPU AMD ("Bonaire") yang lebih lama dan saya menjalankan OpenCL pada GPU dan CPU, jadi saya dapat menguji ini. Saya mungkin akan mencobanya selama akhir pekan; Saya sangat menginginkan OpenCL TensorFlow di GPU saya.

Adakah dukungan tensorflow 1.3 gpu/opencl di macos?

Berita terbaru: Saya telah berhasil membangun TensorFlow 1.3.1 dengan OpenCL dari sumber GitHub. Ada beberapa bagian yang hilang dalam dokumentasi, dan saya belum mencoba menjalankan apa pun di GPU, tetapi setidaknya berfungsi untuk CPU non-OpenCL. BTW, saya tidak menginstal CPU OpenCL, hanya GPU OpenCL.

Adakah yang punya kasus uji untuk TensorFlow dengan GPU OpenCL? Saya harus membangun satu untuk diri saya sendiri pada akhirnya, tetapi saya berharap untuk pemeriksaan cepat.

@znmeb Ya, ada aplikasi uji dalam masalah yang saya laporkan. https://github.com/hughperkins/tf-coriander/issues/64

Bisakah Anda memberi tahu saya jika itu berfungsi dalam kasus Anda?

@unoexperto Ya - itu berfungsi (tidak macet) tetapi tidak ada indikasi apakah itu menemukan OpenCL atau tidak.

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

Saya pikir tindakan terbaik di sini adalah mengajukan masalah terpisah untuk meminta dokumentasi, karena jelas (ketika Anda menjalankan ./configure membangun dari sumber) bahwa ada kode untuk OpenCL. Begitulah cara saya menemukannya.

@znmeb Saya ragu itu menemukan perangkat GPU dalam kasus Anda karena di tambang itu mencetak info debug di awal tentang memilih perangkat GPU. Mungkin Anda dapat mengkompilasi ulang dengan menambahkan printf ke konsol di suatu tempat di tensorflow/core/common_runtime/gpu/gpu_device.cc .

@unoexperto Saya bergabung dengan grup diskusi Google dan memposting permintaan dokumentasi. Saya akan menunggu untuk melihat apakah ada yang merespons sebelum saya berusaha lebih keras untuk ini.

@znmeb Instruksi apa yang Anda ikuti? Sudahkah Anda menjalankan clinfo? Sudahkah Anda menjalankan computecpp_info? Apakah itu menunjukkan bahwa driver OpenCL Anda diinstal seperti yang diharapkan? Petunjuk untuk Ubuntu 14.04 ada di sini https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow dan jika Anda menggunakan 16.04 ada beberapa petunjuk eksperimental di sini http://deep-beta.co. uk/tensorflow-1-3-on-ubuntu-16-04-lts/

@rodburns clinfo dan clpeak keduanya berjalan. Saya belum melakukan ini baru-baru ini, tetapi ketika saya membuat caffe dari sumber dan menjalankan tes, itu pasti mengenai GPU. Jadi saya cukup yakin driver/library OpenCL/GPU berfungsi.

Saya menggunakan Arch Linux - kernel adalah LTS mereka - linux-lts 4.9.52-1. Jika itu penting, "Bonaire" memuncak sekitar 1,7 TFLOPS dalam mode 32-bit dan berada dalam keluarga GPU AMD "Pulau Laut".

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

Apakah seseorang mengumpulkan log pengujian? Dikatakan perangkat saya belum diuji jadi saya akan mengujinya. ;-)

Mustahil bagi saya untuk membangun TensorFlow untuk Sycl/OpenCL !

Konfigurasi:
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

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

Kesalahan:

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

Model pelatihan pada CPU saya membutuhkan waktu lama, saya sangat membutuhkan akselerasi OpenCL/GPU ...

@ErwanGalline Kami sedang dalam proses upsreaming perubahan Eigen ( https://bitbucket.org/benoitsteiner/opencl/pull-requests/16/changes-required-for-new-computecpp-ce/diff#comment-None ) yang akan memperbaiki masalah yang Anda lihat.

Kami juga sedang bersiap untuk meningkatkan kinerja hulu ke Eigen - ini agak rumit dan perlu koordinasi dengan @benoitsteiner untuk menghindari aliran konflik penggabungan - tetapi kami sudah sampai di sana.

Untuk pengguna AMD saya sarankan mencoba garpu saya: https://github.com/lukeiwanski/tensorflow/tree/dev/AMD_gpu
Petunjuk pengaturan untuk Ubuntu 16.04 dapat ditemukan di sini: http://deep-beta.co.uk/tensorflow-1-3-on-ubuntu-16-04-lts/
Semua perubahan akan mengarah ke tensorflow setelah perubahan Eigen yang disebutkan sebelumnya diterapkan.

Semoga membantu.

@lukeiwanski Apakah garpu Anda hanya mendukung GPU AMD R9 Nano / AMD FirePro?

@lukeiwanski Apakah ada kasus uji yang dapat saya gunakan untuk memverifikasi bahwa saya menggunakan GPU? Saya dapat memantaunya dengan radeontop tetapi saya ingin sesuatu yang menggunakan TensorFlow itu sendiri.

@ZixuanLiang tidak, tidak hanya..
Saat ini kami menguji pada AMD ( R9 380, R9 Nano, FirePro ). Kami tahu GPU Intel memperlihatkan beberapa bug driver, tetapi ada perbaikan yang akan datang. Dan kami telah mengumumkan Renesas R-Car dan berharap lebih banyak lagi yang akan menyusul.

Saya percaya bahwa Xilinx meningkatkan dukungan untuk triSYCL https://github.com/tensorflow/tensorflow/pull/12882 - jadi FPG (?) - @keryell harus tahu lebih banyak tentang itu

@znmeb bazel test -c opt --config=sycl --test_output=all //tensorflow/python/kernel_tests:basic_gpu_test harus menjadi verifikasi yang adil .. output akan terlihat seperti ini:
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 Terima kasih saya akan mencobanya di AMD GPU

@lukeiwanski Pembuatan dan pengujian tampaknya berhasil di Bonaire saya. Saya menggunakan Python 3.6, dan instruksinya menggunakan Python 2.7. Apakah saya perlu menggunakan 2.7 atau akankah 3.6 berfungsi?

@znmeb Mengikuti https://github.com/tensorflow/tensorflow/issues/6533#issuecomment -273852647 sepertinya Python 3.6 seharusnya berfungsi - saya belum mencobanya

@lukeiwanski Apakah itu versi ComputeCpp yang dapat membangun TF saat ini?
Saya mencoba berbagai versi antara 0.3.2 dan 0.1.4 dan tidak ada yang berhasil. Semuanya berakhir dengan kesalahan "multiple overloads dari 'global_ptr' instantiate ke tanda tangan yang sama".
Btw, saya tidak dapat menemukan file TensorDeviceSycl.h di sumber TF, apakah itu yang diganti namanya? Apakah mungkin untuk menerapkan tambalan ke sumber saat ini?

Terima kasih sebelumnya.

@eLvErDe ComputeCpp 0.3.2 dapat membangun: https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu

Upstream tidak memiliki patch untuk Eigen yang memperbaikinya.. lihat https://github.com/tensorflow/tensorflow/issues/22#issuecomment -334154564

Adakah yang tahu bagaimana cara menyuntikkan tambalan Eigen ini selama pembuatan bazel? Mungkin kita harus bertemu versi Eigen tgz di suatu tempat untuk mendapatkan yang diperbaiki?

Terima kasih, Adam.

ya, Anda harus bisa memilih itu

Sayangnya, itu jelas tidak cukup, inilah beberapa kegagalan build berikutnya:

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 ada beberapa komitmen yang harus Anda terapkan untuk mengompilasinya.
Saya akan menyarankan menggunakan tip dev/AMD_gpu atau jika Anda tidak ingin mengubah cabang Anda saat ini.. Anda dapat menggabungkan dev/Amd_gpu ke sana.

Sebenarnya saya sedang mengerjakan paket Debian/Ubuntu tidak resmi saya jadi saya mencoba untuk tetap dekat dengan rilis resmi 1.3.1. Saya dapat hidup tanpa dukungan OpenCL tetapi saya akan siap untuk mengaktifkannya segera setelah didukung dengan benar. Mungkin saya akan memperbarui paket terhadap cabang Anda untuk tujuan pengujian, tapi itu cukup untuk hari ini ;)

Saya memiliki sekitar sepuluh jenis GPU AMD yang berbeda di rig penambangan saya. (dari 7970 hingga RX 480 menjalankan ubuntu 16.04 dan amdgpu-pro). Beri tahu saya jika saya dapat berkontribusi dengan menguji apa pun.

Beri tahu saya jika saya dapat berkontribusi dengan menguji apa pun.
Bagaimana dengan https://github.com/ROCmSoftwarePlatform/hipCaffe
https://github.com/ROCmSoftwarePlatform/hipeigen

Pada Selasa, 17 Oktober 2017 pukul 10:54, [email protected] menulis:

Saya memiliki sekitar sepuluh jenis GPU AMD yang berbeda di rig penambangan saya. (dari
7970 hingga RX 480 menjalankan ubuntu 16.04 dan amdgpu-pro). Beri tahu saya jika saya bisa
berkontribusi dengan menguji apa pun.


Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-337309059 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AA6MNxXJ-G3nCQUA9RucrJ8y4vs5NPtLks5stOnbgaJpZM4Gex3i
.

@lukeiwanski Akankah garpu Anda mendukung GPU AMD di macOS juga?

Hai,
Saya sedang membangun API tensorflow di Ubuntu16.04 x64 untuk perangkat Android saya dengan GPU (Mali-T720) diaktifkan,

Informasi OS saya:
Ubuntu 16.04 x64
GPU Komputer: NVIDIA 1080Ti
CUDA 8.0
CUDNN 5.1 ( meskipun saya tidak menggunakan cuda atau cudnn untuk membangun )
bazel 0,5.2
ComputeCpp CE 0.3.2

build.sh saya adalah:
'
bazel build -c opt --config=sycl //tensorflow/contrib/android:libtensorflow_cc.so --cxxopt="-
std=c++11" --cxxopt="-DTENSORFLOW_DISABLE_META" --verbose_failures --
crosstool_top=//eksternal:android/crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --
cpu=armeabi-v7a
'
sebelum membangun. Saya mengekspor LD_LIBRARY_PATH=my_sycl_lib_path=$LD_LIBRARY_PATH, membangun tanpa ' --config=sycl ' baik-baik saja dan saya mendapatkan libtensorflow_cc.so yang benar, tetapi dengan ' --config=sycl ', hasil akhirnya ternyata hilang -lComputeCpp tanpa yang lain kompilasi kesalahan

Log lengkap seperti ini:

GALAT: /home/e0024/workspace/tensorflow/tensorflow/contrib/android/BUILD:102:1: Penautan aturan '//tensorflow/contrib/android:libtensorflow.so' gagal: link_dynamic_library.sh gagal: kesalahan mengeksekusi perintah
(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/ game:/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 tidak diabaikan diabaikan eksternal/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -shared -o bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/contrib/android/libtensorflow.so '-Wl,-rpath,$ORIGIN/../../../ _solib_armeabi-V7A / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib '-Lbazel-out / arm-linux-androideabi-4.9-V7A-gnu-libstdcpp-opt / bin / _solib_armeabi-V7A / _U @local_Uconfig_Usycl_S_Ssycl_Csyclrt___Uexternal_Slocal_Uconfig_Usycl_Ssycl_Slib -Wl, -seluruh-arsip bazel-out / arm -linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/c/libc_api.a -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi- 4.9-v7a-gnu-libstdcpp-opt/bin/tensorflow/core/libandroid_tensorflow_lib.lo -Wl,-no-whole-archive -Wl,-whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu -libstdcpp-opt/bin/tensorflow/core/kernel/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 -arsip -Wl,-arsip lengkap bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf.a -Wl,-tidak-seluruh-arsip -Wl, -whole-archive bazel-out/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/external/protobuf/libprotobuf_lite.a -Wl,-no-whole-archive -lComputeCpp external/androidndk/ndk/ sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a external/androidndk/ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libsupc++.a -landroid -llog -lm -z defs -s -Wl,--gc-sections '-Wl,-soname=libtensorflow.so' -Wl,--version-script tensorflow/c/version_script.lds -lz -static-libgcc - no-canonical-prefixes '-march=armv7-a' -Wl,--fix-cortex-a8 '--sysroot=external/androidndk/ndk/platforms/android-14/arch-arm'): com.google.devtools.build.lib.shell.BadExitStatusException: Proses keluar dengan status 1.
external/androidndk/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../.. /Sarm-linux-androideabi/bin/ld: peringatan: melewatkan bazel-out yang tidak kompatibel/arm-linux-androideabi-4.9-v7a-gnu-libstdcpp-opt/bin/_solib_armeabi-v7a/_U@local_Uconfig_Usycl_S_Ssycl_Csyclrt_Uexternal_Slib mencari untuk 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: kesalahan: tidak dapat menemukan -lComputeCpp
kumpulkan2: kesalahan: ld mengembalikan 1 status keluar
Target //tensorflow/contrib/android:libtensorflow.so gagal dibuat
INFO: Waktu berlalu: 617,736 detik, Jalur Kritis: 54,66 detik

uhm.... Saya ingin membangun API tensorflow di lengan dengan GPU (Mali-T720) diaktifkan,
Dihargai jika seseorang bisa meninggalkan beberapa pengalaman atau saran di sini. Thx a lot.

Datang ke pembicaraan saya minggu depan di Arm TechCon, @laMia482 ! http://schedule.armtechcon.com/session/running-tensorflow-machine-learning-on-arm-embedded-hardware/850230

Anda akan memerlukan driver Mali dengan dukungan SPIR-V, yang mungkin belum tersedia dengan mudah. Dan Anda akan memerlukan runtime ComputeCpp untuk Android dengan dukungan Arm CPU dan dukungan SPIR-V, yang juga belum tersedia (belum). Jadi, Anda harus sedikit _sedikit_ sabar.

Kami (Vertex.AI) baru saja membuka PlaidML, tumpukan pembelajaran mendalam kami dengan dukungan untuk menjalankan Keras di OpenCL. Dukungan TensorFlow akan datang, bantuan akan diterima. Dan ya, dukungan Mac sedang dalam proses (juga Windows). http://vertex.ai/blog/announcing-plaidml @ggaabe

@choongng saya ingin mencobanya tetapi gagal.
pip search plaidml kembali

plaidml (0.1.0rc3)        - PlaidML machine learning accelerator

Tapi pip install plaidml atau pip install plaidml==0.1.0rc3
kembali

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

@hy9be Saya pikir akan lebih tepat untuk membuat masalah di repositori plaidml daripada di sini, karena masalah ini tentang mendukung OpenCL di tensorflow. Selain itu, dengan melihat petunjuk penginstalan di sana, perintah instal pip Anda mungkin salah.

Terima kasih @andrerichards atas perhatian dan pidato sesi Anda.

Tetapi untuk saat ini bagi saya (mahasiswa pascasarjana), untuk membangun aplikasi menggunakan Tensorflow di perangkat Android dan ingin GPU (Mali-T720) diaktifkan, apa yang diperlukan untuk mendapatkan driver Mali dengan dukungan SPIP-V dan runtime ComputeCpp untuk Android dengan Arm CPU dukungan dan dukungan SPIR-V.

Karena saya telah mengunduh ComputeCpp(Ubuntu16.04 x64 dengan bin/doc/include/lib/) di beranda CodePlay, kemarin saya menjalankan:
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
kesalahan mengatakan libComputeCpp.so incompatible , jadi saya menganggap mungkin saya memerlukan ComputeCpp untuk Android dengan dukungan Arm CPU dan dukungan SPIR-V, tetapi saya tidak dapat menemukan kode sumber apa pun untuk membangun Android ComputeCpp, hanya ada sampel di github.

Dan Anda mengatakan ComputeCpp untuk Android sekarang tidak tersedia, jadi apakah ada rencana untuk mendukung perangkat Android atau bagaimana saya bisa mendapatkannya jika didukung.

Untuk pengguna AMD gpu dan linux, AMD baru-baru ini merilis port HIP dari tensorflow di sini . Anda mungkin tertarik.

Saya belum mengujinya.

Saya bisa mengujinya - tetap disini. Sepertinya itu gagal CI sekalipun.

Memang itu gagal. Masih dalam tahap awal, kurasa.

Saya mengujinya, mendapatkan segfault dalam contoh MNIST segera.
Tidak tahu apa yang saya lakukan salah di sini.

$ 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 - pastikan Anda telah menginstal rocm 1.6.4 base.

@bensander Terima kasih, saya akan meningkatkan.

@bensander Ada lagi yang saya butuhkan dari tumpukan AMD? Yang saya miliki sekarang adalah perpustakaan opencl milik AMD yang menggunakan driver "amdgpu" open source.

@masahi - jika Anda menginstal rocm dan rocm-libs (yaitu "apt-get install rocm rocm-libs") itu semua yang Anda butuhkan. rocm_docs di repot memiliki instruksi lengkap termasuk hasil yang diharapkan.

@bensander bagaimana saya tahu jika saya menjalankan rocm 1.6.4 dengan benar (dan bukan 1.6.3)?

@masahi hanya menebak: Anda harus mengajukan pertanyaan di tempat yang lebih terkait untuk masalah Anda, seperti proyek AMD atau RoCM daripada di sini...

@keryell benar, saya keluar dari topik. Saya berhenti di sini.
Bagaimanapun, saya tidak bisa membuat hiptensorflow bekerja di sistem saya. Saya akan mencoba nanti dengan instalasi Ubuntu yang bersih.

@masahi - buka saja masalah di sana dan kami akan menyiapkan Anda.

Hai, Saya hanya ingin menyebutkan bahwa saya dapat membuat hiptensorflow berfungsi, terima kasih kepada @bensander dan orang lain di AMD. Saya dapat menjalankan semua contoh di panduan memulai cepat mereka.

Terima kasih

Bagi yang ingin mencoba TensorFlow pada hardware AMD menggunakan ROCm, saya menulis blog yang menjelaskan cara menjalankan notebook Fast.ai menggunakan AMD Fury Nano.
http://briansp2020.github.io/2017/11/05/fast_ai_ROCm/

👍 tidak sabar untuk ini!

ROCm 1.7 sedang dalam proses, dengan dukungan Tensorflow yang tepat!

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

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

Ini bekerja sangat baik untuk saya. Pengaturan perangkat keras saya:
GPU: AMD Radeon RX 480
CPU: Intel Xeon 2603 v3
MB: supermikro x10srl-f

Kuncinya adalah motherboard dan CPU harus mendukung PCIe v3

Performanya mirip dengan Nvidia 980Ti

Saya bahkan tidak bisa mendapatkan driver AMD yang "didukung" untuk bekerja pada instalasi Ubuntu 16.04 LTS saya yang "didukung". Keusangan yang direncanakan?

znmeb, apa GPU AMD Anda? Jika Anda memiliki GPU ganda, nonaktifkan yang tidak didukung dari BIOS.

Tidak dapat membaca seluruh utas... apa status tensorflow saat ini pada OpenCL di MacOS (sierra +)? Secara khusus, saya memiliki GPU Intell Iris dan berharap jika saya dapat membangun dari sumber dukungan Tf+Open CL untuk itu.
Juga, tf corrainder tampaknya berjalan dengan baik, pada versi 1.2.

@varun19299 FWIW ada Intel SDK untuk OpenCL - Saya memilikinya di laptop Sandy Bridge kuno saya, tetapi saya yakin itu akan berfungsi di mesin Anda. https://software.intel.com/en-us/intel-opencl

Apakah ini saat ini dalam keadaan dapat digunakan pada sistem linux non-ubuntu? Halaman peta jalan hanya tertaut di sini.

@pfc Apakah yang saat ini dapat digunakan di Linux non-Ubuntu? TensorFlow menggunakan OpenCL secara umum? Atau TensorFlow menggunakan OpenCL pada GPU AMD? Saya akan menganggap yang terakhir, karena itu satu-satunya alasan Anda ingin menjalankan TensorFlow menggunakan OpenCL. Untuk GPU NVidia Anda akan menggunakan driver/library NVidia dan hanya untuk CPU tidak ada keuntungan dari OpenCL.

Saya memiliki ini bekerja beberapa minggu yang lalu di Arch Linux, menggunakan perpustakaan ComputeCpp SYCL berpemilik dan GPU AMD "Bonaire" (Arsitektur Kepulauan Laut). Ada rilis ComputeCpp baru yang perlu saya uji tetapi saya kira itu akan berhasil.

Ternyata perpustakaan berpemilik AMDGPU Pro yang Anda butuhkan untuk membuat ini berfungsi tidak berjalan di Ubuntu 16.04.3. Pembaruan dari 16.04.2 membawa kernel Linux dan X Server yang lebih baru, dan AMD belum mengirimkan sesuatu yang berfungsi di dalamnya. Lihat http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-Compatibility-Advisory-with-Ubuntu-16.04.2-and-16.04.3.aspx untuk detailnya. Saya tidak dapat membuat AMD OpenCL berfungsi di Ubuntu.

Ada TensorFlow versi AMD eksperimental yang menggunakan kompiler untuk menerjemahkan kode CUDA ke kode OpenCL, tetapi saya juga belum mengujinya. Dengan tidak adanya driver yang didukung, tidak ada gunanya.

https://github.com/ROCmSoftwarePlatform/hiptensorflow/tree/hip/rocm_docs adalah cara yang didukung secara resmi untuk menjalankan aliran tensor pada perangkat keras AMD.

@bensander Apakah runtime ROCm berfungsi di Ubuntu 16.04.3? Saya belum bisa membuatnya bekerja.

PS: Apakah Anda memiliki wawasan jika / kapan pengaturan AMDGPU-Pro akan berfungsi di Ubuntu 16.04.3? Saya membutuhkan itu untuk proyek lain.

Hmm, saya tidak (dan tidak akan) menikmati Ubuntu di mana pun tetapi saya memiliki CentOS 7 w/ repo dan GTX1080TI di dalamnya, menjalankan kernel 4.14.x dan driver beta Nvidia terbaru, jadi saya dapat membantu mengujinya di sana di beberapa titik hari ini jika itu membantu?

--
Sam McLeod

Pada 7 Des 2017, pukul 07:28, M. Edward (Ed) Borasky [email protected] menulis:

@bensander Apakah runtime ROCm berfungsi di Ubuntu 16.04.3? Saya belum bisa membuatnya bekerja.


Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@sammcj Mengapa Anda menjalankan GPU NVidia dengan OpenCL ketika ada perpustakaan CUDA yang sangat bagus untuk itu?

Hanya untuk membantu mengujinya untuk Anda!

Jangan khawatir jika Anda tidak memerlukan pengujian tangan, hanya berpikir saya akan menawarkan. Saya bahkan belum mencoba mesin itu dengan cuda TBH, saya hanya mencobanya di MacOS di mana saya tidak dapat menggunakan OpenCL melalui Docker saat ini.

--
Sam McLeod

Pada 7 Des 2017, pukul 08:16, M. Edward (Ed) Borasky [email protected] menulis:

@sammcj Mengapa Anda menjalankan GPU NVidia dengan OpenCL ketika ada perpustakaan CUDA yang sangat bagus untuk itu?


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@znmeb Saya akan mencoba ComputeCpp SYCL namun mereka hanya menyediakan penginstal ubuntu (saya juga menggunakan arch) dan skrip instal aur rusak. Senang mendengarnya bisa berhasil. Jika saya cukup putus asa, saya dapat mencobanya.
@bensander Itu terlihat seperti apa yang saya perlukan untuk mendapatkan dukungan ADM namun saya khawatir dengan fakta bahwa kode ini belum di-porting kembali ke TF dan kodenya terakhir diperbarui lebih dari 2 bulan yang lalu mengingat bahwa kode saya menargetkan TF 1.4. 0
Sepertinya saat ini tensorflow pada dasarnya mengikat Anda ke Nvidia, setidaknya bagi kami programmer "fana". Kurangnya dokumentasi/peta jalan yang diperbarui tidak membantu. Saya tidak keberatan membantu dengan cara apa pun yang saya bisa, namun sejauh ini saya kurang berhasil membuat semuanya berjalan baik.

@pfc Saya membuat SYCL ComputeCpp bekerja di Arch - ada tarball biner di situs web mereka ketika saya melakukannya.

Dalam berita ini tentang rilis SYCL 1.2.1
https://www.roboticstomorrow.com/news/2017/12/06/the-khronos-group-releases-finalized-sycl-121-/11107/
ia mengatakan :
_Spesifikasi baru ini menggabungkan pengalaman signifikan yang diperoleh dari tiga implementasi terpisah dan umpan balik dari pengembang kerangka kerja pembelajaran mesin seperti TensorFlow, yang sekarang mendukung SYCL bersama back-end akselerator CUDA asli._

Apakah itu berarti sekarang mungkin untuk "dengan mudah" menjalankan TensorFlow pada GPU AMD yang mendukung OpenCL 1.2 di mana SYCL dibangun?

"Mudah" dalam arti bahwa beberapa perangkat lunak / driver / perpustakaan tingkat rendah untuk perangkat keras AMD adalah tempat sebagian besar barang rusak, bukan di perangkat keras atau TensorFlow atau standar OpenCL atau SYCL. ;-) Jika Anda memiliki driver GPU AMD yang berfungsi dan pustaka OpenCL yang berfungsi, Anda memiliki TensorFlow di GPU AMD.

Pengaturan kerja saya untuk AMD Bonaire (arsitektur Kepulauan Laut):

Arch Linux dengan modul kernel amdgpu dimuat dan modul kernel radeon masuk daftar hitam
Paket Arch User Repository opencl-amd
Pustaka ComputeCpp
TensorFlow dibuat dari sumber di workstation saya menggunakan garpu @lukeiwanski :

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

Saya sedikit terkejut dengan apa yang Anda katakan " Jika Anda memiliki driver GPU AMD yang berfungsi dan pustaka OpenCL yang berfungsi, Anda memiliki TensorFlow di GPU AMD". Saya telah memahami bahwa versi "Resmi" TensorFlow tidak berjalan di OpenCL (khusus CUDA). Sepertinya aku bingung.
Saya cukup senang menemukan proyek PlaidML yang setidaknya memungkinkan beberapa kode Keras berjalan di iMac saya dengan AMD Redeon HD 6970. (https://groups.google.com/forum/#!topic/plaidml-dev/ksFMgxjgKrM ) AFAIK Anda juga telah mencoba Kerangka itu.
Saya akan mencoba menjalankan TensorFlow di Ubuntu VirtualBox jika Tensorflow sudah berjalan (khusus CPU).

@PALYGAP Saya tidak berpikir VirtualBox mengekspor OpenCL dari host Mac ke tamu Linux, dan Ubuntu 16.04.3 tidak berfungsi sekarang. Saya tidak punya Mac jadi saya tidak punya cara untuk menguji sesuatu.

Apakah ada yang berhasil mencoba bekerja TensorFlow di AMD melalui OpenCL dan berhasil?.

@mohnkhan Saya memiliki garpu @lukeiwanski berfungsi (Linux Arch) - lihat https://github.com/tensorflow/tensorflow/issues/22#issuecomment-349877056 . Saya menunggu beberapa pekerjaan AMDGPU-Pro lagi sebelum saya menerbitkan posting blog - lihat https://github.com/corngood/archlinux-amdgpu/pull/54 .

@znmeb Terima kasih atas masukannya

@mohnkhan BTW, AMD sedang membangun jalur alternatif yang sepenuhnya open source - menerjemahkan kode CUDA ke kode OpenCL dengan toolchain compiler. Saya tidak yakin apa statusnya untuk kartu lama seperti milik saya.

Jika Anda akan menulis artikel, saya rasa tidak ada salahnya untuk menjelaskan juga (butuh 3 jam untuk mendapatkan gambaran keseluruhan):

  • TF sebenarnya memiliki backend SYCL 1.2. Tidak *aktual* opencl.
  • pada gilirannya, Anda memiliki dua implementasi standar (trisycl terlihat keren, tetapi atmnya terbatas )
  • Pada akhirnya, ComputeCpp 'mengaitkan' SPIR /SPIR-V (selain PTX, tapi ini benar-benar cerita lain )

Dan inilah yang pada akhirnya membawa Anda langsung ke OpenCL 1.2 yang Anda dambakan (w/ cl_khr_spir ext)

HIP sebagai gantinya adalah backend lain, duduk berlawanan dengan SYCL, dan hanya menargetkan dan secara eksklusif ROCm (atau yah, lol, bahkan pada gilirannya cuda jika Anda memiliki nvidia gpu.. tapi ini lagi-lagi cerita lain)

AMD sedang membangun jalur alternatif yang sepenuhnya open source - menerjemahkan kode CUDA ke kode OpenCL dengan toolchain compiler.

Tidak. Anda berbicara tentang HIP, dan.. itu sebenarnya, apa yang akhirnya Anda ubah menjadi . Yang bukan OpenCL.
HIP kemudian berjalan di ROCm seperti yang saya katakan...
ROCm yang juga menjalankan OpenCL untuk Anda (pada kartu yang didukung ), tapi tolong saya menekankan semua orang untuk memperhatikan bagaimana hubungan hanya diteruskan dari ROCm, tidak pernah "intra-sub-lapisan"

Apa yang mungkin Anda pikirkan adalah ketumbar .

Saya tidak yakin apa statusnya untuk kartu lama seperti milik saya.

Diringkas di sini : driver AMDGPU-PRO yang lengkap, driver amdgpu-pro-opencl-only seperti yang Anda lakukan sekarang ... Atau terus menunggu hingga akhir dekade sampai seseorang akhirnya membuat semanggi dapat digunakan.

Juga, fglrx... Tapi jika itu sulit untuk direkomendasikan untuk kartu pra-gcn, kurasa lebih baik untuk menutupinya.

@mirh

  1. Saya tidak peduli dengan kartu pra-GCN. Milik saya adalah Kepulauan Laut dan saya tidak berencana membeli yang lebih tua. Kemudian lagi, saya juga tidak berencana untuk membeli GPU AMD lainnya. ;-)
  2. Saya tidak tahu apakah ROCm akan berjalan di workstation saya - tidak ada penguji perangkat keras sumber terbuka yang dapat memberi saya jawaban ya atau tidak. Saya telah membuka masalah untuk itu dan tidak menerima tanggapan.
  3. SPIR-V adalah target kompiler - saya melihatnya dan mengangkat tangan, tidak memiliki anggaran untuk menyewa penulis kompiler.

Sehingga meninggalkan SYCL ... atau mengangkat kedua tangan saya yang lain dan melakukan segalanya dengan Keras, yang memiliki TensorFlow, Theano (yang semakin beku), CNTK atau PlaidML ujung belakang. Dari sudut pandang ekonomi rekayasa murni, Keras / PlaidML adalah pemenang besar asalkan saya mendapatkan TensorBoard entah bagaimana.

@mirh terima kasih atas ringkasan yang bagus dengan semua tautan. Saya pikir Anda belum menyia-nyiakan 3 jam Anda ... :-)

Saya tidak tahu apakah ROCm akan berjalan di workstation saya - tidak ada penguji perangkat keras sumber terbuka yang dapat memberi saya jawaban ya atau tidak. Saya telah membuka masalah untuk itu dan tidak menerima tanggapan.

Seperti yang saya katakan beberapa kali , tidak, itu tidak akan berhasil.
Pra GCN 3rd gen GPU hanya kekurangan perangkat keras untuk ROCm baik untuk melakukan atau bahkan bekerja sama sekali.

SPIR(-V) .. Saya tidak yakin apa yang Anda bicarakan. Bukan tugasmu untuk peduli tentang itu. Computecpp membuatnya dari SYCL "perintah", dan kemudian itu semua (opencl) bisnis driver.

Anda memiliki apa yang saya sebut sementara hanya amdgpu-pro-opencl-only, dan saya tidak yakin apa masalahnya.
EDIT: akan juga keren untuk memiliki semacam ETA agar kode Luke mendarat

@znmeb dan semuanya

Saya memiliki (L) Ubuntu 17.10 termasuk. kernel 4.14.x dan bagian perpustakaan OpenCL dari driver AMDGPU Pro 17.40 berjalan dan dapat menjalankan aplikasi OpenCL seperti clinfo atau Boinc (misalnya Engima @Home , Milkyway@Home) tanpa masalah pada APU AMD A12-9800E saya.

Saya juga dapat berhasil mengkompilasi dan menggunakan versi CPU tensorflow (saat ini versi 1.4.1). Tetapi saya gagal mengkompilasi tensorflow versi OpenCL. Saya menggunakan computecpp 0.5 (yang saat ini dapat saya unduh tanpa perlu mendaftar) bersama dengan vanilla tensorflow 1.4.1 dan dengan cabang "dev/amd_gpu" dari garpu @lukeiwanski .

Jadi bisakah seseorang yang berhasil mengkompilasi versi OpenCL dari tensorflow memberikan beberapa informasi versi perpustakaan computecpp yang mana dan cabang git tensorflow mana yang dia gunakan?

Terima kasih

@AlphasCodes Saya tidak menjalankan apa pun di Ubuntu - semua pekerjaan saya ada di Arch. Saya memiliki mesin yang di-boot ganda dengan Ubuntu 16.04.3 tetapi perpustakaan milik AMD belum berfungsi di sana. Sejauh yang saya tahu mereka tidak didukung pada 17.10, tetapi jika Anda memiliki bagian OpenCL yang berfungsi pada 17.10, saya mungkin menambahkan boot ketiga - Saya memiliki banyak ruang disk. ;-)

Apa jenis kesalahan yang Anda dapatkan? Jika itu adalah kesalahan pembuatan, Anda mungkin memiliki ketidakcocokan Bazel. Bazel terus bergerak maju seperti TensorFlow dan terkadang yang satu lebih unggul dari yang lain.

Apa maksudmu, "tidak didukung"?

ini .
Adapun ubuntu, hanya 16.04.3 yang dikatakan didukung (setidaknya secara resmi, mengingat bahkan arch dapat membuatnya berfungsi setelah beberapa skrip ajaib)
EDIT: Driver AMDGPU-PRO 'lengkap' membutuhkan kernel 4.9, itu kemungkinan masalahnya

Jika ada yang peduli, port AMDGPU-Pro Driver 17.40 ke Arch sedang berlangsung dan sangat aktif di GitHub di https://github.com/corngood/archlinux-amdgpu/pull/54 ,

Kami benar-benar harus menutup masalah ini, karena, seperti yang ditunjukkan @mirh , TensorFlow menggunakan SYCL, bukan OpenCL. Mungkin kita harus membuka yang lain, "TensorFlow pada kartu AMD"??

Tidak, itu benar-benar sah.
Anda ingin tensorflow berjalan pada akhirnya di perangkat opencl, itulah tujuannya. Sah dan berakhir.
Mengatakan itu benar-benar menggunakan SYCL hanyalah nitpick teknis yang saya buat, karena semua akronim dari teknologi acak ajaib ini membuat saya marah.
EDIT: Saya juga ingin mengucapkan terima kasih kepada semua orang codeplay untuk pekerjaan mereka yang mengerikan

Jika Anda menginginkan sesuatu yang dibuat khusus untuk amd, saya sarankan untuk memeriksa hiptensorflow mereka. ROCm saja. Dan tolong, mari kita tinggalkan argumen ini.

OK saya tidak tahu apakah saya punya cukup waktu untuk melakukan build lagi dan memberikan kesalahan kompilasi hingga akhir pekan. Tetapi saya menambahkan dokumentasi saya yang ada ke repo github baru saya.

Lihat https://github.com/AlphasCodes/DeepLearning untuk detailnya (pengaturan perangkat keras/perangkat lunak saya + pengaturan AMD OpenCL + pengaturan Tensorflow).

@mirh untuk mengklarifikasi "akronim dari teknologi acak ajaib [...] membuat [Anda] gila":

Di ranah Grup Khronos, OpenCL adalah API sumber non-tunggal tingkat rendah dan SYCL adalah bahasa tertanam khusus domain C++ sumber tunggal (DSeL) sumber tunggal tingkat tinggi. SYCL diharapkan dibangun di atas OpenCL, jadi dengan transitivitas ketika Anda menggunakan SYCL, Anda sering menggunakan OpenCL.

Karena TensorFlow menggunakan Eigen yang menggunakan pendekatan C++ sumber tunggal dengan CUDA sumber tunggal , ketika kemudian di-porting ke OpenCL, SYCL dipilih karena merupakan cara standar Grup Khronos untuk memiliki C++ sumber tunggal .

Tetapi jika Anda berpikir tentang CUDA, itu bahkan lebih halus.

Hampir semua orang menggunakan CUDA versi sumber tunggal tingkat tinggi yang sebenarnya bernama "CUDA Runtime API". Ini entah bagaimana mirip dengan SYCL.
Tetapi sebenarnya ada versi CUDA non-sumber tunggal tingkat rendah yang kurang dikenal yang disebut "CUDA Driver API", mirip dengan OpenCL, dan digunakan misalnya oleh implementasi "CUDA Runtime API" itu sendiri.

Karena ini semacam FAQ, saya mengklarifikasi sedikit https://en.wikipedia.org/wiki/SYCL dan https://en.wikipedia.org/wiki/CUDA

ComputeCpp yang merupakan implementasi SYCL yang Anda gunakan dengan TensorFlow belum mendukung Ubuntu 17.10. Anda harus tetap menggunakan Ubuntu 16.04 yang merupakan LTS saat ini. Petunjuk dan prasyarat ada di sini https://developer.codeplay.com/computecppce/latest/getting-started-with-tensflow

Selain itu, dukungan OpenCL untuk TensorFlow tidak berarti hanya dukungan perangkat AMD. Integrasi SYCL juga memungkinkan perangkat OpenCL lainnya. Sebagai bagian dari pekerjaan yang kami lakukan dengan TensorFlow, dukungan untuk ARM dan GPU Intel akan tersedia saat driver terbaru dari perusahaan ini tersedia. Kami juga bekerja untuk mengaktifkan dukungan untuk prosesor akselerator Renesas juga untuk platform R-Car.

@rodburns Terima kasih! Saya memiliki ini bekerja di Arch Linux (4.14.4 kernel) dengan perpustakaan opencl-amd dari Arch User Repository. Kartunya adalah Bonaire (GCN 2.0). Saya akan menjalankan tes pada halaman itu untuk memverifikasi bahwa itu melakukan apa yang seharusnya.

GCN 2nd gen (alias 1.1) jika ada, 2.0 tidak ada.
(harus membungkuk untuk menjadi sangat bertele-tele)

KESUKSESAN!

Cabang "dev/amd_gpu" terbaru melakukan di garpu @lukeiwanski memperbaiki masalah kompilasi OpenCL Tensorflow saya. Saya berasumsi itu adalah komitmen terkait SysCL 1.2.1.

Saya berhasil mengkompilasi versi Tensorflow OpenCL dan dapat menggunakannya. Lihat dokumen Pengaturan Tensorflow saya untuk detailnya.

Saya juga menambahkan halaman tolok ukur di mana Anda dapat menemukan beberapa tolok ukur pengaturan saya di bawah pengaturan Tensorflow yang berbeda (tidak dioptimalkan CPU, dioptimalkan CPU, OpenCL) di masa mendatang.

Driver AMDGPU Pro versi 17.50 juga berfungsi untuk saya. Saya memperbarui dokumen AMD OpenCL Setup terkait.

Terima kasih kepada semua kontributor.

Saya melakukan beberapa benchmark dan tampaknya iGPU lebih lambat dari 4 thread CPU yang tersedia kecuali benchmark matmul_bench.py .

Inisialisasi proses OpenCL Tensorflow juga jauh lebih lambat daripada proses OpenCL Tensorflow khusus CPU. Sesuatu seperti 5 detik untuk CPU vs 1-2 menit untuk OpenCL.

Adakah yang bisa mengkonfirmasi hasil seperti itu?

OK saya melakukan beberapa pemecahan masalah lagi.

  • saya menggunakan contoh Tensorflow MNIST, lihat dokumen Validasi Tensorflow Setup
  • saya menggunakan "Sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info" untuk memeriksa/menonton jam/muat iGPU dan "top" untuk memeriksa beban CPU
  • fase inisialisasi hingga Langkah 0 memakan waktu sekitar 6 menit, beban iGPU sekitar 0%, jam iGPU pada 300 MHz (jam minimal yang tersedia) dan penggunaan CPU proses python sekitar 200% (= 2 utas)
  • dimulai dengan Langkah 0 beban iGPU sekitar 90%, jam iGPU selalu beralih dari 654 MHz - 720 MHz - 800 MHz - 900 MHz (jam maksimum yang tersedia) dan kembali, penggunaan CPU proses python sekitar 100% (= 1 CPU benang)

Saya masih mencoba untuk mengkompilasi sesuatu di Arch.

Yang saya pakai kemarin .
Setelah 14 jam (ya, kentang saya sangat lambat) saya mendapatkan biner ini , jika Anda ingin mencoba.

Saya telah mencoba mencari tahu apa yang terjadi tetapi sayangnya saya tidak bisa. Saya akan menghargai jika seseorang yang mengetahui tentang hal berikut dapat membantu saya mempercepat!

Sebagian besar diskusi di atas berkaitan dengan menjalankan Tensorflow dengan akselerasi OpenCL pada chip AMD. Apakah saya benar mengatakan ini? Jika saya ingin mendapatkan tensorflow yang dipercepat GPU menggunakan kartu grafis terintegrasi saya (intel HD 5000) yang mendukung opencl, apa pendekatan saya?

Terima kasih sebelumnya!

@znmeb Hai Ed, terima kasih telah membalas. Saya telah mengunduh dan menjalankan OpenCL di sistem saya. Tetapi pertanyaan saya adalah - bagaimana saya bisa mengkompilasi tensorflow untuk benar-benar menggunakan perpustakaan OpenCL?

@AlphaCodes Terima kasih telah mempublikasikan hasil Anda. Berkenaan dengan waktu inisialisasi, cara kerja OpenCL adalah kode dikompilasi sebelum dieksekusi, jadi waktu startup adalah proses kompilasi.

@brainwave Untuk perangkat Intel, ada utas dengan @mirh di sini yang menjelaskan cara menghapus batasan seputar perangkat yang sedang berjalan. Kami telah melihat masalah dengan driver Intel, itulah sebabnya jenis perangkat ini dibatasi, tetapi kami berharap driver yang diperbarui akan segera tersedia untuk perangkat Intel yang meningkatkan dukungan. Sementara itu, Anda dapat mengkompilasi ulang TensorFlow dengan perubahan untuk menguji perangkat keras Intel Anda sendiri. Kami sedang mencari cara untuk menghapus batasan perangkat di basis kode.

@AlphasCodes Guys, saya minta maaf untuk pertanyaan yang mungkin naif tetapi mengapa ini hanya membangun AMD GPU? Bukankah OpenCL seharusnya standar? Apakah saya memahaminya dengan benar bahwa itu tidak akan berfungsi pada Intel Carbon X1 saya dengan driver OpenCL 2.0 yang diinstal?

Jika Anda membaca masalah yang ditautkan dua kali, Anda akan melihat bahwa tidak ada apa-apa tentang amd gpu.
Intel saat ini dikecualikan, tetapi tidak ada hubungannya dengan keinginan untuk memaksa pengguna, dan ada solusi sementara - diskusikan di sana jika memang ada.

Ketika saya menggunakan cabang amd_gpu dengan notebook jupyter, sepertinya ada sisa utas. python masih menggunakan 100% dari satu cpu, bahkan setelah komputasi selesai. Restart kernel menyelesaikan utas yang tersesat. Apakah ada orang lain yang mengalami ini?

@brainwave @unoexperto
Maaf saya tidak dapat membantu dengan Intel OpenCL karena saya hanya memiliki perangkat keras AMD OpenCL.

@desperadoduck
Saya belum menggunakan jupyter. Saya menggunakan shell bash biasa dan lingkungan Python 3 virtual ( lihat pengaturan Python 3 + Tensorflow saya ). Tetapi saya tidak dapat mereproduksi masalah ini. Tidak ada penggunaan CPU oleh proses python setelah komputasi selesai.

@rodburns
Terima kasih untuk informasinya. Apakah mungkin untuk mempercepat waktu kompilasi awal? misalnya menggunakan semua utas CPU yang tersedia, bukan hanya 50%.

@brainwave @rodburns
Untuk Intel GPU (Gen9) di Linux, kami telah melihat kinerja DNN yang jauh lebih baik dengan implementasi Beignet open source Intel vs yang closed source saat melakukan benchmark dengan common vision nets di PlaidML. Beignet juga lebih mudah dipasang yang bagus.

Apakah ini mendukung intel graphics hd615 (cpu gen ke-7) di ubuntu17.10?

Dirver opencl SRB5.0 untuk linux64 berjalan dengan baik di ubuntu17.10.

Dan itu sudah lama tidak diperbarui:
https://bitbucket.org/mehdi_goli/opencl/branch/IntelGPU

Demi tuhan, tidak bisakah kamu membaca 2 (dua!) posting di atas saja?
Diskusikan kurangnya dukungan intel gpu (atau amd cpu) di sini https://github.com/codeplaysoftware/computecpp-sdk/issues/78

@znmeb itu adalah tujuan untuk memanfaatkan sepenuhnya berbagai sumber daya komputasi (misalnya cpu,gpu,DSP, coprocessor lainnya).
Sebenarnya, itu tergantung pada dukungan vendor perangkat keras: dirver dan OS.
Seperti yang saya tahu, Anda mungkin tidak dapat mengaktifkan intel GPU dan nvida GPU untuk video secara bersamaan, karena keterbatasan dari driver vedio. (Anda mungkin dapat beralih di antara mereka).
Namun, opencl dapat menggunakannya secara bersamaan. Mereka berdua adalah "perangkat" di dalamnya.

@choongng Itu menarik untuk diketahui, kami melakukan beberapa pekerjaan untuk membantu mengaktifkan Beignet tetapi aktivitas pada proyek ini tampaknya agak sepi.

@znmeb Ya GPU apa pun mungkin tidak akan berkinerja lebih baik pada masalah kecil, senang Anda membuat beberapa kemajuan!

@unoexperto ComputeCpp dengan TensorFlow dapat digunakan oleh perangkat keras apa pun yang mendukung instruksi perantara SPIR OpenCL yang mencakup GPU Intel namun seperti di utas di sini , kami sengaja mencegahnya berjalan karena kami tidak berpikir driver saat ini berfungsi saat ini . Anda dapat menghapus batasan itu karena sepertinya beberapa pengguna telah membuatnya bekerja dengan driver Intel yang berbeda. Kami juga bekerja untuk mengaktifkan ini untuk prosesor ARM dan Renesas yang memiliki driver OpenCL.

@sxpc722 Itu seharusnya berhasil. Omong-omong, mesin barunya adalah Windows 10 dan saya tidak berencana untuk melakukan dual-boot dengan Linux sampai saya benar-benar harus melakukannya! Saya muak mengejar bug driver dan perpustakaan untuk vendor (melihat Anda, AMD). Bahkan, saya dapat menempatkan partisi Windows di workstation saya untuk alasan AMD yang sama. ;-)

Sudah 14 hari tanpa aktivitas dan masalah ini memiliki penerima tugas. Harap perbarui label dan/atau status yang sesuai.

Performa Tensorflow AMD OpenCL sangat lambat menurut pengujian saya. Jadi saya melakukan beberapa tes dasar dengan kerangka kerja Deep Learning lainnya. Anda akan menemukan pengaturan dan tolok ukur saya di halaman GitHub saya di sini .

Singkat cerita. Kerangka kerja Deep Learning lainnya sekitar 10 kali lebih cepat dari Tensorflow AMD OpenCL saat ini.

@AlphasCodes @znmeb Saya tahu tim TF lebih suka menyimpan utas TF saja, kami senang menjadi tuan rumah percakapan khusus PlaidML di proyek PlaidML. Meskipun demikian, kami berharap pada akhirnya dapat mendukung TensorFlow sendiri serta platform non-OpenCL (misalnya Apple's Metal for iOS yang saat ini ada dalam bentuk prototipe).

https://github.com/plaidml/plaidml

@choongng Terima kasih atas informasi yang saya edit sesuai pesan saya.

@znmeb AMD A12-9800E iGPU harus GCN v3.

Alasan utama dan satu-satunya bagi saya untuk melakukan benchmark/tes adalah untuk menemukan jawaban atas pertanyaan saya "Tetap dengan AMD atau beralih ke Nvidia untuk petualangan Deep Learning saya".

Dan jawabannya adalah. Saya sangat menyukai pendekatan opensource AMD tetapi saya kemungkinan akan beralih ke Nvidia karena 2 faktor. Pertama, tumpukan perangkat lunak Deep Learning (misalnya Tensorflow) jauh lebih matang untuk Nvidia. Kedua, penawaran kartu grafis untuk kebutuhan saya yang sangat spesifik (harus sesuai dengan Kasus Dan A4 SFX dan harus sangat sangat sunyi / hampir tanpa suara di bawah beban penuh selama berjam-jam) sangat terbatas atau bahkan tidak ada di sisi AMD.

Apakah GPU Intel didukung? Saya pikir Iris Pro saya dapat sedikit mempercepat pelatihan lama.

Diskusikan kurangnya dukungan intel gpu (atau amd cpu) di sini codeplaysoftware/computecpp-sdk#78

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

Hanya mencoba untuk memahami keadaan masalah ini. Apakah saya benar untuk mengatakan bahwa repo ini:

https://github.com/lukeiwanski/tensorflow

...dibuat dengan ComputeCpp, apakah opsi terbaik saat ini untuk membangun Tensorflow dengan dukungan GPU AMD umum? Dan jika demikian, apakah ada bukti benchmark bahwa build ini memberikan percepatan di atas CPU?

Tergantung pada apa yang Anda maksud dengan "dukungan GPU AMD umum". Jika yang Anda maksud adalah dGPU atau APU yang sangat tua, saya tidak tahu. Tetapi jika Anda memiliki yang lebih baru (GCN Generasi ke-2 atau yang lebih baru), hipTensorFlow (v1.0.1) yang berjalan di ROCm bekerja dengan cukup baik.

@briansp2020 Ah ya saya telah melihat pekerjaan AMD di ROCm. Sayangnya mereka hanya mendukung Linux, dan sepertinya dukungan untuk OS lain tidak ada di peta jalan mereka. Saya berharap untuk sesuatu yang mendukung Windows.

@mjmax Apakah ada paket tensorflow akselerasi GPU yang tersedia untuk Windows? Saya pikir, jika Anda ingin deeplearning yang dipercepat GPU, Linux adalah satu-satunya pilihan. Jika TensorFlow di-porting ke OpenCL, apakah itu akan mempermudah porting ke Windows? Saya tidak yakin mengapa TensorFlow tidak tersedia di windows dengan akselerasi GPU ketika CUDA didukung di sana.

Saya kira ini sekarang di luar topik, tetapi jika ada yang tahu tentang TensorFlow dan/atau PyTorch untuk windows yang dipercepat GPU, saya juga ingin mengetahuinya ...

@briansp2020 Sejauh yang saya tahu, Tensorflow sudah mendukung akselerasi GPU Nvidia di Windows.

CL tensofrflow sudah berantakan di linux, jangan berharap apa-apa segera.
Jika Anda ingin mempercepat hal-hal di sana, hanya ada plaidML.
(dan tolong, kita sudah di 500 komentar.. mari kita coba posting hanya jika benar-benar perlu)

@mirh OpenCL Caffe berfungsi di Windows. Tentu bukan TensorFlow dalam hal fitur, tetapi cukup solid untuk Perangkat Lunak yang harus digunakan di mana-mana.

Bagaimana dengan mengganti port openCL dengan port HIP yang didukung oleh AMD?

https://github.com/ROCmSoftwarePlatform/hiptensorflow

Ha ha! @LifeIsStrange Hidup sangat aneh sebenarnya... Apakah Anda bekerja untuk tim pemasaran HiP AMD? :-)
Silakan lihat subjek masalah ini: "Dukungan OpenCL".

Ini berarti tentang standar Khronos https://en.wikipedia.org/wiki/OpenCL (dan standar SYCL lainnya dari kelompok kerja OpenCL Khronos muncul di akhir bagian "Ringkasan").

Tentu saja ada dunia di luar masalah ini, tapi itu... di luar ! :-)

Tolong cobalah untuk tidak meningkatkan entropi alam semesta secara berlebihan dengan memposting beberapa posting acak pada diskusi yang sudah terlalu panjang ini ... :-)
Komentar ini berlaku untuk beberapa poster lain di sini, bukan hanya Anda.
Ini adalah masalah GitHub untuk memecahkan masalah teknis : menjalankan TensorFlow pada perangkat yang mendukung standar OpenCL, bukan halaman FaceBook tentang bagaimana orang menyukai atau tidak menyukai alat A atau B. :-)
Tapi jangan ragu untuk mengirim beberapa git commit terkait dengan masalah ini yang bisa kita lihat...

Ada garpu TensorFlow yang mendukung OpenCL https://github.com/hughperkins/tf-coriander

Dan tentu saja karya @benoitsteiner https://github.com/benoitsteiner/tensorflow-opencl

IMHO, konyol bahwa TF arus utama masih belum menggabungkan pekerjaan mereka.

Apakah fokus di sini untuk menjalankannya sebagai-lomg-seperti-itu-OpenCL, atau membuatnya benar-benar berjalan lebih cepat? Saya lebih suka tidak ada perang suci, tetapi fokus untuk membuatnya berjalan cepat di beberapa GPU. Fokus LifeIsStrange adalah membuatnya bekerja pada GPU AMD dan kemudian HIP masuk akal. Bagi yang lain, fokusnya adalah membuatnya bekerja pada GPU Intel atau Android, dan kemudian OpenCL jauh lebih masuk akal. Bahasa GPU berantakan, jadi harap tetap praktis,

Jika saya membaca beberapa komentar di sini, kinerja adalah masalah dengan port OpenCL. Tapi sayangnya saya tidak bisa melihat banyak benchmark di sekitar. Apakah ada lebih banyak tolok ukur dari yang ini? https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

Seperti yang saya pahami, benchmarking sulit jika Anda membandingkan CUDA dengan OpenCL, karena Anda harus menggunakan perangkat keras yang berbeda. Diduga, nVidia sengaja membuat/membiarkan implementasi OpenCL mereka menjadi agak rusak, sehingga benchmarking pada perangkat keras yang sama akan selalu menghasilkan CUDA yang tampak hebat.

Pada 12 Februari 2018 14:26:11 GMT+00:00, VincentSC [email protected] menulis:

Apakah fokus di sini untuk menjalankannya seperti-lomg-as-it-is-OpenCL, atau
membuatnya benar-benar berjalan lebih cepat? Saya lebih suka tidak ada perang suci, tapi
berfokus untuk membuatnya berjalan cepat di beberapa GPU. LifeIsAneh
fokusnya adalah membuatnya bekerja pada GPU AMD dan kemudian HIP menjadi baik
nalar. Bagi yang lain, fokusnya adalah membuatnya bekerja pada GPU Intel atau
Android, dan kemudian OpenCL lebih masuk akal. Bahasa GPU adalah
berantakan, jadi tolong tetap praktis,

Jika saya membaca beberapa komentar di sini, kinerja adalah masalah dengan
port OpenCL. Tapi sayangnya saya tidak bisa melihat banyak benchmark di sekitar.
Apakah ada lebih banyak tolok ukur dari yang ini?
https://github.com/AlphasCodes/DeepLearning/blob/master/Tensorflow_Benchmarks.md

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/tensorflow/tensorflow/issues/22#issuecomment -364936498

--
Dikirim dari perangkat Android saya dengan K-9 Mail. Mohon maafkan singkatnya saya.

Membandingkan hanya 2 angka bukanlah informasi - siapa yang peduli jika OpenCL pada NVidia berjalan dengan kecepatan setengah jika berjalan pada kecepatan 4x pada GPU lain?

Saya pikir kita membutuhkan tolok ukur ini:

  1. CUDA pada NV GPU (benchmark referensi)
  2. https://github.com/hughperkins/tf-coriander pada AMD, Nvidia dan Intel GPU
  3. https://github.com/benoitsteiner/tensorflow-opencl pada AMD, Nvidia dan Intel GPU
  4. https://github.com/lukeiwanski/tensorflow di AMD, Nvidia dan Intel GPU

Tolok ukur referensi mudah ditemukan. Kami memiliki beberapa GPU kelas atas di sini, jadi hanya perlu tempat untuk memasukkan angka (dengan tautan ke dokumen bangunan).

Dukungan OpenCL Itu harus menjadi kenyataan.

cuda terlalu terbatas, dan nvidia tidak ingin membagikannya.
cuda hanya bekerja untuk Nv GPU.
itu adalah jalan buntu untuk TensorFlow,
jika "TensorFlow" lain keluar tetapi lebih banyak dukungan daripada TensorFlow.
jika TensorFlow masih hanya mendukung cuda di windows.
Anda harus menyadari TensorFlow bukan satu-satunya pilihan.

Mengapa OpenCL lebih baik daripada HIP? Saya pikir OpenCL telah gagal untuk mendapatkan daya tarik dan mendukung OpenCL pada saat ini mungkin kontra produktif dan pinggang sumber daya untuk seluruh komunitas/industri. Saya lebih suka melihat TensorFlow mendukung HIP secara langsung dan membiarkan kompiler/alat/perpustakaan untuk menangani portabilitas.

Bukankah lebih baik perangkat lunak mendukung 1 model bahasa/pemrograman?

Perangkat lunak harus mendukung apa yang harus didukungnya untuk mencakup setiap kasus penggunaan.
HIP adalah semua lonceng dan peluit (setidaknya di atas kertas) jika Anda telah mendukung perangkat keras. Tetapi tidak hanya "kartu amd dan nvidia yang lebih baru" di dunia ini.

Sekarang tolong, demi Tuhan, mengeluh di sini untuk masalah apa pun dengan itu.
Dan di sini untuk semua orang yang tertarik dengan kelanjutan masalah ini.

Saya pikir, SPIR-V akan langsung menggantikan CUDA sebagai alternatif lintas perangkat keras:
http://alphanew.net/index.php?section=alphanew&site=overview&lang=eng&newsID=111

Mengapa Google masih mengandalkan CUDA?

Bisakah ini membantu?

Pembuatan nomor acak 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 (lupa siapa yang menulis ini)

https://Gist.github.com/tugrul512bit/c8170f74846e36e350607664f12c525c

Harap hapus penerima tugas, karena masalah ini mengundang kontribusi eksternal. Jika tidak, hapus label contributions welcome . Terima kasih.

Harap hapus penerima tugas, karena masalah ini mengundang kontribusi eksternal. Jika tidak, hapus label contributions welcome . Terima kasih.

Adalah kepentingan Google untuk mendukung OpenCL,
dengan memiliki perangkat keras tertentu (perusahaan/merek/vendor) sebagai ketergantungan perangkat lunak Anda, Anda memaksakan diri untuk membayar lebih untuk perangkat keras, persaingan pasar menurunkan biaya.
Google selalu tentang perangkat keras komoditas sejak awal yang dan masih penting untuk kesuksesan Google (dominasi pasar), memiliki biaya operasi pusat data yang lebih rendah, memungkinkan penawaran layanan revolusioner yang pada dasarnya gratis seperti Gmail (ruang penyimpanan) dan Google Foto (penyimpanan). spasi dan penandaan otomatis).

@wesamco Tidak, itu belum tentu untuk kepentingan Google. Mereka membuat perangkat keras mereka sendiri - sesuatu yang disebut "TensorBoard", IIRC. Mereka dapat melewati OpenCL dan CUDA / CUDnn dan membuat board menjalankan kode TensorFlow mentah.

kode TensorFlow mentah.

Tidak ada hal seperti itu - ini tidak seperti makanan yang tidak diproses. TPU membutuhkan perpustakaan DNN mereka sendiri yang menangani berbagai jenis panggilan.

Sepertinya sudah waktunya untuk mengompresi diskusi di atas menjadi satu daftar lagi:

  • CodePlay sedang mengerjakan backend SYCL
  • Hugh Perkins sedang mengerjakan tf-coriander
  • AMD sedang mengerjakan backend HIP
  • PlaidML hanya mendukung CPU saat ini.
  • Status dukungan untuk GPU Intel tidak jelas.

Jadi pilih proyek yang Anda suka dan mulailah mendukung mereka. Mungkin masing-masing grup dapat memberikan pembaruan status pada proyek mereka?

Pahami bahwa OpenCL telah diubah dari bahasa lengkap menjadi definisi bahasa/spesifikasi perangkat keras yang direpresentasikan dalam SPIRV (kernel), yang kemudian dapat dijalankan di atas platform seperti driver OpenCL dan kemudian juga pada driver Vulkan (platform). Jadi dengan mendukung SYCL, Anda juga mendukung OpenCL.

Ringkasan sempurna, tetapi plaidml juga berjalan di GPU.
Hanya saja saat ini mereka adalah backend untuk keras, bukan tensorflow. Jadi agak OT di sana.

Halo semua,
@VincentSC terima kasih atas jumlah besar dari berbagai upaya!

Jadi pilih proyek yang Anda suka dan mulailah mendukung mereka. Mungkin masing-masing grup dapat memberikan pembaruan status pada proyek mereka?

Pendekatan SYCL mendukung berbagai platform / perangkat sekarang. Yang bisa saya sebutkan adalah:

  • AMD GPU (FirePro W8100, R9 Nano dan R9 380 Series ) Instruksi tersedia di sini atau di sini
  • Instruksi ARM Mali ( HiKey 960 ) tersedia di sini
  • Intel GPU (seri SkyLake) dengan driver Intel NEO OpenCL

Ketika datang ke AMD, saat ini GPU yang disebutkan di atas menggunakan driver AMDGPU-Pro 17.40-xxx dengan OpenCL lawas yang diaktifkan.
Saya tidak melihat alasan yang jelas mengapa seri lain tidak berfungsi (dengan asumsi bahwa SPIR / SPIR-V didukung)

Platform utama yang kami fokuskan adalah Linux - namun, kami terus berupaya untuk mengaktifkan Windows di masa mendatang. Kami tidak memiliki rencana untuk mendukung OSX dalam waktu dekat. Aku tahu wajah sedih.

Fokus kami adalah meningkatkan kinerja CNN. Performa saat ini tidak dioptimalkan dan tidak jauh dari tempat kami melihatnya berakhir. Meskipun demikian, kami telah mengalahkan kinerja CPU untuk sebagian besar model pada target yang berbeda.

Untuk mempercepat siklus pengembangan dan mengurangi waktu kompilasi keseluruhan TensorFlow (serta meningkatkan portabilitas), kami sedang mengerjakan library Eigen, BLAS, dan DNN.
Pustaka ini bertujuan untuk memecahkan masalah kinerja serta membangun ekosistem pustaka portabel yang dapat dengan mudah diintegrasikan dengan proyek kompleks seperti TensorFlow.

Di bawah ini, lihat grafik kinerja yang dapat kami bagikan saat ini. Mereka diambil dari garpu saya https://github.com/lukeiwanski/tensorflow/tree/dev/amd_gpu di 271093b21cc5ca38e8699e154b5cada96bd7ac0d.
Tolok ukur yang digunakan adalah https://github.com/tensorflow/benchmarks

cpuvssycl
Grafik dinormalisasi ke hasil Intel i7-4790K.

Kami perlahan-lahan meningkatkan perubahan ke Eigen setelah itu terjadi, kami akan mengikuti dengan TensorFlow.

Semoga membantu,
Lukas

Untuk inferensi pembelajaran mendalam pada perangkat seluler dengan dukungan GPU/OpenCL, Anda dapat memeriksa MACE , yang dioptimalkan untuk GPU Adreno, Mali, dan PowerVR. Berikut adalah beberapa hasil benchmark .

@keryell @benoitsteiner , versi tensorflow dan trisycl mana yang diperlukan untuk integrasi. Saya mengalami masalah saat membuat tensorflow (1.9) dengan rilis trisycl terbaru.

Sayangnya TensorFlow terbaru menggunakan fitur yang lebih canggih daripada yang dapat diatasi oleh triSYCL saat ini, jadi Anda harus menggunakan ComputeCpp, saat ini satu-satunya implementasi SYCL yang sepenuhnya sesuai...

Tensorflow didukung oleh Google Brain, dan Google memiliki kemitraan dengan nVidia, saya rasa kami tidak akan mengharapkan Tensorflow untuk mendukung OpenCL
Diperlukan upaya komunitas OpenCL yang besar

Mohon dukungan OpenCL!

OpenCL juga lebih cocok untuk kita.

@Makhaon Saya juga. Saya tidak mampu membeli mesin dengan kartu grafis NVIDIA.

Selain 2 posting di atas, saya ingin menambahkan bahwa sekarang GPU Vega AMD (termasuk yang ada di dalam APU Raven Ridge) dapat melakukan FP16 dua kali lipat FLOPS, jadi jika TF dapat mendukungnya (melalui OpenCL) itu akan sangat membantu orang dengan anggaran kurang. Juga banyak dari orang-orang ini akan menjadi siswa, dan jika kita membuat mereka menggunakan TF sebagai titik awal perjalanan DNN mereka, mereka mungkin akan tetap menggunakan TF di kemudian hari, dan bahkan memberi tahu orang lain tentang TF; ini adalah cara yang bagus untuk membantu mengembangkan proyek ini.

Saya pikir utas ini sebagian besar tidak berarti bagi pengembang (terlalu banyak kebisingan - dan saya akan menambahkan lebih banyak lagi ;-) tapi saya pikir banyak komentar yang hilang intinya:
Jika Anda ingin menjalankan Tensorflow dengan kartu AMD, OpenCL BUKAN yang Anda cari - silakan kunjungi https://github.com/ROCmSoftwarePlatform/ dan instal tumpukan ROCm. Strategi AMD AFAIK saat ini didasarkan pada ROCm alih-alih OpenCL untuk Tensorflow/pytorch .

OpenCL generik terlalu banyak perawatan/tidak memberikan manfaat kinerja yang cukup untuk bermanfaat bagi AMD. Oleh karena itu tiket ini hanya menarik jika Anda menjalankan (misalnya) platform ARM yang hanya menggunakan OpenCL.

(Penafian: hanya orang luar, tidak ada orang dalam yang nyata dalam pengembangan Tensorflow jadi mungkin informasi di atas sepenuhnya salah dan menyesatkan. Jangan ragu untuk memukul saya jika Anda tahu lebih baik.)

Hanya sebuah pemikiran, bagaimana dengan llvm dengan offload GPU baru? Itu akan menempatkan tingkat abstraksi yang hebat antara tensorflow dan kode khusus cuda.

Bagaimana dengan Anda semua yang membaca hanya 10 posting di atas dan memperhatikan bahwa sudah ada garpu oleh lukeiwanski/codeplaysoftware yang dapat Anda coba?
(juga saya angkat topi untuk xiaomi untuk, sekali, menyumbangkan beberapa jenis upaya open source yang serius)

@FelixSchwarz Agar Anda mengetahui bahwa ROCm menggunakan OpenCL, ini adalah driver OpenCL ruang pengguna AMD di Linux (itulah sebabnya mengapa tidak mendukung windows), jadi jika Anda tidak mengetahui cara kerja ekosistem driver AMD di linux, mereka memiliki driver sisi kernel mereka AMDGPU dan AMDKFD (yang sekarang digabungkan menjadi AMDGPU) kemudian ada driver ruang pengguna RadeonSI (untuk OpenGL) RadV/AMDVLK (untuk Vulkan) dan ROCm (untuk OpenCL).

Dilihat dari dinamika bug ini dan fork lainnya, Google tidak tertarik dengan hal ini dan tidak akan pernah mengimplementasikannya di repositori resmi. Saya akan memilih untuk menutup masalah ini (atau menguncinya) sama sekali untuk tidak memberikan harapan palsu untuk semua orang.

Masalahnya harus ada di sini untuk setidaknya menunjukkan di sini semua orang yang mau
mau tidak mau membukanya lagi.

Pada Sabtu, 15 September 2018, 09:45 Anton Kochkov [email protected] menulis:

Dilihat dari dinamika bug ini dan garpu lainnya, Google tidak memiliki nol
tertarik dalam hal ini dan tidak akan pernah menerapkan ini secara resmi
gudang. Saya akan memilih untuk menutup masalah ini (atau menguncinya) sama sekali untuk
tidak memberikan harapan palsu untuk semua orang.


Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/22#issuecomment-421535747 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AB1qNyDrfbiQ4h3kQyqObEfpK3O0FqRGks5ubKIBgaJpZM4Gex3i
.

Ada TensorRT yang mendukung Movidius Pi Hat. Dan Movidius Pi Hat itu adalah "AIY ​​Vision Kit" Google seharga $45. Google menautkan ke Target untuk membelinya.

Ini tidak memiliki hubungan dengan CUDA atau Nvidia? Katanya menggunakan chip Intel. Pada intinya, mungkin chipnya adalah FPGA? Adakah yang tahu lebih banyak tentangnya?

Saya tahu sedikit tentang unit Movidius besar - ini hanya inferensi dan menjalankan model pra-kompilasi TensorFlow atau Caffe. IIRC semuanya dalam mode 16 bit.

Chip Movidius sendiri jauh lebih kuat tetapi Anda harus menjadi mitra yang memenuhi syarat untuk mendapatkan SDK.

Apakah ada pembaruan? Masalah ini sudah lebih dari 3 tahun.

YA HANYA MELIHAT POSTINGAN TERAKHIR.

@filips123 tidak, tidak ada pembaruan dan tidak akan pernah ada di masa mendatang - kemungkinannya lebih rendah daripada invasi alien dan menemukan cara untuk melakukan perjalanan kembali ke masa lalu.

Inisiatif intel PlaidML ini bekerja dengan cukup baik, layak untuk dicoba.
https://github.com/plaidml/plaidml
Ini berjalan di opencl ATAU logam di mac. Ini bekerja dengan GPU AMD Macbook Pro, yang saya cari.
Sementara itu, bisakah kalian membantu memilih dukungan Pytorch di PlaidML? https://github.com/plaidml/plaidml/issues/63

PlaidML tentu saja semuanya bagus dan keren (saya, misalnya, entah bagaimana bisa mendapatkan lebih banyak kinerja pada nvidia gpu di opencl daripada dengan cuda tf itu sendiri)..
Tapi itu backend untuk keras? Sebagai pengganti lengkap untuk tensorflow, yang Anda tahu, ini adalah repo tempat kita membahas ini?
(sejauh yang saya mengerti, versi tf terbaru dapat mengekspor model langsung ke keras? jadi begitulah ..)

Bagaimanapun, untuk keempat kalinya, jika Anda menginginkan solusi terbaru pada opencl dan sesuatu yang masih dikembangkan secara aktif ( dan juga hal dengan peluang aktual untuk digabungkan di sini secara nyata suatu hari nanti), hanya ada tumpukan codeplay.
Lagi:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/AMD_gpu

PlaidML tentu saja semuanya bagus dan keren (saya, misalnya, entah bagaimana bisa mendapatkan lebih banyak kinerja pada nvidia gpu di opencl daripada dengan cuda tf itu sendiri)..
Tapi itu backend untuk keras? Sebagai pengganti lengkap untuk tensorflow, yang Anda tahu, ini adalah repo tempat kita membahas ini?
(sejauh yang saya mengerti, versi tf terbaru dapat mengekspor model langsung ke keras? jadi begitulah ..)

Bagaimanapun, untuk keempat kalinya, jika Anda menginginkan solusi terbaru pada opencl dan sesuatu yang masih dikembangkan secara aktif (_dan juga_ hal dengan peluang aktual untuk digabungkan di sini secara nyata suatu hari), hanya ada tumpukan codeplay.
Lagi:
https://developer.codeplay.com/computecppce/latest/tensorflow-overview
https://github.com/Rbiessy/tensorflow/tree/dev/AMD_gpu

Saya minta maaf, saya tidak menyadari tidak ada dukungan tensorflow. Otak asumsi saya berpikir bahwa dukungan keras gpu == dukungan tensorflow.

plaidML sangat keren. Bekerja pada keras.
Tentu saja saya harus mentransfer beberapa kode tf ke pure keras untuk bekerja di backend plaidML (misalnya tf.image.ssim)
Tetapi hasilnya - kode saya berfungsi pada kartu NVIDIA dan AMD.

Juga plaidML adalah surga bagi para peneliti. Ini secara otomatis menghasilkan gradien untuk fungsi apa pun yang akan Anda tulis pada bahasa "Tile" dan itu akan bekerja pada GPU Anda dengan kecepatan tensorflow 80%.

Jadi saya tidak mengerti mengapa peneliti ML masih menggunakan PyTorch ? Mari tingkatkan ilmu ML dengan plaidML Intel?

@iperov Ingin tahu mengapa praktis tidak ada yang menggunakan PlaidML ?

  1. Ini berjalan sangat lambat pada implementasi OpenCL AMD dibandingkan dengan backend CUDA Tensorflow sehingga setidaknya ada setengah alasan untuk menggunakannya. Performa sangat buruk sehingga menggunakan Tensorflow dengan CPU sangat kompetitif atau bahkan mengalahkan perangkat keras mereka menggunakan PlaidML?

  2. Tidak ada yang tertarik untuk mempertahankan bahasa pemrograman Tile khusus mereka di mana hanya seseorang seperti profesor matematika murni yang akan mengarang sehingga kualitas kode PlaidML menjadi sia-sia dan tidak ada pemrogram serius yang waras yang ingin berurusan dengan kode yang terlalu pintar ...

  3. Ini cukup terkait dengan #2 tetapi sejak Intel membeli Vertex.AI, mereka tidak peduli lagi dengan PlaidML. Solusi Intel untuk pembelajaran mesin yang dipercepat komputasi GPU memperkenalkan kompiler baru khusus untuk pembelajaran mendalam yang sekarang dikenal sebagai nGraph untuk menargetkan Tensorflow, PyTorch, atau kerangka kerja pembelajaran mendalam lainnya sebagai backend untuk mereka. Tidak ada alasan bagi mereka untuk terus mengembangkan PlaidML lagi sebagai perantara mereka ketika mereka memiliki nGraph ...

Orang-orang menggunakan PyTorch untuk alasan lain seperti pemeliharaan atau fitur lain, jadi kesimpulannya PlaidML adalah alat Intel dan mereka mungkin tidak bermaksud memainkannya dalam peran apa pun dari bagian akhir rencana mereka. Backend GPU Intel nGraph saat ini didasarkan pada OpenCL 2.1 di mana hanya Intel yang memiliki implementasi yang sesuai sehingga Intel hanya ada untuk melihat diri mereka sendiri daripada murni untuk perbaikan pembelajaran mesin. Ketika Intel melanjutkan untuk mengembangkan nGraph lebih lanjut, saya tidak dapat melihat mereka terus mendasarkan backend GPU mereka pada OpenCL 2.1 saja karena banyak kerangka kerja pembelajaran mendalam memiliki kernel templat yang tidak kompatibel dengan model pemrograman sumber terpisah OpenCL, Metal atau Vulkan jadi mungkin hanya untuk tujuan eksperimen. Backend GPU akhir Intel mungkin akan didasarkan pada SYCL 2.2 atau sesuatu yang sama sekali berbeda seperti OpenMP dan mungkin mereka bahkan akan membawa solusi khusus vendor ...

Adapun AMD, siapa yang peduli? OpenCL tidak relevan bagi mereka dan mereka akhirnya menunjukkan beberapa hasil dengan pekerjaan mereka di HIP ...

@iperov Ingin tahu mengapa praktis tidak ada yang menggunakan PlaidML ?

  1. Ini berjalan sangat lambat pada implementasi OpenCL AMD dibandingkan dengan backend CUDA Tensorflow sehingga setidaknya ada setengah alasan untuk menggunakannya. Performa sangat buruk sehingga menggunakan Tensorflow dengan CPU sangat kompetitif atau bahkan mengalahkan perangkat keras mereka menggunakan PlaidML?
  2. Tidak ada yang tertarik untuk mempertahankan bahasa pemrograman Tile khusus mereka di mana hanya seseorang seperti profesor matematika murni yang akan mengarang sehingga kualitas kode PlaidML menjadi sia-sia dan tidak ada pemrogram serius yang waras yang ingin berurusan dengan kode yang terlalu pintar ...
  3. Ini cukup terkait dengan #2 tetapi sejak Intel membeli Vertex.AI, mereka tidak peduli lagi dengan PlaidML. Solusi Intel untuk pembelajaran mesin yang dipercepat komputasi GPU memperkenalkan kompiler baru khusus untuk pembelajaran mendalam yang sekarang dikenal sebagai nGraph untuk menargetkan Tensorflow, PyTorch, atau kerangka kerja pembelajaran mendalam lainnya sebagai backend untuk mereka. Tidak ada alasan bagi mereka untuk terus mengembangkan PlaidML lagi sebagai perantara mereka ketika mereka memiliki nGraph ...

Orang-orang menggunakan PyTorch untuk alasan lain seperti pemeliharaan atau fitur lain, jadi kesimpulannya PlaidML adalah alat Intel dan mereka mungkin tidak bermaksud memainkannya dalam peran apa pun dari bagian akhir rencana mereka. Backend GPU Intel nGraph saat ini didasarkan pada OpenCL 2.1 di mana hanya Intel yang memiliki implementasi yang sesuai sehingga Intel hanya ada untuk melihat diri mereka sendiri daripada murni untuk perbaikan pembelajaran mesin. Ketika Intel melanjutkan untuk mengembangkan nGraph lebih lanjut, saya tidak dapat melihat mereka terus mendasarkan backend GPU mereka pada OpenCL 2.1 saja karena banyak kerangka kerja pembelajaran mendalam memiliki kernel templat yang tidak kompatibel dengan model pemrograman sumber terpisah OpenCL, Metal atau Vulkan jadi mungkin hanya untuk tujuan eksperimen. Backend GPU akhir Intel mungkin akan didasarkan pada SYCL 2.2 atau sesuatu yang sama sekali berbeda seperti OpenMP dan mungkin mereka bahkan akan membawa solusi khusus vendor ...

Adapun AMD, siapa yang peduli? OpenCL tidak relevan bagi mereka dan mereka akhirnya menunjukkan beberapa hasil dengan pekerjaan mereka di HIP ...

Bagaimana dengan semua GPU di dalam mesin lengan seperti ponsel dan raspberry pi odroid dan lain-lain?
Mereka tidak mendukung opencl?
Google harus peduli tentang memasukkan tensorflow pada gpu di android.
Perpustakaan terbesar pelatihan jaringan saraf hanya berjalan di Nvidia gpu, itu hanya membuat GPU Nvidia semakin mahal (karena orang dan perusahaan hanya membelinya untuk pelatihan jaringan saraf profesional), maka google akan kehilangan lebih banyak uang dengan cara itu.

@Degerz dari planet mana Anda berasal?
Bagaimana Anda dapat membandingkan tf-CPU dan AMD GPU?
AMD GPU pada plaidML x30 lebih cepat dari tf-CPU

  1. Ini berjalan sangat lambat pada implementasi OpenCL AMD dibandingkan dengan backend CUDA Tensorflow sehingga setidaknya ada setengah alasan untuk menggunakannya

dalam tes deepfakes saya, OpenCL lebih lambat hanya sebesar 20%, tetapi di beberapa jaringan mini, OpenCL 20% LEBIH CEPAT.

Proyek saya DeepFaceLab memiliki banyak pengguna yang telah menunggu dukungan dari AMD. Berapa banyak orang yang senang ketika deepfake akhirnya dapat dilatih pada kartu AMD.
Juga plaidML adalah satu-satunya backend untuk keras yang mendukung AMD/IntelHD di luar kotak.
Jika backend AMD baru untuk keras muncul, tentu saja proyek saya akan beralih ke sana.
PyTorch tidak memiliki masa depan.

Apa yang harus dipertahankan di plaidML ? Operasi dapat dibedakan secara otomatis, tidak ada yang perlu dipertahankan.

Bahasa pemrograman ubin di mana hanya seseorang seperti profesor matematika murni yang akan mengarang

Pembelajaran mesin ditemukan oleh profesor matematika, bukan?

@talregev Bagaimana dengan ARM atau Broadcom? Yang pertama mungkin memiliki implementasi OpenCL di bawah standar dan yang terakhir bahkan tidak secara resmi menyediakan driver OpenCL! Bukan tanggung jawab Google untuk membuat dan memelihara tumpukan komputasi yang kompeten untuk vendor perangkat keras ...

@iperov Anda menyadari bahwa melatih jaring saraf dengan menyematkan lapisan di PlaidML itu menyakitkan, bukan? PlaidML juga memiliki banyak batasan lain seperti tidak terlalu cocok untuk DenseNets atau fakta bahwa grafik komputasinya statis dan apakah PlaidML bekerja dengan baik dengan RNN?

Adapun proyek Anda, jangan khawatir tentang itu. Anda akan beralih ke sesuatu yang lebih baik seperti Tensorflow karena AMD akan segera menawarkan backend GPU asli untuk itu setelah MIOpen di-upstream yang merupakan perpustakaan akselerasi GPU primitif untuk jaringan saraf dalam yang mirip dengan perpustakaan cuDNN pesaing mereka yang keduanya akan meninggalkan PlaidML di debu dalam hal kinerja. Siapa yang peduli dengan Intel iGPU? Jika Intel benar-benar berkomitmen untuk memberikan pembelajaran mendalam kinerja tinggi pada perangkat keras grafis diskrit masa depan mereka, maka mereka akan menawarkan opsi sumber tunggal seperti yang dilakukan oleh yang lain (AMD/HIP dan Nvidia/CUDA) sebelum mereka ...

PyTorch tidak memiliki masa depan.

Banyak iri? PyTorch ~10x lebih populer daripada PlaidML, teknik terbaru dalam DL diimplementasikan dengan mudah di PyTorch, banyak kontributor berbeda dan secara aktif dikembangkan oleh Facebook sementara Intel tidak berkontribusi pada PlaidML selama hampir sebulan ?

Apa yang harus dipertahankan di plaidML ? Operasi dapat dibedakan secara otomatis, tidak ada yang perlu dipertahankan.

Jadi saya mengambil dari Anda bahwa PlaidML seharusnya tidak menerima perbaikan baru atau fitur baru di masa mendatang? Jika Anda tidak melihat nilai dalam meningkatkan kode, maka tidak ada gunanya meyakinkan Anda untuk mengakui kekurangan mencolok PlaidML ...

Pembelajaran mesin ditemukan oleh profesor matematika, bukan?

Tidak berarti kita harus menggunakan bahasa pemrograman apa pun yang mereka buat terutama dalam kasus Tile di mana keanggunan jelas lebih disukai daripada keterbacaan. Tidak heran mengapa begitu banyak kontributor potensial takut untuk berkontribusi ...

Yesus, saya berharap kalian STFU dan kembali bekerja sebagai gantinya. Saya harus berhenti berlangganan tiket karena tidak tertahankan menerima email dengan perang api. Sayang sekali pengelola tidak membisukan utas.

@gunan @caisq @sanjoy Bisakah Anda melakukan sesuatu tentang itu?

Apakah halaman ini membantu?
0 / 5 - 0 peringkat