From: Aapo T. <ae...@ra...> - 2005-06-03 08:29:01
|
> 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 applie= d >> to >> > clearbuffer. >> > >> > Im starting to think that this sequence is needed whenever overwriti= ng >> > certain states rather than whenever 3d operation begins and ends. > > Perhaps. I don't think it's just the pacifier sequence, though. I've be= en > running applications with RADEON_DEBUG=3Dsync, which causes idle calls > between cmdbuf calls, and I've been seeing lockups where the read point= er > 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. --=20 Aapo Tahkola |