linux-kernel - Re:Re:Re: Re: [PATCH v6 08/16] drm/rockchip: vop2: Support 32x8 superblock afbc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3cf0785a.2c2e.193d7a55527.Coremail.andyshrk@163.com>
Date: Wed, 18 Dec 2024 10:42:36 +0800 (CST)
From: "Andy Yan" <andyshrk@....com>
To: "Daniel Stone" <daniel@...ishbar.org>
Cc: heiko@...ech.de, hjc@...k-chips.com, krzk+dt@...nel.org, 
	s.hauer@...gutronix.de, devicetree@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-rockchip@...ts.infradead.org, derek.foreman@...labora.com, 
	detlev.casanova@...labora.com, "Andy Yan" <andy.yan@...k-chips.com>, 
	"Michael Riesch" <michael.riesch@...fvision.net>, 
	"Sebastian Reichel" <sebastian.reichel@...labora.com>
Subject: Re:Re:Re: Re: [PATCH v6 08/16] drm/rockchip: vop2: Support 32x8
 superblock afbc


Hi Daniel,

At 2024-12-18 08:55:48, "Andy Yan" <andyshrk@....com> wrote:
>
>Hi  Daniel,
>
>At 2024-12-17 20:07:54, "Daniel Stone" <daniel@...ishbar.org> wrote:
>>Hi Andy,
>>
>>On Tue, 17 Dec 2024 at 00:41, Andy Yan <andyshrk@....com> wrote:
>>> At 2024-12-16 21:06:07, "Daniel Stone" <daniel@...ishbar.org> wrote:
>>> >On Sat, 14 Dec 2024 at 08:18, Andy Yan <andyshrk@....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