jhuber6 wrote: > Breaking any existing HIP feature is a no-go in my opinion. Textures and > surfaces are important to some developers.
Surfaces and textures are being phased out of CUDA as far as I can tell, so I wasn't sure how relevant it was (since we can use `--no-offload-new-driver` as a workaround for now) > I don't follow the connection to textures This codegen here, https://github.com/llvm/llvm-project/blob/7c729418d721147bf1f2b257afd30f84721888ad/clang/lib/CodeGen/CGCUDANV.cpp#L672. The new driver works by putting the information into a "runtime-array" of structs and then creating a single initialization function that loops over those structs. The problem with these calls is that they use way more arguments than currently fit in the struct definition. I could change the struct, but then it would break OpenMP. I could also just change the definition for HIP / CUDA, but ideally they all share the same method for registering things so we can interoperate. https://github.com/llvm/llvm-project/pull/123359 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
