コグノスケ

ぼやけるWindows

以前の日記（2019年3月17日の日記参照）で、Windows Updateのあとにウインドウのタイトルがズレてしまう話を書きました。

その際に同時に発生する画面がぼやけてしまう現象についてもスクリーンショットを取ったので載せておきます。

ボヤけている状態

このようにフォントがボヤけてしまいます。タスクマネージャの場合はあまり目立ちませんが、アプリケーションによってはさらに顕著です。

サインアウト、サインインしなおした状態

前回は「再起動で直る」と書きましたが、サインインしなおすだけでも直るようです。

ボヤける理由の予想

ざっくりいうと、Windows Updateがテキストサイズの拡大縮小設定を元に戻した後に、サインインしなおさないからじゃないか？と思っています。

Windows 10にはアプリケーションのテキストサイズを調整する機能があります。[Windowsの設定] -> [システム] -> [ディスプレイ] から設定できます。

拡大縮小設定を変更したときの警告文

設定変更すると一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません、という警告文が表示されます。

購入当初は125％ の設定になっていました。初期値はディスプレイの物理的なサイズと解像度によって決まっているそうです。あと、私は拡大縮小の設定を「100％」に変更して使用しています。

以上から導いた私の予想ですが、

• Windows Updateによって、テキストサイズの設定が初期値（125％）に戻る
• Windows UpdateがPCを再起動する
• アプリケーションがテキストサイズ125％ で表示する
• Windows Updateがユーザーが使っていたテキストサイズ設定（私の場合100％）に設定しなおす
• サインアウトは行わないため、アプリケーションがついてこられずボヤけてしまう

こんな状態になっているのではないかと思っています。

簡易CPU消費電力測定

簡易的にCPUの消費電力を測ってみました。測定ポイントはATX電源とACコンセントの間です。要はワットチェッカーでPC全体の消費電力を測っています。

アイドル状態から1スレッド、2スレッド、と負荷を増やし、
(負荷時の消費電力) - (アイドル時の消費電力) ＝CPUの消費電力
と見なしています。負荷には仮想通貨のマイニングソフトのベンチマークモードを使っています。それなりに複雑な計算と、スレッド数の制御が容易いので便利です。

Ryzen 7 2700のTDPは65Wなのに、消費電力が70W以上に計算されるところからわかるように、消費電力は若干多めに出ています。おそらくCPUの負荷に連動して冷却ファンが回ること、ATX電源の変換効率が負荷によって変わること、などが原因だと思われます。

スレッド数と消費電力

Ryzen 7 2700は8コア16スレッドですが、5スレッドを超えた辺りから、フルパワーの消費電力とあまり差がなくなります。

スレッド数と電力効率

またW辺りの計算効率（kH/s・W）を計算すると、16並列が一番効率が良いです。逆に5〜6スレッド程度だと効率が悪いです。中途半端な並列度で計算するくらいなら、16スレッドフルに使いきれということですね。

コア優先で割り当てたらどうなるか？

上記の実験方法を見て「スレッドをどのCPUに張り付けるかを制御しなくても良いのか？」疑問に感じた方、さすがです。手抜きしていたことがバレましたね。

マイニングソフトのコードを見たら、ちょいと改造すれば簡単にスレッドのaffinityを設定できそうだったので、改造してもう一度測りました。

まずRyzen 7 2700はSMT構成になっていまして、1コアが2スレッド実行可能（OSからは1コア ＝2 CPUとして扱う）です。私の環境Debian Testingだと、

• CPU 0: コア0スレッド0
• CPU 1: コア0スレッド1
• CPU 2: コア1スレッド0
• CPU 3: コア1スレッド1
• ...

以上のように割り当たるようです。ここで素直にCPU 0から順にスレッドのaffinityを設定すると、1つのコアに2スレッドずつ張り付きます。どういうことかと言いますと、4スレッド起動したとき、コア0とコア1に2スレッドずつ張り付いて、他の6コアはヒマになるということです。これはあまり効率が良くなさそうですよね？

今回の測定では、コアを使い切ることを優先してスレッドを割り当てました。当然ながら16スレッドの性能は変わらないのですが、途中の傾向が少し変わります。

スレッド数と消費電力、コア優先割り当て

消費電力は4コアの時点でピークにかなり近くなります。8コアじゃないのは何ででしょうね？2コアがペアで電源制御されているんでしょうか……？

スレッド数と電力効率、コア優先割り当て

電力効率は8スレッドが最大で、16スレッドに向かってやや下がります。SMTの特徴が出ている感じがします。

メモ: 技術系の話はFacebookから転記しておくことにした。多少修正。

ROCKPro64のシリアル文字化け - 真因発見か？

目次: ARM

ROCKPro64のシリアル文字化け問題に進展がありました。結論から先に言えば、現在のlinux-nextのI/Oドメインaudio_gpio3d4a_msの電圧設定が間違っていそうです。直したらシリアルの波形が綺麗になりました。

RK3399はI/Oドメイン（正式な名前かどうか知らない）といって、いくつかの出力ピンがグループになっています。グループごとに電源ピンがあり、電源ピンに何Vを供給しているか設定する必要があるようです。audio_gpio3d4a_msドメインの電源はAPIO5_VDD端子です。

要はAPIO5_VDD端子に1.8Vを供給するなら、audio_gpio3d4a_msドメインの設定も1.8Vにする必要があり、APIOD5_VDD端子に3.0Vを供給するなら、audio_gpio3d4a_msドメインの設定も3.0Vにする必要があります。

ROCKPro64の回路図を見ると、P.4のPower Domain Mapというページにaudio_gpio3d4a_msには電源IC（RK808）のVLDO7が繋がっていて、1.8Vだと書いてあります。linux-nextはこの記述を見て設定していると思われます。

しかしP.16の回路図を見ると、APIO5_VDD端子にはVCC_3V0（その先はVLDO8）という3.0V出力ピンが繋がっています。つまりROCKPro64の回路図は自己矛盾しています。

APIO5_VDDの配線図

VCC_3V0の配線図

配線ミスってるとか、そんなのありかよ……と思いつつP.16の回路図を信じることにして、audio_gpio3d4a_msを3.0V設定にするパッチをLKMLに送りました。

偉そうに書いていますが、私はP.16の回路図には全く気づいておらず、LKMLのナイスガイ達に助けられました。ありがたいことです。

関係ないドメインなのに、なぜ影響するのか？

UART2信号が出ているGPIO4_C3ピンはgpio1830_gpio4cdドメインに属しており、audio_gpio3d4a_msドメインでは「ない」です。にも関わらず、なぜかaudio_gpio3d4a_msドメインの設定ミスでUART2の波形がおかしくなります。

Power Domain Mapと回路図の意図を整理すると、Power Domain Mapの設計は、下記の通りです。

• audio_gpio3d4a_ms - APIO5_VDD - VCCA1V8_CODEC - VLDO7
• gpio1830_gpio4cd - APIO4_VDD - VCC1V5 - VLDO6, VCC3V0_IO - VLDO8

一方の回路図はというと、全然接続が違いますし、端子がなかったりします。

• VCCA1V8_CODEC - VLDO7
• VCC_1V5 - VLDO6
• VCC3V0_IO存在しない
• audio_gpio3d4a_ms - APIO5_VDD - VCC3V0 - VLDO8
• gpio1830_gpio4cd - APIO4_VDD - VCC3V0 - VLDO8

VLDO系の配線図

推測ですが、意図せずに2つのドメインで電源ラインVLDO8を共有したために、audio_gpio3d4a_msドメインの設定ミスが、gpio1830_gpio4cd側のドライブ能力に影響していると思われます。

VLDO8に想定してない負荷が掛かっているような気がしますが、大丈夫なんですかね……？？まあ、コスパ重視だし、趣味のおもちゃですから、燃えたり爆発したりしなければ問題ないのかな。

（補足）audio_gpio3d4a_msドメインの設定は、GRF_IO_VSELレジスタ（アドレス0xff77e640）のビット1です。

GCCがない世界はどうなるか？

目次: GCC

世界からgccがなくなるとどうなるのか？と思ったので、試してみました。その世界では、少なくともターゲットとなる実機上でセルフコンパイルが可能になるまで、別の環境（例えばPCなど）で、

• clang
• クロスコンパイル

を用いて世界を構築する必要があります。何もかも試すのは不可能なので、必要最小限の要素として、

• ブートローダー（U-Boot）
• カーネル（Linux）
• libc（glibc, newlib）

を試すことにします。

最近はclangとgccは互換性も高いし、楽勝でしょ〜などと生半可な知識で楽観視していましたが、実際やると何かもう全然ダメです。そもそもx86向けのビルドが成功しません。クロスコンパイルなんか以ての外です。

RISC-Vの人たちがGCCに真っ先に対応して、LLVMを放置している理由はこれかなあ？特にGNU, Linux系システムをビルドしようと思ったら、LLVMだけでは話にならないのでは……？？

U-Boot

まずはU-Bootです。

$ make CC=clang defconfig
$ make CC=clang

うまくいきました。さすが！ARMとかAArch64向けなら、U-Bootは良い選択肢のはずです。RISC-Vは違うブートローダを使うので意味ありませんけど。

Linux

次はLinuxです。

$ make CC=clang defconfig
$ make CC=clang
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
Compiler lacks asm-goto support.
make: *** [arch/x86/Makefile:298: checkbin] Error 1

序盤でコケます。どうしたら良いんでしょう、これ。回避方法が見当たりません。

libc (glibc)

$ mkdir build
$ cd build
$ ../configure --prefix="/usr" CC=clang
...
configure: error:
*** These critical programs are missing or too old: compiler
*** Check the INSTALL file for required versions.

まずconfigureが通りません。門前払いです。どうもclangを使ったとき、configureはGCC 3.x系だと思うようで、そんな古いコンパイラはダメよ？と怒られてしまいます。どうしろと。

libc (newlib)

GNU系列のglibcはclangに対応するとは思えませんし、newlibなら何とかしてくれるはず。

$ mkdir build
$ cd build
$ ../newlib/configure --disable-multilib CC=clang CXX=clang++
...
In file included from ../../../newlib/libc/ssp/gets_chk.c:39:
In file included from /home/katsuhiro/share/projects/oss/newlib-cygwin/newlib/libc/include/limits.h:132:
In file included from /usr/lib/llvm-7/lib/clang/7.0.1/include/limits.h:37:
/usr/include/limits.h:145:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT)
^
1 error generated.

ええ、そう思っていた時代が私にもありました。救世主だと勝手に思っていましたが、まさかのコンパイルできず。

注意

いずれの手順もCC=clangを付けなければ（＝GCCを使えば）成功することは確かめていますが、私の実行したビルド手順が正しい保証はありません。

GCC → clangへの切り替えを行う際に「CC=clangを付ける」が正しい手順とは限らないからです。ソフトウェアによってはclang専用に別のビルド手順が存在するかもしれません。

ビルド失敗していることからもわかる通り、私は正しいビルド手順は発見できていません。知っていたらぜひ教えて欲しいです……。

メモ: 技術系の話はFacebookから転記しておくことにした。いろいろ追記した。