http://bugs.freedesktop.org/show_bug.cgi?id=26347
--- Comment #19 from Rafał Miłecki <zaj...@gmail.com> 2010-03-04 13:51:04 PST --- (In reply to comment #15) > @Rafał Miłecki: > > Currently (nearly) everything in PM looks wrong to me. Uhm. > First of all the user has no way to configure the power management. I can't > force the card into low-power mode like I can on Windows. Nor can I force the > card into high-power mode if I need the performance e.g. for games (even on > Windows there are situation where I don't want dynamic clock changes because I > want a steady framerate). What you want is static PM, I never claimed we have that. I focus on dynpm. > There is currently no way to tell the driver: I'm in this situation and I need > that much performance. And that's (at least from my understanding) the main > reason for the different "power states" the card offers. No. Power states in AtomBIOS are for both: dynamic and static PM. How do you imagine dynamic PM without knowing valid modes? > This problem extends to mobile systems. On these the driver has currently no > knowledge about the battery/AC-adapter situation. If we want the driver to > react to ACPI events (like AC unplug/plug events) (and I really think we > SHOULD > react to that) we need to expose power state selection to userspace. We may use AC/battery state info in future, when doing much more advanced PM. For now there is not any usage of such info. > > Anyway, I don't think it's really important to understand Windows driver. We > > may eventually need smarter reclocking algorithm. > I think it very much is, because the Windows driver actually does reclocking > right (no artifacts, no sudden gamespeed slowdowns when reclocking occurs) and > offers the user the ability to configure the reclocking behaviour. You won't get info about how to do reclocking to avoid artifacts/corruptions from watching Catalyst. Unless you're going to RE it. About providing UI for static PM I don't think there is much we can learn from Catalyst. We just need someone who will implement that. > I agree that we may need a smarter algorithm for WHEN to do reclocking, but we > should adapt to the Windows driver for WHICH clock/voltage/etc. to select. I believe we known most of flags of power states. If we meet some flags we don't know we may eventually try to find out when Catalyst uses mode with such flag. > The current PM implementation on linux does too much "automagic", which fails > in most cases. It ignores the concept of "power states" in the sense that the > term "power state" doesn't really matter to the driver - it switches between > them anyway. Well, what really more would you like to use from power states? They just provide clocks and voltage with some flags (which we don't parse fully yet). Don't see much more magic about them we could use. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
