I think the debug code is confusing and not isolated. Might be better to remove it. We don't need that in production (I mean the cost of having a separate framebuffer + clear etc...), you can just use an empty framebuffer for that.
Use exp2 instead of pow(2, x). Try to apply this everywhere.
Be conservative in Z too. Bias far_box_t by step_size to have one more iteration before and after.
Im' not sure why you are changing that for the debug visuals.
This only works because max_v2 is a define. Use vs_inflate_vector.xy to avoid the confusion.
I didn't catch that first but has_next_pool_ is basically the list length. Might be worth renaming the variable.
I have to admit I'm a bit doubtful about what's the intent here. Is the lock thing inside the loop supposed to just slow down the waiting thread and avoid high CPU usage? This does feel hacky anyway.
As a side note, I think the patch is in mergeable state, that's why I approved it. But would like to see the small fixes be done first.
How does that work? Material can have different resources based on their flag (see EEVEE_material_bind_resources(à). Unless this is only for the vertex inputs and fragment outputs, these should be the same.
Maybe note what is the expected status of both parameters. I guess material can be in any state, whereas default_material should be compiled?
