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

Chia-I Wu olvaffe at gmail.com
Thu Mar 12 00:43:32 UTC 2020


On Wed, Mar 11, 2020 at 4:36 PM Gurchetan Singh
<gurchetansingh at chromium.org> wrote:
>
>
>
> 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,
Yeah, I think we will need multiple timelines per context.

>
> 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.
In addition to multiple threads, we should also consider multiple VkQueues.

I will start with... how many timelines do we want to expose per
context?  In my mind, it goes like

V1: 1 timeline per virtqueue (there is one timeline for ctrlq right now)
V2: 1 timeline per context (VK and GL on different timelines)
V3: N timelines per context (each VkQueue in a VK context gets a timeline?)
V4: N+M timelines per context (each CPU thread also gets a timeline?!?!)

I certainly don't know if V4 is a good idea or not...



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


More information about the dri-devel mailing list