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 4BDF440DA5 for ; Thu, 30 Dec 2021 19:20:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AC1EE68AE64; Thu, 30 Dec 2021 21:20:51 +0200 (EET) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12olkn2072.outbound.protection.outlook.com [40.92.23.72]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 14B1568A7C0 for ; Thu, 30 Dec 2021 21:20:45 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=notntx/fl0sRntwu7Kp8kG4sL+5dm0g2UVTJ0spCGv/rwcNDNhcnZGBCIFEM/rNUYfJuR66QQhZq7AqbsJpuIcN9RtZnXEOn7+khJNr5/cc6ecbUxl8ezHJSVO6h35adxmwPkvpwMRZzQbXBSI50/hIALkn2iJla36+jCOIitwWC1kkCo15GSoxAJ9RSLvSR856ObMcmZ0YHgkokcY80wNlbgSwjd2P/t8sb4n9Dv/cIzVD8Liz/DNSNFxMgvEC27Kwwp17iGzf9vQYGBtMlK1YtdEjTsZoDQt85c5wlKtWehKOeYsEr+qhTvHrFWOGSAD8BNxf8wo+XxrXRwPopMg== 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=f2RaKMXWMbiebc+sCBGO7aaQF4EzkDZ+YJmTnDvQVc0=; b=jI3eGqrwf2LY0ifG4x71Taw3Ip4e88eTtnFTj7dxvr6CBCE4uN9QFSREnMg/oMeuwl5J7zDpATqsLPn8SzjdVpWbv8L5bafcDyItkUa+YwSxGRosJA341CPpDNDCuIFFGXNtH1VtM25jlQ7pIQSpdhezw5wRl6uuqxPpPyiOYkS/1XszWD31uFD4vte0NnB4vWbCBA15m5bQDH1ELWPBbePI3yCgCDvwD/8cYiuk6IJbqzqCGgV1to6dSDhJ3mkzLeTBItyHdNy2cctbK59vqS4fKwUAVJsHYFnVYP9JQiinITLzsTAnVXjHK/O5JvKyra9X6r8P5ygjoWH0OKh/GA== 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=f2RaKMXWMbiebc+sCBGO7aaQF4EzkDZ+YJmTnDvQVc0=; b=fTJuRmsCFNoavWymfFik1sb8fpy3yEKQTkMHSkST24DMH64MOXozye0Geyoe2MUuWuDe+yILmKcze18BRqKZu3lNLL8u5x39wIbHW6a5mHf9QxVlXCg5bMLnET2eCrWODlkzeWvJ0Cbyd1F69bSFS2kyv06StUA5Q687Cyjjh5WfmRSpaeB3XOrFVqUjCWUd3O6qEt9zuBKh/ACWqTDtOBdBqOh8/mbFLQar580ULzVwRzOwqSdSKiWCj4gvWHiixHJqGp8vHCdks+h97/rwjM2Luiz4jr7Rh1pbtAwTyMHYjLSiTnx7TpW1viDsRgJozCFa+Z3Vw/93SNpCNQUDrA== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by DM8P223MB0381.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.13; Thu, 30 Dec 2021 19:20:42 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::54ae:66eb:e304:96d6]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::54ae:66eb:e304:96d6%5]) with mapi id 15.20.4844.014; Thu, 30 Dec 2021 19:20:42 +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: AQGnQV+GaP/9mUjFEoNhMBDgx+itSwJHT6uBrJlTkwCAAAIsQIAAy+GAgAB9bSA= Date: Thu, 30 Dec 2021 19:20:42 +0000 Message-ID: References: <0d168258-b2d3-f60e-87af-28b01e809038@jkqxz.net> <10c6a99f-9fa4-012c-66a2-7df163daeade@jkqxz.net> In-Reply-To: <10c6a99f-9fa4-012c-66a2-7df163daeade@jkqxz.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [aVDhKoRZZBD6gr4tyG8dW2E2tOB5k5ls] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d359a8b-2cc7-45b3-4c89-08d9cbc978ea x-ms-traffictypediagnostic: DM8P223MB0381:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1VMa4bIuVz3u654S/C8Hm1UHmY1foijGI8EgIFbgOnR4nRlcocbfiJYBnGuEZkOyREbn3mTcEwZsoe6N0YivkQVg3aEZZ+KmLURvBrvqAdUX0fQ8trdaZl0FnUhsxHEQEFsS04vFf9esFgCfoSXVUUP08CXzsMY7D2joHBJ/qvibVs686miIVl7dJLymfeAn/n7+uJnQ/hKeSVLqKn6X2saGJsGap80STS3uXTsy9OchfkKsiG0ndneTboewdL8k4En64Awv35jc3S9Y+N/vbMWzHYtgRSYBCW2Z5Xv1gpRbA8UIRVQnpPXdAEA7DZZfN7FZnmRnzQ+XIB6xWTSMnPKw37zb7Sbnzamg0rcODdhHRQ5hxl/o4KNUyrW+gkxpOUoE3IZBzm7pkY1XQpgCRb5gjYnImdtMbwNI6DH4G++tN9CpF1l2AuZZ7zol1+8eSTsU7bNBY2yWRfoK8jSjUGlfRNR3h/U4EOiTHRW/ihZVu0EoxRI8SU0zAU1w7odad2GejHAeBSzRJflsNQlpQBRXu87hKIoJgKLU0wiOFxK3Zo/pYdT2Rrsjfa1iK3I0HNdQhu1D8A9O2p99tC+sGg== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: KmnfuRxWlWTW9d445Hdz5PvNrB6Nij5XRzC7ZALZK2PPwzlhIoKEZwWp5iqMYGiPna/hJFYuCpCDD4rATyFetzkLZuiny3VOu+tA8PuKgJKoo4ycSBPZuz+eXWKP1Cx5ql7rvi4SeU/3Zvj35bhJJW14WRdd2rcur4yFY0okLldgfblKVs+DwRGf6nbL21OlSSAn6hGdmgqtiqKj5UF7Dyz6NafgeRMjYZP5R6fn+R4uC7ur78oaYz3N3RwE6banEaGJkCBNrR/vVcEpmb0+qZZDnlzJZs/10hP26kgWEQ6KjfGGMAT5htKXhDZEANYIqFQX7DW6snG1RwI5cFHc7Ig0fhdEucEcZg2m7EQz75oxcrW2/6nQpwBlB2IRSwL/iOjCUf4gQowxeq29PlMML+89lQB4+i9OpbGALIQLjhUIyB5iRVEDuu0mZnXTRQjUQBUffJexK2APbiSB6TofnLt1rELlCuC9Jrc/oN+jHQYW/dyYW1V6Mk9cOuvPnVuFg5pb0nKMIPAWTYC/4BhiG03ZTQ7SwSCMUUq7ES1XvEW8SCPO2bXmQxYSIXVHmYIhVZ5OIP+B9oEMWcM8+Q7agvpEZIXbEgmw0H1u4VURZkii//hm2QSAz4rXOWbSKMQ+oZqgg6sb7v7ZfxnqPFlEUEjt66iw8bq0g/hlBPdjH3jo29tNr7sHxyKxumPQ38VSzfffUTcwKtVudWXEVg/7K1YZlQd4gZzeFIp3lZKUxL4rp0Yh1T7fQJyLa/mSBIv0OIU1ovLIKt6/KhWR6G+1axi46gDPa7lZKlmQdHvpMOxlbHkjCDONSlXLQuAqKL6HMt7kRHZe43m9oL4ohEq1iBTC3I31BbLnqMX916i6TAFG9bQMTyLLqXcojokC6ERJHkYs5lVnSZHwEDbLcFAvX9b5F413fu0En7/XG+zL9woSK5PhB7jrvm3tYxBTCWDj 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: 1d359a8b-2cc7-45b3-4c89-08d9cbc978ea X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2021 19:20:42.6276 (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: DM8P223MB0381 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: Thursday, December 30, 2021 12:22 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 30/12/2021 00:29, Soft Works wrote: > >> -----Original Message----- > >> From: ffmpeg-devel On Behalf Of Mark > >> Thompson > >> Sent: Thursday, December 30, 2021 12:04 AM > >> 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 25/11/2021 02:41, Soft Works wrote: > >>> The test /libavutil/tests/hwdevice checks that when deriving a device > >>> from a source device and then deriving back to the type of the source > >>> device, the result is matching the original source device, i.e. the > >>> derivation mechanism doesn't create a new device in this case. > >>> > >>> Previously, this test was usually passed, but only due to two different > >>> kind of flaws: > >>> > >>> 1. The test covers only a single level of derivation (and back) > >>> > >>> It derives device Y from device X and then Y back to the type of X and > >>> checks whether the result matches X. > >>> > >>> What it doesn't check for, are longer chains of derivation like: > >>> > >>> CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4 > >>> > >>> In that case, the second derivation returns the first device (CUDA3 == > >>> CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new > >>> OpenCL4 context instead of returning OpenCL2, because there was no link > >>> from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1) > >> > >> Yes, this is exactly what I expect. > >> > >> Because of how these APIs work, device derivation is always one-way - you > can > >> make an OpenCL device from a D3D11 one, but not the other direction. I > don't > >> think there is any case which allows both directions > > > > hwmap=reverse=1 > > Indeed, hwmap reverse exists because mapping is one-way and sometimes a > filter graph wants to use it in the other direction. => mapping is not only one-way > >> Saying that derivation from A should always return the same B is not > >> intended, nor do I think it should be. > > > > Why not? > > > > Looking at the reality of API users: > > > > - I'm covering a wide range of different processing pipelines and > > found that this behavior is crucial to make important and relevant > > processing pipelines work > > > > - Intel have three different workaround-patches in their backlog/queue > > of ffmpeg patches to get certain processing setups working > > > > - The developers working on Vulkan have confirmed that this change > > is necessary and crucial for certain setups to work > > > > - Nobody has named any case or scenario that would be negatively > > affected by this change > > > > Given that situation, I don't think it's useful to talk about > > theoretical implications. > > You are not talking about API users at all. When does an API user ever want > this patch? From their point of view it is surprising and unwanted - if they > want the same device again, they just use the same device again. No. Not when using libavfilter with a filter graph. => It affects API users in the same way > > You are talking about users of the ffmpeg utility. No. See above. > The change is a library > hack to work around the inability to select devices per-filter in the ffmpeg > utility. No, it's not a hack, it's about making libavfilter hw context deriving and reverse mapping working as expected and needed. > Please, just implement device selection for filters in ffmpeg rather than > adding unexpected behaviour elsewhere. libavfilter has supported it for API > users for a long time, no library changes should be needed. I'm afraid but I disagree. I stick to the proposed solution; this change is welcomed and needed by many which are having problems with the current implementation. I still haven't seen any (real-world and not theoretical constructed) scenario where this would have a negative effect or break something, neither did I see anybody else objecting. Anyway, I have no intentions to propose a different solution. This is what I'm using and what others want and need. Thanks, 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".