[RFC PATCH 0/8] *** Per context fencing ***

[Chia-I Wu]

On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kraxel at 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?
>
> > Multi-queue sounds very interesting indeed, especially with VK
> > multi-threaded command submission.  That to me is V3 rather than V2.. let's
> > start easy!
>
> Having v2 if we plan to obsolete it with v3 soon doesn't look like a
> good plan to me.  It'll make backward compatibility more complex for
> no good reason ...
I agree we want to study multi-queue a little bit before doing v2.  If
we do decide that multi-queue will be v3, we should at least design v2
in a forward-compatible way.

Every VK context (or GL context if we go multi-process GL) is
isolated.  I think there will need to be at least one virtqueue for
each VK context.  Can virtqueues be added dynamically?  Or can we have
fixed but enough (e.g., 64) virtqueues?

Multi-threaded command submission is not helped by multi-queue unless
we go with one virtqueue for each VKQueue in a VK context.  Otherwise,
multi-queue only makes context scheduling easier, which is not a
priority yet IMO.


>
> Also: Does virglrenderer render different contexts in parallel today?
> Only in case it does we'll actually get benefits from per-context
> fences.  But I think it doesn't, so there is no need to rush.
>
> I think we should better have a rough plan for parallel rendering first,
> then go start implementing the pieces needed.
It will be soon.  Each VK context will be rendered by a different
renderer process.  Besides, VK contexts and GL contexts are not on the
same timeline.  We don't want one to delay another by presenting a
unified timeline.


>
> cheers,
>   Gerd
>