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

Resource state between subsequent commands #4245

Closed
gents83 opened this issue Oct 16, 2023 · 3 comments · Fixed by #4782
Closed

Resource state between subsequent commands #4245

gents83 opened this issue Oct 16, 2023 · 3 comments · Fixed by #4782
Labels
api: vulkan Issues with Vulkan type: bug Something isn't working

Comments

@gents83
Copy link
Contributor

gents83 commented Oct 16, 2023

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 teoxoy added type: bug Something isn't working api: vulkan Issues with Vulkan labels Oct 16, 2023
@teoxoy teoxoy added this to the WebGPU Specification V1 milestone Oct 16, 2023
@cwfitzgerald
Copy link
Member

@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.

@gents83
Copy link
Contributor Author

gents83 commented Oct 16, 2023

Sure! Forcing it in the following way was luckily resulting in an always reproducible issue:

        case.create_command_encoder();
        case.discard_depth();
        let submit_index = case.submit_command_encoder();
        case.wait_for_submit(submit_index);

        case.create_command_encoder();
        case.discard_stencil();
        let submit_index = case.submit_command_encoder();
        case.wait_for_submit(submit_index);

        case.create_command_encoder();
        case.copy_texture_to_buffer();
        let submit_index = case.submit_command_encoder();
        case.wait_for_submit(submit_index);

@gents83
Copy link
Contributor Author

gents83 commented Nov 27, 2023

Closed by #4782

@gents83 gents83 closed this as completed Nov 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: vulkan Issues with Vulkan type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants