rigaya / rkmppenc

Rockchip系SoCのHWエンコーダ(rkmpp)の性能実験
https://rigaya34589.blog.fc2.com/blog-category-35.html
Other
78 stars 8 forks source link

deb パッケージを GitHub Actions でビルドできるようにした #1

Closed tsukumijima closed 1 year ago

tsukumijima commented 1 year ago

deb パッケージを GitHub Actions で完全自動ビルドできるようにしました。実装にあたっては、VCEEncC などのものを参考にしました。 また、librga と mpp に関しても .deb パッケージになっていないと色々取り回しが悪いので、こちらのフォーク (mpp, librga) で GitHub Actions で deb パッケージをビルドできるようにし、push されるたびにリリースページにビルド済みのバイナリが自動アップロードされるように設定しました。 このほか、librga のヘッダファイルは mpp 同様に submodule から読み込んだ方が良いかと思い、そのように変更しました。もし気に入らないようでしたら外していただいても構いません。

これらを組み合わせて、(あらかじめグラフィックスドライバ (libmali) はインストールしておいた上で)librockchip-mpp1, librga2, rkmppenc の3つの deb パッケージをインストールすれば、比較的簡単に利用できるような状態にできたのではないかと思います。Build.xx.md もそれに合わせて修正してあります。

手元の Ubuntu 22.04 LTS 環境では動作していますが、Ubuntu 20.04 LTS での動作は未検証です。また、クリーンな環境で試せているわけではないので、もしかすると他にも依存ライブラリが必要かもしれません。

rigaya commented 1 year ago

パッケージ作成のpull request作成いただきありがとうございます。

後回しになっていたので大変助かります。VCEEncのままだった箇所なども細かく修正いただき、ありがとうございました。スクリプトやパッケージ作成方法に関しては、いただいたpull requestで全く問題ありません。

ただ、下記パッケージをインストールして

こちらの Ubuntu 20.04 環境で動作確認しましたが、mppの初期化関連の箇所でSegmentation faultで落ちてしまう状況です。自ビルドの librockchip_mpp.so.0 に差し替えると動作するため、いまのところ librockchip-mpp1_1.5.0-1_arm64.deblibrockchip_mpp.so.0 の問題のように思います。もちろんもしかするとわたくしの環境のせいかもしれないず、申し訳ないのですが…。

そこで1点気になったことについて質問なのですが、 librockchip-mpp1_1.5.0-1_arm64.deb でインストールされるのは下記でよいのでしょうか (ちょっと日付が古そうですが関係ない…?)

rigaya@rock-5b:~$ dpkg-deb -x ./librockchip-mpp1_1.5.0-1_arm64.deb ~/librockchip-mpp1
rigaya@rock-5b:~$ cd librockchip-mpp1/
rigaya@rock-5b:~/librockchip-mpp1$ cd usr/lib/aarch64-linux-gnu/
rigaya@rock-5b:~/librockchip-mpp1/usr/lib/aarch64-linux-gnu$ ls -l
合計 1856
lrwxrwxrwx 1 rigaya rigaya      20  5月 20  2021 librockchip_mpp.so -> librockchip_mpp.so.1
-rw-r--r-- 1 rigaya rigaya 1897552  5月 20  2021 librockchip_mpp.so.0
lrwxrwxrwx 1 rigaya rigaya      20  5月 20  2021 librockchip_mpp.so.1 -> librockchip_mpp.so.0

またもう1点、細かな点かもしれませんが、作成いただいた librga のパッケージについて質問・確認させてください。

librgaの(パッケージの)バージョンを 2.2.0 とされていますが、 1.9.1 のほうが適切ではありませんでしょうか?

おおもとのリポジトリを見ると、最新版は 1.9.1 であるとの記載があります

また、rkmppenc --check-rgainfo を呼ぶと、librgaのquery APIで取得した情報が確認できるのですが、今回作成いただいたパッケージを実際にインストールして実行すると下記のように出力されます。

rigaya@rock-5b:~$ rkmppenc --check-rgainfo
rga_api version 1.9.1_[4]
RGA vendor            : Rockchip Electronics Co.,Ltd.
RGA_api version       : v1.9.1_[4]
RGA version           : RGA_2_Enhance RGA_3
Max input             : 8192x8192
Max output            : 8128x8128
Byte stride           : 16 byte
Scale limit           : 0.0625 ~ 16
Input support format  : RGBA_8888 RGB_888 RGB_565 RGBA_4444 RGBA_5551 YUV420_sp_8bit YUV420_sp_10bit YUV420_p_8bit YUV420_p_10bit YUV422_sp_8bit YUV422_sp_10bit YUV422_p_8bit YUV422_p_10bit YUYV422 YUV400/Y4
output support format : RGBA_8888 RGB_888 RGB_565 RGBA_4444 RGBA_5551 YUV420_sp_8bit YUV420_sp_10bit YUV420_p_8bit YUV422_sp_8bit YUV422_sp_10bit YUV422_p_8bit YUYV420 YUYV422 YUV400/Y4
expected performance  : max 4 pixel/cycle

もし、私の誤解でしたら申し訳ないです。

2.2.0 という数字は、 Rockchip_Developer_Guide_RGA_EN.md の "Current Version: V2.2.0" (更新日: 2022-09-15)が出所かなと推察いたしますが、Rockchip_FAQ_RGA_EN.md を確認すると、"Current Version: V1.1.0" (更新日: 2022-12-21) となっており、これはドキュメントのバージョンを意味しているのではないかと思います。

tsukumijima commented 1 year ago

すみません!色々忙しく返信が遅れてしまいました…。

こちらの Ubuntu 20.04 環境で動作確認しましたが、mppの初期化関連の箇所でSegmentation faultで落ちてしまう状況です。自ビルドの librockchip_mpp.so.0 に差し替えると動作するため、いまのところ librockchip-mpp1_1.5.0-1_arm64.deb の librockchip_mpp.so.0 の問題のように思います。もちろんもしかするとわたくしの環境のせいかもしれないず、申し訳ないのですが…。

少なくともこちらの Ubuntu 22.04 環境では librockchip-mpp1_1.5.0-1_arm64.deb をインストールして動いているんですよね…。 librga の方はビルド済みバイナリをどうにかして .deb にパッケージングするために諸々手を加えていますが、mpp に関しては元々あった .deb のビルド用データを活用して GitHub Actions でビルドしているだけなので (こちら) 、少なくともビルド環境はクリーンだと思います。

こちらでは再現できていないので、tsukumijima/mpp の Actions ワークフロー内でのビルド手順を変更するなど、お手数ですがそちらで色々試していただけないでしょうか…?

もしかすると、librockchip-vpu も同じビルドでインストールしておかないとダメだとかがあるのかもな…?とは思いました。内部で参照されてるかはわかりませんが…。

そこで1点気になったことについて質問なのですが、 librockchip-mpp1_1.5.0-1_arm64.deb でインストールされるのは下記でよいのでしょうか (ちょっと日付が古そうですが関係ない…?)

インストールされるファイルに関しては dpkg -c xxxx.deb で確認できると思います。

pi@NanoPi-R6S:/Develop$ sudo dpkg -c librockchip-mpp1_1.5.0-1_arm64.deb
drwxr-xr-x root/root         0 2021-05-20 10:40 ./
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/lib/
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/lib/aarch64-linux-gnu/
-rw-r--r-- root/root   1905760 2021-05-20 10:40 ./usr/lib/aarch64-linux-gnu/librockchip_mpp.so.0
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/share/
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/share/doc/
drwxr-xr-x root/root         0 2021-05-20 10:40 ./usr/share/doc/librockchip-mpp1/
-rw-r--r-- root/root      2686 2021-05-20 10:40 ./usr/share/doc/librockchip-mpp1/changelog.Debian.gz
-rw-r--r-- root/root      2050 2021-05-20 10:40 ./usr/share/doc/librockchip-mpp1/copyright
lrwxrwxrwx root/root         0 2021-05-20 10:40 ./usr/lib/aarch64-linux-gnu/librockchip_mpp.so -> librockchip_mpp.so.1
lrwxrwxrwx root/root         0 2021-05-20 10:40 ./usr/lib/aarch64-linux-gnu/librockchip_mpp.so.1 -> librockchip_mpp.so.0

私の環境ではこのような結果になりました。 日付が 2021 年な件ですが、どうも debuild (?) はファイルの日付を changelog ファイルのうち一番新しい日付にするようで(ついでにバージョンデータもそこから取得される)、それが反映されているだけだと思います。日付もピッタリ一致します。

librgaの(パッケージの)バージョンを 2.2.0 とされていますが、 1.9.1 のほうが適切ではありませんでしょうか?

それちょっと謎なんですよね…。

この 2.2.0 という表記は、Firefly の RK3588 向け librga (ソースあり版の最新、ただし少し古い) の debian/changelog ファイルに由来しています。

元々 airockchip で公開されている「最新だがソースコードがない」版のリポジトリには Deb パッケージを作成するためのデータ等がありませんでした。一方上記のような「少し古いがソースコードがある」版のリポジトリには mpp と同様に Deb パッケージを作成するための debuild 向けデータが入っているので (debian/ 以下)、それをそのまま持ってきた上で、ソースコードがない事でエラーになる部分を諸々を修正したものが tsukumijima/librga になります。

コミッターが rock-chips.com の人になっていること、Firefly 側での独自変更?には firefly の suffix がついていることから Rockchip の内部リポジトリでも Debian パッケージとしては少なくとも 2.x 系ということになっていそうです。 ここを書き換えて 1.9.0 などにすることもできなくもなかったのですが、公式で一応そういうバージョン表記なこと、rockchip-multimedia の PPA で提供されている ビルド済み librga もバージョン 2.2.0 となっていることから、こちらの方が無難かなと思い、changelog はそのままにしています。

余談ですが、この PPA の librga 自体 Firefly の RK3588 向けブランチをビルドしたものらしく、バージョン表記に含まれるコミットハッシュからして、https://gitlab.com/firefly-linux/external/linux-rga/-/tree/c1d5c71569d8944dbc0b875a54181402caf3971f 時点のソースコードをビルドしたものと思われます。

rigaya commented 1 year ago

ご返信ありがとうございます。また、メインブランチの更新にも追従いただき感謝いたします。

mppがこちらでSegmentation faultで落ちてしまう問題は、いろいろ調べて下記リンクの件であると確認できました。 https://github.com/rockchip-linux/mpp/issues/356

リンク先の通り、下記 udev rules を適用し、/dev/dma_heap/[ system-dma32, system-uncached, system-uncached-dma32 ] に権限を付与することで、問題を解消できました。

KERNEL=="mpp_service", MODE="0660", GROUP="video" RUN+="/usr/bin/create-chromium-vda-vea-devices.sh"
KERNEL=="rga", MODE="0660", GROUP="video"
KERNEL=="system-dma32", MODE="0666", GROUP="video"
KERNEL=="system-uncached", MODE="0666", GROUP="video"
KERNEL=="system-uncached-dma32", MODE="0666", GROUP="video" RUN+="/usr/bin/chmod a+rw /dev/dma_heap"

こちらでは、問題の発生する rockchip-linux/mpp@062c1752 より前のmppをビルドして使用していたことから発生していなかったようです。お騒がせしました。

librgaのパッケージのバージョン番号についても、ご説明いただきありがとうございました。2.2.0となっている経緯について理解できました。なかなかややこしいですが、そういった事情ですと2.2.0が無難そうですね。

こちらでの問題点・疑問点が解消できましたので、マージさせていただきました。pull requestいただき、ありがとうございました!