- Even though the bindless surface/texture interfaces are promoted, there are still code using surface/texture references. For example, PR#26400 reports the compilation issue for code using tex2D with texture references. For better compatibility, this patch proposes the support of surface/texture references.
- Due to the absent documentation and magic headers, it's believed that nvcc does use builtins for texture support. From the limited NVVM documentation[^nvvm] and NVPTX backend texture/surface related tests[^test], it's believed that surface/texture references are supported by replacing their reference types, which are annotated with device_builtin_surface_type/device_builtin_texture_type, with the corresponding handle-like object types, cudaSurfaceObject_t or cudaTextureObject_t, in the device-side compilation. On the host side, that global handle variables are registered and will be established and updated later when corresponding binding/unbinding APIs are called[^bind]. Surface/texture references are most like device global variables but represented in different types on the host and device sides.
- In this patch, the following changes are proposed to support that behavior: + Refine device_builtin_surface_type and device_builtin_texture_type attributes to be applied on Type decl only to check whether a variable is of the surface/texture reference type. + Add hooks in code generation to replace that reference types with the correponding object types as well as all accesses to them. In particular, nvvm.texsurf.handle.internal should be used to load object handles from global reference variables[^texsurf] as well as metadata annotations. + Generate host-side registration with proper template argument parsing.
[^nvvm]: https://docs.nvidia.com/cuda/pdf/NVVM_IR_Specification.pdf
[^test]: https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/test/CodeGen/NVPTX/tex-read-cuda.ll
[^bind]: See section 3.2.11.1.2 `Texture reference API in CUDA C Programming Guide.
[^texsurf]: According to NVVM IR, nvvm.texsurf.handle should be used. But, the current backend doesn't have that supported. We may revise that later.
This should be DeviceVarKind