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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 19BFAC5519F for ; Fri, 20 Nov 2020 09:35:04 +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 6D58E22227 for ; Fri, 20 Nov 2020 09:35:03 +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="X4UHOJmN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D58E22227 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 7809D6E88C; Fri, 20 Nov 2020 09:35:02 +0000 (UTC) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id B6DC16E88C for ; Fri, 20 Nov 2020 09:35:01 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id k26so9784620oiw.0 for ; Fri, 20 Nov 2020 01:35:01 -0800 (PST) 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=hgF4wfg69hNpww4OAKMoqR+eWE3jKpfJosXp9fxVBjI=; b=X4UHOJmNLvGaGQarNMiO8EklXG6lG45+9sS//8PEIAcGFyr8tKX+5nnGXzRAbO6Ue6 3W839yCL3pKJT002ic0S4VGSLeiJV67iqE0XZrHk+eXI21jAtiOEXzLIkiE0kqevhGVR MPDC0aauVbAhrazQEsofDf0TWh93oG9z4Np2U= 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=hgF4wfg69hNpww4OAKMoqR+eWE3jKpfJosXp9fxVBjI=; b=h/NnDug2PsBmnltbG/jL5HY6XDZz31xXjruwfqz5tZPnAlQTNn4vep6evR3fuliNAS 2h8PmCBuJ6qlCpMnisBuPlPmal/tWuYUI6PjGjxTNfIyFNYuGm4XT6a1sL0nNomp08oj z/i4/kb2dsmxtDXnNJ82hY9ymQ76cRW3vOdT8sBoZqE8vZiXpcjdGW1c2vqMhQKKB5tH yCVIAApT1PNvvxvsQWftBNGZYc+0RcBfnEE83fmlvvWWx/7a27xyzOsy/QrLOA/aqRSY H7y/tpCuITJm0gjOSBmD8dtIPTW6xKTzCRFMbJ6+Y8W/ooTfgsjTYLaxwd97G9e3DJzC sbGQ== X-Gm-Message-State: AOAM532wQn0wBiHnRMgBk/fqn1BV1CrHgiVPhRPo8X8MP+AfvjYSp9uR jYfprN+hXz37LeyVsSNiWV0SneQNKOhB21DGHX9BOQ== X-Google-Smtp-Source: ABdhPJwGdgkRwcd6PL3pN7daWCrNpgUvuP86thM6e5fGMCZGTC6PnlV9Y7Fldm85Rp0ewgPAUXlSIvmIrS0hPfBByDs= X-Received: by 2002:aca:7506:: with SMTP id q6mr5872181oic.128.1605864900943; Fri, 20 Nov 2020 01:35:00 -0800 (PST) MIME-Version: 1.0 References: <20201110034934.70898-1-john.stultz@linaro.org> <20201112093237.GS401619@phenom.ffwll.local> <20201113203933.GT401619@phenom.ffwll.local> In-Reply-To: From: Daniel Vetter Date: Fri, 20 Nov 2020 10:34:50 +0100 Message-ID: Subject: Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation To: Sumit Semwal 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: Sandeep Patil , DRI mailing list , Ezequiel Garcia , Robin Murphy , James Jones , lkml , Liam Mark , Christian Koenig , Laura Abbott , Chris Goldsworthy , Hridya Valsaraju , =?UTF-8?Q?=C3=98rjan_Eide?= , "open list:DMA BUFFER SHARING FRAMEWORK" , Suren Baghdasaryan , Daniel Mentz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Nov 20, 2020 at 7:32 AM Sumit Semwal wrote: > > Hi Daniel, > > > On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote: > > > > On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote: > > > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote: > > > > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > > > > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote: > > > > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > > > > > On Tue, 10 Nov 2020 at 09:19, John Stultz wrote: > > > > > > > > > > > > > > > > Hey All, > > > > > > > > So just wanted to send my last revision of my patch series > > > > > > > > of performance optimizations to the dma-buf system heap. > > > > > > > > > > > > > > Thanks very much for your patches - I think the first 5 patches look good to me. > > > > > > > > > > > > > > I know there was a bit of discussion over adding a new system-uncached > > > > > > > heap v/s using a flag to identify that; I think I prefer the separate > > > > > > > heap idea, but lets ask one last time if any one else has any real > > > > > > > objections to it. > > > > > > > > > > > > > > Daniel, Christian: any comments from your side on this? > > > > > > > > > > > > I do wonder a bit where the userspace stack for this all is, since tuning > > > > > > allocators without a full stack is fairly pointless. dma-buf heaps is a > > > > > > bit in a limbo situation here it feels like. > > > > > > > > > > As mentioned in the system-uncached patch: > > > > > Pending opensource users of this code include: > > > > > * AOSP HiKey960 gralloc: > > > > > - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > > > > > - Visibly improves performance over the system heap > > > > > * AOSP Codec2 (possibly, needs more review): > > > > > - https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > > > > > > > > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > > > > > able to use the current dmabuf heaps instead of ION. > > > > > > > > > > So I'm not sure what you mean by limbo, other than it being in a > > > > > transition state where the interface is upstream and we're working on > > > > > moving vendors to it from ION (which is staged to be dropped in 5.11). > > > > > Part of that work is making sure we don't regress the performance > > > > > expectations. > > > > > > > > The mesa thing below, since if we test this with some downstream kernel > > > > drivers or at least non-mesa userspace I'm somewhat worried we're just > > > > creating a nice split world between the android gfx world and the > > > > mesa/linux desktop gfx world. > > > > > > > > But then that's kinda how android rolls, so *shrug* > > > > > > > > > > Plus I'm vary of anything related to leaking this kind of stuff beyond the > > > > > > dma-api because dma api maintainers don't like us doing that. But > > > > > > personally no concern on that front really, gpus need this. It's just that > > > > > > we do need solid justification I think if we land this. Hence back to > > > > > > first point. > > > > > > > > > > > > Ideally first point comes in the form of benchmarking on android together > > > > > > with a mesa driver (or mesa + some v4l driver or whatever it takes to > > > > > > actually show the benefits, I have no idea). > > > > > > > > > > Tying it with mesa is a little tough as the grallocs for mesa devices > > > > > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > > > > > allocation path for dmabuf heaps there gets a little complex as last I > > > > > tried that (when trying to get HiKey working with Lima graphics, as > > > > > gbm wouldn't allocate the contiguous buffers required by the display), > > > > > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > > > > > private handle metadata in the buffer when it was passed in. > > > > > > > > > > But I might take a look at it again. I got a bit lost digging through > > > > > the mesa gbm allocation paths last time. > > > > > > > > > > I'll also try to see if I can find a benchmark for the codec2 code > > > > > (using dmabuf heaps with and without the uncached heap) on on db845c > > > > > (w/ mesa), as that is already working and I suspect that might be > > > > > close to what you're looking for. > > > > > > > > tbh I think trying to push for this long term is the best we can hope for. > > > > > > > > Media is also a lot more *meh* since it's deeply fragmented and a lot less > > > > of it upstream than on the gles/display side. > > > > > > > > I think confirming that this at least doesn't horrible blow up on a > > > > gralloc/gbm+mesa stack would be useful I think. > > > > > > Sorry, I'm still a little foggy on precisely what you're suggesting here. > > > > > > The patch stack I have has already been used with db845c (mesa + > > > gbm_grallloc), with the codec2 (sw decoders) using dmabuf heaps. > > > So no blowing up there. And I'm working with Hridya to find a > > > benchmark for codec2 so we can try to show the performance delta. > > > > > > However, if you're wanting a dma-buf gralloc implementation with mesa, > > > that may be a little tougher to do, but I guess I can give it a go. > > > > > > Hopefully this will address concerns about the system-uncached heap > > > patch (the last two patches in this series)? > > > > > > In the meantime I hope we can queue the first five patches, as it > > > would be nice to get the code rearranging in as there are others > > > trying to stage their own heaps, and I'd like to avoid dragging that > > > churn out for too long (in addition to improving the allocation > > > performance). Those changes have no ABI implications. > > > > Maybe I'm also misunderstanding what dma-buf heaps is used for in > > Android, at least usually. I thought it's used to allocate all the > > winsys/shared buffers through gralloc (at least in the blobby stacks), > > to handle the allocation constraints problem. In the open stacks we > > don't seem to have a platform with both mesa and v4l (or some other > > codec) with "interesting" allocations constraints, so no one using > > that gralloc+dma-buf heaps combo for what it was meant for. Hence why > > I'm a bit vary that we're creating something here which just misses > > the point a bit when we try to actually use it (in that glorious > > forever-future world where an android platform has enough drivers in > > upstream to do so). > > > > For other "this solves a system problem" we tend to be quite a bit > > more picky with the demonstration use case, to make sure we're > > actually creating something that solves the problem in reality. > > > > But it also looks like Android's just not there yet, so *shrug* ... > > For me, looking at the first 5 patches (listed below, for quick > reference), they are only doing code reorganisation and minor updates > for already existing heaps, and no ABI change, I am not able to > clearly see your objection here. To me, these seem to be required > updates that the existing system heap users can benefit from. > > dma-buf: system_heap: Rework system heap to use sgtables instead of > pagelists > dma-buf: heaps: Move heap-helper logic into the cma_heap > implementation > dma-buf: heaps: Remove heap-helpers code > dma-buf: heaps: Skip sync if not mapped > dma-buf: system_heap: Allocate higher order pages if available > > If we talk about the last two patches - the ones that add system > uncached heap, I somewhat agree that we should be able to show the > performance gains with this approach (which has been in use on ION and > in devices) using dma-buf gralloc or similar. > > We can discuss the system-uncached heap when the dma-buf gralloc or > similar demonstration for performance benefits is done, but I am > inclined to push these 5 patches listed above through. Yeah makes total sense - I was arguing about the new stuff, not the refactoring. -Daniel > > Best, > Sumit. > > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- 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