Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 12:39:15 +0200 Maxim Levitsky wrote: > On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: > > On Sun, 07 Mar 2010 00:24:24 +0200 > > Maxim Levitsky wrote: > > > > > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote: > > > > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: > > > > > On Sat, 06 Mar 2010 18:02:51 +0100 > > > > > Stephan Raue wrote: > > > > > > > > > > > looks this like my problems that i have reported some days ago with > > > > > > Subject "Problem using an Mesa based App with recent > > > > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx > > > > > > list? > > > > > > > > > > > > i have still this issue, but i dont know what you need for > > > > > > informations > > > > > > to fix the issues? > > > > > > > > > > > > with ati driver i dont have problems, only here with intel driver > > > > > > on my > > > > > > Thinkpad X200t with intel HDA Graphics card > > > > > > > > > > > > > > I now see that compiz hangs in same way. > > > > > > > > Attached are backtrace of the compiz, and backtrace of etracer which did > > > > start full screen but became hung on resolution change. > > > > > > > > Best regards, > > > > Maxim Levitsky > > > > > > Other info that might help: > > > > > > I took a look at X and found that it was in normal waiting state > > > sleeping waiting for input. > > > > > > Also, I found when 'unstable' mesa would appear to work when I start the > > > X while 'stable' one is used. It was compiz. When compiz is running > > > using stable mesa, an game does change the resolution 'usualy' without > > > hang even if uses unstable mesa. > > > > > > Best regards, > > > Maxim Levitsky > > > > i found that the kernel updates for 2.6.34-rc1 did make the hang time > > out... this has to be some vblank issue, i assume... > > > Note that I did try git master of linus tree, and that didn't help with > the hang at all (now pulled it again, but don't see any changes in drm > code) > > Best regards, > Maxim Levisky yeah. i'm sorry. My issues vanished with current git versions of libdrm,mesa,xserver,xf86-video-intel ... while trying to find out(in vain) which part of the stack did fix the issue, i noticed that the xserver-patches in jesse's tree was which changed "hung" into "timeout"... hth, Flo -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue wrote: > looks this like my problems that i have reported some days ago with > Subject "Problem using an Mesa based App with recent > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list? > > i have still this issue, but i dont know what you need for informations > to fix the issues? > > with ati driver i dont have problems, only here with intel driver on my > Thinkpad X200t with intel HDA Graphics card > > Stephan > > Am 06.03.2010 17:46, schrieb Maxim Levitsky: > > Here, gdb backtrace while running sauerbraten full screen: > > > > > > #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 > > #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 > > #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, > > discard=0) at xcb_io.c:454 > > #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, > > drawable=62914575, width=0x93eed74, height=0x93eed78, > > attachments=0xbfc6a5dc, count=2, > > outCount=0xbfc6a608) at dri2.c:428 > > #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, > > width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, > > out_count=0xbfc6a608, > > loaderPrivate=0x93eecb0) at dri2_glx.c:435 > > #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, > > drawable=0x93eed50) at intel_context.c:253 > > #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at > > intel_context.c:395 > > #9 0xb657a423 in brw_try_draw_prims (ctx=, > > arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 > > '\001', > > min_index=0, max_index=3) at brw_draw.c:340 > > #10 brw_draw_prims (ctx=, arrays=0x910418c, > > prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', > > min_index=0, max_index=3) > > at brw_draw.c:441 > > #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at > > vbo/vbo_exec_draw.c:384 > > #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfdfc, > > unmap=255 '\377') at vbo/vbo_exec_api.c:872 > > #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at > > vbo/vbo_exec_api.c:906 > > #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 > > '\001') at main/enable.c:283 > > #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007 > > #16 0x080abf08 in ?? () > > #17 0x080ad3fc in ?? () > > #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, > > ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, > > rtld_fini=0xb789cd20<_dl_fini>, > > > > > > Best regards, > > Maxim Levitsky > > > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > with glxgears I can reproduce a hang in _XReply with the same backtrace up to intel_prepare_render.. i think there are some vblank events going awol or somewhat like that.. i just have to move glxgears from one xrandr head to the next... (a little bit timing in there, but nonetheless it is easy to trigger) with the soon-to-be linux-2.6.34-rc1 however, it will now only hang some 1 or 2 secs then continue to run. i'm running on 64bit... (kernel + userland) ... hth, Flo -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 6 Mar 2010 15:11:59 -0800 Jesse Barnes wrote: > It would help to know what the server is doing at this point with the > client. It may be that it put the client to sleep and hasn't woken it > up yet, or there could be something wrong with our getbuffers code in > the new scheme. > > Jesse > i played a little with parallel debugging of glxgears and X ... i could manage it somewhat... one problem i had, was that after a while the screen-saver would disable my displays and then glxgears wouldnt hang anymore... (where to disable that?) the other problem i faced was, that i could happily step through the dispatch loop in the xserver and could also break in the dri2GetBuffersWithFormat, but i didn't know what to look at... what datastructures hold the xserver-side state of the client? hm.. i think i have to give that another go... cheers, Flo -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky wrote: > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote: > > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: > > > On Sat, 06 Mar 2010 18:02:51 +0100 > > > Stephan Raue wrote: > > > > > > > looks this like my problems that i have reported some days ago with > > > > Subject "Problem using an Mesa based App with recent > > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx > > > > list? > > > > > > > > i have still this issue, but i dont know what you need for informations > > > > to fix the issues? > > > > > > > > with ati driver i dont have problems, only here with intel driver on my > > > > Thinkpad X200t with intel HDA Graphics card > > > > > > > > I now see that compiz hangs in same way. > > > > Attached are backtrace of the compiz, and backtrace of etracer which did > > start full screen but became hung on resolution change. > > > > Best regards, > > Maxim Levitsky > > Other info that might help: > > I took a look at X and found that it was in normal waiting state > sleeping waiting for input. > > Also, I found when 'unstable' mesa would appear to work when I start the > X while 'stable' one is used. It was compiz. When compiz is running > using stable mesa, an game does change the resolution 'usualy' without > hang even if uses unstable mesa. > > Best regards, > Maxim Levitsky i found that the kernel updates for 2.6.34-rc1 did make the hang time out... this has to be some vblank issue, i assume... -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky wrote: > On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: > > On Fri, 05 Mar 2010 23:18:07 +0200 > > Maxim Levitsky wrote: > > > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > > > On Fri, 05 Mar 2010 22:42:21 +0200 > > > > Maxim Levitsky wrote: > > > > > > > > > After quite long period of inactivity, I updated graphical stack on my > > > > > desktop/server. > > > > > > > > > > To say the truth, I did such update about month ago, but found out > > > > > that > > > > > X refuses flatly to use DRI modules. I assumed that it was my mistake > > > > > in > > > > > compilation process (although it is automated). > > > > > > > > That generally indicates a build or config problem of some kind. Did > > > > you ever narrow it down? > > > Because the same compile process works now, I suspect that wasn't build > > > failure. > > > > Well something weird is going on; maybe you didn't build X after Mesa > > or with the right Mesa includes? > I am very sure that this issue isn't relevant now. > > I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in > that order, compiling everything from scratch (doing git clean -dfx in > all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Wed, 03 Mar 2010 12:31:24 +0100 Francisco Jerez wrote: > Florian Mickler writes: > > > [...] > > p.s.: my software stack is git master of libdrm, mesa > > and xf86-video-intel as well as xserver-master + krh's pull request, so > > that it looks light that: > > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when > > its buffers become invalid. > > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the > > DRI2InvalidateBuffers event. > > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front > > on DRI2GetBuffers if they're just being reused. > > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from > > the intel DDX. > > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled > > compat_output > > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for > > det_monrec_parameter sync_source > > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable > > in DRI2SwapEvent > > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch > > 'whot/for-keith' > > Is it a side effect of this patch series? Could you try without? Ah yes. Of course. Should have checked that before... Anyway, I just did, and with current xserver-master it is hanging nontheless... , Flo -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Tue, 2 Mar 2010 13:59:00 -0800
Jesse Barnes wrote:
> commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
> Author: Eric Anholt
> Date: Wed Feb 24 17:54:13 2010 -0800
>
> In frame event handling, track drawable id instead of drawable
> pointer.
>
> in your xf86-video-intel tree?
>
yes. before that, glxgears wouldn't ever start ... the error goes away if i
restart the xserver...
Am Dienstag, den 02.03.2010, 22:48 +0100 schrieb Florian Mickler:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes wrote:
>
> > So the server is hanging when the client tries to get buffers? Can you
> > see what it's doing at the time?
> >
>
> i'll try tomorrow...
btw, no. it is glxgears which is hanging. everything else works as it
should.
and it is hanging on this _XReply (@428) here:
@line 428 in mesa/src/glx/dri2.c:
416XextCheckExtension(dpy, info, dri2ExtensionName, False);
417
418LockDisplay(dpy);
419GetReqExtra(DRI2GetBuffers, count * (4 * 2), req);
420req->reqType = info->codes->major_opcode;
421req->dri2ReqType = X_DRI2GetBuffersWithFormat;
422req->drawable = drawable;
423req->count = count;
424p = (CARD32 *) & req[1];
425for (i = 0; i < (count * 2); i++)
426 p[i] = attachments[i];
427
428if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) {
429 UnlockDisplay(dpy);
430 SyncHandle();
431 return NULL;
432}
433
434*width = rep.width;
435*height = rep.height;
it's not looping... i verified with strace that glxgears is blocking on
that poll() here...
I tried to follow the program flow up into that.. but besides me
thinking that this _XReply is surfacing in the xserver's dispatch.c
i'm not really advancing here ;) where does this request get handled?
when does _XReply return?
cheers,
Flo
p.s.: if the screen is idle and get's turned off, glxgears is running
fine... (started via ssh... i see the framerate reporting...)
p.p.s.: the whole backtrace when glxgears is hanging:
(gdb) bt full
#0 0x7f3aef5ea10f in poll () from /lib/libc.so.6
No symbol table info available.
#1 0x7f3aee19fa32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1
No symbol table info available.
#2 0x7f3aee1a15e1 in xcb_wait_for_reply ()
from /usr/lib/libxcb.so.1
No symbol table info available.
#3 0x7f3aef2460be in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0x7f3aefb44f76 in DRI2GetBuffersWithFormat (dpy=0x234c010,
drawable=, width=0x235f3b4, height=0x235f3b8,
attachments=0x7fffc5ac6450, count=2, outCount=0x7fffc5ac648c) at
dri2.c:428
info = 0x2357960
rep = {type = 112 'p', pad1 = 100 'd', sequenceNumber = 50604,
length = 32767, width = 3984539715, height = 32570, count =
0,
pad2 = 0, pad3 = 37116448, pad4 = 0}
buffers =
repBuffer = {attachment = 41009200, name = 0, pitch =
3985030468,
cpp = 32570, flags = 2097152}
i =
#5 0x7f3aefb43ca8 in dri2GetBuffersWithFormat (
driDrawable=, width=0x235f3b4,
height=0x, attachments=0x234d6d8, count=5277,
out_count=0x7fffc5ac648c, loaderPrivate=0x235f2c0) at dri2_glx.c:435
---Type to continue, or q to quit---
pdraw =
buffers =
#6 0x7f3aed6de927 in intel_update_renderbuffers (
context=, drawable=0x235f380) at
intel_context.c:252
rb =
region =
depth_region =
intel = 0x2365a20
front_rb =
back_rb = 0x3
depth_rb = 0x26b9340
stencil_rb = 0x26b9340
buffers =
screen = 0x235cf20
i = 3
count =
attachments = {1, 32, 9, 32, 13, 0, 0, 0, 655360, 0}
region_name =
__func__ = "intel_update_renderbuffers"
#7 0x7f3aed6decef in intel_prepare_render (intel=0x2365a20)
at intel_context.c:395
driContext = 0x2361d70
drawable = 0x235f380
---Type to continue, or q to quit---
#8 0x7f3aed70d3ca in brw_try_draw_prims (ctx=0x2365a20,
arrays=0x23b54a8,
prim=0x7fffc5ac65a0, nr_prims=1, ib=0x0,
index_bounds_valid=, min_index=0, max_index=3)
at brw_draw.c:340
retval =
warn =
first_time =
i =
intel = 0x7fffc5ac6200
__FUNCTION__ = "brw_try_draw_prims"
warned = 0 '\000'
#9 brw_draw_prims (ctx=0x2365a20, arrays=0x23b54a8,
prim=0x7fffc5ac65a0,
nr_prims=1, ib=0x0, index_bounds_valid=,
min_index=0,
max_index=3) at brw_draw.c:441
No locals.
#10 0x7f3aed7c91bf in vbo_exec_DrawArrays (mode=6, start=0, count=4)
at vbo/vbo_exec_array.c:524
ctx = 0x2365a20
prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = 0,
pad = 0,
start = 0, count = 4, basevertex = 0}}
__FUNCTION__ = "vbo_exec_DrawArrays"
Re: [Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Tue, 2 Mar 2010 11:50:05 -0800 Jesse Barnes wrote: > So the server is hanging when the client tries to get buffers? Can you > see what it's doing at the time? > i'll try tomorrow... meanwhile, i watched a film and did some other things and now glxgears doesn't start anymore: d...@schatten ~ $glxgears Mesa: Mesa 7.8-devel DEBUG build Mar 2 2010 19:57:41 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa: Initializing x86-64 optimizations Running synchronized to the vertical refresh. The framerate should be approximately 1/8504368 the monitor refresh rate. X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 133 (DRI2) Minor opcode of failed request: 8 (DRI2SwapBuffers ) Resource id in failed request: 0x1c2 Serial number of failed request: 32 Current serial number in output stream: 32 does this 1/[bignumber] look alright? maybe that is the culprit... waiting some 10^6 time ... i think the monitor refresh rate is something about 60 hz? not over some khz? which means that 1khz/8504368 is something about 1/8500 hz which amounts to about 140 secs? (it is late and i may have switched nominater and denominator a bit too often... but if i don't have crossed anything, than that could cause some hang... don't it?) cheers, Flo p.s.: my software stack is git master of libdrm, mesa and xf86-video-intel as well as xserver-master + krh's pull request, so that it looks light that: 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid. 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event. 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused. 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX. 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Tue, 2 Mar 2010 09:32:57 -0800 Jamey Sharp wrote: > On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue wrote: > > i have problems running an Application that depends on Mesa. It seems there > > is an loop after starting this App and before the GUI loads. I use > > A loop? Or just a hang? > > > #1 0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, timeout=-1) at > > ../sysdeps/unix/sysv/linux/poll.c:87 > > #2 0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0, vector=0x0, > > count=0x0) at xcb_conn.c:306 > > #3 0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30, e=0xbf9dbc6c) > > at xcb_in.c:390 > > Judging only by the stack trace, it looks like your application is > waiting for a reply that never comes. There are a variety of bugs that > can cause that. The sequence number (30) looks reasonable for > application startup, which rules out one or two things. > > For the rest, if the Intel/Mesa folks don't have an answer, it would > help if you could get a trace of the X wire protocol using something > like Wireshark. > > Jamey > ___ > xorg-devel mailing list > xorg-de...@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-devel i'm seeing the same with glxgears, see below for a gdb run... if i login glxgears runs fine, until i start up some programs (licq, psi, twinkle, skype)... then it hangs sometimes and doesnt redraw the screen anymore. if i start it after that point it never draws... seems to me, like some event goes missing somewhere... ? anyway, i'm on amd64 with intel from git, using the new event-driven invalidate stuff... what debugging would be helpful here? dmesg doesn't show anything (abnormal) with kernel drm.debug=1 ... cheers, Flo p.s.: i verified with strace that it hangs on that poll... (gdb) r Starting program: /usr/bin/glxgears [Thread debugging using libthread_db enabled] Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. ^C Program received signal SIGINT, Interrupt. 0x7766410f in poll () from /lib/libc.so.6 (gdb) bt #0 0x7766410f in poll () from /lib/libc.so.6 #1 0x76219a32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #2 0x7621b5e1 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #3 0x772c00be in _XReply () from /usr/lib/libX11.so.6 #4 0x77bbe996 in DRI2GetBuffersWithFormat () from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #5 0x77bbd6c8 in dri2GetBuffersWithFormat () from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1 #6 0x75780cef in intel_update_renderbuffers () from /usr/lib64/dri/i965_dri.so #7 0x757810b7 in intel_prepare_render () from /usr/lib64/dri/i965_dri.so #8 0x757af15a in brw_draw_prims () from /usr/lib64/dri/i965_dri.so #9 0x75857383 in vbo_exec_DrawArrays () from /usr/lib64/dri/i965_dri.so #10 0x758d2987 in _mesa_meta_Clear () from /usr/lib64/dri/i965_dri.so #11 0x7577fccb in intelClear () from /usr/lib64/dri/i965_dri.so #12 0x00402be6 in draw () #13 0x0040360b in main () (gdb) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
