[Mesa-dev] [PATCH 3/9] r600: overhaul buffer resource query.

[Roland Scheidegger]

Am 06.02.2018 um 06:04 schrieb Dave Airlie:
> On 6 February 2018 at 14:12, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 05.02.2018 um 05:29 schrieb Dave Airlie:
>>> From: Dave Airlie <airlied at 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 <airlied at 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