Currently all means of developing SYCL applications on Windows are either discontinued or has missing driver/runtime components.
- Codeplays ComputeCpp has prime time support for SPIR, experimental SPIR-V and has an AMDGPU back-end on the back log.
- SPIR was last supported in Radeon Software 18.2.3 (hence discontinued) which is over a year old.
- SPIR-V at the time of writing is still missing from latest Radeon Software runtimes. Ideally, current 2.0 implementation need be pushed to 2.1 which introduces SPIR-V, as is also the requirement for ComputeCpps experimental SPIR-V back-end.
- Finishing the AMDGPU back-end is up to Codeplay, but it's a workaround that should really not exist.
- HipSYCL recently moved to a Clang plugin compilation model. In order to leverage this path, ROCm need be ported to Windows.
- I got a little disconnected with triSYCL development since they started to focus on compiling with Clang. The OpenMP back-end would require OpenMP 5.0 support from either Clang or MSVC on Windows, none of which is going to happen anytime soon.
- Edit: Intels Clang fork with SYCL which is being upstreamed in a slightly non-conforming manner exposes SPIR 1.2(.1) atop an OpenCL 2.1 runtime with SPIR-V.
I understand there's a strong focus on ROCm, but the ecosystem perhaps reached the volume where the gains of porting ROCm to PAL would outweigh the costs. The relevant issue on Github was closed, the question on this forum receivies no official statement.
Edit: As a sidenote, the title might as well have been just st SYCL development, without the Windows part. On my Linux install which I rarely boot can only handle HipSYCL. Codeplay requires an extremely outdated AMDGPU-PRO which requires an older Ubuntu even, triSYCL is moving to Clang instead of baking an OpenMP 5.0 back-end (which would still require GCC to up its game concerning hooking it into the AMDGPU back-end)... so generally, this awesome Khronos GPGPU API is very hard to get working on AMD GPUs in any way.
