「LinuxにはIntel*Nvidia」は終わり、時代はAMDに

安定してきたAMD Linux

LinuxにおいてはCPUもビデオカードもAMDは非常に安定性がなく、「LinuxではAMDはリスキー、IntelとNvidiaが鉄板」という時代が非常に長かった。

これはWindowsにおいてもそんなものだとは言えるが、どちらかといえば性能とか好みとか思想の問題であり、AMDだと困るという要素は少なかったのだが、Linuxにおいては動作安定性という意味でもAMDは避けたい、という状況があった。

大きな問題としてはCatalystドライバのデキの悪さがあった。プロプライエタリドライバーとしてもNvidiaよりも後にサポートされてきたCatalyst(flgrx)ドライバーだが、様々な問題が発生していた。私が利用している限りでもXサーバーのフリーズ、マウスカーソルの文字化け、ティアリング、画面化け、X再起動の失敗、などなど枚挙に暇がない。

AMDがLinuxに力を入れるという選言をしたのは、Linux 4.6の頃であったと思う。 そしてAMDGPUドライバーが誕生したわけだが、実際安定性は高いものの性能はいまひとつであった。

そこから3年ほどが経過している。 Linux 4.18ではAMDGPUの改善が進んだ。Vega 20や、Intel Kabylake-Gプロセッサ(IntelのプロセッサにAMDのビデオカードが内蔵されている!!)といったデバイスサポートが主だが、AMDGPUドライバーそのものの改善も結構手を入れていた印象だ。 その結果AMDGPUドライバーは4.18の初期には性能が従来よりも低下していた(!)

AMD APU(Godavari)マシンに4.18を導入してみて驚いた。 アップデートごとにどんどんよくなっていたAMD環境だが、4.18は明らかに描画がスムーズになった。 ビデオ性能に関していえばNvidiaのほうが(私の手持ちでは)良いのだが、結局のところLinux利用の上での快適性は画面のちらつきや、フリーズの有無、あるいはビデオ再生に支障があるか…といったことに左右される。

結果的に性能は圧倒的に低いのだが、そうしたエラーが少ないAMDGPU環境が非常に快適に感じられてしまうのだ。 実際、ビデオ再生に関してもLinux 3.17あたりの再生と比べて明らかに快適になった。

現状、ビデオドライバーから見れば「AMDGPU > Intel > nouveau > nvidia」という状況になっている。 本当に力を入れてきたAMDドライバーの成果が、「とりあえずIntel安牌」という状況を靴替えしている。Nouveauもそれなりに安定しているのだが、基本的にはメーカー協力のない、リバースエンジニアリングの成果物であること、またNvidiaはLinuxドライバーにあまり力を入れていないことからこの滋養今日が生まれているのだろう。

実際にPhoronixのベンチマークを見るとRX580がGTX1060よりも良い結果を出していたりする。 (まぁ、一方でVega56がGTX1070に全然勝てていなかったりするのでドライバーの優劣を反映しているようにも見えないが)

現状、Nvidiaドライバーでの問題と言えば

  • Google Chromeはウィンドウ移動時にマルチディスプレイでは座標がずれる
  • 画面が激しく点滅することがある
  • ffmpegでの録画時にちらつく。Allow Flippingを無効にしてもまだちらつく
  • Wineが条件によって問題を起こす (nouveauでも)

あたりである。このほか、Xサーバーのrespawnの失敗、Blink系ブラウザにおいてコンソールと行き来したり状況によってはフリーズする、デスクトップエフェクトの反応が悪い、などがある。

そしてCPUもしっかりとパフォーマンスを発揮するようになっていて、4.18においてはXeon Silver 4114のpowersave governorよりもA10-7870KのほうがChromiumで高速に描画できる(シングルスレッド性能の差だ)。

性能と選択肢の改善

Ryzenによって向上した選択価値

A10-7870Kシステムを組んだときには随分と後悔したものだが、Linux側の改善によって随分と快適なシステムに進化してきた。 従来のAMD APUは使い勝手は良いもののその性能は悲しいほどしょうもなかった。

A10はAMD APUでも上級グレードだが、その性能はIntel Core i3に及ばない。 PentiumやCeleronよりは良いのだが、現在はPentium Goldに抜かれてしまっているほどだ。

AMDはAシリーズの上はゲーム向けとしてビデオカードを内蔵しないFXシリーズをラインナップしていた。 だかいくらなんでも「Aシリーズの上はゲーム用」というのはちょっと乱暴である。一般用途で確実に十分であるほどにはA10は性能はよくない(ただし、恐らく十分である程度には高い)。

ところが、現在はRyzen Gシリーズがある。 これは従来のAPU (Aシリーズ)を置き換える新しいAPUである。

少し複雑なので説明すると、第二世代Ryzenには、第一世代Ryzenと同じくビデオカードを持たないモデル、 つまり従来のFXと同じ「ゲーマー向け高性能プロセッサ」という位置づけだった。

しかし、Ryzen3/5/7というネーミングの通り、Core i3/5/7の直接的なライバルとなるラインナップであり、 Core i3をゲーマー向けプロセッサとするのは無理がある通り、AMDも考えを改めた。 さらにいえば、Aシリーズの不評っぷり(性能がとても低く、そのくせ消費電力は大きい)とRyzenの好評っぷり(いままでのAMDが嘘のようだ)を踏まえてもAシリーズを継続させていくよりさっさと仕舞にしたほうが良いと考えたのだろう。 結果RyzenシリーズはAMDの主力プロセッサシリーズへと転身した。

しかし、それはそれでややこしいことになった。 AMDの場合、Ryzenにはビデオカードを内蔵するGシリーズと、そうでないSTD/Xシリーズの2系統がある。 さすがにゲーマーはRyzen3を使わないと悟ったのか、Ryzen3はGのみ、一方ゲーマーでもなければRyzen7は使わないだろうと考えているらしくRyzen7はSTD/Xのみ、一方Ryzen5は両方ある。1

単にビデオカードの有無かというとそんなことはなく、Passmarkで見てみると

CPU Score Intel rival Rival score
Ryzen 7 2700X 16882 Core i7-8700K 15975
Ryzen 7 2700 15087 Core i7-8700 15217
Ryzen 5 2600X 14448 Core i5-8600K 12805
Ryzen 5 2600 13523
Ryzen 5 2400G 9264 Core i5-8500 12060
Ryzen 5 2400GE 8513 Core i5-8400T 9672
Ryzen 3 2200G 7331 Core i3-8100 8086
Ryzen 3 2200GE 7229 Core i3-8100T 7532
Ryzen 3 2300U 7172

RyzenのGEやU、またIntelのH/T/Uについては後述する。

また、Ryzen Proというのはセキュリティの追加機能があるものである。

このようにRyzen5 2400GはRyzen5 2600よりも下位グレードという扱いになっていて、Core i5と勝負できるのはビデオカードなしモデル、ということになっている。お値段的にもちょこっと2400Gのほうが安い。

この中でRyzen5 2400G及びRyzen3 2200Gは非常に魅力的である。

そもそもAPUという発想は悪くなかった。「別にそんなにCPUパワーはいらないだろうけど、動画見たり、たまにはゲームもするだろうし、ビデオ性能はそれなりに高いほうがいいだろう?」という考え方にはとても同意できたのだ。だが、Aシリーズは「そんなにない」というか「あまりにもない」というのが現実であって机上の空論に終わっていたのだ。

ざっくり、RyzenになってAPUは「2倍のパワーになった」と考えれば良い。さすがに2倍も速いと話は変わってくる。 HEVCのエンコードにも対応した最新ビデオカード(後述するvegaである)を搭載しながら、2倍速くなったAPUは普通の人にとって本当にいいバランスになっている。

普通の作業にはRyzen5 2400Gのパワーは十分だし、軽作業ならRyzen3 2200Gは悪くない。そしてビデオ性能のほうはIntelはいささか不足気味だ。 大きなポイントとしては、IntelのQSVはCPUパワーをかなり使う。これは動画見ながら作業することは考えにくいラップトップではあまり気にならないが、デスクトップの場合、特にマルチディスプレイ環境では足かせになる。 また、コンシュマークラスのIntel CPUの場合依然として「動画エンコード中は他の作業が難しい」という状況が発生する。 人によっては些細な違いに思えるかもしれないが、実際は使い心地に影響を及ぼす可能性がある。

また、自作する場合はAMDのマザーボードは非常に高機能なものや安価なものが揃うという点も見逃せない。 実際、私のA10システムは豊富なUSBサポート、8つのSATA、S/SPIF端子を持つオーディオなど豊富な機能によってデスクトップユースで一線級ではなくなったとしても様々な使い途が残る。

強力なシステムも組めるようになった

Core iと比べたとき必ずしもRyzenは魅力的なわけではないが、AMDのプロセッサの性能が大幅に上がったために、高性能が求められる局面でもAMDという選択肢が加わった、という点が大きい。

さらにThreadripperに至っては文句なしに強力である。

だが、CPUに関してはあからさまにLinuxにおける利があるわけではない。 ビデオカードの話をしよう。

現在のAMDのビデオカードラインナップはちょっと複雑で、やや古いRX 400シリーズはPolaris10, メインストリームのRX500シリーズはPolaris20、ハイクラスのRX VegaはVegaと設計が異なる。 さらにメインストリームはVegaにならずPolaris30になり、ゲーム用はVega20になってからメインストリームがNaviに、ハイクラスはNavi20になる、と噂されている。 (つまり、Navi登場までの間をメインストリームはPolaris、ハイクラスはVegaのままプロセス微細化されたものでつなぐらしい)

ところがAPUに搭載されているのはVega。Vegaのほうが新しい。取り残されているRX500がすごくいまいちに思えてしまう。

しかしここには罠があって、Linuxでは(Windowsと比べても)性能的にVegaがいまいち振るわず、Polarisのほうが良い結果を残している。 AMDGPUドライバが新しいVegaの性能を発揮できていないのかもしれない。

ともかく、Ryzen 7 2700X + Radeon RX580, Ryzen Threadripper 2950X + Radeon RX Vega 56, Ryzen Threadripper 2990WX + Radeon Pro WX 8200のような強力なシステムを組めるようになったわけだ。

Radeonの重大な欠点だったHEVCエンコードも対応しており、NVENCほどではないもののVCE/VA-APIでかなり高速にエンコードができる。

APUによる省コストなシステムだけでなく、パワーを必要とするシステムにおいてRadeonを使う、ということが現実的になったのだ。 もちろん、これはIntelプロセッサと組み合わせても構わない。

省電力システム

AMDはいつの時代も電気を食うものだった。 さすがにそれが終わりを告げた、とまでは言わないが、Intelの高性能プロセッサがTDPを越える電気を使ってしまう中、 Threadripperは実質的なワットパフォーマンスでの逆転を見せた。

そんな新時代のAMDとして推したいのがRyzen 5 2400GEである。

Intelの場合H(省電力), T(超省電力), U(超低消費電力)とラインナップされていたりするのだけど、AMDの場合GEはT相当と考えてよさそうだ。

2400GもcTDPで35W/45W/65Wということらしいけれど、そんなややこしいことは置いといて、2400GEは35Wである。 35Wだけどベースクロックは3.2GHz。ここらへんのCPUは割と容赦なく電気を使うので、まったり処理してほしい低消費電力システム(特にホームサーバー)ではすごく便利だ。

それだったらIntelのTでも良さそうに思えるけれども、前述のようにビデオカードが強力である。 ホームサーバーとして使うなら動画処理性能は重要な項目となりえるし、デスクトップとして使うなら描画環境は重要であり、AMDのほうが快適である。

もちろん、これは「Linuxで使うラップトップでAMD優位」という状況でもあると言える。 (もっとも、絶対的な消費電力の問題があるから話はそう簡単ではなくなってしまうが)


  1. この考えはとても正しい。多くの人はCore i3で満足できるが、ゲーマーはCore i3では足りない。一方、多くの人はCore i7を必要としていない。

【検索ワードに応えて】 ThinkPad X1 Carbon (2017, シルバー) のお話, Linux関連, その他

久しぶりの検索ワード反応企画。 ThinkPad X1 Carbon関連の検索が多かったので、併用されたワードに従ってコメントさせていただくことにする。

なお、ThinkPad X1 CarbonについてはYouTube (はるかみ☆ チャンネル)で開封動画を掲載させていただいているので、よかったらそちらもどうぞ。

また、そのほかLinux関連の検索にも回答させていただく。

ThinkPad X1関連

基本的なレビュー

ラップトップをガリガリ使うモバイラーなら持たない理由が見つからない。

XPS13のような13.3インチの中でも小型のものを除けばボディは13.3インチと変わりないサイズだ。 しかし14インチの画面は明らかに見やすく、作業もしやすいし、人に画面を見せるときにも良い。

そして非常に軽量でバッテリーマイレージも素晴らしい。 もちろん、キーボードはあらゆる現行ラップトップの中で最高だと思う。

唯一欠点としては天板の外板が弱い。 既に凹み、割れがある。それほど目立たないし、動作には問題ないのだが、ちょっとカナシイ。

買い時について

「高性能」「最先端」などを意識したい場合はリリース間もない頃が良い。

リリース直後は割引はなく、およそ半年程度で30%程度の割引になる。モデル末期は40%を越える程度の割引だ。

基本的にはThinkPadの場合30%程度割り引いた状態で競争力のある通常価格で、割引のない最初期というのはフリーク向けと考えられる。 なので買い時を気にするような人なら直後はないだろう。

春頃には30%前後の割引になっていたりするから(現時点でサイト公式のクーポンが28%、恐らくメルマガや店頭クーポンならもう少し行くだろう)、それぐらいが買い時ではなかろうか。

少しでも安く買いたい人は、翌年モデルが発表されてから決めるといい。 その頃にはかなり安くなっているし、在庫が残っていれば翌年モデルが出てからでも安く買える。 翌年モデルを待つべきかどうかの判断も出来てお得だ。

2017と2018に関しては、X1 Carbonとしての進化は微々たるものだったけれど、第8世代プロセッサになったという点がとても大きい。 ただ、私はかなり安く買えたので、そのタイミングでよかったと思う。

シルバーのThinkPadについて

良いと思う。

ThinkPadらしくないという批判はあるだろうけれども、マットだけれども黒のピーチスキンよりもサラッとした手触りで汚れもつきにくく目立たない。

シルバーのラップトップはそれなりに存在するので目立たないということは言えるけれども、「Hacker’s itemたるThinkPad」と「美しくおしゃれな高級ラップトップ」を両立させる意図は十分に達成できている。

控え目にいっても最高にかっこいい。

国産と中国産について

何も違わないから安心してほしい。 400万円するようなP920でも中国産だ。

なお、納期はかかる。X1は予定納期よりも遅かったという人が珍しくないようなので注意してほしい。

その他の検索ワード回答

シェルスクリプトの並列実行

基本的な形式は次のとおり

シェルスクリプトの並列実行は待ち合わせず投げっぱなしにするのが基本。

ただし、どうしても待ち合わたい場合はwaitを使う方法もある。

とした時、$!でサブシェルのPIDが取れるので、

としておけば待ち合わせる必要があるタイミングで

とすることができる。これはBashでもZshでも共通。

入出力をやりとりするのであれば、下流のパイプに流すべきで、親プロセスが出力を披露ようなことは考えないほうがよい。

どうしてもであればファイルに書いてwaitするか、もしくはZshならProccess Substitutionを使用する。

あるいは大量の処理があり、複数のワーカーを走らせたい場合はflockを使うのが無難だろう。 例えば以下のようにする。

要点は以下の通りだ。

  • 関数workerが各ワーカーが実行する内容
  • これをサブシェル内でworker nの形で実行する
  • ファイルデスクリプタはクローンされるので、標準入力から読んだ場合、親シェルもサブシェルも同じものを読み進めるし、位置も同時に変化する
  • しかし、もし同時に読んでしまうとおかしなことになるので、読んでいる間は他のシェルに読んでもらっては困る
  • そこでロックファイルを作り、これをロックすることで排他制御する。いわゆるドットロック。
  • exec 9>| .lockでファイルデスクリプタ9番をロック用に確保
  • 開きっぱなしになるので、flockでこのファイルをロック
  • ロックを獲得できたら標準入力から読む
  • 読み終わったらファイルデスクリプタを閉じてロックも解放
  • これでキューから1行読めたので、処理を進める
  • 「1行では足りないよ!」という場合、エントリをファイルに書いておいてディレクトリにまとめ、キューはファイル名にするとかすれば良い

AMD APU (Godavari/Kaveri) と Linux

特に問題はない。

以前はCatalystドライバのおかげでずいぶん苦労させられたけれども、 AMDGPUになって以来目立った問題は発生していない。

割と電気を食うけれど性能は微妙なので嬉しくはないと思う。 コストパフォーマンス的にみれば、これくらいの性能がおいしいという人は多いと思う。 ビデオ関連も充実しているし、Killerシリーズなんかは機能も充実しているしね。

XMPP

ちょっと話題が広すぎて何を求めているのかがわからない。ごめんよ。

DPI

これかなり広い。

LinuxでのHi-DPIの話なら/etc/X11/xorg.conf.d/以下にモニターの設定ファイルを書く。 40-monitor.confとかで。

Section "Monitor"
    Identifier             "<default monitor>"
    DisplaySize            286 179    # In millimeters
EndSection

で、KDE Plasmaを使うといい感じになる。 Plasmaを使わない場合については、Qtアプリケーションについてはなんとかなるけれど、GTKに関してはうまいことスケールしない。

LightDMに関してはGreeterの設定ファイルにxft-dpi=と書きましょう。

Hi-DPIはLinuxでは結構苦手にしている感じ。

フォントの設定はまた別。

某人物について

コメントする気はありません。

VP9のハードウェアエンコード

  • Intel QSVを使ってください
  • LinuxならVA-API経由ffmpegが良いよ
  • ただし画質は絶望的だったとは言っておく

Intel QSV * H.265

  • LinuxならVA-API経由ffmpeg
  • 速度はそこそこ。X.265とは雲泥の差。CPU負荷は0ではないというか、普通に40%くらいはいく
  • ちゃんとVA-APIドライバ入れようね

scale_vaapi

VA-APIを使用する場合の出力画面サイズ指定。 変更しない場合は省略して大丈夫。

AMD VCE / NVIDIA NVENC

VCEはLinux的にはVA-API経由。なのでQSVと一緒。

ただし、AMDのビデオドライバはVA-APIだけじゃなくVDPAUも使える。 ところがVA-APIがエンコード/デコードなのに対してVDPAUはデコードのみ。

VA-APIをVDPAUに転送するドライバ(libva-vdpau-driver)と、VDPAUをVA-APIに転送するドライバ(libvdpau-va-gl)があり、 VDPAUを有効にして、VA-APIに転送するドライバを使ってしまうと(Nvidiaの場合はVA-APIが使えないのでこうする)デコードのみになってしまって使えない。

ちゃんとlibva-mesa-driverを使いましょう。

Nvidiaの場合はVA-APIをサポートしておらず、VDPAUはエンコードができないので、 NVENCは専用のインターフェイスになっている。

どっちが優れているというのは難しいけれど、Nvidiaのほうが対応フォーマットは多い。

DiscordとSlack

基本的にはDiscordがいいと思うし、最近はSlackも微妙だと思うのだけれども、「両方あると嬉しい」という面もある。

Discordの場合「ユーザーという概念がある」ということが大きい。

Discrodでつながると、どのようなつながりであれ、「その人」というのが見えてしまう。 Discordは通知をカスタマイズできないため、「通知をオンにしている全ての人からの通知が一律に行われる」ということになる。 棲み分けをする方法がない。

これはLINEと同様の問題である。 恋人だろうが、ゲーム仲間だろうが、仕事の人間だろうが、区別する方法がないのだ。 アカウントの切り替えは難しいためアカウントで分けるのも現実的ではないし、アカウントで認識されているから一時的な連絡先にもしにくい。

Slackの場合はやりとりもつながりもあくまでそのチーム内でのことなので、仕事の関係などであればSlackのほうが便利だ。

自前メールサーバーからのメールをGMailが受け取らない

主にはホスト認証の関係。

GMailは送られてきたメールサーバーが、本当にそのメールを送る資格があるかをチェックする。

設定方法はいくつかあるけれど、SPFレコードを書くのが楽。 「メール SPF」で検索すると色々出てくる。

LinuxとRealTek ネットワークカード (RTL8152ほか)

ASIXよりはマシだけれど安定して苦しめてくれるRealTekのネットワークカード。

Linuxではネットワークアダプタは

Intel > Atheros (Killer) > Broadcom > RealTek > Asix

だからね。

RealTekのWiFiモジュールであるRTL8152のドライバはカーネルモジュールとしてある。 Arch Linuxの場合はDKMSになっていて、AURからインストール可能。 場合によってはRTL8153をブラックリストに入れる必要がある。

インストールしなくても動作はするけれど、うまく交信できなくなったりする。 安定性の面から言えば入れるべきだけれど、入れたところでうまくいかない場合もある。

「うちのディストリビューションにはないよ!!」という方。 Archにおいで。むしろManjaroにおいで。

Quadro2000 + GeForce GTX750Ti with Linuxで5面ディスプレイ

まえがき

Quadro2000は出力ポートを3つ持っているものの、出力は2系統で2面しか出ない。
これが不便すぎたので、GeForce GTX750Tiを導入した。

750Tiは2世代前の性能の低いビデオカードだが、消費電力、発熱量が少なく、補助電源も必要ない。
あまり余裕のない既存システムの拡張は比較的行いやすいカードだ。
2スロットカードだが、GT720にすれば1スロットで接続できる。

750Tiの基本的な出力は、4k1面を含む3ディスプレイ、CRTのものとDFPのものがあるようだ。
また、4k3面を含む4面ディスプレイのモデルも存在する。

性能的にはQuadro2000がFermiチップで実に4世代前なので、2世代前とはいえかなり隔たりがある。
そのため、OpenGL性能の高いQuadroとはいえ、当時の中堅モデルでしかなかったGTX750TiのほうがOpenGLにおいても性能はだいぶ高い。
ビデオエンコーディング作業の時間短縮も狙った。
単にディスプレイの追加だけであれば、最悪2枚同時動作が叶わず交換となったとしても、720で3面出力は可能だが、
750Tiを選択することでその場合でも性能向上が可能となるようにした。

前知識

NVIDIAのマルチグラフィックスといえばSLIだが、これは単なるマルチグラフィックスを意味するものではないらしい。

SLIは、複数のビデオカードをケーブル接続することによって、画面描画を分担するものである。
そのため、画面出力を行うビデオカードは1枚、であるそうだ。

SLIは「複数ビデオカードを同時利用する技術」ではなく、「複数ビデオカードで並列演算する技術」であるという理解でおそらく正しい。
しかし、SLI接続されていない複数のビデオカードで演算する方法としてMulti-GPUも用意されているようだ。

以前はLinuxにおいて複数(場合によっては多数)のビデオカードを使って多数のディスプレイを出す方法としてXineramaがあった。
だが、最新のnvidiaドライバではこれが無効である、との説明がある。
設定方法などもかなり変更があったようで、2014年頃のドキュメントは役に立たない。

それ以外の方法として、TwinViewもあるが、これはあくまでひとつのビデオカードで2面を使う方法であり、それはわざわざ使うほどのものではない。

Base Mosaic及びSLI Mosaicは複数のNVIDIAビデオカードに接続されたディスプレイをひとつのスクリーンにまとめる。
NVIDIAの説明を見る限りはこれはディスプレイの実際の間隔を反映して表示する(ベゼルの幅などで画面と画面の間にある幅や、ディスプレイの角度を理解して3Dグラフィックスを表示する)技術に読めるのだが、少なくともLinuxではマルチディスプレイテクノロジーであるらしい。

うまくいかない

Windowsでは何の苦労もない。ドライバーインストールだけでできた。

ところが、Linuxではうまくいかなかった。Base Mosaicであれ、MultiGPUであれ、この調子だ。

[    19.599] (EE) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration.
[    19.599] (EE) NVIDIA(GPU-0): Invalid Base Mosaic configuration 1 of 1:
[    19.599] (EE) NVIDIA(GPU-0): GPUs:
[    19.599] (EE) NVIDIA(GPU-0):     1) NVIDIA GPU at PCI:15:0:0
[    19.599] (EE) NVIDIA(GPU-0):     2) NVIDIA GPU at PCI:40:0:0
[    19.599] (EE) NVIDIA(GPU-0): Errors:
[    19.599] (EE) NVIDIA(GPU-0):     - GPU PCI IDs do not match
[    19.599] (WW) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration for the
[    19.599] (WW) NVIDIA(GPU-0):     NVIDIA graphics device PCI:15:0:0. Please see Chapter 28:
[    19.599] (WW) NVIDIA(GPU-0):     Configuring SLI and Multi-GPU FrameRendering in the README
[    19.599] (WW) NVIDIA(GPU-0):     for troubleshooting suggestions.

だいたい

[ 19.599] (EE) NVIDIA(GPU-0): GPUs:
[ 19.599] (EE) NVIDIA(GPU-0): 1) NVIDIA GPU at PCI:15:0:0
[ 19.599] (EE) NVIDIA(GPU-0): 2) NVIDIA GPU at PCI:40:0:0

の意味がわからない。なぜならば

lspci | grep VGA
0f:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000] (rev a1)
28:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)

と食い違うし、かといって0f:00:028:00:0を指定するとXが起動しない。
結局ずっとこのあたりでつまずくことになり、解決できなかった。

Manjaroのフォーラムでその苦労が見られたりする。

結局どうもQuadroクラスのカード以外はそもそもNVIDIA Mosaic Technologyに対応しない、ということのようなのだが、MultiGPU

</ins>

暫定的な方法

Xineramaは使えない、という記述があるのだが、実際はそんなことはなかった。
ただし、単にXineramaを使ってしまうと、同じスクリーンにあるディスプレイは1枚とみなされてしまう(つまり、2枚接続されているQuadro2000の部分は3840×1080の1枚のディスプレイということにされてしまう)。
見づらい上に使いにくい。

それぞれのディスプレイを違うスクリーンに割り当てれば大丈夫だが、

  • ものすごく遅い
  • とっても不安定
  • Conkyのウィジットが更新時に点滅する
  • randrによる設定ができない

MultiGPUも使えないことだし、1枚でまかなえる3画面までの話であれば普通にGTX750Ti単独にしたほうがはるかに良いように思える。

また、不安定の内容としてはChromium/Google Chromeなどが特にひどく、

  • ウィンドウ移動時にウィンドウハンドルと1画面以上ずれる
  • ウィンドウラベルをダブルクリックすると右に1画面程度ジャンプする
  • 左側のディスプレイ(GTX750Ti上)に出すとブラックアウトしたりする
  • YouTube再生がしょっちゅう止まる

といった問題が発生する。そのほかにもCinnamonが時々クラッシュしたりもする。
Gtkのウィジットの描画が欠損したりもする。

Chromiumのワークアラウンドとしては、「システムタイトルバーと枠線の使用」を音にすれば改善する。
これはVivaldiでも同様である。

</ins>

問題の根幹

Base Mosaicは対応するidentical(全く同一の) cardでなければならない、ということらしい。

異なるカード間でBase Mosaicを構成することはできず、まだ、

PCI IDs do not match.

でいうIDとは、BusIDのことではなく、Product IDのことであるとのこと。

また、MultiGPUも同様の制限がある(これは調べてもSLIに関することばかりで出てこない)とのこと。

結論

  • hp Z400でGeForce GTX750Tiは動作する
  • Quadro2000とGeForce GTX750Tiは同時に動作する
  • Windowsでは特になにもしなくても(ドライバーアップデートは必要だった)それぞれにつないだディスプレイが出る
  • Linuxの場合、解決方法はXinerama/Base Mosaic/SLI Mosaic
  • Base MosaicあるいはSLI Mosaicはidentical card(完全に同一のカード)でなければならない
  • Xineramaはnvidiaドライバーでサポート外とあるが、不安定ではあるものの動作する
  • 現在最新のnvidia-settingsだと、Base Mosaicが組めない環境ではBase Mosaicの選択肢は出ない
  • 画面数を増やしたいだけであればカードを増やすのは有効。処理性能は増えない
  • SLIする場合はSLIケーブル/ブリッジでカードを接続する必要がある
  • SLIであれMultiGPUであれ、複数カードによるアクセラレーションはidentical cardsである必要がある
  • ffmpegはプライマリであれセカンダリであれ、設定なしに性能の高いGTX750Tiをエンコードに使用した
  • OpenGLやエンコーディング性能でも、Quadro2000よりもGeForce GTX750Tiのほうがはるかに速い

</ins>

Linuxにおけるビデオフォーマットの取り扱い(H.264/H.265/VP9 WebM)

ビデオのファイルフォーマットについて

ビデオのファイルフォーマットは、

  • 動画部分
  • 音声部分
  • それをまとめる部分

の3パートからなる。
今回は

  • H.264+AACのMPEG-4 Part14(mp4)
  • H.265+AACのMPEG-4 Part14(mp4)
  • VP9+OpusのWebM

の3種類についての検討となる。

検討すべき点

画質とファイルサイズ

画質面では基本的に非圧縮が最良である、と考えて良い。
しかし、それではあまり巨大なデータになってしまうので、圧縮することになる。
非可逆圧縮を行えば画質は劣化する。これは、音声と同じ理屈である。可逆圧縮も存在するが、やはりサイズが大きく、現実的ではないとみなされている。

そもそもの話として、そんな巨大すぎるデータを扱うことは難しいため、動画素材が出力される時点でなんらかの圧縮がされているというのが普通だ。
それは、例えば録画ソフトだったり、ビデオカメラだったりだ。録画の場合、録画時に圧縮されるだけでなく、録画ソースがデジタル動画なら、その動画自体が既に圧縮されていて、2回目の圧縮をかけることになる。

いずれにせよ、非圧縮の映像ソースが手に入らないのであれば、映像ソースの状態が最良である。画質向上のための加工をすれば改善する可能性はあるが、それは普通ではない。

そこからさらにファイルサイズを小さくするために変換するか、あるいは取り扱いやすさのために変換するか、ということになる。
場合によっては、カメラから出力されるデータの圧縮形式を選べる、という場合もある。

つまりここで問題になるのは、ファイルサイズに対して画質の劣化がどれくらい抑えられるか、である。

速度

エンコード時に時間がかかるコーデックは、動画を変換してファイルとして出力する際に時間がかかる。

デコード時に時間がかかるコーデックは、再生が間に合わず飛んでしまうかもしれない。

ただ、実感としては、デコード時の所要時間の問題というよりは、ビットレートが高い動画は飛びやすい、という印象だ。
ただし、動画再生の重さには関係する。

ハードウェアアクセラレーション

デコードが重いコーデックであっても、ビデオカードがそのデコードを担うことができるのであれば、それは問題にならない。

これは、プロセッサ、ドライバ、そしてアクセラレーションの仕組みの全てがサポートしていなければ利用できない。

フォーマット

H.264

H.264(≈MPEG-4 AVC)は2003年に勧告された新しいフォーマットで、現在の主流といっていい。
MPEG-1から続く基本的な動画圧縮アルゴリズムを改良したもので、かなりの高圧縮でも目立った劣化が少ないことから主流となった。

高機能・高圧縮・高画質とメリットは大きいが、H.264を「使わない理由」といえば、エンコードに時間がかかりすぎるため、というのが一般的だ。

一般的なので、とりあえず迷ったらH.264で良いと思う。
LinuxではVDPAU/VA-APIにおいて、nVidiaグラフィックスにオープンソースまたはプロプライエタリのドライバ、さらにAMDグラフィックスにRadeonまたはCatalystドライバでH.264アクセラレーションがサポートされるというのは大きなメリットだろう。
どうもAMD APUでうまく動作してくれていないが。

nVidia Quadro 2000グラフィックスにLinux 4.3 + nvidia 1:352.53-1という構成のvdpauinfoはこのようになっている。

H264_BASELINE                  --- not supported ---
H264_MAIN                      41  8192  2048  2048
H264_HIGH                      41  8192  2048  2048
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---

Quadro 2000はFeature set Cなのでこうなっているのだろう。

非常に扱いやすい、お勧めできるフォーマットだ。
可搬性からいえば、MPEG-4のほうが上かもしれない。ちなみに、MPEG-4 Part2は、H.263がベースで、H.264と比べると劣っている。

H.265/HEVC

承認されたのが2013年という非常に新しいコーデックで、携帯向け映像配信から8kビデオまで幅広くターゲットにしている。
dアニメストアがH.265を採用していることで知られている。

同等の画質でH.264の半分の容量、という触れ込みだ。
非常に優れたフォーマットだが、新しすぎて結構厳しい。ハードウェア支援が追いついておらず、それでいて処理は非常に重い、というのが辛い部分でもある。
将来的には、H.265を置き換えていくのだろう。

H.265をサポートするFeature set FはGTX950/960のみで、TITANも含まない。QuadroシリーズはM6000まで含めて最大でもEまでだ。H.265が新しいフォーマットであることもあり、対応はまだまだ進んでいない、最新のカードでようやく対応がはじまったということなのだろう。

ちなみに、エンコード速度の差はあまりなかった。
というよりも、私の環境ではH.264の高品位エンコードが結構遅いので、H.265を若干軽い設定にしたこともあってか、2.1fpsでどちらも同じだった。

VP9 (WebM)

H.264はかなり複雑な特許関係になっているし、H.265はMPEG LAが特許を保有している。
こうしたことを嫌う人は、かなりいる。

Mozilla Firefoxは、以前mp4系ではなく、Ogg Theoraをサポートしていくことを表明したことがある。

Ogg Theoraについてはちょっと説明が必要だろう。Oggというのは、そもそもコンテナフォーマットで、任意の数の対応したコーデックを格納できる。一番有名なのは非可逆圧縮音声コーデックのVorbisで、OggコンテナフォーマットにVorbisを格納したものがOgg Vorbisだ。

そして、可逆圧縮音声コーデックのFLACを格納したものがOgg FLAC(FLACはOggに格納しないほうが普通)、動画コーデックのTheoraを格納したものがOgg Theoraだ(音声はSpeex, Vorbis, CELT, Opus, FLAC, OggPCMのどれか)。

このあたりは、Xiph.orgが開発したロイヤリティフリーコーデック/フォーマットで、OSSの一翼を担うと自負するMozillaなりのプライドだったのだろう。
しかし、そもそもOn2のVP3をベースにしたTheoraはあまり品質の良いものではなく、結局普及もしないままだ。オープンなのは良いことだが、Ogg Theoraをサポートしているプレイヤーも少なく、最初から影の薄い存在だ。

動機は似ているが、よりアグレッシヴに、技術的な主導権を握ろうとしたのがChromeの開発を行うGoogleだ。GoogleはChromeへの搭載とYouTubeでの採用の両面から働きかけている。

GoogleはコンテナフォーマットWebMを開発し、VPコーデックを開発してきたOn2を買収してその最新コーデックであるVP8を採用、音声フォーマットはVorbisをメインに採用してきた。
VP8に関しては特許問題があったが、最初から利用者に対する開放という方針は貫かれている。その後特許問題をライセンス契約締結によって解決し、自由に使えるようにした。

主導権を得るために、かなり献身的な振る舞いをしていると言ってもいい。品質面に問題があるTheoraに対して、VP8を採用するWebMは品質面でもH.264+AACのmp4に対抗できる存在だった。
現在においてもこの試み、つまりオープンソースによってデファクトスタンダードを塗替え、フォーマットを統一してリーダーボードを握るというのは依然として野心的だが、挑戦は続いているし、かつ悪くない話でもあり失敗もしていない。

そして、WebMの第二世代ともいうべきサポートが、VP9ビデオコーデックとOpusオーディオコーデックの採用だ。

VP9は、VP8に対して同一画質でビットレートを半分にする、ということなので、その目標はH.264に対するH.265と等しい。仕様がH.265と比べてもシンプルで、YUV444, 12bit色深度, アルファチャンネル, 深度チャンネル, 8kと機能はむしろ勝ってさえいる。
2011年にスタートしたプロジェクトで、後追いだったVP8とは違い、H.265に対して一歩前をいく状況で始まっている。

さらに、音声コーデックのOpusは、スピーチ向き音声フォーマットのSpeex、あるいは音楽向けコーデックのVorbisを越える存在として登場している。
IETFによって開発され、RFCで標準化され、リファレンス実装がBSDライセンスでリリースされている。Xiph.orgが手動するVorbisやFLACよりも、さらに文句なしにフリーだ。
音質がいいだけでなく、低レイテンシも実現している。ビットレートによって(場合によってはシームレスに)モードが切り替わり複数の仕様が混在するのは美しいとは言えないように思うが、実際に品質は素晴らしいのだから文句のつけようがない。
政治的紛争と無縁というわけではないのだが、Vorbisの次を叶えるコーデックではあるだろう。

つまり、完全に特許と制約に基づいたH.265+AACに対して、課題はあれども利用者としては自由に使うことが約束されているVP9+Opusでは、まずそこで魅力がかなり異なる。
しかも品質面でも優れている。

だが、決定的なディスアドバンテージもある。LinuxのVDPAUにおいてどころか、WindowsのPureVideoでさえ、VP9はもちろん、VP8もハードウェアアクセラレーションがサポートされていない。
VP8がサポートされていないということは、将来的にも大きな状況の変化がない限りはVP9も含め、WebMでのハードウェアアクセラレーションはサポートされないのだろう。
H.265のサポートはもう見えている。これは決定的だ。

比較

実際に比較してみた。

エンコーディングはだいたい同じくらいの時間がかかった。VP9+OpusのWebMが3.0fps出ていて1.5倍ちかく速かったが、それでもとても遅いのであまり意味はない。

サイズを見てみよう。

-rw------- 1 aki users 194571866 12月 10 10:59 moto-mad-01.h264.mp4
-rw------- 1 aki users 153719824 12月 10 17:14 moto-mad-01.h265-crf20.mp4
-rw------- 1 aki users  96287262 12月 10 09:13 moto-mad-01.h265.mp4
-rw-r--r-- 1 aki users 492912031  4月 16  2015 moto-mad-01.mov
-rw------- 1 aki users 215367319 12月 10 11:50 moto-mad-01.webm

H.264はCRF18、h265-crf20とWebMはCRF20、h265はCRF24だ。
ちなみに、元のMOVファイルはH.264+AC3である。

CRFが同一基準にならないようにしか見えないので、それぞれのコーデックで画質と容量の関係を探らなければ意味がなさそうだ。
実際、FFmpeg公式で、x265については

default CRF of 28. The CRF of 28 should visually correspond to libx264 video at CRF 23, but result in about half the file size.

と言っていたりする。色々やってみなければ分からないのだが、実際H.265の「劣化が少ない」は納得できる。H.264と比べてもそこは結構違う。H.264でCRFを上げていくとかなり乱れるので、ケータイ向けに用意したりするとはっきりと違ってくるのだ。

ちなみに、この生成物の感覚的な画質の比較でいうと

  • H.264は若干粗い。滑らかさが足りない
  • H.265は綺麗。CRF20かCRF24かの違いはほとんど分からない
  • WebM(VP9)はなめらかに見えるが、動きが激しいところではざらついて見える

結論

  • 今のところはH.264を使うのが可搬性を考えてもまとも
  • どうしてもファイルサイズを落としたい場合、H.265は結構いい
  • とりあえずVP9を使うメリットは、OSS派以外にはなさそう。エンドユーザーから見るとこだわりがない限り動機としてはかなり弱い
  • 将来的にはH.265に移っていくと考えて良いと思う
  • WebMがもっと普及して、ハードウェアアクセラレーションも対応してくれると嬉しい
  • そもそも、現在大抵の動画はH.264になってるし、普通の人がコーデックを選ぶ機会があまりないと思う
  • 昔のWMVやRM抱えてる人はWebMにしちゃうのもいいかもよ

FM2+Killer GodavariとXeon W3565+Quadro2000マシンを比べてみた

コンピュータの仕様

FM2+88X Killer

  • AMD A10-7870K APU
  • DDR3-1600 8GB RAM *4
  • 320GB 2.5inch HDD SATA2 (Windows System)
  • 256GB ADATA SSD SATA3 (Linux SYstem)
  • UEFI Boot

hp Z400

  • Intel Xeon W3565
  • nVidia Quadro 2000 Graphics
  • DDR3-1366 2GB ECC Unbuffered RAM * 2 + DDR3-1600 4GB Non-ECC Unbuffered RAM * 2 (DDR3-1066 driven)
  • 250GB Samsung 3.5inch HDD SATA2 (Windwos System)
  • 120GB Corsair SSD SATA3 (SATA2 Connection) (Linux System)
  • Legacy Boot

Windows Experience Indexによる比較

項目 FM2+Killer Z400
CPU 7.4 7.5
Memory 7.4 7.5
3D Graphics 6.8 7.0
2D Graphics 6.8 7.0
Disk 5.9 5.9

「Z400のXeon W3565+Quadro2000のほうがわずかに速い」というのは、ベンチマークの通りで面白みもない。

だが、見るべきところはある。

まず、メモリーもz400のほうが速い、ということだ。
メモリーはz400は1066で、FM2+Killerは1600で動作していて、FM2+Killerのほうが速いはずだ。
しかも、FM2+Killerはデュアルチャンネル構成だが、z400はトリプルチャンネルだが2種類を2枚ずつで機能していない。
それでもメモリアクセスはz400のほうが高速だという。

さらに、グラフィックスにしても、3DグラフィックスはDirectX9でテストされるが、OpenGLに特化していて3Dグラフィックスを得意としないQuadroであるにもかかわらず、Radeon R7を内蔵したGodavari APUに優るという。

AMDという第二の選択に対して、Intel+nVidiaという定番構成がいかに強力かがよくわかる。
理屈では見えてこない差があるようだ。

LinuxでのCPU処理

実用的かつ単純な方法として

time xz -zc image.iso > /dev/null

によって比較。これは、今のところxzが最も時間がかかっているためで、imageはtmpfs上にDebian jessie DVD 64bit(debian-8.2.0-amd64DVD-1.iso)。SystemRescueCDをnomodeset+nokmsboot+docacheでブートし、wgetでイメージを取得してテストした。つまり、イメージはRAM上にあり、ディスクアクセスは発生しない。

FM2+Killerは

1862.41s user 3.46s system 99% cpu 31:09.98 total

対するZ400は

1743.0s user 1.92s system 99% cpu 29:09.72 total

やっぱりZ400のほうがやや速い。

xzはコアをフルに使い切れないことが多いのだが、日常的にすることで、全てのコアを使い、かつ負荷や結果が一定になるものが思い浮かばず、xzにした。差自体は恐らくこんなものだと思う。ImageMagickでは極端に差が出るが、およそこれくらいの割合でZ400のほうがいつも速い。
プロセス数の多い処理はZ400のほうが有利か。

LinuxのGPU処理

OpenGLの処理速度を比較するため、Linux上でのベンチマーク。

Windows上の普通のベンチマークとは色々と事情が変わってくる。

  • LinuxではDirectXは使えないため、OpenGLを使う
  • いずれもメーカー提供のプロプライエタリドライバを使用するが、Windowsドライバと比べるとかなり性能が低い。特にAMD Catalystは出来が悪い
  • Quadroは元々OpenGLグラフィックスであり、AMD APUは一般向けであるためDirectXグラフィックスである

テストはUnigine Heaven Benchmark 4.0を使用した。
なお、再起動した上で新規ユーザーでテストすることで差異を可能な限り埋めてはいるが、CatalystがLinux 4.2ではうまく動かないため、Linux 4.1を使用している。

いずれもプロブライエタリドライバを使用し、ディスプレイはFHDの1台にセッティングした。

  • Render: OpenGL
  • Mode: 1920×1080 fullscreen
  • Preset: Custom
  • Quality: Low
  • Tessellation: Disabled
Term FM2+Killer Z400
Platform Linux 4.1.12-1-MANJARO x86_64 Linux 4.2.5-1-MANJARO x86_64
CPU Model AMD A10-7870K Radeom R7, 12 Compute Cores 4C+8G (3892MHz) x4 Intel(R) Xeon(R) CPU W3565 @ 3.20GHz (3200MHz) x8
GPU Model AMD Radeon(TM) R7 Graphics (1024MB) x1 Quadro 2000 PCI Express 352.55 (1024MB) x1
FPS 22.4 26.0
Score 563 655
Min FPS 7.7 17.7
Max FPS 47.0 39.8

FM2+killerも体感よりはかなりがんばっている。
FM2+Killerはビデオ再生がひどいため、まともに動くとは思わなかったのだ。

Max FPSは大幅に逆転している。
だが、全体にはWindows Experience Indexの結果と比べて、さらにもう少し差が開いた印象ではある。

LinuxではCatalystドライバに不具合がかなり多いため、数値よりも快適性には大きな隔たりがある。

しかし、ドライバの出来と、openGLに特化したQuadroであることを考えると、もっと差が開いて然るべきだったけれど、意外とGodavariが健闘した。

結果を受けて

FM2+Killerの構成は、もともとはKaveri(A10-7700K)で、およそ19万円かかったが、これは大容量メモリと、多数のハードディスクのためだ。

例えば、TSUKUMOのAMD A10-7870K Black Edition BOX スペシャルセットが34344円(2015-11-07現在)となっている。
実際は、4GBx2 RAMであること、Mini-ITXマザーボードであることを考えれば、TSUKUMOで計算するとFM2A88X Killerが12480円、A10-7870Kが18274円、W3U1600HQ-8GC11(8GBx2)が12150円で42904円。
PCケースDefine R5が13014円、Seagate STT1000DM003が5992円、慶安 静か KT-S400FXAが6151円なので、全体では68061円になる。

高機能を狙った構成なので、もっと安く上げるのであれば、4.5万円くらいで収まる可能性もあるだろう。だが、だいたいそのあたりであり、別の見方をすればPC1台組むのに必要なコストがそれくらいであるとも言える。
A10-7870Kはミドルに迫るくらいの性能を持ってはいるが、素晴らしく快適な性能でもない。性能的には中途半端だが、コストパフォーマンスは良い、という微妙な立ち位置だ。
「下の上」である。

しかし、「微妙な割に便利」でもある。
オフィススイートななどの基本的な事務、1080p動画再生を含むインターネット体験、そこまで本格的でなければ3Dゲームだってできる。
つまり、一般的なユーザーのニーズを満たすことができるのだ。

ただし、Windowsであれば。Linuxでは、そのパフォーマンスが十分に発揮できず、実際Windowsで不足を感じないのに、Linuxでは随分ひっかかる。

加えて、「性能はいらないが機能が欲しい」というユーザーにも安価に応えられるのは大きい。例えばトリプルヘッドディスプレイや、4kディスプレイが欲しい、eSATAが欲しい、USB3が欲しい…といった要求にも、マザーボードが安いので対応に費用がかからない。
性能はともかく高機能を要求する場合には結構な価格差が出る。

一方、Z400は、秋葉原で3万円ほどで買った中古だ。

3万円というと、自作にせよ、BTOマシンにせよ、かなり困難なラインになる。非常に小さな、ラップトップと変わらないようなものなら購入できるが、本当に最低辺のPCだ。
だが、最新型を購入できてしまうために、中古ならでは、とはいいにくい。

ちなみに、Windowsを含む場合は、3万円で自作は恐らく出来ない。

Z400は、2010年のhpのエントリーワークステーションだ。
エントリーモデルとはいえミドルタワーのワークステーション。普通の人が手にするようなものではない。
安価なhp Z230SFFでも123,200円から。値段的にはそこまでもないとも取れるが、用途が特殊だ。
Z400の構成は、当時でいえば、パソコンならば最上位クラスにあたる。

PCが5年使い続けられることはない。性能の変化、規格の変化、タイミングにもよるが、どうしても5年はもたない。3年が良いところだ。

だが、要求水準が元より異なる場合はその限りではない。5年前は時代遅れのポンコツだが、それでもかたや5年前の、パソコンでいえばハイエンドに匹敵するクラス。かたや最新ながら、あくまで安価でありながら性能を確保したことが魅力であるエントリー・モデルだ。

それを比べた結果、「5年前のワークステーションのほうがやや高性能だった」という結果が出たということだ。これをどう捉えるか。

安価なマシンを求めるのであれば、秋葉原で、良い中古マシンを確保したほうが性能は高い。

これはおおよそ真だ。ただし、機能的にはどうしても劣る。タイミングによっては、旧規格を採用しているために非常に苦労する場合もある。
Z400はSATA2, USB 2.0といった旧規格であり、新規格には対応していない。小さなことだが、不便でもある。
メモリの速度は1066だ。1600が普通に使える今となっては低速で勿体無くもある。
そして、グラフィックスは4kより前の時代であり、4kに対応しておらず、トリプルヘッドにも対応していない。

こうした機能面では最新のGodavari、それも高機能マザーボードのFM2+Killerのほうが圧倒的に優れている。
もし、Windowsを普通に使うのであれば、私はFM2+Killerをメインにしていたと思う。

だが、Linuxでは随分とエクスペリエンスの差がある。
さらにいえば、AMD CPUだとオーディオエンジンが頻繁にドロップしてしまう(SONARにおいて)。
性能差というよりも、快適さが随分と違う。さすがに、王道、Intel+nVidiaという構成は強かった。

もしあなたが、何らかの理由でこのようなコンピュータを欲したとする。
もちろん、「普通にしか使わないから」といって「普通な用途に適したコンピュータ」を選ぶことはあまり勧められない。
ライフタイムが短くなるからだ。
もう少し視野を広くもったほうが良い。それに、そこそこ大きい買い物なのだし、もっと積極的に楽しんだほうがお得だ。

だが、色々理由は考えられる。
私のように急な故障で、予算はないがとりあえずまともに使えるレベルのーたが早急に必要だとか。
Windows XPマシンのリプレイスが必要だが、予算が確保できておらず、導入までの時間を遅延させたいとか。

また、業務利用の場合、要件が全く変わらず、「環境が変化しないこと」が求められる場合もある。
事務仕事や、株取引などにおいては、特に変更される必要はない。
定期的に必要にはなるが、刷新タイミング意外では毎日同じように業務を遂行できることのほうが大事だ。
この場合、特に故障などがなければ、規格が時代遅れといった問題はない。そのため、現状で使えるのであれば、そのマシンが使える限り、もしくは刷新がなされるまで使える、という考え方が可能だ。
ちなみに、DTMは環境を更新し続けるのが一般的なのでむしろ最新マシンが必要になるが、環境を変えないなら変えないでもなんとかなるものだ。

そのような場合においてどちらを選ぶべきか?

中古のほうが若干だがお得感はある。だが、新品のほうが高機能で快適である可能性がある。

もちろん、中古の場合は保証がない。新品の場合はある。
だが、5年も前のもので、しかもずっと使われてきたものであるならば中古はそうそう壊れない。機会の故障率はバスタブカーブを描くため、故障するなら普通はそれ以前に生じる。
新品であれば保証が利き、修理も依頼しやすい。

どちらが良いかは、好き好きとしか言いようがない。
そして、自作も中古も、趣味が入っていないとやっていられない。
本当の業務システムでやるようなことではない。

nVidia vs AMD (nvidia-driver vs catalyst) on Linux

AMD APU (Radeon R7)からQuadroに変わって猛烈に快適になった私のPC。これまで抱えていた非常に多くの問題が、なんだか勝手に解決した。

今までの苦労はなんだった。

そんなにRadeonがダメなのか?それとも、そんなにCatalystがダメなのか?
Windowsでもマウスカーソルが歪むという話は出ているのであまり良くはないだろうとは思うけれど、それともGeForceだと同じようなものなのか。

Phoronixの記事を見ると、この場合はLinux Gamingだし、しかもGeForceとRadeonだしではあるけれど、この情報から明らかなことがある。

RadeonよりもGeForce(グレード関係なし)。

RadeonよりもGeForceのほうがゲームで好まれるというのはあるが、WindowsにおけるそれはどちらかというとGeForceに最適されているからである、という話をきく。Radeonに最適化されたゲームにおいてはRadeonのほうが快適だというのだ。

だが、Linuxのこの結果は、10万円クラスのR9 Furyが3万円以下のGTX 950と同等というわけのわからない結果になっている。

つまり、Catalystはひどい、と。R9 Furyみたいなモンスターを腐らせてしまうくらいに。

AMDはLinuxサポートの強化とかいってなかったか?それでこれか?
様々な挙動不審も、CatalystドライバーがLinux向けにちゃんと作られていないからだろう。

Manjaro Linux 0.8.13 セットアップ (5) Z400編

はじめに

システム更新

$ sudo pacman -Syuu

Grub設定。nomodesetを入れる

$ sudo nano /etc/default/grub

最新カーネル

$ sudo mhwd-kernel -i linux42

ビデオカード

$ sudo mhwd-gpu --setgl nvidia

再起動。

パッケージインストレーション

  • nss-mdns
  • bind-tools
  • encfs
  • ctags
  • leafpad
  • zsh

ホスト設定を行う。

必要ならchsh

  • medit
  • geany
  • geany-plugins
  • smplayer
  • smplayer-themes
  • smplayer-skins
  • opera-developer
  • cinnamon
  • plasma
  • kde-applications
  • fcitx-kkc

X関係に問題が出るので、Zshでホームディレクトリ上で(多分、extended_globを伴って)

$ rm .[xX](^(profile))

入力関係の設定をしておく。

  • emacs
  • xsane
  • fetchmail
  • spamassassin
  • razor
  • tasque
  • skype
  • skype-call-recorder
  • openssh
  • sshfs

sshの設定

  • lv
  • w3m
  • amarok
  • audacious
  • audacious-plugins
  • libcue
  • audacity
  • sox
  • zsh
  • gtkhotkey
  • libgcrypt15
  • inkscape-gtk3-bzr
  • sylpheed
  • ttf-tahoma
  • fcitx-anthy
  • ttf-ricty
  • ttf-migmix
  • ttf-rounded-mplus
  • ttf-migu
  • ttf-sawarabi-gothic
  • ttf-hanazono
  • ttf-mikachan
  • ttf-sawarabi-mincho
  • ttf-mona
  • ttf-sazanami
  • ttf-monapo
  • ttf-kibitaki
  • ttf-mplus
  • ttf-ume
  • ttf-kochi-substitute
  • ttf-ohruri
  • ttf-vlgothic
  • ttf-koruri
  • ttf-vlkoruri

Infinality, Java, Mozc-UTは猛烈に時間がかかる。

  • cairo-infinality
  • fontconfig-infinality
  • freetype-infinality
  • jre8-openjdk-infinality
  • fcitx-mozc-ut

続き

  • kde-gtk-config
  • ttf-tahoma
  • bundler
  • fcitx-anthy

    nVidia向けのビデオ関連。

  • libva-vdpau-driver
  • gst-vaapi

続き

  • gtk-theme-preference
  • font-manager
  • gtk-chtheme
  • alsaplay
  • gedit
  • gedit-code-assistance
  • gedit-plugins
  • evince
  • gnome-terminal
  • tomboy
  • mcomix
  • gnome-screenshot

Gnome Screenshotは設定が必要

  • xlhtml
  • vivaldi

Vivldiは必要か??
Wine関連

  • wine
  • winetricks
  • twine
  • wine-mono
  • q4wineyaourt
  • wine_gecko

Haskell (for pandoc)

  • ghc
  • cabal-install
  • alex
  • happy
  • texlive-core
  • texlive-langcjk

続き

  • chromium-pepper-flash
  • dialog
  • perl-tk
  • psutils
  • ruby-kramdown
  • livestreamer

ウェブブラウザ。

  • midori
  • qupzilla
  • rekonq

続き

  • xnviewmp
  • nkf

Gtk+2テーマ関連

  • oxygen-gtk2
  • lib32-qtcurve-gtk2-1.8.18-1
  • lib32-qtcurve-qt4-1.8.18-1
  • lib32-qtcurve-utils-1.8.18-1
  • qtcurve-gtk2-1.8.18-3
  • qtcurve-qt4-1.8.18-3
  • qtcurve-qt5-1.8.18-3
  • qtcurve-utils-1.8.18-3

Gtkテーマ, Sylpheed, Leafpad

Gtk+2アプリケーションの中に、Gtkテーマを原因にSegmentation faultを起こす奴がいる。

SylpheedはGtk+2専用テーマでなければいけない。場合によってはフォールバックできるが、できない場合もある。フォールバックできる場合も起動時間が全く異なってくる。

そこで、Gtk+ 2専用のOxygen-Gtkにしたのだが、なんとLeafpadはOxygen-Gtkで動かない(!)

QtCurveが最も簡単に解決してくれるが、それも嫌なので、Leafpadだけは代替プログラムを書いた。

#!/bin/sh

export GTK2_RC_FILES=$HOME/lib/alt-gtkrc-2.0

exec leafpad

で、alt-gtkrc-2.0でQtCurveを指定している。

Gtk+2フルなテーマは

  • Clearlooks
  • Industrial
  • Mist
  • Redmond
  • ThinIce
  • Xfce-redmondxp
  • Xfce-kolors
  • Xfce-dawn
  • Xfce-dusk
  • Xfce-cadmium
  • Silver

もしかするとoxygen-gtk3-gitを入れるとダメかもしれない。

なお、Gtk3はCinnamonで、Gtk2はgtk-chthemeで設定。

文字入力設定

入力関係のため、~/.xprofile

export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=/home/aki/bin:$PATH

ログアウトしてログインしなおしたほうが良い。
gtk-query-immodules-*は必要なかった。

Gnome Screenshot

デフォルトの保存場所を変更する。

gsettings set org.gnome.gnome-screenshot auto-save-directory /path/to/directory

Maxthon

リポジトリ落ちしているので

$ git clone --depth=1 git://pkgbuild.com/aur-mirror.git
$ cd aur-mirror/maxthon-browser
$ makepkg
$ sudo pacman -U maxthon-browser-1.0.5.3-4-x86_64.pkg.tar.gz

英数キーでCaps Lockになる

Archのevdevがいうこときかなくなっているので、.xprofileあたりに

setxkbmap -model jp106 -layout jp

Pandoc

$ export PATH=$HOME/.cabal/bin
$ cabal update
$ cabal install pandoc

openSSH

$ sudo systemctl start sshd
$ sudo systemctl enable sshd

ホスト設定

MDNS (Zeroconf)

/etc/nsswitchhost項目にmdns_minimalを追加。filesよりも後に。

fcitx-mozc-utのために

/etc/hostsdig japanese-usage-dictionary.googlecode.comした結果に基づき、このホストをIPv4で決め打ち。

ビデオの設定

Quadro2000でのVDPAUについては、単純にnon-freeでインストールしていれば、有効になっている。
nvidia-utilsでOKだからだ。

VA-APIについては、libva-vdpau-driverをインストールし、環境変数$LIBVA_DRIVER_NAMEの値にvdpauをセットするようにすれば良い。
私は~/.xprofileに記載した。

Smplayerは「ビデオ」タブで出力ドライバーvdpauに、
パフォーマンスタブのハードウェアデコードvdpauにする。

VLCについては、ハードウェアアクセラレーションによるデコードX11のVA-APIビデオデコーダーに設定する。

Flashは/etc/adobe/mms.cfgのコメントアウトされているEnableLinuxHWVideoDecodeを有効にする。


追記

Conkyを触ってみたのだが、AMD APUで発生していた

  • execiしていると2回目から表示が消える
  • RSSが取れないことが多い

RSSがとれないというのは、RSSのエントリが表示されない状態になる。Conkyの組み込みrssの話だ。取れたかとれなかったかの状態は永続するが、取れないことが圧倒的に多く、5つのRSSをまとめている部分に関しては、何十回も起動・停止しなければ十分に表示できなかった。

また、Conkyの負担もかなり大きかったので、結局使用をやめていたけれど、Z400になってなんの問題もなくなった。

やはりLinuxにはQuadroだ。

hp Z400 ( Intel Xeon W3565 + nVIDIA Quadro 2000 ) Manjaro Linux

経緯

事はデスクトップPCが壊れたことに端を発する。

起動不能となり、配線のチェックなども行ったものの解決せず、結局秋葉原まで持ち込み修理に出してきた。

BUYMORE秋葉原本店で購入したものであるため、Unicom秋葉原サポートセンターに持ち込み。
事前に、ケースが不要であることを確認し、電源と、マザーボード+メモリ+APUの状態で持ち込んだ。

ちなみに、台風のため(甚大な被害を出したあの雨だ)、翌日の持ち込みとなった。

秋葉原サポートセンターは非常にわかりづらい場所にある。随分探しまわってしまった。
総武本線の高架下沿いで、JRの駅からは中央通りをはさんで反対側、御茶ノ水方向で、KFCの向かいだが表ではなく裏側の向かい、マウスコンピューターの地下1階で、しかもその階段はサービスカウンター沿いの奥にある。

とりあえず持ち込んだはいいが、なんといっても台湾送りのため、1ヶ月程度はかかるもよう。その間仕事ができないというのは、とても困る。

暫定的な対応

とりあえずは、ProLiant MicroserverのSlaveディスク4台を抜き出し、Masterディスク4台を投入、Masterのキーファイルを入れ、Masterをマウントできるようにする。

SlaveをMasterに昇格させると数日分の作業データを失うこととなる。
基本的にはSlaveはMasterディスクの損失に対する存在だ。

これによってProLiant MicroServerで本来のデータが扱えるようになり、sshfsでアクセスすることでデータにはアクセスできるようになった。

だが、環境に関するデータは結構困る。
FUSEやNFSでマウントしているデータへのアクセスはかなり制限される。FUSE環境だとアクセスできるのが所有者に限られるためsudoが使えない、という程度はわかるが、なんとSpamassassinがちゃんと動かない。ちなみに、sudoでもsu -cでも動かないが、su -なら動く。

細かく様々制約され、「なんだか変な挙動」「なぜか動かない」が蓄積し、作業効率を大幅に下げる。

問題はそれだけではない。それをドライブする端末がないのだ。
ThinkPad e440は異常なまでに不安定であり、作業効率は10%も出ない。1分ごとにXが落ちて、その再起動に30秒程度かかるなど話にならない。

ちなみに、e440はWindowsの初期状態でもかなり不安定な挙動を見せる。もう、Lenovoのことはだいぶ嫌いになっている。

かといってとProLiant MicroServerの直接利用も性能的にも厳しいし、映像出力系にトラブルがあり、難しい。

対策の候補

いずれにせよ、必要だと分かっていた冗長系投入を遅延させていたのが問題であり、冗長系を投入するのが妥当だろう。
窮状にあって苦しいが、やむを得ない。

候補は以下だ

  • 直近の将来の要求である4k x3モニターが可能なメイン系(現行を冗長系へ) (14万円)
  • あくまでも冗長系の新品AMD A4マシン (3万円)
  • あくまでも冗長系の中古マシン (2万円)
  • 活用可能な中古マシン (4万円)

4k x3を可能にするのは、Quadro K1200が最低ラインのようだ。K620に関しては、DP Hubによる分岐もFQHDまでしかサポートしない。そのため、結構な額になった。なお、全体はSkylakeで構成することを想定した。

やはり、額が大きいことと、これからSkylakeも安くなっていくだろうし、USB CやDDR4メモリなど新規格が続々の中ではなかなか筋が悪い。

新品AMDマシンは構成が近いため、冗長環境を作りやすいが、既に問題が大量にあり、しかも十分なパフォーマンスがないというのに、さらに下位のものを選ぶのはなかなか厳しい。

さらに、メーカーが非常に評判が悪く、保証どころか修理すら預けられない感じであったため、それならば中古のほうが良いと判断し、最初に消去した。

2万円はCore i7-870、4GB RAM、GeForce 250GTマシン、4万円はXeon W3565, 4GB RAM, Quadro 2000マシンだった。

Windows的に、そしてベンチマーク的に測ればおそらく大差ない。実際ベンチマークを見るとXeon W3565が6,093、i7 870が5,480で、7700kは5,247となっている。

Skylake i7のベスト(i7-6700k)は10,957、4770kでも10,184ということを見れば、やはりふるさは否めない。
一方で逆の見方をすればそれで最新のKaveriよりも上なのだから、ハイエンドってすごいなぁ、とも思う。

GeForce GTS250は随分数字が小さいことに不安を覚えたが、この時は全世代のハイエンドである9800 GTX+(上から2番目)の名前だけを変えたのがGTS 250で、このシリーズでは上から6番目、下から4番目、とのことだ。

古いので、最新ゲームは結構きつそう。時代を感じる。

もっとも、もうこの世代になるとGeForceはOpenGLを切る方向だった。
LinuxはDirectXを使わないし、安定性を求めるならQuadroのほうがいい。nVidiaはQuadroに関してはLinuxのサポートも手厚い。

Windows上での性能は差が小さいが、私が使う上での価値はかなり差が開いている。妥当な価格差だ。

これだけの性能があれば、何かの時に助けてくれる気がする…ということで、hp Z400 workstationを購入した。

hp Z400 Workstation

2009年に投入された前期型型Z400ワークステーションは、CPUはXeon W3520からW3580までで、これら対して5250円の水冷オプションがある。

グラフィックスボードを持たない最小構成で22万円程度、Quadro FX1800を含むと27万円程度とのこと。

後期型はW3520はそのままだが、W3565, W3680, W3690とプロセッサが変更され、グラフィックスのラインナップも一新、QuadroだけでなくFireProも加わっている。
また、メモリスロットを4から6に増やし、最大24GBメモリをサポートするようになった。チップセットはintel X58とのことだ。

最小構成+水冷を99,750円で提供していたらしいが、最初構成で買う人がいたのだろうか?

SASモデルもある。SASモデルでなくてよかった。

私が購入したモデルは、Xeon W3565プロセッサ, 4GB RAM, Quadro 2000の水冷モデル。
SATA仕様で、電源は475Wブロンズ、X58チップセットの後期型だ。

光学ドライブを搭載している。DVD-ROMドライブやBDドライブもあったようだが、DVDスーパーマルチドライブだった。

Xeonについて

Intel XeonはIntelのワークステーション/サーバー向けのCPUである。

ワークステーション向けは処理性能が高く、サーバー向けはコア数が多くて発熱が抑えられている。

Xeonのワークステーション向けの下位モデルは、民生用で最上位のCore i7 Extreameシリーズと同等品となり、またそれ以上のモデルが用意されている。

基本的には民生用のCoreシリーズと比べると高性能だが、それだけでなくECCメモリーへの対応や、CPUあたり6本のメモリスロット、マルチCPUのサポートなどより高度な性能要求や安定性に耐える仕様となっている。

その分各部品は割高だ。マザーボードも非常に高価だが、ECCメモリーなども地味に痛い。

Quadroについて

nVIDIA Quadroは、nVIDIAの映像処理向けグラフィックスボードだ。

民生用のGeForceがDirectXに特化した「ゲーム用」であるのに対し、3Dグラフィックデザイナー、CADアーティスト、映像クリエイターなどに向けてOpenGLに特化した仕様としている。

また、安定性もかなり高められており、他画面出力にも強くトレーダーにも適している。

nVIDIAはQuadroについてパッケージにLinuxへの対応を明記している。

ドライバーサポートはnVIDIAのほうが全体に手厚い。
ただし、ビデオドライバのパフォーマンスは、Windowsはおろか、FreeBSDと比べてもはるかに低いのが残念なところだ。

Z400の内部とシステム

配線は余り過ぎない長さになっており、さらにそれがまとめられた上にカバーまでかけられている。

カバーはメモリも覆うようになっていて、放熱上不利に見えるが、もしかしたらエアーコントロールによってむしろメモリ放熱が考えられているのかもしれない。

5インチオープンベイが3つ、3.5インチシャドウベイが2つ、3.5インチオープンベイに見えるが実際は使いみちのない塞がれたベイがひとつある。

SATAコネクタは6で、SATA 2.0 3Gbps。
ただし、SATA電源コネクタは5。空きの4ピンがふたつあり、電源増設は可能。

PCI関連は

  • PCI e2 x8
  • PCI e2 x16
  • PCI e x8
  • PCI e2 x16
  • PCI
  • PCI

となっている。

メモリスロットは6、最大搭載可能量は24GB。標準では2GBx2が積まれていた。トリプルチャンネル仕様。

おそらくはスタビライザーとして昨日するのであろう緑色のステーがQuadroに向かって伸びている。

基本的には緑色の部分は工具なしで操作できる部分だ。パネル自体はハンドル式になっており、必要な工具は増設時のトルクスのみか。

BIOS式でUEFIなし。

BIOSは、起動ロック、ディスクの暗号化に対応。また、RAIDコントローラを持ち、RAID構築が可能。

WoLに対応。ハイパースレッディングのOn/Offが可能。カバーセンサーについては有効・無効を設定可能。

設定項目は非常に少ない。

ブートデバイスの選択は、Optical, USB, Diskのみ。WindowsとLinuxの切り替えは基本的にはデバイスの起動順序を利用する必要がある。

また、Opticalを指定すればOptical Driveを読みにはいくのだが、ブータブルなCDを入れていてもスルーされてしまうことが結構あった。

OSはWindows 7 Professional。ちなみに、この個体はhpのデフォルトではなく、ショップで入れて認証したものが入っている。

Windowsエクスペリエンスでは、だいたい7.0から7.5。ディスクだけは5.9にとどまった。Windowsのディスクは250GB HDDである。UEFIをサポートしないため、ブートディスクの容量は2.2TBが上限となる。

メモリ増設

あとから知ったのだが、hpは

  • DDR3-1366 DIMM ECC Unbufferedのみ対応
  • hp以外のメモリは使用不可
  • ECCとNon-ECCを併用すると、メモリエラーとなり起動しない

と言っている。また、調べてみると

  • ECCとNon-ECCを混ぜることはできない
  • BIOSで有効・無効が切り替えられるのなら、無効にすればNon-ECCメモリが使用できる。常に有効であるなら使用できない。いずれにせよ混ぜることはできない
  • 否、無効にしてしまえば混ぜてもNon-ECCとして動く

とある。

CFD ELIXIR W3U1600HQ-4Gを追加した。

「おそらくはNon-ECCの、DDR3-1600メモリの4GBx2」である。

メモリチェックはちゃんと通ったし、LinuxもWindowsも問題なく機能する。
よくわからないが、とりあえず気にしないことにした。人には勧めない。

なお、最初から1366のメモリが積んであるにもかかわらず、1066で動作している。

HDD

完全にデスクトップを代替しようとすると、Windowsは「音楽系ソフトを入れる別なディスクが必要」となる。

ディスクは6、マウントは5でいいと思ったのだが、実際はディスクは7、マウントが6必要であることに気がついた。

これは、Windows + Windows DATAで2台、Linuxシステムで1台、btrfsプールで4台だ。
PCIeカードでコネクタは間に合うし、電源はなんとかするとしてもマウントがない。

1台はSSDなので、適当に固定すれば良いのだが、HDDはそうもいかない。しかも、光学ドライブがあるため、マウントはさらにもうひとつ必要なのだ。

結局は、全てHDDに充てることで解決したが、実は方法はあった。

マウントに関してはiStar USA BPN-DEを利用した。

これは、5.25インチベイに固定するHDDラックで、5インチベイx2に対して3.5inch HDDx3を固定できる。
ガシャポン式で、コネクタはSATA 6Gbps。トレイなし、ホットスワップ非対応だ。

このラックは、SATAコネクタは3本(当然)必要だが、電源コネクタは2つでまかなえる。そのため、これを使うと電源増設が不要だ。

WindowsのHDDの割り当てが1台しかないため、音楽をこちらに移すことは諦めたが、このラックを使って入れ替えれば可能であることに気がついた。

それどころか、入れ替える前提であるならば光学ドライブを残すことすら可能だ。

しかし、どの程度抜き差しして大丈夫なものか、よくわからないため、しょっちゅう交換する使い方は不安がある。

なお、これらの固定方法はやや特殊。ドライブ自体にまずガイドネジを取り付け、ベイ開口部から挿入する、という形だ。
5インチベイのラックについては、上段が若干ネジ穴位置が低く、ネジを入れてしまうとガイドを通らなかったので、下段のみにネジを入れて固定した。

ネジはシャーシに固定されている。これはProLiant Microserverと同様だ。マイナスドライバーも受け付けるが、基本的にはトルクス。これはProLiant Microserverと規格が同じで、レンチが流用できた。

Linux上での性能

まず、この通り

$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.60 GHz - 3.19 GHz
			available frequency steps: 3.19 GHz, 3.19 GHz, 3.06 GHz, 2.93 GHz, 2.79 GHz, 2.66 GHz, 2.53 GHz, 2.39 GHz, 2.26 GHz, 2.13 GHz, 2.00 GHz, 1.86 GHz, 1.73 GHz, 1.60 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.60 GHz and 3.19 GHz.
				The governor "ondemand" may decide which speed to use
				within this range.
current CPU frequency is 1.60 GHz.
boost state support:
	Supported: yes
	Active: yes
	25500 MHz max turbo 4 active cores
	25500 MHz max turbo 3 active cores
	25500 MHz max turbo 2 active cores
	25500 MHz max turbo 1 active cores

ここで躓かれても困るが。ただ、ondemandperformanceしかないのか。

ハイパースレッディングをONにした状態だと、

$ nproc
8

これも当たり前。

実際、感覚としてはA10-7700Kとはまるで違う。
A10-7700Kは3.4GHzだというのだが、実際に動かしているとほとんどの場合、2.4GHzで動作する。負荷がめいいっぱい高い状態でも2.6GHz、2.8GHzがせいぜいで、フリーズするような状態になってもそんなものだ。

ベンチマークなどで見る性能には、はるか届いていない。というか、モバイル用Celeronのほうがさくさく動く始末だ。

それに対して、Xeonは圧倒的に速い。細かく停止するようなトラブルもない。

メモリは4GBでは圧倒的に足りない。yaourtでビルドできないパッケージが結構ある。
/etc/yaourtrcで設定すれば回避できるが、結局メモリが足りないという問題の解決にはなっていない。

12GBあれば日常的には問題ない。
ただし、一時的であれtmpfsに大きなファイルを置くと圧迫される可能性がある。
とはいえ、実際に使われる範囲としては、6GB前後というのが私の感覚なので、tmpfsに半分とられてもswapもあるし、12GBというのは、おおよそ問題ない気がする。

ただ、そもそも圧迫されている状態になった時にバッファとして使える領域が非常に少ないため、16GBあったほうが安心ではある。

Xeonがとにかく速く、メモリを増設した時のパフォーマンスは本当に感心する。
それだけ良いようだと、最新のワークステーションはどれほどのものなのか…

Quadro 2000 と Linux

さて、問題のQuadroだ。

AMD A10-K7700はAMD R7グラフィックス相当だが、Catalystドライバを使っていても

  • セカンダリディスプレイのマウスカーソルが歪む
  • VDPAU/VA-APIともに使用できない
  • Xのパフォーマンスが非常に悪い。描画のもたつき、プチフリーズが多い
  • Chrome系ブラウザが動作しない。画面が表示されたり消えたりする。プロセスが増えるとまずダメ
  • Skypeで画面が歪む。変色し、緑色の線が入る
  • マルチデスクトップは正常に機能しない

これなら安定して動作するIntelグラフィックスのほうがいいのではないか…と思ってしまう。パフォーマンスも非常に悪い。

対するQuadroは、これらの問題が見事なまでに発生しない。
100時間以上を費やし、動作しない理由の究明に勤しんだVDPAU/VA-APIも、いともあっさりと動いた。動画再生は非常に快適だ。

ただし、VLCで「DRM経由のVA-API」にすると動作しない。「XのVA-API」にする必要がある。

驚いたのはImageMagickの処理が飛躍的に高速化したことだ。
従来1分は余裕でかかっていた処理が3秒以内に完了する。おそらく、数時間かかっていたmogrifyの負担も著しく軽減されるだろう。

とにかく安定している。問題らしき問題が発生すること自体稀だ。

ただし、デスクトップで動作していたOpera Devloperは動作しない。フリーズしてしまう。また、Chrome系のChromiumなどは動作はするものの、入力に対する反応が著しく遅い。Blinkの神経質さが気になる。

Blink系ブラウザではMaxthonが正常に動作するが、Maxthonは現在AURから落ちてしまっている。旧リポジトリから入手可能だ。

これからは事実上Blink以外の選択肢が失われていくように思うのだが、Blinkの動作の不安定さは非常に気になる。WebKit系は動作するが、非常にもっさりだ。

結論

LinuxのグラフィックスボードはQuadro。

AMDのCPUのパフォーマンスが出ない理由はよくわからない。ビデオもCPUも、Windowsではそれほど悪くないように感じるのだ。

ただし、Windowsではオーディオデバイスのほうが見事に落ちまくる。ASIOドライバを使うようなデバイスは、やはりIntelのほうが最適化されているのだろう。AMD CPU不可というものもあるくらいだし、完全な互換性はないのか。

で、AMD APUのパフォーマンスはWindowsの時よりもはるかにしょうもないものに見える。非常にストレスフルな性能だ。

結局のところ、Intel CPU + Quadroという、普通の組み合わせ(Quadroは普通ではないが、Linux的にはむしろ妥当だ)が一番いいようだ。

愛着のある、はじめての自作PCとの比較がこのようなことになって、とても残念だが、だが、このような蓄積は仕事上必要だと思うことにしよう。

高度なことを求める人にLinuxを動かすハードウェアとしてAMD APUは勧められない。

VDPAU/VAAPIが動作しないのは、ディストリビューション的な事情かもしれないが、少なくともマウスカーソルが歪むという問題はディストリビューション問わず発生した。Skypeに関しても同様だ。

これが、Radeon全般の問題なのか、7700K固有の問題なのか、はたまた私の7700Kの問題なのか、あるいはCatalystの問題で将来的に解決されるのか…といったことはわからない。
ただ、マウスカーソルが歪む問題は、やはりRadeon * CatalystにおいてWindowsでも報告されている。

スペックだけをみればAMDの製品はLinuxのほうを向いているかのようだが、事実はそうではないらしい。