All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@free.fr>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: cand@gmx.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] radeon: Make PM info available to all, not just debug users
Date: Mon, 04 Jun 2012 19:54:16 +0200	[thread overview]
Message-ID: <4FCCF648.2090904@free.fr> (raw)
In-Reply-To: <CAH3drwZBA+qvmMuc4JkAASXA+k0wPRYKHGnt4TK18jYVj6wa5A@mail.gmail.com>

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?

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.

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.

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.
>
> 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.

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

  reply	other threads:[~2012-06-04 17:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-02 16:08 [PATCH] radeon: Make PM info available to all, not just debug users Lauri Kasanen
2012-06-03 10:54 ` Christian König
2012-06-04  8:44   ` Lauri Kasanen
2012-06-04 11:30     ` Christian König
2012-06-04 12:30       ` Alex Deucher
2012-06-04 12:40       ` Martin Peres
2012-06-04 14:31         ` Jerome Glisse
2012-06-04 15:02           ` Martin Peres
2012-06-04 15:18             ` Jerome Glisse
2012-06-04 16:18               ` Christian König
2012-06-04 16:29                 ` Lauri Kasanen
2012-06-04 17:05                   ` Jerome Glisse
2012-06-05 10:11                     ` Lauri Kasanen
2012-06-04 17:01               ` Martin Peres
2012-06-04 17:19                 ` Jerome Glisse
2012-06-04 17:54                   ` Martin Peres [this message]
2012-06-04 18:18                     ` Jerome Glisse
2012-06-04 18:29                       ` Jerome Glisse
2012-06-04 20:31                         ` Martin Peres
2012-06-04 19:54                       ` Daniel Vetter
2012-06-04 20:34                         ` Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FCCF648.2090904@free.fr \
    --to=martin.peres@free.fr \
    --cc=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.