-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Downstream Vulkan-ValidationLayers 1.3.295 #32
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will report syncval stats during SyncValidator destruction. The project should be built with stats enabled for this too work: VVL_ENABLE_SYNCVAL_STATS=1
After the code is moved the compiler started to notice unused VkQueueFlags queue_flags parameter, so it was removed.
New checks for: * VUID-VkFramebufferCreateInfo-flags-03196 * VUID-VkFramebufferCreateInfo-flags-03197
New tests for: * VUID-VkFramebufferCreateInfo-flags-03196 * VUID-VkFramebufferCreateInfo-flags-03197
In html and csv output cases the vk_validation_stats.py script will print out the VUID text as the last column. However, using text output mode the "ext" field was printed previously.
This change contains various fixes, including fixes for the following problems: - incorrect query entry point used by vkGetCalibratedTimestampsKHR validation - incorrect generator script logic for the malfunctioning generator script caching - incorrect handling of empty structextends lists - incorrect assumptions about entry points with VkObjectType parameters - API parameterization changes for the Test ICD - incorrect test cases still expecting "stateless" SPIR-V validation at pipeline create call - incorrect test case dependencies
When the stats object is the last one being destroyed this has a nice properly that non-zero counters indicate a potential leak. Also adds a counter for CommandBufferAccessContext.
I forgot to clean up handles in CommandBufferAccessContext::Reset. With this fix the memory consumption by HandleRecord objects in doom capture is ~7MB (previously ~700MB). There is an opportunity to de-duplicate groups of handles which might reduce HandleRecord memory usage to < 1MB range for complex workloads.
The query is a two-level search. Indexing operator does not provide a hint what's going on and can mislead that it is a vector/map access. Also this operation is used only in one place, so not a scenario of a common operation that can benefit from a simpler syntax.
This add support for detecting specific buffer resource that participates in a race condition during submit time validation. This solution adds ResourceUsageTagEx structure that extends tag information with resource handle information.
See issue 8238. Due to recent changes the remove-files script created unexpected interactions with other layer build artifacts. The script and build action are no longer needed and so have been removed.
According to conventions.
It's the second attempt after: KhronosGroup/Vulkan-ValidationLayers#8400 Original present fence synchronization was implemented here: KhronosGroup/Vulkan-ValidationLayers#7694. It was based on PresentSync, although PresentSync was not designed for this (only for acquire-based synchronization). The angle issue happened because we accidentally ended up with two solutions handling the present fence: QueueSubmission and PresentSync. This solution removes code path that uses PresentSync and uses QueueSubmission fence instead.
The previous name was nice but also a bit too general, which allowed to use it in more contexts than initially was planned, which led to problems that are already fixed, but not forgotten. Added comment to better explain the idea of acquire fence synchronization.
Using the vkAcquireNextImage2KHR with the VkAcquireNextImageInfoKHR struct always returned the VUID-vkAcquireNextImageKHR-fence-01287 message if the fence was in incorrect state. However, the correct one is VUID-VkAcquireNextImageInfoKHR-fence-01289. Add a simple version check to select what vuid to return.
This test doesn't create any image views and so doesn't need to check layeredShadingRateAttachments
|
aqnuep
approved these changes
Oct 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Vulkan-ValidationLayers-downstream-1.3.295.patch