<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 4, 2017 at 1:43 AM, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Jason Ekstrand (2017-08-04 02:25:21) > Vulkan allows you to do a submit whose only job is to wait on and > trigger semaphores. The easiest way for us to support that right > now is to insert a dummy execbuf. > --- > diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c > index 793e519..0f0aa22 100644 > --- a/src/intel/vulkan/anv_device.c > +++ b/src/intel/vulkan/anv_device.c > @@ -1014,6 +1014,28 @@ anv_device_init_border_colors(struct anv_device *device) > border_colors); > } > > +static void > +anv_device_init_trivial_batch(struct anv_device *device) > +{ > + anv_bo_init_new(&device->trivial_batch_bo, device, 4096); Is this created with ASYNC?</blockquote><div> No, it isn't but I'm happy to set the flag. This patch predates the ASYNC stuff, I believe. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Just thinking that you only want the external ordering constraints on this bo, and not accidentally serialize between contexts. </blockquote><div> </div><div>Is this really an issue? No other process will ever see this BO. I suppose the kernel is still doing unneeded flushing but this shouldn't cause cross-context synchronization. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > + void *map = anv_gem_mmap(device, device->trivial_batch_bo.gem_handle, > + 0, 4096, 0); > + > + struct anv_batch batch = { > + .start = map, > + .next = map, > + .end = map + 4096, > + }; > + > + anv_batch_emit(&batch, GEN7_MI_BATCH_BUFFER_END, bbe); > + anv_batch_emit(&batch, GEN7_MI_NOOP, noop); > + > + if (!device->info.has_llc) > + gen_clflush_range(map, batch.next - map); > + > + anv_gem_munmap(map, device->trivial_batch_bo.size); > +} > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h > index b599db3..bc67bb6 100644 > --- a/src/intel/vulkan/anv_private.h > +++ b/src/intel/vulkan/anv_private.h > @@ -745,6 +745,7 @@ struct anv_device { > struct anv_state_pool surface_state_pool; > > struct anv_bo workaround_bo; > + struct anv_bo trivial_batch_bo; Do you use all 4096 bytes of the workaround_bo, or could you spare 64? ;) </blockquote><div> </div><div>I could... Then again, I can also easily spare a single 4K page per context and prevent myself from accidentally overwriting my little batch. :-) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c > index 446c3de..9934fef 100644 > --- a/src/intel/vulkan/anv_queue.c > +++ b/src/intel/vulkan/anv_queue.c > @@ -159,6 +159,23 @@ VkResult anv_QueueSubmit( > pthread_mutex_lock(&device->mutex); > > for (uint32_t i = 0; i < submitCount; i++) { > + if (pSubmits[i].commandBufferCount == 0) { > + /* If we don't have any command buffers, we need to submit a dummy > + * batch to give GEM something to wait on. We could, potentially, > + * come up with something more efficient but this shouldn't be a > + * common case. > + */ > + result = anv_cmd_buffer_execbuf(device, NULL, > + pSubmits[i].pWaitSemaphores, > + pSubmits[i].waitSemaphoreCount, > + pSubmits[i].pSignalSemaphores, > + pSubmits[i].signalSemaphoreCount); Might as well just pass &pSubmits[i] along? </blockquote></div> </div><div class="gmail_extra">I can't. See below where we only pass the wait semaphores to the first execbuf in the batch and only pass the signal semaphores to the last. </div><div class="gmail_extra">--Jason </div></div>