On Wed, Mar 11, 2020 at 4:36 PM Gurchetan Singh <gurchetansingh@xxxxxxxxxxxx> wrote: > > > > On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 >> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
