mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Andy Yan" <andyshrk@163.com>
To: "Daniel Stone" <daniel@fooishbar.org>
Cc: heiko@sntech.de, hjc@rock-chips.com, krzk+dt@kernel.org,
	 s.hauer@pengutronix.de, devicetree@vger.kernel.org,
	 dri-devel@lists.freedesktop.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	 linux-rockchip@lists.infradead.org, derek.foreman@collabora.com,
	 detlev.casanova@collabora.com,
	"Andy Yan" <andy.yan@rock-chips.com>,
	 "Michael Riesch" <michael.riesch@wolfvision.net>,
	 "Sebastian Reichel" <sebastian.reichel@collabora.com>
Subject: Re:Re:Re: Re: [PATCH v6 08/16] drm/rockchip: vop2: Support 32x8 superblock afbc
Date: Wed, 18 Dec 2024 10:42:36 +0800 (CST)	[thread overview]
Message-ID: <3cf0785a.2c2e.193d7a55527.Coremail.andyshrk@163.com> (raw)
In-Reply-To: <32246002.9ef.193d7438b96.Coremail.andyshrk@163.com>


Hi Daniel,

At 2024-12-18 08:55:48, "Andy Yan" <andyshrk@163.com> wrote:
>
>Hi  Daniel,
>
>At 2024-12-17 20:07:54, "Daniel Stone" <daniel@fooishbar.org> wrote:
>>Hi Andy,
>>
>>On Tue, 17 Dec 2024 at 00:41, Andy Yan <andyshrk@163.com> wrote:
>>> At 2024-12-16 21:06:07, "Daniel Stone" <daniel@fooishbar.org> wrote:
>>> >On Sat, 14 Dec 2024 at 08:18, Andy Yan <andyshrk@163.com> wrote:
>>> >> This is the only afbc format supported by the upcoming
>>> >> VOP for rk3576.
>>> >>
>>> >> Add support for it.
>>> >
>>> >Out of interest, how was this tested? There is no 32x8 modifier in the
>>> >format list in format_modifiers_afbc[], so it seems like it shouldn't
>>> >be possible to get a 32x8 buffer on a plane at all.
>>>
>>> The 32x8 modifier  added in PATCH 16/16:
>>>
>>> +/* used from rk3576, afbc 32*8 half mode */
>>> +static const uint64_t format_modifiers_rk3576_afbc[] = {
>>> +       DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
>>> +                               AFBC_FORMAT_MOD_SPLIT),
>>> +
>>
>>Hmmm, that's strange; I applied the whole series with b4 but wasn't
>>seeing that block defined. Maybe a bad conflict resolution. Sorry for
>>the confusion.
>
>I think that might have been caused by my mistake. I initially sent the V6 version as a -in-reply to the V5 version.
>When I realized the mistake, a part of it had already been sent out. Then I sent the entire V6 series separately
>again. Maybe that make b4 and lore confused。
>
>>
>>> I write an ovltest[0] tool which can take linear/AFBC rgb/yuv data from a file, then
>>> commit to drm driver, I use this tool for most basic format test.
>>>
>>> But when tested on weston, I found that weston does not use the AFBC format for display,
>>> don't know why.
>>
>>You'll need a Mesa tree with e0f48568c7f2 included; if you have this
>>then it should just work out of the box.
>
>Thanks, I will check it.

When update to lasted mesa: GL version: OpenGL ES 3.1 Mesa 25.0.0-devel
I can get 32x8 AFBC output in weston for rk3576:

# cat /sys/kernel/debug/dri/0/vop2/summary 
Video Port0: ACTIVE
    Connector: HDMI-A-1
        bus_format[0]: Unknown
        output_mode[f] color_space[0]
    Display mode: 1920x1080p60
        clk[148500] real_clk[148500] type[48] flag[5]
        H: 1920 2008 2052 2200
        V: 1080 1084 1089 1125
    Cluster0-win0: ACTIVE
        win_id: 0
        format: XR24 little-endian (0x34325258)[AFBC] glb_alpha[0xff]
        rotate: xmirror: 0 ymirror: 0 rotate_90: 0 rotate_270: 0
        zpos: 0
        src: pos[0, 0] rect[1920 x 1080]
        dst: pos[0, 0] rect[1920 x 1080]
        buf[0]: addr: 0x000000000081a000 pitch: 7680 offset: 0
    Cluster1-win0: ACTIVE
        win_id: 1
        format: AR24 little-endian (0x34325241)[AFBC] glb_alpha[0xff]
        rotate: xmirror: 0 ymirror: 0 rotate_90: 0 rotate_270: 0
        zpos: 1
        src: pos[0, 0] rect[250 x 250]
        dst: pos[736, 503] rect[250 x 250]
        buf[0]: addr: 0x00000000010b6000 pitch: 1024 offset: 0

301 frames in 5 seconds: 60.200001 fps
302 frames in 5 seconds: 60.400002 fps
300 frames in 5 seconds: 60.000000 fps
301 frames in 5 seconds: 60.200001 fps
>
>>
>>Cheers,
>>Daniel

  reply	other threads:[~2024-12-18  2:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-14  8:16 [PATCH v6 00/16] VOP Support for rk3576 Andy Yan
2024-12-14  8:17 ` [PATCH v6 01/16] drm/rockchip: vop2: Add debugfs support Andy Yan
2024-12-14  8:17 ` [PATCH v6 02/16] drm/rockchip: vop2: Fix the windows switch between different layers Andy Yan
2024-12-14  8:17 ` [PATCH v6 03/16] drm/rockchip: vop2: Set AXI id for rk3588 Andy Yan
2024-12-14  8:17 ` [PATCH v6 04/16] drm/rockchip: vop2: Setup delay cycle for Esmart2/3 Andy Yan
2024-12-14  8:17 ` [PATCH v6 05/16] drm/rockchip: vop2: Check linear format for Cluster windows on rk3566/8 Andy Yan
2024-12-14  8:17 ` [PATCH v6 06/16] drm/rockchip: vop2: Add check for 32 bpp format for rk3588 Andy Yan
2024-12-14  8:17 ` [PATCH v6 07/16] drm/rockchip: vop2: include rockchip_drm_drv.h Andy Yan
2024-12-14  8:17 ` [PATCH v6 08/16] drm/rockchip: vop2: Support 32x8 superblock afbc Andy Yan
2024-12-16 13:06   ` Daniel Stone
2024-12-17  0:41     ` Andy Yan
2024-12-17 12:07       ` Daniel Stone
2024-12-18  0:55         ` Andy Yan
2024-12-18  2:42           ` Andy Yan [this message]
2024-12-14  8:17 ` [PATCH v6 09/16] drm/rockchip: vop2: Add platform specific callback Andy Yan
2024-12-14  8:17 ` [PATCH v6 10/16] drm/rockchip: vop2: Support for different layer select configuration between VPs Andy Yan
2024-12-14  8:18 ` [PATCH v6 11/16] drm/rockchip: vop2: Introduce vop hardware version Andy Yan
2024-12-14  8:18 ` [PATCH v6 12/16] drm/rockchip: vop2: Register the primary plane and overlay plane separately Andy Yan
2024-12-14  8:18 ` [PATCH v6 13/16] drm/rockchip: vop2: Set plane possible crtcs by possible vp mask Andy Yan
2024-12-14  8:19 ` [PATCH v6 14/16] drm/rockchip: vop2: Add uv swap for cluster window Andy Yan
2024-12-14  8:19 ` [PATCH v6 15/16] dt-bindings: display: vop2: Add rk3576 support Andy Yan
2024-12-14  8:19 ` [PATCH v6 16/16] drm/rockchip: vop2: Add support for rk3576 Andy Yan
2024-12-14 23:11 ` (subset) [PATCH v6 00/16] VOP Support " Heiko Stuebner
2024-12-18 16:42 ` Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3cf0785a.2c2e.193d7a55527.Coremail.andyshrk@163.com \
    --to=andyshrk@163.com \
    --cc=andy.yan@rock-chips.com \
    --cc=daniel@fooishbar.org \
    --cc=derek.foreman@collabora.com \
    --cc=detlev.casanova@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@wolfvision.net \
    --cc=s.hauer@pengutronix.de \
    --cc=sebastian.reichel@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®