On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kra...@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 > >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
