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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 5B8B7C433F5 for ; Tue, 7 Sep 2021 08:15:05 +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 914A060F13 for ; Tue, 7 Sep 2021 08:15:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 914A060F13 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 12B8D89DA7; Tue, 7 Sep 2021 08:15:04 +0000 (UTC) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4ABAB89DA7 for ; Tue, 7 Sep 2021 08:15:03 +0000 (UTC) Received: by mail-oi1-x22c.google.com with SMTP id r26so11823978oij.2 for ; Tue, 07 Sep 2021 01:15:03 -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=iyaLNySbhh45lJT//R/2ibyQzwlerV4MwYqvcybxoiI=; b=erSvtHL6a+XPvcGTK79Y7SHAx69EBrL5eIEz5SERc5yLwY5grat8RTOHDZqsQcAyjM COvtcuR3KKw8Pe7vkRdt15i8cQWm6lMrdEnemLPZb0MFd3GmNTaTixxqcsPLzeJWzNBU +tLc1Z76wdaUomY0Ha2F9xyF5rODzuXV1GdzE= 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=iyaLNySbhh45lJT//R/2ibyQzwlerV4MwYqvcybxoiI=; b=mO687QrfTYbMmcrq72VmwSR/WfIWvSwXgiz6k6ctpt73Qon+KAqThGhMgeWw3HUCdn clmNFxs4DuHz4YK/Ftmkau3uVWAG9o7Ermew5jKIsm5RcHd1dk/qOaKCTYbZ10l7F+ix du57YT3P1BmpKaXCw6iiMKx9wnOAmPJwZO0GLDoPoA3sZ7YK3FepTU7Wam7KfyvJJ5aB xNQ4K6TBVBduKJlHFfoCICyBTtIjWkVv8t3z/CQUD5kuucPOgA/gdeZlxaVTQC7g630c AIy9Api5ATIcbavl1JzJCKOvILwEFr+Ezojvp8Klb5A/j0Nsv4QgGTUv2Es9cC9M6IMu Bhwg== X-Gm-Message-State: AOAM533UcnbdDsyoi2hRa2/sNsZZnNRm3wnnbrziGcRZ7s/155D/v8Mq pTtyNIr/jUqIGn5k9jWTHRl9mx86f/KPOBnJBkqXBw== X-Google-Smtp-Source: ABdhPJzwB/hhM1dA/SWJwRK2U7IbtZuhJ/CpG50AL1jAzS+fPGUVitC5wzS3w2xRAbVQSigik2fAG3O9hzuGoiRTY5U= X-Received: by 2002:aca:3954:: with SMTP id g81mr2057351oia.101.1631002502266; Tue, 07 Sep 2021 01:15:02 -0700 (PDT) MIME-Version: 1.0 References: <20210906034356.2946530-1-airlied@gmail.com> <20210906034356.2946530-2-airlied@gmail.com> <87mtoq86ct.fsf@intel.com> In-Reply-To: From: Daniel Vetter Date: Tue, 7 Sep 2021 10:14:51 +0200 Message-ID: To: Dave Airlie Cc: Jani Nikula , Intel Graphics Development , "Syrjala, Ville" , Rodrigo Vivi , Joonas Lahtinen , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Subject: Re: [Intel-gfx] [PATCH 01/10] drm/i915: move display funcs into a display struct. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Sep 6, 2021 at 9:45 PM Dave Airlie wrote: > On Mon, 6 Sept 2021 at 18:18, Jani Nikula wrote: > > On Mon, 06 Sep 2021, Dave Airlie wrote: > > > From: Dave Airlie > > > > > > This is the first step in an idea to refactor the display code > > > into a bit more of a corner. > > > > So, do we want to make i915->display a pointer? > > > > If we do, and we're about to touch every place accessing the display > > struct, we might just as well have: > > > > struct drm_i915_private { > > struct drm_i915_display _display; > > struct drm_i915_display *display; > > }; > > > > and initialize i915->display = &i915->_display, and make all access > > happen via the pointer. If we want to allocate it dynamically at some > > point, it'll be a *much* easier task. > > > > But the first question to figure out is whether we want to do that or > > not. > > I think the advantage is that we can hide a lot more structs from the > main struct, > the disadvantage is additional pointer chasing, esp for the drm_device and other > i915_priv members. For display pointer chasing doesn't matter at all. Imo the case is more what make sense as object hierarchy, and embedding vs pointer has quite different meaning. We've discussed in the past that the split into display/gem with branches seems to work ok-ish, but could probably be improved a lot in code org. If we make display a lot more a free-standing thing (i.e. pointer, not embedding) with a much more clearer/cleaner api contract to other pieces, then maybe there's some case to be made for all this churn. The problem with all that is that we'd then essentially need to backpointers everywhere in all display structures: One to the drm_device provided by base structs, and the other to the i915_display struct, which is what our code uses. This way display would stay display. In a way this would then look similarly-ish to amdgpu's DC. But I'm honestly not sure how much that would improve anything, and whether it's worth all the churn to make drm/i915/display more self-contained. -Daniel > Has anyone any non-anecdotal knowledge of how bad the latter problem > actually is? > Other drivers seem to do a lot of it and nobody has complained about it. > > I'm happy to move to a pointer for it all to be honest, > Dave. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch