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 E74E74BA22 for ; Wed, 10 Jul 2024 08:19:10 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 36DB868D977; Wed, 10 Jul 2024 11:19:08 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 69D6C68D767 for ; Wed, 10 Jul 2024 11:19:01 +0300 (EEST) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=GVMrtu7a; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id CD7C9240DB7; Wed, 10 Jul 2024 10:19:00 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id XdKm8yhcWedT; Wed, 10 Jul 2024 10:19:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1720599540; bh=+2wi3TuOT4I3ed63Qgd7PArwdbkpSul3V8yXvs5DSaU=; h=Subject:From:To:Cc:In-Reply-To:References:Date:From; b=GVMrtu7aywJf8etMBACqqT5uu+Eve32d7nm+VADHx+zgyo4NEAVg7XoHP8ACsDO3I JwW6dji2mogpDxjhZFLfo0doSMwn2DRtwyzz353gjQnN1MI/xs4LskKCFx0CuzjPXW N4BLaJlBEboo0i7hnrCsn1cJ9fRD13os3WIklakIJhVy90MiBsT3Dl25kH1qyhnePZ blZ315iwzCi7ix3vT/SReup+idkGYn5s01y8WfgnOZZ8wJy9trLHsWcxX2KZtZqa8r oQKIZpkXRZi9Ek5O+ISKmW+jW8d5J9xx/Osw8hdjuTfueTpnaf/GnPCNJizYCComYA EaKsiQxvS0omQ== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 425AF240695; Wed, 10 Jul 2024 10:19:00 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 1C2951601B9; Wed, 10 Jul 2024 10:18:54 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20240709010719.914497-1-dev@lynne.ee> <172050825390.21847.1255531124935548598@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches , Lynne Date: Wed, 10 Jul 2024 10:18:54 +0200 Message-ID: <172059953409.21847.16652442096149443980@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: add a new mechanism to expose used queue families 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: Lynne 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: Quoting Lynne via ffmpeg-devel (2024-07-10 01:56:57) > On 09/07/2024 08:57, Anton Khirnov wrote: > > Quoting Lynne via ffmpeg-devel (2024-07-09 03:07:12) > >> @@ -151,6 +162,17 @@ typedef struct AVVulkanDeviceContext { > >> * Similar to lock_queue(), unlocks a queue. Must only be called after locking. > >> */ > >> void (*unlock_queue)(struct AVHWDeviceContext *ctx, uint32_t queue_family, uint32_t index); > >> + > >> + /** > >> + * Queue families used. Must be preferentially ordered. List may contain > >> + * duplicates, as long as their capability flags do not match. > >> + * > >> + * For compatibility reasons, all the enabled queue families listed above > >> + * (queue_family_(tx/comp/encode/decode)_index) must also be included in > >> + * this list until they're removed after deprecation. > >> + */ > >> + AVVulkanDeviceQueueFamily qf[16]; > > > > Why 16? And are we really really sure sizeof(AVVulkanDeviceQueueFamily) > > should be a part of the ABI? > > 16 is just an arbitrary limit. I don't expect to need more than this > ever, but if we do, its not something that we can't wait until a bump > occurs. > I can increase it to 32 if you're concerned about it. > > There are 6 total queue family types, and 6 more currently supported > encode and decode operations for each queue -> 12. > > I'd like to avoid making this not a part of the ABI, particularly as its > a context that users should be able to easily set themselves. I'm more concerned about adding new fields to AVVulkanDeviceQueueFamily. Can't you just make qf an array of pointers, with a new function that adds a new queue family to it? -- Anton Khirnov _______________________________________________ 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".