Michael wrote: > I've just noticed some combinations of 2 apps running at once causes > hangs (well, I had glxgears minimised and had forgotten and ran q3) > > A wild stab in the dark. > > When we currently send a cmd buffer something like this :- > > app 1 packet 1 app2 packet 1 > 5 (LOAD_VBPNTR) 5 (LOAD_VBPNTR) > ... .... > state > State > -----FLUSH HERE cmd packet full 6 > cmd packet 2 elts > 6 (CLIP_PACKET3) ---- FLUSH HERE > elts > state > 5 packet > 6 > ---- FLUSH here > > If we flush packet 1, what happens if another app > sends a cmd packet to the card with a few 5 + state + 6 packet sequences? > > Don't we then send our elts with whatever the last LOAD_VBPTR command > was (i.e possibly a different applications) instead of our own when > we flush packet 2?
Yes, this makes sense -- we restore other state, but treat the VBPTR packet as an event & don't try to reset it when the buffer is flushed. > Perhaps I'm missing something or completely off the wall, but adding a > FlushCmdBuf to force each command buf to start with a 5 packet seems to > eliminate the hang (but I'm wary that the frequent flushing may have > fixed the real problem) It's a bit confusing to call it a 5 packet, as that can mean just about anything... I think the right thing to do is somehow integrate the VBPTR info into the existing state mechnism, so that it gets emitted at the head of each buffer. Another possibility is to define OLD_PACKETS, where the VBPTR and vertex/index packet are bundled together. Keith _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
