-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Closed
Labels
backend: vulkanIssues with VulkanIssues with Vulkantype: bugSomething isn't workingSomething isn't working
Milestone
Description
While debugging test zero_init_texture_after_discard::discarding_either_depth_or_stencil_aspect() with Arcanization CL #3626
I noticed that the following code was causing in Compute pass to have the resource in a wrong state compared from the one present in the device (it's initialized to RESOURCE instead of DEPTH_STENCIL_WRITE).
case.create_command_encoder();
case.discard_depth();
case.submit_command_encoder();
case.create_command_encoder();
case.discard_stencil();
case.submit_command_encoder();
case.create_command_encoder();
case.copy_texture_to_buffer();
case.submit_command_encoder();
And I was forced to have a unique command buffer with all operations in the same flow in order to avoid the issue, and have not validation error trigger on wrong resource state:
case.create_command_encoder();
case.discard_depth();
case.discard_stencil();
case.copy_texture_to_buffer();
case.submit_command_encoder();
So may be worth to check resource state between different command buffers.
I added following command into the code to keep track of it (other then adding this issue):
//When splitting it in subsequent submits of different command encoders
//it seems that texture tracker is not able anymore to get that the texture has been left in DEPTH_STENCIL_WRITE
//and it assume that it could find it uninitialized and set it in RESOURCE as not owning it
//When using a unique submit instead the tracker is able to follow all resource barriers and everything is smooth
teoxoy
Metadata
Metadata
Assignees
Labels
backend: vulkanIssues with VulkanIssues with Vulkantype: bugSomething isn't workingSomething isn't working