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.3 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 B21AFC433E0 for ; Mon, 1 Jun 2020 14:25:39 +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 7489C2068D for ; Mon, 1 Jun 2020 14:25:39 +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="H7+bg400" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7489C2068D 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 57D9889701; Mon, 1 Jun 2020 14:25:38 +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 2FEEF8923C for ; Mon, 1 Jun 2020 14:25:37 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id l10so12074wrr.10 for ; Mon, 01 Jun 2020 07:25:37 -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=OMf/0WAuD70wcdLb9A+olYE5SwA7tqyVBkYxZj8o4nI=; b=H7+bg400UzOQ/Fday2TDexITPydfFPjEFwo0QaApfFPWgR2DqUMIK4jz9w/VaK10/+ RZBGez8sOOCOhA/UdkAHDp2pX19jG8yr/7SulnVCpDcA/k3DmCDBcrTs9x3th55dUegt mYQI7SuIBlXytMVygCj8g5L14K6rIU9tmbYakSAsAUPlTw1rI3WlgpwzpcrXrrw08kuA r6xk8ZcJD9pFSw0QIX+9shyzGp7He/jEr7JbsspJpsnpSSJt4GGxjj7Qpydtv+o5I0nw ZldS1jqzZ/VT8+oarfYZ5z7ZA74KdEpkvMiUM6NeU/EP/kmNWE0fSdneRTapeBmnanBH 9ECg== 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=OMf/0WAuD70wcdLb9A+olYE5SwA7tqyVBkYxZj8o4nI=; b=Dh1+D0/323G5DV8fpvwaCGzcPDbInYPlmPbel8ghSa2t/lOXqnWrFGRDkCi/X1L3sf exl3C8i/C0ITmZVLbLXV+kyGD9aj/3MTTuiDw24pNywweLLC2dVyDQJA8pO5v/4xINaA QIgLjaLx87BVSGX0e5Yu1H5oMEfVWAPRvOL0nm5g2AHmIrlbuMoTg7i8oyqv5Y9x6EXj pBAGxGJT1vtPU2a8lckQ2egJGsjFwd4nWkeFn6wFyr1y1Zk/Q+TVb9Q4E/esPciIKjrz 2XzRDMG8rMq7CW73HPxWaW8Xstg7Viwb/QXBzVX37z/qz/ds3tiQpHm60wXWbA4k9x6x p5bw== X-Gm-Message-State: AOAM533mw4a9qKAee2WLo5lBp4JGdu6iIndb3A3YlheOsDvzaREgYNY6 L4BDyQkNcxp61p5Xo4RXAk2a9Fzp7lUhHfnl0oE= X-Google-Smtp-Source: ABdhPJyjk5F9ArrML06XEkixBahrYXZhQTUCImKoTNioUeOw35PJArYxTgfZ1zvMIza+H1l4hfH0VozHNML21KjOHqI= X-Received: by 2002:adf:fd41:: with SMTP id h1mr23049025wrs.374.1591021535718; Mon, 01 Jun 2020 07:25:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Deucher Date: Mon, 1 Jun 2020 10:25:24 -0400 Message-ID: Subject: Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements To: Daniel Stone 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: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , dri-devel , Daniel Vetter Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote: > > On Fri, 29 May 2020 at 15:36, Alex Deucher wrote: > > On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote: > > > On Fri, 29 May 2020 at 15:29, Alex Deucher wrote: > > > > Maybe I'm over thinking this. I just don't want to get into a > > > > situation where we go through a lot of effort to add modifier support > > > > and then performance ends up being worse than it is today in a lot of > > > > cases. > > > > > > I'm genuinely curious: what do you imagine could cause a worse result? > > > > As an example, in some cases, it's actually better to use linear for > > system memory because it better aligns with pcie access patterns than > > some tiling formats (which are better aligned for the memory > > controller topology on the dGPU). That said, I haven't been in the > > loop as much with the tiling formats on newer GPUs, so that may not be > > as much of an issue anymore. > > Yeah, that makes a lot of sense. On the other hand, placement isn't > explicitly encoded for either modifiers or non-modifiers, so I'm not > sure how it would really regress. > > In case it was missed somewhere, there is no generic code doing > modifier selection for modifier optimality anywhere. The flow is: > - every producer/consumer advertises a list of modifier + format > pairs, declaring what they _can_ support > - for every use where a buffer needs to be allocated, the generic > code intersects these lists of modifiers to determine the set of > modifiers mutually acceptable to all consumers > - the buffer allocator is always handed a _list_ of modifiers, and > makes its own decision based on ?? > > For a concrete end-to-end example: > - KMS declares which modifiers are supported for scanout > - EGL declares which modifiers are supported for EGLImage import > - Weston determines that one of its clients could be directly > scanned out rather than composited > - Weston intersects the KMS + EGL set of modifiers to come up with > the optimal modifier set (i.e. bypassing composition) > - Weston sends this intersected list to the client via the Wayland > protocol (mentioned in previous MR) > - the client is using EGL, so Mesa receives this list of modifiers, > and passes this on to amdgpu > - amdgpu uses magic inscrutable heuristics to determine the most > optimal modifier to use, and allocates a buffer based on that > > Weston (or GNOME Shell, or Chromium, or whatever) will never be in a > position as a generic client to know that on Raven2 it should use a > particular supertiled layout with no DCC if width > 2048. So we > designed the entire framework to explicitly avoid generic code trying > to reason about the performance properties of specific modifiers. > > What Weston _does_ know, however, is that display controller can work > with modifier set A, and the GPU can work with modifier set B, and if > the client can pick something from modifier set A, then there is a > much greater probability that Weston can leave the GPU alone so it can > be entirely used by the client. It also knows that if the surface > can't be directly scanned out for whatever reason, then there's no > point in the client optimising for direct scanout, and it can tell the > client to select based on optimality purely for the GPU. Just so I understand this correctly, the main reason for this is to deal with display hardware and render hardware from different vendors which may or may not support any common formats other than linear. It provides a way to tunnel device capabilities between the different drivers. In the case of a device with display and rendering on the same device or multiple devices from the same vendor, it not really that useful. It doesn't seem to provide much over the current EGL hints (SCANOUT, SECURE, etc.). I still don't understand how it solves the DCC problem though. Compression and encryption seem kind like meta modifiers. There is an under laying high level layout, linear, tiled, etc. but it could also be compressed and/or encrypted. Is the idea that those are separate modifiers? E.g., 0: linear 1: linear | encrypted 2. linear | compressed 3: linear | encrypted | compressed 4: tiled1 5: tiled1 | encrypted 6: tiled1 | compressed 7: tiled1 | encrypted | compressed etc. Or that the modifiers only expose the high level layout, and it's then up the the driver(s) to enable compression, etc. if both sides have a compatible layout? Thanks, Alex > > So that's the thinking behind the interface: that the driver still has > exactly as much control and ability to use magic heuristics as it > always has, but that system components can supplement the driver's > heuristics with their own knowledge, to increase the chance that the > driver's heuristics arrive at a configuration that a) will definitely > work, and b) have a much greater chance of working optimally. > > Does that help at all? > > Cheers, > Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel