davisking
interest in a oneDNN or SYCL GPU backend?
Main idea
An alternative to the CUDA-backend, for support for intel GPUs primarily but all GPUs (oneDNN has partial support for NVIDIA and AMD cards already if you compile it with the correct flags).
Presumably the task would be to introduce a new flag like DLIB_USE_ONEAPI and then every time #ifdef DLIB_USE_CUDA occurs write an equivalent implementation that calls oneDNN instead of cuDNN. Perhaps putting the oneAPI things into a new namespace rather than cuda.
You do seem to have some raw CUDA as well, which does make it more complex, since SYCL requires a custom compiler like AdaptiveCpp or Intel® oneAPI DPC++/C++ Compiler. Though the latter does seem to ship with oneAPI. There are tools to automatically translate CUDA into SYCL, so the CUDA parts might be easier than the cuDNN parts.
Anything else?
I am considering implementing a OneDNN/SYCL backend for dlib as a hobby project. I was wondering how interested dlib was in having such a feature. For example, if you would only accept it if I got it perfect, or if you would be interested in a partial implementations, or an implementations that still has some bugs (particularly in the build process), etc. .
I don't personally have a strong need for a non-cuda backend since I have NVIDIA graphics, but I am interested in learning these sorts of lower level tools and I care about weakening the NVIDIA's control over AI and future-proofing dlib.
It would have to be complete and have no bugs. Realistically though, it would complicate the code and build system to a level that I wouldn't want to merge it. Having to deal with cuda build systems is already a huge pain for dlib users. This kind of stuff you are talking about will be even more frustrating than the cuda SDK, which is pretty good as far as those things go.
This is a good point, and I will look for a different hobby project. Perhaps, if oneAPI actually becomes a wildly-used universal API, it could be worth it, but not currently.
Warning: this issue has been inactive for 35 days and will be automatically closed on 2025-07-21 if there is no further activity.
If you are waiting for a response but haven't received one it's possible your question is somehow inappropriate. E.g. it is off topic, you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's official compilation instructions, dlib's API documentation, or a Google search.
Warning: this issue has been inactive for 43 days and will be automatically closed on 2025-07-21 if there is no further activity.
If you are waiting for a response but haven't received one it's possible your question is somehow inappropriate. E.g. it is off topic, you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's official compilation instructions, dlib's API documentation, or a Google search.
Notice: this issue has been closed because it has been inactive for 45 days. You may reopen this issue if it has been closed in error.