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 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 been > > running applications with RADEON_DEBUG=sync, which causes idle calls > > between cmdbuf calls, and I've been seeing lockups where the read pointer > > sits after the beginning of what cmdbuf emits and long before the first > > rendering commands. > > 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. > > > 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 ? > > > - 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); > > 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 client sends a command buffer where all the state blocks (from r300->hw) are sent to the hardware *anyway*. It's actually the *order* of emission (e.g. the order in which insert_at_tail is called for state bits) that can make a difference. The thing is, while the order definitely *does* affect the probability of lockups, lockups will not go away completely even if I use the exact same order that fglrx uses. So I'm beginning to believe that we can't trust radeon_do_cp_idle to completely idle the chip, or that whatever is wrong is pretty fundamentally wrong (some wrong bits in how the memory is configured?). cu, Nicolai
pgprQzzlJLfsA.pgp
Description: PGP signature
