开启完整HWP(SpeedShift)电源管理特性

syscl

jiangzhourui 发表于 2017-4-3 14:05
机型是imac17.1，cpu是7700，不过后来发现用ssdt的话也是没有睿频

iMac171需要替换成支持机型的plist文件 即可

jiangzhourui

syscl 发表于 2017-4-3 14:07
iMac171需要替换成支持机型的plist文件 即可

这个是改了的，plist文件改成了Mac-B809C3757DA9BB8D

syscl

jiangzhourui 发表于 2017-4-3 14:09
这个是改了的，plist文件改成了Mac-B809C3757DA9BB8D

添加SortedOrder: SSDT-pr.aml

甘新平

syscl 发表于 2017-4-3 14:10
添加SortedOrder: SSDT-pr.aml

问题是改成对应机型后直接开机禁行了，Waht?

syscl

甘新平 发表于 2017-4-3 14:18
问题是改成对应机型后直接开机禁行了，Waht?

截图。

syscl

syscl

nobbs 发表于 2017-4-2 15:01
另外，问一下，Broadwell 只要ssdtPRGen.sh就能保证speedstep正常了吧？

对

syscl

甘新平

syscl 发表于 2017-4-3 14:34
对

syscl

喜旸旸

老平台不能用这个？？

jiangzhourui

hwp怎样才算是完整开启？是一共26档，然后x86不加载，电源管理只有2项还是一共8项，然后x86加载，电源管理有5项？

1148070455

syscl 发表于 2017-4-3 14:26
截图。

syscl

我的也是，尝试几种机型都不可以，一改就挂～其它确认无误，只要一改这里就废了

syscl

jiangzhourui 发表于 2017-4-3 14:44
hwp怎样才算是完整开启？是一共26档，然后x86不加载，电源管理只有2项还是一共8项，然后x86加载，电源管理有 ...

X86PlatformPluginsInjector会加载在这种情况下。

作用是替代掉了原来的X86.

理论上用Lilu创建一个Plugin出来可以完成X86PlatformPlugin的功能，但是需要更多的开发者参与到讨论中来。

syscl

口袋妖怪heart

syscl 发表于 2017-4-3 14:51
X86PlatformPluginsInjector会加载在这种情况下。

作用是替代掉了原来的X86.

如果需要开发此类型的 Lilu plug-in 的话，应该原理与 AppleALC 一致。
不过 @vit9696 觉得难以维护：CPU 型号太多，每个model需要用的 FrequencyVectors 也可能会有很大的不同，此外可能跨系统兼容性不好（比如在老系统(10.8.5/10.9.x/10.10.x/10.11.x)下 FrequencyVectors 的类型是 dict，但在10.12的某个DP中改成了array。）还有一个重要的原因或许是目前对 FrequencyVectors 的结构研究仍然不够。

另外我觉得，修改大量的 raw data 对用户来说，也可能是件麻烦事...

syscl

口袋妖怪heart 发表于 2017-4-3 15:01
如果需要开发此类型的 Lilu plug-in 的话，应该原理与 AppleALC 一致。
不过 @vit9696 觉得难以维护：CP ...

他跟我说了这个，需要在IM上弄一个group chat才行

他的两个方法（实际上和我想的差不多）：
1. 提供接口给用户自己设置，然后通过Lilu+新的Plugin上传特定的plist 检测特定的CPU属性 注入
2. 让维护者对其中的plist进行维护

我更倾向于先实现#2最后才是实现#1, 但是问题在于vit觉得直接实现#1会更好。raw data改动的地方很多，可以通过脚本给用户特定的选项（然而他觉得这样还不如#1). #1的问题在于CPU Models太多了, 光是维护这一张表就容易失去延续性，同时，每个人对CPU变频管理的策略不同，有的希望高性能，有的希望节能，这其中很难取舍。

syscl

口袋妖怪heart

syscl 发表于 2017-4-3 15:07
他跟我说了这个，需要在IM上弄一个group chat才行

他的两个方法（实际上和我想的差不多）：

Well, 和昨晚和我说的完全一致...

是的，另外对于 Haswell 与 Broadwell 及以上的 FrequencyVectors 结构也有较大差异，Skylake 开始的 hwp; epp; /* 现在又多出个 hwp_override */ 也带来了更大的麻烦。
我觉得写这样的 plugin 倒不是问题，甚至可以完全照抄 AppleALC 。ResourceConverter 也仅仅需要极少的修改。真正的问题在于，如此庞大的数据库，要如何维护；即使真的能够做到非常及时更新的话，可能还会有一些 ES CPU 无法及时得到更新。Yup. We are similar in this case.
另外关于脚本的话，我觉得可能更难实现。比如为一个不受支持的机型如 iMac17,1 开启 HWP：可能需要修改/插入的位置对于不同机型来说也不尽相同，每个机型包含的 power features 也不同，在插入/删除 power features 后要如何调整为 7668 bytes 可能也比较麻烦，（虽然应该就删掉相同长度的nullstr 即可。）

syscl

口袋妖怪heart 发表于 2017-4-3 15:13
Well, 和昨晚和我说的完全一致...

是的，另外对于 Haswell 与 Broadwell 及以上的 FrequencyVectors 结 ...

他想的太复杂了

一个简单的例子就是AppleALC, 他替用户做了太多的事情，以至于有些Res本身是错的（并且不能得到及时的更新, overtune)。

同样的情况也包括在X86Platform里面，本来Platform里面的数值就非常多，个人的精力也极其有限。。

syscl

口袋妖怪heart

syscl 发表于 2017-4-3 15:18
他想的太复杂了

一个简单的例子就是AppleALC, 他替用户做了太多的事情，以至于有些Res本身是错的（并且 ...

是的。。此外除了 FrequencyVectors ，其他的东西也是不同的，比如

1. power_reduced_playback
   
2. thermally_optimized_xcode
   
3. optimized_photobooth
   
4. thermally_optimized_xcode
   
5. optimized_screensavers
   
6. optimized_slideshows
   
7. optimized_visualizers
   
8. thermally_optimized_maps

复制代码

口袋妖怪heart

Anyway, 我觉得vit最担心的应该是database, which is really hard to maintain.

昨天我提出了"不提供database like AppleALC" 的想法，不过他觉得这样的话写出这种plugin也就毫无意义了。。

[EDIT]: A new group PM has been sent to you and @vit9696 on IM.

794767404

syscl 发表于 2017-4-3 14:51
X86PlatformPluginsInjector会加载在这种情况下。

作用是替代掉了原来的X86.

所以"功能扩展"里X86PlatformPlugin显示没加载是因为X86PlatformPluginInjector替代掉了原来的X86 ?(用了Injector时X86PlatformPlugin显示没加载；没用Injector时X86PlatformPlugin显示加载)，这样正常吗？

syscl

794767404 发表于 2017-4-3 16:02
所以"功能扩展"里X86PlatformPlugin显示没加载是因为X86PlatformPluginInjector替代掉了原来的X86 ?(用了 ...

恭喜 正常。

syscl

syscl

口袋妖怪heart 发表于 2017-4-3 15:28
Anyway, 我觉得vit最担心的应该是database, which is really hard to maintain.

昨天我提出了"不提供dat ...

他觉得不提供res的写法是rethink和ridiculous的，但是，关键是，这样的话实际上一个驱动接管的事情太多了。会引起很多其他的问题。如果CPU的String拿不到（由于系统更新）该怎么办？

他的想法还是没走出ALC的路子，实际上ALC的数据库已经很大了。一个驱动编译下来快体积很快就爆炸了。

syscl