I haven't checked in detail, but vlVaGetImage appears to ignore the passed-in x/y/width/height parameters. What happens if e.g. you have a 1000x1000 surface, and I call vlVaGetImage(x=10,y=10,width=1,height=1)? Shouldn't it just return me one pixel? If this is legal, then these limits need to be taken account in vlVaGetImage.
-ilia On Mon, Oct 1, 2018 at 10:57 PM Guttula, Suresh <suresh.gutt...@amd.com> wrote: > > 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 > > ________________________________ > From: Ilia Mirkin <imir...@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.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
