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.koe...@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.sha...@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.leichtzumer...@gmail.com>
Sent: Tuesday, October 2, 2018 3:42 AM
To: Sharma, Deepak <deepak.sha...@amd.com>; mesa-dev@lists.freedesktop.org
Cc: Guttula, Suresh <suresh.gutt...@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.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.
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.gutt...@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@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
