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