[gmx-developers] GROMACS OpenCL on Gallium

Thu Nov 26 20:25:46 CET 2015

On Thu, Nov 26, 2015 at 2:07 PM, Szilárd Páll <pall.szilard at gmail.com>
wrote:

> Hi,
>
> Besides FPGA folks, what about Apple, embedded and mobile platforms
> (Qualcomm, ARM, Samsung, etc.)?
>
All the embedded GPUs are for the foreseeable futures uninteresting for
HPC. And I don't think anyone is interesting to program for ARM CPUs in
OpenCL.

> 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.
>
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. And again Iris will probably not be relevant for HPC.

NVIDIA: no comment.
>
> 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.
>
Well that's what they told me. Go ahead write HIP/Cuda and it'll work on
AMD.

> 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.
>
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.

Roland

>
> Cheers,
>
> --
> Szilárd
>
> On Thu, Nov 26, 2015 at 7:37 PM, Roland Schulz <roland at utk.edu> wrote:
>
>> Hi,
>>
>> 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 (
>> http://www.amd.com/en-us/press-releases/Pages/boltzmann-initiative-2015nov16.aspx)
>> 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.
>>
>> Roland
>>
>> On Thu, Nov 26, 2015 at 1:04 PM, Szilárd Páll <pall.szilard at gmail.com>
>> wrote:
>>
>>> One more thing!
>>>
>>> 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!
>>>
>>> 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.
>>>
>>> I'd be happy to share ideas and collaborate with the goal of improving
>>> the OpenCL support for the next release!
>>>
>>> So if you're interested, get in touch!
>>>
>>> Cheers,
>>>
>>> --
>>> Szilárd
>>>
>>> On Thu, Nov 26, 2015 at 6:52 PM, Szilárd Páll <pall.szilard at gmail.com>
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> My reply got quite delayed, sorry about that.
>>>>
>>>> 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!
>>>>
>>>> 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.
>>>>
>>>> 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)!
>>>>
>>>> Cheers,
>>>> --
>>>> Szilárd
>>>>
>>>>
>>>> On Tue, Oct 20, 2015 at 8:45 PM, Vedran Miletić <rivanvx at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> is there any interest for extending GROMACS OpenCL support to include
>>>>> Gallium for Radeon cards and perhaps others?
>>>>>
>>>>> (Background: We have a machine in our lab with Debian
>>>>> unstable/experimental and latest Kernel/DRM/LLVM/Mesa and an AMD
>>>>> Caicos card, set up a couple of years ago in hope that AMD will make
>>>>> completely open source OpenCL stack work at some point. After recent
>>>>> updates, we managed to run hello world examples and parts of ViennaCL
>>>>> benchmark.)
>>>>>
>>>>> Running gmx mdrun on Radeon HD 7450 on Kernel 4.2.3 and Mesa 11.0.2
>>>>> results in
>>>>>
>>>>> Fatal error:
>>>>> Failed to compile NBNXN kernels for GPU #AMD CAICOS (DRM 2.43.0, LLVM
>>>>> 3.7.0)
>>>>>
>>>>> This creates a file named nbnxn_ocl_kernels.cl.FAILED with the
>>>>> following information:
>>>>>
>>>>> Compilation of source file failed!
>>>>> -- Used build options: -DWARP_SIZE_TEST=64 -D_AMD_SOURCE_
>>>>> -DGMX_OCL_FASTGEN_ADD_TWINCUT -DEL_EWALD_ANA -DEELNAME=_ElecEw
>>>>> -DVDWNAME=_VdwLJ -DCENTRAL=22 -DNBNXN_GPU_NCLUSTER_PER_SUPERCLUSTER=8
>>>>> -DNBNXN_GPU_CLUSTER_SIZE=8 -DNBNXN_GPU_JGROUP_SIZE=4
>>>>> -DNBNXN_AVOID_SING_R2_INC=1.0e-12f
>>>>> -I"/usr/local/gromacs/share/gromacs/opencl"
>>>>> --------------LOG START---------------
>>>>> input.cl:59:10: fatal error:
>>>>> 'nbnxn_ocl_kernels_fastgen_add_twincut.clh' file not found
>>>>> input.cl:45:36: note: expanded from macro 'FLAVOR_LEVEL_GENERATOR'
>>>>> ---------------LOG END----------------
>>>>>
>>>>> Is there any interest in supporting this configuration? Is there
>>>>> anyone besides us who would run GROMACS on Gallium and Radeon cards?
>>>>>
>>>>> Regards,
>>>>> Vedran
>>>>>
>>>>> --
>>>>> Vedran Miletić
>>>>> http://vedranmileti.ch/
>>>>> --
>>>>> Gromacs Developers mailing list
>>>>>
>>>>> * Please search the archive at
>>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>>>>> before posting!
>>>>>
>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>>
>>>>> * For (un)subscribe requests visit
>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>>>> or send a mail to gmx-developers-request at gromacs.org.
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>>
>
>

-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20151126/5e88bbfe/attachment.html>