[随笔] 续：关于我在机房安装Arch Linux – Ghost-Face

背景

これは、Arch Linux をコンピュータルームにインストールするシリーズの 3 番目の記事です (うれしい、おめでたいです)
エッセイ: コンピューター室に Arch Linux をインストールしたことについて
エッセイ: チュートリアル
私が言及したチュートリアルで気づくのは難しくありません。

私は主に、KDE または Niri+DMS という 2 つのデスクトップ環境を推奨します。どちらも Shorin スクリプトでサポートされています。
国産以外のグラフィックカードをお使いの方へ！ニリを試すことができます。
国内グラフィックカードユーザー向け！必ず KDE を使用してください。そうしないと悲惨な結果になります。
では、なぜそんなことを言うのでしょうか？
実際、これは国産のグラフィックカードが国産以外の Linux のサポートが非常に不十分であり、自分でコンパイルする必要があるためです。それでもコンパイルが成功しない可能性があります。たとえば、私のコンピュータのグラフィックカードは Linux カーネルバージョン 7 までをサポートしていますが、Arch は 7.2 カーネルを使用しています。カーネルのバージョンをダウングレードしても、ローリングアップデート中にドライバーが破損する可能性があります。
KDE は画像を解決するために CPU をサポートしますが、Niri はグラフィックカードを必要とするため、国内のグラフィックカードを搭載したマシンまたはグラフィックカードを搭載していないマシンに KDE をインストールしてください。

しかし、一日試した結果、国産グラフィックスカード（ここでは具体的にはGlenfly Tech Co., Ltd.のArise1020グラフィックスカード）のドライバーが実際にArchで使用できることがわかりました。
最終的な結果は、Niri+DMS を WM として使用することに成功しました。(ちなみに私はArchへの国産グラフィックスカードドライバの移植に初めて成功した人になりました)
もちろん、現地の環境に慣れない部分も必ずあります。これはすべての Chrome ベースのアプリ (QQ や TRAE に代表される多数の Electron フレームワークアプリを含む) は、GPU アクセラレーションを使用できません。その理由については後ほど説明します。
(もちろん、これは Niri の外観や、これをいじる私の最大の動機である KDE の破壊には影響しません。 ~~私はビューティーコントロールであることを宣言します~~）

鎧を積み上げています。これが私が嘘をついていないことを証明する写真です。

分析する

では、なぜグラフィックカードドライバーが使用できないと言ったのですか？公式 Web サイトを開くと、このグラフィックスカードがサポートする Linux カーネルの最高バージョンは 7.0 であり、国内の Linux のみを十分にサポートしていることが簡単にわかります。
私のArchカーネルは7.2です。各 Linux カーネルは一部の API を変更するため、7.0 ドライバーを直接インストールすると、システムのフリーズ、黒い画面、ログインインターフェイスに入れないなどの深刻な問題が発生します。
次にソースコード解析に入ります。このプロセスには、エージェントと私で合計 3 時間以上かかりました。 (注: 技術的な部分を読みたくない場合は、Niri の部分まで下にスクロールしてください)

ソースコード分析

始める前に、明確にしておく必要がある事実は、グラフィックスカードやドライバー自体には何も問題がないということです。欠けているのは、ドライバーとカーネルの間の接続です。うまくマッチングしないかもしれないAPI インターフェースが一致するかどうかは、すべてカーネル API とドライバーに依存します。
このための最初のステップは、ドライバーのソースコードを入手することです。これは、次のコマンドを使用してドライバーを解凍することで入手できます。 bsdtar ：

mkdir -p ~/arise-pkg && cd ~/arise-pkg
bsdtar -xf gf-arise-linux-graphics-driver-glvnd-dri_25.00.55_amd64.deb
mkdir data && bsdtar -xf data.tar.xz -C data

解凍後に得られたのはソースコードだったので、それを確認し始めました。
私はまずエージェントに一連のトラブルシューティングを行うよう依頼しました。心配していた7.2で修正されたスケジューラドライバは全く使用されませんでした。

それで私は喜んでコンパイルし、エラーを報告しました。
したがって、実際の問題は Linux カーネル 7.1 で発生します。
7.1握り struct drm_atomic_state 全体の名前が変更されました struct drm_atomic_commitその後にアトミック操作関数のバッチが続きます。これはグローバルなリファクタリングであり、DRM サブシステム内のすべてのドライバーをそれに応じて変更する必要があります。 Grenfell 25.00.55 は 4 月にリリースされ、バージョン 7.0 に適応されているため、これらの位置は当然エラーとして報告されます。 1 つずつ変更すると、50 以上のファイルを変更する必要があり、OIer にとってはあまりにも洗練されていません (また、次回カーネルを変更するときにも同じ作業を行う必要があります)。

したがって、それを前処理段階でマッピングし直すこともできます。

新しいものを追加しました linux/gf_compat_71.h、使用 #if LINUX_VERSION_CODE >= KERNEL_VERSION(7,1,0) グループをまとめる #define、バンドル drm_atomic_state この型名と、それに応じて名前が変更されたいくつかのアトミック関数はすべて新しい名前にマップされます。それから Makefile リガ旅行 -includeこれにより、ドライバーツリー全体が統一された方法でこのヘッドを使用できるようになり、古いカーネルには副作用がありません (条件付きコンパイルが使用されるため)。

また、より隠されたものを修復しました: カーネル 7.1 以降 strncpy ドライバー内で削除されました os_interface.c の gf_strncpy そして gf_trace.h の 2 つのトレースイベントは次のように置き換える必要があります。 strscpy。この変更により、落とし穴も回避されます—strncpy ソース文字列の長さがバッファと等しい場合は埋め込まれません。 \0、strscpy ミーティング。
もちろん、変更が完了した後も使用でき、コンパイルは非常にスムーズです。

コンパイル、ロード、ライト

DKMS 側ではほとんど変更が必要ありません。
dkms.conf gcc バージョン検出機能が付属しています (カーネルのコンパイル時に使用される gcc と一致します)。 Arch のシステム gcc はカーネル gcc です。コンパイルを続けることができます。

sudo cp -a data/usr/src/arise-25.00.55 /usr/src/
sudo dkms add arise/25.00.55
sudo dkms build arise/25.00.55 -k "$(uname -r)"
sudo dkms install arise/25.00.55 -k "$(uname -r)"
sudo modprobe arise

ここの最後の文は、グラフィックスカードにレンダリングを引き継ぐように要求するコマンドです。画面がしばらく真っ暗になりますが、すぐに回復します。
関連するログは次のとおりです。

[    8.682454] arise 0000:01:00.0: [drm] Registered 10 planes with drm panic
[    8.688578] [drm] Initialized arise 37.0.85 for 0000:01:00.0 on minor 1
[    8.768027] arise 0000:01:00.0: [drm] fb0: arisedrmfb frame buffer device

チェックも簡単です。

ls /dev/dri/                 # renderD128 出现了
glxinfo -B | grep renderer   # OpenGL renderer string: Glenfly Arise1020

OpenGL 4.5、GLES 3.2KDE は llvmpipe から実際のグラフィックスカードに変更されました。この時点で、マシンには実際にグラフィックスカードが搭載されています (もちろん、これは Niri を使用できることを意味します!!)。

ユーザーモード

カーネル部分が完了したら、次にユーザーモードアプリがレンダリングに GPU を使用できるようにします。

カーネルはレンダーノードを取得するためにのみ点灯します。アプリケーションを実際に高速化するのは、クローズドソースのユーザー状態ライブラリです。デビアン postinst インストール中にいくつかのことを実行します。 Arch は手動でコピーする必要があり、どれも見逃すことはできません (どうしてこれを知っているかは聞かないでください)。

1 つ目は、GLVND のベンダー構成です。usr/share/glvnd/egl_vendor.d/10_arise.json 内部 library_path フィールドは、 ""。これを入力しない場合、EGL はローリングログを dlopen し、ドライバーのインストール後も llvmpipe が実行されます (エラーは報告されません)。

sudo sed -i 's|"library_path" : ""|"library_path" : "libEGL_arise.so.0"|' \
  /usr/share/glvnd/egl_vendor.d/10_arise.json

これを修理したら逃げられると思いますか？いいえ、いいえ、ライブラリのパスが間違っています。 Debian の multiarch ディレクトリはプレフィックスを取り除く必要があります: ライブラリはすべてそこにあります usr/lib/x86_64-linux-gnu/ 以下、アーチは usr/lib/ 直接タイル張りします。そして arise_gbm.so 入っている必要があります /usr/lib/gbm/メサと dri_gbm.so 同じディレクトリ内に dri_gbm.so と同じ ABI があるため、libgbm は追加の構成を行わなくても、DRM ドライバー名に基づいて自動的にそれを検出できます。

最後に、X11 では GLX ベンダーを明示的に指定する必要もあります。usr/share/X11/xorg.conf.d/10-arisegpu.conf 内部 MatchDriver "arise" その後に行を追加する必要があります。

Option "GlxVendorLibrary" "arise"

やっと sudo ldconfig +再起動、eglinfo -B ここのベンダーはGlenflyになります。

加えて、etc/modprobe.d/arise_gfx.conf バッグの中に入っています空のファイル、usr/share/initramfs-tools/hooks/arise これは Debian 専用です。独立したグラフィックスには初期の KMS は必要なく、どちらも Arch ではスキップできます。

すべての Chrome アプリケーションが GPU アクセラレーションをオンにできないのはなぜですか?

インストール後、最初は問題ないように見えますが、QQ または TRAE を開くと画面が吹き飛ばされます。
それで何が問題なのでしょうか？ CoreDump を直接実行するだけです。

#0~17  libariseGLSLCompiler.so   段错误
#17    OGL_Compiler_CompileShader
#18    arise_vndri.so
#20    fast_data_types.so         ← kitty 在编译着色器

クラッシュするのは、グラフィックスカードドライバーに付属するクローズドソースの GLSL コンパイラーです。
Chrome/Electron システムは内部で ANGLE + Skia を使用します。このような複雑なシェーダの場合、Glenfield のサポートは適切ではないため、これが理由です。このカードのクローズドソース GL スタックは、Chromium のシェーダと互換性がありません。。

どうすればいいでしょうか？コマンドライン起動パラメータを追加するだけです。.desktop 中国とカナダ --disable-gpuそれでおしまい。

電子用途には使用しないように注意してください。 --use-angle=swiftshaderSwiftShader は純粋な CPU ラスタライズであるため、ウィンドウが表示されるとすぐに CPU が起動します。比較して --disable-gpu Skia の軽量ソフトレンダリングを使用すると、CPU 曲線がより平坦になります。

ニリ+DMS

ここではこれ以上のテクニカル分析は行わないことに注意してください。これは誰もが聞きたがる段階です。
以前は、グラフィックカードが使用できないという理由だけで Niri を使用できませんでした。グラフィックスカードがあり、KDE が Niri と共存できるようになったので、インストールしてみませんか?
現在の結果は次のとおりです。