Fix buffer updates going to the wrong cmd buffer if barriers were 0

[darksylinc]

From what I could see only SSAO & SSIL were affected when they both call:

int zero[1] = { 0 };
RD::get_singleton()->buffer_update(ssao.importance_map_load_counter, 0, sizeof(uint32_t), &zero, 0);

int zero[1] = { 0 };
RD::get_singleton()->buffer_update(ssil.importance_map_load_counter, 0, sizeof(uint32_t), &zero, 0);

Also documented what setup_command_buffer & draw_command_buffer are for.

I placed breakpoints to see who calls buffer_update() with barriers = 0 and those two were the only calls.

@DarioSamo found this bug while working on Acyclic Render Graphs, but asked me to look deeper into it as he is occupied with the ARG.

Fortunately it doesn't seem like the damage is large:

• When buffer_update calls _buffer_update with the wrong queue, buffer_update has the _THREAD_SAFE_METHOD_ macro
• All the other functions that call _buffer_update directly also use the _THREAD_SAFE_METHOD_ macro.

So there are no race conditions on the CPU side.

As for the GPU side it's a little more horrible:

What Godot wanted to do:

1. Execute SSAO (or SSIL).
2. Reset the counter to 0 for the next frame.

What Godot ends up doing:

1. Execute SSAO (or SSIL).
2. Reset the counter to 0 "whenever you feel like". Before SSAO, during SSAO, after SSAO.

What most likely ends up happening most of the time:

1. Reset the counter to 0 at the beginning of the frame.
2. Execute SSAO (or SSIL).

With my fix, I had to add BARRIER_MASK_TRANSFER to compute_list_end so that the reset is guaranteed to happen after the compute work (though it could probably be moved far elsewhere, e.g. at the end of the frame).

[clayjohn]

Looks good. Nice to have this cleaned up.

Let's merge this early in the 4.3 dev cycle

[akien-mga]

Thanks!

[YuriSizov]

Cherry-picked for 4.2.1.