From: Benjamin H. <be...@ke...> - 2006-03-30 04:09:37
|
Haven't had time to investigate much yet (and probably won't for a couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X against that Mesa version (the whole lot), the server blows up right away when launching glxinfo or glxgears. The latest log I got (with glxgears) shows this backtrace: Backtrace: 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] 1: [0x100374] 2: [0x10c5b548] 3: [0x10c5b548] 4: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x54) [0xf61c004] 5: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x60) [0xf61ac54] 6: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616f04] 7: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x5d8) [0xf98e06c] 8: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXMakeCurrent+0x24) [0xf98e164] 9: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993d94] 10: /usr/local/xorg/bin/X(Dispatch+0x21c) [0x10043c40] 11: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] 12: /lib/libc.so.6 [0xfc558ec] 13: /lib/libc.so.6 [0xfc55a34] |
From: Brian P. <bri...@tu...> - 2006-03-30 05:13:50
|
Benjamin Herrenschmidt wrote: > Haven't had time to investigate much yet (and probably won't for a > couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X > against that Mesa version (the whole lot), the server blows up right > away when launching glxinfo or glxgears. > > The latest log I got (with glxgears) shows this backtrace: > > Backtrace: > 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] > 1: [0x100374] > 2: [0x10c5b548] > 3: [0x10c5b548] > 4: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x54) [0xf61c004] > 5: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x60) [0xf61ac54] > 6: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616f04] > 7: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x5d8) [0xf98e06c] > 8: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXMakeCurrent+0x24) [0xf98e164] > 9: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993d94] > 10: /usr/local/xorg/bin/X(Dispatch+0x21c) [0x10043c40] > 11: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] > 12: /lib/libc.so.6 [0xfc558ec] > 13: /lib/libc.so.6 [0xfc55a34] Update your Mesa CVS and try again. I checked in some changes a few hours ago. -Brian |
From: Benjamin H. <be...@ke...> - 2006-03-30 05:26:48
|
> Update your Mesa CVS and try again. I checked in some changes a few > hours ago. Ok, in fact, I have 2 Mesa trees, one used to build the server and one used to build libGL, DRI, etc... :) (the later because I use it for experimenting with the DRI). The one used to build the server is up to date vs. anoncvs as of now, though I suppose it could also be anoncvs being slow as hell to replicate... I haven't tried the real CVS as I didn't have my ssh keys at hand back then. The one used to build libGL and the DRI was a bit less up to date and had some stale junk I missed, so I think the problem is my fault. (I've been hacking on a native ppc dispatch but it's still incomplete). I'm not sure 100% the client library caused the server to crash tho, it might have to do with AIGLX maybe going through the client dispatch from the server. So forget about it for now, I'll re-test with clean builds. Cheers, Ben. |
From: Benjamin H. <be...@ke...> - 2006-03-30 05:51:57
|
On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote: > The one used to build libGL and the DRI was a bit less up to date and > had some stale junk I missed, so I think the problem is my fault. (I've > been hacking on a native ppc dispatch but it's still incomplete). Rebuilt with up to date on both sides and gets that (though it's still anoncvs and thus might not have caught up with your latest fixes): 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] 1: [0x100374] 2: [0x10bb3e50] 3: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616ec4] 4: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXUnrefDrawable+0x68) [0xf99510 c] 5: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993450] 6: /usr/local/xorg/bin/X(FreeClientResources+0xe4) [0x10027f28] 7: /usr/local/xorg/bin/X(CloseDownClient+0x210) [0x10042ce4] 8: /usr/local/xorg/bin/X(Dispatch+0x39c) [0x10043dc0] 9: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] 10: /lib/libc.so.6 [0xfc558ec] 11: /lib/libc.so.6 [0xfc55a34] |
From: Daniel S. <da...@fr...> - 2006-03-30 07:36:27
|
On Thu, Mar 30, 2006 at 04:50:52PM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote: > > The one used to build libGL and the DRI was a bit less up to date and > > had some stale junk I missed, so I think the problem is my fault. (I've > > been hacking on a native ppc dispatch but it's still incomplete). >=20 > Rebuilt with up to date on both sides and gets that (though it's still > anoncvs and thus might not have caught up with your latest fixes): anoncvs is only *two* *minutes* behind, in the worst case. |
From: Benjamin H. <be...@ke...> - 2006-03-30 07:59:18
|
On Thu, 2006-03-30 at 10:36 +0300, Daniel Stone wrote: > On Thu, Mar 30, 2006 at 04:50:52PM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote: > > > The one used to build libGL and the DRI was a bit less up to date and > > > had some stale junk I missed, so I think the problem is my fault. (I've > > > been hacking on a native ppc dispatch but it's still incomplete). > > > > Rebuilt with up to date on both sides and gets that (though it's still > > anoncvs and thus might not have caught up with your latest fixes): > > anoncvs is only *two* *minutes* behind, in the worst case. Yah, I checked out the non-anon CVS and it had no diffs Ben. |
From: Pedro M. <ped...@ne...> - 2006-03-30 12:54:24
|
I was having some trouble, with the viewport update. But latest cvs changes have fixed. The diference here is that i'm using Xorg 6.9, so no AIGLX. The problem is probably there, i guess. Pedro Maia |
From: <kr...@bi...> - 2006-03-30 20:13:27
|
Benjamin Herrenschmidt wrote: > Haven't had time to investigate much yet (and probably won't for a > couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X > against that Mesa version (the whole lot), the server blows up right > away when launching glxinfo or glxgears. > > The latest log I got (with glxgears) shows this backtrace: It isn't clear from the stack trace what went wrong, but I've just checked in a patch which fixes a few issues: GLcore needs to build with TLS settings matching glx, the ARGB visual is now marked as non-conformant, and there was a problem with freeing a mesa buffer even if it never got allocated. Kristian > Backtrace: > 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] > 1: [0x100374] > 2: [0x10c5b548] > 3: [0x10c5b548] > 4: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x54) [0xf61c004] > 5: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x60) [0xf61ac54] > 6: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616f04] > 7: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x5d8) [0xf98e06c] > 8: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXMakeCurrent+0x24) [0xf98e164] > 9: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993d94] > 10: /usr/local/xorg/bin/X(Dispatch+0x21c) [0x10043c40] > 11: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] > 12: /lib/libc.so.6 [0xfc558ec] > 13: /lib/libc.so.6 [0xfc55a34] |
From: Ian R. <id...@us...> - 2006-03-30 21:52:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristian H=C3=B8gsberg wrote: > Benjamin Herrenschmidt wrote: >=20 >> Haven't had time to investigate much yet (and probably won't for a >> couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X >> against that Mesa version (the whole lot), the server blows up right >> away when launching glxinfo or glxgears. >> >> The latest log I got (with glxgears) shows this backtrace: >=20 > It isn't clear from the stack trace what went wrong, but I've just > checked in a patch which fixes a few issues: GLcore needs to build with > TLS settings matching glx, the ARGB visual is now marked as > non-conformant, and there was a problem with freeing a mesa buffer even > if it never got allocated. What is non-conformant about those visuals? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFELFLWX1gOwKyEAw8RAmUtAJwPKDdiwBwNaeHRQ1ZuiKDr0eHB5wCfbaKW w1O6+XV3qlKEjQ2wOVa+n18=3D =3DlJeo -----END PGP SIGNATURE----- |
From: <kr...@bi...> - 2006-03-30 22:15:21
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Kristian H=C3=B8gsberg wrote: >> Benjamin Herrenschmidt wrote: >> >>> Haven't had time to investigate much yet (and probably won't for a >>> couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and = X >>> against that Mesa version (the whole lot), the server blows up right >>> away when launching glxinfo or glxgears. >>> >>> The latest log I got (with glxgears) shows this backtrace: >> It isn't clear from the stack trace what went wrong, but I've just >> checked in a patch which fixes a few issues: GLcore needs to build wit= h >> TLS settings matching glx, the ARGB visual is now marked as >> non-conformant, and there was a problem with freeing a mesa buffer eve= n >> if it never got allocated. >=20 > What is non-conformant about those visuals? Maybe it's not non-conformance, but a driver bug instead. The radeon=20 driver panics and calls exit() if it sees a visual with no depth buffer=20 (see the switch on line 175 in radeon_state_init.c). Kristian |
From: Brian P. <bri...@tu...> - 2006-03-30 22:43:12
|
Kristian H=C3=B8gsberg wrote: > Ian Romanick wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Kristian H=C3=B8gsberg wrote: >> >>> Benjamin Herrenschmidt wrote: >>> >>>> Haven't had time to investigate much yet (and probably won't for a >>>> couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and= X >>>> against that Mesa version (the whole lot), the server blows up right >>>> away when launching glxinfo or glxgears. >>>> >>>> The latest log I got (with glxgears) shows this backtrace: >>> >>> It isn't clear from the stack trace what went wrong, but I've just >>> checked in a patch which fixes a few issues: GLcore needs to build wi= th >>> TLS settings matching glx, the ARGB visual is now marked as >>> non-conformant, and there was a problem with freeing a mesa buffer ev= en >>> if it never got allocated. >> >> >> What is non-conformant about those visuals? >=20 >=20 > Maybe it's not non-conformance, but a driver bug instead. The radeon=20 > driver panics and calls exit() if it sees a visual with no depth buffer= =20 > (see the switch on line 175 in radeon_state_init.c). Yikes! That should be fixed. The default case should probably be: rmesa->state.depth.clear =3D 0; rmesa->state.depth.scale =3D 0.0; /* or 1.0? */ rmesa->staet.stencil.clear =3D 0; Can someone try that? -Brian |
From: Benjamin H. <be...@ke...> - 2006-03-31 08:18:12
|
Ok, I rebuild it all from fresh CVS checkouts today and made sure the trees had no stale .o file or anything. Result is, it doesn't crash, but doesn't work very well neither. Machine is a ppc32 laptop, Mesa/DRI built with TLS enabled and X built with the new enable-glx-tls option from Kristian. So far, what I've been able to collect is: - DRI r300 doesn't work. I get that when running any GL app: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering - AIGLX doesn't work, probably for the same reason as above. Message in log is: (EE) AIGLX error: Calling driver entry point failed(EE) GLX-DRI: reverting to software rendering - When using glxgears and EXA, the gears (software rendering by GLcore on server side) are garbage all over the framebuffer. Looks like the pitch is wrong, not sure exactly what's up there at this point. Seems to work ok with XAA. (I haven't tried indirect GL for ages since until recently, DRI worked fine, so this might be an old breakage). At this point, I didn't have any time to try to track down these issues, thus this email, in case I wake up with everything fixed in CVS tomorrow morning :) Cheers, Ben. |