Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Thu, 2010-03-11 at 19:05 +0200, Maxim Levitsky wrote: On Wed, 2010-03-10 at 13:04 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 12:39:15 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com 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 mailingli...@openelec.tv 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... Note that I updated the stack today, but nothing changed. Best regards, Maxim Levitsky Also note that mesa master + xserver-1.7-branch work fine too. Now xserver-1.7-branch=5a2b3f36a05d1e0fcfd1b0f85d6584478ba24eda Best regards, Maxim Levitsky -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Wed, 2010-03-10 at 13:04 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 12:39:15 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com 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 mailingli...@openelec.tv 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... Note that I updated the stack today, but nothing changed. Best regards, Maxim Levitsky -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 12:39:15 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com 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 mailingli...@openelec.tv 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#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sun, Mar 07, 2010 at 05:18:04PM +0100, Florian Mickler wrote:
[...]
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?)
[...]
Some combination of:
xset -dpms
xset s off
xset s noblank
The first one is probably sufficient to keep X from powering down
the display, however.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
Download Intel#174; 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
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com 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 mailingli...@openelec.tv 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#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv 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=value optimized out, 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=value optimized out, 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#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com 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 mailingli...@openelec.tv 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 -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
Hi Jesse, Am 07.03.2010 00:11, schrieb Jesse Barnes: 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. dont know if this help: strace output from Xorg (1.1MB): http://sources.openelec.tv/tmp/logfile/xbmc/Xorg.strace strace output from my Application (1.4MB): http://sources.openelec.tv/tmp/logfile/xbmc/xbmc.strace i have only strace and gdb installed for debugging, let me know if i need other programs for debugging. Stephan Jesse On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Rauemailingli...@openelec.tv 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: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. 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,
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 6 Mar 2010 15:11:59 -0800 Jesse Barnes jbar...@virtuousgeek.org 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#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. Done: https://bugs.freedesktop.org/show_bug.cgi?id=26939 I also opened a bug for other very annoying problem that was present for long time. https://bugs.freedesktop.org/show_bug.cgi?id=26938 Best regards, Maxim Levitsky -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. Best regards, Maxim Levitsky -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) Best regards, Maxim Levitsky -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. 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=value optimized out, 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=value optimized out, 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
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
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: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. 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=value optimized out, 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=value optimized out, 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
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv 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 GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Attaching to process 4123 Reading symbols from /usr/bin/compiz.real.disabled...(no debugging symbols found)...done. Reading symbols from /usr/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcomposite.so.1 Reading symbols from /usr/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXdamage.so.1 Reading symbols from /usr/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libXrandr.so.2...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxslt.so.1 Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/libstartup-notification-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstartup-notification-1.so.0 Reading symbols from /usr/local/lib/mesa/lib/libGL.so.1...done. Loaded symbols for /usr/local/lib/mesa/lib/libGL.so.1 Reading symbols from /lib/tls/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libm-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.10.1.so...done. [Thread debugging using libthread_db enabled] (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 Reading symbols from /lib/tls/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libc-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /usr/local/lib/libX11.so.6...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libdl-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libxcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/lib/libxcb-aux.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-aux.so.0 Reading symbols from /usr/lib/libxcb-event.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-event.so.1 Reading symbols from /usr/lib/libxcb-atom.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-atom.so.1 Reading symbols from /usr/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
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 mailingli...@openelec.tv 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 -- Download Intel#174; 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
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 On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv 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: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com 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 Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. 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=value optimized out, 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=value optimized out,
