Gauging interest/compatibility for WebGPU backend/Request

[jon-chuang]

Apparently, there should exist a path from SYCL source to WebGPU backend, by writing an abstraction layer that takes SYCL calls and converts them to WebGPU C API calls (see here and the header file). WebGPU exposes graphics interface, but also allows general compute and should allow for Vulkan compatible SPIR-V code, which can be converted from OpenCL SPIR-V via clspv.

Hence, I was wondering what the process might be to compile these Vulkan SPIR-V bytecode files through sycl-llvm SPIR-V codegen and pass through clspv, and link with a SYCL runtime that makes wgpu.h calls?

I understand that SYCL is primarily of interest to Intel in the HPC/data center space to program their complex suite of devices through a single API. However, having compatibility with a web-facing standard that works flawlessly could be in Intel's and SYCL's favour. This is because it could encourage adoption of SYCL by those looking to maintain a single code-base for both their web users and for data center scale accelerations, for instance if they themselves have customers with varying compute requirements.

[jon-chuang]

Can I get some response on this issue?

[bader]

WebGPU exposes graphics interface, but also allows general compute and should allow for Vulkan compatible SPIR-V code, which can be converted from OpenCL SPIR-V via clspv.

AFAIK, clspv compiles "OpenCL C" source code to SPIR-V shaders at the cost of limiting OpenCL features. So I don't think proposed compilation flow is possible with the available tools.

Do you have any particular examples where using SYCL programming model for WebGPU back-end is beneficial?

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days.