[Openchrome-devel] K8M800 artifacts, trac #145, trac #164

[Gabriel Mansi]

On Thu, 2008-03-20 at 10:05 +0100, Thomas Hellstr?m wrote:
> Gabriel Mansi wrote:
> > On Wed, 2008-03-19 at 21:55 +0100, Thomas Hellstr?m wrote:
> >   
> >> Gabriel Mansi wrote:
> >>     
> >>> On Tue, 2008-03-18 at 20:13 +0100, Thomas Hellstr?m wrote:
> >>>   
> >>>       
> >>>> There'll be some more optimizing / stablizing work for AGP DMA in a
> >>>> week 
> >>>> or so, but I'll ask Dave not to push anything until it's considered 
> >>>> stable. I think the code in DRM now is reasonably stable but not
> >>>> really 
> >>>> optimal.
> >>>>
> >>>> That AGP command reader is really screwed. There's a register that
> >>>> you 
> >>>> read to determine where it is currently reading. Locations that are 
> >>>> newly read by the command reader can supposedly be reused for new
> >>>> data....
> >>>>
> >>>> However every now and again the register shows that the command
> >>>> reader 
> >>>> has read "too far", and then suddenly it goes in the reverse
> >>>> direction.....
> >>>>     
> >>>>         
> >>> I found that reg_pause_addr in via_dri.c was incorrectly assigned to
> >>> 0x40c instead of 0x418 for the CX700:
> >>> http://www.openchrome.org/trac/changeset/556
> >>> With the wrong pause address register I was getting a lot of messages
> >>> like this:
> >>>
> >>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edb500,
> >>> 0xf1eda500 0x00000000
> >>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edc500,
> >>> 0xf1eda500 0x00000000
> >>> [drm:via_hook_segment] *ERROR* Paused at incorrect address. 0xf1edd500,
> >>> 0xf1eda500 0x00000000
> >>>
> >>> I wonder if the other chipsets (VM800 and PM800) should be using that
> >>> register as well. VIA is using 0x418 for all chipsets.
> >>>
> >>> Regards,
> >>> Gabriel.
> >>>
> >>>   
> >>>       
> >> Gabriel,
> >> I'm running a CX700-M2 without obvious problems with 0x40C, but I'll 
> >> check tomorrow with 0x418. The PM800 and CN400 both worked well with 
> >> 0x40C when I tried the last time.
> >>
> >>     
> > Thomas,
> > I made a few tests again, I am sure that register makes the difference.
> > I am testing quake 3 demo, I can play it only setting that register to
> > 0x418. I am rebooting the machine after each test.
> > Note that glxgears and the mesa demos runs with both registers 0x418 and
> > 0x40c, also with the old dma code [1] everything works with any of those
> > two registers.
> > I would appreciate any suggestion to make a serious test.
> >
> > Regards,
> > Gabriel.
> >   
> Gabriel, can you try out the attached patch. I'm interested in seeing
> 1) Whether you get a warning on "paused on the wrong address".
> 2) Whether the code works anyway.
> Both with 0x40c and 0x418.
> 
Thomas,

With your patch applied it works with both registers without warning
messages, so, to summarize my tests:

patch applied    register    working   messages
yes              0x40c       yes       none
yes              0x418       yes       none
no               0x40c       no        Paused at incorrect address
no               0x418       yes       none

The performance seems to be similar in all cases, probably a little bit
smoother without the patch applied. I still think that the register must
be 0x418 because, according to the documentation, 0x40c is used for
something else.

Regards,
Gabriel.

> My K8M800 works with both registers, and I've actually never seen the 
> "paused on the wrong address" warning on the K8M800 or CX700-M2 but that 
> might also be related to CPU speed etc.
> 
> > [1] before this commit
> > http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=6c04185857694b2293046b7ea1d4515404a740c3
> >
> >   
> Yes, that version is reasonably stable, but it relies on the code 
> waiting an unreasonable amount of time for the command regulator to 
> pause each command submission.  And if it does, it's not restarted with 
> the correct command.
> 
> The code in the current patch detects false pauses and restarts them 
> with the correct command, but only on the *next* command submission. If 
> there is no next command submission, the last one might not be executed. 
> So if we seem to get a lot of false pauses, we might need a kernel timer 
> that regularly restarts the command reader.
> 
> 
> /Thomas
>