On Thu, May 23, 2002 at 08:10:09AM +0100, Keith Whitwell wrote:
> Michael wrote:
> >I've been trying to track down one of the hangs on the radeon at the mo.
> >
> >Tuxkart draws, amongst other things, a course map with 2 GL_LINE_LOOPS
> >and a quad for each racer.
> >
> >If I either (a) remove the function to draw that from tuxkart
> >
> >or (b) force tcl_render_line_loop_verts to use the
> >tcl_render_line_strip_verts path at the bottom of that function (which
> >uses EMIT_PRIM() rather than ALLOC_ELTS et al), it doesn't hang. i.e I
> >put "if (0 && (flags & PRIM_END)) {" at line 215 in t_dd_dmatmp2.h
> >
> >The only thing that looks odd is that the call to radeonEmitAOS it uses
> >in this path is the one that's part of ALLOC_ELTS that always uses 0 as
> >an offset, so you see the 4: value below is the same for all 3
> >primitives - I wondered if that was it?
> >
> >Here's a short extract running it in debug.
> >
> >basically it's flush_prims radeon_vtxfmt.c
> > -> tcl_render_line_loop_verts
> > -> emit_contiguous_verts (x2)
> > ALLOC_ELTS (which does radeonEmitAOS, and
> > AllocEltsOpenEnded)
> > etc
> >
> >The hang does always trigger, sometimes it's a couple of seconds into
> >the level, sometimes you can get 1/2-way around the track but I've
> >played for significantly longer without a prob, with the kludge above.
>
> Wow, good work... How did you track this down? It looks like it would
> have taken ages...
Actually I think I'm getting closer but the kludge above seems to
avoid the problem rather than it having anything specificially to do
with LINE_LOOPS per se. If you look at the verbose output you get
0: 5 (cmd packet type five)
blah..
5: 1201 (various state packets, at minimum the ZBS state for the hang
I assume was caused by a 6 packet immed following a 5 packet?)
xx: 6 (cmd packet3, clip)
...and so on..
My kludge above changes this pattern, because it emits some of the
primitives differently and I think that's all it did.
What I have seen (and I went to bed, just got up so I need to carry on
from where I left off but with a bit of luck this might be tuxracer's
problem too...)
This is the packet I saw just before the hang.
0: lots of 5 packet, state, 6 packet sequences...
... etc etc
8000: 6 packet
....
8132 0d000d - last elt of 6 packet
flushes etc
0: 1301 (state??? Which confuses me, because I was expecting to
see a 5 here)
pageflip - hangs
Almost as though the 5 packet was lost at the end of a buffer - or
perhaps just a red herring, but I'm sure this is getting closer and
explains why it hangs at a seemingly random place rather than the emit
bogus state fix, which hangs q3 at exactly the same frame - the first
one where there are no state changes to emit this one - if I'm not up
another blind alley it needs a specific sequence at the point where a
buffer is full to trigger)
As you surmise, it takes hours, more so now, because I'm pouring through
DEBUG_VERBOSE output. (I've noticed a couple of places where the packet
type isn't 6 because there's no cmd[0].i = 0, I don't think they cause
problems because the drm module would ignore the bogus values, that had
me confused for a bit)
--
Michael.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
