コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2019年7月12日 >>> 2019年6月29日
link もっと後

2019年7月12日

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辺りのパッケージでインストールできます。

AMD OpenVXライブラリのビルド
$ 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オプションを外してください(おそらく「そのようなライブラリは存在しない」とエラーが出る)。

OpenVXサンプルアプリケーションのビルド
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内蔵)

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

OpenVXサンプルアプリケーション(ソフトウェア版OpenVX)
$ 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で実行します。

OpenVXサンプルアプリケーション(GPU版OpenVX)
$ 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恐るべしですね。

編集者:すずき(2023/09/24 11:57)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2019年7月7日

Debian Busterが来た

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

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

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

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

編集者:すずき(2019/08/25 22:41)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2019年7月5日

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から転記しておくことにした。多少追記。後日追記。

編集者:すずき(2021/06/28 15:35)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2019年7月4日

HiFive Unleashedの動作周波数

目次: RISC-V

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

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

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

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

PRCIレジスタ領域のダンプ
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周波数の計算式
COREPLL = 33.33MHz / (divr + 1) * 2 * (divf + 1) / 2 ^ divq

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

COREPLL周波数
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を見ると簡単に最大動作周波数を取得できます。

RK3328の各コアの最大動作周波数
$ 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
RK3399の各コアの最大動作周波数
$ 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から転記しておくことにした。大幅に追記。

編集者:すずき(2021/06/28 15:25)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2019年7月12日 >>> 2019年6月29日
link もっと後

管理用メニュー

link 記事を新規作成

<2019>
<<<07>>>
-123456
78910111213
14151617181920
21222324252627
28293031---

最近のコメント5件

  • link 21年9月20日
    すずきさん (11/19 01:04)
    「It was my pleasure.」
  • link 21年9月20日
    whtさん (11/17 23:41)
    「This blog solves my ...」
  • link 24年10月1日
    すずきさん (10/06 03:41)
    「xrdpで十分動作しているので、Wayl...」
  • link 24年10月1日
    hdkさん (10/03 19:05)
    「GNOMEをお使いでしたら今はWayla...」
  • link 24年10月1日
    すずきさん (10/03 10:12)
    「私は逆にVNCサーバーに繋ぐ使い方をした...」

最近の記事3件

  • link 23年4月10日
    すずき (11/15 23:48)
    「[Linux - まとめリンク] 目次: Linux関係の深いまとめリンク。目次: RISC-V目次: ROCK64/ROCK...」
  • link 24年11月6日
    すずき (11/15 23:47)
    「[Ubuntu 24.04 LTS on ThinkPad X1 Carbon Gen 12] 目次: Linux会社ではTh...」
  • link 24年11月11日
    すずき (11/15 23:26)
    「[Pythonのテストフレームワーク] 目次: Python最近Pythonを触ることが増えたのでテストについて調べようと思い...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 11/19 01:04