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]ch...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
