[Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
Stephan Raue
mailinglists at openelec.tv
Sun Mar 7 16:19:06 CET 2010
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 Raue<mailinglists at 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 Levitsky<maximlevitsky at 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<maximlevitsky at 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<maximlevitsky at 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<maximlevitsky at 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
>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>>
>>>
>>
>>
>
>
--
### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
http://www.openelec.tv
More information about the Intel-gfx
mailing list