<div dir="ltr">That's a pity. The GalliumCompute page you linked seems to claim support for atomics, something must be off here that would be worth clarifying.<div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br clear="all"><div><div>--<br>Szilárd</div></div>
<br><div class="gmail_quote">On Sat, Nov 28, 2015 at 10:31 AM, 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">Same issue with radeonsi, interestingly enough. According to [1],<br>
Bonaire is Sea Islands; according to [2], it should support global<br>
(and local) atomics.<br>
<br>
Running on 1 node with total 6 cores, 6 logical cores, 1 compatible GPU<br>
Hardware detected:<br>
CPU info:<br>
Vendor: AuthenticAMD<br>
Brand: AMD FX(tm)-6300 Six-Core Processor<br>
SIMD instructions most likely to fit this hardware: AVX_128_FMA<br>
SIMD instructions selected at GROMACS compile time: AVX_128_FMA<br>
<span> GPU info:<br>
Number of GPUs detected: 1<br>
</span> #0: name: AMD BONAIRE (DRM 2.43.0, LLVM 3.8.0), vendor: AMD,<br>
device version: OpenCL 1.1 MESA 11.2.0-devel, stat: compatible<br>
<span><br>
Reading file em.tpr, VERSION 5.1-dev-20150219-7c30fcf-unknown (single precision)<br>
Note: file tpx version 100, software tpx version 106<br>
</span>Using 1 MPI thread<br>
Using 6 OpenMP threads<br>
<span><br>
1 compatible GPU is present, with ID 0<br>
1 GPU auto-selected for this run.<br>
Mapping of GPU ID to the 1 PP rank in this node: 0<br>
<br>
Selecting kernel for AMD<br>
</span>LLVM ERROR: Cannot select: t28: i32,ch = AtomicCmpSwap<Volatile<br>
LDST4[%522(addrspace=1)]> t0, t2, t4, t9<br>
t2: i64,ch = CopyFromReg t0, Register:i64 %vreg299<br>
t1: i64 = Register %vreg299<br>
t4: i32,ch = CopyFromReg t0, Register:i32 %vreg302<br>
t3: i32 = Register %vreg302<br>
t9: i32 = bitcast t8<br>
t8: f32 = fadd t7, t5<br>
t7: f32,ch = CopyFromReg t0, Register:f32 %vreg298<br>
t6: f32 = Register %vreg298<br>
t5: f32 = bitcast t4<br>
t4: i32,ch = CopyFromReg t0, Register:i32 %vreg302<br>
t3: i32 = Register %vreg302<br>
In function: nbnxn_kernel_ElecEw_VdwLJ_F_opencl<br>
<br>
Regards,<br>
Vedran<br>
<br>
[1] <a href="http://xorg.freedesktop.org/wiki/RadeonFeature/" rel="noreferrer" target="_blank">http://xorg.freedesktop.org/wiki/RadeonFeature/</a><br>
[2] <a href="http://dri.freedesktop.org/wiki/GalliumCompute/" rel="noreferrer" target="_blank">http://dri.freedesktop.org/wiki/GalliumCompute/</a><br>
<div><div><br>
2015-11-27 21:05 GMT+01:00 Vedran Miletić <<a href="mailto:rivanvx@gmail.com" target="_blank">rivanvx@gmail.com</a>>:<br>
> 2015-11-27 20:50 GMT+01:00 Szilárd Páll <<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>>:<br>
>> Thanks for getting back! Without CAS we won't get very far, I'm afraid. The<br>
>> kernels would need to be rewritten to dump forces to global memory and<br>
>> reduce them later which will likely completely kill performance (and it's a<br>
>> hassle to do).<br>
>><br>
>><br>
>>><br>
>>> I can see what I can do, but perhaps StreamComputing guys would be the<br>
>>> ones to ask here because it is their code.<br>
>><br>
>><br>
>> I know the code fairly well, but I double-checked to be sure and<br>
>> (unfortunately) image support never got fixed, see:<br>
>> <a href="http://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_data_mgmt.cpp#L208" rel="noreferrer" target="_blank">http://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_data_mgmt.cpp#L208</a><br>
>> <a href="http://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_data_mgmt.cpp#L423" rel="noreferrer" target="_blank">http://redmine.gromacs.org/projects/gromacs/repository/revisions/master/entry/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_data_mgmt.cpp#L423</a><br>
>><br>
>> So image support is definitely not in the way of using radeonsi - and even<br>
>> if we implement it, keeping a version with simple gmem direct acesses for<br>
>> the latter parameter lookup and the analytical estimate iso tabulated Ewald<br>
>> correction (former) will always remain as an option.<br>
>><br>
>> Cheers,<br>
>> --<br>
>> Szilárd<br>
>><br>
><br>
> If it works, that would be uber awesome... I have to compile the stack<br>
> on radeonsi machine... I will try to do it over the weekend, don't<br>
> really want to wait next week to find out if it works or not.<br>
><br>
> Regards,<br>
> Vedran<br>
><br>
> --<br>
> Vedran Miletić<br>
> <a href="http://vedranmileti.ch/" rel="noreferrer" target="_blank">http://vedranmileti.ch/</a><br>
<br>
<br>
<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>.</div></div></blockquote></div><br></div></div>