Skip to content

Change in has_external_format#2852

Merged
panos-lunarg merged 1 commit intoLunarG:devfrom
panos-lunarg:change_in_has_external_format
Apr 11, 2026
Merged

Change in has_external_format#2852
panos-lunarg merged 1 commit intoLunarG:devfrom
panos-lunarg:change_in_has_external_format

Conversation

@panos-lunarg
Copy link
Copy Markdown
Contributor

External images which during capture have been dumped as VK_FORMAT_R8G8B8A8_UNORM, during replay can be treated as normal images

@panos-lunarg panos-lunarg requested a review from a team as a code owner April 3, 2026 12:47
@panos-lunarg panos-lunarg force-pushed the change_in_has_external_format branch from c9ee4de to 027837c Compare April 3, 2026 12:52
@panos-lunarg panos-lunarg added the approved-to-run-ci Can run CI check on internal LunarG machines label Apr 3, 2026
@MarkY-LunarG
Copy link
Copy Markdown
Contributor

I don't see you explicitly checking for R8G8B8A8 where you removed the external copy. Is this not needed?

@panos-lunarg
Copy link
Copy Markdown
Contributor Author

I don't see you explicitly checking for R8G8B8A8 where you removed the external copy. Is this not needed?

From what I understand if you are inside this if condition then you are hitting this case where the AHB was sampled in the compute path and dumped as a R8G8B8A8 image. I believe this is confirmed by the other 3 lines above:

// In this case, the image has been sampled at capture time and format is now RGBA8_UNORM.
modified_create_info.format     = VK_FORMAT_R8G8B8A8_UNORM;
external_format->externalFormat = 0;

@MarkY-LunarG
Copy link
Copy Markdown
Contributor

I don't see you explicitly checking for R8G8B8A8 where you removed the external copy. Is this not needed?

From what I understand if you are inside this if condition then you are hitting this case where the AHB was sampled in the compute path and dumped as a R8G8B8A8 image. I believe this is confirmed by the other 3 lines above:

// In this case, the image has been sampled at capture time and format is now RGBA8_UNORM.
modified_create_info.format     = VK_FORMAT_R8G8B8A8_UNORM;
external_format->externalFormat = 0;

Should we at least add an assert to make sure it doesn't change in the future? It just seems this is a little fragile without some watch.

@panos-lunarg
Copy link
Copy Markdown
Contributor Author

I don't see you explicitly checking for R8G8B8A8 where you removed the external copy. Is this not needed?

From what I understand if you are inside this if condition then you are hitting this case where the AHB was sampled in the compute path and dumped as a R8G8B8A8 image. I believe this is confirmed by the other 3 lines above:

// In this case, the image has been sampled at capture time and format is now RGBA8_UNORM.
modified_create_info.format     = VK_FORMAT_R8G8B8A8_UNORM;
external_format->externalFormat = 0;

Should we at least add an assert to make sure it doesn't change in the future? It just seems this is a little fragile without some watch.

Sorry I am a bit confused, can you be more specific about to what to check with an assert? VK_FORMAT_R8G8B8A8_UNORM is not stored somewhere, if the if condition is true then we assign the format to the new image.

@MarkY-LunarG
Copy link
Copy Markdown
Contributor

MarkY-LunarG commented Apr 6, 2026

Sorry I am a bit confused, can you be more specific about to what to check with an assert? VK_FORMAT_R8G8B8A8_UNORM is not stored somewhere, if the if condition is true then we assign the format to the new image.

But only if the external_format is originally undefined. It seems to me we could enter this same path without that being true, and what guarantee do we have that the original format is RGBA8? That's my concern. I won't hold up the review for this, I just worry about what could happen.

@panos-lunarg
Copy link
Copy Markdown
Contributor Author

and what guarantee do we have that the original format is RGBA8?

This is basically a silent "agreement" between capture at

host_image_format = VK_FORMAT_R8G8B8A8_UNORM;
and this place

@panos-lunarg panos-lunarg force-pushed the change_in_has_external_format branch from 027837c to e45b17b Compare April 11, 2026 05:04
External images which during capture have been dumped as
VK_FORMAT_R8G8B8A8_UNORM, during replay can be treated as normal images.
Letting VulkanImageInfo.external_format to false blocks
VulkanResourcesUtil::ReadImageResources from dumping such images while
it should be ok to do so
@panos-lunarg panos-lunarg force-pushed the change_in_has_external_format branch from e45b17b to b2f1a00 Compare April 11, 2026 11:06
@panos-lunarg panos-lunarg merged commit d3fa6be into LunarG:dev Apr 11, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved-to-run-ci Can run CI check on internal LunarG machines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants