search for: rocm

...version 11.0.0 (https://github.com/llvm/llvm-project 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None) !1 = !DIFile(filename: "foo.cpp", directory: "/home/mahesha/ROCm/issues/hipclang/other/crash/foo") !2 = !{} !3 = !{i32 7, !"Dwarf Version", i32 4} !4 = !{i32 2, !"Debug Info Version", i32 3} !5 = !{i32 1, !"wchar_size", i32 4} !6 = !{!"clang version 11.0.0 (https://github.com/llvm/llvm-project 9e0b52e2e68412a9a2add18697f42...

...ct > > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false, > > runtimeVersion: 0, emissionKind: FullDebug, enums: !2, > > splitDebugInlining: false, nameTableKind: None) > > !1 = !DIFile(filename: "foo.cpp", directory: > > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo") > > !2 = !{} > > !3 = !{i32 7, !"Dwarf Version", i32 4} > > !4 = !{i32 2, !"Debug Info Version", i32 3} > > !5 = !{i32 1, !"wchar_size", i32 4} > > !6 = !{!"clang version 11.0.0 (https://github.c...

...697f4246e5e5ee5e3)", isOptimized: false, > >> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2, > >> > splitDebugInlining: false, nameTableKind: None) > >> > !1 = !DIFile(filename: "foo.cpp", directory: > >> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo") > >> > !2 = !{} > >> > !3 = !{i32 7, !"Dwarf Version", i32 4} > >> > !4 = !{i32 2, !"Debug Info Version", i32 3} > >> > !5 = !{i32 1, !"wchar_size", i32 4} > >> > !6 = !{...

...d: false, > >> >> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2, > >> >> > splitDebugInlining: false, nameTableKind: None) > >> >> > !1 = !DIFile(filename: "foo.cpp", directory: > >> >> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo") > >> >> > !2 = !{} > >> >> > !3 = !{i32 7, !"Dwarf Version", i32 4} > >> >> > !4 = !{i32 2, !"Debug Info Version", i32 3} > >> >> > !5 = !{i32 1, !"wchar_size&quot...

There certainly is support; after all AMD supports both OpenCL and HIP (a dialect of C++ very close to cuda). AMD device libraries (in bitcode form) are installed when ROCm ( https://rocm.github.io/ ) is installed. AMD device libraries are mostly written in (OpenCL) C and open source at https://github.com/RadeonOpenCompute/ROCm-Device-Libs . They are configured by linking in a number tiny libraries that define global constants; these allow unwanted code including br...

Hi dev list, I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The following IR is generated for a simple address space test that copies from global to shared memory and back to global after a barrier synchronization. Here is the IR is attached as as1.ll The output is as follo...

...Thanks! On Tue, Sep 4, 2018 at 9:23 AM 董昌道 <dongchangdao at gmail.com> wrote: > I am writing a miner of crypto currency, for which most users run it with > amdgpu driver. I have written a script the translate the meta data of LLVM > isa format into clrxasm format. I also modified ROCm version of llvm to > reorganize the order of the kernel args so that it’s compatible with > clrxasm. It seems working and clrxasm seems support this dispatch kernel > ptr thing. But it would be nice if I can turn it off. Reading the LLVM code > it seems this intrinsic is hard coded? Hop...

Does anyone know whether there is yet support for math functions in AMD GPU kernels? In the NVIDIA world they provide the libdevice IR module which can be linked to an existing module containing the kernel. In other words they provide all math functions on IR level. NVIDIA even claims that libdevice is actually device specific (compute capability). I was wondering how that is done on the AMD

...th a prefix in my home directory. Second, for OpenMP target offloading, we recommend users to compile the latest trunk because it is under heavy development. In practice, if you are using target offloading, you have to compile it yourself because it needs to match the installed version of CUDA (or ROCm) and I have yet to see a distribution where OpenMP target offloading works out of the box. Michael

Hi Folks, At AMD we are growing our ROCm ( https://rocm.github.io/index.html) compiler team. The compiler is built on the llvm compiler foundation, and it supports OpenCL, HCC C++ and HIP for application portability. We are considering all qualified applicants regardless of the experience level. Requirements are: Strong background...

...a runtime library (PACXX-RT) to execute kernels on the available hardware. Currently, PACXX supports Nvidia GPUs through the NVPTX Target and CUDA, CPUs through MCJIT (including whole function vectorization thanks to RV [1]) and has an experimental back-end for AMD GPUs using the AMDGPU Target and ROCm. The main idea behind PACXX is the use of the LLVM IR as kernel code representation which is integrated into the executable together with the PACXX-RT. At runtime of the program the PACXX-RT compiles the IR to the final MC level and hands it over to the device. Since, PACXX does currently not enf...

...a runtime library (PACXX-RT) to execute kernels on the available hardware. Currently, PACXX supports Nvidia GPUs through the NVPTX Target and CUDA, CPUs through MCJIT (including whole function vectorization thanks to RV [1]) and has an experimental back-end for AMD GPUs using the AMDGPU Target and ROCm. > > The main idea behind PACXX is the use of the LLVM IR as kernel code representation which is integrated into the executable together with the PACXX-RT. At runtime of the program the PACXX-RT compiles the IR to the final MC level and hands it over to the device. Since, PACXX does current...

...a runtime library (PACXX-RT) to execute kernels on the available hardware. Currently, PACXX supports Nvidia GPUs through the NVPTX Target and CUDA, CPUs through MCJIT (including whole function vectorization thanks to RV [1]) and has an experimental back-end for AMD GPUs using the AMDGPU Target and ROCm. >> >> The main idea behind PACXX is the use of the LLVM IR as kernel code representation which is integrated into the executable together with the PACXX-RT. At runtime of the program the PACXX-RT compiles the IR to the final MC level and hands it over to the device. Since, PACXX does c...

Hi Alexey, Your reply has been a great help to me,your way of explain the different types of compilation is very detailed and easy to understand. Even so, I have a couple of questions. 1) What do yourefer by OpenCL RT? 2) Could you give me some examples of an open-source OpenCL implementation and update optimization pipeline? Thank you in advance. Regards El vie., 20 sept. 2019 a las 12:34,

...arsenm2 at gmail.com> wrote: > > > >> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi dev list, >> >> I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The following IR is generated for a simple address space test that copies from global to shared memory and back to global after a barrier synchronization. >> >> Here is the IR is attached as as1.ll >&...

Am Mi., 18. Nov. 2020 um 05:32 Uhr schrieb David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>: > In terms of the most useful build configuration to be the default, I > think there are a bunch of users that we need to consider: > > - Developers of LLVM > - Developers of downstream projects that use LLVM > - Package builders > - CI admins. This is missing

...ectory tree). > Second, for OpenMP target offloading, we recommend users to compile > the latest trunk because it is under heavy development. In practice, > if you are using target offloading, you have to compile it yourself > because it needs to match the installed version of CUDA (or ROCm) and > I have yet to see a distribution where OpenMP target offloading works > out of the box. That sounds unfortunate. I presume that there is a long-term plan for fixing this? David

On Sat, Jan 28, 2023 at 1:17 AM Christian K?nig <christian.koenig at amd.com> wrote: > > Am 27.01.23 um 15:44 schrieb Danilo Krummrich: > > [SNIP] > >>>> > >>>> What you want is one component for tracking the VA allocations > >>>> (drm_mm based) and a different component/interface for tracking the > >>>> VA mappings