You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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:
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
The text was updated successfully, but these errors were encountered:
@gents83 you mentioned that you had a way to unconditionally get a validation error from this problem? Could you post that bit and we'll add it as an always failing test.
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).
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:
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):
The text was updated successfully, but these errors were encountered: