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

[Guttula, Suresh]

While calling ucopy* functions to copy data to image ,it passes box.width which is calculated from surface . If the image buffer created for image dimensions width=40 and u copy use surface width=48. Which is giving a wrong stride for dst buffer.

Thanks,
Suresh G

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Ilia Mirkin <imirkin at alum.mit.edu>
Sent: Tuesday, October 2, 2018 7:53:09 AM
To: Sharma, Deepak
Cc: ML Mesa-dev; Guttula, Suresh
Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.

Looking at vlVaGetImage, it looks like it just copies data into the
texture -- I don't see how UVD is implicated in this. Perhaps the
transfer's stride is being set wrong? Or maybe either
u_copy_nv12_to_yv12 or util_copy_rect (or one of the functions they
call) is having trouble?
On Mon, Oct 1, 2018 at 10:17 PM Sharma, Deepak <Deepak.Sharma at amd.com> wrote:
>
> 16 was considering UVD.
>
> in vlVagetImage, the width,height passed to function is not used but rather the surface width/height and that causes issue in this case,not sure how driver will handle that ?
>
> ________________________________
> From: Ilia Mirkin <imirkin at alum.mit.edu>
> Sent: Monday, October 1, 2018 6:49 PM
> To: Sharma, Deepak
> Cc: ML Mesa-dev; Guttula, Suresh
> Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
>
> On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak <Deepak.Sharma at amd.com> wrote:
> >
> > 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.
>
> Shouldn't the driver be allocating a larger backing texture instead?
> Why 16 and not 8 or 32 or 4096?
>
>   -ilia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181002/ebfd14ea/attachment-0001.html>