From: Andy Yan <andy.yan@rock-chips.com>
This is the only afbc format supported by the upcoming
VOP for rk3576.
Add support for it.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568
Tested-by: Detlev Casanova <detlev.casanova@collabora.com>
---
(no changes since v2)
Changes in v2:
- split it from main patch add support for rk3576
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
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);
--
2.34.1Hi 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
© 2016 - 2025 Red Hat, Inc.