I notice that if I boot KMS git with modeset=1 agpmode=8 dynpm=1 dynclks=1 that I get stalls during games, and lots of corresponding messages as in attached dmesg. Doesn't happen if I don't use dynpm=1 dynclks=1. Card is RV670 AGP, running git ddx,mesa,libdrm & drm-radeon-testing. I don't usually boot with pm (it doesn't ever reduce clocks for me eg. in dpms) so don't know if it ever worked.
Created attachment 33386 [details] dmesg
Confirming on my RV740 in quake3. q3 performance is good, but every other second the whole rendering slows down for a bit to then accelerate again - very annoying. Deactivated all PM and it's gone. Anyway, thanks to some change in the latest drm-radeon-testing any other game than q3 runs REALLY slow - even the good old CS 1.5 through wine goes to a crawl with around 4fps, compared to something around 60-80fps with older snapshots of drm-radeon-testing.
Created attachment 33399 [details] [review] drm/radeon/kms/pm: do not take cp mutex Does it help?
This patch helps, but the stalls don't disappear completly. You can try this yourself, I think ioquake3 + demodata or openarena should work for this. It's like the gamespeed changes inbetween - very subtle but extremely annoying.
(In reply to comment #3) > Created an attachment (id=33399) [details] > drm/radeon/kms/pm: do not take cp mutex > > Does it help? > Yes it fixes the stalls for me, I don't see any framerate variation either. I am still getting the same output in dmesg.
(In reply to comment #2) > Anyway, thanks to some change in the latest drm-radeon-testing any other game > than q3 runs REALLY slow - even the good old CS 1.5 through wine goes to a > crawl with around 4fps, compared to something around 60-80fps with older > snapshots of drm-radeon-testing. I also have a problem with drm-radeon-testing since the 6th, which I have reported to the DRI list. It only affects me using AGP gart and I haven't seen any one else report it - so I guess it may not be what you are seeing, but just in case here's the detail - http://article.gmane.org/gmane.comp.video.dri.devel/42770
(In reply to comment #5) I don't see any framerate variation either. Of course this may be explained by my clock never actually getting changed, if it was changed every time I get a line in dmesg then it could be an issue.
(In reply to comment #3) > Created an attachment (id=33399) [details] > drm/radeon/kms/pm: do not take cp mutex > > Does it help? > We need to take the CP lock to avoid scheduling commands when the CP is running. We probably need a better algo for when to adjust clocks. Maybe some sort of self adjusting timer where we only change the clock when the count of submitted command buffers has been static for a certain amount of time.
(In reply to comment #8) > We need to take the CP lock to avoid scheduling commands when the CP is > running. We need to take the CP lock to avoid scheduling commands when we are changing the clock.
(In reply to comment #7) > (In reply to comment #5) > I don't see any framerate variation either. > > Of course this may be explained by my clock never actually getting changed, if > it was changed every time I get a line in dmesg then it could be an issue. > Running todays drt my clock does now get changed. When it changes I sometimes see visual disturbances - maybe lines, a brief whole screen flash of white or lower part of screen flash black. I still see not in vbl messages. This happens with or without the patch, without the patch I still get long glitches (1/4 or sometimes seems like more seconds) I also notice that even just running gears the clock changes up/down accompanied by visual disturbance every couple of seconds, which seems a bit pointless, as do a lot of the in game changes.
(In reply to comment #10) > I also notice that even just running gears the clock changes up/down > accompanied by visual disturbance every couple of seconds, which seems a bit > pointless, as do a lot of the in game changes. Another thing I've noticed is that if I have two screens cloned then pm doesn't do this. In fact the only time it seems to change clock is to reduce going into DPMS and increase to full on coming back out, so I don't get pm during use unless I turn off one of the screens with xrandr.
(In reply to comment #11) > (In reply to comment #10) > > > I also notice that even just running gears the clock changes up/down > > accompanied by visual disturbance every couple of seconds, which seems a bit > > pointless, as do a lot of the in game changes. > > Another thing I've noticed is that if I have two screens cloned then pm doesn't > do this. In fact the only time it seems to change clock is to reduce going into > DPMS and increase to full on coming back out, so I don't get pm during use > unless I turn off one of the screens with xrandr. > Although the above issues still occur with today's drt the stalls that this bug refers to are now gone - so closing. Missing vbls/disturbances still happen, but only about 1 time out of 5 now (85Hz CRT)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.