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

[Gurchetan Singh]

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?
>

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.


> > 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 ...
>
> 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.
>
> cheers,
>   Gerd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200311/8d9d6dea/attachment.htm>