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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 603BBC36014 for ; Tue, 1 Apr 2025 10:05:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B893610E54E; Tue, 1 Apr 2025 10:05:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; secure) header.d=mailbox.org header.i=@mailbox.org header.b="YhQnbN3P"; dkim-atps=neutral X-Greylist: delayed 545 seconds by postgrey-1.36 at gabe; Tue, 01 Apr 2025 10:05:25 UTC Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7678810E550; Tue, 1 Apr 2025 10:05:25 +0000 (UTC) Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4ZRk0W3nTNz9stJ; Tue, 1 Apr 2025 11:56:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1743501371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iBt5tLaDB2fSpMRs+SjOGds3Pi+iDzfHllCKkb+bv34=; b=YhQnbN3PAoOdKjtc1SsMpjZiRwPmSBIOQY5hlGhP7eMYUvk4VZJERGj3/Nh7G5HqU+yL1K b3Zho/v5pn/alIt+h2Fw9Bzepd0TX4m+GUMvNCPPeADDMyyK1EjygOfZ0DfAJbHtQNk8PI BSBa5XPguGXWiPF02OD97bW47R2VB5Vk3SUrovPEQboDkTIDJcHAOmRC7n9TgBcCNkFFuX Z+LD6wwJ+KF/C2+ACftNktvLBM9loar+MpAjjQuhLa/kf3kpqcY1I/FMGRq50Bw2CgAUiG oWnMVE/bxZKbqxwIYEGtpOVDDU18xKRgSq1wBVMURq0vMwgqxNozP3xmzAaY4w== Message-ID: <63d2a14e-759f-44b6-99b4-de42b8d6b1e0@mailbox.org> Date: Tue, 1 Apr 2025 11:56:04 +0200 MIME-Version: 1.0 Subject: Re: [PATCH V8 24/43] drm/amd/display: Skip color pipeline initialization for cursor plane To: Alex Hung , Shengyu Qu , dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Cc: wayland-devel@lists.freedesktop.org, harry.wentland@amd.com, leo.liu@amd.com, ville.syrjala@linux.intel.com, pekka.paalanen@collabora.com, contact@emersion.fr, mwen@igalia.com, jadahl@redhat.com, sebastian.wick@redhat.com, shashank.sharma@amd.com, agoins@nvidia.com, joshua@froggi.es, aleixpol@kde.org, xaver.hugl@gmail.com, victoria@system76.com, daniel@ffwll.ch, uma.shankar@intel.com, quic_naseer@quicinc.com, quic_cbraga@quicinc.com, quic_abhinavk@quicinc.com, marcan@marcan.st, Liviu.Dudau@arm.com, sashamcintosh@google.com, chaitanya.kumar.borah@intel.com, louis.chauvet@bootlin.com References: <20250326234748.2982010-1-alex.hung@amd.com> <20250326234748.2982010-25-alex.hung@amd.com> <0add5ab1-0717-42a8-8994-a381b635040b@amd.com> <9984f8e4-3f24-49d0-a7be-4f746dfbb4cc@amd.com> <5eac0bab-60c2-4e94-9ab2-bad5f451c8c9@amd.com> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: <5eac0bab-60c2-4e94-9ab2-bad5f451c8c9@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-META: esnz54tjxhrx3qh6pkmczao1sn49dmoh X-MBO-RS-ID: 8d68b9ceeb8fe02e7ed 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2025-03-31 19:42, Alex Hung wrote: > On 3/31/25 11:04, Shengyu Qu wrote: >> Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE property, to let userspace know that cursor plane and background plane share the same colorop config. So that userspace could do extra conversion on cursor image data to avoid display wrong cursor color. > > That's over-complicate and makes little sense for both device drivers and userspace applications. > > If any planes share same colorop config, a device driver exposes the same color pipeline with the same colorops. > > If a plane does not support color pipeline or a driver doesn't want to support it, there is no color pipeline and no color objects. I suspect using the cursor plane is generally higher priority for Wayland compositors than using overlay planes, because the former is critical for a responsive user experience. This requires that the amdgpu DC driver backs the cursor plane with a dedicated HW plane though (as it's already doing in some cases), to either fully support color pipelines for the cursor plane, or at least provide proper "no color pipeline" behaviour for it. Letting the effective behaviour be determined by the other planes which happen to be behind the cursor plane isn't usable for Wayland compositors. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast