みなさまお元気ですか

暑さも少し落ち着いてきて、ようやく外に出てもいいかなという気になってきました。季節の変わり目体調には気をつけていきたいですね。

実は、一ヶ月くらい前にLinux PC を自作してMac から移行しました。そのときの考え、その後の感想を残しておきます。

また、学んだことや作業のログを細かく残しておきたいと思います。（どこかの誰かが不安に思ったときに同じ失敗や疑問を経験した人がいて安心してもらえたら嬉しい）

目次

• Mac をやめるきっかけ、経緯
• Ubuntu に移行して一ヶ月の感想
• おまけ1: どのような PC になったか
• おまけ2: 事前に学んだこと
• おまけ3: PC の組み立て
• おまけ4:Ubuntu のセットアップ

加筆/修正

• 指摘のあった誤字を修正
• NVEnc について誤った内容があったので修正
• レイテンシという単語の使い方が一部曖昧だったので修正

Mac をやめるきっかけ、経緯

この 10 年くらいiOS 開発に必須ということもありmacOS を使っていました。

性能的には困ってない

今使ってるMac はiMac 2020 でもう 4 年以上前のになるんですけど、性能的にはあまり困ってない。個人的には「10 年くらい困らなさそうだな〜」なんて思ってました。

これだけ長く一つの PC で困らないのは性能の向上が需要を上回ったというのもあるんですが。特に近年は性能がいるタスクをクラウドでやるようになった というのも大きいかもしれません。ゲームとかやらないので、低レイテンシ（低遅延）であることを求められる高度な処理があまりないというのもあるかもしれないです。

でも買い替えることに...

買い替えを意識したきっかけは、 2024/03/08 に出された tensorflow のこのアナウンスだった。

機械学習の開発が不便になるのは相当大きいことだった。

また別件ですが、あるフォーラムで「誰がこれから無くなるx86mac に時間をかけたいんだ？（意訳）」ってことを言われた り、まあx86mac は何かとコミュニティに見捨てられた環境であったりもした。

ということで、本気で買い替えを考え始めた。

まず、最近の PC にやらせるタスクを整理してみる。特にクラウドを使えるか、ローカルの PC でやる必要性があるか を考えた。

必要なローカル PC の性能って？

以下のように、低レイテンシ（低遅延）を求められるものやデータ量が多いもの、その中で計算量が多いものを中心にローカル PC の性能を決めればいいと個人的には思っている。

PC で何をするんだっけ？

で一般的な PC でやることを書き出して、自分が次の PC に必要だと思う部分を赤色でしめした。

これはあくまでも自分にとってだけど、次の PC は ML の推論、動画編集、動画エンコードに構成していけばいいことがわかった。

CPU の性能はいらないかも

上のことから、次のパソコンはGPU やアクセラレータが重要で CPU の性能は必要なさそう。今後はなるべくグラボなどをアップデートしながらその他のパーツを長く使うことを意識したい。

10 年使える PC にしたい

必要なソフトウェアが提供され、グラボの交換ができれば今のMac は性能的には 10 年は使えた のではないだろうか。

自分が今買い替えを検討している理由は、自分の PC の拡張性の問題と、x86mac の「ユーザ数の先細り」の問題なのだ。

次の PC は 10 年買い替えないでいいものにしたい。そう思った。

10 年使える PC の要件とは？

その上で、 10 年使える PC とはどのようなものだろうか。

• 大きめのタスクは基本クラウドで対応し、ローカル向けのタスクのみを考慮した設計にする
• 未来の ML の推論や動画のコーデック必要になるGPU やアクセラレータの拡張性を持つ
• ユーザの規模がそれなりに大きい OS やハードウェア規格
• 買い替え乗り換えサイクルが遅い OS やハードウェア規格（サーバで使われるものは特に遅い）

Linux にする

上のようなことを考えるとMac はよくないだろう。GPU の増設すら難しく拡張性もない。買い替えサイクルも早い。

結論としてLinux。10 年の安定を手に入れたい

ディストリビューションの選定

まず、候補としてはサーバサイドでよく使われるUbuntu,Debian,Redhat系 、最近よく名前を見る ArchLinux このあたりで悩んだ。

調べたところRedhat 系はUbuntu,Debian, ArchLinux と比べてあまりユーザコミュニティの活気がない気がしたのでRedhat 系は一旦除外。

Debian とUbuntu だと「ユーザの規模」や「オープンソース以外のパッケージの存在」からUbuntu が良さそうだと思った。

ArchLinux はどうか

ArchLinux のローリングリリースはめちゃくちゃいいなと思った。Ubuntu だと「Ubuntu 24.04 だと〇〇」のような議論になりがちだけど、ローリングリリースだとそうはならないだろう。ちゃんとした要件を議論できそう。

実際、ネット上の有用な情報は ArchLinux のコミュニティやWiki から得られることが多いように思う。

結論としてはUbuntu

上のように ArchLinux にかなり魅力を感じた。だが色々悩んだ末Ubuntu を選択した。

理由はUbuntu が「営利企業が多く使っているディストリビューション」であり市場的に保守される可能性が高いこと。

ただ、 ArchLinux は本当に良さそう。次に OS を入れ替えるときには ArchLinux を選ぼうと思った。

Ubuntu に移行して一ヶ月の感想

Ubuntu に移行して良かったこと、良くなかったことを書いておく。

良かったこと

ビルド難易度が低い

github とかにあるようなオープンソースのツールのビルドの成功率も問題解決も圧倒的に楽になったと感じる。

これは何故なのかわからない。自分の使うツールの特性か、それともオープンソースの開発者はLinux を使っている人が多いのだろうか。

Mac のときは「XCode で入れられた〇〇」と競合するみたいなのがあったりした。 clang とかはLinux でもMac でもそう変わらないと思う。

あと特にGoogle のオープンソースライブラリのビルドはLinux になってかなり楽になった。Google が使ってる bazel はその特性からプロプライエタリなものを混ぜると使いにくい。

自分で修正しやすい

プロプライエタリな製品は不具合があまりオープンに議論されない。アカウントマネージャやソリューションエンジニアとの間でクローズドで解決することが多い。

オープンソースなソフトウェアは議論のログやパッチがオープンにされることが多く、それらの資産が個人にも届く形で残ることが多い。それによって不具合があっても個人で修正できることが多い。

逆にオープンソースであっても大きなコミュニティがなくなれば急速に問題解決が難しくなると思われる。企業も含めて多くのユーザが使っていることが問題の解決をかんたんにしている。特に問題があったときに企業で使う人たちの上げる issue に助けられることが多い。

「OS」の粒度

他の環境では「OS」とひとまとめにされる部分も細かく分かれていて、それらのコンポーネントの依存関係によってソフトウェアの要件や前提条件を詳細に認識しやすい。

たとえばGUI アプリケーションへの入力がおかしければ以下のようにコンポーネントを分けて考えることができる。

• Gtk や Qt などのライブラリ
• Mutter などウィンドウマネージャ
• デスクトップシェル
• デスクトップポータルデーモン
• IME デーモン
• DBus
• ディスプレイサーバ

ユーザが認識できるコンポーネントの粒度が細かいので、それぞれの境界でどのような入出力があったかを調べることで問題の原因を特定しやすい。

たとえ、画面全体がフリーズしてもテキストモードに移行してディスプレイサーバを再起動することもできる。これもちゃんとユーザがその境界を認識できているからであると思う。

過去Mac を使っているとき、よくわからないデーモンがあって「それが悪い」と決めつけるみたいなことをよくしてしまっていた。

設計やコンセプトが読める

多くの部外者が関わるので開発者が設計やコンセプトや妥協点を残していることが多い。開発者に直接話しかけることもできる。

プロプライエタリなソフトウェアだと「なんでこうなったの？」っていうのが分からずモヤモヤすることが多かった。また、方針が分からず、今後使い続けるか判断する材料が乏しかったというのがあった。

クラウド環境と近い

個人的な指向ではあるかもしれないけど最近のML のタスクは「短時間で単価の高い高性能なクラウド環境でやる」っていうのが良いと思っていて、頻繁に Cloud TPU などを使っている。

Cloud TPU の一番安いインスタンスだと Docker コンテナとかは使えず、ある程度固定された環境だったりする。これまでローカルとの違いでデプロイした先で挙動が違ったりすることがたまにあった。

クラウドはLinux を使うことがほとんどなので、ローカルもLinux だとやっぱり便利だと思った。

良くなかったこと

ファイル名の制限

Linux で一番困ったのがファイル名が 255 バイトだとカーネルに書かれてしまっている。これには自分はかなり困ってしまった。

Mac やWindows でも文字数制限はある。だがLinux では文字数制限ではなくバイト数制限なので特にマルチバイト圏の人たちが困る

ただ 255 バイトというのは日本語でもそれなりの情報を書くことができる。なので新規にLinux を使う人は困らないかもしれない。ただ、これまでの環境の大量のファイルを単純にLinux に移行できないのはそれなりに大変だった。

ファイル管理GUI

Mac の Finder のようなよくできたファイル管理アプリはLinux にはない

Finder は素晴らしいアプリだと知った。カラムのソートとか、カラムで扱える情報量とか、最後に開いた日時とか、ドラッグドロップでできることの多さとか。とにかく洗練されていたと気がつくことができた。

マルチメディア系のソフトが弱い

要はAdobe CC がないって話である。他にもWindowsMac だけにツールを提供している企業は多い。特にクリエイター系のツール。

（ただ俺達には gstreamer があり、 mediapipe があり、オープンな ML ネットワークがある。コードを書く前提なら、クリエイティブな作業を自動化や効率化させるというところではLinux のほうが頑張れる！！！！（といいな））

ベンダロックされたときに困る

iOS のアプリの開発とか開発環境がロックされるケースは困る。ビジネスツールでWindows 系しか使えないものもあるんだろうと思う。

なので会社でMac を使うことになりがちである。

システム依存とアプリバンドル

普通にソフトウェアをビルドして導入すると、 ldconfig を通じてシステムの DLL を使うことになる。まあそれでもいいのだけど、そのシステムの DLL 、厳密に想定されたものですか？ という問題は残る。

根本的に解決するとしたら、すべてのライブラリがバンドルされたバイナリとしての配布するとか、 bazel のように依存関係の一致を hash 値で確認してビルドされることが一般的になるのがいいことなのかもしれない。

ただ、それが幸せかはわからない。

Linux でも Flatpak や Snap や AppImage などがあるがWindows やMac のそれと比べると若干使いにくい（ファイル選択ウィンドウとか）

今後 AI と OS が密結合になったら困る

Copilot + PC のようなものが業務効率に直結するようになったら、もうLinux はかなり厳しいだろうなとおもう。そうなったら Near PC Computer としてLinux をローカルに置いて AI 指向の OS を使うことにしよう。

次に「Linux やめた」となるとしたらこの方向性の可能性が高そう。

なんとも言えないところ

AppleScript と GLib

GLib は C 言語のライブラリで、他の言語からも使いやすい形で DLL (GLib Module と呼ばれる) のエクスポートができたり、 C 言語の枠内でオブジェクト指向プログラミングすることができたり、GUI と連携するイベントドリブンなプログラムをかけたり、まあプログラミング観点ではAppleScript というよりObjective-C に似たものだ。

ただ、使う場所という点でいうと AppleScirpt と似ている。

Mac で AppleScirpt やAutomator を書いてたくらいにはこれから GLib を日常的に使うことになるんだろうんなと思っている。

GLib は gstreamer とかでも使われてるし、勉強してもいいかなとは思える。

問題がちゃんと起きる

頻繁ではないがMac と比べると問題が起こる頻度は高い。

画面が固まってディスプレイサーバを再起動したり、 Files が落ちたり、システムのデーモンが起動しなかったり、グラボつけたら udev がX11 に勝手に変えていろいろなアプリを設定しなおしたり、とにかく問題は起こる。

ただ、自分はこれらの問題を愛せている。なぜなら原因がちゃんと分かるから。

原因がわからないと影響範囲が確定できずに疑心暗鬼になる。原因がわかれば「ちゃんと想定した問題が起こっている」とすら思える。そういうものだと思ってる

総評

全体としてはかなり良かったと思っている。

まず、プログラミング環境や実験環境として最高であること。

そして、最新のオープンソースのソフトウェアを導入するのが楽しくなったこと。そして、問題を愛する心が生まれたこと。

Linux デスクトップ楽しいですよ！みなさんも使ってみませんか？

（ここからはおまけです）

おまけ1: どのような PC になったか

拡張性が大切だ。市販品はケースは省スペースに作られていて不器用な自分には拡張が少しむずかしそうに思えた。

CPU は弱くてよく PCIe スロットへのアクセスは重要だ。

いろいろこだわりがあるので、パーツを選んで自作することにした

ハードウェア構成

備考欄に選定したポイントを書いた。

ほぼ完成したときの写真

ほぼ完成した感じはこんなの。

正面	側面	裏面

とても拡張性が高くてケーブルの配線とかが簡単だった。今後、容積がかなり大きいのでどんな機器でも収まりそう。

その他、買ったもの

• HDMI ケーブル
  • Dell のディスプレイについてなかったので
• CPU グリス
  • MX-6
  • 下手に塗ってもショートしない電気を通さないやつ

家にあって便利だったもの

• 電源ジャンパピンを短絡させる実験用スイッチ
  • フロントパネルに接続する前にマザーボードの動作確認するときにあると便利
• ビープスピーカ
  • 家にあったというかケースについてた
  • マザーボードがエラーを知らせる一つのインタフェースとして結構便利
  • デバッグ LED があればいらないっちゃいらない
• エアダスター
  • ホコリを飛ばすのにめちゃくちゃ使った
• キムワイプと無水エタノール
  • ちょっと汚れが気になったときに使った
• クロス LAN ケーブル
  • 古いパソコンと直接繋げられる。Wifi より圧倒的にレイテンシが低い。大量のファイルとかをやり取りするのにすごく便利だった。これを使って古いパソコンをNAS として使ってる、めんどくさいデータ移行を後回しにできた。
• キーボード、マウス
  • 14年前の HKK とMicrosoft のマウスが動いた

買ってないけど買わないといけさそうなもの

• ウェブカメラ、マイク
  • たぶん zoom とかする必要も出てくるだろうし何か買わないとなあ

パーツ購入時に大変だったこと

初期不良を期間中に確認するためにある程度価格を度外視してそれぞれのパーツが近い日時に送達されるように PC ショップを選ぶ必要があった。これは、一台目の自作の場合はある程度しょうがないことかもしれない。

数時間で値段がコロコロ変わる。 PC パーツの最安値をみていると本当に頻繁に変わる。これを追っていたらいつまでも買えないので、価格はある程度安ければあまり気にしないほうが良い。コストを考えずに「高くてもいいや」「失敗したらもう一個買うしいいや」などとにかく心理的な安全性を高める考え方をした。

おまけ2: 事前に学んだこと

会社でサーバを組み立てたり拡張したりというこをやったことはあったが、自分一人で PC の構成を考えたり組み立てたりするのは、思えば初めての経験だった。なので、色々と座学をした。

ATX (ケース、マザーボードのサイズ、電源の容量と特性）

• ATX specification 2.2
  • Intel が出してるマザーボードの仕様書。
  • マザーボードやそれを拡張するパーツやコネクタがケースに収まり、外部との接続性が担保されることが目的。
  • マザーボードの寸法やスロットの位置、推奨される機能を示している
  • ATX,microATX などがある
  • まずマザーボードがATX の仕様に従ったものかどうか決めるところから自作 PC の設計を始めるのが良い。ATX 以外にも Mini ITX などがある
• ATX 3.1 Power supply design
  • 上で述べたATX は、電源に関する仕様も定義している
  • 「ATX 電源」とは、この仕様にのっとた PC 用の電源であることを示している
  • 電源に関しては寸法だけではなく、電源コネクタの形状、ピンアサインを仕様化している。
  • 電源ユニットが持つべき電気的特性や機械的特性についても仕様化している。
  • ATX power supply design は 2.x から 3.x へ最近 20 年ぶりにメジャーバージョンが上がった。
  • 3.0 ではGPU などが発するスパイク電流への耐性を仕様の中に盛り込んだ。
  • 3.1 では、新たにGPU などの PCIe 機器に 600 W という大電力を供給するためのコネクタを定義した（16 ピンコネクタや 12VHPWR と呼ばれる。このコネクタやケーブルに対応していることを PCIe 5.0 対応電源と呼んだりもするようだ）
    • 市場の製品は従来の PCIe 補助電源でも使えるようになっているが、将来的に 12VHPWR が必須となる時代が来るかもしれない
  • ATX Power supply design の仕様を見ると現代ではほとんど +12V レーンが電力供給のメインであることがわかる（そのため +12V だけを供給してシンプルにするための ATX12VO などの仕様もでていたりもする）。なので、電力や電流の計算は主に +12V レーンに対して行えば良い。他の電圧 5V レーンや 3.3V レーンは 60W くらいあれば十分ではないかと思う。
    • PCIe 補助電源は 12V しか使わない
    • 5V レーンはSATA や USB への給電に使われる
    • 3.3V レーンは古い機器にしか使われていない
    • CPU やメモリへはマザーボードのVRM によって 12V レーンから給電されている（と思ってる）
  • なので単純に +12V レーンの容量 = 電源容量と考えてほぼ問題はない
  • あとはATX Power supply design 3.1 準拠が必要かどうかを検討

CPU

• 電子回路的に CPU の仕組みを理解する
  • ZEXぶらっく さんの「CPU」を「トランジスタで」作ろうシリーズが非常にわかりやすい
  • www.youtube.com
• 周波数とコア数
  • プログラマ的にはシングル性能よりは、マルチコア全部使った性能が重要でその辺をどう選ぶか
    • タスク全体として性能が足りなかったらコードをマルチスレッド化していけば解決できることが多い
    • シングル性能には限界はあるけど、マルチ性能はXEON とか ThreadRipper でかなりスケールできる
  • GPU などのアクセラレータに載せづらい処理がどのくらいタスクとしてあるのかも考える
• 周波数とコア数以外の部分
  • 世代が上がっていれば効率的なんだろうとざっくり理解は正しい（以下に続く内容）
  • メモリとの通信による遅延をどのくらいカバーできるか
    • L1/L2/L3 キャッシュ
    • アウト・オブ・オーダー実行（メモリを待ってる間に、依存しない命令を先に実行してしまう）の賢さ
  • 後続の命令を効率的に予測し実行する
    • 命令スケジューリング
    • 分岐予測
  • SIMD 命令のサポート
    • 一つの命令で複数のデータを演算する命令
  • 命令の多重化
    • スーパースカラアーキテクチャ
    • ハイパースレッディング
• 演算ユニットはマイクロコードを実行する
  • x86 の命令は更に細かいマイクロコードにデコードされて実行される
  • マイクロコードはマザーボードメーカーがBIOS のアップデートとして配布する
    • マザーボードのBIOS のアップデートは大切
• CPU のチップの中には周辺機器のコントローラやアクセラレータも入っている
  • 昔はノースブリッジといわれて、別のチップに入っていたものが CPU に統合されていった（？）という理解
  • メモリコントローラも入ってる
  • PCIe バスコントローラも入ってる
  • USB コントローラも入ってる
  • GPU も入ってることが多い (iGPU)
  • AIアクセラレータ、行列計算特化演算装置とか (XDNA とか）が入ってることもある

UEFI/BIOS

• CPU の回路は最初のクロックは何をフェッチするか
  • CPU の固定物理アドレスに結線された ROM 領域にある命令をフェッチして実行が開始される
    • BIOS と呼ばれる OS のコードが読み込まれるまでのすべての処理を行う命令群が連なっている
      • 色々な初期化やキャリブレーションを行って最後に OS のブートローダにジャンプする
• UEFI とは
  • Intel がEFI というBIOS を作っていて、それをオープンな仕様にしたのがUEFI
  • UEFI に従って実際にBIOS を実装するのはマザーボードメーカー
    • マザーボードメーカーはBIOS という超重要なソフトウェアを作っているソフトウェアの会社でもあることは重要な視点
• UEFI のオープンソースの実装がある
  • EDK 2 といって、割とこれを元にUEFI/BIOS を開発しているメーカーも多いんだと思ってる
  • github.com
• UEFI はどこまで初期化されたかを段階（フェーズ）として定義している

• UEFI の理解は普通の PC ユーザにも役に立つ
  • CPU とメモリをつけたけど「起動しない」となったときに「UEFI のどこのフェーズまで進んだか」を理解できると、グッと解決までの解像度があがる
  • UEFI の PEI フェーズではメモリがなくても C 言語のコードが動いている（結構びっくり！）
    • UEFI では CPU の初期化がある程度進んだら、 CPU のキャッシュ上にスタック領域を形成し、メモリの初期化以降のコードは C 言語で記述することができている。
    • CPU が C 言語で書かれた（スタックを持つような）「普通のプログラム」を実行できる状態まで初期化できたかどうかは、マザーボードにメモリを刺さなくても確認できるということ。 問題がメモリにあるのか CPU にあるのかなどの切り分けするときに便利（メモリを外して、UEFI のフェーズがメモリエラーまで進むか見る）
  • 特にBIOS の設定画面が表示される前の状態で不具合が起こるとき、UEFI のフェーズが理解できていると問題解決の難易度が下がる

SSD

• M.2
  • M.2 はややこしい。 PCIe、USB 3.0、SATAなどいずれかのバスと機器をつなげる
  • 機器によって対応する接続可能なバスの種類が決まっている。同じ M.2 でも「この機器は PCIe に接続される」とか、「この機器は PCIe かSATA に接続可能」とか決まってる
  • スロット側（マザーボード側）にも「このスロットは PCIe のみ」とか「このスロットはSATA のみ」とか「SATA と PCIe」とか色々決まっている。
  • Key といって、スロットの切り欠きの位置である程度レーン数などの成約を示すことができるが、SATA か PCIe かは Key では示せない。
  • なので M.2 は、マザーボード側で何に接続される M.2 スロットか、何に接続される機器かを確認する必要がある
  • 上の図はSATA Express という M.2 のもとになった仕様の図をWikipedia から引用している。このように M.2 は「PCIe やSATA や USB 3.0 に機器をつなぐためのスロットを共通にした」というものに過ぎないので、その上で「何をどのように繋いだか」が大事。

• NVMe,AHCIプロトコル
  • PCIe 上でブロックデバイスと通信を行うプロトコル。
  • 今まではAHCI というSATA 専用プロトコルを使っていた。
    • AHCI との通信はLinux ではざっくり Block IO ->SCSI device layer -> libata ->ahci という風にレイヤになっていてSCSI レイヤなどは多くのブロックデバイスと共有するレイヤとなっている
  • NVMe デバイスは Block IO -> NVMe device というように NVMe ドライバが担当する領域が大きい。これはSCSI デバイスのレイヤで IO 要求が一つのキューで待たされるのを回避するため。 NVMeプロトコルではそれが許容されているため。複数の CPU からの IO 要求に依存関係がなければ同時に実行したりできるようになるということだと思ってる。
  • NVMe はこれまでのAHCIプロトコルの制約から脱して機器の性能を引き出すことに成功している
  • M.2 経由で PCIe を使うことに加えて、 NVMe を使うことでSSD は速くなった。

• MLC,TLC, SLC Caching

  • SSD はフローティングゲートという絶縁された領域にある電荷の量をビットとして扱う
    • SLC: 素子一個 1 ビット
    • MLC: 素子一個 2 ビット（電荷の量を 4 段階に量子化する）
    • TLC: 素子一個 3 ビット（電荷の量を 8 段階に量子化する）
    • QLC は 4 ビット
  • 特性
    • 寿命: SLC >MLC >TLC > QLC
    • 速度: SLC >MLC >TLC > QLC
    • データ量: SLC <MLC <TLC < QLC
  • SLC とTLC が主に使われている
    • SLC はキャッシュとして使われる
    • TLC は主記憶として使われる（QLC のものもある）

• 書き込み増幅 (Write Amplification)

  • SSD は数 MB とかの単位で消去、書き込みを繰り返すため小さなデータをランダムに書く処理に弱い。そのため様々な工夫が行われる。
  • Wikipedia の Write amplification が詳しい

• カタログスペックは当てにならない

  • 何故？
    • カタログの速度は理想的なもの
    • SLC キャッシュがどのように実装されているか
    • Over provisioning がどのくらいあるか
    • DRAM キャッシュがどのくらいあるかとか
    • ガーベジコレクション戦略など、 Controller がどのくらい賢いか、触ってみないとわからない
  • フル書き込みをしたときの特性を見ると良い
    • SLC キャッシュの枯渇、全体の枯渇でどのような速度になるか
    • Tech Power Up さん などの製品レビューで、以下のようなSSD にフル書き込みをしたときの速度を実験してくれている。かなり色々な特性が見られて面白い。この特性を見て、自分のタスクに向いたSSD を買うと良い。

メモリ

• DDR

  • クロックの立ち上がりと立ち下がりの両方でデータを処理するから Double data rate というらしい
  • めちゃくちゃ早いのでクロックを共有するだけでは、通信ができない。なので CAS 遅延や RAS 遅延など（メモリタイミングともいう）の様々な遅延情報を CPU のメモリコントローラと交換する必要がある
  • さらに DDR5 とかでは周波数が高すぎて取り付けられた基板の電気的な特性、特に回路のリアクタンスやキャパシタンスによって出てくる微分成分や積分成分（そんな言葉があるかは知らないけど）が無視できないらしく、しきい値やタイミングのキャリブレーション（調整）を行う必要がある。
    • マザーボードメーカーはUEFI/BIOS の PEIMプラグインという形でメモリコントローラのキャリブレーションを行うソフトウェアを提供する

• メモリタイミングとJEDEC/OC プロファイル

  • DDR はJEDEC という団体によって標準化されている
  • JEDEC は標準となる DDR5-4800 などの仕様を決めて様々なメモリタイミングの値のセットを標準化している
    • 各メーカーこれに合わせてメモリのタイミングを調整して製品化する（はず）
  • このタイミング仕様はSPD というDDR メモリ内の EEPROM にかかれている。これをJEDEC プロファイルといったりする
  • 「JEDEC の標準から逸脱したメモリタイミングを使えばもっと速度が出せる」ということで、DDR メモリはJEDEC 非準拠のSPD のようなものを持つことがある。これを OC （オーバークロック）プロファイルといったりする
    • XMP:Intel CPU 用の OC プロファイル
    • EXPO:AMD CPU 用の OC プロファイル
  • OC プロファイルについて
    • 遅延を大きくしてクロック数を稼いだりするものもあり、一概にクロック数を上げれば必ず速くなるというものではない
    • JEDEC と同じパラメタを持つ OC プロファイルも存在する。これはJEDEC か OC かプロファイルの種類でメモリコントローラの設定を変えてしまう PEIM があるらしいから
      • Crucial のJEDEC 準拠メモリにそういう OC プロファイルがあり、説明にそのようなことが書いてあった。

マザーボード

• チップセット（PCH）

  • ノースブリッジが CPU に吸収される前は、サウスブリッジと呼ばれていた部分が今はチップセットや PCH と呼ばれている（と思っている）
  • DMI や Infinity Fabric というプロトコルで CPU とつながっている（物理層は PCIe）
  • 重要な役割としてはTPM とつながっていて、 OS の検証に一定の役割を果たす
  • それ以外は以下のような一般的に必要な拡張機能が「全部入り」してるようなシステムハブとしてみなせる。
    • PCIe のハブ
    • USB コントローラ
    • Wifi やEthernet のコントローラ
    • SATA コントローラ
    • Bluetooth のコントローラ

• CPU とチップセットの機能を確認したあとマザーボードを選ぶ

  • CPU の機能のどれがどのスロットやコネクタで使えるか/使えないか
  • チップセットの機能のどれがどのスロットやコネクタで使えるか/使えないか

• デバッグ LED

  • UEFI/BIOS のフェーズのどこを実行しているか、どのようなエラーが出たかを数値で表す LED がついているものがある
  • これがあるとBIOS 画面が表示しない状態だったり、メモリがない状態だったりしてもある程度BIOS の処理を確認することができ、非常に便利。
    • 自力で切り分けることができる問題の範囲が大きくなる
    • 自分的には必須

CPU クーラー

空冷とか水冷をちゃんと整理。

まず、「水冷だから冷える」というのは単純すぎる。結局冷えるのは「熱をいかに周辺温度の低い場所に移動させるか」「ファンでいかに冷やせるか」で、一般的に水冷が強いのは熱源と遠ざけるのが速く、性能の良いファンをつけやすいから。

基本的にTDP で決めればいい。- CPU のTDP （熱設計電力）が、クーラーの targetTDP 以下に収まっているか- 条件を満たす中で以下のニーズを検討してくーらーを決める - メンテナンス性 - 静音性 - 寿命の見積もり

熱は物理的に CPU の寿命を縮めるので、ちょっと余裕を持ちたい。

GPU/グラボ/ビデオカード

• 自分の使い方だと重要なのは以下の 2 つ
  • GPGPU としての性能
  • 動画のハードウェアエンコーディング
• GPGPU としての性能
  • VRAM の容量
    • VRAM に載るデータサイズが大きいと機会学習のバッチが大きくできるので
  • GPGPU の計算能力
    • TFLOPS とかを見る
    • CPU と同様いろんな指標があるのでベンチマークを見る
  • 個人的には基本的にクラウドを使いたい
    • Cloud TPU 最高！
    • ただし単純な処理を大量のデータにかけたい場合などはローカルの強みが出ることがある
      • 通信料金でコストが律されるときとか
• 動画のハードウェアエンコーディング（この部分はこの記事を投稿した時点で大きく勘違いしていたので、書き直しました）
  • 個人的にはGPGPU よりこっちのほうが重要度は大きい
  • 動画のコーデック系のチップにはデコード用の NVDec とエンコード用の NVEnc がある
  • 最新の RTX 40XX だと AV1 ハードウェアエンコードに対応した 8th 世代の NVEnc が搭載されている
  • NVEnc 一基で 8 セッションのエンコードができる。
  • GeForce RTX 4070 Ti から NVEnc が二基になり、複数のエンコーディングを走らせるときに高速になる（一基で複数セッションできるけど、同時にやるなら二基使ったほうがパフォーマンスは良い）
  • ffmpeg での例
    • ハードウェアデコーディング-hwaccel cuda -hwaccel_output_format cuda -i input.mp4
    • ハードウェアエンコーディング-vcodec av1_nvenc output.mp4
  • svtav1 などのソフトウェアエンコーディングと比べると画質は少し劣るが、速度でいうと文字通り一桁違うスピードが出る

おまけ3: PC の組み立て

色々と写真をたくさんのせておく。

このブログを読んでいる人の多くに役に立つかはわからないけれど、今回いろいろ組み立てるにあたって自分と同じパーツで作業している人の画像を見たりすると少し失敗への不安が減る感覚があった。

なので、誰かのために載せておきたい。

作業場所の確保とか

ディスプレイ組み立て

Dell S2722QC のセットアップ

開封	組み立て	ドット欠けチェック

他にはHDMI ケーブルはテレビとかに繋いで単体テストをした。

ケース開けておく

ケースThe Tower 500 も開封して、マザーボードとの配線レイアウトが物理的に問題ないか確認しておく

開ける

箱。大きい...	本体

フロントパネルとそのフロントパネルから伸びているピンを確認（マザーボードに刺さるものが多く出てるはずなので）。

フロントパネル（ここから右のピン達が出てる）	LED とスイッチのピン	ヘッドホンやマイクのピン	USB 3.0 のコネクタ 2 つ	USB-C のコネクタ 1 つ

工具なしでパカパカあける（ちょっと固い部分もあるので、念のためドライバー（2番）もあってもいいかも、特に下の裾っぽいところが固かった）

その他の付属品（説明書とかは省略）

120mmファンx2	電源固定金具	ラジエータやファンをカスタマイズして付ける金具	束ねるやーつ	マザーボードのエラーを教えてくれるビープスピーカー

マザーボードのネジ穴（スタンドオフ、スペーサ）	ドライバで六角を回すやつ	ATX電源用のネジ	ハードディスクのネジ穴に付けるもの（振動対策？）	その他 2 種類に統一された多目的ネジ（形が違うので説明書に用途ごとにネジの絵で記載してある。かしこい）

マザーボードの説明書をダウンロードしてきて、物理的なコネクタの位置や配線関係が記載されたページを印刷して確認しておくと良い。

こういうのを印刷	物理的な配置を確認して配線場所からピンを出しておく

電源ユニットの準備

マザーボードや CPU の動作確認を行うためにも電源は必要なので、電源ユニットMPG A1000G PCIE5 を開ける

箱	本体

ケーブル類

↓まず CPU 用（CPU には直接させないのでマザーボードに刺す。 CPU に安定した電圧をかけるためのVRM という回路がマザーボードに実装されている）

CPU 電源用 2本（大電力の CPU だと 2 本使う）	電源側	マザボ側

↓PCIe 機器用（グラボは 12VHPWR のやつ使うからそれ以外）

PCIe 補助電源 2 本（150Wまでいるやつ）	電源側	機器側 (二股に別れてる）

↓グラボ用の大電力用（下のどっちか）

12VHPWR 1 本 （600Wまでいけるやつ）	コネクタ部分（たしか右のコネクタが電源側）

電源側だけ 12VHPWR で機器側は PCIe 補助電源 1 本（たぶん 2 本合わせて 300W までなのかな）	下のほうが電源側、機器側は二股に別れてる

↓SATA 用（2.5 inch とか 3.5 inch とかの HDD やSSD をつなぐやつ）

SATA 電源 3 本	電源側	機器側は電車の駅みたいにレールの途中にコネクタがついてる

↓なぞのケーブル

ペリフェラル、フロッピーディスク電源 1 本	電源側	ペリフェラル機器 2 つ	フロッピーディスク側 1 つ

↓マザーボードにガッチリさすやつ。

マザーボードの電源	電源側 (28ピン)	マザーボード側 (24ピン)

その他の付属品は以下（説明書とかは省略）

家庭用 100V 交流用ケーブル	ケーブル入れ	ケースにもついてたATX電源用の固定ネジ

コネクタはピンの本数が同じもの同士は刺す位置が入れ替わっても問題ないようになっている。なのでそこまで心配する必要はない

CPU クーラーの開封

CPU のテストをするために CPU クーラーAK400 も先に開封が必要だ。

箱	開封

ファンとヒートシンクを分離	こういう金具でファンが引っかかってるだけ	ファンは 4 ピンコネクタでマザボとつながるよ

↓CPU とくっつける際の金具（あとで使う）

Intel 用	AMD 用

グリスは塗ってあった

グリスはもともと塗ってあった	自分は別で買ってしまったので無水エタノールで拭いてこっち使った

（説明書とかは省略）

最新のBIOS 用を USB メモリに入れとく

マザーボードMPG X670E CARBON WIFI は CPU がなくてもマザーボードだけでBIOS のアップデートができるので USB メモリに入れておく。

BIOS は CPU に向けたアップデートされる。それなのに CPU を接続しないとBIOS のアップデートができないマザーボードが多い。これだと未テストの環境でBIOS が動くことになる。

BIOS アップデート機能がマザーボードについていると安心できる。

MSI の場合、マザーボードのサポートページ（簡単にググればでてくる）からBIOS ファイルをダウンロードする。

ダウンロードしたファイルを解凍すると以下のようなMSI.ROM というファイルが入っている

これをFAT32 でフォーマットした USB メモリのルートディレクトリにポンと置いておく

マザーボードの開封

マザーボードMPG X670E CARBON WIFI を開封する

箱	マザボ

その他の付属品（説明書とかは省略）

SATA ケーブル（電源じゃなくて通信の方）	光らせる系のケーブル（詳しくない）	アンテナ（バックパネルに付ける）	M.2 を引っ掛けて固定するネジ	ツール群（Windows 用？使ってない）	シール

↓デバッグ LED これが自分にとっては最重要。

バックパネルの写真がなかったので公式ページから引用

左の方にBIOS をアップデートするためのボタンがある。

CPU を開封する

CPURyzen 7 7700 を開封する

箱	中身	本体

CPU クーラーが付属していたけど、自分で買ったので付属のやつは使わない。

マザーボードがエラーを伝える手段の一つビープスピーカをつける

説明書を見る

BUZZER とか SPEAKER とか書かれている。フロントパネルのイヤホンとつながる部分はもっと密集したピンになっているので SPEAKER と書いてあっても 4 ピンならビープスピーカの可能性が高い

これを	ここに	こう

デバッグ LED を確認

現代のBIOS はUEFI のフェーズの順に初期化プロセスが行われる。そしてデバッグ LED でそのフェーズ上どこまで処理が進んでいるか。どこで停止したか。エラーの ID などがわかる。

このスイッチを ON になっているか確認	これがデバッグ LED

BIOS のアップデート

CPU が最初の命令をフェッチする前にBIOS は新しくあってほしい。マザーボードだけでBIOS アップデート出来る場合はする。

↓電源とマザーボードだけをつなぐ

↓BIOS とかかれた USB ソケットに前述したBIOS が入った USB メモリを挿して

↓電源ユニットを通電して

↓FlashBIOS と書かれたボタンを長押しする

完了するまで待つ

フロントパネルのスイッチの部分を短絡するためのスイッチを付ける

ケースに組み込む前にマザーボードと CPU のテストをするので、それ用にスイッチをつける。

これを	ここに	こう

CPU を付ける

パカっとあけて	のせて	とめる	上の黒いカバーが勝手に外れる

CPU クーラーを付ける

固定具を付ける

黒いの外して	オレンジの付けて	銀色の付けて

グリスはマスキングテープと定規できれいにぬった（普通にのっけるだけでいいらしい）

うとぅくしい....

ヒートシンク付けて	ファンを金具で固定

ファンの向きは大事なので、要確認。羽が膨らんでるほうが吸気方向。

これを	この	ここに	こう

CPU とマザーボードのテストを行う

自作パートではここがたぶん一番重要。

CPU とマザーボードと電源だけでテストを行う。（メモリはつけない）

できるだけ最小構成で、UEFI (BIOS) のフェーズがメモリエラーまで進むことを確認する（前述）

これはプログラムでいうHello world! にあたるテストで、ここが成功すればこの後の作業が二分法での問題の特定が可能になる。

ここが一番大事な瞬間である。

ここからの作業はマザーボードの説明書を印刷しておくと作業が捗る。

まず、今の状態。メモリが刺さってなくて、 CPU、 CPU クーラー、マザーボード、電源、スイッチ、ビープスピーカー、がつながっている状態。

↓説明書を確認して 10 が出れば成功ということを認識する

↓電源ユニットを通電して、スイッチを押す。

↓ちゃんとエラーを起こす。 10 が出れば CPU はUEFI の PEI フェーズまで問題なく動いていることになる。

10 番のエラーが出ている！そして、ビープ音がピー、ピー、ピーとなっている。メモリがないことを示している。

正しく動いている！！！！

メモリを取り付ける

メモリは付属品とかもないので、シンプル

メモリは枚数によって付ける場所が決まっているので確認して

こうして

こう

BIOS の設定画面を表示するためにディスプレイとキーボードマウスをつなぐ

グラフィック内蔵 CPU だとこの時点でグラボも刺さなければならないので、グラフィック内蔵 CPU のほうが細かいステップで確認しながらセットアップできて好き。

上の用にHDMI と USB キーボードと USB マウスを挿した。

BIOS の設定画面が表示されることを確認

CPUマザーボードをテストしたときのスイッチを押して、画面が表示されるのを待つ

メモリも問題なく動いていてBIOS がほぼ最後のフェーズまで起動することが確認できた。

BIOS を設定

USB で OS をインストールするための Boot 設定	Advaced -> Security -> Secure Boot を切っておく（ちゃんと Boot イメージを署名しないと駄目だと思うので）

この時点で Boot イメージに署名する方法とかがあるのかは知らない。

M.2 を刺す

M.2 も付属品はない。

箱	中身

取り付け

ここを	外して	サーマルパッドのシールを剥がして	つける	とめる

蓋もサーマルパッドがある	はずして	とめる

ケースに入れる

色々と確認は終わってるのでケースに入れる

↓まず電源

ここの金具を外して	電源につけて	ケースに戻して付け直す	GPU と CPU とマザボのケーブル挿して	表に出しておく

この際にマザーボードのレイアウトがあると便利

↓次マザーボード

ATX サイズだと基本スタンドオフ（スペーサ）はかえなくていい

止めるネジ確認	置く	こういう点々の印の穴 9 箇所に	ネジ止め	止めた

↓ケーブルつなぐ。もう事前にケーブルは出ているので刺すだけ

USB	USB	フロントパネル	USB C	マザーボード主電源	CPU 電源 2 個	フロントパネルのイヤホン

で、フロントパネルとグラボの電源以外の電源はつながった状態。

ケースファンを付ける

ケースファンを付けるときはマザーボードの SYS_FAN<番号> などと書かれているコネクタの位置を確認して、分岐ケーブルを揃えたり配線の取り回しを先に図として書いておくといいです。

背面	天板	マザーボードとグラボに空気を送る位置	下から室温取り込み	ケースとつなぐ

ケースファンを接続した SYS_FAN<番号> の番号を覚えておくと、ファンの設定をするときに使えます。

後日: ファンの設定

デフォルトだと温度による制御が聞いていなかったのでPWM 制御の設定をしておいた

「Hardware Monitor」というボタンからファンを個別に設定できる。基本的に最近のファンだとPWM 制御でいいとおもっている。

Wifi のアンテナ

これを	つけた

グラボつける

箱	中身

つける

ここを	2スロットはずして	こうはめて	電源つなぐ

完成！！

つかれた〜〜！パソコンできました！

後日: ハードディスクが届いた

普通に電源につないだのだけど、少しだけハマったので書いておきたい

以下のように普通に電源とつないだ時に動かなかった

これはデータセンター向けの POWER DISABLE という、電源を制御するための機能を持っている HDD だからのようだった。

説明書もついてた

電源とケーブルとつなぐとその制御のピンに定格 3.3 V の電圧提供に使われていてそのせいで電源が入らなくなってしまう。

この HDD についていた 3.3 V ピンを繋がないためのケーブルを噛ませることで、電源が入った

このカラフルなやつを間に噛ます

認識された

組みたての感想！

今回、先にレイアウトを見ておいてマザーボードを置く前にだいたい配線をすませておいたのが楽だった。

これといってハマったポイントはなかったけど、値段が高い部品を触っているときの心理的安全性が低かった。10 年使うものだしパーツの一個や二個は誤差という気持ちで頑張った。

おまけ4:Ubuntu のセットアップ

少しずつセットアップしてるので、やっととこまで

Ubuntu のインストール USB を作る

Ubuntuを入手する | Ubuntu | Ubuntu にいく

ubuntu-24.04-desktop-amd64.iso というファイルがダウンロードできる。あたりまえだけどamd64 それは命令の種類の話でintel でもamd64 で大丈夫だ。（念の為）

以下はMac で作業。 iso の内容をまるまるコピーした USB メモリを作る。

USB メモリを挿して diskutil list をして、その内容から USB メモリを表す/dev/disk<番号> 探す。

$ diskutil list.../dev/disk<番号> .......

アンマウントする

$ diskutil unmountDisk /dev/disk<番号>

dd で上から下まで iso の内容をコピー

$ sudo dd if=<ダウンロードしたファイル名> of=/dev/rdisk<番号> bs=4M status=progress && sync

ここで/dev/disk<番号> ではなく/dev/rdisk<番号> になっていることを確認する

Mac の場合だと /dev/disk<番号> だと中間にレイヤがあり、めちゃくちゃ遅くなる。

BIOS (UEFI) からブート可能か確認する

$ sudo gpt -r show /dev/disk<番号>

こうしたときに C12A7328-F81F-11D2-BA4B-00A0C93EC93B という行が途中に見つかればブートできる可能性が高い。

BIOS (UEFI) は、パーティションの種類として C12A7328-F81F-11D2-BA4B-00A0C93EC93B という固定値を持つパーティションを探してそこからブートするので

USB を挿して起動

組み立てのときにブートの設定を買えていると思うので USB メモリからブートして「Ubuntu インストール用のUbuntu」が起動する。

振り返り

BIOS の設定で以下のように USB から起動するように設定されていることが前提

以下のような画面が出る

Ubuntu のインストール

とりあえず English。（英語のほうがググったときに情報量が多い

キーボードレイアウトの設定。自分はDvorak なので English (US) - English Dnvorak を選択。早い段階で設定できるのでその先の打ち込みが楽になって良い。

ネットにつなげて

インストーラ自体も update

インストーラが更新されてるので再起動してやりなおし。

その後、ネットにつなげるところまでやり直して

Interactive Installation を選択

Default selection

third-party software も media format も使いそうなので、両方チェック

空のSSD を挿してるので Erase disk and installUbuntu

ユーザ名とパスワードは個人でいつも使ってるやつを入れて

タイムゾーン設定して

設定の内容を確認して Install ボタン

少し待って

完了したので Restart now で再起動

再起動でもう一回インストーラが起動しないように、刺さってたら抜けって教えてくれた。

起動して、ログイン画面。

Chromium のインストール

左のバッグみたいな App Center メニューから

Install からインストール

完了したら左下の Show Apps から確認できる

ターミナルを開く

左下の Show Apps から

Terminal を起動でき、bash というシェルを打ってコンピュータを操作できる

起動中に左側で Pin to Dash とすると、今後は左から起動できるようになる。

日本語入力用にIME デーモンを入れる

fcitx5 と mozc をインストール（fcitx5-mozc で両方入る）

im-config -n fcitx5 としてデーモンとして起動するようになる。

で、 reboot

$ sudo apt install fcitx5-mozc$ im-config -n fcitx5$ reboot

reboot すると

右上にこんなメニューがでるので

そこから config を選び、左半分のペインを mozc と英語を入力するためのレイアウトを選択してあげる。自分はDvorak なので、 English のところは English (Dvorak) と書いてあるやつになってる。

日本語打てた

Chromium で日本語打てるようにする

Chromium はユーザがディスプレイサーバとして何をつかっているかを教えないと、 fcitx5 のデーモンとやりとりしてくれないので、設定する必要がある。

ディスプレイサーバとはGPU やキーボードやマウスと、ディスプレイマネージャやGUI アプリの仲介をするレイヤで wayland とx11 がある。

ターミナルから

$ echo $XDG_SESSION_TYPE

とすると wayland かx11 かが表示される。GPU の選択とかで変わったりするので一概にどちらかとは言えない。

それを確認したら

Chromium のアドレスにchrome://flags と入力し、 PreferredOzone Platform という設定をx11 か wayland か自分のディスプレイサーバに設定する。

一応、自分はこれで入力できたが。

Chromium の開発の issue を見ていると wayland では苦労しそうで、 wayland の text-input v3 のイベントをChromium がサポートしていないようだった。今後のリリースで少し使いやすいオプションが提供されるようだ。

Chromium + wayland で日本語入力ができない場合、修正を待つ間Firefox を使うのも手だし、Chromium の nightly ビルドなどを使ってみるのも良いかもしれない。

自分もちょっときになったので試してみた。 nightly で以下のオプションをつければ日本語入力できることは確認できた。

$ chromium --enable-wayland-ime --wayland-text-input-version=3

パスワード管理機能

Chromium にはChrome のようなクラウドにパスワードを保存する機能がないようだったので 1Password を導入した。

VLC 入れた

nvim を設定

公式のgithub から nvim-linux64.tar.gz をダウンロードしてきて

$ tar xvfz ~/Downloads/nvim-linux64.tar.gz

解凍して、

$ sudo mv nvim-linux64 /opt

とりあえず /opt に置いておいた

~/.bashrc にも書いた

一旦雑に.config/nvim/init.lua も上のようにしておいた

ポータブルなバイナリとして配布されていて素晴らしいなあと思った。

Nvidia のドライバと CUDA ライブラリ

オープンソース版のドライバが入らないように/et/modprobe.d/blacklist-nouveau.conf に

Nvidia のドライバやライブラリのダウンロードに関しては、調べるといろいろと情報が分散して古かったりもするし、あまり URL を直で語らない方がいいように思った。常にトップページからたどるのがおすすめ

このドライバをダウンロード

CUDA の互換性を調べて

CUDA のバージョンをナビゲータにしたがって選んで

インストールするためのコマンドが出てくるのでそれにしたがってインストール

Pytorch とかから使われる cudnn も同様にナビゲータに従ってインストール（コマンド省略）

また、An Even Easier Introduction to CUDA | NVIDIA Technical Blog に書いてあるコードで、ちゃんと cuda が動くか

確かめたりした。

Max error: 0.000000 なら問題ない。今までの経験で CUDA のインストールが間違っていて 2.000000 となったこともあり、このコードには助けられた経験がある。おすすめ

$ sudo ldconfig

DLL がシステムに配置されるので、 ldconfig して使えるようにしておく

ffmpeg のカスタムビルド

以下のように

ffmpeg のリポジトリからコードをもってくる

上のように依存関係をリストアップしていれる。それを使うようにビルド。特に今回 cuda や nvenc の機能をちゃんとffmpeg から使えるように以下のようになった

$ ./configure \    --disable-static --enable-shared \    --ld="g++" \    \    --enable-gpl \    --enable-version3 \    --enable-nonfree \    --enable-cuda-nvcc \    --enable-libnpp \    --extra-cflags="-I/usr/local/cuda/include "\    --extra-ldflags="-L/usr/local/cuda/lib64 -L/usr/local/cuda/lib64/stubs" \    --enable-cuvid \    --enable-libnpp \    \    --enable-libsvtav1 \    --enable-libx264 \    --enable-libx265 \    --enable-libvpx \    --enable-libfdk-aac \    --enable-libopus \    --enable-libdav1d \    --enable-libfontconfig \    --enable-libfreetype \    --enable-libaribb24 \    --enable-openssl \    --enable-libbluray \    --enable-libmp3lame \    --enable-libssh \    --enable-libtheora \    --enable-libvorbis \    --enable-libwebp \    --enable-libxcb \    --enable-libxcb-shm \    --enable-libxcb-xfixes \    --enable-libxcb-shape \    --enable-libxvid \    --enable-libxml2 \    --enable-openal \    --enable-opencl \    --enable-opengl \    --enable-ffnvcodec \    --disable-stripping \    --enable-nvenc \    --enable-nvdec \    --enable-cuda \    --enable-libvmaf

--enable-nvenc とか--enable-cuda--enable-cuda-nvcc などを追加している

実は上の libvmaf に関してはこのあとビルドする。順番が前後になってしまっているが、ゆるして欲しい。

configure したら make && sudo make install

$ make -j 16$ sudo make install

16 はスレッド数

$ sudo ldconfig

DLL も置かれるので ldconfig しておく

CUDA を使って爆速で VMAF を求められるようにする

VMAF はnetflix が作った。エンコードした結果画質がどのくらい下がったかをスコア化するためのライブラリ。

コードをリポジトリからもってきて

上のように enable_cuda してビルド

ただ、少しコードを書き換えないとビルドはできるが実行時にクラッシュするようだった

こんな感じで実行するが

こんな感じでセグフォする。

セグフォしたらgdb で場所を特定

原因をとくていしてパッチを書いたのでComparing Netflix:master...amachang:master · Netflix/vmaf · GitHub からパッチを作って当てると動く（本家の issue にも連絡済み）

で、

$ meson setup libvmaf/build libvmaf -Denable_cuda=true -Denable_avx512=true$ ninja -vC libvfam/build

みたいにして libvmaf をビルドすることができた。

2000 Kpbs とかの動画同士だったら1800fps とかで VMAF が求められるようになったので、めちゃくちゃ快適である。

NeoVim の設定

特にプラグイン管理の lazy の設定や copilot の導入、 language server の設定

Lazy の設定

Lazy から copilot を入れる

Lazy の設定書いて、Vim を再起動。

インストールされたらvim 上で :Copilot auth とやってブラウザで認証をする。

language-server の設定もなんやかんや書いた。

Gnome Shell で一部のアプリの最初の起動が遅い

デスクトップポータルというアプリがデスクトップシェルの機能を使うための仕組みがあり、これを通じて各アプリが連携できるようになっている。

このデスクトップポータルがX11 なのに wayland を待ち続けて、そのポータルが必要なアプリも、タイムアウトするまで起動しない。という現象があるらしい。まだ治ってないらしい。

遅いのも最初の一回だけだし、原因がわかったし放置することにした。

NeoVim とクリップボードの連携

ヘルプをみる

クリップボードがx11 と連携できるように unnamedplus を設定

これだけでは動かなかったので、ちょっと調べた

NeoVim は xsel というプロセスを通じてx11 のクリップボードと連携するようでその xsel がシステムに入ってなかったようだ

$ sudo apt install xsel

NeoVim で yank したものを他のアプリで貼り付けたりできるようになった

Delete キーがない問題

よくgnome-shell のデスクトップ環境だと Delete キーがいろんなもののショートカットになっていたけど、自分のキーボードには Backspace しかなかった。

ちなみに 14 年前のHHK を使っている。

Backspace を Delete キーにマッピングする機能がキーボード自体にあったが、それをすると今度は Backspace キーがなくなってしまい直前に打った文字が消せなくなってしまう。

で、 HKK をしらべていると fn + ` が Delete キーとして働くらしい。そうだったのか...。

今思うと

Mac だと Backspace が Delete と呼ばれていて Delete キーの存在自体を自分は忘れてしまっていた。

その後

なんやかんやした（追記するかも）

最後まで読んでくれた人、ありがとう

最後まで読んでくれてありがとう！

この記事が、誰かの新しいことに挑戦する安心感や何かの問題を理解するのに役にたったら嬉しいです！

では！