[Mesa-dev] [Libva] vaPutSurface never returns

Vasilis Liaskovitis vliaskov at gmail.com
Fri Feb 19 20:02:04 UTC 2016


Hi,

On Fri, Feb 19, 2016 at 5:04 PM, Emil Velikov <emil.l.velikov at gmail.com>
wrote:

> Was about to mention the same thing as Christian :-)
>
> Vasilis, is there any reason why you're using vdpau + the vdpau to
> vaapi adapter, as opposed to the gallium vaapi target directly ?
>

Someone on #radeon mentioned to not use vaapi mesa driver on radeon. Is
this driver supposed to work on amd GPUs?

I have tried using vaapi driver from oibaf/graphics-drivers, which has mesa
11.2~git1602191930.e6f1a4~gd~t

vainfo output:
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: Trying to open
/usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.2)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints

Using this driver, my app gets an Xerror and also segfaults using this
driver (although the segfault appears to happen in a font rendering
library, not in vaapi itself).

X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  155 (DRI2)
  Minor opcode of failed request:  8 (DRI2SwapBuffers        )
  Resource id in failed request:  0x3800007
  Serial number of failed request:  32
  Current serial number in output stream:  34

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff049ab2b in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff049ab2b in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(gdb) bt
#0  0x00007ffff049ab2b in ?? () from
/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#1  0x00007ffff04a1c24 in ?? () from
/usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007ffff6dddc87 in FTGlyphContainer::Render(unsigned int, unsigned
int, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2
#3  0x00007ffff6de395e in FTFontImpl::Render(char const*, int, FTPoint,
FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2
#4  0x00007ffff6de7e67 in FTTextureFontImpl::Render(char const*, int,
FTPoint, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2
#5  0x00007ffff6de21c3 in FTFont::Render(char const*, int, FTPoint,
FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2
#6  0x00007ffff6de4868 in ftglRenderFont () from
/usr/lib/x86_64-linux-gnu/libftgl.so.2
#7  0x000000000040e3de in font_write (L=0x8d2550) at font.c:68

Full backtrace: http://pastebin.com/VbXgdDT0

This problem does not happen with vdpau (although vdpau encounters the
vdpau_putSurface problem I originally mentioned, and outputs black frames
after a while)
Regarding the vdpau issue, I don't see any dmesg messages about GPU lockup.
Desktop and GPU keeps working fine. Also fence debug info is:
sudo cat /sys/kernel/debug/dri/0/radeon_fence_info
--- ring 0 ---
Last signaled fence 0x0000000000088cf4
Last emitted        0x0000000000088cf4
Last sync to ring 1 0x0000000000000000
Last sync to ring 2 0x0000000000000000
Last sync to ring 3 0x0000000000397e7e
Last sync to ring 4 0x0000000000000000
Last sync to ring 5 0x0000000000002a97
--- ring 1 ---
Last signaled fence 0x0000000000000001
Last emitted        0x0000000000000001
Last sync to ring 0 0x0000000000000000
Last sync to ring 2 0x0000000000000000
Last sync to ring 3 0x0000000000000000
Last sync to ring 4 0x0000000000000000
Last sync to ring 5 0x0000000000000000
--- ring 2 ---
Last signaled fence 0x0000000000000001
Last emitted        0x0000000000000001
Last sync to ring 0 0x0000000000000000
Last sync to ring 1 0x0000000000000000
Last sync to ring 3 0x0000000000000000
Last sync to ring 4 0x0000000000000000
Last sync to ring 5 0x0000000000000000
--- ring 3 ---
Last signaled fence 0x0000000000397e82
Last emitted        0x0000000000397e82
Last sync to ring 0 0x0000000000088cf2
Last sync to ring 1 0x0000000000000000
Last sync to ring 2 0x0000000000000000
Last sync to ring 4 0x0000000000000000
Last sync to ring 5 0x0000000000002a97
--- ring 4 ---
Last signaled fence 0x0000000000000001
Last emitted        0x0000000000000001
Last sync to ring 0 0x0000000000000000
Last sync to ring 1 0x0000000000000000
Last sync to ring 2 0x0000000000000000
Last sync to ring 3 0x0000000000000000
Last sync to ring 5 0x0000000000000000
--- ring 5 ---
Last signaled fence 0x0000000000002aa0
Last emitted        0x0000000000002aa0
Last sync to ring 0 0x0000000000088869
Last sync to ring 1 0x0000000000000000
Last sync to ring 2 0x0000000000000000
Last sync to ring 3 0x0000000000397a54
Last sync to ring 4 0x0000000000000000

thank you,

- Vasilis



>
> Mesa 11.0.x has the said target (toggle with --enable-va at configure
> time), although there has been quite a few fixes from Christian,
> Julien and others since then. As an alternative I'd suggest mesa
> 11.1.x series (or mesa 11.2.0-rc1 coming out later on today).
>
> -Emil
>
> On 19 February 2016 at 09:53, Christian König <deathsimple at vodafone.de>
> wrote:
> > Questions for VDPAU should probably go to either the Mesa list or the
> VDPAU
> > list, libva is completely unrelated to this.
> >
> > Well is it possible that you just locked up the GPU? Please take a look
> at
> > /sys/kernel/debug/dri/0/radeon_fence_info and dmesg.
> >
> > Regards,
> > Christian.
> >
> >
> > Am 18.02.2016 um 23:43 schrieb Vasilis Liaskovitis:
> >
> > Hi,
> >
> > I have an application that renders by binding libva/vdpau surfaces onto
> GLX
> > pixmaps.Playback works ok for a while, but than the application displays
> > black frames after a few minutes of operation (always reproducible within
> > 1-15 minutes usually).
> >
> > When this happens, gdb backtrace shows that the current call to
> > vdpau_PutSurface (done from the application) never returns. Are there any
> > obious reasons that would lead to vaPutSurface to never return (e.g. some
> > deadlock in libva/vdpau?)
> >
> > Using vdpau driver on radeon.
> >
> > Backtrace of thread waiting in vaPutSurface():
> >
> > Thread 8 (Thread 0x7fca1f778700 (LWP 3580)):
> > #0  0x00007fca55a3e12d in poll () at
> ../sysdeps/unix/syscall-template.S:81
> > #1  0x00007fca5316b262 in poll (__timeout=-1, __nfds=1,
> > __fds=0x7fca1f776a20) at
> >     /usr/include/x86_64-linux-gnu/bits/poll2.h:46
> > #2  _xcb_conn_wait (c=c at entry=0x2885500, cond=cond at entry=0x7fca1f776b40,
> >         vector=vector at entry=0x0, count=count at entry=0x0) at
> xcb_conn.c:459
> > #3  0x00007fca5316cadf in wait_for_reply (c=c at entry=0x2885500,
> > request=31161,
> >         e=e at entry=0x0) at xcb_in.c:491
> > #4  0x00007fca5316cbf2 in xcb_wait_for_reply (c=0x2885500, request=31161,
> > e=0x0)
> > at xcb_in.c:521
> > #5  0x00007fca419b8004 in vl_dri2_get_flush_reply (scrn=0x2653600) at
> > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:110
> > #6  0x00007fca419b8101 in vl_dri2_destroy_drawable (scrn=0x2653600) at
> > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:153
> > #7  0x00007fca419b8185 in vl_dri2_set_drawable (scrn=0x2653600,
> >         drawable=71303307) at
> > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:176
> > #8  0x00007fca419b82c8 in vl_dri2_screen_texture_from_drawable
> > (vscreen=0x2653600, drawable=0x440008b) at
> > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:193
> > #9  0x00007fca419b61ab in vlVdpPresentationQueueDisplay
> > (presentation_queue=<optimized out>, surface=5, clip_width=1280,
> >  clip_height=720, earliest_presentation_time=0)
> >         at
> > ../../../../../../src/gallium/state_trackers/vdpau/presentation.c:234
> > #10 0x00007fca423ca6a3 in flip_surface_unlocked
> >         (driver_data=driver_data at entry=0x2650c90,
> >          obj_output=obj_output at entry=0x291a2b0) at vdpau_video_x11.c:583
> > #11 0x00007fca423cb2e1 in queue_surface_unlocked (obj_surface=<optimized
> > out>,
> >         obj_output=0x291a2b0, driver_data=0x2650c90) at
> > vdpau_video_x11.c:610
> > #12 put_surface_unlocked (flags=32, target_rect=0x7fca1f776f90,
> >         source_rect=0x7fca1f776f80, obj_output=0x291a2b0,
> > obj_surface=0x2919bf0,
> >         driver_data=0x2650c90) at vdpau_video_x11.c:689
> > #13 put_surface (driver_data=driver_data at entry=0x2650c90,
> >         surface=surface at entry=50331655, drawable=drawable at entry
> =71303307,
> >         drawable_width=<optimized out>, drawable_height=720,
> >             source_rect=source_rect at entry=0x7fca1f776f80,
> >             target_rect=target_rect at entry=0x7fca1f776f90,
> > flags=flags at entry=32)
> > at vdpau_video_x11.c:755
> > #14 0x00007fca423cb59c in vdpau_PutSurface (ctx=<optimized out>,
> >         surface=50331655, draw=0x440008b, srcx=<optimized out>,
> > srcy=<optimized
> >         out>, srcw=<optimized out>, srch=720, destx=0, desty=0,
> >             destw=1280, desth=720, cliprects=0x0, number_cliprects=0,
> > flags=32)
> > at vdpau_video_x11.c:808
> > #15 0x000000000040eed2 in on_client_draw (glsink=<optimized out>,
> > buf=<optimized
> >         out>, data=0x626d40 <video>) at video.c:619
> >
> >
> > Full backtrace at:http://pastebin.com/RZqmUkMY
> >
> > Using vdpau driver on radeon and:
> >
> > libX11 1.6.2
> > libxcb 1.11 or 1.10
> > mesa 11.0
> >
> >
> > thank you for any help,
> >
> > - Vasilis
> >
> >
> > _______________________________________________
> > Libva mailing list
> > Libva at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/libva
> >
> >
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160219/fbc1101d/attachment-0001.html>


More information about the mesa-dev mailing list