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

ShadowmapData.TargetTexture barrier on the transfer queue #105

Closed
AaronHaganAMD opened this issue Feb 2, 2021 · 1 comment
Closed

ShadowmapData.TargetTexture barrier on the transfer queue #105

AaronHaganAMD opened this issue Feb 2, 2021 · 1 comment

Comments

@AaronHaganAMD
Copy link

AaronHaganAMD commented Feb 2, 2021

IMAGE_BARRIER(cmd_buf,
.image = ShadowmapData.TargetTexture,
.subresourceRange = { .aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT,.levelCount = 1,.layerCount = 1 },
.srcAccessMask = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT,
.dstAccessMask = VK_ACCESS_SHADER_READ_BIT,
.oldLayout = VK_IMAGE_LAYOUT_UNDEFINED,
.newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL);

This barrier is doing a layout transition to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL on the transfer queue.

Should it be transferring ownership to the graphics queue with an addition of
srcQueueFamilyIndex=(transfer queue index) and dstQueueFamilyIndex=(graphics queue index) ?

apanteleev added a commit that referenced this issue Mar 22, 2021
@apanteleev
Copy link
Collaborator

Fixed by moving that command buffer to the graphics queue. Doing it the right way with ownership transfer makes the image layout undefined on the destination queue, which requires another barrier on that queue, ... This happens once at load time anyway, so the queue doesn't really matter.

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

No branches or pull requests

2 participants