Am 06.02.2018 um 06:04 schrieb Dave Airlie: > On 6 February 2018 at 14:12, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 05.02.2018 um 05:29 schrieb Dave Airlie: >>> From: Dave Airlie <airl...@redhat.com> >>> >>> This cleans up and fixes the previous fix even more. >>> >>> Buffers from textures start at max const, >>> buffers from buffers/images come in from the 168 offset. >>> >>> This fixes a bunch of: >>> KHR-GL45.shader_storage_buffer_object* >>> >>> Signed-off-by: Dave Airlie <airl...@redhat.com> >>> --- >>> src/gallium/drivers/r600/r600_shader.c | 15 ++++++++------- >>> 1 file changed, 8 insertions(+), 7 deletions(-) >>> >>> diff --git a/src/gallium/drivers/r600/r600_shader.c >>> b/src/gallium/drivers/r600/r600_shader.c >>> index 8c4460a5d5..32f24c071d 100644 >>> --- a/src/gallium/drivers/r600/r600_shader.c >>> +++ b/src/gallium/drivers/r600/r600_shader.c >>> @@ -7007,7 +7007,7 @@ static int do_vtx_fetch_inst(struct r600_shader_ctx >>> *ctx, boolean src_requires_l >>> return 0; >>> } >>> >>> -static int r600_do_buffer_txq(struct r600_shader_ctx *ctx, int reg_idx, >>> int offset) >>> +static int r600_do_buffer_txq(struct r600_shader_ctx *ctx, int reg_idx, >>> int offset, int eg_buffer_base) >> >> I think it would be nicer if you'd just stick to the offset parameter >> here. Just add both together in the caller - as far as this function is >> concerned two offsets don't really make sense. > > > Well it matters for the r600 path if I'm not mistaken. It just wants > id + offset, not the MAX_CONST or > other bits. >
Ah yes, right. Maybe things would be more obvious if r600_do_buffer_txq would just figure out offsets on its own? It already knows what the src reg is, so determining offset for sampler/buffer/image could be easily be done there. But as long as it works... Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev