From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25261C43460 for ; Tue, 20 Apr 2021 16:25:49 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BB7C7613CE for ; Tue, 20 Apr 2021 16:25:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB7C7613CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BF1876E86B; Tue, 20 Apr 2021 16:25:47 +0000 (UTC) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by gabe.freedesktop.org (Postfix) with ESMTPS id B72DB6E869; Tue, 20 Apr 2021 16:25:45 +0000 (UTC) Received: by mail-pl1-x62e.google.com with SMTP id p16so15997684plf.12; Tue, 20 Apr 2021 09:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3olkwhs1InWkMJ/RRttEUmBfTAZ5d8pWrvCEODN8Kdc=; b=FjDRAjPuatXktpmflw1VX4M8vW2uW0MoteUQsdrfmU9aiJcVqRmvHRUHxslw3y+XxL Q8A69o+Lwt3tmptmvnVZb4Sa14/5acu0GPcdxPT4Kg34FAOclUP5Y3ecNmDdRbWJBJ1O jzqQbHJZBl0mk+6vTmDzq6F63tw0Gbh7407I83QC1R3YTSBRNj4/S1N/4RRARGhzTi8M NBIwhN05pAvNf3CfleEABPG4seGeKpcJZx6gW+gvoqBVzRJYQNUVQaVTi/omUNY2NPmL hjc0VSGJKGfkUx7KjLBiCC6AmfY8IcisC0cMitpQA3SKngPmEyPnQEqUqLGBHyIr+cHu 8LlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3olkwhs1InWkMJ/RRttEUmBfTAZ5d8pWrvCEODN8Kdc=; b=qrqMB/FNUkXOGesfbyhMtXK2+NoVnsLN6Q9cj39Q8O2sR4JOMxlyW6l1mEY9xkt5/k qzlKc5I9S6W6iCEhXDrZ9Y5CRH58IRSSX71+9KUI31ILchCesUgK+q8Kady+G02N3ZbN EVVXyujS68Y7bANDjxsta3Ne0L1EQ/EXkqzMnApQvwQBd2MRbzf/JAU/23HWBGocFTNd oy3U5+22X4pzKSWOUaLGhMRAcVlLXIdPV9Wss0Q6zCbBWlWoCsEiXok9xWLB/7KqiMdu zQyw8rKJRcayCvACGxiFGlg2FxvMQ6RQvSEK6wrcEwiFuKt+x8qAMmO9hHJeZ3kGImM/ TzOQ== X-Gm-Message-State: AOAM531D1Wbrpch1glX8L08Uh44Wxiz1tLWZsp9e9irlg4IoURYC41CL o2lEWMkiIvvNfg3zxF89DMXYy99bMf3gg9wwR+DD6zkadtk= X-Google-Smtp-Source: ABdhPJxY/H61IK95LvspQUjew7+hhaJ84u4qgi//JhYah23e8zY0kWR5gyKNoesVwtNLHa3Hqkz7581/IIOi4NVuUMc= X-Received: by 2002:a17:902:b602:b029:e6:cabb:10b9 with SMTP id b2-20020a170902b602b02900e6cabb10b9mr29300317pls.47.1618935945361; Tue, 20 Apr 2021 09:25:45 -0700 (PDT) MIME-Version: 1.0 References: <136d3b55-ff1e-c47b-d443-22bd27427956@gmail.com> <8e5026aa-599e-52d0-4959-6c3bcc16cb76@gmail.com> In-Reply-To: From: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Date: Tue, 20 Apr 2021 12:25:09 -0400 Message-ID: Subject: Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal To: Daniel Stone X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel , ML Mesa-dev Content-Type: multipart/mixed; boundary="===============0452867734==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============0452867734== Content-Type: multipart/alternative; boundary="000000000000effc4205c069e5c4" --000000000000effc4205c069e5c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Daniel, imagine hardware that can only do what Windows does: future fences signalled by userspace whenever userspace wants, and no kernel queues like we have today. The only reason why current AMD GPUs work is because they have a ring buffer per queue with pointers to userspace command buffers followed by fences. What will we do if that ring buffer is removed? Marek On Tue, Apr 20, 2021 at 11:50 AM Daniel Stone wrote: > Hi, > > On Tue, 20 Apr 2021 at 16:16, Christian K=C3=B6nig < > ckoenig.leichtzumerken@gmail.com> wrote: > >> Am 20.04.21 um 17:07 schrieb Daniel Stone: >> >> If the compositor no longer has a guarantee that the buffer will be read= y >> for composition in a reasonable amount of time (which dma_fence gives us= , >> and this proposal does not appear to give us), then the compositor isn't >> trying to use the buffer for compositing, it's waiting asynchronously on= a >> notification that the fence has signaled before it attempts to use the >> buffer. >> >> Marek's initial suggestion is that the kernel signal the fence, which >> would unblock composition (and presumably show garbage on screen, or at >> best jump back to old content). >> >> My position is that the compositor will know the process has crashed >> anyway - because its socket has been closed - at which point we destroy = all >> the client's resources including its windows and buffers regardless. >> Signaling the fence doesn't give us any value here, _unless_ the composi= tor >> is just blindly waiting for the fence to signal ... which it can't do >> because there's no guarantee the fence will ever signal. >> >> >> Yeah, but that assumes that the compositor has change to not blindly wai= t >> for the client to finish rendering and as Daniel explained that is rathe= r >> unrealistic. >> >> What we need is a fallback mechanism which signals the fence after a >> timeout and gives a penalty to the one causing the timeout. >> >> That gives us the same functionality we have today with the in software >> scheduler inside the kernel. >> > > OK, if that's the case then I think I'm really missing something which > isn't explained in this thread, because I don't understand what the > additional complexity and API change gains us (see my first reply in this > thread). > > By way of example - say I have a blind-but-explicit compositor that takes > a drm_syncobj along with a dmabuf with each client presentation request, > but doesn't check syncobj completion, it just imports that into a > VkSemaphore + VkImage and schedules work for the next frame. > > Currently, that generates an execbuf ioctl for the composition (ignore KM= S > for now) with a sync point to wait on, and the kernel+GPU scheduling > guarantees that the composition work will not begin until the client > rendering work has retired. We have a further guarantee that this work wi= ll > complete in reasonable time, for some value of 'reasonable'. > > My understanding of this current proposal is that: > * userspace creates a 'present fence' with this new ioctl > * the fence becomes signaled when a value is written to a location in > memory, which is visible through both CPU and GPU mappings of that page > * this 'present fence' is imported as a VkSemaphore (?) and the userspace > Vulkan driver will somehow wait on this value either before submitting > work or as a possibly-hardware-assisted GPU-side wait (?) > * the kernel's scheduler is thus eliminated from the equation, and every > execbuf is submitted directly to hardware, because either userspace knows > that the fence has already been signaled, or it will issue a GPU-side wai= t > (?) > * but the kernel is still required to monitor completion of every fence > itself, so it can forcibly complete, or penalise the client (?) > > Lastly, let's say we stop ignoring KMS: what happens for the > render-with-GPU-display-on-KMS case? Do we need to do the equivalent of > glFinish() in userspace and only submit the KMS atomic request when the G= PU > work has fully retired? > > Clarifying those points would be really helpful so this is less of a > strawman. I have some further opinions, but I'm going to wait until I > understand what I'm actually arguing against before I go too far. :) The > last point is very salient though. > > Cheers, > Daniel > --000000000000effc4205c069e5c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Daniel, imagine hardware that can only do what Window= s does: future fences signalled by userspace whenever userspace wants, and = no kernel queues like we have today.

The only reas= on why current AMD GPUs work is because they have a ring buffer per queue w= ith pointers to userspace command buffers followed by fences. What will we = do if that ring buffer is removed?

Marek
=

= On Tue, Apr 20, 2021 at 11:50 AM Daniel Stone <daniel@fooishbar.org> wrote:
Hi,
On = Tue, 20 Apr 2021 at 16:16, Christian K=C3=B6nig <ckoenig.leichtzumerken@gmail= .com> wrote:
=
Am 20.04.21 um 17:07 schrieb Daniel Stone:
=20
If the compositor no longer has a guarantee that the buffer will be ready for composition in a reasonable amount of time (which dma_fence gives us, and this proposal does not appear to give us), then the compositor isn't trying to use the buffer for compositing, it's waiting asynchronously on a notification that the fence has signaled before it attempts to use the buffer.

Marek's initial suggestion is that the kernel signal the fence, which would unblock composition (and presumably show garbage on screen,=C2=A0or at best jump back to old content).

My position is that the compositor will know the process has crashed anyway - because its socket has been closed - at which point we destroy all the client's resources including its windows and buffers regardless. Signaling the fence doesn't give us any value here, _unless_ the compositor is just blindly waiting for the fence to signal ... which it can't do because there's no guarantee the fence will ev= er signal.

Yeah, but that assumes that the compositor has change to not blindly wait for the client to finish rendering and as Daniel explained that is rather unrealistic.

What we need is a fallback mechanism which signals the fence after a timeout and gives a penalty to the one causing the timeout.

That gives us the same functionality we have today with the in software scheduler inside the kernel.

OK, if that's the case then I think I'm really missing som= ething which isn't explained in this thread, because I don't unders= tand what the additional=C2=A0complexity and API change gains us (see my fi= rst reply in this thread).

By way of example - say= I have a blind-but-explicit compositor that takes a drm_syncobj along with= a dmabuf with each client presentation request, but doesn't check sync= obj completion, it just imports that into a VkSemaphore=C2=A0+ VkImage and = schedules work for the next frame.

Currently, that= generates an execbuf=C2=A0ioctl for the composition (ignore KMS for now) w= ith a sync point to wait on, and the kernel+GPU scheduling guarantees that = the composition work will not begin until the client rendering work has ret= ired. We have a further guarantee that this work will complete in reasonabl= e time, for some value of 'reasonable'.

My= understanding of this current proposal is that:
* userspace crea= tes a 'present fence' with this new ioctl
* the fence bec= omes signaled when a value is written to a location in memory, which is vis= ible through both CPU and GPU mappings of that page
* this 'p= resent fence' is imported as a VkSemaphore=C2=A0(?) and the userspace V= ulkan driver will somehow wait on this value=C2=A0 either before submitting= work or as a possibly-hardware-assisted GPU-side wait (?)
* the = kernel's scheduler is thus eliminated from the equation, and every exec= buf=C2=A0is submitted directly to hardware, because either userspace knows = that the fence has already been signaled, or it will issue a GPU-side wait = (?)
* but the kernel is still required to monitor completion of e= very fence itself, so it can forcibly complete, or penalise the client (?)<= /div>

Lastly, let's say we stop ignoring KMS: what h= appens for the render-with-GPU-display-on-KMS case? Do we need to do the eq= uivalent of glFinish() in userspace and only submit the KMS atomic request = when the GPU work has fully retired?

Clarifying th= ose points would be really helpful so this is less of a strawman. I have so= me further opinions, but I'm going to wait until I understand what I= 9;m actually arguing against before I go too far. :) The last point is very= salient though.

Cheers,
Daniel=C2=A0
--000000000000effc4205c069e5c4-- --===============0452867734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0452867734==--