Gauging interest/compatibility for WebGPU backend/Request #5614
Replies: 3 comments
|
Can I get some response on this issue? |
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? |
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions