Skip to content
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 493 commits into from
Oct 3, 2024
Merged

Conversation

MathiasMagnus
Copy link
Contributor

@MathiasMagnus MathiasMagnus commented Oct 3, 2024

spencer-lunarg and others added 30 commits July 1, 2024 23:16
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.
spencer-lunarg and others added 25 commits August 26, 2024 09:25
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
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ MathiasMagnus
❌ stu-s
You have signed the CLA already but the status is still pending? Let us recheck it.

@aqnuep aqnuep self-requested a review October 3, 2024 12:22
@aqnuep aqnuep merged commit 139b820 into sc_main Oct 3, 2024
20 of 21 checks passed
@aqnuep aqnuep deleted the downstream-1.3.295 branch December 12, 2024 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.