Re: [RFC PATCH 0/8] *** Per context fencing *** - Chia-I Wu

From: Chia-I Wu <olvaffe@gmail.com>
To: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: Chad Versace <chadversary@chromium.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	David Stevens <stevensd@chromium.org>,
	John Bates <jbates@chromium.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [RFC PATCH 0/8] *** Per context fencing ***
Date: Fri, 13 Mar 2020 14:20:27 -0700	[thread overview]
Message-ID: <CAPaKu7SgkdBaFcDU1O7T+mMyzqO5iR8qYJxFJmcYGp_Hfe3S0g@mail.gmail.com> (raw)
In-Reply-To: <CAAfnVBkTWy2pohv5kWWYwAa1yq14fRJrtN4GD7sF-h4inabH6Q@mail.gmail.com>

On Thu, Mar 12, 2020 at 4:08 PM Gurchetan Singh
<gurchetansingh@chromium.org> wrote:
>
>
>
> On Thu, Mar 12, 2020 at 2:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> On Wed, Mar 11, 2020 at 04:36:16PM -0700, Gurchetan Singh wrote:
>> > On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>> >
>> > >   Hi,
>> > >
>> > > > I should've been more clear -- this is an internal cleanup/preparation
>> > > and
>> > > > the per-context changes are invisible to host userspace.
>> > >
>> > > Ok, it wasn't clear that you don't flip the switch yet.  In general the
>> > > commit messages could be a bit more verbose ...
>> > >
>> > > I'm wondering though why we need the new fence_id in the first place.
>> > > Isn't it enough to have per-context (instead of global) last_seq?
>> > >
>> >
>> > Heh, that was to leave open the possibility of multiple timelines per
>> > context.  Roughly speaking,
>> >
>> > V2 -- multiple processes
>> > V3 -- multiple processes and multiple threads (due to VK multi-threaded
>> > command buffers)
>> >
>> > I think we all agree on V2.  It seems we still have to discuss V3
>> > (multi-queue, thread pools, a fence context associated with each thread) a
>> > bit more before we start landing pieces.
>>
>> While thinking about the whole thing a bit more ...
>> Do we need virtio_gpu_ctrl_hdr->fence_id at all?
>
>
> A fence ID could be useful for sharing fences across virtio devices.  Think FENCE_ASSIGN_UUID, akin to  RESOURCE_ASSIGN_UUID (+dstevens@).
>
>>
>> At virtio level it is pretty simple:  The host completes the SUBMIT_3D
>> virtio command when it finished rendering, period.
>>
>>
>> On the guest side we don't need the fence_id.  The completion callback
>> gets passed the virtio_gpu_vbuffer, so it can figure which command did
>> actually complete without looking at virtio_gpu_ctrl_hdr->fence_id.
>>
>> On the host side we depend on the fence_id right now, but only because
>> that is the way the virgl_renderer_callbacks->write_fence interface is
>> designed.  We have to change that anyway for per-context (or whatever)
>> fences, so it should not be a problem to drop the fence_id dependency
>> too and just pass around an opaque pointer instead.

I am still catching up, but IIUC, indeed I don't think the host needs
to depend on fence_id.  We should be able to repurpose fence_id.  On
the other hand, the VIRTIO_GPU_FLAG_FENCE flag is interesting, and it
indicates that the vbuf is on the host GPU timeline instead of the
host CPU timeline.

>
>
> For multiple GPU timelines per context, the (process local) sync object handle looks interesting:
>
> https://patchwork.kernel.org/patch/9758565/
>
> Some have extended EXECBUFFER to support this flow:
>
> https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.com

I think this only affects the kernel/userspace interface?  I know
there were works being done to support VK_KHR_timeline semaphore,
which is something we definitely want.  I don't know if it is the only
way for the userspace to gain the extension support.  I need to do my
homework...

>
>>
>> cheers,
>>   Gerd
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel