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 7AB2D428F2 for ; Sun, 9 Jan 2022 21:15:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B67B468AE5D; Sun, 9 Jan 2022 23:15:37 +0200 (EET) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10olkn2021.outbound.protection.outlook.com [40.92.40.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AA957688324 for ; Sun, 9 Jan 2022 23:15:31 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Us2VhxsnScxyexnpKjKx7fdlELWH2bfsvfBtJwN/ehm7HigpWbwEw9pdTLPokxm3Tp1o/2D47esjbmDLpUT9Nt1l7vV1kzzpeTH1MVS+Y0PPfAOFRdsgXHxb1EM8Mo0nqKekoPsHb6t9o2n5pYL+w+SfV07PPIJRWNn3dvKbDP58T1c26PS0XyW2zRmy30XNJUth9PVAmqZ+lmBgGhoUbAD7/rIap6SYegeF4TKX6XH38nNjFkxUy9sXNdhhAee5Crby6UCGx8zHzk84QYpBl/SBe/Dkci6tz8plRFgI2j7H7qYXJbxwAQwZvPlZaGydsW47lVIcGnN+WiFCpIDuGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uvZh2q5UbtfTmJXlS61EL7ezO3SgMzmuOyKp0HqpP9g=; b=efnkEGiGpZoGBGr5a9n/0DDWuERDCX+BKojPKL/IKEQemm2oDoxY360Y1mSuMGXSU2qSQGrs56q/5Mq+shvSbBkXvYv/VMWPSPWJTkuqwKaPiNyWfbjBYkIMzkCAuq142OhFkvxzxY47/W72Yb2pSsS1uBmtVIAtN/zU1RBD3sSAUdQBxIIqArmPKn1/3dRR4kgpKylNSs4rYLnC3NU/9AHwdDz62O705MRc0g+M6enX7FyVvIC+4U+H4mblyScGi73c3OYyMnKvMhlfNKirK8fKj+JSps2LB/yq5j9DH1oMWYURM/mom0X8MDRVsfeakgRAwoQHlv+76iFMbxjf2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uvZh2q5UbtfTmJXlS61EL7ezO3SgMzmuOyKp0HqpP9g=; b=McjcDdk43JyxGObYUkJNqPoiDjWGwywVavUa1yoQugeX5DvWCriTQ+sn6ghYGOHiAOmSpmhEr2rD4r8wnMQMCKkMhbrFNQv5voLSKV04PsKuPGKNI2HhJSIr5KkJpYWEOf8CxkF3MzoAWqpgSh3QXEZK4oRJ27sroNUnmEReHbgdHbWbmCF9nX3pg680RzNyyNnNUf0jTNffy3yBKDX1645RUVQ0vtyj5lNoTEP1dZQRF1qtS+9t3KYD17uI1WDny3p6qNQ9mdkpoEA5yZL0NO9lla2tmrnx4elT2lL8cY5eiAHuYi0yE1gskwj8T1E1Cc7jQLOHMFWVrqByiI/gRQ== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by DM8P223MB0223.NAMP223.PROD.OUTLOOK.COM (2603:10b6:5:316::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Sun, 9 Jan 2022 21:15:28 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::54ae:66eb:e304:96d6]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::54ae:66eb:e304:96d6%8]) with mapi id 15.20.4867.011; Sun, 9 Jan 2022 21:15:28 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions Thread-Index: AQHX4hsaAmZdWHZNkEmQMqyBRUcuZKwV/XxngAAxZbGAAAJXAIAqFb0AgAWS1oCADigTgIAABTgAgAdFDYCAAA0iIA== Date: Sun, 9 Jan 2022 21:15:28 +0000 Message-ID: References: <163785839519.25323.16303122737288435026@lain.red.khirnov.net> <163794332023.25323.7446601680884381987@lain.red.khirnov.net> <163795393240.7822.9483345286843818669@lain.red.khirnov.net> <50841f8a73c902d3fca896b1eda923d082b27383.camel@intel.com> <6c1f517dad96d2d6075cb69a30e1a50aefd3feb9.camel@intel.com> <1379ae9c-d8f9-7e32-260f-eff79ac1cfd7@gmail.com> <6cc00dffb915619af857283b9fb503e7aaeeb603.camel@intel.com> <595cea3f-43d1-e1fb-8541-c620cfd47090@jkqxz.net> In-Reply-To: <595cea3f-43d1-e1fb-8541-c620cfd47090@jkqxz.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [yst5IOel6Gsx6iYW2BhOTG/Ok3xzIM/+] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6be30e4d-73e9-4fd9-e7c0-08d9d3b52964 x-ms-traffictypediagnostic: DM8P223MB0223:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +OE3nSzgIy+k+YFcIrxW5pB7xd1k75tnz6NX4jeVtc4gdkKRZYKQzkCF6JSfW6mCNBc8wmPm2jhGrUfB1awI0jV49CjdpsBbyLj24M58+UTK9jPqSyK3r8cLN2NRkU4GhdlrdSIw+RPutmCqc43P0HPxnzYem3D+XDJCWY/mI9jg3b+/2ovjSDbI2H5E7lGfSkPC8t0ggHQS5h4fd8rrsr0wEoG+mmGVNQwm++p334BacSXsqjhh+d990sG6I9hVpyy0Kh0xE/vChXgnWEgsMNXPKIQuTac0EjcT3W6lsrUpw9RLP4VFAqBXttID1vmnfD/Q8ytuD1gA3UIoIBE9y4yBDjN0NTy7tNsjzNHCtC7/eGqnOFLaJDbo5LQKqRVoPUiDRoktzv0msFZ+ya3XmPPpCKshUKKbzNQXTAARuUer5TmlgEnI8EXmMeFeu6gDf1iA1n+BRHxCkDduz5r1uToDo6ic1/D+jg+0mUZhG2D+kODZz/oYn3RYqaQZcGC4vyIto4jCJ0BQIXRD/5p/Nq2RJmI9gbYqEYoiGR8/cHDFKWXeoR0drApLp0crGlCKaBOs6l1ZQ5sCkz5pUbsOJg== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TkdsVWJhdEUya0pYTkhsZjJ4dVgyN3BxSVgxMUtQWFVEc1kxN2hBdEhmamF3?= =?utf-8?B?aDJvd09KaitWOFFadXdCZHhQNUQ5TGlrSnZYQTg5akMxTkxDbjJ0dE43L01L?= =?utf-8?B?TXFKU3VQTEFGVzNnTTJIVkMwN3J6ZlRRamxDTUt1cVduclJLUktOdTJBSVQ4?= =?utf-8?B?M0s5Tzd5U08xRlNsaG93WTN2c3p1NStFNXc5bmYyOWFaMC8wZnNhTStZUGk1?= =?utf-8?B?TENwMDEyNEVvQWM0Um1RRWxaU3dvQzJ4VGJnemdRWmd4YTJ6ZGtFVm5oaG5X?= =?utf-8?B?ZEtnWC85SDZ0RG1ENENQUnNnQWQvaXgvVVllWWMzaWxxMUp4UkZ5VkJlVm9X?= =?utf-8?B?bFNNTTF4TjhGVXNIc3VQNjFsbFVuOWNUaDExN1gzN2h3T2w0K0ZWRERNeFVE?= =?utf-8?B?YWF2bVBveUJ2WDc4VGJlZDM4ak1EMlpEYTZXRktvTUY5RS9raS9Lc0NPdXVE?= =?utf-8?B?aHIxNDlZbXIwUjhTa2ExY00vOW5YZC9UcDdhWUhvOHNDc0ozUE51czMzbEoz?= =?utf-8?B?ZURjRFN3VzYxTHFLbGFoaFVsM2xkUHZsblprWm54SWx2MjJXM29HdVFvTDJX?= =?utf-8?B?TUpVR0wycktwVlgzL2MzODVOWEwyT0F6aDlWV0RQQzVrNWF1WitrQk5BSmhX?= =?utf-8?B?a0Z5emNZcnB0bkExM1BtR21BaGttdzd5UWJtZHN6TEJQOWRCbmhWQ3E3V1pO?= =?utf-8?B?a1NWTi8vYlBkS1UzVnEzWjV1ajBBYm9iRWMrN1dIVkh2V25oMTQzMlFTSVQ0?= =?utf-8?B?R2pSbURla3NJWDBTSGlwKytDMDhQU3VBQ2l6Q0JsT0RRMHZkMTQvdTFEeVhj?= =?utf-8?B?Q2hURFUzT0RmYTJIcVp5Y2RwOCszS2JWeFhpaElxMU92MEpBZVRIRnpWWWdQ?= =?utf-8?B?SHBRYkg1dFhWOWdJNDB1QnltRG5mbnUwbEhhcU43alczeVJpdFB5d21XVG9S?= =?utf-8?B?VGh1ejZ6TExUdU9JWm56NnZ3L0tRbWpsbkhVNG9CK0ZsWGJ4aUdkbmN6Y0l6?= =?utf-8?B?RDZjRzBINEcvRkFPOWlCKzlVQ2k3cEhsYVNONXdOQnFGTUd1SVpIeXdMZ0di?= =?utf-8?B?NFkzQWFOU242V3hiNk1nYUZYTHBmYnY2UHcrVEYwNjlFSHBzK3c0a1U5RmQ3?= =?utf-8?B?ejdBTDg0c2VRNnp6VytoVHd1bDdYSmszd3FTWGliOW5vWHJMMHFHZDFOM3lY?= =?utf-8?B?Y2NjbjlpMFRuTGs4czBzZzVZZlQwelJadTBRWGpXK2NlSS8vdFdHUHlEclNv?= =?utf-8?B?cVdTUytja09VZ0tNcy9hemVQRUZEajhwSHJtZkhHY2RmMmFPQT09?= MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-1ff67.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6be30e4d-73e9-4fd9-e7c0-08d9d3b52964 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2022 21:15:28.6031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P223MB0223 Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions 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: > -----Original Message----- > From: ffmpeg-devel On Behalf Of Mark > Thompson > Sent: Sunday, January 9, 2022 7:39 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a > hwdevice, search for existing device in both directions > > On 05/01/2022 03:38, Xiang, Haihao wrote: > > ... this patch really fixed some issues for me and others. > > Can you explain this in more detail? > > I'd like to understand whether the issues you refer to are something which > would be fixed by the ffmpeg utility allowing selection of devices for > libavfilter, or whether they are something unrelated. > > (For library users the currently-supported way of getting the same device > again is to keep a reference to the device and reuse it. If there is some > case where you can't do that then it would be useful to hear about it.) Hi Mark, they have 3 workaround patches on their staging repo, but I'll let Haihao answer in detail. I have another question. I've been searching high and low, yet I can't find the message. Do you remember that patch discussion from (quite a few) months ago, where it was about another QSV change (something about device creation from the command line, IIRC). There was a command line example with QSV and you correctly remarked something like: "Do you even know that just for this command line, there are 5 device creations happening in the background, implicit and explicit, and in one case (or 2), it's not even creating the specified device but a session for the default device instead" (just roughly from memory) Do you remember - or was it Philip? Anyway, this is something that the patch will improve. There has been one other commit since that time regarding explicit device creation from Haihao (iirc), which already reduced the device creation and fixed the incorrect default session creation. My patch tackles this from another side: at that time, you (or Philip) explained that the secondary context that QSV requires (VAAPI, D3Dx) and that is initially created when setting up the QSV device, does not even get used when subsequently deriving to a context of that kind. Instead, a new device is being created in this case. That's another scenario which is fixed by this patch. It's a hybrid device context, that's the reason why QSV is more affected than all other hwaccels as it consists of a QSV session already DERIVED from a VAAPI or D3Dx device. Example (let's assume Windows with D3D9): You go into decoding with a QSV decoder in a QSV context and then you want to use an OpenCL filter. This requires an OpenCL context, and of course you want to share the frames memory. For memory sharing, OpenCL requires the underlying context of the QSV session - in this example D3D9. Before this patch - like you said - deriving devices was usually (except reverse hwmap) forward-only. That means - you are stuck in this situation: you could (forward-)derive to a D3D9 context, but that doesn't help: for sharing the memory, you need to provide the original hw device to OpenCL, you can't supply just another newly derived device of the same type. And there is (was) no way to get the original hw context. Anyway I'm wondering whether it can even be logically valid to derive from one device to another and then to another instance of the previous device type. >From my understanding, "deriving" or "hw mapping" from one device to another means to establish a different way or accessor to a common resource/data, which means that you can access the data in one or the other way. Now let's assume a forward device-derivation chain like this: D3D_1 >> OpenCL_1 >> D3D_2 We have D3D surfaces, then we share them with OpenCL. Both *_1 contexts provide access to the same data. Then we derive again "forward only" and we get a new D3D_2 context. It is derived from OpenCL_1, so it must provide access to the same data as OpenCL_1 AND D3D_1. Now we have two different D3D contexts which are supposed to provide access to the same data! 1. This doesn't even work technically - neither from D3D (iirc) - nor from ffmpeg (not cleanly) 2. This doesn't make sense at all. There should always be only a single device context of a device type for the same resource 3. Why would somebody even want this - what kind of use case? Regards, softworkz _______________________________________________ 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".