On 04.06.2012 17:18, Jerome Glisse wrote:
On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres<martin.peres@xxxxxxx> wrote:
Le 04/06/2012 16:31, Jerome Glisse a écrit :
I don't think sysfs is the way to go, i am pretty sure that power
management will change drasticly again in the future especialy btw
discret and integrated GPU. I would rather have hardware specific
ioctl.
Cheers,
Jerome
Any particular idea of what may change?
The proposed interface would work even on entirely dynamic
reclocking (per-domain frequency scaling) as opposed to
perflvl-based reclocking. It is unlikely to happen though.
A more realistic possibility could be that engines would be reclocked
independently according to their internal load.
If that was to happen, then the already-existing API could be used as
a master control and engines could specify the performance level policy
they want (follow master, always min, always max, conservative, dynamic).
I'm pretty sure voltage domains will soon appear but I don't see what could
possibly be changed that wouldn't be covered by what I proposed.
As for the reason we would like to use IOCTLs instead of sysfs, I really
don't understand what is the rationale. I personally want to empower the
users to let them decide what is best for them. Sysfs is way easier to
work with!
Although my idea may be sketchy, I am dead-serious about coming up with
a good API.
Martin
My experience is that things that are true today for GPU, are not
tomorrow. Yes there will still be clock/voltage, but there could be
new complete different things, like shutting down block.
I am not even mentioning things like complex value range dependency
btw things (for instance if a domain as clock/voltage in certain range
than some other domain can only have clock in a restricted range
value).
While i agree that sysfs looks easy for user to play with, i believe
that gui is what you really after and afaik closed source driver all
expose a gui for their power management. Using ioctl allow better
overall control, like atomic setting of several domain ...
Yeah, I think Jerome is right here.
The internals like different voltage areas, dependencies of clocks,
possible powered down chip areas, etc are very complex and actually
completely unteresting to the end user. Also the general direction of
AMD hardware is going to a complete self containing system, e.g. the
chip is handling mostly everything on its own.
I agree that this is better done in a hardware dependent ioctl and then
abstracted in userspace instead of pushing the whole abstraction into
the kernel.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
