Heads up that I'll soon be submitting a PR to help with cuda/cudnn version
checking. My goal is to address two points:
- rnn.cc of mxnet v1.5 does not compile against cudnn v6. Do we scramble
to fix it or admit that we no longer support cudnn v6 or earlier?
- how do we handle the
Just double checked CUDA 9, 10 and 10.1 all support SM3, so actually I
don't believe there's any need to drop SMs.
On Wed, Jun 19, 2019 at 9:56 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> I think where we're all going to have agreement is that we shouldn't have
> code targeting
I think where we're all going to have agreement is that we shouldn't have
code targeting CUDA versions earlier than CUDA 9, or cuDNN versions earlier
than 6. We can go ahead and remove any code that targets those old
versions, and drop any SMs that are not supported by CUDA 9 / cuDNN 6. Id
Good points anirudh. Generally I would understand N as being the major
versions. Speak we would maintain CUDA 9 and 10.1 in your given example and
drop 10.0 as soon as we verified that 10.1 is working. CUDA 9 would only be
dropped when 11 is released and tested.
At the same time, we would always
+1, Agree this should be done for both CUDA and CUDNN versions. At max CUDA
Version N and CUDA Version N - 1 should be supported in CI.
My question is what happens, when we are at a position, where we are on a
CUDA version N and removed support for CUDA version N - 1. Within a small
duration
Actually, I tried to say that support *doesn't necessarily* include N-1. I'm
proposing that the supported versions are 1) covered by CI and 2) have been
available in a usable form long enough that a semi-motivated user has been able
to transition to it. That might mean only N (e.g. per my
Your proposal of having support for N and N-1 makes a lot of sense to
me. Are there use cases for supporting older CUDA versions?
Thanks.
On Mon, Jun 3, 2019 at 3:06 PM Dick Carter wrote:
>
> I'd like to revisit the discussion of:
>
