[Mesa-dev] [PATCH 3/3] anv: Don't record the handle in the relocation

[Chris Wilson]

On Thu, May 11, 2017 at 09:29:40AM -0700, Jason Ekstrand wrote:
>    On Thu, May 11, 2017 at 12:42 AM, Chris Wilson
>    <[1]chris at chris-wilson.co.uk> wrote:
> 
>      On Wed, May 10, 2017 at 04:08:55PM -0700, Jason Ekstrand wrote:
>      > We use the look-up table mechanism for relocations so this isn't the
>      > value we want.  The correct value is filled out at execbuf2 time by
>      > anv_cmd_buffer_process_relocs.
>      > ---
>      >  src/intel/vulkan/anv_batch_chain.c | 2 +-
>      >  1 file changed, 1 insertion(+), 1 deletion(-)
>      >
>      > diff --git a/src/intel/vulkan/anv_batch_chain.c
>      b/src/intel/vulkan/anv_batch_chain.c
>      > index cc4f92e..5811503 100644
>      > --- a/src/intel/vulkan/anv_batch_chain.c
>      > +++ b/src/intel/vulkan/anv_batch_chain.c
>      > @@ -165,7 +165,7 @@ anv_reloc_list_add(struct anv_reloc_list *list,
> 
>      Just before this is a comment talking about using LUT - you already are.
>      It's relevant as the invalid target_handle for LUT is -1 and 0 for !LUT.
> 
>    Right.  So now the kernel will fail to execbuf if we ever don't fill the
>    value out rather than just doing the wrong thing.  Would you like a
>    comment about that in the commit message or something?

If you are feeling like adding a sentence, I would add it to
setup_execbuf_for_cmd_buffer() where you explain the conditions for
NO_RELOC. Explaining the difference there (or a bit earlier?) for setting
LUT and how it means you have to walk the reloc[] after completing the execobj[]
earlier in the function.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre