[Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.

[Christian König]

What the heck are you talking about? As far as I can see this patch is 
about adding hw specific alignment to vlVaCreateImage which is a state 
tracker function.

Completely agree that vlVaGetImage should respect the parameters given 
instead of using the one from the surface, but that sounds like a 
different problem.

Maybe mixing mail threads?

Regards,
Christian.

Am 02.10.2018 um 21:34 schrieb Ilia Mirkin:
> vlVaGetImage should respect the x/y/width/height. The surface size
> need not have any correlation to the image size. Someone should
> double-check the docs for how that function should work, but the
> current logic seems completely bogus.
> On Tue, Oct 2, 2018 at 3:09 PM Koenig, Christian
> <Christian.Koenig at amd.com> wrote:
>> Well that's the complete wrong place for that.
>>
>> The stride of the surface is determined by addrlib. That one should handle aligning the parameters.
>>
>> Christian.
>>
>> Am 02.10.2018 20:38 schrieb "Sharma, Deepak" <Deepak.Sharma at amd.com>:
>> Christian, the issue which trying to address here is vlvaGetImage doesn’t use width/height
>> passed to function. box.width is calculated from surface and that will end up in wrong stride for dst buffer
>> for said resolution. So was thinking to use aligned width/height for vaCreateImage as well as surface.
>> But as you said that depends on codec , So I think either we can use width/height aligned based on codec
>> or use passed width/height in vlvaGetImage to fix this issue.
>>
>> Thanks,
>> Deepak
>>
>> -----Original Message-----
>> From: Christian König <ckoenig.leichtzumerken at gmail.com>
>> Sent: Tuesday, October 2, 2018 3:42 AM
>> To: Sharma, Deepak <Deepak.Sharma at amd.com>; mesa-dev at lists.freedesktop.org
>> Cc: Guttula, Suresh <Suresh.Guttula at amd.com>
>> Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
>>
>> Am 02.10.2018 um 03:47 schrieb Sharma, Deepak:
>>> From: suresh guttula <suresh.guttula at amd.com>
>>>
>>> In case of decoding of resolution like 40x24, while allocating surface
>>> video buffer is always aligned with macroblock width/height which is 16.
>>> But when application tries to get data after decoding through
>>> vaCreateImage /vaGetImage, image width/height aligned with 2 and
>>> result a smaller image buffer which causes the memory stomping issue.
>> Well NAK. It depends on the codec if the picture needs to be aligned to
>> 16 or not.
>>
>> For example VC-1 would created decoding errors with that.
>>
>> Regards,
>> Christian.
>>
>>> Signed-off-by: suresh guttula <suresh.guttula at amd.com>
>>> ---
>>>    src/gallium/state_trackers/va/image.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/va/image.c
>>> b/src/gallium/state_trackers/va/image.c
>>> index 3f892c9..2fc47b7 100644
>>> --- a/src/gallium/state_trackers/va/image.c
>>> +++ b/src/gallium/state_trackers/va/image.c
>>> @@ -123,8 +123,8 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat *format, int width, int heig
>>>       img->format = *format;
>>>       img->width = width;
>>>       img->height = height;
>>> -   w = align(width, 2);
>>> -   h = align(height, 2);
>>> +   w = align(width, 16);
>>> +   h = align(height, 16);
>>>
>>>       switch (format->fourcc) {
>>>       case VA_FOURCC('N','V','1','2'):
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev