Bug 110443 - vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
Summary: vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-16 04:41 UTC by Julien Isorce
Modified: 2019-06-11 16:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Julien Isorce 2019-04-16 04:41:34 UTC
vaDeriveImage reports wrong stride.

Indeed Mesa's vlVaDeriveImage always sets the stride to w * 4 for RGBA format https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n259 

This results in wrong video output, see https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/100

Is there a way to know the pipe_resource's stride https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n283 without exporting it to dmabuf (through whandle.stride) and without mapping it (drv->pipe->transfer_map / pipe_transfer.stride) ?
Comment 1 Marek Olšák 2019-04-16 20:02:08 UTC
(In reply to Julien Isorce from comment #0)
> vaDeriveImage reports wrong stride.
> 
> Indeed Mesa's vlVaDeriveImage always sets the stride to w * 4 for RGBA
> format
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/
> image.c#n259 
> 
> This results in wrong video output, see
> https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/100
> 
> Is there a way to know the pipe_resource's stride
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/
> image.c#n283 without exporting it to dmabuf (through whandle.stride) and
> without mapping it (drv->pipe->transfer_map / pipe_transfer.stride) ?

No, there isn't. whandle.stride is pipe_resource's stride and is for GPU access. pipe_transfer.stride can be different and is for CPU access.
Comment 2 Julien Isorce 2019-04-16 20:16:00 UTC
Thx for your comment. What about the following in vlVaDeriveImage:

-   w = align(surf->buffer->width, 2);
-   h = align(surf->buffer->height, 2);
+
+   alignment = screen->get_param(screen, PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT);
+   w = align(surf->buffer->width, alignment);
+   h = align(surf->buffer->height, alignment);

here https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/image.c#n235

This is not entirely right but I feel it has more chance to succeed than the current align 2. At least it works on my GFX6 card.
Comment 3 Marek Olšák 2019-04-16 23:47:36 UTC
That's incorrect. The only way to get the stride is through winsys_handle. We could add a separate query function though.
Comment 4 Julien Isorce 2019-04-18 16:51:35 UTC
Something like this:

--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -262,6 +262,15 @@ struct pipe_screen {
                                  struct winsys_handle *handle,
                                  unsigned usage);
 
+   boolean (*resource_get_stride)(struct pipe_screen *screen,
+                                  struct pipe_context *context,
+                                  struct pipe_resource *tex,
+                                  unsigned *stride);
+   boolean (*resource_get_offset)(struct pipe_screen *screen,
+                                  struct pipe_context *context,
+                                  struct pipe_resource *tex,
+                                  unsigned *offset);
+

? Thx
Comment 5 Marek Olšák 2019-04-19 22:37:54 UTC
Yes. It can be just 1 function returning both values and it doesn't have to return boolean.
Comment 6 Julien Isorce 2019-04-23 22:48:33 UTC
Thx for the suggestion, I submitted patches here https://gitlab.freedesktop.org/mesa/mesa/merge_requests/721.
Comment 7 Viktor Jägersküpper 2019-05-01 22:24:01 UTC
After commit 0e3a348bec436b9d949e85574e363a1fe0e7683c VLC crashes when I want to play a video encoded in H.264 using VA-API. I have an AMD RV770, OS is Arch Linux. From the merge request I see that there is an additional commit for radeonsi to fix this bug, but not for r600. Since this bug is not closed yet, is another commit for r600 necessary to not break that driver? Or should I open another bug report for the crash?
Comment 8 Julien Isorce 2019-05-01 22:27:24 UTC
Thx a lot for reporting this issue. It should fallback to previous path for r600, at least, I will take a look.
Comment 9 Julien Isorce 2019-05-01 23:18:50 UTC
I think it is missing a:

"if (screen->resource_get_info)"

here
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/state_trackers/va/image.c#L254
Comment 10 Viktor Jägersküpper 2019-05-02 20:15:19 UTC
I tried to investigate a bit further, and I think video acceleration does not really work on my RV770, neither with VA-API nor with VDPAU. However, even if I deactivate hardware video decoding in VLC, it crashes when I want to play a video.

So I think you're right, it should just fall back to whatever "worked" before the change.
Comment 12 Viktor Jägersküpper 2019-05-03 19:49:58 UTC
I tested the commit in the merge request together with the r600-related change which has already been committed to the master branch, VLC doesn't crash any more.
Comment 13 Julien Isorce 2019-05-03 19:56:54 UTC
Thx!
Comment 15 Juan A. Suarez 2019-06-11 16:02:00 UTC
The fixes landed in master, as well as in Mesa 19.1.0.

Closing this.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.