Tim Smith wrote:
> On Tuesday 28 May 2002 1:13 pm, Keith Whitwell scribed numinously:"
>
>>Tim Smith wrote:
>>
>>>On Tuesday 28 May 2002 8:40 am, Keith Whitwell scribed numinously:"
>>>
>>>
>>>>Tim Smith wrote:
>>>>
>>>>>I've done some more digging and it would appear to send an enormous
>>>>>amount of commands via radeon_cp_cmdbuf, all ending up going via
>>>>>radeon_emit_packet3_cliprect. Actually I don't think it's such a huge
>>>>>number compared to other calls (32 commands), except that this time
>>>>>the loop gets called with nbox=4 so it emits everything 4 times, and
>>>>>runs out of FIFO.
>>>>>
>>>>If it's really a fifo issue, I may have a solution for this in terms of
>>>>only writing the ring tail register once per ioctl.
>>>>
>>>Is it in a testable state? If you mail me a patch I'll test it tonight
>>>and report.
>>>
>>>Assuming that RADEON_CP_RB_WPTR is the ring tail register, I count at
>>>least 20 writes to it on this one call, and 16 on the previous "clear"
>>>(also with nbox=4). And there are 13 consecutive calls to
>>>radeon_emit_packet3_cliprect with nbox=4 before it locks, making a
>>>total of 260 writes from one call to radeon_cp_cmdbuf.
>>>
>>It's committed on the tcl branch now (it's also a minor optimization).
>>
>
> No so minor actually; the difference between the two may be small, but there
> is a noticeable improvement in interactivity when wandering around the 3D
> map, at least in my application.
Thats good to know - I didn't get a very large improvement here.
> It doesn't fix this lockup though, so I guess it's not a FIFO issue.
>
> The big storm of stuff during which the lockup occurs appears to be
> generated by radeonEmitState ('lost context'), so maybe there's something
> unpleasant in that lot. It's been called a lot of times before, without
> causing trouble though. The only thing I can think of is that this time
> there's still a menu window slap bang in the middle of the 3D area (simply
> popping up a menu and then taking it away again will not produce the
> lockup; I have to pop up a submenu and then let the submenu go away while
> its parent is still there to make it lock).
>
> Can anyone give me an idea of sequences which it's known will lock the card,
> so I can attempt to determine if any of them is occurring? I'm a
> "bottom-up" kind of guy when it comes to bug hunting, especially when I'm
> trying to understand the code as I go.
The trouble with that approach is there are probably an infinite number of bad
sequences... The classic one is providing a "bad" number of vertices or
indices for a render packet, but there are thousands of ways to lock these
cards, it seems.
What I'm doing at the moment is building a sanity checker for the stream that
looks at the command headers and verifies that they make sense. After that we
could do some value tracking to see if this is the first time a given register
has been set to a particular value, or the first of a number of other
occurances. This should draw the eye to unusual things.
As Linus has pointed out, that patch reduces the number of writes to the ring
register, but doesn't necessarily prevent overflows. It could yet be a fifo
problem.
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
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
