<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 2:29 AM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 11, 2020 at 04:36:16PM -0700, Gurchetan Singh wrote:<br>
> On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br>
> <br>
> >   Hi,<br>
> ><br>
> > > I should've been more clear -- this is an internal cleanup/preparation<br>
> > and<br>
> > > the per-context changes are invisible to host userspace.<br>
> ><br>
> > Ok, it wasn't clear that you don't flip the switch yet.  In general the<br>
> > commit messages could be a bit more verbose ...<br>
> ><br>
> > I'm wondering though why we need the new fence_id in the first place.<br>
> > Isn't it enough to have per-context (instead of global) last_seq?<br>
> ><br>
> <br>
> Heh, that was to leave open the possibility of multiple timelines per<br>
> context.  Roughly speaking,<br>
> <br>
> V2 -- multiple processes<br>
> V3 -- multiple processes and multiple threads (due to VK multi-threaded<br>
> command buffers)<br>
> <br>
> I think we all agree on V2.  It seems we still have to discuss V3<br>
> (multi-queue, thread pools, a fence context associated with each thread) a<br>
> bit more before we start landing pieces.<br>
<br>
While thinking about the whole thing a bit more ...<br>
Do we need virtio_gpu_ctrl_hdr->fence_id at all?<br></blockquote><div><br></div><div>A fence ID could be useful for sharing fences across virtio devices.  Think FENCE_ASSIGN_UUID, akin to  RESOURCE_ASSIGN_UUID (+dstevens@).</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">
At virtio level it is pretty simple:  The host completes the SUBMIT_3D<br>
virtio command when it finished rendering, period. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the guest side we don't need the fence_id.  The completion callback<br>
gets passed the virtio_gpu_vbuffer, so it can figure which command did<br>
actually complete without looking at virtio_gpu_ctrl_hdr->fence_id.<br>
<br>
On the host side we depend on the fence_id right now, but only because<br>
that is the way the virgl_renderer_callbacks->write_fence interface is<br>
designed.  We have to change that anyway for per-context (or whatever)<br>
fences, so it should not be a problem to drop the fence_id dependency<br>
too and just pass around an opaque pointer instead.<br></blockquote><div><br></div><div>For multiple GPU timelines per context, the (process local) sync object handle looks interesting:</div><div><br></div><div><a href="https://patchwork.kernel.org/patch/9758565/" target="_blank">https://patchwork.kernel.org/patch/9758565/</a><br></div><div><br></div><div>Some have extended EXECBUFFER to support this flow:</div><div><br></div><div><a href="https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.com" target="_blank">https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.com</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
cheers,<br>
  Gerd<br>
<br>
</blockquote></div></div>