On Fri, 3 Jun 2005 14:57:37 +0200 Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> 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?). Remember that because of reemiting, those states arent in perfect order. Fortunately taking out lines 206-212 of r300_context.c doesnt seem to have any side effects on rv350. -- Aapo Tahkola ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
