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 3D6F345F13 for ; Thu, 18 May 2023 12:28:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E1A8B68C15D; Thu, 18 May 2023 15:28:25 +0300 (EEST) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 11CD368C14C for ; Thu, 18 May 2023 15:28:19 +0300 (EEST) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id BE8C010601FD for ; Thu, 18 May 2023 12:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1684412898; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=5auBTGbb3oO3mlFjAZuRceP2cyihuWemP48Rx7Z+2sA=; b=ukFHojFb2CvxyeMuWUaJTvaomPdUOvhLAAiNsOggbP60VC5Z/h0wycGCtUfgZjbo +nF+GTHQ7iPoHx11HyX1PwULQmgISC/sapP9rEnIEop6SOmoAQFh/z5bjxp2Nezn5HY 4HmdnVUy0tVLxIlg8Xch12NTBXGwWvbdYZVjHtVxAgJc62z/QDNCMvBT5QlbxRHg4Gd IkRVWnWMJhuToRZ4PZuP26qANIeav8zO7TJc0rHwn2OatL67b4apOWxhLpb5784I/2V bJtjzKr57NCdRg4CtY24Jk6x44FCwRPcjFvgz4DzFX+CcfmgLt4lWbeOvOntfQ9Bg4+ mKdFyYPQwQ== Date: Thu, 18 May 2023 14:28:18 +0200 (CEST) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: <168439859157.3843.5730303366938975471@lain.khirnov.net> References: <168382259881.3843.17606833076993456127@lain.khirnov.net> <168424444727.3843.5127395344901862629@lain.khirnov.net> <168439859157.3843.5730303366938975471@lain.khirnov.net> 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: May 18, 2023, 10:30 by anton@khirnov.net: > 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. > added a counter _______________________________________________ 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".