[Mesa-dev] Buffer update assert with multiple contexts.

[c***@gmail.com]

I'm hitting this assert in radeonsi: si_descriptors.c:1414:
si_desc_reset_buffer_offset: Assertion `old_buf_va <= old_desc_va' failed.

It seems to happen when a buffer is updated after being bound (as a
uniform buffer) on multiple contexts in a sharing group. If it's bound
on context A and B, then reallocated (BufferSubData) on context A, the
descriptor on context B is never updated, so the next time the buffer is
updated on B, you hit this assert.

I've attached a test for piglit, which shows the assert, and also shows
that the updated buffer contents aren't used when the buffer is updated
from another context. The test does:

- create context A+B
- make A current
- create buffer
- set buffer content to red
- bind buffer as uniform
- draw quad with uniform colour
- make B current
- bind buffer as uniform
- draw quad with uniform colour
- set buffer content to green
- draw quad with uniform colour
- make A current
- draw quad with uniform colour
** this one ends up red
- set buffer content to blue
** this results in the assert
- draw quad with uniform colour

Setting all resources as shared stops the assert and the incorrect (?)
output:

--- a/src/gallium/auxiliary/util/u_threaded_context.c
+++ b/src/gallium/auxiliary/util/u_threaded_context.c
@@ -265,7 +265,7 @@ threaded_resource_init(struct pipe_resource *res)
tres->latest = &tres->b;
util_range_init(&tres->valid_buffer_range);
tres->base_valid_buffer_range = &tres->valid_buffer_range;
- tres->is_shared = false;
+ tres->is_shared = true;
tres->is_user_ptr = false;
}

I've tested mesa 17.1, 17.2, 17.3, and master, and they all seem to
behave the same way.

Is this a bug, or am I misunderstanding what's allowed with shared
buffers? I haven't found any clear documentation on sharing.

Assuming it's a bug, does anyone have any thoughts on fixing it? As far
as I can tell there's currently no way for buffers to be marked as
'is_shared'. Getting the descriptor rebinding working for multiple
contexts seems like it would be tricky.