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 A5D4B40CE8 for ; Thu, 30 Dec 2021 11:21:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D7C9868AED4; Thu, 30 Dec 2021 13:21:54 +0200 (EET) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8EFBA68AB2E for ; Thu, 30 Dec 2021 13:21:48 +0200 (EET) Received: by mail-wr1-f42.google.com with SMTP id v11so49822189wrw.10 for ; Thu, 30 Dec 2021 03:21:48 -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=N8XBYBCXwsiBY9L+g45EiGzymXgiv30GLa6YjUg/RaQ=; b=luFgehUK/PBztJZ73o2z+2qDH6trDYR/PvmivnfCq2FrGoeYRIgsNfukyKCMeKzvCv LjbsIIrZrwp6m/lJ0dY7xyyNhZQrpMrfI+xkNyrr+vrb5UWzXduu9wCDsuzJ/CUXsvUM r7Hz/q3WcXqdmfblFebXJbUlBIgopv+aDCAjJXqiwSeMEF70equk0dErIHanETzq/2+5 z5os7lGia0L/zeIXGwPWUErRaoXyJBnzJ4FKywZm+QaJ0a46nOsei8UzNT+ehV8/TwCb TUcy42q+pS/HEkdOn6psTCeCDGzqlCUPCOBjBfXGIeCGjkCu6GJRrqDQOC/OUF3gf/a/ Nv+w== 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=N8XBYBCXwsiBY9L+g45EiGzymXgiv30GLa6YjUg/RaQ=; b=LLDajKzDoca53VfZ6eMSQaGjyGOVYhx7g7UalOOCZXR4JlHeFU82PBuhpzTUC6K28m SUsZeqA9JMVsNwi8VE1oHD0vQp3IFN5Jrt+OKj5SOJhRDq2ox7QIYcKdvENEbIKIrIug XszuWmGHQvtQRndLmsqoKMuhB3zAAL0QH8zBMN3dLs0ysW+4ntV3nEe2FQKd7qtm4OOg dAZvxQRyz74i1BPxyqrXXgOnxfzZM0YAzqg+lBRhr0PbHOGxar2tFeO1Wi/Kzx7MfTJc prkbhy3UHCqRfShR/uDzmzbDbebbKqW0T35oAlgiI2SlGFsV2YE05vR7FWMef4dpgumM f9xQ== X-Gm-Message-State: AOAM5337aLuVsrwanv0O+hXhk29N+1viKSE7vEGtwSHcH11DB+BK/sOc Y6VrFibu1mffbrX44bLBRFxkY1XW3PpTCQ== X-Google-Smtp-Source: ABdhPJz9sJeSIm6fBfFciGRS/yrQDsa9VPbOL7pPY0bWc0Xcciwxg8maeDY1ovqpYwhj+8A7qFfYqg== X-Received: by 2002:a5d:5746:: with SMTP id q6mr24804164wrw.163.1640863308017; Thu, 30 Dec 2021 03:21:48 -0800 (PST) Received: from [192.168.0.3] (cpc91224-cmbg18-2-0-cust201.5-4.cable.virginm.net. [81.106.228.202]) by smtp.gmail.com with ESMTPSA id 1sm26509020wry.33.2021.12.30.03.21.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Dec 2021 03:21:47 -0800 (PST) Message-ID: <10c6a99f-9fa4-012c-66a2-7df163daeade@jkqxz.net> Date: Thu, 30 Dec 2021 11:21:47 +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: <0d168258-b2d3-f60e-87af-28b01e809038@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 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. >> 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. You are talking about users of the ffmpeg utility. The change is a library hack to work around the inability to select devices per-filter in the ffmpeg utility. 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. - 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".