Hello, I'm not confortable in fostering proprietary solution like CUDA against libre alternative in Debian project. CUDA libraries are de-facto outdated when new Debian release comes out due to new hardware release and vendor lock-in business model. As a consequence, the user will always download the last libraries version from the vendor web-site. So, spending time pushing these libraries in the archive is pointless in my opinion. I would better spend time promoting free alternative or high level abstractions like OpenCL or SYSCL even if they are less performant. One day they will be better and Debian would be part of the success. Reminds me some Direct3D/OpenGL war some times ago. With this in mind, I also think that Debian should not prevent CUDA integration in scientific softwares, maybe by providing a simple way to rebuild or configure software to use CUDA libraries from the nVidia website. Sorry for being more purist than pragmatic when dealing with Debian. As a reminder: https://www.debian.org/intro/why_debian.en.html Best, François Le vendredi 21 mai 2021 à 04:40 +0000, M. Zhou a écrit : > Hi folks, > > --- > > Q: How far should Debian go along the way for supporting hardware > acceleration solutions like CUDA? > > Choice 1: this game belongs to the big companies. we should offload > such burden to third-party providers such as Anaconda. > Choice 2: we may try to provide what the users need. > Choice 3: <write down yours> > > --- > > As we know, hardware acceleration means a lot to scientific > computing, > and I believe a number of debian users use solutions like CUDA, ROCm, > or even SYCL. And the most prevalent solution seems to be CUDA. > Recall that anaconda might be one of the simplest ways to get the > cuda > version of tensorflow and pytorch, etc. So I just want to hear your > opinions on how far we should go along this direction. > > If we really want to go further, then a GPU server should be > available > in our infrastructure to facilitate development. Although license is > another considerable blocker, this can be discussed later. > > Thanks! >
Attachment:
signature.asc
Description: This is a digitally signed message part