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=0xfffffdfc, 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
------------------------------------------------------------------------------
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
