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? > > > 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
