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 0A8FE46425 for ; Thu, 18 May 2023 08:30:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4F15768C13D; Thu, 18 May 2023 11:29:58 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9C27268C06C for ; Thu, 18 May 2023 11:29:52 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 5B0C42404EC for ; Thu, 18 May 2023 10:29:52 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Xp3VROPRLwTl for ; Thu, 18 May 2023 10:29:51 +0200 (CEST) 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 B07AE240177 for ; Thu, 18 May 2023 10:29:51 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 94CB01601B2; Thu, 18 May 2023 10:29:51 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <168382259881.3843.17606833076993456127@lain.khirnov.net> <168424444727.3843.5127395344901862629@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Thu, 18 May 2023 10:29:51 +0200 Message-ID: <168439859157.3843.5730303366938975471@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 55/97] Vulkan patchset part 2 - hwcontext rewrite and filtering 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-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 (2023-05-16 16:46:45) > May 16, 2023, 15:41 by anton@khirnov.net: > > > Quoting Lynne (2023-05-11 20:13:29) > > > >> >> diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h > >> >> index 4bd1c9fc00..4c38dbc2e6 100644 > >> >> --- a/libavutil/vulkan.h > >> >> +++ b/libavutil/vulkan.h > >> >> @@ -216,6 +216,9 @@ typedef struct FFVulkanContext { > >> >> VkPhysicalDeviceProperties2 props; > >> >> VkPhysicalDeviceDriverProperties driver_props; > >> >> VkPhysicalDeviceMemoryProperties mprops; > >> >> + VkQueueFamilyQueryResultStatusPropertiesKHR *query_props; > >> >> + VkQueueFamilyVideoPropertiesKHR *video_props; > >> >> + VkQueueFamilyProperties2 *qf_props; > >> >> > >> > > >> > How does the user of these know how many elements are in each array? > >> > > >> > >> They don't have to, we read the total number of queues available > >> for the device, so all indices are always available. > >> > > > > "all indices"? > > > > The allocated size of these arrays is purely local to > > ff_vk_load_props(), so there is no safe way for any outside caller to > > know it. > > > > The init function queries the driver for the total number of queue family indices, > allocates an array of that amount for each structure, and reads the properties > into the array. > API users then index into the array based on the queue family index. > API users cannot index outside of the array ever, as the queue family index > they receive is always AVVulkanDeviceContext.queue_family_index (or the > transfer, compute, encode, or decode queue family index member of that structure). > The queue family index members of that structure are checked upon initialization > to not be larger than what the driver returns. > > Hence, there's no need for them to know how large the array is, as > it is allocated for all possible indices. That's way too much indirection and way too much code that has to make the exact same unstated assumption on what the actual size is. In my experience, it is almost always a good idea to be explicit: store the exact array size right next to the array itself. If nothing else, it will be very helpful for the person debugging the inevitable invalid accesses. -- 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".