2018년 09월 13일 17:49에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
>
> On 2018-09-13 10:23, Inki Dae wrote:
>> 2018년 09월 13일 17:03에 Marek Szyprowski 이(가) 쓴 글:
>>> On 2018-09-13 07:14, Inki Dae wrote:
>>>> 2018년 09월 12일 15:59에 Andrzej Pietrasiewicz 이(가) 쓴 글:
>>>>> W dniu 12.09.2018 o 01:54, Inki Dae pisze:
>>>>>> Hi Marek and Andrzej,
>>>>>>
>>>>>> 2018년 08월 10일 22:29에 Marek Szyprowski 이(가) 쓴 글:
>>>>>>> From: Andrzej Pietrasiewicz <andrze...@samsung.com>
>>>>>>>
>>>>>>> Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
>>>>> <snip>
>>>>>
>>>>>>> -static u32 scaler_get_format(u32 drm_fmt)
>>>>>>> +struct scaler_format {
>>>>>>> + u32 drm_fmt;
>>>>>>> + u32 internal_fmt;
>>>>>>> + u32 chroma_tile_w;
>>>>>>> + u32 chroma_tile_h;
>>>>>>> +};
>>>>>>> +
>>>>>>> +static const struct scaler_format scaler_formats[] = {
>>>>>>> + { DRM_FORMAT_NV12, SCALER_YUV420_2P_UV, 8, 8 },
>>>>>>> + { DRM_FORMAT_NV21, SCALER_YUV420_2P_VU, 8, 8 },
>>>>>>> + { DRM_FORMAT_YUV420, SCALER_YUV420_3P, 8, 8 },
>>>>>>> + { DRM_FORMAT_YUYV, SCALER_YUV422_1P_YUYV, 16, 16 },
>>>>>>> + { DRM_FORMAT_UYVY, SCALER_YUV422_1P_UYVY, 16, 16 },
>>>>>>> + { DRM_FORMAT_YVYU, SCALER_YUV422_1P_YVYU, 16, 16 },
>>>>>>> + { DRM_FORMAT_NV16, SCALER_YUV422_2P_UV, 8, 16 },
>>>>>>> + { DRM_FORMAT_NV61, SCALER_YUV422_2P_VU, 8, 16 },
>>>>>>> + { DRM_FORMAT_YUV422, SCALER_YUV422_3P, 8, 16 },
>>>>>>> + { DRM_FORMAT_NV24, SCALER_YUV444_2P_UV, 16, 16 },
>>>>>>> + { DRM_FORMAT_NV42, SCALER_YUV444_2P_VU, 16, 16 },
>>>>>>> + { DRM_FORMAT_YUV444, SCALER_YUV444_3P, 16, 16 },
>>>>>>> + { DRM_FORMAT_RGB565, SCALER_RGB_565, 0, 0 },
>>>>>>> + { DRM_FORMAT_XRGB1555, SCALER_ARGB1555, 0, 0 },
>>>>>>> + { DRM_FORMAT_ARGB1555, SCALER_ARGB1555, 0, 0 },
>>>>>>> + { DRM_FORMAT_XRGB4444, SCALER_ARGB4444, 0, 0 },
>>>>>>> + { DRM_FORMAT_ARGB4444, SCALER_ARGB4444, 0, 0 },
>>>>>>> + { DRM_FORMAT_XRGB8888, SCALER_ARGB8888, 0, 0 },
>>>>>>> + { DRM_FORMAT_ARGB8888, SCALER_ARGB8888, 0, 0 },
>>>>>>> + { DRM_FORMAT_RGBX8888, SCALER_RGBA8888, 0, 0 },
>>>>>>> + { DRM_FORMAT_RGBA8888, SCALER_RGBA8888, 0, 0 },
>>>>>> Seems the tile size of each format you declared above is wrong.
>>>>>> According to data sheet for Exynos5420/5422/5433, each plane has
>>>>>> different tile size.
>>>>>> I.e., SACLE_YUV420_2P_UV/VU has two planes, and Y plane has 16 x 16 tile
>>>>>> size but U and V plane have 8 x 8 tile size each other.
>>>>>>
>>>>>> However, above declaration has only one tile size
>>>>> true, but the members of struct scaler_format are called
>>>>>
>>>>> _____chroma_____tile_w/h
>>>>>
>>>>>> and it means that each plane has always same tile size.
>>>>> this conclusion is not justified
>>>>>
>>>>>> And also RGB formats have 16 x 16 tile size in tile mode but you
>>>>>> declared it as 0.
>>>>> The data sheet says, that all formats have the same Y/RGB tile size
>>>>> and it is always 16x16. That is why only chroma tile size is remembered,
>>>>> because only chroma tile size can be different between formats.
>>>> Ok, chroma_tile_h/w are used to calculate only the position of the chroma
>>>> buffer.
>>>>
>>>> By the way, user space would want to know the size limit in tiled mode so
>>>> that they can allocate each buffer for Y(luma) and CbCr(chroma).
>>>> However, below code would provide Y/RGB tile size limit - 16 - to user
>>>> space,
>>>> static const struct drm_exynos_ipp_limit scaler_5420_tile_limits[] = {
>>>> { IPP_SIZE_LIMIT(BUFFER, .h = { 16, SZ_8K }, .v = { 16, SZ_8K
>>>> })},
>>>> { IPP_SIZE_LIMIT(AREA, .h.align = 16, .v.align = 16) },
>>>>
>>>> It would mean that user space will allocate 16 pixels aligned buffer even
>>>> for chroma but the actual size limit of it would be 8 pixels in case of
>>>> SCALE_YUV420_WP_UV/VU foramt.
>>>> Is there some code I'm missing?
>>> Userspace knows everything needed to allocate proper buffers. Those
>> How does user space know everything? Actually, the size of each plane in
>> tiled mode would depend on Hardware, Scaler device in our case. Is there
>> something user space can know it explictly? Or you mean they can know it
>> implictly?
>
> The size of each plane depends on the selected pixel format only. If you
> select DRM_FORMAT_NV12 + DRM_FORMAT_MOD_SAMSUNG_16_16_TILE modifier,
> then this unambiguously defines buffer size for each plane. Hardware has
> nothing to change here. Userspace can even query if given IPP module
> supports such pixel+modifier combo and get alignment requirements for it.
>
>>> limits describes size of the image buffers in pixels. The size of each
>>> plane (luma or chroma if exists for given format) in bytes directly
>>> comes out of the selected pixel format (fourcc).
>> fourcc would say the size not considered for the Hardware limit.
>
> Alignment can be queried by userspace via get EXYNOS_IPP_GET_LIMITS
> ioctl. It provides limits for given pixel format + tile modifier combo,
> although in case of Exynos Scaler, the alignment requirements are simple
> result of the tiled format definition (tiled formats are typically
> defined only for width/height matching multiples of single tile size).
Right, this is why I commented like below before,
"However, below code would provide Y/RGB tile size limit - 16 - to user space,
static const struct drm_exynos_ipp_limit scaler_5420_tile_limits[] = {
{ IPP_SIZE_LIMIT(BUFFER, .h = { 16, SZ_8K }, .v = { 16, SZ_8K })},
{ IPP_SIZE_LIMIT(AREA, .h.align = 16, .v.align = 16) },
It would mean that user space will allocate 16 pixels aligned buffer even for
chroma but the actual size limit of it would be 8 pixels in case of
SCALE_YUV420_WP_UV/VU foramt."
As you can see, only Y(luma) size limit will be provided to user space, and I'm
saying about CbCr(chroma) size limit.
Anyway, this is a trivial thing. 16 pixels limit for CbCr would be no problem
although really a little bit memory is wasted.
Thanks,
Inki Dae
>
> Best regards
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
