<div dir="ltr">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.<div><br></div><div>So what about starting out with GROMACS kernels sans images and targeting GCN through radeonsi?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Szilárd</div></div>
<br><div class="gmail_quote">On Thu, Nov 26, 2015 at 8:21 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Vedran,<br><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div class="gmail_extra"><div><div>--<br>Szilárd</div></div><div><div class="h5">
<br><div class="gmail_quote">On Thu, Nov 26, 2015 at 7:46 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Szilard and others,<br>
<br>
I have just been talking to Tom Stellard from AMD regarding the same<br>
topic (synchronicity, anyone?). Getting stuff to work on open source<br>
stack without any proprietary components and have it neatly packaged<br>
in downstream distributions has been my primary motive here as well.<br>
<br>
The problem at this point is not on GROMACS side, but on the side of<br>
open source driver for Radeon GPUs. There are two Radeon drivers in<br>
Mesa which support OpenCL:<br>
1) r600g, which roughly supports HD 5000/6000 and low-end HD 7000/8000<br>
(pre-GCN architecture),<br>
2) radeonsi, which supports high-end HD 7000 and newer cards (GCN architecture).<br>
<br>
The main issue with GROMACS, perhaps among other issues, is missing<br>
image support. r600g image support was implemented in a GSoC project<br>
[1]. Patches have not been upstreamed yet, but they are available on<br>
GitHub [2]. I have a Caicos card, and I plan to give those patches a<br>
shot if it is not too much work. Given that I get it working, I might<br>
go the extra mile and try to make them ready for inclusion in upstream<br>
Mesa, but no promises here.<br>
<br>
On the side of radeonsi, I will be working on the OpenCL image support<br>
in the coming weeks/months. My goal is to get GROMACS working first,<br>
and then see if we can do anything with regards to performance on the<br>
Radeon driver side or GROMACS side. I have already allocated the time<br>
for it, and I have a Bonaire card to work with and will get a Tonga<br>
card soon.<br>
<br>
Regards,<br>
Vedran Miletic<br>
<br>
[1] <a href="https://www.google-melange.com/gsoc/project/details/google/gsoc2015/zogi/5738600293466112" rel="noreferrer" target="_blank">https://www.google-melange.com/gsoc/project/details/google/gsoc2015/zogi/5738600293466112</a><br>
[2] <a href="https://github.com/zogi/mesa/commits/gsoc" rel="noreferrer" target="_blank">https://github.com/zogi/mesa/commits/gsoc</a><br>
<div><div><br>
2015-11-26 19:04 GMT+01:00 Szilárd Páll <<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>>:<br>
> One more thing!<br>
><br>
> Let me take the opportunity to invite everyone interested to contribute<br>
> (with either code, testing, docs) and help improving features and<br>
> performance of our truly portable GPU/accelerator OpenCL code-path!<br>
><br>
> Our OpenCL implementation is stable and solid, but is lacking thorough<br>
> tuning for AMD GPUs and support for integrated CPU+GPU architectures would<br>
> be great too. There are a number of known to be useful extensions &<br>
> optimizations (and probably even more that we have not thought of) that<br>
> could be pursued, but due to the lack of time/resources we have not done it<br>
> yet.<br>
><br>
> I'd be happy to share ideas and collaborate with the goal of improving the<br>
> OpenCL support for the next release!<br>
><br>
> So if you're interested, get in touch!<br>
><br>
> Cheers,<br>
><br>
> --<br>
> Szilárd<br>
><br>
> On Thu, Nov 26, 2015 at 6:52 PM, Szilárd Páll <<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi!<br>
>><br>
>> My reply got quite delayed, sorry about that.<br>
>><br>
>> Just wanted to let you know that I am personally interested in getting<br>
>> Gallium support to work. I can't drive the work, ATM have very limited time<br>
>> to put into this, but I would love to help with fixing small things and with<br>
>> code review!<br>
>><br>
>> It would be nice to be able to use GROMACS on GPUs without any proprietary<br>
>> stuff. I'm sure distros will be happy to be able to provide a GROMACS<br>
>> package with no proprietary dependencies for GPUs. Of course, the<br>
>> performance matters too, but first thing is to get it to work.<br>
>><br>
>> If somebody is interested in taking up the task of driving the work,<br>
>> please file a (some) redimine issue (list the concrete tasks if they're<br>
>> known)!<br>
>><br>
>> Cheers,<br>
>> --<br>
>> Szilárd<br>
>><br>
>><br>
<br>
</div></div><div><div>--<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>.</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>