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 2E56240B47 for ; Mon, 27 Dec 2021 18:32:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2B69B68AFDE; Mon, 27 Dec 2021 20:32:04 +0200 (EET) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 433AF68A255 for ; Mon, 27 Dec 2021 20:31:57 +0200 (EET) Received: by mail-wr1-f44.google.com with SMTP id v11so33797884wrw.10 for ; Mon, 27 Dec 2021 10:31:57 -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=5ZbMWyKgb5l9cok+3Odd+vf2YqLa+iNB1/7xxukQd2g=; b=KFU31Ld6W+pyAyJKhgzLGzb6pfrBnq/l+gVGn33vzkuOoEsB1yObo0pWcv4N8QNEgY 1oFX/FrwwFQWeTY0MGe5u40baA227A8XgLF2Wg0IiNzrH2h+4V/IV1Wpst+SoZLE5H3A bRkZXGmR76XMUGjSkFPgp5JTcASIQtipAZQ2R3AAiEVMCR5/XbH0cJD1e753Q1vai/x4 XSMUyG8+vsbROa7cdFFOUlpNceumrk5tBypusuJ8p7yK6PCnTzLO3toKHS/kjCh1lt0x NjovoI7s8qEN4AhgINtEPuxl2g5sjxHsKuMOsyXrc9xgvwutH45pH4oNdWao2WRJFJi6 QsVQ== 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=5ZbMWyKgb5l9cok+3Odd+vf2YqLa+iNB1/7xxukQd2g=; b=CvsnJU0aYFWQ3MWH3ZoB2+Ws1tV5rs2YEWpuNnMeQ3jeTEPZLd5MTO4/CcK8QlIX79 IEVc+MT9kI+vYaaMh40pA5Zzal3Lg+aBDGeFJO24rzkLFbwgYdi72iFtKVhLJkc+O7Kf g+8/yfx8Dh1oaSwANpUqVa/SImbbCWvdj2janJNxF/ULYbXOHQcLRfOYil9jbEENsmcl hPXuML8R+h/qjcR8ACdTYRKTz/3hX/d41F69w/u9Jzbpa8qhI8OUDszpAYBqM0YuwqHV JOUhdcEKFts62K1vBM8pLiyk+CGAouOLZG5zLA4EBumWY/mQ1dFX67tBpUFTRihzh+ZQ qkqw== X-Gm-Message-State: AOAM531CMT5tvxiYnIGr6QZqObuIOXWPBmrQBmlbWFSn5q9Tvk0gL6wZ ELq+aD1QqFd6WA5TmbR3b/YEeMBbfCqZ7Q== X-Google-Smtp-Source: ABdhPJyzsJlFmxPT1KfMLwQHsc2z2rmP76SpJTzz/5oYvlRKgbQf1Khtq08IGEejBmuQmqnWVa5U1Q== X-Received: by 2002:a5d:6488:: with SMTP id o8mr13619337wri.631.1640629916186; Mon, 27 Dec 2021 10:31:56 -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 n1sm16819662wri.46.2021.12.27.10.31.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 10:31:55 -0800 (PST) Message-ID: <5a7d1a75-57c0-30cb-cc4f-4c8a346876d6@jkqxz.net> Date: Mon, 27 Dec 2021 18:31:50 +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: <20211027085705.4114165-1-wenbin.chen@intel.com> From: Mark Thompson In-Reply-To: <20211027085705.4114165-1-wenbin.chen@intel.com> Subject: Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/vaapi_encode: Change the way to call async to increase performance 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 27/10/2021 09:57, Wenbin Chen wrote: > Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance > decrease. The reason is that vaRenderPicture() and vaSyncSurface() are > called at the same time (vaRenderPicture() always followed by a > vaSyncSurface()). When we encode stream with B frames, we need buffer to > reorder frames, so we can send serveral frames to HW at once to increase > performance. Now I changed them to be called in a > asynchronous way, which will make better use of hardware. > 1080p transcoding increases about 17% fps on my environment. > > Signed-off-by: Wenbin Chen > --- > libavcodec/vaapi_encode.c | 41 ++++++++++++++++++++++++++++----------- > libavcodec/vaapi_encode.h | 3 +++ > 2 files changed, 33 insertions(+), 11 deletions(-) The API does not allow this behaviour. For some bizarre reason (I think a badly-written example combined with the Intel driver being synchronous in vaEndPicture() for a long time), the sync to a surface is to the /input/ surface of an encode rather than the output surface. That means you can't have multiple encodes outstanding on the same surface and expect to sync usefully, because the only argument to vaSyncSurface() is the surface to sync to without anything about the associated context. Therefore trying to make it asynchronous like this falls down when input surfaces might appear multiple times, or might be used in the input of multiple encoders, because you can't tell whether your sync means the thing you actually wanted to finish has finished. (The commit you point to above as having decreased performance fixed this bug, since it became much more visible with decoupled send/receive.) So: put this change after the switch to syncing on output buffers (since that operation does make sense for this), and leave the existing behaviour for cases where you have to sync on the input surface. - 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".