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 977A7429EF for ; Mon, 10 Jan 2022 20:56:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A658E68A631; Mon, 10 Jan 2022 22:56:44 +0200 (EET) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4D0F56880E5 for ; Mon, 10 Jan 2022 22:56:38 +0200 (EET) Received: by mail-wr1-f41.google.com with SMTP id l25so18269809wrb.13 for ; Mon, 10 Jan 2022 12:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=JGrEUJFdaOBLcPSoBwPKwJZ0eGFHuBe7O9TEnxqiP8s=; b=i0X/JOlgRBbktjP35Rb1ZvfAikRpdMNtq9zzawMoOcXFW2PT7bTdNIhd3+2UwnR3S/ TjevzoosTSotx2/TAnsewknwgLhwmFZMNEHvOFAuuy8jkqekOXGMBz8IwdHu+WfekX2v /UB5+fFHTUBj8FGaAhB2/zoCLFGLUT0/GQ8YnexrHvlaJyuLVRcStW/IGGoL19xkXx1u YcVrT1B7TMqaqhesUSi+V6M+xEuLqb+vNMBYKjH4UR3TZ70ckZ3jj1XhAXMVeg1xk4oR 03QUynXAJRdjdoQQMpnz6EdqwTHJcXeFJMd8deDJTPJegSKE8kE3bDZPwoY2CsOtbnGW qGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=JGrEUJFdaOBLcPSoBwPKwJZ0eGFHuBe7O9TEnxqiP8s=; b=wT7t1kSos0hccJ5ib2kpllGateQWX0u6ebYx4tXCdLMu/n87ifO83kcedUsaxMM1sP Gq2Bo87/Vqjw13G6JO4KNb7kaeMMfllHjBMT7zIIQYxOabAxuKxm2HEF1RNIeHNcXEiL tpPkzzmD/EzlqKlXKzSKGIq4aiF3x87vkDAQnUmoFfzPhrue6vGFYuPcDIKRUAUj6dt1 0cX13pxBZmGiBGe6Dg1GpWWTESAZfv1wuVUvscRVLVMXJZtQ04nkHLlTmVVDY3aUZucD +i+hSp0WnpWCrZ4ytyDRJFWdt2npYTWt3VY5nk+Qq41QV4Nf87lbeFFCWCSS+vrsy55L CvuQ== X-Gm-Message-State: AOAM533gj+TCPm7pQNQum8d9NPInguRkmEdDbaEnJDXkN7CxgB10Osd4 9bWqZ5q5BcoBadaUs8ZF7+CYnXIxnDCi+PjW X-Google-Smtp-Source: ABdhPJxhiAmHpq8t5Go5QyKpY7+AtK8+hCw6u92bwL0wXJqaW4vNlhS06LocI+bhwF1rYrTbOjD8dw== X-Received: by 2002:a5d:6f02:: with SMTP id ay2mr1123329wrb.269.1641848197614; Mon, 10 Jan 2022 12:56:37 -0800 (PST) Received: from [192.168.0.11] (cpc91222-cmbg18-2-0-cust46.5-4.cable.virginm.net. [81.106.30.47]) by smtp.gmail.com with ESMTPSA id j26sm8784922wms.46.2022.01.10.12.56.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jan 2022 12:56:37 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2022 20:56:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <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> <97ce0944-17bc-6e89-160a-e103b77db861@jkqxz.net> From: Mark Thompson In-Reply-To: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 10/01/2022 01:40, Soft Works wrote: >> -----Original Message----- >> From: ffmpeg-devel On Behalf Of Mark >> Thompson >> Sent: Monday, January 10, 2022 1:57 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 >> >> [trimmed somewhat] >> >> Device derivation means making a compatible context of a different type on >> the same physical device. >> >> Now that's probably intended because you are going to want to share some >> particular resources, but exactly what can be shared and what is possible is >> dependent on the setup. >> >> Similarly, any rules for concurrency are dependent on the setup - maybe you >> can't do two specific things simultaneously in the same device context and >> need two separate ones to solve it, but they still both want to share in some >> way with the different device context they were derived from. >> >>>> * When global options have to be set on a device, so a component which >> does >>>> that needs its own instance to avoid interfering with anyone else. >>> >>> This is NOT derivation. This case is not affected. >> >> Suppose I have some DRM frames which come from somewhere (some hardware >> decoder, say - doesn't matter). >> >> I want to do Vulkan things with some of the frames, so I call >> av_hwdevice_ctx_create_derived_opts() to get a compatible Vulkan context. >> Then I can map and do Vulkan things, yay! >> >> Later on, I want to do some independent Vulkan thing with my DRM frames. I >> do the same operation again with different options (because my new thing >> wants some new extensions, say). This returns a new Vulkan context and I can >> work with it completely independently, yay! > > You are describing the creation of a Vulkan context with other parameters > with which you can work independently. > > That's not my understanding of deriving a context. I don't the implementation > in case of Vulkan, but in case of the others, deriving is about sharing > resources. And when you share resources, you can't "work with it independently", > so what you're talking about is not a scenario of deriving a context. But that's what deriving a context is as currently implemented. In my example, the Vulkan parts don't care about where the context came from. Derivation is used to ensure that frames can be shared, but all compute happens independently. > To wrap things up a bit: > > - you want an approach which requires even more complicated filter > command lines. Ha, that characterisation isn't exactly neutral - the derivation in filter graphs is removed and replaced with explicit specification of devices. Indeed, once device creation is explicit, command lines are clearer because you don't need to reason about creation of devices inside filter graphs and whether they are actually the same device. > I have understood that. It is a possible addition for filter command lines > and I would even welcome somebody who would implement precise hw context > selection for hwdownload and also for hwmapn for (rare) cases where this > might be needed. (that somebody won't be me, though) > > - but this is not what this patchset is about. it is about having things > working nicely and automatically in a way as one would expect it instead > of failing. this patchset only touches and changes behavior in those cases > that are currently failing anyway No it doesn't; it changes the behaviour of a library API when you are talking about use-cases in the ffmpeg utility. If you need some library assistance, perhaps by making some new concept of a bundle of related devices which have the properties you want, then maybe that's a good idea. Perhaps you even want to add to the av_hwdevice_ctx_create_derived() API so it can take a YKNOW_ACTUALLY_DONT flag to indicate you don't want to create a new derived device, I don't know. - Mark _______________________________________________ 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".