Beelink EQ12 Proの高負荷時フリーズ解消

Beelink EQ12 Proでもう少しベンチマークしてみようと思ったのだが、ちょっとトラブったのでメモ書き。

続きを読む

続きを閉じる

---

症状としては、CPUに突然大きな負荷をかけるとシステムごとフリーズするというもの。

x265とかprime95 In-place large FFTテストとか、マルチスレッドでAVX系を酷使する系統の処理を実行すると、実行開始直後にフリーズした。なお、7zipのようなAVXを使用しないベンチマークでは問題なかったし、Cinebenchやx264、prime95のblendテストのような、マルチスレッドでもそこまで演算器への負荷が高そうでないものは問題ないようだった。

なんとなくCPUの電圧不足っぽい症状に似ている。特に高負荷時に問題ということなので、高負荷時に電圧を少し盛ってあげればよさそう。

幸い、EQ12 ProのBIOSはOCこそできないものの、細かい設定が可能になっているので、いろいろ試して高負荷時の電圧に影響するパラメータのLoadline calibrationを調整するとよさそうということが分かった。

起動時に[Del]キー連打で入れるBIOSから [Advanced] > [Power & Performance] >[CPU VR Settings] > [Core/IA VR Settings] の"AC Loadline"と"DC Loadline"をデフォルトから下げるとよさそう。











デフォルトは、下の写真の上のほうにある "470" (=4.7mΩ) というのが標準値のようなのだけど、これを適当に下げてみた。(ACとDCはどっちが効くのかようわからんので適当に両方同じ値にした)

とりあえず"200" (=2.0mΩ) にしてみると、これまで問題の発生していた処理でも安定して動作するようになった。

---

このあたりはCPUの個体差が影響しそう。そもそも私のが外れ個体なだけかもだし、どの個体でもこうした調整が必要ということではないかもしれない。

ただ、TDP=15Wのi3 N305に対して、PL2=35Wの設定の製品なので、電力的にやや厳しい状態というのはあるのかもしれない。(効いているのかわからないけどPL4=83W (持続 2.44ms)というのも見えるし…)



とりあえずフリーズする問題が解消できてよかった。

Beelink EQ12 Proを買ってみた

Alderlake-N搭載のミニPC、Beelink EQ12 Proを買ってしまった。



ということで、この後に実物とか、もう少し細かいスペックとか。

続きを読む

続きを閉じる

---

BeelinkのAlderlake-N搭載ミニPC

---

Alderlake-N搭載のBeelinkのミニPCは今のところ4系統あるらしい。

ざっと調べると、大きな違いはCPU、RAM、LANの性能。あとはSSDやRAMの容量違いなんかもあるようだ。

	CPU	RAM	LAN
S12	N95 (4コア)	DDR4	1GbE
S12 Pro	N100 (4コア)	DDR4	1GbE
EQ12	N100 (4コア)	DDR5	2.5GbE
EQ12 Pro	i3 N305 (8コア)	DDR5	2.5GbE

---

Beelink EQ12 Pro

---

今回買ったEQ12 Proのスペックはこんな感じ。

CPU Gen	Alderlake-N
CPU	i3-N305
Core	8C/8T
Clock	3.8GHz
iGPU	24EU, 1.25GHz
RAM	DDR5-4800, 1ch
RAM Size	16GB
PL1/PL2	20W/35W
ストレージ	M.2 SSD 500GB (PCIe3 x1)
LAN	2.5GbE x2
WiFi	WiFi 6
Bluetooth	5.2
Interface	USB 3.2 x3, HDMI x2, USB Type-C
OS	Windows 11 Pro

CPUがAlderlake-NでEコアのみのCPUというのが特徴。

こんな感じの箱に入ってくる。



箱も小さいと思ったけど、中身はもっと小さい。前に電源、イヤホンジャックとUSB3 x2がある。



後ろはこんな感じで、USB-C、USB3-A、HDMI x2、2.5GbE x2、電源(ACアダプタ)。

---

HWiNFO読みのシステム情報。



CPUがi3 N305、メモリがDDR5-4800の1chが16GB。

HWiNFO読みではDDR5 Dual Channelとなっているが、IntelのページではAlderlake-NはDDR5 1chまでの対応とあるので、HWiNFOの"Dual Channel"はDDR5の内部のチャンネル数のことを言っているのだと思う(ややこしい)。

---

SSDはNVMe SSDが512GB。ただ、PCIe 3x1接続なので、900MB/s弱しか出ない。

とはいえ、ディスクアクセスで最も重要なQ1T1はNVMe SSDらしい速度が出ているので、ディスクが引っかかるというようなことは滅多になさそう。

---

Alderlake-N i3 N305

---

Alderlake-N i3 N305は、AlderlakeのEコアのみを8コア使用したCPU。

Alderlake-N i3 N305をCPU-Zで見ていくと、L2 Cacheが2MBx2となっているので、やはり4コアのクラスタが2つという構成になっているようだ。

---

HWiNFOでみたCPUの詳細情報。



最大3.8GHz動作、All Coreで3.0GHzで、Eコアとしてはかなり高めの周波数に設定されている。

面白いのは、PL2=35W、PL1=20W、tau=28sとなっていること。

Beelinkのページでは25Wとなっていたので、PL2は25Wと思っていたが、実際には35Wに引き上げられている。Intel公式ではTDP=15Wとなっているので、そこから見ると倍以上に引き上げられている。

---

実際のCPU性能がどうなのか、Cinebench R23で確認してみる。

スコアはこんな感じ。

Single Thread	1038.6
Multi Thread (10分)	4213.0

シングルスレッドは、AlderlakeのEコアを3.8GHzまで引っ張っているので、そこそこの性能。Skylake i7 6700KのSTが1100前後らしいので、それに近いシングルスレッド性能があるのだとなかなか侮れない性能だと思う。

マルチスレッドのほうは、8コアのわりにPL1=20Wという制限が厳しいためか、思いのほかの伸びが悪い。

---

実際に、Cinebench R23 10分間を実行中の平均動作周波数、Package Power、最大コア温度を見てみる。



Package Powerを見ると、最初はPL2(35W)で動作し、そのあと30秒ほどでPL1(20W)に移行にしているのが確認できる。

次に動作周波数を見ると、瞬間的に3.6GHzまで上がっているが、全コアが動き出すと最初のうちはPL2の間は2.8GHz前後、その後30秒ほどで2.2GHz前後での動作になっている。やはり8コアをフル稼働させるようなCinebenchのようなケースでは、かなり動作周波数を下げざるを得ないようだ。

CPU温度は最大83℃と結構高くなっている。まあ、ミニPCで筐体が小さいので、ある程度仕方ない部分だと思う。

動作音については、Cinebench中はさすがにちょっとファンの音がするものの、うるさいと思うほどではなかった。負荷がかかっていない状態ではかなり静かだった。

---

ひとまずまとめ

---

AlderlakeのEコアを8コア搭載したi3 N305を使用するEQ12 Proは、こうした低価格なミニPCとしてはかなり高い性能になっていると思う。

これまでのIntelのいわゆるAtom系列のCPUは、どうしても性能がいまひとつで「動作が重い」という印象あったが、今回のAlderlake-NはSkylake同等ぐらいのそこそこ高いシングルスレッド性能を持っているので、「速い」とまでは思わないけれど少なくとも「重い」とは感じることなくそこそこ快適に使用できた。

ミニPCとしては、CPU 8コア/ RAM 16GB / SSD 500GB / 2.5GbE / Wifi6 と一通りほしいものはきちんと揃っているのがうれしいところ。低価格よりの製品だと、どこか微妙にケチられていたりする中、このあたりがそろっているのがありがたい。

あと、地味にWindowsのPro版搭載なのもプラス。

まあ欲を言えばSSDがPCIe3x1なのをなんとかしてほしかったが、Alderlake-NはPCIeレーンが9レーンしかないようなので、やむなし、といったところだろうか。

ROCK 5BのHDMI Inを使って4Kキャプチャしよう

Rock 5BにはHDMI Inがついて来る。4K60 YUV420まではキャプチャできるようで、スペック上はなかなか優秀だ。

ということで、これを活用してみる。

いろいろ試行錯誤した結果、素のffmpegやobsではうまくキャプチャできなかったが、独自にv4l2のmulti planar APIに対応させたffmpeg改造版とrkmppencを組み合わせることで、4K60 YUV420でキャプチャ & hwエンコードできるようになった。

続きを読む

続きを閉じる

---

まず、Radxa ROCK 5Bのキャプチャデバイスは、 /dev/video0 として認識される。

rigaya@rock-5b:~$ v4l2-ctl --device /dev/video0 --all
Driver Info:
        Driver name      : rk_hdmirx
        Card type        : rk_hdmirx
        Bus info         : fdee0000.hdmirx-controller
        Driver version   : 5.10.110
        Capabilities     : 0x84201000
                Video Capture Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04201000
                Video Capture Multiplanar
                Streaming
                Extended Pix Format
Priority: 2
DV timings:
        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148348000 Hz (59.94 frames per second)
        Horizontal frontporch: 84
        Horizontal sync: 48
        Horizontal backporch: 148
        Vertical frontporch: 4
        Vertical sync: 5
        Vertical backporch: 36
        Standards:
        Flags:
DV timings capabilities:
        Minimum Width: 640
        Maximum Width: 4096
        Minimum Height: 480
        Maximum Height: 2160
        Minimum PClock: 20000000
        Maximum PClock: 600000000
        Standards: CTA-861
        Capabilities: Interlaced, Progressive
Format Video Capture Multiplanar:
        Width/Height      : 1920/1080
        Pixel Format      : 'NV24' (Y/CbCr 4:4:4)
        Field             : None
        Number of planes  : 1
        Flags             : premultiplied-alpha, 0x000000fe
        Colorspace        : Unknown (0x10098a48)
        Transfer Function : Default
        YCbCr/HSV Encoding: Unknown (0x000000ff)
        Quantization      : Default
        Plane 0           :
           Bytes per Line : 1920
           Size Image     : 6220800

Digital Video Controls

                  power_present 0x00a00964 (bitmask): max=0x00000001 default=0x00000000 value=0x00000001 flags=read-only

ここまではよさそうだが、いろいろな問題がある。まとめると、こんな感じ。

- Multiplanar formatを使っているが、ffmpegもOBSも対応していない
- ffmpegのv4l2読みがNV16/NV24に対応しない
- デバイスがffmpegの使用する一部の呼び出しに対応していない。
- VIDIOC_G_INPUT (読み込み状況の確認)
- VIDIOC_G_PARM (フレームレートの取得)

---

ffmpegとv4l2-ctlを使いながら、ひとつひとつ見てみよう。

まず、入力はRGB, YUV444(NV24), YUV422(NV16), YUV420(NV12)に対応するが、厄介なのは v4l2 multi-planar API を使用している点である。

rigaya@rock-5b:~$ v4l2-ctl --device /dev/video0 --list-formats
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture Multiplanar

        [0]: 'BGR3' (24-bit BGR 8-8-8)
        [1]: 'NV24' (Y/CbCr 4:4:4)
        [2]: 'NV16' (Y/CbCr 4:2:2)
        [3]: 'NV12' (Y/CbCr 4:2:0)

OBSもffmpegもMultiplanar APIには非対応のようで、これが原因でエラーをはいてしまう。

ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 ~/out.ts
[video4linux2,v4l2 @ 0x558b621f80] Not a video capture device.
/dev/video0: No such device

また、現行のffmpegのv4l2はNV16、NV24に対応していないので、ここもうまくいかない原因となってしまう。

さらに一部の呼び出しに対応していないようで、これはかなり困った点だ。

例えば、VIDIOC_G_INPUT 呼び出し(v4l2-ctl --get-input)にも応答しない。ffmpegは、VIDIOC_G_INPUT 呼び出しで入力があるかを判定しており、応答がないとエラー終了してし
しまう。ついでに、VIDIOC_S_INPUTにも反応しない。

rigaya@rock-5b:~$ v4l2-ctl --get-input
VIDIOC_G_INPUT: failed: Inappropriate ioctl for device

また、VIDIOC_G_PARM 呼び出し(v4l2-ctl --get-parm) にも応答しない。ffmpegは VIDIOC_G_PARM でフレームレートを取得しているが、これの応答がないため、フレームレートが取得されず、でたらめなフレームレートになってしまう。
また、下記のように --get-freq にも応答しない。

rigaya@rock-5b:~$ v4l2-ctl --get-parm
VIDIOC_G_PARM: failed: Inappropriate ioctl for device

rigaya@rock-5b:~$ v4l2-ctl --get-freq
VIDIOC_G_TUNER: failed: Inappropriate ioctl for device
VIDIOC_G_FREQUENCY: failed: Inappropriate ioctl for device

VIDIOC_G_DV_TIMINGS (v4l2-ctl --get-dv-timings) には対応しているため、これを使うと、フレームレートを取得できるようだ。

rigaya@rock-5b:~$ v4l2-ctl --get-dv-timings
DV timings:
        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148348000 Hz (59.94 frames per second)
        Horizontal frontporch: 84
        Horizontal sync: 48
        Horizontal backporch: 148
        Vertical frontporch: 4
        Vertical sync: 5
        Vertical backporch: 36
        Standards:
        Flags:

---

このように、いろいろ問題があるので、とりあえずffmpegのv4l2読み部分を改造して、なんとか読み込めるようにしてみた。
https://github.com/rigaya/FFmpeg/tree/v4l2-multiplanar

1. v4l2 multi-planar APIへの対応
v4l2のドキュメントを参考に、multi-planar APIへの対応をざっと行った。それなりにコードの書き換えが必要だった。
https://github.com/rigaya/FFmpeg/commit/6ecd35e9d8e74da49a03e82b203c5fd6f1c084d8

2. NV16/NV24への対応
対応するといっても、これは単に定義を追加してあげるだけ。
https://github.com/rigaya/FFmpeg/commit/d7bf5fb1dcdd7ddbd173935ca026b17c219a2583

3. VIDIOC_G_INPUT/VIDIOC_S_INPUT に応答しない問題への対応
新たに ignore_input_error というオプションを追加する。 現状だと、VIDIOC_G_INPUT/VIDIOC_S_INPUTが常にエラーを返すので、ここで処理が止まってしまって先に進めない。そこで、"-ignore_input_error 1" とした場合には、ユーザーがchannelを指定した場合に限り、VIDIOC_S_INPUTがエラーを返してもエラー終了するのではなく、警告のみ表示して先に進むよう処理を変える。
https://github.com/rigaya/FFmpeg/commit/a91b4136cccf69954cef70e3f5fd3da3aabbc15a

4. VIDIOC_G_PARM がエラーを返し、フレームレートが設定されない問題への対応
VIDIOC_G_PARM がエラーを返した場合に、VIDIOC_G_DV_TIMINGS を使ってこちらからフレームレートを推定するようにする。

取得できるのは、毎秒のpixel数でフレームレートではないので、若干値がずれるが、多少であれば丸めてそれっぽいフレームレートにしてしまう。
https://github.com/rigaya/FFmpeg/commit/0d6e971afec7d5e997ef197a327e14d8b86443c2

ここまでやって、やっとffmpegでキャプチャできるようになる。

---

この改造版ffmpegを使って試しにキャプチャしてみる。

ffmpeg -f v4l2 -thread_queue_size 4096 -channel 0 -ignore_input_error 1 -i /dev/video0 -pix_fmt yuv420p -c:v libx264 -crf 20 -preset ultrafast ~/test.ts

1080p60なので、x264のultrafastを使ってもかなりCPU使用率は高め。それでも、現実的にエンコードできている。

---

HDMI Inの音声

---

次に、音声も読み込んでみよう。音声の入力デバイスは "arecord -l" で確認可能。

ただ、最初は残念ながら音声がないと言われてしまった。

rigaya@rock-5b:~$ arecord -l
arecord: device_list:276: サウンドカードが見つかりません...

実際には、デバイスは見えていないだけで、存在はしている。

rigaya@rock-5b:~$ cat /proc/asound/cards
 0 [rockchiphdmi0  ]: rockchip-hdmi0 - rockchip-hdmi0
                      rockchip-hdmi0
 1 [rockchiphdmi1  ]: rockchip-hdmi1 - rockchip-hdmi1
                      rockchip-hdmi1
 2 [rockchipdp0    ]: rockchip_dp0 - rockchip,dp0
                      rockchip,dp0
 3 [rockchipes8316 ]: rockchip-es8316 - rockchip-es8316
                      rockchip-es8316
 4 [rockchiphdmiin ]: rockchip_hdmiin - rockchip,hdmiin
                      rockchip,hdmiin

dmesgを見ても認識はされてそうだった。

dmesg | grep audio
[  429.654609] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_audio_interrupts_setup: 1
[  429.817567] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio
[  429.817577] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: restart audio fs(44100 -> 48000) ch(0 -> 2)
[  429.817589] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_audio_fifo_init
[  478.615980] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_audio_interrupts_setup: 1
[  478.628920] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio
[  478.628930] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: restart audio fs(44100 -> 48000) ch(0 -> 2)
[  478.628941] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_audio_fifo_init

原因は気づいてしまえば簡単で、権限の問題だった。ユーザーを "audio" groupに追加することで解決した。

sudo gpasswd -a ${USER} audio

これでshellを立ち上げなおすと、

rigaya@rock-5b:~$ arecord -l
**** ハードウェアデバイス CAPTURE のリスト ****
カード 3: rockchipes8316 [rockchip-es8316], デバイス 0: fe470000.i2s-ES8316 HiFi es8316.7-0011-0 [fe470000.i2s-ES8316 HiFi es8316.7-0011-0]
  サブデバイス: 1/1
  サブデバイス #0: subdevice #0
カード 4: rockchiphdmiin [rockchip,hdmiin], デバイス 0: fddf8000.i2s-dummy_codec hdmiin-dc-0 [fddf8000.i2s-dummy_codec hdmiin-dc-0]
  サブデバイス: 1/1
  サブデバイス #0: subdevice #0

hdmiinは "カード4" なので、これをffmpegで読み込むにはalsaを使って、

ffmpeg -f alsa -thread_queue_size 4096 -i hw:4 -f v4l2 -thread_queue_size 4096 -channel 0 -ignore_input_error 1 -i /dev/video0 -pix_fmt yuv420p -c:v libx264 -crf 20 -preset ultrafast ~/test.ts

とすればよかった。

---

キャプチャ映像をhwエンコード

---

先ほどはx264でswエンコードしていたので、CPU使用率が高かったが、hwエンコードすれば、CPU使用率を抑えられる。

前回作成したhwエンコーダのrkmppencを使ってみる。

まず、先ほど作成した改造版ffmpegのライブラリ(特にlibavdevice)をビルド・インストールして、さらにこれにリンクさせたrkmppencをビルドした。

リンク先がパッケージのlibavdeviceでなく、自分でビルドしたlibavdeviceであることを確認しよう。

rigaya@rock-5b:~/app/rkmppenc$ ldd rkmppenc | grep libavdevice
        libavdevice.so.60 => /usr/local/lib/libavdevice.so.60 (0x0000007fb1f21000)

そのうえで、下記コマンドを実行。

rkmppenc --audio-source hw:4:format=alsa,codec=aac -i /dev/video0 --input-format v4l2 --input-option ignore_input_error:1 --input-option channel:0 --input-option ts:abs --cqp 20 --gop-len 120 -o ~/test.ts

無事hwエンコードでCPU使用率をかなり低く抑えながら、キャプチャできている。

下記はNintendo SwitchのHDMIをキャプチャしたとき。1080p RGBで問題なくキャプチャできている。



今度はPC(RTX4080)の4K出力をキャプチャした場合。YUV420出力ではあるが、こちらも問題なくキャプチャできた。

---

いろいろと調整が必要だったものの、ROCK 5BのHDMI Inで4Kキャプチャができて、さらに強力なhwエンコーダのおかげで、これをリアルタイムエンコードできることも確認できた。

本当はキャプチャするならOBSでしたいところではあるけど、SBCでリアルタイムエンコードしながらHDMIの4Kキャプチャができるのはなかなか面白いと思う。

ROCK 5B (RK3588) でhwエンコード ( rkmppenc )

Rock 5BのRK3588 SoCはhwデコーダ・エンコーダを内蔵していて、下記のコーデックに対応している。

hwエンコード
H.264/HEVC

hwデコード
H.264/HEVC/AV1/MPEG1/MPEG2

このデコーダ・エンコーダを試すため、rkmppenc というアプリを作成した。



H.264からH.264への1080pのエンコードで、400fps以上出しながら、CPU使用率は70%台(Linuxで8コアCPUなのでmaxは800%)と非常に低く抑えられている。

まあ、Bフレームとかはないので、画質はいまいちだけど、とりあえずこの速度でエンコードできるのはかなり高速なエンコーダが積まれているということだと思う。

続きを読む

続きを閉じる

---

ROCK 5BのRK3588 SoCのhwデコーダ・エンコーダ

---

Rock 5BのRK3588 SoCのhwエンコーダ・デコーダはmppというライブラリから呼び出すことができる。

また、リサイズ等を行うことのできる画像処理エンジン(NPU)を搭載しており、これはlibrgaというライブラリから呼び出すことができる。

---

ffmpeg-rkのテスト

---

実際のアプリケーションとしては、公式ではgstreamerで対応しており、また下記のffmpegのフォークから使うことができる。

gstreamerはなんかコマンドラインが独特で使いにくいので、できればffmpeg系を使いたい。ただ、試したかぎり、このffmpeg-rkだといろいろな問題が発生してしまった。

- MPEG2 hwデコードがまともに行えない
dropが多発して、そもそもまともにデコードできなかった。

- hwデコードすると勝手にインタレ解除される

- HEVCエンコードに対応していない

- H.264エンコード時に、levelが適切に設定されない
このため、プレーヤーによっては再生できなかったりという問題が発生する。

- hwデコード + hwエンコードの組み合わせのみしか動作しない
例えば、swデコード + hwエンコード、hwデコード + swエンコード等がうまく動作しない。

- librgaによるリサイズがうまく動作しない
使用しているlibrgaのAPIバージョンが古いため、RK3588 SoCでは動作しない?

といろいろな問題があった。

gstreamerはもう少しちゃんと動作するようだが、やはりMPEG2デコードが安定しないなどの問題がある。

---

rkmppenc

---

ffmpeg-rkでは多くの問題があるため、ffmpegの枠組みの中でいろいろ調査するよりも、自分が全体を理解しているコードで自由に実装できるほうが調べやすいと思ったので、VCEEncをベースに新たにrkmppencというアプリを作成した。

いろいろ試行錯誤して、ひととおりffmpeg-rkでいろいろあった問題は解消でき、安定して動作できるようになった。

対応状況は下記の通り。

- hwエンコード
H.264/HEVC

- hwデコード
H.264/HEVC/MPEG2 (8bitのみ)

- librgaによるhwリサイズ
- iepによるhwインタレ解除
- OpenCLによるフィルタ

---

一番の問題だったhw MPEG2デコードも問題なく動くようになって、
MPEG hwデコード → hwインタレ解除(iep) → hwリサイズ(librga) → H.264 hwエンコード
みたいに処理してこんな感じ。



MPEG2デコードは、H.264デコードより遅いのだけど、それでもCPU使用率も低めに抑えられ、60fpsちょっと出すことができている。

---

エンコードというよりはおそらくインタレ解除周りで律速しているので、インタレ解除でbob化を選択すると、もう少し速度が出て、130fpsぐらい。

---

なお、RK3588のhwエンコーダはBフレームは非対応なので、圧縮率・画質はあまりよろしくはない。このあたりはSBCだし仕方ないだろうし、まあ画質を求めるならQSVとかNVENC、あるいはswエンコーダを使用したほうがよいだろう。

課題は下のようあるけど、一通りは動作するようになったかも。
- hwデコードで対応しているコーデックが限られている
- hwデコードで10bit未対応 (一応ハード的には対応しているはずだが、そこまで実装できていない)
- RK3588以外でどう動作するかわからん
　なんかライブラリのバージョン違いで呼び出し方とかも大きく変わるらしい…?

---

ビルド方法

---

Ubuntuでのビルド方法は下記に書いてみたので、試す場合はこちらを参考にしてみてほしい。
https://github.com/rigaya/rkmppenc/blob/master/Build.ja.md

---

まとめ

---

ということで、mpp/iep/rgaライブラリを活用して、RK3588 SoCでエンコードするアプリを作成した。

うまく動くようになるまで、いろいろ大変だった。とにかく情報が少ないのが、こういうデバイスの難点。でも、とりあえずそこそこ安定して動くようになって本当によかった。

---

おわりに

---

ROCK 5Bのhwデコーダ・エンコーダ調査に関して、tsukumi様にさまざまなご助言・情報提供・テスト等、多大なご協力をいただきました。ありがとうございました。

Radxa ROCK 5Bのキャッシュ・メモリ帯域

今度はいつもの自作のメモリやキャッシュ速度をはかるプログラムで、Rock 5Bのメモリ・キャッシュの速度を確認してみる。

続きを読む

続きを閉じる

---

比較環境

---

Jetson Nanoと、ちょっと前の4コア程度のIntel/AMD CPUと比較した。

Rock 5BはCortex-A76とCortex-A55という2系統のコアを搭載しているので両方測定した。

	RK3588	Jetson Nano	R3 3200G	i5 7500	i5 1035G7
スレッド数	8C/8T	4C/4T	4C/4T	4C/4T	4C/8T
コア/クロック	A76 2.4GHz A55 1.8GHz	A57 2.0GHz	Zen+ 3.6GHz	KBL 3.8GHz	ICL 3.7GHz
RAM	LPDDR4X -4224	LPDDR4 -3200	DDR4 -2400	DDR4 -2666	LPDR4X -3733
RAM容量	8GB	2GB	8GB	8GB	8GB
GPU EU	4SC	1SM	8CU	24EU	64EU
GPU演算器	256	128	512	192	512
OS	Ubuntu 20.04	Ubuntu 20.04	Win 11	Win 10	Win 11

---

まずはメモリアクセスのレイテンシで、キャッシュ階層がわかりやすいようにしたアクセスパターンから。


グラフが表示されない場合はこちら。

Rock 5BのCortex-A76はL1=64K、L2=512K、L3=3MB。
Cortex-A55のほうはL1=32KB、L2=128KB、L3=3MB。

L1あたりはわかりやすいものの、L2/L3あたりはあまりきれいに出ておらずわかりにくい。

Jetson Nano(L2=1MB)よりはキャッシュ量が多い。一方で、Intel/AMDのCPUと比べると当然キャッシュ量は少なめとなっていることもわかる。

---

次に実際のメモリアクセスのレイテンシを測定するランダムなアクセスパターン。


グラフが表示されない場合はこちら。

キャッシュの領域では、Rock 5BのA76はJetson Nanoよりは高速でデスクトップ系の石にそこそこ近いレイテンシになっている。

一方、メモリアクセスの領域ではかなりレイテンシが大きい。LPDDR系はレイテンシが大きめというのもあるのかもしれない。

Rock 5BのA55は全領域で遅め。littleコアなので仕方ないと思う。

---

次に、キャッシュ・メモリの帯域を測定。まずはシングルスレッドから。

グラフが表示されない場合はこちら。

クロックが安定しないのか測定結果がガタガタしてしまっているが、なんとなく本来の形はわかりそう。

Rock 5BのA76はまずまずの速度が出ていて、特にL2以降では、i5 1035G7といい勝負になっていると思う。

Rock 5BのA55はやはりかなり遅く、メモリ・キャッシュ性能も限定的ということがわかる。

---

次にマルチスレッドでアクセスした場合のキャッシュ・メモリの帯域を測定。

グラフが表示されない場合はこちら。

Rock 5B A76はそこそこの帯域が出ているとはいってもIntel/AMDのメモリ・キャッシュ性能よりはクロックが低いのもあって当然低め。それでも大きく離されてはいないあたり、消費電力を考えれば優秀かもしれない。

Rock 5B A55の帯域は狭い。これはまあ、こんなものだろう。ただ、全然メモリ帯域を引き出せないJetson Nanoよりはそこそこメモリ帯域を引き出せている。

---

最後にスレッド数を変えていった時のメモリアクセス速度。

グラフが表示されない場合はこちら。

Cortex A76はシングルスレッドで15GB/s、マルチスレッドで21.6GB/sとそこそこのメモリ帯域を引き出せている。Intel/AMDのPCと比べれば低いものの、SBCとしては優秀だと思う。

本題から外れるが、Jetson Nanoは最大でも7.3GB/sとCPU側の帯域は狭い。GPU側からは20GB/sぐらい出るので、やはりGPU全振りのようだ。

---

ということで、Rock 5Bのメモリアクセス性能を確認した。

絶対性能もまずまずで、SBCで低消費電力なのも考慮すれば優秀な部類なのではないかと思う。このぐらいの性能がファンレスで動いてしまうというのは、なかなか驚きだ。

Radxa ROCK 5Bでベンチマーク

前回はRadxa ROCK 5Bのセットアップ方法を紹介したので、今回はそのベンチマークをして、性能をチェックしてみた。

ROCK 5BのCPUのRK3588は、Cortex-A76を4コアとCortex-A55を４コア搭載しているので、SBCとしては比較的高性能かも?

続きを読む

続きを閉じる

---

Rockchip RK3588

---

RK3588は、8nmプロセスで製造され、CPUについてはCortex-A76 2.4GHzを4コアとCortex-A55 1.8GHzを４コアの計8コアとなっている。

Cortex-A76は、2018年に発表されたARMの"big"コアで、4way decodeのOoO実行。モバイル向けとはいえかなり強力なコアになっている。

Cortex-A55のほうは、ARMの"little"コアなので、こちらは2way decodeのIn Order実行。クロックも低いので、まああまり性能は期待しないほうがよさそう。

GPUは、Mali G610 MP4というGPUで、4シェーダコア、L2 Cache 1MBで実装されている。シェーダコアあたり16レーンの実行ユニットを2基搭載したクラスタを2つ持っているため、GPU全体の演算基は256基となり、これもそこそこの規模となっている。(例えばAlderlakeのGT1も32EUなので、256基)

---

比較環境

---

Jetson Nanoと、ちょっと前の4コア程度のIntel/AMD CPUと比較した。

	RK3588	Jetson Nano	R3 3200G	i5 7500	i5 1035G7
スレッド数	8C/8T	4C/4T	4C/4T	4C/4T	4C/8T
コア/クロック	A76 2.4GHz A55 1.8GHz	A57 2.0GHz	Zen+ 3.6GHz	KBL 3.8GHz	ICL 3.7GHz
RAM	LPDDR4X -4224	LPDDR4 -3200	DDR4 -2400	DDR4 -2666	LPDR4X -3733
RAM容量	8GB	2GB	8GB	8GB	8GB
GPU EU	4SC	1SM	8CU	24EU	64EU
GPU演算器	256	128	512	192	512
OS	Ubuntu 20.04	Ubuntu 20.04	Win 11	Win 10	Win 11

Intel/AMDのCPUはデスクトップ用で、クロックがRock 5Bの1.5倍程度あるので、どうしてもRock 5Bは不利になるけど、まあ比較対象としては同じ4コアだしありかなと。

なお、さすがにOSは揃えられてはいないので注意。

---

CPU: x264

---

まずffmpegのx264で1080pの映像のエンコード速度から。crf=20でその他オプションは指定していない。

ffmpeg -y -i input.mp4 -c:v libx264 -crf 20 -an output.mp4

エンコード速度(fps)をまとめると下記の通り。


Jetson Nanoと比べると圧倒的に高速。

デスクトップ系の石との比較では、やはりクロックの差は大きく、絶対性能は控えめ。あまりこの性能でエンコードをしたくはないだろう。

一方、クロックの分を差し引くとちょっと遅いだけとなり、そこそこよい勝負になっている。i5 7500やR3 3200Gはわりと前のCPUであるとはいえ、デスクトップのCPUと比較可能なレンジの性能が出ているのは結構驚きだ。ファンレスで問題ないほど低電力でこのぐらい出るのは、わりとすごいかもしれない。

---

CPU: 7-zip

---

こちらも同様の傾向。やはりJetson Nanoと比べると圧倒的に高速。

ただ、Rock 5BはRyzen 3200Gやi5 7500に対しては、クロックの分を差し引くとちょっと遅いだけだが、Icelake(i5 1035G7)に対してはかなり大きな差となっていることがわかる。

---

GPU: mixbench

---

CPUはここまでで、今度はGPU。

GPUのピーク性能をOpenCLで引き出して計測するベンチマーク。演算とメモリアクセスの比率(グラフ横軸)を変え、ピーク演算性能とピークメモリバンド幅を取得することができる。

---

まずはGPU演算性能から。


このグラフから、それぞれのピーク性能を取るとこんな感じ。


Rock 5B RK3588は、Jetson Nanoの2倍程度、i5 7500の内蔵GPUよりやや高速ということで、そこそこのパワーのあるGPUを積んでいることがわかる。

とはいえ、演算器の数の多いR3 3200Gや、i5 1035G7と比べると、大きな差がある。

---

次にメモリバンド幅。GPU側から引き出せるメモリ帯域を確認できる。


このグラフから、それぞれのピーク性能を取るとこんな感じ。


Rock 5B RK3588は、Jetson Nanoよりやや高速、i5 7500の内蔵GPUよりわずかに遅いぐらい。RK3588の理論帯域は33.8GB/sなので、まあこんなもんだろうか。とはいえ、SBCとしては立派な数字だと思う。

3200Gやi5 1035G7はさすがにかなりのメモリ帯域が引き出せる。ただ、演算器の性能に見合っているかというと微妙で、やはり内蔵GPUはメモリ帯域のほうが苦しくなりがちというのを示していると思う。この辺りはDDR5世代になると少しはましになるだろうか?

---

M.2 SSD: EXCERIA NVMe PLUS SSD 1TB

---

SSDの性能は、KDiskMarkというLinuxで動作するベンチマークソフトで測定した。

どっかで見たことあるようなUIである。



このSSDは、Seq Readで最大3400MB/s程度まで出るはずだが、2624MB/sにとどまっていて、さすがにフルスピードは出せなかったようだ。とはいえ、これだけ出れば十分だし、実際ディスク操作は非常に快適だ。

SBCでNVMe SSDを使えるのは大きなメリットだと思う。

ただ、今回使用したSSDはオーバースペック感があるので、8ch動作のSSDでなくとも、4ch動作のものでも十分だとは思う。そのほうが値段も抑えられて片面実装のものも選びやすいかもしれない。

---

LAN: RTL8125 2.5GbE Controller

---

iprefで測定した。

最大で2.35Gbps出ていて、非常に優秀。

rigaya@rock-5b:~$ iperf3 -c 192.168.0.24 -p 5201 -t 10 -i 1 -V
iperf 3.7
Linux rock-5b 5.10.110-37-rockchip-g74457be0716d #rockchip SMP Mon Feb 6 09:18:21 UTC 2023 aarch64
Control connection MSS 1460
Time: Sun, 26 Mar 2023 00:55:42 GMT
Connecting to host 192.168.0.24, port 5201
      Cookie: 26xc2povt2aa5lhfin4du2x4lkqmqbjqlkfx
      TCP MSS: 1460 (default)
[  5] local 192.168.0.31 port 56038 connected to 192.168.0.24 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   280 MBytes  2.35 Gbits/sec    0    315 KBytes
[  5]   1.00-2.00   sec   269 MBytes  2.25 Gbits/sec    0    315 KBytes
[  5]   2.00-3.00   sec   276 MBytes  2.32 Gbits/sec    0    315 KBytes
[  5]   3.00-4.00   sec   269 MBytes  2.26 Gbits/sec    0    315 KBytes
[  5]   4.00-5.00   sec   271 MBytes  2.28 Gbits/sec    0    315 KBytes
[  5]   5.00-6.00   sec   275 MBytes  2.31 Gbits/sec    0    315 KBytes
[  5]   6.00-7.00   sec   271 MBytes  2.28 Gbits/sec    0    315 KBytes
[  5]   7.00-8.00   sec   272 MBytes  2.29 Gbits/sec    0    315 KBytes
[  5]   8.00-9.00   sec   266 MBytes  2.23 Gbits/sec    0    315 KBytes
[  5]   9.00-10.00  sec   269 MBytes  2.25 Gbits/sec    0    315 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.66 GBytes  2.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  2.65 GBytes  2.28 Gbits/sec                  receiver
CPU Utilization: local/sender 17.1% (0.3%u/16.7%s), remote/receiver 36.1% (15.6%u/20.5%s)
snd_tcp_congestion cubic

iperf Done.

---

まとめ

---

全体的にSBCとしては非常に性能が高く、快適に使える環境で、これが非常に小さなサイズに収まっているのでかなり面白い。

ただ、その分、そこそこの値段がしてしまうのも事実で、本体24000円、これに追加でケース、ヒートシンク、電源、SSDは別途必要。

最近はAlderlake-NのNUCなんかもあって、Beelink Mini S12を例にとれば、

・Alderlake N95 Eコアx4 (Max 3.4GHz)
・メモリ 8GB DDR4-3200 (1ch)
・iGPU 16EU @ 1.2GHz
・NVMe SSD (PCIe3x1)
・1GbE, Wifi5 (802.11ac)
・Windows 11 Pro付き
・HDMI x2
・USB3.2 Gen2 x4

まあこのぐらいのスペックで3万円弱とかだったりするので、まあだいたい同じくらいの値段になってしまう。

普通にPCとして使うなら、Windowsもついてくるし、ソフトウェア関連で苦労しなくていいAlderlake-N NUCでよくね感は結構感じてしまう。というかこの辺のNUCほんと安すぎ…。

もちろんArm系に興味があったり、低電力・超小型に魅力を感じるなら、今回確認したように結構快適に動作するので、楽しめると思う。

Radxa ROCK 5Bで遊ぼう

ちょっと前に、シングルボードコンピュータ(SBC)であるところのRadxa ROCK 5Bをゲットしてみた。

外見はこんな感じ。まあ、かなりちっちゃいし、ファンレスになっている。水色のアクリルケースもわりと好きかも。

続きを読む

続きを閉じる

---

スペック

---

比較的高性能なRK3588を搭載し、メモリも4～16GBと多め。

さらにUSB 3.0x2、USB 2.0x2、M.2 M、M.2 E、2.5GbEとこの手の製品としてはかなり拡張性が高いと思う。

	Rock 5B
CPU	Rockchip RK3588
コア	Cortex-A76 2.4GHz x4 + Cortex-A55 1.8GHz x4
GPU	Mali G610 MP4
RAM	LPDDR4X-4224 32bitx2 4GB、8GB、16GB
LAN	2.5GbE (48V PoE対応)
ストレージ	M.2 PCIe3x4 eMMC microSD
USB	3.0x2, 2.0x2
映像	HDMI 2.1Out x2 HDMI In x1 (microHDMI)
M.2 E Key	PCIe2.1x1(Wifi用等)、SATA
その他	カメラ、ステレオジャック
電源	USB PD 9-20V 2A

---

必要なもの

---

・本体

・ストレージ
M.2 SSD、eMMCモジュール、microSDのどれか。

せっかくなので高速なM.2 SSDがよいかも。ただ、M.2 SSDの場合は、片面実装のものを推奨。(理由は後述)

・電源
9-20V 2AのUSB Type-C PD電源。

・HDMIケーブル
HDMI出力は通常のフルハイトHDMIでOK。

・LANケーブル or M.2 Key Wi-fiモジュール
Wifiモジュールはついてこないので、どちらかは必要。

・キーボードとマウス

---

外観 & 組み立て

---

こんな感じのちっちゃい箱に入ってくる。かわいい。

---

表面。



CPUの上にプッシュピンでヒートシンクを付けて、こんな感じ。片方のDRAMの上にはヒートシンクが来ないが、GDDRとかと違ってDRAMはたいして発熱しないので特に問題なさそう。

---

裏面。

M.2 SSDを取り付けたところ。これだけ見るとちゃんと取り付けられているように見えるが…



実はこんな感じで、M.2ねじがちゃんと回し切れていない…



なんでこんなことになったかというと、両面実装のM.2 SSDだったために、裏面のNANDが邪魔で、ヒートシンクのプッシュピンと思いっきり干渉してしまうため。

ということで片面実装のM.2 SSDにするのが無難。



まあアクリルケースに入れてしまえば問題ないといえば問題ないが…。

---

初期セットアップ (OSインストール等)

---

初期セットアップはこのあたりを見て進める。

Rock 5B Getting Started

起動ドライブをM.2 SSDにするか、eMMCにするか、microSDにするかで方法が違うので要確認。

個人的には遅いeMMCだのmicroSDだのは勘弁だったので、M.2 SSDにした。ただ、M.2 SSDの場合はちょっと手順が面倒。

---

M.2 SSDでのセットアップ手順はこちら。

1. M.2をPCに取り付け、ダウンロードしたOSイメージを焼き込み
M.2 SSDへのOSイメージの書き込みは、

・普通のWindows PCで書き込む方法
・Rock 5BでmicroSDから書き込む方法

があるが、PCで書き込むことにした。

公式ページに用意されているOSイメージをダウンロード。

これをEtcherというソフトでM.2 SSDに焼き込む。

2. M.2から起動できるようにSPI flashにbootloaderを書き込み
M.2で起動するには、SPI flashというのにbootloaderを書き込む必要がある。

公式の手順はこちら。

USB CケーブルでWindows PC-Rock 5Bを接続して、これもWindows上から書き込むことができる。

・Windows PC上の準備
2-1. RKDevToolのインストール
2-2. ドライバ(RKDriverAssistant.zip)のインストール

・Rock 5Bをmaskrom modeで起動
2-3. Rock 5Bの電源を切る
2-4. Rock 5BのMicroSDやeMMC、M.2 SSDは取り外す
2-5. Rock 5Bをmaskrom modeで起動するため、丸下部分のボタンを押しながら、USBケーブルのUSB TypeC側をRock 5Bに、もう片方をWindows PCにつなげる
2-6. ボタンを離す



2-7. 書き込み用のツールであるRKDevToolでmaskrom modeで起動できたか確認

"Found One MASKROM Device" と出ていたらOK

2-8. loader imageとSPI imageをダウンロード
公式ページからダウンロード

・SPI flashにbootloaderを書き込む
ちょっとスクリーンショットを取り忘れたのでこのあたりは公式ページを見ていただいたほうがいいかも。

2-9. RKDevToolのlist boxを右クリックして、[Load Config]から rock-5b-spinor.cfg を選択
2-10. list boxの"Loader"の"Path"で rk3588_spl_load_vxxx.bin の場所を指定
2-11. list boxの"Image"の"Path"で rock-5b-spi-image.img の場所を指定
2-12. [Run]ボタンの下の[Write by Address]にチェックを入れる
2-13. [Run]ボタンをクリックして100%になるまで待つ
2-14. USBケーブルを抜く



・M.2 SSDを取り付け
これで、普通に起動すればM.2 SSDから起動するはず。

---

Ubuntu 20.04から見た環境情報

---

uname

rigaya@rock-5b:~$ uname -a
Linux rock-5b 5.10.110-37-rockchip-g74457be0716d #rockchip SMP Mon Feb 6 09:18:21 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

lscpu
CPU 0-3がCortex-A55、4-7がCortex-A76のようだ。

rigaya@rock-5b:~$ lscpu
アーキテクチャ:                      aarch64
CPU 操作モード:                      32-bit, 64-bit
バイト順序:                          Little Endian
CPU:                                 8
オンラインになっている CPU のリスト: 0-7
コアあたりのスレッド数:              1
ソケットあたりのコア数:              2
ソケット数:                          3
ベンダー ID:                         ARM
モデル:                              0
モデル名:                            Cortex-A55
ステッピング:                        r2p0
CPU 最大 MHz:                        2400.0000
CPU 最小 MHz:                        408.0000
BogoMIPS:                            48.00
L1d キャッシュ:                      256 KiB
L1i キャッシュ:                      256 KiB
L2 キャッシュ:                       1 MiB
L3 キャッシュ:                       3 MiB
Vulnerability Itlb multihit:         Not affected
Vulnerability L1tf:                  Not affected
Vulnerability Mds:                   Not affected
Vulnerability Meltdown:              Not affected
Vulnerability Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:            Mitigation; __user pointer sanitization
Vulnerability Spectre v2:            Vulnerable: Unprivileged eBPF enabled
Vulnerability Srbds:                 Not affected
Vulnerability Tsx async abort:       Not affected
フラグ:                              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
rigaya@rock-5b:~$ lscpu --all --extended
CPU SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ
  0      0    0 0:0:0:0          yes 1800.0000 408.0000
  1      0    1 1:1:1:0          yes 1800.0000 408.0000
  2      0    2 2:2:2:0          yes 1800.0000 408.0000
  3      0    3 3:3:3:0          yes 1800.0000 408.0000
  4      1    4 4:4:4:0          yes 2400.0000 408.0000
  5      1    5 5:5:5:0          yes 2400.0000 408.0000
  6      2    6 6:6:6:0          yes 2400.0000 408.0000
  7      2    7 7:7:7:0          yes 2400.0000 408.0000

lspci

rigaya@rock-5b:~$ lspci
0000:00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3588 (rev 01)
0000:01:00.0 Non-Volatile memory controller: KIOXIA Corporation Device 0008 (rev 01)
0004:40:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3588 (rev 01)
0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

lsusb

/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

lsblk

rigaya@rock-5b:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mtdblock0    31:0    0    16M  0 disk
nvme0n1     259:0    0 931.5G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot
└─nvme0n1p2 259:2    0   931G  0 part /

clinfo

Number of platforms                               1
  Platform Name                                   ARM Platform
  Platform Vendor                                 ARM
  Platform Version                                OpenCL 2.1 v1.g6p0-01eac0.ba52c908d926792b8f5fe28f383a2b03
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_subgroup_extended_types cl_khr_subgroup_non_uniform_vote cl_khr_subgroup_ballot cl_khr_il_program cl_khr_priority_hints cl_khr_create_command_queue cl_khr_spirv_no_integer_wrap_decoration cl_khr_extended_versioning cl_khr_device_uuid cl_arm_core_id cl_arm_printf cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_import_memory_dma_buf cl_arm_import_memory_host cl_arm_integer_dot_product_int8 cl_arm_integer_dot_product_accumulate_int8 cl_arm_integer_dot_product_accumulate_saturate_int8 cl_arm_scheduling_controls cl_arm_controlled_kernel_termination cl_ext_cxx_for_opencl
  Platform Host timer resolution                  1ns
  Platform Extensions function suffix             ARM

  Platform Name                                   ARM Platform
Number of devices                                 1
arm_release_ver of this libmali is 'g6p0-01eac0', rk_so_ver is '6'.
  Device Name                                     Mali-LODX r0p0
  Device Vendor                                   ARM
  Device Vendor ID                                0xa8670000
  Device Version                                  OpenCL 2.1 v1.g6p0-01eac0.ba52c908d926792b8f5fe28f383a2b03
  Driver Version                                  2.1
  Device OpenCL C Version                         OpenCL C 2.0 v1.g6p0-01eac0.ba52c908d926792b8f5fe28f383a2b03
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Device Available                                Yes
  Compiler Available                              Yes
  Linker Available                                Yes
  Max compute units                               4
  Max clock frequency                             1000MHz
  Device Partition                                (core)
    Max number of sub-devices                     0
    Supported partition types                     None
    Supported affinity domains                    (n/a)
  Max work item dimensions                        3
  Max work item sizes                             1024x1024x1024
  Max work group size                             1024
  Preferred work group size multiple              16
  Max sub-groups per work group                   64
  Preferred / native vector sizes
    char                                                16 / 4
    short                                                8 / 2
    int                                                  4 / 1
    long                                                 2 / 1
    half                                                 8 / 2        (cl_khr_fp16)
    float                                                4 / 1
    double                                               0 / 0        (n/a)
  Half-precision Floating-point support           (cl_khr_fp16)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
  Single-precision Floating-point support         (core)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support         (n/a)
  Address bits                                    64, Little-Endian
  Global memory size                              8059092992 (7.506GiB)
  Error Correction support                        No
  Max memory allocation                           8059092992 (7.506GiB)
  Unified memory for Host and Device              Yes
  Shared Virtual Memory (SVM) capabilities        (core)
    Coarse-grained buffer sharing                 Yes
    Fine-grained buffer sharing                   No
    Fine-grained system sharing                   No
    Atomics                                       No
  Minimum alignment for any data type             128 bytes
  Alignment of base address                       1024 bits (128 bytes)
  Preferred alignment for atomics
    SVM                                           0 bytes
    Global                                        0 bytes
    Local                                         0 bytes
  Max size for global variable                    65536 (64KiB)
  Preferred total size of global vars             0
  Global Memory cache type                        Read/Write
  Global Memory cache size                        1048576 (1024KiB)
  Global Memory cache line size                   64 bytes
  Image support                                   Yes
    Max number of samplers per kernel             16
    Max size for 1D images from buffer            65536 pixels
    Max 1D or 2D image array size                 2048 images
    Base address alignment for 2D image buffers   32 bytes
    Pitch alignment for 2D image buffers          64 pixels
    Max 2D image size                             65536x65536 pixels
    Max 3D image size                             65536x65536x65536 pixels
    Max number of read image args                 128
    Max number of write image args                64
    Max number of read/write image args           64
  Max number of pipe args                         16
  Max active pipe reservations                    1
  Max pipe packet size                            1024
  Local memory type                               Global
  Local memory size                               32768 (32KiB)
  Max number of constant args                     128
  Max constant buffer size                        8059092992 (7.506GiB)
  Max size of kernel argument                     1024
  Queue properties (on host)
    Out-of-order execution                        Yes
    Profiling                                     Yes
  Queue properties (on device)
    Out-of-order execution                        Yes
    Profiling                                     Yes
    Preferred size                                2097152 (2MiB)
    Max size                                      16777216 (16MiB)
  Max queues on device                            1
  Max events on device                            1024
  Prefer user sync for interop                    No
  Profiling timer resolution                      1000ns
  Execution capabilities
    Run OpenCL kernels                            Yes
    Run native kernels                            No
    Sub-group independent forward progress        Yes
    IL version                                    SPIR-V_1.0
    SPIR versions                                 
  printf() buffer size                            1048576 (1024KiB)
  Built-in kernels                                (n/a)
  Device Extensions                               cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_subgroup_extended_types cl_khr_subgroup_non_uniform_vote cl_khr_subgroup_ballot cl_khr_il_program cl_khr_priority_hints cl_khr_create_command_queue cl_khr_spirv_no_integer_wrap_decoration cl_khr_extended_versioning cl_khr_device_uuid cl_arm_core_id cl_arm_printf cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_import_memory_dma_buf cl_arm_import_memory_host cl_arm_integer_dot_product_int8 cl_arm_integer_dot_product_accumulate_int8 cl_arm_integer_dot_product_accumulate_saturate_int8 cl_arm_scheduling_controls cl_arm_controlled_kernel_termination cl_ext_cxx_for_opencl

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  ARM Platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   Success [ARM]
  clCreateContext(NULL, ...) [default]            Success [ARM]
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-LODX r0p0
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-LODX r0p0
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-LODX r0p0

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.2.11
  ICD loader Profile                              OpenCL 2.1

---

ひととおり、Rock 5Bのスペック・外観・セットアップ方法等をまとめた。

今後はベンチマークとかできるといいかな?

Intel Arc A380のアイドル電力を下げる

Intel Arc GPUを去年の8月にゲットして簡単にベンチマークをしたとき、アイドル電力が高いというのを紹介した。

その後、10月の時点でIntelからアイドル電力の下げ方について情報があった。

遅くなってしまったけど、その効果を確認してみる。

続きを読む

続きを閉じる

---

環境

CPU	i9 12900K
コア数	8P+8E/24T
L2	14MB
L3	30MB
Boost	5.2GHz
メモリ	G.Skill F4-3600C16D-16GTZNC
速度	DDR4-3600
容量	8GBx4
タイミング	16-19-19-39-1
メモリFCLK	Gear1
iGPU	Intel UHD Graphics 770
dGPU0	INNO3D GeForce RTX 4080 16GB X3
dGPU1	EVGA GeForce RTX 2070 XC Gaming
dGPU2	GUNNIR Intel ARC A380 Photon 6G OC
dGPU3	ZOTAC GTX 1060 Mini
SSD1	Plextor M10PGN 1TB NVMe PCIe Gen4
SSD2	Plextor M8PeG 1TB NVMe PCIe Gen3
マザー	MSI MAG Z690 TOMAHAWK WIFI DDR4
冷却	Corsair iCUE H150i RGB PRO XT
電源	KRPW-PA1000W/92+ (80+ Platinum)
ケース	Thermaltake Core V71
OS	Windows 11
ドライバ	Intel 31.0.101.4032 NVIDIA 527.56

ちょっとGPUを3枚とかいろいろ積んでしまっているので、そもそもアイドル電力の絶対値は大きめの環境になってしまう。

今回は、設定前後での差を確認してみたい。

---

設定方法

まず、BIOSの設定を確認。

今回のMSIマザーだと [Settings] > [Advanced] > [PCIe Sub-system Settings] 以下に設定がある。

まず、 "Native ASPM" が "有効(Enable)" になっているか確認。



さらに、Arc GPUを挿しているPCIeポートのASPMを "L1" や "L0sL1" あるいは "Auto" など、とにかく"L1"が有効になる設定になっていることを確認する。今回は、Port5がArc GPUに相当していて、ここで "Auto" を選択した。

---

次に、OSの設定変更が必要になる。

[コントロールパネル] > [システムとセキュリティ] > [電源オプション] で現在使用している電源プランの [プラン設定の変更] を選び、[詳細な電源設定の変更] から、[PCI Express] の設定を確認する。

デフォルトでは、[適切な省電力]となっていることが多いと思うが、これだとArc GPUのアイドル電力は高いままになってしまうので、これを[最大限の省電力]に変更する。

---

[適切な省電力]のときのアイドル電力

---

実際に、[適切な省電力]のときの電力をHWiNFOで確認すると、Total GPU Powerが17Wちょっとをうろうろしてしまう。



+Styleのスマートプラグでコンセントの消費電力を測定できるので、システム全体のアイドル電力を確認すると、102W前後で、100Wを切ることができない。



HWiNFOでみると、ASPM StatusがDisabledになっていて、省電力機能が有効になっていない。

---

[最大限の省電力]のときのアイドル電力

---

今度は、[最大限の省電力]にしたときのアイドル電力を確認。HWiNFOで確認すると、Total GPU Powerが一気に下がって、1.4Wちょっとになっている。



先ほどと同じように、システム全体のアイドル電力を確認すると、82W前後で、なんと20Wも下がった！

[最大限の省電力]はシステム全体の設定なので、Arc GPUの省電力効果だけではないかもしれないが、HWiNFOの表示も併せて考えれば、Arc GPUで省電力機能が有効になったからというのが大きいのだと思う。



一応、HWiNFOでも確認。ASPM StatusがL1 Entryになっていて、省電力機能が有効になっていることが確認できる。

---

アイドル電力問題も解決したArc GPU

---

Arc A380のアイドル電力問題を確認してみた。

Intelの公開した情報の通りに設定をすることで、高かったアイドル電力がきちんと下げることができた。

Arcは登場時いろいろな問題を抱えていたが、ドライバも継続して更新されているし、だんだん改善されて行っている。

Arcのエンコーダは非常に優秀だし、それ以前にやはりGPUでより活発な競争が生まれるのはユーザーとしては良いことなので、第3のGPUとして、今後も頑張っていってほしいと思う。

とはいえ、こうした省電力機能は、NVIDIAやAMDなら、こうした設定をしなくてもドライバをインストールすればデフォルトで有効になるものだと思う。今後、そのあたりの改善も期待したい。

2022年を振り返る (PC編)

2022年ももうすぐ終わり。ということで今年さわった自作PCパーツを振り返ってみる。

今年はAV1エンコーダを搭載したGPUがどんどん出てきて、エンコーダをいろいろテストして、まあテストとか実装とかデータまとめたりとか疲れたけど、とても楽しい1年だった。

一方でかつてなく散財してしまった。やばい。

続きを読む

続きを閉じる

---

CPU

---

今年はZen4 7950Xを入手。

定格は熱いのだが、正直電力入れすぎな感じで、75℃に制限したり、PPT=125Wとかに設定してもあまり性能が落ちず、これでSVT-AV1でのエンコードをよくぶん回しているのだけど、静かでかつ5950Xよりかなり速くSWエンコードできるのでとても満足。もっとも、シングススレッドの点ではRaptorLakeのほうがよさそうで、このあたりはZen5での巻き返しを期待したい。

CPUとしては文句ないけど、やはりいわゆるスイートスポットを遠く離れていて、電力を投入している割に少ししか性能が上がっていないところまでデフォルトで引っ張るのはちょっとなあと思う。(まあZen4だけでなくRaptor/Alderもそうだけど)

性能が大きく変わるなら爆熱でも面白いかもだけど、今回のようにそれほど速度のメリットがないのに爆熱・爆音になっていると、使用感を損ねるほうが強く出てしまうように思うので、ちょっともったいない調整だと思う。

もちろん、それ自体は自分でPPT等をさわればよいだけではあって、それは自体は間違いなく簡単にできる。ただ、もうひとつ問題があって、この爆熱仕様の影響で、マザーの電力回路が完全にオーバースペック気味になってきていて、マザーの値段が爆上げしているのが残念。

ハイエンドマザーが高いのは当然としても、発売時の最も安いマザーでもあまりにも構成が豪華すぎで、そりゃそれだけ積めば高いよねという感想しか持てないので、より低価格な選択肢もちゃんと用意しておいてほしい。Zen4登場時、マザーが5万円からというのは円安を考慮しても勘弁して…。

---

GPU

---

AV1対応GPUが続々登場した年になって、いろいろエンコーダを弄り回して楽しかった！

---

GPU - Intel

最初は遅れに遅れたIntel Arcで、しかも中国から発売だったので、中国jd.comで買って検証してみた。結果的に日本での発売時までにQSVEncをそこそこ動くところまで持っていけたので、先にゲットできてよかったと思う。

最初は不安定だったけど、ドライバの更新によりある程度安定して動作するようになった。AV1エンコーダも優秀だったが、特にHEVCエンコーダの画質ー容量比もよく、かつ高速なので、高速・高画質なHWエンコーダを搭載した比較的安価なGPUとしては非常に面白いと思う。

実際のA380のエンコーダとしての使用感は、ドライバが更新され、安定して動作するようになってからは悪くない、というか結構よさげ。エンコーダ自体の性能(画質ー容量比、速度)はかなり優秀だし、多少のフィルタをかける演算力もメモリ帯域もあるし、メモリ量も6GBとエンコードには十分。規模の小さいGPUなので、消費電力も少なく、大きくなく静かでよいと思う。

欲を言えば、まだ性能の割に値段が高いのでコスパがいいとは言えないこと、TDPに対し実消費電力が少ないことを思えば、本来はもっとGPUを小さく、また補助電源なしにもできそうなので、そのあたりはもったいないかなと思う。

GPUとしてどうかはわからん。

---

GPU - NVIDIA

次にNVIDIAのGeforce RTX40xxが発売された。RTX4090は性能・消費電力・大きさ・値段のすべてにおいて超弩級。相対的にRTX4080は微妙な立ち位置だ。

こちらもAV1エンコーダが追加され、こちらもHWエンコーダとしてはかなり優秀な画質ー容量比となっている。ただ現時点ではあまりにも高いので、来年は下位の製品群が充実してくるのを期待したい。

実際にRTX4080を使ってみると、GPU性能は4090ほどではないにしても文句なく高く、また過剰気味な冷却装備のおかげでよく冷え、静かなのがよかった。また確かに最大消費電力は高い(300W以上)が、思ったより実消費電力は小さい場面が多い印象で、特にCUDAフィルタ等を使ってもそれほど消費電力は上がらず150W程度なので、不必要に電力は食わないようだ。

AV1エンコーダの画質はかなり優秀で、かつCUDAフィルタ等も使用できる。やはりGeforceは、CUDA関係のアプリが使用できることで、活用の幅が広いのがやはり他のGPUにはないメリットだと思う。

もっとも、登場時の私が買った時の値段はなかなかやばかった。もうGPUは安くならないとかあきらめてしまわずに、もうちょっと頑張ってほしいと思う。

---

GPU - AMD

最後に来たのがRadeon RX7900XTX/XT。RTX4080に対しかなり演算力・メモリ帯域に優位性があり、かなり期待は高かったように思うが、残念ながら現時点ではそれが必ずしも十分に発揮されているようには見えない。

特に不思議なのは、4Kでのパフォーマンス。これまでいろいろなベンチマークでは、メモリ帯域が強いGPUが4Kでは優位となる傾向が繰り返されてきた。ところが、RX7900XTX/XTに関しては、なぜか4Kのほうが相対的に微妙な傾向があって、こうした上位クラスのGPUって本来高解像度で力を発揮することが期待されているのでは? と思うと、今後のドライバ更新等でパフォーマンスが改善されることを期待したい。

いまのところは、むしろチップレット構造による優れたコスパでアピールするタイプの製品のようだ。リファレンスモデルは比較的安価にはなっていたと思う。

RadeonもAV1エンコーダが追加されたが、これまでと比べればだいぶんと健闘してはいるものの、案の定というか、QSV/NVENCと比べると明確に下回る結果となってしまった。

個人的には、RX7900XTを買って、リファレンスモデルのデザインは気に入っているが、エンコーダに関して言うと…うーん。Arc A380とRTX4080があるなかで、あえてこれでエンコードしようという気は起きないので、正直本当にお高い検証機材と化してしまいそうで、ちょっと残念だ。

---

DRAM

---

当初高かったDDR5もだいぶ安くなってきた1年だったと思う。比較的高速なDDR5も充実してきたので、当初問題になったレイテンシの増大も、多少高速なDDR5を買うことで容易に対処できそう。

今年はZen4用にDDR5-6000, 32GBx2をゲットした。まあこのぐらいのものを買っておけば、長く使いまわせるかなと。

---

ストレージ

---

そろそろPCIe Gen5対応SSDが出てくるらしい。ただ、個人的にはそこまで必要ないので、安くなってきたGen4 SSDのほうが狙い目なように思う。

---

今年買ったCPU/GPU

---

	Intel CPU	AMD CPU	GeForce	Radeon	Arc
2008	C2Q6600		GT8600
2009	i7 920		GT9600
2010	Xeon W3680			HD4350
2011	i5 2500		GTX460
2012	i7 3770K
2013	i7 4770K		GTX 660
2014	i7 5960X	A10-7850K
2015	i7 6700K Celeron N3150		GTX970
2016	Celeron J3710		GTX1080 GTX1060	RX 460
2017	i7 7700K i9 7980XE	R7 1700
2018			RTX2070
2019		R7 3700X R3 3200G
2020	i5 1035G7
2021	i7 11700K i9 12900K	R9 5950X		RX5500XT
2022		R9 7950X	RTX4080	RX7900XT	Arc A380
2023

今年買いすぎでは?

---

来年

---

なにが来るのだろうか?

MetorLake
デスクトップには来ないだの、6P+16Eに減るとか、6P+8E構成しか来なくて結局本命は2024のArrowLakeだとかいう怪しげなうわさが。じゃあ来年はなに出すんや… Raptorちゃんはもう限界よ?

MeteorLakeはIntel4に移行するということなのだけど、やっぱりデスクトップ向けにはなるほどにはクロックが上がらないとかで苦しんでいるのだろうか。14nmや10nmも最初はそうだったし…。

クロック低下分はIPC上げで相殺して、あとはせっかくタイルで作るのならなら6P+8Eを2チップぺたぺたして12P+16Eにしてくれればよいのですよ? (超願望)

Zen5
これも2024年なのだろうか。Zen4ではIPC増が控えめだったので、Zen5ではより大きなIPC向上に期待。

GPU
基本的にはNVIDIAもAMDも下位ラインアップを充実させる年になるはずなので、あまり動きはないかも?

Battlemageは…どうなる!?

---

まあちょっと来年何が来るのかよくわかっていないけど、面白そうな新アーキとか出たら試してみたい。

AV1エンコーダがそろった (Radeon RX7900XT)

ということで、SAPPHIRE Radeon RX7900XT (リファレンスモデル) をゲット。



リファレンスのシンプルなデザイン、わりと好き。

ただ、最近RTX4080をさわったせいか、RX7900XTを手に持った時小さいなと思ってしまった…。完全に感覚がおかしくなっている気がする。

続きを読む

続きを閉じる

---

リファレンスのRX7900XTにしたのは、検証用に早くほしい一方、検証機材を少しでも安く抑えたいというのが大きいが、もうひとつ切実な事情として、今使っている比較的小さめなケース(Define 7 Compact LightTG)に突っ込みたいというのがあった。

GPUが使える幅は実測で約28cm。RX7900XTのリファレンスは276mmなので本当にギリギリ。

RX7900XTXのリファレンスは287mmでたぶんアウト、RX7900XTでもオリファンモデルは大きいのばかりなのでダメそう。ということで、RX7900XTのリファレンスが確保できて本当に良かった。



本当にぎりぎり。あと1cmない。



下に
・RX5500XT (2slot)
・RX550 (ロープロ・1slot)
をいれて配線して完成。

---

ということで、無事RX7900XTを設置完了。

とりあえず、RX7900XT用の22.12.1ドライバを入れると認識した。



ただ、まだ専用ドライバという位置付けなのか、AMD Softwareでは、RX5500XTとRX550を見失ってしまった。GPU-Zでは認識できているのに…。



よく見るとGPU-ZでもちゃんとRX5500XTの情報が取れてない…?



このあたりはちょっといま調べてる時間がないので、まあそのうち…。

まずは、AV1 hwエンコードのほうを先にテストしていきたい。