コグノスケ

OpenVX on OpenCL

目次: OpenCL

会社の人にOpenVXの別実装があることを教えてもらったので、試してみました。

以前、ソフトウェア実装のOpenVXライブラリを動かしました（2018年11月14日の日記参照）が、AMDのOpenVXの実装（GitHubへのリンク）を使うと、GPUでOpenVXを動かすことができます。

AMDのOpenVX実装ではありますが、OpenCLを使うのでGPUはRadeonである必要はなく、IntelのGPUでもOKです。これが共通APIたるOpenCLの良いところですね。私は現状Radeonを持っていませんので、Intelの内蔵GPUで動かしてみようと思います。

動かし方

まずOpenVXライブラリをビルドします。Debianであればopencl-c-headers辺りが必要になるはずです。またGPUドライバとしてIntel GPUドライバのOSS実装であるbeignetを使います。Debianであればbeignet-dev, beignet-opencl-icd辺りのパッケージでインストールできます。

$ git clone https://github.com/GPUOpen-ProfessionalCompute-Libraries/amdovx-core
$ cd amdovx-core

$ mkdir build
$ cd build
$ cmake ../
$ make -j4

テストには前回も活躍したOpenVXアプリを使用します。OpenCVのバージョンは3.2です。もし古いバージョンのOpenCVを使っている場合は -lopencv_videoioオプションを外してください（おそらく「そのようなライブラリは存在しない」とエラーが出る）。

g++ solution_exercise1.cpp -Wall -I../include \
  -lopencv_video -lopencv_videoio -lopencv_highgui -lopencv_imgproc -lopencv_core \
  -lopenvx -L/path/to/amdovx-core/build/lib

前回とほぼ同じですので、さほど難しくないと思います。

GPUの実力

ビルドできましたので、実行……をする前に、vxProcessGraphの前後に時間計測のコードを入れておきます。

diff --git a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
index c7b8e21..ebc07e5 100644
--- a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
+++ b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
@@ -30,6 +30,8 @@
  *          Kari Pulli             <kari.pulli@gmail.com>
  */
 
+#include <sys/time.h>
+
 ////////
 // Include OpenCV wrapper for image capture and display.
 #include "opencv_camera_display.h"
@@ -368,6 +370,8 @@ int main( int argc, char * argv[] )
     // Process the video sequence frame by frame until the end of sequence or aborted.
     for( int frame_index = 0; !gui.AbortRequested(); frame_index++ )
     {
+        struct timeval st, ed, el;
+
         ////////********
         // Copy the input RGB frame from OpenCV to OpenVX.
         // Use vxAccessImagePatch and vxCommitImagePatch APIs (see "VX/vx_api.h").
@@ -407,8 +411,11 @@ int main( int argc, char * argv[] )
         //      if the frame_index == 0 (i.e., the first frame of the video
         //      sequence), otherwise, select the feature tracking graph.
         //   2. Use ERROR_CHECK_STATUS for error checking.
+        gettimeofday(&st, NULL);
         ERROR_CHECK_STATUS( vxProcessGraph( frame_index == 0 ? graphHarris : graphTrack ) );
-
+        gettimeofday(&ed, NULL);
+        timersub(&ed, &st, &el);
+        printf("ProcessGraph:%d.%06d[s]\n", (int)el.tv_sec, (int)el.tv_usec);
 
         ////////********
         // To mark the keypoints in display, you need to access the output

実行環境は下記のとおりです。

• CPU: Pentium J4205/1.50GHz
• Mem: DDR3L-1600 8GB x 2
• GPU: Intel HD Graphics 505/250MHz（J4205内蔵）

最初にソフトウェア版のライブラリを実行します。

$ LD_LIBRARY_PATH=/path/to/openvx1.1/out/LINUX/x86_64/release/ ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

ProcessGraph:0.254740[s]
ProcessGraph:0.183655[s]
ProcessGraph:0.181082[s]
ProcessGraph:0.180022[s]
ProcessGraph:0.182914[s]
ProcessGraph:0.180622[s]
...

最初のフレームはHarrisCornerによる角検出、それ以降のフレームはトラッキングに要した時間です（そういう内容のデモです）。トラッキングに大体180ms程度、掛かっている様子がわかります。

次に内蔵GPUで実行します。

$ DISPLAY=:1 LD_LIBRARY_PATH=/path/to/amdovx-core/build/lib ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

LOG: [ status = 0 ] OK: OpenVX using GPU device#0 (Intel(R) HD Graphics Broxton 0) [OpenCL 2.0 beignet 1.3] [SvmCaps 0 0]

ProcessGraph:0.030192[s]
ProcessGraph:0.016439[s]
ProcessGraph:0.015872[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015679[s]
...

トラッキングに16ms程度しか掛かりません。正直言ってGPUとしてはローエンドの下の方ですが、J4205のCPU処理と比較すると圧倒的に速いです。GPU恐るべしですね。

Debian Busterが来た

いつもやっているapt-get dist-upgradeを実行して、ろくに読まずにYes, Yesと適当に答えていたら、家のサーバーのDebianをStretchからBusterにアップグレードしてしまいました。

アップグレードすること自体に何も悪い点はないですが、何も今日、刈谷のホテルからやる必要は全くなかったなあ、と反省しきりです。これで起動しなくなったら、明日の夜にアクセスできなくなって困りますね……。

今回は幸いなことに再起動後も元気に動作していたので、何ら被害はありませんでした。設定を大幅に弄っている場合など、たまに起動しなくなることがあるので、今後は遠隔地から大胆なアップデートをするのはやめておきます。

メモ: 技術系？の話はFacebookから転記しておくことにした。追記＆文を組み換えた。

ARMとRISC-VでCoreMark対決

目次: RISC-V

先日購入したHiFive Unleashedが異様に遅く感じるので、手持ちの64bitコア同士でベンチマーク対決をしてみました（2019年12月5日、Raspberry Pi 3の結果を追記）。以前、モナコインのマイナーでベンチマークしたとき（2019年5月27日参照）は、Cortex-A53の1/4くらいの性能でした。

• Rockchip RK3399（Cortex-A72 / 1.8GHz x 2, Cortex-A53 / 1.4GHz x 4）
• Rockchip RK3328（Cortex-A53 / 1.3GHz x 4）
• Broadcom BCM2837（Cortex-A53 / 1.2GHz x 4, 32bit mode）
• SiFive FU540（Rocket / 1GHz x 4）

ベンチマークはCoreMarkを使いました。コンパイル条件は下記の通りです。

• RK3399, RK3328: GCC-6.3.0 Ofast
• BCM2837: GCC-6.3.0 Ofast, 32bit
• FU540: GCC-8.3.0 Ofast

RK3399, RK3328はDebian arm64 Stableを使っています。StableはRISC-Vに対応していませんので、FU540だけはDebian riscv64 Unstableを使っています。BCM2837はRaspbianです。

測定の結果は、

• RK3399: Iterations/Sec : 10242.753252
• RK3328: Iterations/Sec : 4427.390791
• BCM2837: Iterations/Sec : 4008.016032
• FU540: Iterations/Sec : 2255.130422

RK3328とFU540は2倍の差です。動作周波数の差は1.3倍ですから、インオーダーのコア同士にしては性能差があります。

RK3399は異様に速いです。もしかするとA72側で動いているかもしれません。CoreMarkは特定のCPUに張り付ける方法が良くわからないですね……。

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

HiFive Unleashedの動作周波数

目次: RISC-V

SiFive FU540のコア動作周波数は簡単に見ることはできなかったので、求め方をメモしておきます。

アドレス0x10000000にPRCI（Power Reset Clocking Interrupt）のレジスタがありますので、実機でその辺をダンプします。

突然ダンプしますって言われても、どうしたら良いんですか？という方は拙作のmemaccess（GitHubへのリンク）をお使いください。使い慣れたツールがあれば、RISC-V上でビルドすれば使えます（UnleashedはLinuxが動くので）。

私の持っているHiFive Unleashedでは下記のようになっていました。

10000000 c0000000 82110ec0 00000000 82110dc0
10000010 80000000 00000000 00000000 82128ec0
10000020 80000000 00000000 0000002f 00000004

COREPLL周波数を司るレジスタは、corepllcfg0（offset: 0x04）です。値は0x82110ec0ですね。

• [ 5: 0] divr = 0x0
• [14: 6] divf = 0x3b = 59
• [17:15] divq = 0x2
• [20:18] range = 3'b100 => 33MHz

レジスタの各フィールドはこんな意味になっています。計算式は、

COREPLL = 33.33MHz / (divr + 1) * 2 * (divf + 1) / 2 ^ divq

ですので、上記の値を当てはめますと、

COREPLL
= 33.33MHz / (0 + 1) * 2 * (59 + 1) / 2 ^ 2
= 33.33 * 120 / 4 = 999.99MHz≒1GHz

すなわち1GHz駆動であることがわかります。

ウソは書いていないつもりですが、情報源が気になる方はFU540の仕様書 "Chapter.7 Cloking and Reset" の章を見てください。

FU540の仕様書はSiFiveのサイト（FU540のサイトへのリンク）から、誰でもゲットできます。ページの下側かつ左側にある "FU540-C000 Manual" と書いてあるリンクです。

ARMの場合は簡単

Unleashedは面倒でしたが、Rockchip系（に限らないと思いますが）のSoCは /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freqを見ると簡単に最大動作周波数を取得できます。

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1296000

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq
1800000
/sys/devices/system/cpu/cpu5/cpufreq/cpuinfo_max_freq
1800000

簡単で良いですね。こういう細かい使い勝手はRISC-Vはこれからでしょうか。とはいえ世界はRISC-V旋風が吹き荒れているそうなので、次第に充実していくことでしょう。

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

ROCK64の音がlinux-nextで鳴らなくなった

目次: ROCK64/ROCKPro64

ある時からlinux-nextでROCK64のPCMデバイスが全部消えて、一切音が鳴らなくなっていました。ROCKPro64も同じようです。

結論だけ先に言うと、この問題は既にALSA MLで指摘されていて、下記のコミットをリバートすると直ります。

commit b9f2e25c599bbbf0646957e07ebb72b942c286cc
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Jun 20 09:49:33 2019 +0900

    ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()

    snd_soc_find_dai() finds component first via specified
    snd_soc_dai_link_component, and find DAI from it.

    We already have soc_find_component() to find component,
    but soc_find_dai() has original implementation to find component.

    We shouldn't have duplicate implementation to do same things.
    This patch uses soc_find_component() at soc_find_dai()

    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

これは散々調べた後で知りました。悲しい。せっかくなので調べたこともメモしておきます。

ASoCとコンポーネントの登録

最近、ALSA SoC Layer（以下、ASoC）は、ルネサスの森本さんという方の尽力により、実装がかなり変わっているのですが、その一部がバグっていたようです。

ASoCは大まかにいうと、登録と組み合わせの2段階に分かれています。

ドライバのprobe時に、2つのcomponentを登録します。正式な呼び名がわからないので、ここではとりあえずPCMとDMACのcomponentと呼びます。

PCM componentはDAI（Digital Audio Interface）を持っています。DAIはPCMデータの入出力インタフェースのことらしいです。他にもCODECと呼ばれる、PCMデータ（デジタル音声）←→ アナログ音声に変換するドライバもcomponentとして扱われています。

サウンドカードのドライバは、複数のcomponentを組み合わせて、PCMの入出力やアナログ音声出力などを実現する仕組みです。

もう少しコード寄りに説明するとPCM componentはdevm_snd_soc_register_component() を使い、DMAC componentはdevm_snd_dmaengine_pcm_register() を使って登録します。

これらの関数を呼び出すと、

devm_snd_soc_register_component()
  snd_soc_register_component()
    snd_soc_add_component()
      snd_soc_register_dais()
        soc_add_dai()          ★DAIをcomponentに登録★
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★componentをリストに登録★

devm_snd_dmaengine_pcm_register()
  snd_dmaengine_pcm_register()
    snd_soc_add_component()
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★componentをリストに登録★

このような経路を辿ります。

一方、componentを組み合わせる際は、

devm_snd_soc_register_card()
  snd_soc_register_card()
    snd_soc_bind_card()
      snd_soc_instantiate_card()
        soc_bind_dai_link()
          snd_soc_find_dai()
            soc_find_component() ★最近変更された部分、適切なcomponentを探す、しかし…★

このように処理されます。

問題の箇所

前置きがかなり長くなりましたが、上記の処理のうちsnd_soc_find_dai() の変更にバグがあるようです。元々は関数内にcomponentを探す処理が記述されていましたが、処理は削除されsoc_find_component() で適切なコンポーネントを探してくる、という実装に変わりました。

先ほど説明した通り、大抵のASoCドライバはPCM用のcomponentをdevm_snd_soc_register_component() で、DMAC用のコンポーネントをdevm_snd_dmaengine_pcm_register() で登録しますが、かなり残念なことに双方とも全く同じ名前で登録されてしまいます。

例えばROCKPro64で /sys/kernel/debug/asoc/componentsを見ると、

root@rockpro64:/# cat /sys/kernel/debug/asoc/components
hdmi-audio-codec.3.auto
ff870000.spdif
ff870000.spdif
ff8a0000.i2s
ff8a0000.i2s
ff890000.i2s
ff890000.i2s
ff880000.i2s
ff880000.i2s
spdif-dit
snd-soc-dummy

このように、同じ名前のcomponentが2つ登録されていることがわかります。今回のバグの件をさておいても、名前が重複しているのはイマイチですよね……。

組み合わせる際はdevm_snd_soc_register_component() で登録した方、つまりPCM用のcomponent（こいつがDAIを持っている）を探してこなければ、PCMデバイスは正常に登録されません。

しかしsoc_find_component() は動きがおかしくて、devm_snd_dmaengine_pcm_register() で登録した方のコンポーネントを返してしまいます。

結果、DAIが見つけることができず、エラーになってしまい、1つもサウンドカードが登録されないままドライバの登録処理が終わります。

もう少し早く知りたかった

この問題を散々調べた後で、既にALSA MLにて指摘されていたことを知りました。

ALSA MLを最初に調べれば、こんなにコード解析しなくても良かったなあ、と思う一方で、そもそもどういうバグかわからないと、メールは探せないので、鶏と卵ですね。

それと、今に始まったことではありませんが、ASoCは似たような名前の関数が多くて混乱します。先ほど説明にも出ましたが、snd_soc_add_component() とsnd_soc_component_add() なんて、一見で違いがわかりません。何でこんな変な名前にしたんだろう……。

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

ノートPCの充電器（代打）

以前、出張先にノートPCのアダプタ（USB-PD）を忘れて帰ってきてしまったことがあります。

我が家のノートPCの電源端子はUSB Type-Cなので、試しにスマホ用の充電器を繋いでみたのですが、うんともすんとも言いませんでした。ノートPCなどUSB-PDで充電する機器は、充電器側もUSB-PDに対応していないと充電が開始されないみたいです。

次のミスに備えて、普段使いの充電器＋ノートPCアダプタの代打、が可能なAUKEYのUSB-PD充電器PA-Y12（AUKEY PA-Y12のサイト）を買いました。Amazonで5,000円くらいです。

大きさは手のひらサイズくらいですね。端子はType-C + Type-A x 2の3ポートで、出力は合計72W（Type-C: USB-PD 20V 3A, Type-A: 5V 2.4A）ですから、大抵のUSB-PD機器には対応できるはずです。

普段はスマホ（USB type-C）とKindleの充電にしか使っていないので、若干勿体ない感が否めないですが、備えあれば憂いなし。

購入は先月（5/25）で、使用して1か月ほど経っていますが、特に異音や異常もなく元気に動いくれています。良い感じです。

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

GCCを調べる - その4 - RTL (Register Transfer Language) を眺める

目次: GCC

RTLは(演算子 引数1引数2 ...) という形で表記されます。LispのS式に似ているんですかね？前回（2019年6月14日の日記参照）出力したRTLのうち5番目のinsnを例にとります。

(insn 6 5 7 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])
        (reg:SI 104)) "a.c":3 132 {*movsi_internal}
     (nil))

RTLはいくつも種類があり、codeという番号で区別されています。RTLをファイルに出力する際はcodeは名前に変換され、開きカッコの後に書かれます。

先頭のRTLは (insn ... で始まっているので、code = insnのRTLで、その後 (set ... とあるので、code = setのRTLがあるんだな、ということがわかります。上記のRTLに出てくるcodeは、insn, set, mem, plus, reg, const_intの6種類です。

RTLを読んでみる

RTLは引数を取ります。先程の例に出てくるRTLの引数はrtl.defに定義されています。一例を示すと下記のとおりです。

• insn : uuBeiie
• set : ee
• mem : e0
• plus : ee
• reg : r
• const_int: w

例えばsetのeeであればeという種類の引数を2つ取る、という意味です。GCCではRTLの引数をこのように定義します。かなり意味不明だと思いますが、こういうものだと思うしかないです。

さらにeという種類の 引数は別のRTLを含んでOKなので、RTLは入れ子になります。先の例に出てきたRTLを分割してみます。

                     ____________________________________________________________________________________________________________________________________  ________  ______________________  _______
                    | e insn__________________________________________________________________________________________________________   ________________ | i insn  | i insn                | e insn
                    |      | e set      __________________________________________________________________________  _  _______________  | e set           |         |                       |
                    |      |           | e mem     ______________________  _______________________________________ |0 | mem additional  |                 |         |                       |
                    |      |           |          | e plus     _________  | e plus      _________________________  |  |                 |          ______ |         |                       |
         __  __  _  |      |           |          |           | r reg     |            | w const_int               |  |                 |         | r reg |         |                       |
        | u | u | B |      |           |          |           |           |            |                           |  |                 |         |       |         |                       |
(insn 6 | 5 | 7 | 2 | (set | (mem/c:SI | (plus:SI | (reg/f:SI | 65 frame) | (const_int | -4 [0xfffffffffffffffc])) |  | [1 a+0 S4 A32]) | (reg:SI | 104)) | "a.c":3 | 132 {*movsi_internal} | (nil))

途切れ目が非常にわかりにくいです。私も正直ぱっと見ではわかりません。特に引数eは入れ子になっていて、ひたすら見づらいです。RTLの引数の正確な切れ目を知るには、print_rtx_operand_code_e() など、引数のprint関数を見るのが一番早いかもしれません。

RTLの引数の切れ目を見るには

RTLの出力をリアルタイムで見たいときは、gdbでprint_rtl_with_bb() 辺りにブレークを掛けておいて、ステップ実行していくとわかりやすいです。

その際printf系の出力がバッファリングされると、printした文字列がなかなかファイルに出力されません。デバッグ時はprint文と、実際に出力されている文字列の対応が確認しづらいため、最初にsetvbuf() を呼んでバッファリングを無効にしておいたほうが見やすいと思います。

/* Like dump_function_to_file, but for RTL.  Print out dataflow information
   for the start of each basic block.  FLAGS are the TDF_* masks documented
   in dumpfile.h.  */

void
print_rtl_with_bb (FILE *outf, const rtx_insn *rtx_first, dump_flags_t flags)
{
  const rtx_insn *tmp_rtx;

  setvbuf(outf, NULL, _IONBF, 0);  //★★この行を足した★★

  if (rtx_first == 0)
    fprintf (outf, "(nil)\n");
  else
    {
      enum bb_state { NOT_IN_BB, IN_ONE_BB, IN_MULTIPLE_BB };

  //...

あとは観察したいRTLファイルをtail -fとかで追い続ければ良いでしょう。

やっつけ感が満載のGCC

RTLの名前と引数の情報を定義したrtl.defというファイルがあるのですが、これだけを見るといかにも整然としたルールに則っているように見えます。ですが実際は例外だらけで、コードを読んでいるとなかなか辛いものがあります……。

例えば、今回の例で行くとmemの最後に何か（[1 a+0 S4 A32] というやつ）出力されていますよね？rtl.defを見るとmemの引数の定義は "e0" なので、"0" の一部だろうと考えたくなりますが、残念ながら、この情報についてはrtl.defには一切記述がありません。これはひどい。

RTLを文字列として出力するprint_rtx() 関数の実装を見ると、最後の方でMEM, CONST_DOUBLE, CONST_WIDE_INT, CONST_POLY_INT, CODE_LABELだけ特別扱いして、特別に出力が追加されます。16進数だと見づらいし、とりあえず出しておこうという感じでしょうか……。