[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Quick Poll: Debian to better support hardware acceleration?


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

Sorry for being more purist than pragmatic when dealing with Debian. As
a reminder:


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

Reply to: