目次: 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
前回とほぼ同じですので、さほど難しくないと思います。
ビルドできましたので、実行……をする前に、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
実行環境は下記のとおりです。
最初にソフトウェア版のライブラリを実行します。
$ 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恐るべしですね。
この記事にコメントする
いつもやっているapt-get dist-upgradeを実行して、ろくに読まずにYes, Yesと適当に答えていたら、家のサーバーのDebianをStretchからBusterにアップグレードしてしまいました。
アップグレードすること自体に何も悪い点はないですが、何も今日、刈谷のホテルからやる必要は全くなかったなあ、と反省しきりです。これで起動しなくなったら、明日の夜にアクセスできなくなって困りますね……。
今回は幸いなことに再起動後も元気に動作していたので、何ら被害はありませんでした。設定を大幅に弄っている場合など、たまに起動しなくなることがあるので、今後は遠隔地から大胆なアップデートをするのはやめておきます。
メモ: 技術系?の話はFacebookから転記しておくことにした。追記&文を組み換えた。
この記事にコメントする
目次: RISC-V
先日購入したHiFive Unleashedが異様に遅く感じるので、手持ちの64bitコア同士でベンチマーク対決をしてみました(2019年12月5日、Raspberry Pi 3の結果を追記)。以前、モナコインのマイナーでベンチマークしたとき(2019年5月27日参照)は、Cortex-A53の1/4くらいの性能でした。
ベンチマークはCoreMarkを使いました。コンパイル条件は下記の通りです。
RK3399, RK3328はDebian arm64 Stableを使っています。StableはRISC-Vに対応していませんので、FU540だけはDebian riscv64 Unstableを使っています。BCM2837はRaspbianです。
測定の結果は、
RK3328とFU540は2倍の差です。動作周波数の差は1.3倍ですから、インオーダーのコア同士にしては性能差があります。
RK3399は異様に速いです。もしかするとA72側で動いているかもしれません。CoreMarkは特定のCPUに張り付ける方法が良くわからないですね……。
メモ: 技術系の話はFacebookから転記しておくことにした。多少追記。後日追記。
この記事にコメントする
目次: 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ですね。
レジスタの各フィールドはこんな意味になっています。計算式は、
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" と書いてあるリンクです。
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から転記しておくことにした。大幅に追記。
この記事にコメントする
| < | 2019 | > | ||||
| << | < | 07 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | 1 | 2 | 3 | 4 | 5 | 6 |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | - | - | - |
25年10月6日
25年10月6日
25年9月29日
25年9月29日
20年8月24日
20年8月24日
16年2月14日
16年2月14日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
20年8月16日
20年8月16日
20年8月16日
20年8月16日
24年6月17日
24年6月17日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: