KhronosGroup / KhronosGroup/Vulkan-ValidationLayers
practices: massive memory use and performance problems from ARM Image layout checks
- Dominant language
- C++
- Stars
- 1k
- Forks
- 504
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 224
Description
**Describe the Issue**
The vector of function objects in BestPractices::QueueValidateImage can become quite huge if validation is run against an application with large descriptor sets. The checking here is very similar to the image layout validation in CoreChecks and it should be restuctured to match. Namely, keep a map or set of the images in use in the command buffer (because they often repeat) and use the sparse range maps to track information about subresources.
**Valid Usage ID**
NONE
**Environment:**
- OS: any
- GPU: any
- SDK or header version if building from repo: 1.3.204 (but really any)
- Options enabled (synchronization, best practices, etc.):
best practices
**Additional context**
Contributor guide
Research direction
Start by reading BestPractices::QueueValidateImage and comparing it with the similar image-layout validation in CoreChecks. Trace how repeated images and subresources are currently represented, then verify that the refactoring avoids the large function-object vector while preserving image layout validation for large descriptor sets.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- performance, testing-qa
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100