Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps

[Dieter <Die...@ha...>]

Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger:
> Dieter N=FCtzel wrote:
> > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
> >> On Mon, 2004-02-09 at 20:55, Michel D=E4nzer wrote:
> >>> [ Following up to the dri-devel mailing list, we aren't really
> >>> using the sf.net bug tracker anymore but rather the kernel and
> >>> XFree86 bugzillas ]
> >>>
> >>> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote:
> >>>> I just ported the latest CVS drm-kernel code into the 2.6.2
> >>>> vanilla kernel.
> >>>
> >>> Do you have a patch for us to look at?
> >>
> >> Yes, I think I posted it to the SourceForge bug tracker. It's down
> >> right now, or I'd be including a bug ID #.
> >>
> >>> Does the same problem occur if you just build the DRM from DRI
> >>> CVS?
> >>
> >> It won't compile. Aside from a small number of API changes, the
> >> Makefile.linux is *severely* broken about include directories under
> >> 2.6.
> >
> > I use only 2.6.x. There is No problem with DRI CVS (DRM).
> >
> > But some apps hang the graphics card (hard).
> >
> > UT2003 Citadel after some (<=3D 3) seconds. But _very_ smooth with S3TC
> > and Roland's hardware TCL patch.

Some additional notes.

It was your code (patch) with Mesa, GLX from last week.
Not with latest Mesa and GLX code (Brian, Ian).

It locks in Citadel during _first_ mouse move (immediately).

I could move around not play "Bombing Run" (Egypt) for about 15 minutes.
My girlfriend and I watched the GREAT textures mirrors and halls...;-)

Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the=20
"behavior" is the same, but some textures (the mirrors, multi textures?) ar=
e=20
broken in "Bombing Run" (Egypt).

> That's not good. There is nothing (both in the S3TC patch as well as in
> the changed lighting code) which could make lockups disappear. Using
> compressed textures shouldn't change anything (except the textures are
> smaller so less texture swapping is needed which might mean there are
> more free dma buffers available). The lighting changes did avoid some
> TCL fallback with materials between begin/end (and it looks like the
> fallback doesn't always work correctly, though I don't think it causes
> lockups), but in the latest patch (submitted to cvs yesterday) it's back
> in (as removing it wasn't correct and sometimes caused obvious rendering
> errors, it still awaits a proper fix). The patch still avoids a tcl
> fallback when using two-sided materials, but that really shouldn't have
> caused lockups...

Maybe the broken textures?

> Meaning if the lockups have disappeared in UT2003, they are likely to
> reappear somewhere else.
> That said, I just tried to reproduce the lockups, but I can't even get
> ut2003 (demo 2206) to start here, it crashes even before the nvidia logo
> appears (seems to segfault and then be stuck waiting for a signal,
> killall -9 will just get rid of it fine).

Now, it sigfault immediately like yours...

/opt/Mesa> ut2003_demo
fcntl: Invalid argument
fcntl: Invalid argument
Mesa: software DXTn compression/decompression available

Backtrace:
[ 1]  ./Core.so [0x40a0b78a]
[ 2]  /lib/i686/libpthread.so.0 [0x40dfd96c]
[ 3]  /lib/i686/libc.so.6 [0x40bc5aa8]
Signal: SIGSEGV [segmentation fault]
Aborting.
Speicherschutzverletzung

> I can only hope it's not=20
> caused by the lighting changes I've commited yesterday (though I've no
> idea how these changes could cause that) - maybe some of the
> experimental code I've got here causes it.

It must be something like that.

=2DDieter