Skip to content

Resource state between subsequent commands #4245

@gents83

Description

@gents83

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions