[gmx-developers] GROMACS OpenCL on Gallium

[Szilárd Páll]

PS: I'm still not accustomed enough with OpenCL wording and it's just
occurred to me that images are actually not a must for GROMACS, I expect
that there will be greater performance limiters. Additionally, AFAIK
image-based fetch/interpolation was never fully implemented for the Ewald
correction term where the performance is likely the most critical.

So what about starting out with GROMACS kernels sans images and targeting
GCN through radeonsi?

--
Szilárd

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

> Hi Vedran,
>
> My feeling is that the (short to mid-term) return from efforts focused on
> higher-end AMD cards would be far greater. The GROMACS CPU kernels are so
> fast, especially with an AVX2 Intel chip, that most older GPUs cards,
> especially the lower-end ones, will simply not provide any performance
> benefit in GROMACS runs. Minor improvements could be made if we allow
> splitting and balancing the non-bonded task between CPU and GPU (which
> currently is either fully offloaded or not offloaded at all), but something
> like 30% gain is not much incentive compared to e.g. 2x.
>
> Therefore, it seems to me that it would be more useful to get something
> working on GCN and demonstrate usable performance on modern cards that e.g.
> gamers or people with decent APUs may have. Otherwise, while your efforts
> are clearly beneficial, they may not provide much benefit for GROMACS - at
> least not initially.
>
> Cheers,
> --
> Szilárd
>
> On Thu, Nov 26, 2015 at 7:46 PM, Vedran Miletić <rivanvx at gmail.com> wrote:
>
>> Hello Szilard and others,
>>
>> I have just been talking to Tom Stellard from AMD regarding the same
>> topic (synchronicity, anyone?). Getting stuff to work on open source
>> stack without any proprietary components and have it neatly packaged
>> in downstream distributions has been my primary motive here as well.
>>
>> The problem at this point is not on GROMACS side, but on the side of
>> open source driver for Radeon GPUs. There are two Radeon drivers in
>> Mesa which support OpenCL:
>> 1) r600g, which roughly supports HD 5000/6000 and low-end HD 7000/8000
>> (pre-GCN architecture),
>> 2) radeonsi, which supports high-end HD 7000 and newer cards (GCN
>> architecture).
>>
>> The main issue with GROMACS, perhaps among other issues, is missing
>> image support. r600g image support was implemented in a GSoC project
>> [1]. Patches have not been upstreamed yet, but they are available on
>> GitHub [2]. I have a Caicos card, and I plan to give those patches a
>> shot if it is not too much work. Given that I get it working, I might
>> go the extra mile and try to make them ready for inclusion in upstream
>> Mesa, but no promises here.
>>
>> On the side of radeonsi, I will be working on the OpenCL image support
>> in the coming weeks/months. My goal is to get GROMACS working first,
>> and then see if we can do anything with regards to performance on the
>> Radeon driver side or GROMACS side. I have already allocated the time
>> for it, and I have a Bonaire card to work with and will get a Tonga
>> card soon.
>>
>> Regards,
>> Vedran Miletic
>>
>> [1]
>> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/zogi/5738600293466112
>> [2] https://github.com/zogi/mesa/commits/gsoc
>>
>> 2015-11-26 19:04 GMT+01:00 Szilárd Páll <pall.szilard at gmail.com>:
>> > 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
>> >>
>> >>
>>
>> --
>> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20151126/ac422a77/attachment-0003.html>