Bug 110443

(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.

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.

That's incorrect. The only way to get the stride is through winsys_handle. We could add a separate query function though.

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

Yes. It can be just 1 function returning both values and it doesn't have to return boolean.

Thx for the suggestion, I submitted patches here https://gitlab.freedesktop.org/mesa/mesa/merge_requests/721.

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?

Thx a lot for reporting this issue. It should fallback to previous path for r600, at least, I will take a look.

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

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.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796

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.

Thx!

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/797
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/842

The fixes landed in master, as well as in Mesa 19.1.0.

Closing this.