Re: [Mesa-dev] leak of gem_objects on intel i965
Hello Kenneth, On 06/16/2011 12:10 AM, Lampersperger Andreas wrote: Hello Stéphane, I've tried your patch (I adopted it to 7.10.3, see attached patch), but it results in a SEGFAULT: Thread [1] 12367 (Suspended : Signal : SIGSEGV:Segmentation fault) st_visual_to_context_mode() at st_manager.c:309 0xb6ea7be0 st_framebuffer_create() at st_manager.c:441 0xb6ea8352 st_api_make_current() at st_manager.c:732 0xb6ea8456 ^^^ This is Gallium code. The official Intel drivers do not use Gallium. Are you trying to use the unsupported i965g driver? No, I'm just using http://www.x.org/releases/individual/driver/xf86-video-intel-2.15.0.tar.bz2 Did I made some mistakes with configuring packages? -Andreas dri_make_current() at dri_context.c:194 0xb6e4662f driBindContext() at dri_util.c:196 0xb6e425a9 dri2_bind_context() at dri2_glx.c:151 0xb7480d10 MakeContextCurrent() at glxcurrent.c:263 0xb7459b2d glXMakeCurrent() at glxcurrent.c:287 0xb7459c43 gdk_gl_window_impl_x11_make_context_current() at gdkglwindow-x11.c:250 0xb7fc583e gdk_gl_drawable_gl_begin() at gdkgldrawable.c:143 0xb7fa384d configure_event() at simple.c:81 0x8049982 ... In st_framebuffer_create() stfbi-visual was not initialized. Do I have to apply other patches to 7.10.3? -Andreas --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Matthias Fauser, Sebastian Tondorf E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] leak of gem_objects on intel i965
Hello Stéphane,
I've applied your Patch against git mesa from yesterday.
It also results in the same SEGFAULT running simple from
the gtkglext examples. (see backtrace below, in
st_visual_to_context_mode(..) visual is not initialized properly).
When I try pure mesa git from yesterday, no SEGFAULT occurs but
the gem_object leak occurs with the modified simple.c.
(Running the attached modified simple.c from
the gtkglext examples for 2 minutes results in 500 MB object bytes)
Thread [1] 15321 (Suspended : Signal : SIGSEGV:Segmentation fault)
st_visual_to_context_mode() at st_manager.c:310 0xb63fdd20
st_framebuffer_create() at st_manager.c:436 0xb63fe4a9
st_api_make_current() at st_manager.c:729 0xb63fe586
dri_make_current() at dri_context.c:194 0xb636e79f
driBindContext() at dri_util.c:196 0xb636a4f9
dri2_bind_context() at dri2_glx.c:151 0xb7476950
MakeContextCurrent() at glxcurrent.c:275 0xb744f63b
glXMakeCurrent() at glxcurrent.c:294 0xb744f753
gdk_gl_window_impl_x11_make_context_current() at
gdkglwindow-x11.c:250 0xb7fc483e
gdk_gl_drawable_gl_begin() at gdkgldrawable.c:143 0xb7fa284d
configure_event() at simple.c:83 0x80496c2
_gtk_marshal_BOOLEAN__BOXED() at gtkmarshalers.c:84 0xb7c19d40
IA__g_closure_invoke() at gclosure.c:767 0xb72ee2bb
signal_emit_unlocked_R() at gsignal.c:3.244 0xb72ff61d
IA__g_signal_emit_valist() at gsignal.c:2.987 0xb730092f
IA__g_signal_emit() at gsignal.c:3.034 0xb7300c49
gtk_widget_event_internal() at gtkwidget.c:4.761 0xb7d29134
gtk_drawing_area_send_configure() at gtkdrawingarea.c:148
0xb7b96b50
gtk_drawing_area_realize() at gtkdrawingarea.c:110 0xb7b96d47
IA__g_cclosure_marshal_VOID__VOID() at gmarshal.c:77 0xb72fb82b
...more frames...
Von: marc...@google.com [mailto:marc...@google.com] Im Auftrag von Stéphane
Marchesin
Gesendet: Donnerstag, 16. Juni 2011 19:29
An: Lampersperger Andreas
Cc: mesa-dev@lists.freedesktop.org
Betreff: Re: [Mesa-dev] leak of gem_objects on intel i965
On Thu, Jun 16, 2011 at 02:05, Lampersperger Andreas
lampersperger.andr...@heidenhain.demailto:lampersperger.andr...@heidenhain.de
wrote:
Hello Stéphane,
your are right, I forgot to attach, here it is...
Erm, you miss half the patch in there... Can you try with my patch on git mesa
instead?
Stéphane
/PREp
--
br
Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office:
Traunreut br
Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard br
Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender /
Chairman),br
Michael Grimm, Matthias Fauser, Sebastian Tondorfbrbr
a href=http://www.heidenhain.de/disclaimer; target=_blankE-Mail
Haftungsausschluss / E-Mail Disclaimer/abrpre
/*
* simple.c:
* Simple GtkGLExt example.
*
* written by Naofumi Yasufuku naof...@users.sourceforge.net
*/
#include stdlib.h
#include gtk/gtk.h
#include gdk/gdkx.h
#include gtk/gtkgl.h
#ifdef G_OS_WIN32
#define WIN32_LEAN_AND_MEAN 1
#include windows.h
#endif
#include GL/gl.h
#include GL/glu.h
#include X11/Xlib.h
static void
realize (GtkWidget *widget,
gpointer data)
{
if (!GTK_WIDGET_REALIZED(widget)) gtk_widget_realize(widget);
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
GLUquadricObj *qobj;
static GLfloat light_diffuse[] = {1.0, 0.0, 0.0, 1.0};
static GLfloat light_position[] = {1.0, 1.0, 1.0, 0.0};
/*** OpenGL BEGIN ***/
if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return;
qobj = gluNewQuadric ();
gluQuadricDrawStyle (qobj, GLU_FILL);
glNewList (1, GL_COMPILE);
gluSphere (qobj, 1.0, 20, 20);
glEndList ();
glLightfv (GL_LIGHT0, GL_DIFFUSE, light_diffuse);
glLightfv (GL_LIGHT0, GL_POSITION, light_position);
glEnable (GL_LIGHTING);
glEnable (GL_LIGHT0);
glEnable (GL_DEPTH_TEST);
glClearColor (1.0, 1.0, 1.0, 1.0);
glClearDepth (1.0);
glViewport (0, 0,
widget-allocation.width, widget-allocation.height);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
gluPerspective (40.0, 1.0, 1.0, 10.0);
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();
gluLookAt (0.0, 0.0, 3.0,
0.0, 0.0, 0.0,
0.0, 1.0, 0.0);
glTranslatef (0.0, 0.0, -3.0);
gdk_gl_drawable_gl_end (gldrawable);
/*** OpenGL END ***/
}
static gboolean
configure_event (GtkWidget *widget,
GdkEventConfigure *event,
gpointer data)
{
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable
Re: [Mesa-dev] leak of gem_objects on intel i965
Hello Stéphane, your are right, I forgot to attach, here it is... Andreas Von: marc...@google.com [mailto:marc...@google.com] Im Auftrag von Stéphane Marchesin Gesendet: Donnerstag, 16. Juni 2011 10:52 An: Lampersperger Andreas Cc: mesa-dev@lists.freedesktop.org Betreff: Re: [Mesa-dev] leak of gem_objects on intel i965 On Thu, Jun 16, 2011 at 00:10, Lampersperger Andreas lampersperger.andr...@heidenhain.demailto:lampersperger.andr...@heidenhain.de wrote: Hello Stéphane, I've tried your patch (I adopted it to 7.10.3, see attached patch), but it results in a SEGFAULT: Hmm right I'm working against mesa git. That said, I don't see an attached patch :) Stéphane /PREp -- br Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office: Traunreut br Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard br Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman),br Michael Grimm, Matthias Fauser, Sebastian Tondorfbrbr a href=http://www.heidenhain.de/disclaimer; target=_blankE-Mail Haftungsausschluss / E-Mail Disclaimer/abrpre mesa_7.3-implement-glx-refcounting_1.patch Description: mesa_7.3-implement-glx-refcounting_1.patch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Thu, Jun 16, 2011 at 02:05, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello Stéphane, ** ** your are right, I forgot to attach, here it is... ** Erm, you miss half the patch in there... Can you try with my patch on git mesa instead? Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Wed, 15 Jun 2011 10:53:13 +0200, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello, I've tried 2.6.39.1 and the gem_objects leak still exists. I found the leak also on a i915 not only on a i965. I recommend focusing your debugging efforts on i965. If we solve the problem in the new driver, and still find that the leaks occur in the old driver, only then should we begin digging through the old driver. It only disappears if I set LIBGL_ALLWAYS_SOFTWARE (not really an opinion ;-). Nope ;) Now I can try to update user space libraries, what lib would you suspect most? libdrm 2.4.23 xorg-server 1.10.2 xf86-video-intel-2.15 gtkglext-1.2.0 mesa-7.10.2 xorg-server: I highly doubt this is guilty. libdrm: All calls out to libdrm are made directly by xf86-video-intel or mesa. So, if a problem exists with libdrm, that problem will be solved by debugging xf86-video-intel or mesa. gtkglext: Can't say. xf86-video-intel and mesa: Likely culprits. I am more suspicious of Mesa than the X driver. Or I can continue debugging, if anyone can give me a hint to the following question: Great! In which function are the buffers freed, which are received from xserver via DRI2GetBuffersWithFormat(..) at dri2.c:431? -Andreas Ah... In Mesa, the buffers are never freed, actually. Mesa just decrements the gem buffer's refcount with drm_intel_bo_unreference(), and the kernel does the freeing at garbage collection. (Chris, correct me if I'm wrong here.) The buffers obtained by DRI2GetBuffersWithFormat get referenced in exactly one location. Here's the callstack, as I understand it. gem_bo means gem buffer object. intel_udpate_renderbuffers intel_query_dri2_buffers_no_separate_stencil dri2GetBuffersWithFormat DRI2GetBuffersWithFormat # Referencing happens later intel_process_dri2_buffers_no_separate_stencil intel_region_alloc_for_handle intel_bo_gem_create_from_name drm_intel_gem_bo_reference # Reference gem buffer intel_renderbuffer_set_region intel_region_reference # Reference current region intel_region_release # Release old region drm_intel_bo_unreference # Release old gem buffer The buffers can get released from two possible paths: 1) The intel_update_renderbuffers path above, and 2) from within intel_delete_renderbuffer(). Good luck chasing this down. And don't prematurely eliminate the possiblity that the problem may lie in xf86-video-intel or gtkglext. - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Wed, Jun 15, 2011 at 01:53, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello, I've tried 2.6.39.1 and the gem_objects leak still exists. I found the leak also on a i915 not only on a i965. It only disappears if I set LIBGL_ALLWAYS_SOFTWARE (not really an opinion ;-). Now I can try to update user space libraries, what lib would you suspect most? libdrm 2.4.23 xorg-server 1.10.2 xf86-video-intel-2.15 gtkglext-1.2.0 mesa-7.10.2 Or I can continue debugging, if anyone can give me a hint to the following question: In which function are the buffers freed, which are received from xserver via DRI2GetBuffersWithFormat(..) at dri2.c:431? This sounds familiar. You may want to try the patch I posted earlied today (glx: implement drawable refcounting). Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 12:20:28 +0200, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello, running my application over a long time results in a kernel freeze or OOM kill, because reparenting a gtkglext drawing area on a intel i965 causes a leak of gem_objects. That sounds like a simple test case to concoct. Do you have one handy? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 13:05:56 +0200, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Hello Chris, I have modified the simple.c from the gtkglext examples. Just replace in gtkglext-1.2.0/examples the original simple.c with the attached version. Builds fine. I see a flashing quadric (every other frame, the gtkglarea appears unrealized) and watching /sys/kernel/debug/dri/0/i915_gem_objects, the number of bo remains static. I think the most likely suspect is i915.ko. Over the years we've had a number of gem leaks mostly associated with vma references and I'm pretty sure that they have not all been backported to 2.6.33 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 15:21:13 +0200, Lampersperger Andreas lampersperger.andr...@heidenhain.de wrote: Which Versions of libdrm mesa xf86_video_intel xorg-server gtkglext linux-kernel do you use? All apart from gtkglext were compiled from git with my own patches included. None of those patches were to address this issue. You think the most suspect part is i915.ko? I watched (via systemtap) all calls to drm_gem_object_alloc(), drm_gem_object_free(), and to drm_gem_object_destroy() (in drm.ko) and I saw that with every realize/unrealize of simple.c there are 2 drm_gem_object_alloc() calls (between other drm_gem_object_allocs/frees) where I cannot found a suitable drm_gem_object_free or .._destroy call. This leads me to suspect the user-space. Or is this wrong, that for every drm_gem_object_alloc()-call there have to be a drm_gem_object_free()-call? Also beware that userspace caches inactive objects. They should be released after a second or so, but that behaviour will obfuscate what is happening lower down. Can you give me some hint, where to start debugging/watching in i915.ko? Yes, start from 2.6.39. But on second thoughts, the v2.6.33 drm_gem_vm_close() has the unref but not the close, which is a different type of leak. If the leak still occurs with 2.6.39, it is definitely in userspace. ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
