From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
Ben Skeggs <bskeggs@redhat.com>,
"mesa-dev@lists.freedesktop.org" <mesa-dev@lists.freedesktop.org>
Subject: Re: [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
Date: Mon, 23 Jun 2014 09:17:22 +0200 [thread overview]
Message-ID: <53A7D482.70108@canonical.com> (raw)
In-Reply-To: <CAKb7Uvjq0iKMM2sG0F+Q=BR6dftJUJL8qGnuV_CAVexYhW1DUA@mail.gmail.com>
op 21-06-14 14:12, Ilia Mirkin schreef:
> On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst
> <maarten.lankhorst@canonical.com> wrote:
>> nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the
>> entire notifier, and use a offset in nv30_context_kick_notify.
> It would be great if you could detail the list of transformations that
> were done in the commit description, as well as what the "new way" is
> (if any) for the various concepts.
I moved the pushbuf and fences to each context separately. The PUSH_KICK on context switch ensures
that the previous context is flushed.
> This change doesn't have any of the locking -- is that coming in a
> future change? Otherwise we're still vulnerable to multiple threads
> trying to render at the same time. (Now with screen sharing, even if
> they end up with separate screens, we'd still be in trouble.)
I haven't done any locking changes, because I don't believe locking is the answer here.
With each context having its own pushbuf we can ensure that things aren't flushed, so
on flush it should assume all state is dirty. After this is done the PUSH_KICK of the old
context on context switch can be removed, and suddenly the driver is thread-safe because
only the pushbuf to kernel command submission could race. ;-)
> I'm still a bit concerned with moving the fence stuff to the
> context... there might be an assumption in gallium that fences are
> context-independent, in which case you need to make sure to have just
> a single fence shared by everything...
I don't think that this is the case, because it's very rare that gallium uses multiple contexts simultaneously.
(Except vdpau interop, which does flush explicitly.)
> Have you done a full piglit run on this (with the glx tests, for good
> measure) on nv30/nv50/nvc0? If so, can you share the results files
> somewhere?
No not yet. But I did confirm that glxgears and glxinfo didn't regress on my nv43, nv96 and nvc0. :-)
~Maarten
next prev parent reply other threads:[~2014-06-23 7:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 6:33 [PATCH try 2 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen Maarten Lankhorst
[not found] ` <539FE12C.90900-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2014-06-17 6:34 ` [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context Maarten Lankhorst
2014-06-21 12:12 ` Ilia Mirkin
2014-06-23 7:17 ` Maarten Lankhorst [this message]
2014-06-23 7:24 ` Ben Skeggs
2014-06-23 7:39 ` Maarten Lankhorst
2014-06-23 7:57 ` Ben Skeggs
[not found] ` <53A7D482.70108-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2014-06-23 14:54 ` [Mesa-dev] " Ilia Mirkin
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=53A7D482.70108@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=bskeggs@redhat.com \
--cc=imirkin@alum.mit.edu \
--cc=mesa-dev@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
/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.