From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7A6E94099B for ; Mon, 4 Apr 2022 09:47:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7CCE668B015; Mon, 4 Apr 2022 12:47:10 +0300 (EEST) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E229568AE7C for ; Mon, 4 Apr 2022 12:47:03 +0300 (EEST) Received: by mail-yb1-f181.google.com with SMTP id g9so6898214ybj.9 for ; Mon, 04 Apr 2022 02:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=S2yEG2UHRcXCj09U+uu8uAbUKqyuaB8GNM6LhPrNHhE=; b=pSU8M0j38I47I+/7zlkfcpX03NpnnJZTyAwlSzW+IzGQJl/zig49dmx0i0zfuJFWcX Rj4jS0VhMKI5EeOn51POUkHYa3h6F2LI2GsKe5FubVcdk2iZO8slw9UTA4dresj0S2fE fq/vMQekxDX3HpV+E/KofNV/mMwpHPst6d7QVoSyI0Bf9tIhTGk+QlswvRkvnW76JV4R hjy5Nv3f+w9kEeRxdeRInaoM1gm9FL9BDhlBvUUiCRVZywfuJA7S+was1/Cef0Y/Xyki aj2NdYRW2L2WUhi2z4AQ+7p1RRHL81C5a42GkgB7kfzSiHTZ7hBQHyHhF36s48egjsyr BPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=S2yEG2UHRcXCj09U+uu8uAbUKqyuaB8GNM6LhPrNHhE=; b=E/l+NK7UzCQBADIPw4PWnZ+r3edUE0tVwk75LCCYk+1oE2kGsa8XcliwUPAG9vNX5x Cekif9Zm0h3oYUJX/zU9rKTvRT7LHHoyxhGortQDcj+a3elUzD1G7agi0ZDGcArCbW8u whaBCC3kvDSXKVaG8M6B5rE3Ww860K30VKDnjTzoSRG9Qjz3dSnsu0CcNg2oCv3ZgA2w isvVbRjdcDWALF6KsON6dACDIDuFRg3EmMLe6eaytZRdWaeT71n2Fb/J5sBmZLYTxvb6 zBw2qWO3PrHctiNaH5OlG7IPeLgkbTi2BObkl5r8quAksfnQpnBjfULEC+Mn8JZnKzvK w9Uw== X-Gm-Message-State: AOAM533rdssM0/xsVB7J3CnSkvyrnttcytHOlY5RakIXaEPHF/j6O/RN ijXvJpUwqeAVlMshITaNTfwPdMSyveXY2+ovqs99jLWglyg= X-Google-Smtp-Source: ABdhPJx6UzijRiJo969bvdq4LaAmvFTJBOmVdWLPflIuZMwNx8lna/0ZsfQacP3fmQ/ITgHmovMsEJPCiuxIadOlaxU= X-Received: by 2002:a05:6902:1149:b0:63d:b4e8:e274 with SMTP id p9-20020a056902114900b0063db4e8e274mr5387987ybu.507.1649065621564; Mon, 04 Apr 2022 02:47:01 -0700 (PDT) MIME-Version: 1.0 References: <20220311081630.21927-1-haihao.xiang@intel.com> <20220311081630.21927-10-haihao.xiang@intel.com> <1202f7ddc68d529bd517aeeb4190bacd9783db79.camel@intel.com> <08febe49f865cc957dbdcb7bddadd6ecb2e0b414.camel@intel.com> In-Reply-To: <08febe49f865cc957dbdcb7bddadd6ecb2e0b414.camel@intel.com> From: Hendrik Leppkes Date: Mon, 4 Apr 2022 11:46:48 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v7 09/10] qsv: use a new method to create mfx session when using oneVPL X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, Mar 15, 2022 at 8:24 AM Xiang, Haihao wrote: > > On Fri, 2022-03-11 at 15:00 +0100, Hendrik Leppkes wrote: > > On Fri, Mar 11, 2022 at 2:43 PM Xiang, Haihao > > wrote: > > > > > > On Fri, 2022-03-11 at 09:35 +0100, Hendrik Leppkes wrote: > > > > On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao > > > > wrote: > > > > > diff --git a/libavutil/hwcontext_d3d11va.c > > > > > b/libavutil/hwcontext_d3d11va.c > > > > > index 8ab96bad25..e0e820f164 100644 > > > > > --- a/libavutil/hwcontext_d3d11va.c > > > > > +++ b/libavutil/hwcontext_d3d11va.c > > > > > @@ -525,6 +525,13 @@ static void d3d11va_device_uninit(AVHWDeviceContext > > > > > *hwdev) > > > > > } > > > > > } > > > > > > > > > > +static void d3d11va_device_free(AVHWDeviceContext *ctx) > > > > > +{ > > > > > + AVD3D11VADeviceContext *hwctx = ctx->hwctx; > > > > > + > > > > > + av_free(hwctx->device_name); > > > > > +} > > > > > + > > > > > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char > > > > > *device, > > > > > AVDictionary *opts, int flags) > > > > > { > > > > > @@ -537,6 +544,8 @@ static int d3d11va_device_create(AVHWDeviceContext > > > > > *ctx, > > > > > const char *device, > > > > > int is_debug = !!av_dict_get(opts, "debug", NULL, 0); > > > > > int ret; > > > > > > > > > > + ctx->free = d3d11va_device_free; > > > > > + > > > > > // (On UWP we can't check this.) > > > > > #if !HAVE_UWP > > > > > if (!LoadLibrary("d3d11_1sdklayers.dll")) > > > > > @@ -561,6 +570,10 @@ static int d3d11va_device_create(AVHWDeviceContext > > > > > *ctx, const char *device, > > > > > if (FAILED(IDXGIFactory2_EnumAdapters(pDXGIFactory, > > > > > adapter, > > > > > &pAdapter))) > > > > > pAdapter = NULL; > > > > > IDXGIFactory2_Release(pDXGIFactory); > > > > > + > > > > > + device_hwctx->device_name = av_strdup(device); > > > > > + if (!device_hwctx->device_name) > > > > > + return AVERROR(ENOMEM); > > > > > } > > > > > } > > > > > > > > > > diff --git a/libavutil/hwcontext_d3d11va.h > > > > > b/libavutil/hwcontext_d3d11va.h > > > > > index 77d2d72f1b..41a315b9e6 100644 > > > > > --- a/libavutil/hwcontext_d3d11va.h > > > > > +++ b/libavutil/hwcontext_d3d11va.h > > > > > @@ -94,6 +94,11 @@ typedef struct AVD3D11VADeviceContext { > > > > > void (*lock)(void *lock_ctx); > > > > > void (*unlock)(void *lock_ctx); > > > > > void *lock_ctx; > > > > > + > > > > > + /** > > > > > + * The string for the used adapter > > > > > + */ > > > > > + char *device_name; > > > > > } AVD3D11VADeviceContext; > > > > > > > > > > /** > > > > > diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c > > > > > index 53d00fa815..6967357093 100644 > > > > > --- a/libavutil/hwcontext_dxva2.c > > > > > +++ b/libavutil/hwcontext_dxva2.c > > > > > @@ -431,6 +431,7 @@ static void dxva2_device_free(AVHWDeviceContext > > > > > *ctx) > > > > > dlclose(priv->dxva2lib); > > > > > > > > > > av_freep(&ctx->user_opaque); > > > > > + av_free(hwctx->device_name); > > > > > } > > > > > > > > > > static int dxva2_device_create9(AVHWDeviceContext *ctx, UINT adapter) > > > > > @@ -571,6 +572,13 @@ static int dxva2_device_create(AVHWDeviceContext > > > > > *ctx, > > > > > const char *device, > > > > > return AVERROR_UNKNOWN; > > > > > } > > > > > > > > > > + if (device) { > > > > > + hwctx->device_name = av_strdup(device); > > > > > + > > > > > + if (!hwctx->device_name) > > > > > + return AVERROR(ENOMEM); > > > > > + } > > > > > + > > > > > return 0; > > > > > } > > > > > > > > > > diff --git a/libavutil/hwcontext_dxva2.h b/libavutil/hwcontext_dxva2.h > > > > > index e1b79bc0de..253ddbed51 100644 > > > > > --- a/libavutil/hwcontext_dxva2.h > > > > > +++ b/libavutil/hwcontext_dxva2.h > > > > > @@ -38,6 +38,10 @@ > > > > > */ > > > > > typedef struct AVDXVA2DeviceContext { > > > > > IDirect3DDeviceManager9 *devmgr; > > > > > + /** > > > > > + * The string for the used adapter > > > > > + */ > > > > > + char *device_name; > > > > > } AVDXVA2DeviceContext; > > > > > > > > > > /** > > > > > > > > Why are these device names required? I would think deriving a child > > > > device would use the actual device, eg. ID3D11Device or > > > > IDirect3DDeviceManager9 (and whatever for VAAPI), and not some string > > > > (that may or may not even be set). > > > > It feels quite a bit icky to store these in the context just for qsv > > > > to do... what with? > > > > > > Yes, it is a little ugly here. MediaSDK or oneVPL application creates mfx > > > session and the device (dxva2, d3d11va or vaapi), then pass this device to > > > the > > > SDK through MFXVideoCORE_SetHandle(). implementation is introduced in oneVPL > > > ( > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/API_ref/VPL_disp_api_struct.html#structmfx_impl_description > > > ) and user must select an available implementation before the creation of > > > mfx > > > session, however the device handle is unknown in the SDK when selecting an > > > available implementation, the SDK provides a method to select implementation > > > via > > > the given adapter (on Windows) or DRI device node (on Linux). The default > > > implementation will be selected if child device name is unknown. > > > > > > > First of all, whoever made that API should get a stern message. > > Expecting to properly interoperate with the dominant platform APIs > > should be a primary goal, and it sounds like it was somehow shoehorned > > in after the fact. > > > > For D3D11 for example, you can get the IDXGIAdapter a device was > > created from, isn't there enough information in there to pass-on > > without storing a string field? > > IDXGIAdapter::GetDesc has tons of identification information to > > identify the device in use. > > > > D3D9 probably has something similar, haven't checked right now. > > > Thanks for the info, I may get AdapterLuid from the adapter description, however > the required parameter in oneVPL is the index of the adapter, is there a way to > map AdapterLuid to adapter index ? (Sorry for this dumb question) > > There is `IDirect3DDeviceManager9 *devmgr` only in AVDXVA2DeviceContext for > D3D9, it seems we have to add other members to get adapter description. > > As for vaapi, there is no API to get the used DRI device from VADisplay handle, > we have to store this info in AVVAAPIDeviceContext, and I prefer using the same > way for d3d9 & d3d11va too. > I'm not sure about VAAPI, but not storing a string just for this one purpose seems like a win to me. What values would mfxImplDescription.mfxDeviceDescription.device.DeviceID contain, and would that perhaps match something in the D3D11 or DXVA2 device description? You already have big alternate pathes inside those functions for windows or vaapi, so that doesn't seem like a big step to handle separately. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".