On Sat, 18 Jan 2020 20:23:00 +0000
Mark Thompson <s...@jkqxz.net> wrote:
> > typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> > diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> > index 30611b1912..18abb87bbd 100644
> > --- a/libavutil/hwcontext_cuda.c
> > +++ b/libavutil/hwcontext_cuda.c
> > @@ -21,6 +21,9 @@
> > #include "hwcontext.h"
> > #include "hwcontext_internal.h"
> > #include "hwcontext_cuda_internal.h"
> > +#if CONFIG_VULKAN
> > +#include "hwcontext_vulkan.h"
> > +#endif
> > #include "cuda_check.h"
> > #include "mem.h"
> > #include "pixdesc.h"
> > @@ -42,6 +45,9 @@ static const enum AVPixelFormat
> > supported_formats[] = { AV_PIX_FMT_YUV444P16,
> > AV_PIX_FMT_0RGB32,
> > AV_PIX_FMT_0BGR32,
> > +#if CONFIG_VULKAN
> > + AV_PIX_FMT_VULKAN,
> > +#endif
>
> Do all devices we can do CUDA on also support Vulkan? If not, this
> should probably filter it out in get_constraints() to avoid exposing
> something which can't possibly work.
I don't have any hardware to test with, but I guess that in theory, we
do - sufficiently old hardware, with legacy driver branches will
support cuda and not vulkan, but it's unclear what we could do beyond
what we already have to handle that. If there's no vulkan support, then
we will not a vulkan device with a matching UUID and things will error
out at that stage. At the moment, the only mechanism I can think of to
detect lack of support is to do the UUID check, but somehow try and do
it early enough to affect the supported formats, which seems dubious to
me. So, it'll error out later than you really want, and possibly with a
slightly unclear message but it'll not do anything wrong.
--phil
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
