From: Gurchetan Singh <gurchetansingh@chromium.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Chad Versace <chadversary@chromium.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>,
John Bates <jbates@chromium.org>
Subject: Re: [RFC PATCH 0/8] *** Per context fencing ***
Date: Wed, 11 Mar 2020 16:36:16 -0700 [thread overview]
Message-ID: <CAAfnVBm1eoGZY7yB8eqEC1eLk=v4dq--O2biQOnWDHCkmguOeA@mail.gmail.com> (raw)
In-Reply-To: <20200311103609.ei446gelkvbqrdzm@sirius.home.kraxel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1581 bytes --]
On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kraxel@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
>
>
[-- Attachment #1.2: Type: text/html, Size: 2270 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-03-11 23:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 1:08 [RFC PATCH 0/8] *** Per context fencing *** Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 1/8] drm/virtio: use fence_id when processing fences Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 2/8] drm/virtio: allocate a fence context for every 3D context Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 3/8] drm/virtio: plumb virtio_gpu_fpriv to virtio_gpu_fence_alloc Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 4/8] drm/virtio: rename sync_seq and last_seq Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 5/8] drm/virtio: track fence_id in virtio_gpu_fence Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 6/8] virtio/drm: rework virtio_fence_signaled Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 7/8] drm/virtio: check context when signaling Gurchetan Singh
2020-03-10 1:08 ` [RFC PATCH 8/8] drm/virtio: enable per context fencing Gurchetan Singh
2020-03-10 7:43 ` [RFC PATCH 0/8] *** Per context fencing *** Gerd Hoffmann
2020-03-10 22:57 ` Gurchetan Singh
2020-03-11 10:36 ` Gerd Hoffmann
2020-03-11 17:35 ` Chia-I Wu
2020-03-12 9:06 ` Gerd Hoffmann
2020-03-11 23:36 ` Gurchetan Singh [this message]
2020-03-12 0:43 ` Chia-I Wu
2020-03-12 9:10 ` Gerd Hoffmann
2020-03-12 9:29 ` Gerd Hoffmann
2020-03-12 23:08 ` Gurchetan Singh
2020-03-13 21:20 ` Chia-I Wu
2020-03-16 7:44 ` Gerd Hoffmann
2020-03-17 20:32 ` Chia-I Wu
2020-03-18 6:40 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAfnVBm1eoGZY7yB8eqEC1eLk=v4dq--O2biQOnWDHCkmguOeA@mail.gmail.com' \
--to=gurchetansingh@chromium.org \
--cc=chadversary@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jbates@chromium.org \
--cc=kraxel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.