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 ESMTPS id 398AD4D449 for ; Fri, 21 Feb 2025 14:36:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4A0A568BF99; Fri, 21 Feb 2025 16:36:28 +0200 (EET) Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CA4F46800F9 for ; Fri, 21 Feb 2025 16:36:20 +0200 (EET) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-6fb3a611afdso18820317b3.0 for ; Fri, 21 Feb 2025 06:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740148579; x=1740753379; darn=ffmpeg.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=n6SR0mL4UaG1ayV1Yu1YbxKzCDSDirDKxSAiCJiOxfs=; b=kbLmJuVrP6zpP3/p1oNRMi5BvoA/AjnM0eTMXio50PDk0ND//jSMyxdAcJgfMolf6O NSgMXVUOrmfOg0iX9IrlJxIZowS2K1T4UZV5MQuuFZj91G4ZcThMXvI1PCYLT/imlPbK k7i+58Y8PhBf86OK9jLiIcxw6RL17sRvHh+oKL9cBEDgrqj794rsqS2scfaWAMErYQqD 5hRPL6XmcS0JNBmYM2++tQnIT4qcIQ6/+aEvOPh14G2YXhd8/CoPOkHqcJCNNJ2f8JYu WlHbPt9mm0Hk5vbLV27mlY+EWt54pVH3oYekuEkHVbpKefh0osSHmZRVIBdTS4dsu4Ni bFVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740148579; x=1740753379; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=n6SR0mL4UaG1ayV1Yu1YbxKzCDSDirDKxSAiCJiOxfs=; b=w3IfGme4/D79O02oX8EBweUbJPyMDaZjfZX9F1BdI6TkA4E2bf8lltY8CGZjGg9j/M Y/gjOipu9hneH0+HNh5s0CdolfBewU4+ZYWNj8YBPHSrFnGgGdyPbbvWlUlt5bWYH28p dh9rn77BhK07DZP4B1XrvMuxK/c1HQWUdmXN0pcjX84jm0mLImnXkWaac1CZrnEJgp8D RH9v7EJsnpOt+gQQMdnieZY5G9qf5pfV5qGav+jbqU6IfE1SNYRVCO6wRN3+mfYDOub7 CehFFRLRN3KjxdPc+p9EbrSff4cYhuQFQ94jalbXyy0lFN5sqFWY2Tsr0VOcUDUMDpkK 1N6Q== X-Gm-Message-State: AOJu0YyiuvLTxca+6FhY46UtCuvMeqBkW/p9dDybVrMzEf/SxxyBJYrX yu9AyIDVT6RAVskWc2McrWNKb+tgKedT70W8uW9fThpG8o54SQBcgmg9k4no2nuVdCq3CNf/adl TG+PY0KbiZ6GqmADtQtH/kS5+ejvdaDzVfv0= X-Gm-Gg: ASbGnct20DCrJ97IayORRZhl13SFlnAA/3BrptYlAAGod7G+Ha8eAFJQEts+Mc/KIqt prOs9AUhH5ZvLH7HMOuq7ECLWc5kyz/tGef0C+5Phq8QnF6m2YdMINnxLQYx0NOpM8ZdiuA56hq jnC620vMjL X-Google-Smtp-Source: AGHT+IGWsfk1FkUbRf5n6bJdspdpP3/MB3u2y66iZLMxO4dYEBshIDZ2jLBJOUK4jHko4bgPFNTr6hE9xeJRFM0TG2U= X-Received: by 2002:a05:690c:4808:b0:6fb:9c08:496d with SMTP id 00721157ae682-6fbcc3831bfmr32194257b3.30.1740148579062; Fri, 21 Feb 2025 06:36:19 -0800 (PST) MIME-Version: 1.0 References: <20250130140934.1800-1-Primeadvice@gmail.com> <15be8639-03c8-42e0-be39-ce86efe490c0@bcheng.me> In-Reply-To: <15be8639-03c8-42e0-be39-ce86efe490c0@bcheng.me> From: Araz Date: Fri, 21 Feb 2025 15:36:08 +0100 X-Gm-Features: AWEUYZlD9phZJRSjIIST-Vaw4FqAXAgGhHk3amMjn2og6vSyXRI80GUjORQgAx8 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: DX12 Reference-only feature support 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 Cc: Benjamin Cheng 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: > > Benjamin Cheng Jan. 31, 2025, 1:22 a.m. UTC This patch only affects d3d12va, why is the commit message amfenc? > We accept this review comment and update it in this patch: avcodec/d3d12va_decode: enable reference-only decoder mode > You could optimize these barriers since reference-only resources don't > need to be transitioned to COMMON, and can remain in > VIDEO_DECODE_{READ,WRITE}. > > I propose the following: > - Transition all reference texture to VIDEO_DECODE_READ at creation time. > - When preparing resources for input to DecodeFrame(), transition only > the texture for reference output to VIDEO_DECODE_WRITE > - After DecodeFrame(), transition the reference output texture to > VIDEO_DECODE_READ. This is already implicitly handled by the barrier SWAP. > > All-in-all, for the cost of an initial transition at creation time, you > decrease the number of barriers in each frame to just 2. We have conducted some evaluation work regarding the suggestions from the review: 1. The proposed method can successfully complete decoding, and the playback quality of the decoded YUV raw data is normal. However, during the execution, a large number of D3D12 errors were encountered, and error sample is shown below. D3D12 ERROR: ID3D12CommandQueue::ExecuteCommandLists: Using DecodeFrame on Command List (0x0000018A94557FD0: 'Unnamed ID3D12VideoDecodeCommandList Object'): Resource state(0x 10000: D3D12_RESOURCE_STATE_VIDEO_DECODE_READ) of resource(0x0000018A95B1C740:'Unnamed ID3D12Resource Object') (subresource : 1) must be in COMMON state when transitioning to use in a different Command List type, because resource state on previous Command List type : D3D12_COMMAND_LIST_TYPE_DIRECT, is actually incompatible and different from that on the next Command List type : D3D12_COMMAND_LIST_TYPE_VIDEO_DECODE. [RESOURCE_MANIPULATION ERROR #990: RESOURCE_BARRIER_MISMATCHING_COMMAND_LIST_TYPE] Further analysis revealed that... According to the suggestion, when decoding each frame, only the current reference texture should be transitioned to VIDEO_DECODE_WRITE, and after DecodeFrame(), the current reference texture should be transitioned to VIDEO_DECODE_READ (this is already implicitly handled by the barrier FFSWAP). For all other reference textures, they should remain in the READ state. However, the evaluation shows that there is a problem when keeping the all other reference textures in the READ state. It expects a transition from COMMON to READ every time, even if the texture is already in the READ state. If the other reference textures does not transition to COMMON, they will throw the D3D12 error mentioned above. In other words, transitioning to the COMMON state is mandatory. 2. Performance testing. We evaluated the performance of the currently submitted patent and the performance of the suggested method from the review. After conducting few dozen tests, minor changes were identified that can be attributed to error, since only 10 out of 18 tests showed a speed improvement of 0.2%. The remaining 8 showed that the current method is faster than the proposed one. Tong Wu Feb. 10, 2025, 3:18 p.m. UTC > Need to handle when DecodeTier == D3D12_VIDEO_DECODE_TIER_2? The submitted patch has been tested on GPUs supporting D3D12_VIDEO_DECODE_TIER_2 (GPU such as AMD RTX 7900XTX), and it works perfectly. Therefore, no additional work is needed for D3D12_VIDEO_DECODE_TIER_2. Lynne Feb. 10, 2025, 4:34 p.m. UTC > This information doesn't belong here, and this value does definitely not > belong here, as the hwcontext_d3d12.c code doesn't even touch it. > We try to not put random internal fields in public structs anymore. We accept this review comment and update it in this patch: avcodec/d3d12va_decode: enable reference-only decoder mode _______________________________________________ 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".