Power management in KMS
I'm thinking of organizing power management in KMS. There are my ideas, would like to get your opinions. First of all we need a few different power modes. I think radeonhd has nice states for that: 1) OFF /* DPMS off */ 2) IDLE /* DPMS on, no activity for some time */ 3) SLOW_2D /* Simple 2D activity */ 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default AtomBIOS setting. */ 7) MAX /* Use theoretical chip maximum, maybe beyond default - not selected automatically */ Filling states with engine/memory/voltage values can be grabbed from radeonhd. About setting states I see 3 ways: 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). That function asks 2D engine, 3D engine and DPMS for current state and pickups the best solution. Implementation: We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), radeon_state_of_dpms(). 2) From every part (2D, 3D, DPMS) we call setting function with proper argument. Examples: 3D engine calls radeon_set_pm(FAST_3D); 2D engine calls radeon_set_pm(SLOW_2D); DPMS calls radeon_set_pm(IDLE); DPMS calls radeon_set_pm(WAKE_UP); Implementation: We have to store each element's state in our power manager. If we get SLOW_2D, but FAST_3D is still running, we can not downclock. 3) We have some state properties in radeon_device and every patch calls generic function radeon_pikcup_pm(). Implementation: We have to create some rdev-state_of_2d, rdev-state_of_3d, rdev-state_of_dpms, and use that in radeon_pikcup_pm(). Personally I'm for third method. Do you have some comments? Preferred method? Suggestions? -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: I'm thinking of organizing power management in KMS. There are my ideas, would like to get your opinions. First of all we need a few different power modes. I think radeonhd has nice states for that: 1) OFF /* DPMS off */ 2) IDLE /* DPMS on, no activity for some time */ 3) SLOW_2D /* Simple 2D activity */ 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default AtomBIOS setting. */ 7) MAX /* Use theoretical chip maximum, maybe beyond default - not selected automatically */ Filling states with engine/memory/voltage values can be grabbed from radeonhd. About setting states I see 3 ways: 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). That function asks 2D engine, 3D engine and DPMS for current state and pickups the best solution. Implementation: We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), radeon_state_of_dpms(). 2) From every part (2D, 3D, DPMS) we call setting function with proper argument. Examples: 3D engine calls radeon_set_pm(FAST_3D); 2D engine calls radeon_set_pm(SLOW_2D); DPMS calls radeon_set_pm(IDLE); DPMS calls radeon_set_pm(WAKE_UP); Implementation: We have to store each element's state in our power manager. If we get SLOW_2D, but FAST_3D is still running, we can not downclock. 3) We have some state properties in radeon_device and every patch calls generic function radeon_pikcup_pm(). Implementation: We have to create some rdev-state_of_2d, rdev-state_of_3d, rdev-state_of_dpms, and use that in radeon_pikcup_pm(). Personally I'm for third method. Do you have some comments? Preferred method? Suggestions? I have been thinking to PM too, getting hint from userspace is i believe somethings we want, how this hint should be given needs more discussion, i was thinking to either use a score (like 100 give me full power, ...) or using asic specific level more or like what you propose with 2donly, fast2d,3d, ... but which would be asic specific because on some asic some stuff doesn't exist (like 2d doesn't on new hw). From implementation pov i would like to merge all powermanagement we have now into a single callback function, of course reussing common sub functions accross asics. Basicly i want to shrink down the number of callback as i think it became harder to follow what's happening on a given asic. So it would be somethings like radeon_pm and each asic would have it's own function (well some asic will likely share one like r3xx r4xx). Cheers, Jerome -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
It's about radeon's KMS and PM of course, sorry for not specifing. W dniu 9 września 2009 10:50 użytkownik Rafał Miłecki zaj...@gmail.com napisał: I'm thinking of organizing power management in KMS. There are my ideas, would like to get your opinions. First of all we need a few different power modes. I think radeonhd has nice states for that: 1) OFF /* DPMS off */ 2) IDLE /* DPMS on, no activity for some time */ 3) SLOW_2D /* Simple 2D activity */ 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default AtomBIOS setting. */ 7) MAX /* Use theoretical chip maximum, maybe beyond default - not selected automatically */ Filling states with engine/memory/voltage values can be grabbed from radeonhd. About setting states I see 3 ways: 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). That function asks 2D engine, 3D engine and DPMS for current state and pickups the best solution. Implementation: We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), radeon_state_of_dpms(). 2) From every part (2D, 3D, DPMS) we call setting function with proper argument. Examples: 3D engine calls radeon_set_pm(FAST_3D); 2D engine calls radeon_set_pm(SLOW_2D); DPMS calls radeon_set_pm(IDLE); DPMS calls radeon_set_pm(WAKE_UP); Implementation: We have to store each element's state in our power manager. If we get SLOW_2D, but FAST_3D is still running, we can not downclock. 3) We have some state properties in radeon_device and every patch calls generic function radeon_pikcup_pm(). Implementation: We have to create some rdev-state_of_2d, rdev-state_of_3d, rdev-state_of_dpms, and use that in radeon_pikcup_pm(). Personally I'm for third method. Do you have some comments? Preferred method? Suggestions? Dave linked me to http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/drm-radeon-pm.patch?revision=1.2.6.2view=markup This patch uses timer to check if nothing has been rendered for some time. That would be quite close to first solution. -- Rafał Miłecki -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
2009/9/9 Jerome Glisse gli...@freedesktop.org On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: I'm thinking of organizing power management in KMS. There are my ideas, would like to get your opinions. First of all we need a few different power modes. I think radeonhd has nice states for that: 1) OFF /* DPMS off */ 2) IDLE /* DPMS on, no activity for some time */ 3) SLOW_2D /* Simple 2D activity */ 4) FAST_2D /* Advanced 2D activity, e.g. video playback */ 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ 6) FAST_3D /*Fast 3D activity, e.g. games. Usually using default AtomBIOS setting. */ 7) MAX /* Use theoretical chip maximum, maybe beyond default - not selected automatically */ Filling states with engine/memory/voltage values can be grabbed from radeonhd. About setting states I see 3 ways: 1) Every part (2D, 3D, DPMS) call generic function radeon_pikcup_pm(). That function asks 2D engine, 3D engine and DPMS for current state and pickups the best solution. Implementation: We have to introduce radeon_state_of_2d(), radeon_state_of_3d(), radeon_state_of_dpms(). 2) From every part (2D, 3D, DPMS) we call setting function with proper argument. Examples: 3D engine calls radeon_set_pm(FAST_3D); 2D engine calls radeon_set_pm(SLOW_2D); DPMS calls radeon_set_pm(IDLE); DPMS calls radeon_set_pm(WAKE_UP); Implementation: We have to store each element's state in our power manager. If we get SLOW_2D, but FAST_3D is still running, we can not downclock. 3) We have some state properties in radeon_device and every patch calls generic function radeon_pikcup_pm(). Implementation: We have to create some rdev-state_of_2d, rdev-state_of_3d, rdev-state_of_dpms, and use that in radeon_pikcup_pm(). Personally I'm for third method. Do you have some comments? Preferred method? Suggestions? I have been thinking to PM too, getting hint from userspace is i believe somethings we want, how this hint should be given needs more discussion, i was thinking to either use a score (like 100 give me full power, ...) or using asic specific level more or like what you propose with 2donly, fast2d,3d, ... but which would be asic specific because on some asic some stuff doesn't exist (like 2d doesn't on new hw). From implementation pov i would like to merge all powermanagement we have now into a single callback function, of course reussing common sub functions accross asics. Basicly i want to shrink down the number of callback as i think it became harder to follow what's happening on a given asic. So it would be somethings like radeon_pm and each asic would have it's own function (well some asic will likely share one like r3xx r4xx). Cheers, Jerome This will need separate hint for PCIE-lanes, memory and engine because some applications might transfer large amount of data with very little processing (xv?) while some applications could do complex stuff in GPU and use very little memory bandwidth (OpenCL?). -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 11:10 użytkownik Jerome Glisse gli...@freedesktop.org napisał: I have been thinking to PM too, getting hint from userspace is i believe somethings we want, how this hint should be given needs more discussion, i was thinking to either use a score (like 100 give me full power, ...) or using asic specific level more or like what you propose with 2donly, fast2d,3d, ... but which would be asic specific because on some asic some stuff doesn't exist (like 2d doesn't on new hw). You should really clarify this :) I thought you want to have whole PM in KMS controlled by user space app. Hope I can quote you selecting just 3 sentences: glissemjg59: i am not saying that kernel should not do thing on it's own glissekernel should powerdown when it has good reasons to do so glissei am all for saving power So if I understand you correctly, you just want to have alternative way of forcing some low power mode (from user space app). I think it's totally fine, just as long as it's additional method on control and base power control is in KMS. -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 11:10 użytkownik Jerome Glisse gli...@freedesktop.org napisał: I have been thinking to PM too, getting hint from userspace is i believe somethings we want, how this hint should be given needs more discussion, i was thinking to either use a score (like 100 give me full power, ...) or using asic specific level more or like what you propose with 2donly, fast2d,3d, ... but which would be asic specific because on some asic some stuff doesn't exist (like 2d doesn't on new hw). It's more about power level, not reference to used hardware blocks. I get it like Use power level that is enough for rendering 2D. So it's still valid for r6xx/r7xx. -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
For the most part, the driver should just implement sensible power management itself. We don't want users to have to define complex power management policies. In almost every case, if the user triggers a graphics operation then they want it to complete as quickly as possible. Autmatically upclocking in response to this is pretty easy on most hardware. The only real problem comes with reclocking RAM on a multi-head system. This has to be done during the vblank interval to avoid data corruption, but syncing the vblanks on both displays may well be difficult or impossible. There's a small number of cases where we can't reconfigure a power management state on the fly - the number of PCIe lanes is an example of this. Changing it simply takes too long, and we drop several frames in the process. The right kind of interface for that does require some thought. -- Matthew Garrett | mj...@srcf.ucam.org -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ FWIW: No, compiz (and any other GLX compositing manager, for that matter) works with direct rendering with DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
W dniu 9 września 2009 17:57 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Wed, 2009-09-09 at 10:50 +0200, Rafał Miłecki wrote: 5) SLOW_3D /* Simple 3D activity, e.g. compiz (Q: how to select? indirect rendering only? */ FWIW: No, compiz (and any other GLX compositing manager, for that matter) works with direct rendering with DRI2. That are comments from radeonhd driver, which doesn't support DRI2. I hope we will find some way to determine if we need speed for SLOW of FAST 3D. -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Power management in KMS
I also think it should mostly be handled in the driver. About the only knobs we may want to enable userspace to mess with are say 3 power modes: low power (battery mode), default, and maybe a high power mode later on. The high power mode may require thermal monitoring support depending on the chip. GPM (and whatever kde uses) or the user can then change the mode on the fly in reaction to events like AC - DC, etc.; much like what is done for backlights now. The driver itself would then handle the power state transitions based on the selection from userspace. For example, if the low power state was selected, the driver would limit the max clocks and voltages based on that. As Matthew mentioned, the driver would adjust the engine clock on the fly when commands come in, and then downclock again after a certain period. There would also be an idle mode where everything would be down to the minimum (i.e., crtcs off, engines idle, etc.). In that case we could drop the clocks and pcie lanes to the lowest level. I don't think there is really any need for 2D vs. 3D mode as most of the useful 2D accel uses the 3D engine anyway. So whenever we see commands come in, we should treat it the same; upclock to the limit imposed by the currently selected mode. The power tables in the bios could be used for setting limits and usable combinations (the hw can be picky about what combinations of sclks and mclks modes it likes) and for getting the idle (and possibly suspend) power modes. Mem clocks and pcie lanes are trickier since you need to make sure you have enough bandwidth available to supply all currently active clients (displays, 2D, 3D, overlays, etc.). It probably makes sense to only adjust them during a mode set or a forced power state or the idle state. These require some more thought. Driver hints may be useful here. Alex -- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
