Re: [r300] [patches] debugging lockups

[Nicolai H. <pre...@gm...>]

On Friday 03 June 2005 10:28, Aapo Tahkola wrote:
> > On Thursday 02 June 2005 13:08, Boris Peterbarg wrote:
> >> Aapo Tahkola wrote:
> >> > I did some figuring on the CB_DPATH problem.
> >> > After little testing it turns out that the lock up with
> >> > progs/demos/isosurf goes away when the pacifier sequences are applied
> >> to
> >> > clearbuffer.
> >> >
> >> > Im starting to think that this sequence is needed whenever=20
overwriting
> >> > certain states rather than whenever 3d operation begins and ends.
> >
> > Perhaps. I don't think it's just the pacifier sequence, though. I've=20
been
> > running applications with RADEON_DEBUG=3Dsync, which causes idle calls
> > between cmdbuf calls, and I've been seeing lockups where the read=20
pointer
> > sits after the beginning of what cmdbuf emits and long before the first
> > rendering commands.
>=20
> I dont know if packet3 was issued before since I tweaked isosurf to dump
> each frame portion of RADEON_DEBUG info into files using freopen.
> But "DISCARD BUF" was really the only key difference in these logs.
>=20
> > This indicates that at least one lockup is cause by
> > one
> > of the following:
> > - intial pacifier sequence in r300_cp_cmdbuf
> > - emission of cliprects or
> Cliprects seem to be little off scale when compairing progs/samples/logo
> against software rendering.
> Perhaps near plane is negative ?
>=20
> > - initial unchecked_state commands sent by the client
> This is bad as you can see from first frame drawn by texwrap...
> Sticking:
> 	r300_setup_textures(ctx);
> 	r300_setup_rs_unit(ctx);
>=20
> 	r300SetupVertexShader(rmesa);
> 	r300SetupPixelShader(rmesa);
> or resethwstate to r300_run_vb_render should fix it.

I'm not sure we're talking about the same thing here. This happens when the=
=20
client sends a command buffer where all the state blocks (from r300->hw)=20
are sent to the hardware *anyway*. It's actually the *order* of emission=20
(e.g. the order in which insert_at_tail is called for state bits) that can=
=20
make a difference. The thing is, while the order definitely *does* affect=20
the probability of lockups, lockups will not go away completely even if I=20
use the exact same order that fglrx uses. So I'm beginning to believe that=
=20
we can't trust radeon_do_cp_idle to completely idle the chip, or that=20
whatever is wrong is pretty fundamentally wrong (some wrong bits in how the=
=20
memory is configured?).

cu,
Nicolai