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=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 A3EA0C10DCE for ; Wed, 18 Mar 2020 07:27:46 +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 6CDFA20768 for ; Wed, 18 Mar 2020 07:27:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pwizgFNE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CDFA20768 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 C833F89CF6; Wed, 18 Mar 2020 07:27:45 +0000 (UTC) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0CE1789CF6; Wed, 18 Mar 2020 07:27:45 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id a25so28885435wrd.0; Wed, 18 Mar 2020 00:27:44 -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=QSMihYeOGG/HiqnP/AX830zIskcO0mtrshGzaPZRRQg=; b=pwizgFNEYVZz+fPR+tMDio40C/gqChzqqn+ulB00rE4aEgn8SDtqEMLxew2GgnSL1E t49tZrX2xgFoS52P0X/Jfn+7Bz7QaBOnpqgSfizkYUsPbthZR93/znCtm421O+pzhsoT gGZiPWGUUg/Yz3jsG+N9nh9OzskjxlgVsBX9Md9keHr/bWQ+5Fxq/XtnIV9mfIDAzadb mkd/PdTLM0Pj3DkLaDFeAZBc2BGc+c6veUYtJZ05qgusDWzW1wn6Q6rmRTo14fffmj41 9Ooj+R6W5Tc/8vPkV5pSFNamFAcxQ0quumqAkHUG0L7VH8vF2FgEX3YwuKGTNZP3bzL8 pqqA== 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=QSMihYeOGG/HiqnP/AX830zIskcO0mtrshGzaPZRRQg=; b=e2/aKLftvjTfR2CT+8yCI9LRcQJOTaNmKQ8rx3hrtOeE6Ge/HzDmjQv3rYO2zOA/Dq PYZpt/H3rogsXcSjLmXHQRM/8w+mMtELDIH14woKOEPWgexRAFQEGcs2Db55NCDAIr7b O5irHFHpe7rKLuPbS8IXrZ03ehxdF6VlUPok71IpIuELiYauG4sVbJG/4g72b57Ac8dH mlwSj2TTqLloa4ByeXpEO4SmgztJdARWqaEd+k9fSfHkbTOv7RzMUrsZsHzsfbZXv79o XaQzy6HA7hGP1CqHuVujVSeo7XlwaVVqmW2yun57juc8ExHa8PYd2Hvqa76c3MNIoqZr 8RhQ== X-Gm-Message-State: ANhLgQ1XqFreyNvYswNjfempsQX37XuFZc6oj+9nz9xNv0rWhmUMDbvX fRbHa06jlBAsQQuNDsZb16eSXC8UVRHHYf5NpqM= X-Google-Smtp-Source: ADFU+vtPlnevW7Td5WqBZuOyfh2BJ236ChxGKrxEZG7CawLl/GBqgQMOfeLQUeI1ISCwD3fKxpvb8gfT+M2ApXA7/zE= X-Received: by 2002:adf:ce8e:: with SMTP id r14mr3850543wrn.415.1584516463649; Wed, 18 Mar 2020 00:27:43 -0700 (PDT) MIME-Version: 1.0 References: <33d1749d876a83416c44671efcb37c74f87d1bd4.camel@ndufresne.ca> <20200316102034.GA30883@pendragon.ideasonboard.com> <20200316211502.GW4732@pendragon.ideasonboard.com> <74477a20fa78758dd6cf8c32d7a77d1cccf2646f.camel@ndufresne.ca> <3e522876ec0287b69483c65aa1e7ba1ded536ec6.camel@lynxeye.de> <949b8373908a9895e97981e872d6e35dcaaba632.camel@lynxeye.de> In-Reply-To: From: Jacob Lifshay Date: Wed, 18 Mar 2020 00:27:30 -0700 Message-ID: Subject: Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem To: Jason Ekstrand 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: Daniel Vetter , xorg-devel , "open list:DMA BUFFER SHARING FRAMEWORK" , Maling list - DRI developers , "wayland-devel @ lists . freedesktop . org" , Laurent Pinchart , ML mesa-dev , Nicolas Dufresne , Discussion of the development of and with GStreamer Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 17, 2020 at 11:35 PM Jason Ekstrand wrote: > > On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay wrote: > > > > The main issue with doing everything immediately is that a lot of the > > function calls that games expect to take a very short time (e.g. > > vkQueueSubmit) would instead take a much longer time, potentially > > causing problems. > > Do you have any evidence that it will cause problems? What I said > above is what switfshader is doing and they're running real apps and > I've not heard of it causing any problems. It's also worth noting > that you would only really have to stall at sync_file export. You can > async as much as you want internally. Ok, seems worth trying out. > > One idea for a safe userspace-backed sync_file is to have a step > > counter that counts down until the sync_file is ready, where if > > userspace doesn't tell it to count any steps in a certain amount of > > time, then the sync_file switches to the error state. This way, it > > will error shortly after a process deadlocks for some reason, while > > still having the finite-time guarantee. > > > > When the sync_file is created, the step counter would be set to the > > number of jobs that the fence is waiting on. > > > > It can also be set to pause the timeout to wait until another > > sync_file signals, to handle cases where a sync_file is waiting on a > > userspace process that is waiting on another sync_file. > > > > The main issue is that the kernel would have to make sure that the > > sync_file graph doesn't have loops, maybe by erroring all sync_files > > that it finds in the loop. > > > > Does that sound like a good idea? > > Honestly, I don't think you'll ever be able to sell that to the kernel > community. All of the deadlock detection would add massive complexity > to the already non-trivial dma_fence infrastructure and for what > benefit? So that a software rasterizer can try to pretend to be more > like a GPU? You're going to have some very serious perf numbers > and/or other proof of necessity if you want to convince the kernel to > people to accept that level of complexity/risk. "I designed my > software to work this way" isn't going to convince anyone of anything > especially when literally every other software rasterizer I'm aware of > is immediate and they work just fine. After some further research, it turns out that it will work to have all the sync_files that a sync_file needs to depend on specified at creation, which forces the dependence graph to be a DAG since you can't depend on a sync_file that isn't yet created, so loops are impossible by design. Since kernel deadlock detection isn't actually required, just timeouts for the case of halted userspace, does this seem feasable? I'd guess that it'd require maybe 200-300 lines of code in a self-contained driver similar to the sync_file debugging driver mentioned previously but with the additional timeout code for safety. Jacob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel