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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 76291C433E4 for ; Wed, 15 Jul 2020 11:57:13 +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 4917B20658 for ; Wed, 15 Jul 2020 11:57:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="GPc9UHNo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4917B20658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 AC8AF6EB1B; Wed, 15 Jul 2020 11:57:12 +0000 (UTC) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by gabe.freedesktop.org (Postfix) with ESMTPS id D59F86EB1B for ; Wed, 15 Jul 2020 11:57:11 +0000 (UTC) Received: by mail-oo1-xc2b.google.com with SMTP id o36so398564ooi.11 for ; Wed, 15 Jul 2020 04:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S1vWkNDq8ilucIymWKAlkOAuy47r8e5xfL8ne720plc=; b=GPc9UHNokUUD2+AvdsbRTDT6CdqwFr7oTCqFELGIXmIAQ8jt6jrrgmzS5JEzf+qKKS uAbtqaJo2qH2sGi+gNHJ8YgCD27UTdLL1qLHgtvzPeWDoRslOUOwbzd1udNxvkwDfODK hRHO74djleERINZQEy/8t5QcyI3fT78h2RdQY= 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=S1vWkNDq8ilucIymWKAlkOAuy47r8e5xfL8ne720plc=; b=DtvK/xJcAqZYnNt7sGVmk59AvL7pQGTfeDzTCzfZRC+iUKHdWC4Ckv3NNkNhKaMcsl kfTtmCqbDoDpY8U3mh+XFS8NdnxZtNYXmSy0eTp6JYCYejEZ8oADaNUBzBqPjWjRslhl CY2rsvIE0EfbzCE5ZPVx3ytxM50UYj7Y3gDFaRORtWUWsCLoRB7z88P1GJpRCSUlzDco Nmluq9gXda2Xj7xJ6CvFyiIFIFXnJincHZ4nWWBXYg2wOvXfaciOkTU8Uwpi2M4orhbL gXv0uoL7vioYOHFSdOLX1/yvw4XGPGIRqKwuluLK+yUqqSBAJyZjDbeHcOKV9tsIbP5G HVnw== X-Gm-Message-State: AOAM533M+d8PtAY5ZwX5WVwxdaDRCyI9Oc+6DtmPL6yQRqmkN5aA2quo JfLArW5OnH8mRYMoSlVTOf/l4N/IkVyYEV9lB6AxZQ== X-Google-Smtp-Source: ABdhPJy4wqJRnsXmPU3pvsNn0LdFwI8ca825p+RaqrYygUhl1NSen9TJGsaiBzm4eBllGYE2AL8EjkAqTsh3Ezyt3CY= X-Received: by 2002:a4a:9653:: with SMTP id r19mr9030351ooi.85.1594814231128; Wed, 15 Jul 2020 04:57:11 -0700 (PDT) MIME-Version: 1.0 References: <20200715100432.13928-1-chris@chris-wilson.co.uk> <159480926758.13728.809663901463022623@build.alporthouse.com> In-Reply-To: From: Daniel Vetter Date: Wed, 15 Jul 2020 13:57:00 +0200 Message-ID: Subject: Re: [Intel-gfx] sw_sync deadlock avoidance, take 3 To: Daniel Stone , Rob Herring , John Stultz 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: intel-gfx , Chris Wilson , ML dri-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > Hi, > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen wrote: > > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson wrote: > > > Maybe now is the time to ask: are you using sw_sync outside of > > > validation? > > > > Yes, this is used as part of the Android stack on Chrome OS (need to > > see if ChromeOS specific, but > > https://source.android.com/devices/graphics/sync#sync_timeline > > suggests not) > > Android used to mandate it for their earlier iteration of release > fences, which was an empty/future fence having no guarantee of > eventual forward progress until someone committed work later on. For > example, when you committed a buffer to SF, it would give you an empty > 'release fence' for that buffer which would only be tied to work to > signal it when you committed your _next_ buffer, which might never > happen. They removed that because a) future fences were a bad idea, > and b) it was only ever useful if you assumed strictly > FIFO/round-robin return order which wasn't always true. > > So now it's been watered down to 'use this if you don't have a > hardware timeline', but why don't we work with Android people to get > that removed entirely? I think there's some testcases still using these, but most real fence testcases use vgem nowadays. So from an upstream pov there's indeed not much if anything holding us back from just deleting this all. And would probably be a good idea. Adding Rob and John for more of the android pov. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel