I just switched to CUDA Toolkit 11.3 (from Toolkit 9.1) and see a lot of deprecation warnings when compiling our .cu files.
It seems that cudaBindTexture2D and a whole lot of other texture-management functions (existing before texture objects came up) are marked as DEPRECATED.
See CUDA Runtime API :: CUDA Toolkit Documentation
That is a real pity if these functions would be missing in a next CUDA toolkit release, because we have a large codebase (with some thirdparty-code, not really documented well) where we would have to port all these functions to ‘texture objects’.
If NVIDIA really discards all these legacy texture management functions in an upcoming CUDA Toolkit release, it would be good if they could provide a header file with an ‘emulation’ C++ class (which internally uses texture objects) and C++ functions, with its interface identical to the legacy texture management functions.
Texture references have been deprecated since CUDA 10.1 (February 2019). Texture objects were introduced with CUDA 5.0 (October 2012), and I am reasonably sure that since then NVIDIA has consistently advocated that CUDA programmers ditch texture references in favor of texture objects (which are technically superior as I recall, not having used any textures for half a dozen years now).
You could of course file a feature request with NVIDIA for an emulation C++ class for texture references. My guess would be that this runs counter to NVIDIA’s interests of saving the work of maintaining outdated interfaces. If they wanted to do that work, they could have just retained the old interfaces indefinitely instead of marking them deprecated.
Unless there is an urgent need to switch to future CUDA versions, you could just stay with CUDA 11.3 for an extended period of time until you can get around to transitioning your code base to use texture objects.
Well, actually it would be fine if they just retained the outdated interface, but I can understand the need to cleanup the CUDA API from time to time.
The issue is with some CUDA source code written by thirdparty contributors, which we compile and use. These thirdparty contributors are not available anymore to change the code. So I would have to change this code (which I do not understand, it’s a complicated variational optical flow algorithm),
Staying with a certain CUDA toolkit is an option, but not for the long term. One has to update from time to time to newest CUDA toolkit & CUDNN. Just recently, I had to update from CUDNN 7 & Toolkit 9.1 to CUDNN 8.2 & Toolkit 11.3, because our object detector would not run on a new Ampere GPU (RTX A4000).
just out of curiosity, how would you emulate the global scope characteristic of a texture reference?
I would have to reshuffle the code a bit so that all code using this texture reference is in the same .cu file.
And the texture reference would be ‘emulated’ by a templatized C++ class, I suppose.
It’s just a thought, and I think ‘emulating’ the legacy functions via a combination of C++ classes and functions is doable.
It’s not at all obvious to me that there is a mechanism by which a templatized C++ class (or any other plausible entity) could be usable in CUDA device code without that class appearing in any way in the kernel parameters. CUDA allows only very limited types of data declared at global scope to be usable in device code.
My initial read is that code refactoring is inevitable to some degree. An emulation layer that does only a partial job simply becomes a new API to be debugged and maintained. The previous API cannot be a perfect spec or definition of the emulation API (I suspect). There is already a debugged and maintained replacement API - texture objects.
In any event, for any sort of serious consideration, I would suggest filing a bug (enhancement request). The more you could provide in the way of a fleshed out example of something that is viable using CUDA C++, the more likely it would get meaningful consideration.
Alright, thanks. I will think about how to flesh out / make that usable such sort of emulation, and possibly discuss with P. Kirst.