KhronosGroup / KhronosGroup/Vulkan-ValidationLayers

practices: massive memory use and performance problems from ARM Image layout checks

Open
#3,823 0 comments 0 reactions 0 assignees View on GitHub
BestPractices Performance
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.