From: Michel <mi...@da...> - 2004-01-23 01:28:19
|
I'm normally using the libGL from my 2003.10.05 snapshot packages, and the current r200 driver segfaults with that (works with current libGL): 0x0eb1a908 in driBindContext2 (dpy=0x100160f8, scrn=0, draw=102760450, read=102760450, gc=0x1001a6c0) at dri_util.c:447 447 pcp->driDrawablePriv = pdp; (gdb) p pcp $1 = (__DRIcontextPrivate *) 0x0 Worked before today's CVS update (last one was about a week ago). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Michel <mi...@da...> - 2004-01-23 02:45:15
|
On Fri, 2004-01-23 at 02:28, Michel Dänzer wrote: > > [...] (works with current libGL): Actually, most if not all textured apps spew [driAllocateTexture:577] unable to allocate texture all over the place and seem to fall back to software rendering. In contrast to the other problem, this doesn't occur on R100. Reverting Ian's commit from Wednesday doesn't help. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Michel <mi...@da...> - 2004-01-27 13:36:09
|
On Fri, 2004-01-23 at 03:45, Michel Dänzer wrote: > On Fri, 2004-01-23 at 02:28, Michel Dänzer wrote: > > > > [...] (works with current libGL): > > Actually, most if not all textured apps spew > > [driAllocateTexture:577] unable to allocate texture > > all over the place and seem to fall back to software rendering. In > contrast to the other problem, this doesn't occur on R100. Reverting > Ian's commit from Wednesday doesn't help. But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3 does. Keith, any idea what's up there? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Ian R. <id...@us...> - 2004-01-25 08:39:16
|
Michel D=C3=A4nzer wrote: > I'm normally using the libGL from my 2003.10.05 snapshot packages, and > the current r200 driver segfaults with that (works with current libGL): >=20 > 0x0eb1a908 in driBindContext2 (dpy=3D0x100160f8, scrn=3D0, draw=3D10276= 0450, > read=3D102760450, gc=3D0x1001a6c0) at dri_util.c:447 > 447 pcp->driDrawablePriv =3D pdp; > (gdb) p pcp > $1 =3D (__DRIcontextPrivate *) 0x0 >=20 > Worked before today's CVS update (last one was about a week ago). I can assure that when I discovered the nature of this bug, there was a=20 lot of yelling, cursing, and general unhappiness. The bug fixes for=20 XFree86 bugs 1091 & 1092 made it necessary to add fields to=20 __GLXvertArrayStateRec. That structure is embedded in=20 __GLXattributeRec, which is embedded in __GLXcontextRec. This structure=20 is shared between libGL and the DRI driver. Adding fields in the middle=20 changes the positions of all the fields after, which causes problems. I think I can hack up a work around. I think I'll revert to the old=20 structure for __GLXvertArrayStateRec (obvious). The old structure=20 (stored in __GLXcontextRec::state will be unused. I'll add a private=20 pointer to the end of __GLXcontextRec to the new __GLXattribute=20 structure. I'll replace the entire __GLXattribute structre to make=20 PushCLientAttrib "sane". Since the new pointer will be private, libGL=20 can point it to whatever it wants and the client-side driver won't care.=20 Sound good? I guess it's a good thing none of my "fixes" went into the XFree86 tree=20 yet. :) I hope that I win the lottery so that I can quit my job and have time to=20 completely re-write all of libGL in the XFree86 5.0 time-frame. :( |
From: Keith W. <ke...@tu...> - 2004-01-25 14:14:11
|
Michel Dänzer wrote: > On Fri, 2004-01-23 at 03:45, Michel Dänzer wrote: > >>On Fri, 2004-01-23 at 02:28, Michel Dänzer wrote: >> >>>[...] (works with current libGL): >> >>Actually, most if not all textured apps spew >> >>[driAllocateTexture:577] unable to allocate texture >> >>all over the place and seem to fall back to software rendering. In >>contrast to the other problem, this doesn't occur on R100. Reverting >>Ian's commit from Wednesday doesn't help. > > > But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3 > does. Keith, any idea what's up there? I've lost the beginning of this thread - how should I reproduce the problem? Keith |
From: Michel <mi...@da...> - 2004-01-25 05:16:02
|
On Sat, 2004-01-24 at 15:28, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fri, 2004-01-23 at 03:45, Michel Dänzer wrote: > > > >>On Fri, 2004-01-23 at 02:28, Michel Dänzer wrote: > >> > >>[...] most if not all textured apps spew > >> > >>[driAllocateTexture:577] unable to allocate texture > >> > >>all over the place and seem to fall back to software rendering. In > >>contrast to the other problem, this doesn't occur on R100. Reverting > >>Ian's commit from Wednesday doesn't help. > > > > But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3 > > does. Keith, any idea what's up there? > > I've lost the beginning of this thread - That's fine, this problem isn't related to that. :) > how should I reproduce the problem? Start any textured app (e.g. the xscreensaver lament hack) with current libGL from DRI CVS and current r200 driver from Mesa CVS. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2004-01-26 19:36:35
|
>>how should I reproduce the problem? > > > Start any textured app (e.g. the xscreensaver lament hack) with current > libGL from DRI CVS and current r200 driver from Mesa CVS. Sorry if I'm being slow about this -- we've had bad mail problems here for the last few days, so I've been losing mail all over the place & long delays as well. I've just been running lament with what I beleive to be a clean build & I'm not seeing any problems at all - has the problem been fixed in the meantime, or do I need to do something more? Keith |
From: Michel <mi...@da...> - 2004-01-26 16:30:22
|
On Mon, 2004-01-26 at 10:28, Keith Whitwell wrote: > >>how should I reproduce the problem? > > > > Start any textured app (e.g. the xscreensaver lament hack) with current > > libGL from DRI CVS and current r200 driver from Mesa CVS. > > Sorry if I'm being slow about this -- we've had bad mail problems here for the > last few days, so I've been losing mail all over the place & long delays as well. No worries, it seems sf.net had at least as severe problems... > I've just been running lament with what I beleive to be a clean build & I'm > not seeing any problems at all - has the problem been fixed in the meantime, > or do I need to do something more? It's still broken here. Does revision 1.4 of Mesa/src/mesa/drivers/dri/common/texmem.c correspond to a DRM change? (I'm running the DRM from the 2.6 kernel) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2004-01-27 03:56:49
|
Michel Dänzer wrote: > On Mon, 2004-01-26 at 10:28, Keith Whitwell wrote: > >>>>how should I reproduce the problem? >>> >>>Start any textured app (e.g. the xscreensaver lament hack) with current >>>libGL from DRI CVS and current r200 driver from Mesa CVS. >> >>Sorry if I'm being slow about this -- we've had bad mail problems here for the >>last few days, so I've been losing mail all over the place & long delays as well. > > > No worries, it seems sf.net had at least as severe problems... > > >>I've just been running lament with what I beleive to be a clean build & I'm >>not seeing any problems at all - has the problem been fixed in the meantime, >>or do I need to do something more? > > > It's still broken here. Does revision 1.4 of > Mesa/src/mesa/drivers/dri/common/texmem.c correspond to a DRM change? > (I'm running the DRM from the 2.6 kernel) No - at least it shouldn't. It is intended to make the userspace drivers respect a kernel module which can set the 'in_use' field in the global LRU to mark 'reserved' regions, such as those handed to individual clients by an in-kernel allocator. But in the absense of any such allocator, the LRU should continue to work the same way - in fact it does even on drivers with such an allocator, up until the point where an allocation is actually made. Keith |
From: Michel <mi...@da...> - 2004-01-26 23:46:07
|
I realised that this X server has been running for a while, so I re-initialised the DRI, and now it's gone. Odd. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Felix <fx...@gm...> - 2004-01-26 15:18:05
|
I got the same after a cvs upgrade of the trunk last night with LIBGL_DRIVERS_PATH still set to my savage-2-0-0-branch installation. On Fri, 23 Jan 2004 02:28:12 +0100 Michel D=E4nzer <mi...@da...> wrote: >=20 > I'm normally using the libGL from my 2003.10.05 snapshot packages, and > the current r200 driver segfaults with that (works with current libGL): >=20 > 0x0eb1a908 in driBindContext2 (dpy=3D0x100160f8, scrn=3D0, draw=3D1027604= 50, > read=3D102760450, gc=3D0x1001a6c0) at dri_util.c:447 > 447 pcp->driDrawablePriv =3D pdp; > (gdb) p pcp > $1 =3D (__DRIcontextPrivate *) 0x0 >=20 > Worked before today's CVS update (last one was about a week ago). >=20 >=20 > --=20 > Earthling Michel D=E4nzer | Debian (powerpc), X and DRI developer > Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |