Re: plan of deep learning team for next stable release?
Thanks for the quick reply.
On Wed, Nov 25, 2020 at 11:15:53AM +0900, Norbert Preining wrote:
> I remember there was some connection requests from Tensorflow devs
> searching for Debian devs ... did that get any followup from any side? I
> haven't seen anything.
Nothing new on my side, neither.
> Looking at https://www.khronos.org/sycl/ and the part on
> SYCL Implementations
> I am not really sure which way one would go? ComputeCpp?
There are many implementations of SYCL. I'd personally wait for Intel's
implementation to be merged into LLVM:
Nvidia focuses on CUDA, while AMD focuses on ROCm. As Intel is about to
sell its discrete graphics card, I think Intel will hold a serious
attitude towards the quality of their own implementation. Besides, well
you know, since it's a future component of LLVM, the corresponding
preparation works are actually offloaded to the llvm team ;-)
ComputeCpp may be one way to go but I'm afraid it will introduce
considerable extra workload for us to maintain a complete "toolchain",
and the volunteers may lack enough hardware resources to test.
> > ROCm gave us a bad impression through its documentations. And I think
> > we're out of man power to deal with it.
> I have worked to build packages for 3.9 and that did progress, but there
> are simply too many packages and not enough man power. Also, I don't see
> ROCm in a stage that it can be reasonably used for machine learning with
> GPU acceleration (unless through jump through several loops). I am
> following the github issues on these topics, and will try to bring the
> ROCm stack forward sooner or later, but this is **for**sure** not for
> this stable release (unless someone jumps forward and contributes lots
> of time and energy and knowledge).
Agreed. Given the limited time frame and man power before the release,
ROCm does not look like something for stable+1 at all.
> I just thought to add Julia here, which is not within debian-ai, but
> still somehow related. Here I am planning to ship the latest julia, and
> we are currently discussion about shipping two independent julia, one is
> julia-latest and one is julia-lts, but I am not sure that this will come
> to fruition before the freeze.
Indeed, Julia community is quite active in terms of developing machine
learning and deep learning libraries in place of the popular python
As for shipping julia-lts and julia-latest simultaneously, I doubt
whether it is necessary given the current popcon record? The embedded
openblas is also something remains to remove. (I still have no idea
why libopenblas64-julia does not work)