Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
I understand the problem with vlVaGetImage not respecting parameter and that has to be fixed. Christian, could you please provide some more input on addrlib alignment for fixing this. Thanks, Deepak -Original Message- From: Ilia Mirkin Sent: Wednesday, October 3, 2018 8:03 AM To: Koenig, Christian Cc: Sharma, Deepak ; ML Mesa-dev ; Guttula, Suresh Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. On Wed, Oct 3, 2018 at 10:59 AM Koenig, Christian wrote: > > Am 03.10.2018 um 16:56 schrieb Ilia Mirkin: > > On Wed, Oct 3, 2018 at 9:36 AM Christian König > > wrote: > >> 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? > > The stated reason (when I originally asked why this was being done) > > was that vlVaGetImage would overwrite bits past the image created > > with vlVaCreateImage (because it uses the full surface size, rather > > than the x/y/width/height clipped to both the image and the > > surface). My comment was that the fix needs to go into vlVaGetImage, > > not into vlVaCreateImage. > > Ah! Yeah, as I said that is a problem on it's own. > > But what Deepak is trying to address here really sounds like a problem > in a deeper layer. addrlib is really not aligning the resulting > texture correctly when we see problems like that. That was not my understanding. vlVaCreateImage creates a linear image, not a render surface. vlVaGetImage then writes data to it, and goes way over because the underlying surface's dimensions are larger than the image's (because the underlying surface *does* have the proper alignment). But perhaps I misunderstood. Either way, I think we're in agreement that vlVaGetImage needs fixing :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
On Wed, Oct 3, 2018 at 10:59 AM Koenig, Christian wrote: > > Am 03.10.2018 um 16:56 schrieb Ilia Mirkin: > > On Wed, Oct 3, 2018 at 9:36 AM Christian König > > wrote: > >> 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? > > The stated reason (when I originally asked why this was being done) > > was that vlVaGetImage would overwrite bits past the image created with > > vlVaCreateImage (because it uses the full surface size, rather than > > the x/y/width/height clipped to both the image and the surface). My > > comment was that the fix needs to go into vlVaGetImage, not into > > vlVaCreateImage. > > Ah! Yeah, as I said that is a problem on it's own. > > But what Deepak is trying to address here really sounds like a problem > in a deeper layer. addrlib is really not aligning the resulting texture > correctly when we see problems like that. That was not my understanding. vlVaCreateImage creates a linear image, not a render surface. vlVaGetImage then writes data to it, and goes way over because the underlying surface's dimensions are larger than the image's (because the underlying surface *does* have the proper alignment). But perhaps I misunderstood. Either way, I think we're in agreement that vlVaGetImage needs fixing :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
Am 03.10.2018 um 16:56 schrieb Ilia Mirkin: > On Wed, Oct 3, 2018 at 9:36 AM Christian König > wrote: >> 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? > The stated reason (when I originally asked why this was being done) > was that vlVaGetImage would overwrite bits past the image created with > vlVaCreateImage (because it uses the full surface size, rather than > the x/y/width/height clipped to both the image and the surface). My > comment was that the fix needs to go into vlVaGetImage, not into > vlVaCreateImage. Ah! Yeah, as I said that is a problem on it's own. But what Deepak is trying to address here really sounds like a problem in a deeper layer. addrlib is really not aligning the resulting texture correctly when we see problems like that. Christian. > > Cheers, > >-ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
On Wed, Oct 3, 2018 at 9:36 AM Christian König wrote: > > 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? The stated reason (when I originally asked why this was being done) was that vlVaGetImage would overwrite bits past the image created with vlVaCreateImage (because it uses the full surface size, rather than the x/y/width/height clipped to both the image and the surface). My comment was that the fix needs to go into vlVaGetImage, not into vlVaCreateImage. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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
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" :
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
Sent: Tuesday, October 2, 2018 3:42 AM
To: Sharma, Deepak ; mesa-dev@lists.freedesktop.org
Cc: Guttula, Suresh
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
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
---
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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
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" :
> 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
> Sent: Tuesday, October 2, 2018 3:42 AM
> To: Sharma, Deepak ; mesa-dev@lists.freedesktop.org
> Cc: Guttula, Suresh
> 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
> >
> > 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
> > ---
> > 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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" :
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
Sent: Tuesday, October 2, 2018 3:42 AM
To: Sharma, Deepak ; mesa-dev@lists.freedesktop.org
Cc: Guttula, Suresh
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
>
> 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
> ---
> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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
Sent: Tuesday, October 2, 2018 3:42 AM
To: Sharma, Deepak ; mesa-dev@lists.freedesktop.org
Cc: Guttula, Suresh
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
>
> 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
> ---
> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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
---
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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 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 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 > 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 wrote: > > > > From: suresh guttula > > > > 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
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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 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 > 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 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 > > 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 wrote: > > > > > > From: suresh guttula > > > > > > 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
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 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 > 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 wrote: > > > > From: suresh guttula > > > > 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
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
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 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 wrote: > > From: suresh guttula > > 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
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > From: suresh guttula > > 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
