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.sha...@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 <imir...@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.sha...@amd.com> wrote:
> >
> > From: suresh guttula <suresh.gutt...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
