| Bug ID | 110443 |
|---|---|
| Summary | vaapi/vpp: wrong output for non 64-bytes align width (ex: 120= 0) |
| Product | Mesa |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | julien.isorce@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
vaDeriveImage reports wrong stride. Indeed Mesa's vlVaDeriveImage always sets the stride to w * 4 for RGBA form= at https://cgit.freedesktop.org/mesa/mesa/tree/src/gal= lium/state_trackers/va/image.c#n259=20 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/gal= lium/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) ?
(In reply to Julien Isorce from comment #0) > vaDeriveImage reports wrong stride. >=20 > Indeed Mesa's vlVaDeriveImage always sets the stride to w * 4 for RGBA > format > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/st= ate_trackers/va/ > image.c#n259=20 >=20 > This results in wrong video output, see > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/1= 00 >=20 > Is there a way to know the pipe_resource's stride > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/st= ate_trackers/va/ > image.c#n283 without exporting it to dmabuf (through whandle.stride) a= nd > without mapping it (drv->pipe->transfer_map / pipe_transfer.stri= de) ? 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 vlVaDeriveIm= age: - w =3D align(surf->buffer->width, 2); - h =3D align(surf->buffer->height, 2); + + alignment =3D screen->get_param(screen, PIPE_CAP_MIN_MAP_BUFFER_ALIG= NMENT); + w =3D align(surf->buffer->width, alignment); + h =3D align(surf->buffer->height, alignment); here https://cgit.freedesktop.org/mesa/mesa/tree/src/gal= lium/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 wi= nsys_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 do= esn't have to return boolean.
Thx for the suggestion, I submitted patches here htt= ps://gitlab.freedesktop.org/mesa/mesa/merge_requests/721.
| What | Removed | Added |
|---|---|---|
| CC | viktor_jaegerskuepper@freenet.de |
After commit 0e3a348bec436b9d949e85574e363a1fe0e7683c VLC cras= hes when I want to play a video encoded in H.264 using VA-API. I have an AMD RV770, OS is A= rch 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 ye= t, 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 prev= ious 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/b= lob/master/src/gallium/state_trackers/va/image.c#L254
I tried to investigate a bit further, and I think video accele= ration 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&= quot; before the change.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796
I tested the commit in the merge request together with the r60= 0-related change which has already been committed to the master branch, VLC doesn't crash any more.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796 htt= ps://gitlab.freedesktop.org/mesa/mesa/merge_requests/797 htt= ps://gitlab.freedesktop.org/mesa/mesa/merge_requests/842
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
The fixes landed in master, as well as in Mesa 19.1.0. Closing this.