On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres <martin.peres@xxxxxxx> wrote: >> Answers inlined. >> >> Le 04/06/2012 19:19, Jerome Glisse a écrit : >> >>> >>> My point is that there is no way for power management to find an API >>> that fits all GPU. If i were to do it now, i would have one ioctl >>> version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one >>> for r9xx, ... yes there would be some common fields accross them. >> >> Right, but would the userspace care for so much information? > > I think it might, think about newer GPU where we could let user do a > custom profile to restrict the GPU into some range of power > consumption/temperature/fan speed .... What kind of information i > would want to expose would be highly GPU family related. > >> As a user, I would rather want a slider that would range from >> agressive power management to full performance. >> Then, it would be cool for tweakers to have a way to set everything >> they want. But if the interface cannot be common, that's not that >> important. >> >>> That being said i think one file might fit all GPU is the power >>> profile one accepting something : performance, normal, energy I am >>> pretty sure all GPU have and will continue to have& use power >>> profile. >> >> We agree on that. >> >>> But when it comes to reporting information and making custom >>> profile i would use an ioctl because on that side i see way too many >>> difference accross gpu from same company but from different >>> generation, so i wouldn't even want to try to bolt something accross >>> GPU from different company. Also think to IGP, where memory clock >>> doesn't make sense and where even voltage might not make sense as the >>> GPU might be so entangle with the CPU that it would be linked with CPU >>> powerstate. >> >> Fair-enough. I'll need to study AMD hw more then. It is perfectly doable >> and straight forward on nvidia, even on IGP. >> >>> >>> Also when i was refering to shutting down things, i think for instance >>> that some custom profile/powersaving might want to disable shader >>> engine (way more radical than clock gatting). Also think to case of >>> single card multi GPU, people might want to have both GPU working with >>> same profile like when in performance mode, or power down one of the >>> GPU. >> >> Exactly my point, but we seem to disagree on who should do this. >> >> I guess my point makes sense only when put this way, the driver >> is responsible for lowering power consumption whenever it has the >> opportunity to do so (and that means being really opportunistic). >> >> Your point makes sense when thinking the kernel should be doing >> as little as possible. > > No, my point make sense for the case where the kernel is doing a lot > of thing too. We want agressive kernel power management where > downclock the GPU even if the user is not asking for it. > > Still user might want to create custom profile to limit the range of > what the kernel can do, like for instance force the kernel to never go > above some clock/voltage, or below some level. The way i see user > input is more as guideline to the kernel side rather than as strict > rules. > >> To be honest, I'm working towards really opportunistic >> reclocking using a general-purpose engine on newer GPUs. >> This would save a lot of energy on the typical browsing scenario. > > We also want to go that way on AMD GPU. > >> This is why I'm concerned about exposing too much to the userspace, >> the current state is so volatile that it doesn't even make sense to mention >> it in same cases. > > User might want to know in which range is the GPU frequency, or limit > the power usage of its GPU, ... > >>> >>> So as i said in previous mail, my perfect solution is ioctl and let >>> the driver dev do some kind of plugin for gnome-control-center >>> (similar to what compiz effect plugin was from design pov) where >>> driver dev can put a gui that reflect best what is available for each >>> specific case. >> >> Yeah, I get your point as a kernel dev, but I pitty the userspace dev that >> will need to figure out how to use all these ioctls and configuration >> options. > > My point there is that we do the userspace bit, i would like to come > up with some kind of module that thing like gnome-control-center can > use or kde equivalent or anyother desktop environment. > >> What about having a simple common API (sysfs, preferably) that allow to >> change >> the performance profile and leave the rest to drivers? >> >> Would that be acceptable? >> Cheers, >> Martin > > I think a powerprofile file is acceptable, i am not sure if it should > be discrete like performance/normal/battery/low or something more like > a scale 0-10 with 10 being full power and 0 being the lowest power the > GPU can do. I am more incline to the word solution for which we can > gave clear definition like : > > low : power mode is only able to meet the need of one light graphical > application (like video playback) expect some sluggishness in > rendering when switching between application. > battery: save as much power and reduce GPU speed while still allowing > fast desktop reactivity > ... > > Cheers, > Jerome Maybe i should stress that i believe that driver can't efficiently do quick reclocking when it comes to GPU. My understanding is that newer GPU wether AMD or NVidia use some kind of controller that use a small firmware to control power adjustment base on GPU usage on the flight. Those firmware use driver input to determine range of operation (max/min voltage/frequency/fan speed/...) What i want to allow is for userspace to customize and know about those range of operations. A power profile is just a set of range (a range might be a single value on some less adjustable GPU) for each of the adjustable parameters. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
