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.6 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 D99A7C433B4 for ; Thu, 20 May 2021 07:55:33 +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 D274B611C2 for ; Thu, 20 May 2021 07:55:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D274B611C2 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 B88E96F37F; Thu, 20 May 2021 07:55:31 +0000 (UTC) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by gabe.freedesktop.org (Postfix) with ESMTPS id 026AE6F37F for ; Thu, 20 May 2021 07:55:30 +0000 (UTC) Received: by mail-ot1-x330.google.com with SMTP id v19-20020a0568301413b0290304f00e3d88so14092145otp.4 for ; Thu, 20 May 2021 00:55:30 -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:content-transfer-encoding; bh=7VsX7/Yz8gqq5F5QEcaTsRmC1RVegDqVZLxieNcvL5Y=; b=a/Tz6gVwAOCMl1U31XbJwz20OWk9IAZsktmDv5Gj+dqcefIzeuJ3KSa4mgmQRQVlwq oCvt2Jry/uKyMhMHZYbCvoeG2kyr0iFlZeMUTSpCI/++fyCiAuXYZQzUBeCzoGYwtIdi GWXzAaG8gTPNTJTRaxDqPyBImkKyRVb0pOlfw= 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:content-transfer-encoding; bh=7VsX7/Yz8gqq5F5QEcaTsRmC1RVegDqVZLxieNcvL5Y=; b=G4YKi3BK4DKCBNBRWkPdYuSTt9KSizUdJ8y/fCUIr9EEAf0dc5vDyZf4n4SV0lw9b0 7WoN6cr7XVNe07OB1Lw2UvYZEOCgSF2szXOi/7eGDm04HCtosxTFxnrrXs0q0mfmTB2D GTou/YeZmXtOyV7uIHrFBbkdlL3FJ608/Ox04ndI2pL+Dw0u2C2w1pN/IQ6DVO86i/5S Ycvfa9kRI9uJX/6cB5qLF6j8iZLXuEHpQL5Fp0mSbJl/CFF99BndM20IMyPqO14ggvBw KNRb4jktLCZW/D4V8NChTkYIGg4VAtGJwClYNZMuMuYcVkevSDlH3eTjcLNCGHN+Gpix lSDw== X-Gm-Message-State: AOAM533LiEH/eohIj7A5FWKiRYBO4QjCjB/KnksKHbsyxCoATGsQSxoS EfC/0TbytZLFMwZ1b0UfqW7PFZv8ySnyqNDRZiz/+w== X-Google-Smtp-Source: ABdhPJw5oxqOn0U5fVq3qtSCcJm4kDUr02ifSMeE3D/j/nbnWJxtqoD/DWDHCg+55DhKPZAvCoXZl4teZNeKUdtM1sI= X-Received: by 2002:a9d:4101:: with SMTP id o1mr2915523ote.281.1621497330332; Thu, 20 May 2021 00:55:30 -0700 (PDT) MIME-Version: 1.0 References: <20210517141129.2225-1-christian.koenig@amd.com> <5a3e9500-9d6b-a865-5385-fde43da2bf66@gmail.com> <14524566-8854-4bc0-9f70-b7219c9fccfc@daenzer.net> <6f3e2628-7b39-417c-3bd2-c837c5367458@daenzer.net> In-Reply-To: <6f3e2628-7b39-417c-3bd2-c837c5367458@daenzer.net> From: Daniel Vetter Date: Thu, 20 May 2021 09:55:19 +0200 Message-ID: Subject: Re: [RFC] Add DMA_RESV_USAGE flags To: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: "moderated list:DMA BUFFER SHARING FRAMEWORK" , =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel , Jason Ekstrand Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, May 19, 2021 at 5:48 PM Michel D=C3=A4nzer wro= te: > > On 2021-05-19 5:21 p.m., Jason Ekstrand wrote: > > On Wed, May 19, 2021 at 5:52 AM Michel D=C3=A4nzer = wrote: > >> > >> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote: > >>> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote= : > >>>> > >>>> On Tue, May 18, 2021 at 7:40 PM Christian K=C3=B6nig > >>>> wrote: > >>>>> > >>>>> Am 18.05.21 um 18:48 schrieb Daniel Vetter: > >>>>>> On Tue, May 18, 2021 at 2:49 PM Christian K=C3=B6nig > >>>>>> wrote: > >>>>>> > >>>>>>> And as long as we are all inside amdgpu we also don't have any ov= ersync, > >>>>>>> the issue only happens when we share dma-bufs with i915 (radeon a= nd > >>>>>>> AFAIK nouveau does the right thing as well). > >>>>>> Yeah because then you can't use the amdgpu dma_resv model anymore = and > >>>>>> have to use the one atomic helpers use. Which is also the one that > >>>>>> e.g. Jason is threathening to bake in as uapi with his dma_buf ioc= tl, > >>>>>> so as soon as that lands and someone starts using it, something ha= s to > >>>>>> adapt _anytime_ you have a dma-buf hanging around. Not just when i= t's > >>>>>> shared with another device. > >>>>> > >>>>> Yeah, and that is exactly the reason why I will NAK this uAPI chang= e. > >>>>> > >>>>> This doesn't works for amdgpu at all for the reasons outlined above= . > >>>> > >>>> Uh that's really not how uapi works. "my driver is right, everyone > >>>> else is wrong" is not how cross driver contracts are defined. If tha= t > >>>> means a perf impact until you've fixed your rules, that's on you. > >>>> > >>>> Also you're a few years too late with nacking this, it's already uap= i > >>>> in the form of the dma-buf poll() support. > >>> > >>> ^^ My fancy new ioctl doesn't expose anything that isn't already > >>> there. It just lets you take a snap-shot of a wait instead of doing > >>> an active wait which might end up with more fences added depending on > >>> interrupts and retries. The dma-buf poll waits on all fences for > >>> POLLOUT and only the exclusive fence for POLLIN. It's already uAPI. > >> > >> Note that the dma-buf poll support could be useful to Wayland composit= ors for the same purpose as Jason's new ioctl (only using client buffers wh= ich have finished drawing for an output frame, to avoid missing a refresh c= ycle due to client drawing), *if* it didn't work differently with amdgpu. > >> > >> Am I understanding correctly that Jason's new ioctl would also work di= fferently with amdgpu as things stand currently? If so, that would be a rea= l bummer and might hinder adoption of the ioctl by Wayland compositors. > > > > My new ioctl has identical semantics to poll(). It just lets you take > > a snapshot in time to wait on later instead of waiting on whatever > > happens to be set right now. IMO, having identical semantics to > > poll() isn't something we want to change. > > Agreed. > > I'd argue then that making amdgpu poll semantics match those of other dri= vers is a pre-requisite for the new ioctl, otherwise it seems unlikely that= the ioctl will be widely adopted. This seems backwards, because that means useful improvements in all other drivers are stalled until amdgpu is fixed. I think we need agreement on what the rules are, reasonable plan to get there, and then that should be enough to unblock work in the wider community. Holding the community at large hostage because one driver is different is really not great. I've just finished the subsystem review of everything, and thus far only found some minor bugs without practical significance. I'll fix those and then send out a series. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch