Re: [Starpu-devel] support for cudaMemcpyPeer

[Hatem Ltaief <hatem.ltaief@kaust.edu.sa>]

> On Mar 25, 2018, at 4:02 AM, Samuel Thibault <samuel.thibault@inria.fr> 
> wrote:
>
> Hatem Ltaief, on dim. 25 mars 2018 10:58:22 +0000, wrote:
>>    On Mar 24, 2018, at 4:09 PM, Samuel Thibault 
>> <[1]samuel.thibault@inria.fr>
>>    wrote:
>>
>>    Hatem Ltaief, on sam. 24 mars 2018 13:52:01 +0000, wrote:
>>
>>        You are right, I have omitted the dyn libs. So, it is there
>>
>>
>>    How is it there exactly?  Please send the nm output :)
>>
>>
>> hltaief@samsara:~/benchmarks/dpotrf$ nm -D /usr/local/cuda/lib64/
>> libcudart.so.9.0 | grep MemcpyPeer
>> 000000000003f510 T cudaMemcpyPeer
>> 000000000004bdd0 T cudaMemcpyPeerAsync
>
> Ok, so I have no idea why the test would fail to find it.
>
>>    There is no reason why we should use -lcudart_static.
>>
>>    That being said, I just dropped that detection, it can only pose problem
>>    whenever NVidia does tricky things with the symbol, and nowadays we can
>>    safely assume by default that it is available.
>>
>> Not sure I followed you on this one.
>> Can you please explain?
>
> I simply removed the test, and instead made configure assume that the
> symbol is there, which gets the issue away.


OK got it!
Is there a way within StarPU (SPARPU_STATS?) to check if this fast copies, 
i.e., vi NVLink, were in effect during a given run? I guess besides 
witnessing performance improvements…

H

>
> Samuel


________________________________
This message and its contents including attachments are intended solely for 
the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete this 
message from your computer system. Any unauthorized use or distribution is 
prohibited. Please consider the environment before printing this email.