<div dir="ltr"><br><div class="gmail_extra"><div><div class="gmail_signature">On Thu, Nov 26, 2015 at 8:51 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><span class=""><div><div>On Thu, Nov 26, 2015 at 8:25 PM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br></div></div></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Nov 26, 2015 at 2:07 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div dir="ltr">Hi,
<div><br>
</div>
<div>Besides FPGA folks, what about Apple, embedded and mobile platforms (Qualcomm, ARM, Samsung, etc.)?</div></div></div></blockquote></span><div>All the embedded GPUs are for the foreseeable futures uninteresting for HPC.</div></div></div></div></blockquote><div><br></div></span><div>Note that HPC does, in most cases, not drive programming language/framework/standard adoption. </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> And I don't think anyone is interesting to program for ARM CPUs in OpenCL.</div></div></div></div></blockquote><div><br></div></span><div>For the above reason, stable libraries and compilers may drive the ecosystem forward even without HPC interest.</div><div><br></div><div>Plus there's the merging phone-tablet-laptiop segment where applications can gain a lot from CPU+GPU heterogeneous execution.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">
<div>I'm not sure Intel is totally uninterested. They've just moved out again their OpenCL SDK form the silly bundle they had before in the latest release AFAIK because people complained.</div></div></div></blockquote></span><div>Both the comments from Intel people and their performance tell me that it is a low to very low priority. They might be more interested for it for Iris but not for Phi.</div></div></div></div></blockquote><div><br></div></span><div>Exactly. Photoshop, Autocad, etc. For the above reasons, I would not dismiss OpenCL as relevant. As far as I understood while chatting with someone from Intel a few months ago, Adobe and similar big players do use OpenCL quite a bit.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> And again Iris will probably not be relevant for HPC.</div></div></div></div></blockquote><div><br></div></span><div>O the sort run likely not. And that's unfortunate, I think.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">
<div>NVIDIA: no comment.</div><span>
<div><br>
</div>
<div>HIP and CUDA support seems like a desperate move from AMD to lower the barrier of entry and make things (seem) easier. Attracting dev/user interest to stay afloat is crucial for them. It would however be a major mistake for AMD to move away from OpenCL,
I think - unless they want to shoot themselves in the foot by encouraging people to only write CUDA kernels for AMD. Still need to look into this closer to understand what the direction is.</div></span></div></div></blockquote><div>Well that's what they told me. Go ahead write HIP/Cuda and it'll work on AMD.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">
<div>Overall, I feel like this is the time to not take the back seat. Rather than letting others decide whether it's going to be open standards or vendor lock-in that defines the low-level accelerator programming for the coming years I feel like we, though
GROMACS, can show that we care and perhaps can make a difference. That's why I wrote the previous mail. Don't get me wrong, I do not have the illusion that tomorrow we can just drop CUDA support just to make a point. However, providing an a decent alternative
based on OpenCL and pointing out that we want the open alternative to work as well as the closed one does require effort, but it is realistic.</div></div></div></blockquote></span><div>Given that we and other won't be willing to drop CUDA as long as it is faster, there is no reason for NVidia to change. And as long as Nvidia doesn't change OpenCL isn't useful for AMD. Hoping that it is different, or asking pretty please, won't change that.</div></div></div></div></blockquote><div><br></div></span><div>Shift some developer focus away from CUDA may be just enough to send a message, no need to drop CUDA.</div><div><br></div><div>Given that there is a substantial effort needed to get from implementing some cool new feature to getting it into a production release, one could postpone bringing this feature into a production version (keep it in an unmerged under review state) and spend the time saved e.g. on tuning OpenCL (e.g. for Intel CPU+iGPU or AMD APUs). This could send a message that may be heard and perhaps taken seriously if done repeatedly by multiple OOS projects.</div></div></div></div></blockquote><div><br></div><div>Correction #1: I meant OSS projects.</div><div><br></div><div>Correction #2: On a second thought, it does not have to be OSS. Many projects can make a difference, they just have to be influential enough, I think. As I see it NVIDIA's dominance is fragile given the quickly shifting nature of the computing industry and accelertorarchitectures.</div><div><br></div><div>--<br>Szilárd<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Cheers,</div><div>--</div><div>Szilárd</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">
<div><br>
</div>
<div>Cheers,</div><span><font color="#888888">
</font></span></div><span><font color="#888888">
</font></span><div class="gmail_extra"><span><font color="#888888"><br clear="all">
<div>
<div>--<br>
Szilárd</div>
</div></font></span><div><div><span><font color="#888888">
<br>
</font></span><div class="gmail_quote"><span>On Thu, Nov 26, 2015 at 7:37 PM, Roland Schulz <span dir="ltr">
<<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br>
</span><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I wouldn't be surprised if OpenCL is fading out. NVidia and Intel have very little to no interest. And AMD has realized that a standard only really supported by them isn't going to be used and they now push HIP (<a href="http://www.amd.com/en-us/press-releases/Pages/boltzmann-initiative-2015nov16.aspx" target="_blank">http://www.amd.com/en-us/press-releases/Pages/boltzmann-initiative-2015nov16.aspx</a>)
instead. People from AMD I talked to at SC, recommended to use HIP over OpenCL because they claim this will allow performance portable code. This might leave the FPGA guys as the only ones providing performant OpenCL implementations. Of course having a true
standard would be nicer than having to rely on HIP/Cuda but in practice it might very well be that those are the only useful (=performant) options in the future. </div>
<div><br>
</div>
<div>Roland</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Thu, Nov 26, 2015 at 1:04 PM, Szilárd Páll
<span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br>
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><span>
<div dir="ltr">One more thing!
<div><br>
</div>
<div>Let me take the opportunity to invite everyone interested to contribute (with either code, testing, docs) and help improving features and performance of our truly portable GPU/accelerator OpenCL code-path!</div>
<div><br>
</div>
<div>Our OpenCL implementation is stable and solid, but is lacking thorough tuning for AMD GPUs and support for integrated CPU+GPU architectures would be great too. There are a number of known to be useful extensions & optimizations (and probably even more
that we have not thought of) that could be pursued, but due to the lack of time/resources we have not done it yet.</div>
<div><br>
</div>
<div>I'd be happy to share ideas and collaborate with the goal of improving the OpenCL support for the next release!</div>
<div><br>
</div>
<div>So if you're interested, get in touch!</div>
<div><br>
</div>
<div>Cheers,</div>
</div>
</span>
<div class="gmail_extra"><br clear="all">
<div>
<div>--<br>
Szilárd</div>
</div>
<div>
<div><br>
<div class="gmail_quote"><span>On Thu, Nov 26, 2015 at 6:52 PM, Szilárd Páll
<span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br>
</span>
<div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi!
<div><br>
</div>
<div>My reply got quite delayed, sorry about that.</div>
<div><br>
</div>
<div>Just wanted to let you know that I am personally interested in getting Gallium support to work. I can't drive the work, ATM have very limited time to put into this, but I would love to help with fixing small things and with code review!</div>
<div><br>
</div>
<div>It would be nice to be able to use GROMACS on GPUs without any proprietary stuff. I'm sure distros will be happy to be able to provide a GROMACS package with no proprietary dependencies for GPUs. Of course, the performance matters too, but first thing
is to get it to work.</div>
<div><br>
</div>
<div>If somebody is interested in taking up the task of driving the work, please file a (some) redimine issue (list the concrete tasks if they're known)!</div>
<div><br>
</div>
<div>Cheers,</div>
<div class="gmail_extra">
<div>
<div>--<br>
Szilárd</div>
</div>
<div>
<div>
<div><br>
</div>
<br>
<div class="gmail_quote">On Tue, Oct 20, 2015 at 8:45 PM, Vedran Miletić <span dir="ltr">
<<a href="mailto:rivanvx@gmail.com" target="_blank">rivanvx@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
is there any interest for extending GROMACS OpenCL support to include<br>
Gallium for Radeon cards and perhaps others?<br>
<br>
(Background: We have a machine in our lab with Debian<br>
unstable/experimental and latest Kernel/DRM/LLVM/Mesa and an AMD<br>
Caicos card, set up a couple of years ago in hope that AMD will make<br>
completely open source OpenCL stack work at some point. After recent<br>
updates, we managed to run hello world examples and parts of ViennaCL<br>
benchmark.)<br>
<br>
Running gmx mdrun on Radeon HD 7450 on Kernel 4.2.3 and Mesa 11.0.2 results in<br>
<br>
Fatal error:<br>
Failed to compile NBNXN kernels for GPU #AMD CAICOS (DRM 2.43.0, LLVM 3.7.0)<br>
<br>
This creates a file named nbnxn_ocl_kernels.cl.FAILED with the<br>
following information:<br>
<br>
Compilation of source file failed!<br>
-- Used build options: -DWARP_SIZE_TEST=64 -D_AMD_SOURCE_<br>
-DGMX_OCL_FASTGEN_ADD_TWINCUT -DEL_EWALD_ANA -DEELNAME=_ElecEw<br>
-DVDWNAME=_VdwLJ -DCENTRAL=22 -DNBNXN_GPU_NCLUSTER_PER_SUPERCLUSTER=8<br>
-DNBNXN_GPU_CLUSTER_SIZE=8 -DNBNXN_GPU_JGROUP_SIZE=4<br>
-DNBNXN_AVOID_SING_R2_INC=1.0e-12f<br>
-I"/usr/local/gromacs/share/gromacs/opencl"<br>
--------------LOG START---------------<br>
input.cl:59:10: fatal error:<br>
'nbnxn_ocl_kernels_fastgen_add_twincut.clh' file not found<br>
input.cl:45:36: note: expanded from macro 'FLAVOR_LEVEL_GENERATOR'<br>
---------------LOG END----------------<br>
<br>
Is there any interest in supporting this configuration? Is there<br>
anyone besides us who would run GROMACS on Gallium and Radeon cards?<br>
<br>
Regards,<br>
Vedran<br>
<span><font color="#888888"><br>
--<br>
Vedran Miletić<br>
<a href="http://vedranmileti.ch/" rel="noreferrer" target="_blank">http://vedranmileti.ch/</a><br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">
http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">
http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to
<a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</font></span></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
<span><font color="#888888"></font></span></div>
</div>
</div>
<span><font color="#888888"></font></span></div>
<span><font color="#888888"></font></span></blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">
cmb.ornl.gov</a><br>
<a href="tel:865-241-1537" value="+18652411537" target="_blank">865-241-1537</a>, ORNL PO BOX 2008 MS6309</div>
</font></span></div>
<br>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">
http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">
http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to
<a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote>
</div></div></div>
<br>
</div></div></div>
</div>
</blockquote></div><div><div><br><br clear="all"><div><br></div>-- <br><div>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309</div>
</div></div></div></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>