[Bug 90515] memory use increase with vdpau

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bug ID 90515
Summary memory use increase with vdpau
Product Mesa
Version 10.4
Hardware Other
OS All
Status NEW
Severity normal
Priority medium
Component Drivers/Gallium/radeonsi
Assignee dri-devel@lists.freedesktop.org
Reporter fabrice@bellet.info
QA Contact dri-devel@lists.freedesktop.org

I noticed a constant increase of rss memory while playing a video using vdpau +
radeonsi, caused by X events accumulating in read_packet (c=0x8275a0) at
xcb_in.c:333, and never flushed, and corresponding to this backtrace :

Breakpoint 6, read_packet (c=0x8275a0) at xcb_in.c:333
(gdb) bt
#0  0x00007fffec99b281 in read_packet (c=0x8275a0) at xcb_in.c:333
#1  0x00007fffec99c742 in _xcb_in_read (c=0x8275a0) at xcb_in.c:936
#2  0x00007fffec999ae4 in _xcb_conn_wait (c=0x8275a0, cond=0x7fffe1636960,
vector=0x0, count=0x0) at xcb_conn.c:495
#3  0x00007fffec99b78b in wait_for_reply (c=0x8275a0, request=207, e=0x0) at
xcb_in.c:493
#4  0x00007fffec99b8a4 in xcb_wait_for_reply (c=0x8275a0, request=207, e=0x0)
at xcb_in.c:523
#5  0x00007fffea7c5ac8 in xcb_dri2_swap_buffers_reply (c=0x8275a0, cookie=...,
e=0x0) at dri2.c:893
#6  0x00007fffe6a982f0 in vl_dri2_get_flush_reply (scrn=0x83cab0) at
../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:103
#7  0x00007fffe6a984b4 in vl_dri2_destroy_drawable (scrn=0x83cab0) at
../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:146
#8  0x00007fffe6a98524 in vl_dri2_set_drawable (scrn=0x83cab0,
drawable=41943041) at ../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:162
#9  0x00007fffe6a988ed in vl_screen_get_timestamp (vscreen=0x83cab0,
drawable=41943041)    at
../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:269
#10 0x00007fffe6aa193d in vlVdpPresentationQueueGetTime   
(presentation_queue=11,    current_time=0x7fffe1636b80) at presentation.c:189
#11 0x00007fffe6aa1f04 in vlVdpPresentationQueueBlockUntilSurfaceIdle
(presentation_queue=11, surface=13, first_presentation_time=0x7fffe1636b80) at
presentation.c:335
#12 0x00007fffe719fb51 in put_surface () at
/usr/lib64/dri/radeonsi_drv_video.so
#13 0x00007fffe719fdcf in vdpau_PutSurface () at
/usr/lib64/dri/radeonsi_drv_video.so
#14 0x00007fffed5ead37 in gst_vaapi_texture_glx_put_surface (flags=0,
crop_rect=0x7fffe1636d20,    surface=0x7fffdc08fd90,   
base_texture=0x7fffcc1385a0) at gstvaapitexture_glx.c:315
#15 0x00007fffed5ead37 in gst_vaapi_texture_glx_put_surface
(texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=0x7fffe1636d20,
flags=0) at gstvaapitexture_glx.c:378
#16 0x00007fffedf6e1b1 in gst_vaapi_texture_put_surface
(texture=0x7fffcc1385a0, surface=0x7fffdc08fd90, crop_rect=<optimized out>,
flags=<optimized out>) at gstvaapitexture.c:332
#17 0x00007fffe99118ec in _do_upload_with_meta (context=<optimized out>,
upload=0x7fffdc029600 [GstGLUpload]) at gstglupload.c:357
#18 0x00007fffe9913198 in _run_message_sync (message=0x7fffe1e37840) at
gstglwindow.c:353
#19 0x00007fffe9917a82 in _run_message (message=0x7fffd8001b60)    at
gstglwindow_x11.c:598
#20 0x00007ffff73857fb in g_main_context_dispatch (context=0x7fffcc010980) at
gmain.c:3111
#21 0x00007ffff73857fb in g_main_context_dispatch
(context=context@entry=0x7fffcc010980) at gmain.c:3710
#22 0x00007ffff7385b98 in g_main_context_iterate (context=0x7fffcc010980,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at
gmain.c:3781
#23 0x00007ffff7385ec2 in g_main_loop_run (loop=0x7fffcc010b70)    at
gmain.c:3975
#24 0x00007fffe9901cf7 in gst_gl_context_create_thread (context=0x7fffdc023260
[GstGLContextGLX]) at gstglcontext.c:959
#25 0x00007ffff73ac3d5 in g_thread_proxy (data="" at gthread.c:764
#26 0x00007ffff6f2352a in start_thread (arg=0x7fffe1637700) at
pthread_create.c:310
#27 0x00007ffff6c5f22d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

The commands generating this case is :

# ln -s vdpau_drv_video.so /usr/lib64/dri/radeonsi_drv_video.so
$ export VDPAU_DRIVER=radeonsi
$ wget
http://samples.mplayerhq.hu/MPEG-4/NeroRecodeSample-MP4/NeroRecodeSample.mp4
$ gst-launch-1.0 filesrc location=NeroRecodeSample.mp4 ! qtdemux !
mpeg4videoparse ! vaapidecode ! videoconvert ! glimagesink

The two malloc() occuring in libxcb in read_packet() are sufficient to make
gst-launch-1.0 memory use grow out of control. It seems to occur because
vl_dri2_set_drawable() is called alternatively with two different drawables,
each call destroying the previous drawable.


You are receiving this mail because:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux