[Openmp-dev] Target architecture does not support unified addressing

Itaru Kitayama via Openmp-dev openmp-dev at lists.llvm.org
Fri May 1 16:24:29 PDT 2020


Doru,
What's the current way of enabling SM_60 CUDA architecture support for
unified addressing?
It's been modified since we exchanged the message.

On Thu, Nov 7, 2019 at 4:05 AM Gheorghe-Teod Bercea <
Gheorghe-Teod.Bercea at ibm.com> wrote:

> Hi Itaru,
>
> We did not test those features on an sm_60 machine like a Pascal GPU so I
> can't guarantee it will work. I suggest you enable it locally and see how
> it performs.
> You only need to make a small change in "void
> CGOpenMPRuntimeNVPTX::checkArchForUnifiedAddressing(const OMPRequiresDecl
> *D)" to allow sm_60 to be accepted as a valid target.
>
> Thanks,
>
> --Doru
>
>
>
>
> From:        Itaru Kitayama via Openmp-dev <openmp-dev at lists.llvm.org>
> To:        Alexey Bataev <a.bataev at outlook.com>
> Cc:        openmp-dev <openmp-dev at lists.llvm.org>
> Date:        11/05/2019 06:04 PM
> Subject:        [EXTERNAL] Re: [Openmp-dev] Target architecture does not
> support unified        addressing
> Sent by:        "Openmp-dev" <openmp-dev-bounces at lists.llvm.org>
> ------------------------------
>
>
>
> Can you say briefly as to why SM60, while it is capable of handing unified
> addresses, is not supported in Clang?
>
> On Wed, Nov 6, 2019 at 7:56 AM Alexey Bataev <*a.bataev at outlook.com*
> <a.bataev at outlook.com>> wrote:
> Yes, it is enforced in clang.
>
> Best regards,
> Alexey Bataev
>
> 5 нояб. 2019 г., в 17:38, Itaru Kitayama <*itaru.kitayama at gmail.com*
> <itaru.kitayama at gmail.com>> написал(а):
>
>
> Thank you, Alexey. Now I am seeing:
>
> $ clang++ -fopenmp -fopenmp-targets=nvptx64 tmp.cpp
> tmp.cpp:1:22: error: Target architecture sm_60 does not support unified
> addressing
> #pragma omp requires unified_shared_memory
>                      ^
> 1 error generated.
>
> P100 is a SM60 device, but supports unified memory. Is a requirement sm_70
> equals or greater
> enforced in Clang?
>
> On Wed, Nov 6, 2019 at 5:07 AM Alexey Bataev <*a.bataev at outlook.com*
> <a.bataev at outlook.com>> wrote:
> Most probably, you use default architecture, i.e. sm_35. You need to build
> clang with sm_35, sm_70, ... supported archs. Plus, your system must
> support unified memory.
> I updated error message in the compiler, now it says what target
> architecture you use .
> -------------
> Best regards,
> Alexey Bataev
> 05.11.2019 3:01 PM, Itaru Kitayama пишет:
> I’ve been building trunk Clang locally targeting the P100 device attached
> to Host. Should I check the tool chain?
>
> On Tue, Nov 5, 2019 at 23:47 Alexey Bataev <*a.bataev at outlook.com*
> <a.bataev at outlook.com>> wrote:
> You're building you code for the architecture that does not support
> unified memory, say sm_35. Unified memory only supported for architectures
> >= sm_70.
> -------------
> Best regards,
> Alexey Bataev
> 05.11.2019 3:16 AM, Itaru Kitayama via Openmp-dev пишет:
> Hi,
> Using a pragma like below:
>
> $ cat tmp.cpp
> #pragma omp requires unified_shared_memory
>
> int main() {
> }
>
> produces en error on a POWER8 based system with P100 devices (that support
> unified memory).
>
> $ clang++ -fopenmp -fopenmp-targets=nvptx64 tmp.cpp
> tmp.cpp:1:22: error: Target architecture does not support unified
> addressing
> #pragma omp requires unified_shared_memory
>                      ^
> 1 error generated.
>
> The Clang is locally and natively built with the appropriate capability,
> so
> what does this mean?
>
>
> _______________________________________________
> Openmp-dev mailing list
> *Openmp-dev at lists.llvm.org* <Openmp-dev at lists.llvm.org>
> *https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev*
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200502/16b942ab/attachment.html>


More information about the Openmp-dev mailing list