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.8 required=3.0 tests=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 89E2BC3A59E for ; Wed, 21 Aug 2019 20:11:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 641C2206BA for ; Wed, 21 Aug 2019 20:11:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730221AbfHUULi convert rfc822-to-8bit (ORCPT ); Wed, 21 Aug 2019 16:11:38 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:64492 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728044AbfHUULi (ORCPT ); Wed, 21 Aug 2019 16:11:38 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 18219228-1500050 for multiple; Wed, 21 Aug 2019 21:11:33 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT From: Chris Wilson User-Agent: alot/0.6 To: =?utf-8?q?Christian_K=C3=B6nig?= , daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org, sumit.semwal@linaro.org References: <20190821123147.110736-1-christian.koenig@amd.com> In-Reply-To: <20190821123147.110736-1-christian.koenig@amd.com> Message-ID: <156641829139.20466.3485292236947741339@skylake-alporthouse-com> Subject: Re: [RFC] replacing dma_resv API Date: Wed, 21 Aug 2019 21:11:31 +0100 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Quoting Christian König (2019-08-21 13:31:37) > Hi everyone, > > In previous discussion it surfaced that different drivers use the shared and explicit fences in the dma_resv object with different meanings. > > This is problematic when we share buffers between those drivers and requirements for implicit and explicit synchronization leaded to quite a number of workarounds related to this. > > So I started an effort to get all drivers back to a common understanding of what the fences in the dma_resv object mean and be able to use the object for different kind of workloads independent of the classic DRM command submission interface. > > The result is this patch set which modifies the dma_resv API to get away from a single explicit fence and multiple shared fences, towards a notation where we have explicit categories for writers, readers and others. Fwiw, I would like the distinction here between optional fences (writers, readers) and mandatory fences (others). The optional fences are where we put the implicit fence tracking that clever userspace would rather avoid. The mandatory fences (I would call internal) is where we put the fences for tracking migration that userspace can not opt out of. -Chris