| Message ID | 20241214081719.3330518-9-andyshrk@163.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | VOP Support for rk3576 | expand |
Hi Andy, 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. You can use the drm_info utility from https://gitlab.freedesktop.org/emersion/drm_info to validate that the list of supported formats/modifiers for each plane matches your expectation. Cheers, Daniel
Hi Daniel, At 2024-12-16 21:06:07, "Daniel Stone" <daniel@fooishbar.org> wrote: >Hi Andy, > >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), + 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 can use the drm_info utility from >https://gitlab.freedesktop.org/emersion/drm_info to validate that the >list of supported formats/modifiers for each plane matches your >expectation. I think this is similar to what modetest dump： 38 0 0 0,0 0,0 0 0x00000001 formats: XR30 XB30 AR30 AB30 XR24 AR24 XB24 AB24 RG24 BG24 RG16 BG16 NV12 NV21 NV16 NV61 NV24 NV42 NV15 NV20 NV30 props: 8 type: flags: immutable enum enums: Overlay=0 Primary=1 Cursor=2 value: 0 30 IN_FORMATS: flags: immutable blob blobs: value: 01000000000000001500000018000000 09000000700000005852333058423330 41523330414233305852323441523234 58423234414232345247323442473234 52473136424731364e5631324e563231 4e5631364e5636314e5632344e563432 4e5631354e5632304e56333000000000 ff0f0000000000000000000000000000 2200000000000008ff0f000000000000 00000000000000006200000000000008 ff0f0000000000000000000000000000 3200000000000008ff0f000000000000 0000000000000000a200000000000008 ff0f0000000000000000000000000000 e200000000000008ff0f000000000000 0000000000000000b200000000000008 ff0f0000000000000000000000000000 f200000000000008ff0f000000000000 00000000000000007200000000000008 ffff1f00000000000000000000000000 0000000000000000 in_formats blob decoded: XR30: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) XB30: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) AR30: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) AB30: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) XR24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) AR24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) XB24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) AB24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) RG24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) BG24: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) RG16: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) BG16: ARM_BLOCK_SIZE=32x8,MODE=SPLIT(0x800000000000022) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE(0x800000000000062) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT(0x800000000000032) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|CBR(0x8000000000000a2) ARM_BLOCK_SIZE=32x8,MODE=SPLIT|SPARSE|CBR(0x8000000000000e2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|CBR(0x8000000000000b2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE|CBR(0x8000000000000f2) ARM_BLOCK_SIZE=32x8,MODE=YTR|SPLIT|SPARSE(0x800000000000072) LINEAR(0x0) NV12: LINEAR(0x0) NV21: LINEAR(0x0) NV16: LINEAR(0x0) NV61: LINEAR(0x0) NV24: LINEAR(0x0) NV42: LINEAR(0x0) NV15: LINEAR(0x0) NV20: LINEAR(0x0) NV30: LINEAR(0x0) [0]https://github.com/andyshrk/mesa-drm/blob/mydev/tests/ovltest/ovltest.c#L1167 > >Cheers, >Daniel > >_______________________________________________ >Linux-rockchip mailing list >Linux-rockchip@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-rockchip
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 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. Cheers, Daniel
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. > >Cheers, >Daniel
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
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c index b5f35839d5e8..efe7d0cbe155 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -1454,16 +1454,18 @@ static void vop2_plane_atomic_update(struct drm_plane *plane, vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, half_block_en); if (afbc_en) { - u32 stride; + u32 stride, block_w; + + /* the afbc superblock is 16 x 16 or 32 x 8 */ + block_w = fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 ? 32 : 16; - /* the afbc superblock is 16 x 16 */ afbc_format = vop2_convert_afbc_format(fb->format->format); /* Enable color transform for YTR */ if (fb->modifier & AFBC_FORMAT_MOD_YTR) afbc_format |= (1 << 4); - afbc_tile_num = ALIGN(actual_w, 16) >> 4; + afbc_tile_num = ALIGN(actual_w, block_w) / block_w; /* * AFBC pic_vir_width is count by pixel, this is different @@ -1474,6 +1476,9 @@ static void vop2_plane_atomic_update(struct drm_plane *plane, drm_dbg_kms(vop2->drm, "vp%d %s stride[%d] not 64 pixel aligned\n", vp->id, win->data->name, stride); + /* It's for head stride, each head size is 16 byte */ + stride = ALIGN(stride, block_w) / block_w * 16; + uv_swap = vop2_afbc_uv_swap(fb->format->format); /* * This is a workaround for crazy IC design, Cluster @@ -1504,7 +1509,11 @@ static void vop2_plane_atomic_update(struct drm_plane *plane, else vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1); - vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0); + if (fb->modifier & AFBC_FORMAT_MOD_SPLIT) + vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 1); + else + vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0); + transform_offset = vop2_afbc_transform_offset(pstate, half_block_en); vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst); vop2_win_write(win, VOP2_WIN_AFBC_PIC_SIZE, act_info);