| Message ID | 20231001020628.2768-1-jamrial@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent() | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On 9/30/2023 11:06 PM, James Almer wrote: > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > > Signed-off-by: James Almer <jamrial@gmail.com> > --- > libavutil/hwcontext_cuda.c | 4 ++++ > libavutil/hwcontext_cuda_internal.h | 9 +++++++++ > 2 files changed, 13 insertions(+) > > diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c > index 0312d3b9d7..4f55f6441d 100644 > --- a/libavutil/hwcontext_cuda.c > +++ b/libavutil/hwcontext_cuda.c > @@ -362,10 +362,14 @@ static int cuda_context_init(AVHWDeviceContext *device_ctx, int flags) { > if (ret < 0) > return ret; > } else if (flags & AV_CUDA_USE_CURRENT_CONTEXT) { > +#if NVDECAPI_CHECK_VERSION(12, 1) Actually no, this check is not enough as cuCtxGetCurrent() was added to ffnvcodec headers after the version bump to 12.1 Either we leave things as is and expect to get people to update their headers until a new SDK version is released, its changes merged and version bumped, or revert the implementation bits of 05f8b2ca0f, leaving only the API in place. AVERROR(ENOSYS) would then be returned any time AV_CUDA_USE_CURRENT_CONTEXT is requested regardless of what headers are present at compile time. > ret = CHECK_CU(cu->cuCtxGetCurrent(&hwctx->cuda_ctx)); > if (ret < 0) > return ret; > av_log(device_ctx, AV_LOG_INFO, "Using current CUDA context.\n"); > +#else > + return AVERROR(ENOSYS); > +#endif > } else { > ret = CHECK_CU(cu->cuCtxCreate(&hwctx->cuda_ctx, desired_flags, > hwctx->internal->cuda_device)); > diff --git a/libavutil/hwcontext_cuda_internal.h b/libavutil/hwcontext_cuda_internal.h > index d5633c58d5..fe0963b4e5 100644 > --- a/libavutil/hwcontext_cuda_internal.h > +++ b/libavutil/hwcontext_cuda_internal.h > @@ -28,6 +28,15 @@ > * FFmpeg internal API for CUDA. > */ > > +#if defined(NVDECAPI_MAJOR_VERSION) && defined(NVDECAPI_MINOR_VERSION) > +# define NVDECAPI_CHECK_VERSION(major, minor) \ > + ((major) < NVDECAPI_MAJOR_VERSION || ((major) == NVDECAPI_MAJOR_VERSION && (minor) <= NVDECAPI_MINOR_VERSION)) > +#else > +/* version macros were added in SDK 8.1 ffnvcodec */ > +# define NVDECAPI_CHECK_VERSION(major, minor) \ > + ((major) < 8 || ((major) == 8 && (minor) <= 0)) > +#endif > + > struct AVCUDADeviceContextInternal { > CudaFunctions *cuda_dl; > int is_allocated;
On 01.10.2023 04:06, James Almer wrote: > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 It's expected behaviour to break compilation with random inter-release versions of ffnvcodec. It's only reliable exactly on release versions. I had planned to draw a release of the headers right after, but then my PC started to eat files for a yet unknown reason, and I need to figure that out first. A workaround for this would be to check for the existence of cuCtxGetCurrent in configure. But there were multiple instances of this exact thing in the past, and everyone agreed that it's just expected behaviour with development versions of both parts. > Signed-off-by: James Almer <jamrial@gmail.com> > --- > libavutil/hwcontext_cuda.c | 4 ++++ > libavutil/hwcontext_cuda_internal.h | 9 +++++++++ > 2 files changed, 13 insertions(+) > > diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c > index 0312d3b9d7..4f55f6441d 100644 > --- a/libavutil/hwcontext_cuda.c > +++ b/libavutil/hwcontext_cuda.c > @@ -362,10 +362,14 @@ static int cuda_context_init(AVHWDeviceContext *device_ctx, int flags) { > if (ret < 0) > return ret; > } else if (flags & AV_CUDA_USE_CURRENT_CONTEXT) { > +#if NVDECAPI_CHECK_VERSION(12, 1) > ret = CHECK_CU(cu->cuCtxGetCurrent(&hwctx->cuda_ctx)); > if (ret < 0) > return ret; > av_log(device_ctx, AV_LOG_INFO, "Using current CUDA context.\n"); > +#else > + return AVERROR(ENOSYS); > +#endif > } else { > ret = CHECK_CU(cu->cuCtxCreate(&hwctx->cuda_ctx, desired_flags, > hwctx->internal->cuda_device)); > diff --git a/libavutil/hwcontext_cuda_internal.h b/libavutil/hwcontext_cuda_internal.h > index d5633c58d5..fe0963b4e5 100644 > --- a/libavutil/hwcontext_cuda_internal.h > +++ b/libavutil/hwcontext_cuda_internal.h > @@ -28,6 +28,15 @@ > * FFmpeg internal API for CUDA. > */ > > +#if defined(NVDECAPI_MAJOR_VERSION) && defined(NVDECAPI_MINOR_VERSION) > +# define NVDECAPI_CHECK_VERSION(major, minor) \ > + ((major) < NVDECAPI_MAJOR_VERSION || ((major) == NVDECAPI_MAJOR_VERSION && (minor) <= NVDECAPI_MINOR_VERSION)) > +#else > +/* version macros were added in SDK 8.1 ffnvcodec */ > +# define NVDECAPI_CHECK_VERSION(major, minor) \ > + ((major) < 8 || ((major) == 8 && (minor) <= 0)) > +#endif > + > struct AVCUDADeviceContextInternal { > CudaFunctions *cuda_dl; > int is_allocated;
On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: > > On 01.10.2023 04:06, James Almer wrote: > > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > > It's expected behaviour to break compilation with random inter-release > versions of ffnvcodec. > It's only reliable exactly on release versions. > But isn't the point that there is no release version of ffnvcodec that I can use to build this? And that it has no check to limit building it, and will always fail with release versions? - Hendrik
On 06/10/2023 14:29, Hendrik Leppkes wrote: > On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: >> >> On 01.10.2023 04:06, James Almer wrote: >>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 >> >> It's expected behaviour to break compilation with random inter-release >> versions of ffnvcodec. >> It's only reliable exactly on release versions. >> > > But isn't the point that there is no release version of ffnvcodec that > I can use to build this? > And that it has no check to limit building it, and will always fail > with release versions? I don't understand what you mean. Right now, it only works with nv-codec-headers master. I will make a new release there very soon.
On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: > > On 06/10/2023 14:29, Hendrik Leppkes wrote: > > On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: > >> > >> On 01.10.2023 04:06, James Almer wrote: > >>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > >> > >> It's expected behaviour to break compilation with random inter-release > >> versions of ffnvcodec. > >> It's only reliable exactly on release versions. > >> > > > > But isn't the point that there is no release version of ffnvcodec that > > I can use to build this? > > And that it has no check to limit building it, and will always fail > > with release versions? > > I don't understand what you mean. > Right now, it only works with nv-codec-headers master. > I will make a new release there very soon. You say that its expected to break with inter-release versions of ffnvcodec, but this is the opposite, it breaks with the release version and works with git versions. So I'm not sure I understand what you are saying. Requiring a non-released version of a dependency was obviously a gigantic oversight with the original patch, and as a result master is currently broken for any reasonable setup avoiding those "inter-release versions". - Hendrik
On 06/10/2023 15:31, Hendrik Leppkes wrote: > On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: >> >> On 06/10/2023 14:29, Hendrik Leppkes wrote: >>> On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: >>>> >>>> On 01.10.2023 04:06, James Almer wrote: >>>>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 >>>> >>>> It's expected behaviour to break compilation with random inter-release >>>> versions of ffnvcodec. >>>> It's only reliable exactly on release versions. >>>> >>> >>> But isn't the point that there is no release version of ffnvcodec that >>> I can use to build this? >>> And that it has no check to limit building it, and will always fail >>> with release versions? >> >> I don't understand what you mean. >> Right now, it only works with nv-codec-headers master. >> I will make a new release there very soon. > > You say that its expected to break with inter-release versions of > ffnvcodec, but this is the opposite, it breaks with the release > version and works with git versions. So I'm not sure I understand what > you are saying. No, with any old release version, configure correctly refuses to use them. It's only broken with master versions after the last release, up to the patch that added the function. > Requiring a non-released version of a dependency was obviously a > gigantic oversight with the original patch, and as a result master is > currently broken for any reasonable setup avoiding those > "inter-release versions". master temporarily requiring a development-version of the headers wasn't an oversight, that was the intended outcome of the update, and was done exactly in that fashion many times before. I'm quite confused why this specific instance suddenly causes so much upset.
On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
> I'm quite confused why this specific instance suddenly causes so much upset.
Because its bad form to break compilation of master, if all it took to
avoid that is change the order of pushing a tag to one repo and a
patch to another.
- Hendrik
On 06.10.2023 18:43, Hendrik Leppkes wrote: > On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler <timo@rothenpieler.org> wrote: >> I'm quite confused why this specific instance suddenly causes so much upset. > > Because its bad form to break compilation of master, if all it took to > avoid that is change the order of pushing a tag to one repo and a > patch to another. > I think you are misunderstanding the versioning of the headers? They were already on the right version, all you needed to do was update them. There was never a time where it was impossible to build ffmpeg.
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c index 0312d3b9d7..4f55f6441d 100644 --- a/libavutil/hwcontext_cuda.c +++ b/libavutil/hwcontext_cuda.c @@ -362,10 +362,14 @@ static int cuda_context_init(AVHWDeviceContext *device_ctx, int flags) { if (ret < 0) return ret; } else if (flags & AV_CUDA_USE_CURRENT_CONTEXT) { +#if NVDECAPI_CHECK_VERSION(12, 1) ret = CHECK_CU(cu->cuCtxGetCurrent(&hwctx->cuda_ctx)); if (ret < 0) return ret; av_log(device_ctx, AV_LOG_INFO, "Using current CUDA context.\n"); +#else + return AVERROR(ENOSYS); +#endif } else { ret = CHECK_CU(cu->cuCtxCreate(&hwctx->cuda_ctx, desired_flags, hwctx->internal->cuda_device)); diff --git a/libavutil/hwcontext_cuda_internal.h b/libavutil/hwcontext_cuda_internal.h index d5633c58d5..fe0963b4e5 100644 --- a/libavutil/hwcontext_cuda_internal.h +++ b/libavutil/hwcontext_cuda_internal.h @@ -28,6 +28,15 @@ * FFmpeg internal API for CUDA. */ +#if defined(NVDECAPI_MAJOR_VERSION) && defined(NVDECAPI_MINOR_VERSION) +# define NVDECAPI_CHECK_VERSION(major, minor) \ + ((major) < NVDECAPI_MAJOR_VERSION || ((major) == NVDECAPI_MAJOR_VERSION && (minor) <= NVDECAPI_MINOR_VERSION)) +#else +/* version macros were added in SDK 8.1 ffnvcodec */ +# define NVDECAPI_CHECK_VERSION(major, minor) \ + ((major) < 8 || ((major) == 8 && (minor) <= 0)) +#endif + struct AVCUDADeviceContextInternal { CudaFunctions *cuda_dl; int is_allocated;
Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 Signed-off-by: James Almer <jamrial@gmail.com> --- libavutil/hwcontext_cuda.c | 4 ++++ libavutil/hwcontext_cuda_internal.h | 9 +++++++++ 2 files changed, 13 insertions(+)