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