Open sudonatalie opened 9 months ago
Blocked pending changes to the dx.create.handle
instrinsic (#75828)
The current DirectX plan is https://github.com/llvm/llvm-project/blob/99f527d2807b5a14dc7ee64d15405f09e95ee9f2/llvm/docs/DirectX/DXILResources.rst#resource-handles. We will try to follow a similar plan. This simplifies the HLSL code generation because it will be make the two paths essentially the same. Diverging as little as possible before going to the backend is beneficial.
The step we need to get just simple uses of RWBuffers:
spirv.Image
.handle_fromBinding
intrinsic and load the handleOnce this is done, we should be able to write a simple shader that is not equivalent to an empty compute shader.
We considered trying to match OpenCL more. We are already reusing the spirv.Image
target type from OpenCL. However, we could not use it for other parts.
In HLSL the resources are global variable, while in OpenCL, the image resources are function parameter and not globals. The two are so different that not much can be reused.
We also cannot reuse the read_image*
and write_image*
functions because these are not reserved names in HLSL, so HLSL developer could write there own functions with those names. This is why we need HLSL specific intrinsics. However, the implementation of the HLSL intrinsics could share code with the implementation of the OpenCL read and write functions.
Resource types are not yet fully supported. In particular, there is not yet sufficient metadata or resources annotations to provide correct data bindings for Vulkan target environments. However, there should be enough information to support simple construction that passes SPIR-V validation with implicit bindings, which would be a good start.