dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	xorg-devel <xorg-devel@lists.x.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	"wayland-devel @ lists . freedesktop . org"
	<wayland-devel@lists.freedesktop.org>,
	Discussion of the development of and with GStreamer
	<gstreamer-devel@lists.freedesktop.org>,
	Jason Ekstrand <jason@jlekstrand.net>,
	ML mesa-dev <mesa-dev@lists.freedesktop.org>,
	linux-media@vger.kernel.org
Subject: Re: Plumbing explicit synchronization through the Linux ecosystem
Date: Tue, 17 Mar 2020 11:01:57 +0100	[thread overview]
Message-ID: <ea771b02-b74b-2a89-e55c-2977d641558d@daenzer.net> (raw)
In-Reply-To: <CAAxE2A5D2HaqjS52jymMbwOUEsaXG_cMeeA9_esqaC54-52Kgw@mail.gmail.com>

On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer <michel@daenzer.net> wrote:
>> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
>>> The synchronization works because the Mesa driver waits for idle (drains
>>> the GFX pipeline) at the end of command buffers and there is only 1
>>> graphics queue, so everything is ordered.
>>>
>>> The GFX pipeline runs asynchronously to the command buffer, meaning the
>>> command buffer only starts draws and doesn't wait for completion. If the
>>> Mesa driver didn't wait at the end of the command buffer, the command
>>> buffer would finish and a different process could start execution of its
>>> own command buffer while shaders of the previous process are still
>> running.
>>>
>>> If the Mesa driver submits a command buffer internally (because it's
>> full),
>>> it doesn't wait, so the GFX pipeline doesn't notice that a command buffer
>>> ended and a new one started.
>>>
>>> The waiting at the end of command buffers happens only when the flush is
>>> external (Swap buffers, glFlush).
>>>
>>> It's a performance problem, because the GFX queue is blocked until the
>> GFX
>>> pipeline is drained at the end of every frame at least.
>>>
>>> So explicit fences for SwapBuffers would help.
>>
>> Not sure what difference it would make, since the same thing needs to be
>> done for explicit fences as well, doesn't it?
> 
> No. Explicit fences don't require userspace to wait for idle in the command
> buffer. Fences are signalled when the last draw is complete and caches are
> flushed. Before that happens, any command buffer that is not dependent on
> the fence can start execution. There is never a need for the GPU to be idle
> if there is enough independent work to do.

I don't think explicit fences in the context of this discussion imply
using that different fence signalling mechanism though. My understanding
is that the API proposed by Jason allows implicit fences to be used as
explicit ones and vice versa, so presumably they have to use the same
signalling mechanism.


Anyway, maybe the different fence signalling mechanism you describe
could be used by the amdgpu kernel driver in general, then Mesa could
drop the waits for idle and get the benefits with implicit sync as well?


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-03-17 10:02 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 17:31 Plumbing explicit synchronization through the Linux ecosystem Jason Ekstrand
2020-03-11 19:21 ` Jason Ekstrand
2020-03-11 20:18   ` Nicolas Dufresne
2020-03-16 10:20     ` Laurent Pinchart
2020-03-16 12:55       ` Tomek Bury
2020-03-16 13:01         ` Laurent Pinchart
2020-03-16 13:34           ` Tomek Bury
2020-03-16 14:19         ` Daniel Stone
2020-03-16 15:33           ` Tomek Bury
2020-03-16 16:03             ` Tomek Bury
2020-03-16 16:04             ` Jason Ekstrand
2020-03-17  8:01               ` Simon Ser
2020-03-17 14:38                 ` Jason Ekstrand
2020-03-16 16:04             ` Daniel Stone
2020-03-16 17:11               ` Tomek Bury
2020-03-16 15:06       ` Jason Ekstrand
2020-03-16 21:15         ` Laurent Pinchart
2020-03-16 22:02           ` Jason Ekstrand
2020-03-17 15:33           ` Nicolas Dufresne
2020-03-17 16:27             ` Jason Ekstrand
2020-03-17 17:12               ` [Mesa-dev] " Jacob Lifshay
2020-03-17 17:18                 ` Jason Ekstrand
2020-03-19 10:34                   ` Daniel Vetter
2020-03-17 17:21                 ` Lucas Stach
2020-03-17 17:59                   ` Jacob Lifshay
2020-03-17 18:14                     ` Lucas Stach
2020-03-18  0:16                       ` Jacob Lifshay
2020-03-18  2:08                         ` Jason Ekstrand
2020-03-18  5:20                           ` Jacob Lifshay
2020-03-18  6:34                             ` Jason Ekstrand
2020-03-18  7:27                               ` Jacob Lifshay
2020-03-18 10:05                   ` Michel Dänzer
2020-03-18 13:54                     ` Nicolas Dufresne
2020-03-19 10:37                     ` Daniel Vetter
2020-03-19 15:45                 ` Adam Jackson
2020-03-17 18:21               ` Nicolas Dufresne
2020-03-19 10:42               ` Daniel Vetter
2020-03-17 17:34             ` [Mesa-dev] " Lucas Stach
2020-03-16 23:41   ` Roman Gilg
2020-03-17  3:37     ` Jason Ekstrand
2020-03-17  7:53       ` Jonas Ådahl
2020-03-11 23:02 ` Adam Jackson
2020-03-12 15:46   ` Jason Ekstrand
2020-03-13  1:37 ` Alexander E. Patrakov
2020-03-14  2:02 ` [Mesa-dev] " Marek Olšák
2020-03-16  2:49   ` Jason Ekstrand
2020-03-16  3:50     ` Marek Olšák
2020-03-16  9:57       ` Michel Dänzer
2020-03-16 18:33         ` Marek Olšák
2020-03-17 10:01           ` Michel Dänzer [this message]
2020-03-17 17:13             ` Marek Olšák
2020-03-19 10:51             ` Daniel Vetter
2020-03-19 19:54               ` Marek Olšák
2020-03-20  8:50                 ` Michel Dänzer

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=ea771b02-b74b-2a89-e55c-2977d641558d@daenzer.net \
    --to=michel@daenzer.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gstreamer-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=linux-media@vger.kernel.org \
    --cc=maraeo@gmail.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=wayland-devel@lists.freedesktop.org \
    --cc=xorg-devel@lists.x.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox