DmitryKo
Veteran
LLVM back-end is based on platform-independent bytecode, and both Vulkan/OpenCL SPIR-V bytecode and CUDA PTX bytecode are versions of LLVM bytecode. It knows nothing about high-level languages - any architecture-specific back-end will support whatever language the front-end implements.]not all of them like Nvidia's PTX backend can support standard C++. Clang/LLVM support does not confer support for standard C++
I don't see your issue of having to maintain another vendor specific standard.
Intel should be the one to implement HIP instead of having AMD waste time with another potentially zombie standard
Compute standards just aren't meant to be community projects
Intel thinks otherwise and their HPC efforts are based on SYCL and Clang/LLVM/SPIR-V, not another proprietary API and compiler. Their upcoming Xe-HPC accelerators have won the Aurora supercomputer contract from USDOE - it they can rival Nvidia Tesla/DGX and AMD Radeon Pro/Instinct, this could be a game changer for the API landscape.
I'm certainly not going to ditch Windows for a server OS on my desktop, I have work to do.Which is exactly why you should ditch Windows
Microsoft doesn't care about high-end compute
Also I'm not sure why it's Microsoft's fault when NVIDIA and AMD advertise HSA features but cannot implement a proper heterogeneous MMU with a page table entry format that supports page faults in system memory, and have to rely on a Linux-specific kernel component to fix the issues that arise. Microsoft works around it with memory residency API in DXGI and Direct3D 12 to manage large heap allocations.
CUDA arguably is a stronger proposition in terms of portability compared to either Khronos' OpenCL or SYCL standard
CUDA enjoys a large following but code migration tools work both ways, so native SYCL with CUDA conversion could become equally popular.
Code analysis and optimization tools are computer-architecture specific, they are not defined in or required by any high-level language specification.it is absolutely not required to support SYCL
Which severely impact application performance.GPU kernel languages are missing standard C++ features
It takes time and the specs are not final yet.I don't see any tests C++ for OpenCL
Yes, it looks like CodeXL repository was archived and developers were directed to ROCm repository or GPUOpen.com website (which relaunches May 11 after a redesign).CodeXL isn't being maintained anymore by AMD
Vulkan only needs to support SPIR-V bytecode as a target for OpenCL/SYCL toolsets.I hoped Vulkan would adopt OpenCL C shaders
Last edited: