W dniu 21 listopada 2009 16:40 użytkownik Jerome Glisse <[email protected]> napisał: > On Sat, Nov 21, 2009 at 01:51:32PM +0100, Rafał Miłecki wrote: >> This adds dynamic engine reclocking when engine doesn't work too much. >> >> I calculate amount of not processed commands using fences. If that is >> 0, I set planned action to DOWNCLOCK with some delay. If that amount >> is bigger than 3 (just some my guess) i set planned action to UPCLOCK >> (with delay). > > I don't think this how it should be done, don't try to poke fence > directly, better add an helper function. Copy radeon_fence_wait_last > to radeon_fence_status_last and make it return status of last emited > fence. Then just downclock when there is no active fence. > > Bottom line is that we need to find some good heuristic on GPU > activity to decide when to downclock and when to reclock GPU. > But i think for now we should just downclock it to some level > when we don't see fence activities for a while, and reclock it > if we start seeing fence activities again (this should be agressive).
It happens really quite often that there is just one or two not processed command when just using standard desktop. So I really would like to avoid just checking status of last emitted fence. That would cause many not needed upclocking operations. Maybe my current solution is too non-aggressive (I plan to upclock on noticing 4 not processed commands and delay that for 200ms with 2 checks for 0 not processed commands). Maybe I could upclock on noticing 4 not processed commands without any delay? On the other hand as I said I didn't notice any performance regression. So maybe current solution is not so bad? >> This keeps my engine downclocked when just using KDE or even starting >> glxgears. >> >> When playing openarena this upclocks my engine. I didn't notice any >> serious regression in openarena demo (I don't cound 0.5FPS drop). >> >> Please try this patch and developers please comment. After applying >> this you have to load radeon module with parameter dynclks >> modprobe radeon dynclks=1 >> >> To confirm you applied patch, recompiled kernel and used parameter try: >> dmesg | grep "dynamic" >> >> TODO: >> - calculate minimum engine clock using AtomBIOS data >> - avoid ~10 horizontal black lines when reclocking >> >> LATER: >> - wait for IRQ support, add memory reclocking >> - add voltage changing >> - consider other heuristics (more aggressive reclocking?) > > GPU doc clearly state that all GPU needs to be IDLE when reclocking > thus we really need to do that during vblank, you won't be able to > avoid glitches without doing it in vblank time. It seems you are right. I made some additional tests, I tried to increase minimum time between reclocks to 300ms, tried to wait until last command is processed (with blocking cs) but this didn't help. I still saw glitches (as you call it, thanks, didn't know correct name). We will have to do that in vblank time. I just wonder if we will fast enought with reclocking engine and memory to fit vblank time. > Minimun engine clock depends on the video output we have to feed, > while doing the bandwidth stuff i tried to compute those limit, > can't remember down to which point i went. That would be interesting and probably important. Could you check if you have some formulas around? Did you try to compute minimum memory clock? > Your patch need also to block all modesetting operation from happening > while reclocking. Likely need to take some of the modesetting lock. That should be simple but I'm really worried about power management in case of two displays connected. It will be hard (impossible?) to find combined blank time for both displays. Should we totally disable power management for dual head? Or should we introduce some option to do not care about glitches? I really do not know. It would be poor to fore max clocks in case of using two displays. > There is also a bunch of code style issue, use checkpatch.pl to fix them. Thanks for pointing, I'll care for correct code style before posting final version :) > Otherwise good job. Thanks for reviewing! :) -- Rafał ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
