perf(image): batch final mip-chain layout transition (#70) #100
No reviewers
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Catcrafts/Crafter.Graphics!100
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "claude/issue-70"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The mip-chain texture-upload path issued
N+1layout-transition barriers per chain, onevkCmdPipelineBarrierper call. The final blit's destination level is never read again, so its dedicatedTRANSFER_DST → TRANSFER_SRCbarrier was redundant — that level was only transitioned to SRC to keep the closingSRC → consumertransition uniform.This change skips that last per-level barrier and folds the final level into the closing transition, which now batches two
VkImageMemoryBarrierentries into a singlevkCmdPipelineBarrier:[0, mipLevels-1):TRANSFER_SRC_OPTIMAL → consumer layoutmipLevels-1:TRANSFER_DST_OPTIMAL → consumer layoutNet: one fewer barrier call per mip-chain. The
N-1interleaved per-level barriers stay one-at-a-time — each is correctness-mandated because the next blit reads the level it transitions (as noted in the issue). Applied to both the host-upload and GPU-decompressUpdatepaths.Testing
MipChainBarrierBatchregression test drives the pure barrier builder (BuildMipChainFinalBarriers) directly — verifies exactly two batched barriers, correct old/new layouts, access masks, and that the two level groups tile[0, mipLevels)with no gap or overlap. No GPU device needed, mirroringMemoryTypeFallback/UploadStrategy.crafter-build test: all 15 tests pass.Resolves #70
🤖 Generated with Claude Code