AMDがGPUソフトウェアをオープン化、Linuxに注力

PCwatchの記事にもなっているが、AMDはRadeon SoftwareのOSS化をはかるようだ。

AMDとnVidia、どちらが優位にあるのか、ということはよく知らない。
GPGPUやPCゲームにおいてはnVidiaが圧倒的第一人者であるように見える。しかし、PlayStation4, Xbox360, Xbox One, Wii Uとコンシュマーゲーム機などではAMDの独占状態だ。

しかし、印象としては、Intelに対するAMD、nVidiaに対するAMDと、巨人に立ち向かうイメージが私の中にはある。

私はAMDが好きだ。AMDとATIは別に考えろという人もいるかもしれないが、AMDが好きだ。できることならばAMDで通したい、と思ってきた。
だが、現実はそうはいかない。
一見すると、コア数が多く高回転なAMDのCPUは、Linux、あるいはUnixで非常に有利に見える。forkモデルによって非常に多くのプロセスを回すためだ。
にもかかわらず、スループットの低さを感じるようなUXの悪さがついてまわる。

グラフィックスのほうはもっと深刻だ。描画のバグが多く、VDPAUはまともに動作しない。ビデオ再生の支援すらできず、セカンダリディスプレイではマウスカーソルが歪む。Skypeではビデオが変色してしまう。

結果的には、AMD環境はWidnowsではあれば、Intel+nVidiaに遜色ない結果を残せる構成であっても、Linux環境ではUXが著しく悪い。
話にはLinuxを向いているようなのに実際は違う、というのは非常に残念な思いだった。

そこに飛び込んできたのがこのニュースだ。

AMDがLinuxを軽視しているためにドライバが不出来でうまく動作しないわけではなく、Linuxに活路を見出してくれたということがとても嬉しい。

記事によればGPUコンピューティングのためのもので、ビデオ改善のためではないようだが、これからの動向が楽しみだ。

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向けにちゃんと作られていないからだろう。

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のほうを向いているかのようだが、事実はそうではないらしい。

VDPAU / VAAPI * AMD A10 kaveri / Cinnamonが立ち上がらない

LinuxでのGPUハードウェアアクセラレーションつきでの再生のトライ。

設定はわかっているが動作のためにセットアップ。

VDPAUを利用するため、libvdpau-va-glとlibva-xvba-driverのインストールを行い、/etc/profile.d/vdpau_vaapi.sh

#!/bin/sh
export VDPAU_DRIVER=va_gl

と設定して実行可能に。(root:root 744)。再起動して有効化できる。 別パッケージのvdpauinfoによると

libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/fglrx_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
display: :0.0   screen: 0
[VS] Software VDPAU backend library initialized
API version: 1
Information string: OpenGL/VAAPI/libswscale backend for VDPAU

Video surface:

name   width height types
-------------------------------------------
420     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
422     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
444     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                   --- not supported ---
MPEG2_MAIN                     --- not supported ---
H264_BASELINE                  51 16384  2048  2048
H264_MAIN                      51 16384  2048  2048
H264_HIGH                      51 16384  2048  2048
VC1_SIMPLE                     --- not supported ---
VC1_MAIN                       --- not supported ---
VC1_ADVANCED                   --- not supported ---
MPEG4_PART2_SP                 --- not supported ---
MPEG4_PART2_ASP                --- not supported ---
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
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 ---
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         457866064 457866064    y  
R8G8B8A8         457866064 457866064    y  
R10G10B10A2      457866064 457866064    y  
B10G10R10A2      457866064 457866064    y  
A8               457866064 457866064    y  

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             -
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  -
SHARPNESS                        -
LUMA_KEY                         -
HIGH QUALITY SCALING - L1        -
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              -  
VIDEO_SURFACE_HEIGHT             -  
CHROMA_TYPE                      -  
LAYERS                           -  

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 -  
CSC_MATRIX                       -  
NOISE_REDUCTION_LEVEL            -  
SHARPNESS_LEVEL                  -  
LUMA_KEY_MIN_LUMA                -  
LUMA_KEY_MAX_LUMA                -  

H.264しかサポートできていない?

VAAPIはAMD APU A10 Kaveriで必要なのはlibva-xvba-driverなので、それだけでOK。Catalystドライバは既に使用している。 Mplayerはmplayer-vaapiをAURから導入すれば良いということだが(コマンドラインオプションは必要。Wikiは英語版mplayerの項目でのみ、AURにあることが示されている。communityからdropしたパッケージ)、現在のところ鍵が検証できない(手動追加しても受け付けない)ので試していない。 SMplayerはVAAPIはIntelのみだと言ってくる。

結局うまく動いていない気がする。

Cinnamonが立ち上がらない

再起動すると、Cinnamonが立ち上がらなくなった。

待たされた上でデフォルトの壁紙が表示され、

Cinnamonはクラッシュしました

と表示される。

~/xsession-errorsを調べると、~/.config/dconfがPermission Deniedになっている。

ls -ldR ~/.config/dconf

したところ、ごっそりとパーミッションがroot:rootのmask077になっている。 chownしたのだが、chownしても何度も戻ってしまい、ちょっと苦労した。

Manjaro Linux 0.8.13 setup (3)

"インストール作業"

  • libaacplus
  • evince
  • gedit
  • gedit-plugins
  • gedit-core-assistance
  • ggjs
  • libgit2-glib
  • flashplayer-standalone
  • cnijfilter-mp620
  • xfce4-goodies
  • purple-line
  • wireshark
  • dconf-editor
  • expect
  • firefox-aurora
  • gstreamer-vaapi
  • libvdpau-va-gl

ビデオ関連と、あとはこれまで使っていて欠如しているものを足した。

firefox-auroraはFlashのOut Of Dateに対応したもの。xfce4-goodiesは中途半端に入っていた。

expectはmkpasswdコマンドのためにある。

ビデオプレイヤーの設定

ビデオのパフォーマンスが非常に悪い。 しかも、えらいCPU大食いなので、調べてみたら、ビデオ再生は無条件にGPUを使う、わけではないようだ。

なお、ビデオカードはAMD A10-7700Kで、AMD Radeon R7ということになる。

VLC

環境設定→入力/コーデック→ハードウェアアクセラレーションによるデコード

がある。だが、VDPAUでもDRM経由のVA-APIでも「開けない」と言われてしまう。なぜかnvidiaドライバーを開こうとしたりしている。

X11のVA-APIならば、ただしくAMD用ドライバーで再生するが、フリーズしたり、盛大なブロックノイズなどが頻発する。

Smplayer

VLCよりも快適な再生ができているSMPlayerは、

環境設定→ビデオ→出力ドライバー

で設定できる。色々あるが、とりあえずgl (高速 - ATI カード)を選択することで改善された。

また、「パフォーマンス」の項目にDecodingがあり、Hardware decodingを選択(vaapiにした)することでハードウェアアクセラレーションが利用可能なようだ。

fetchmailが止まる

fetchmailが受信中に停止。 SIGINTで中断して再開するも止まってしまう。

試してみると、特定サーバーで止まる。 そのサーバーより前に記述されているサーバーは正常に処理される。

どうやら、特定メッセージの受信で止まってしまうらしい。 調べたが、あまり有用な情報はなかった。 IMAPでそのメールを除去すると正常に動作するようになった。

この問題は2回目。

Manjaroのアップグレード時のX起動問題と、マウスカーソルの問題

昨年末にきていたAURのアップデートだが、これを適用するとXが起動しなくなる。LVMスナップショットを使ってロールバックしていたが、3回適用しても全て同様の症状となる。

しかし、3回目にyaorutの実行メッセージにヒントをみつけて次のように実行した

sudo mhwd-gpu --setgl catalyst

これで正常に起動した。スナップショットを削除して完了。

そして先日からセカンドモニターのマウスカーソルがバグる、という話をしていて、なんとかしたいので調べてみた。すると、Radeonの問題であり、Windowsでも生じるらしい。Windowsの解決策が並ぶ。

“linux pointer cursor distored”で検索すると情報が出てきた。

のように、

Option “SwCursor” “true”

xorg.confに追記することで解決する、らしい。解決したのかは分からないが、とりあえず今のところなっていない。

Manjaro LinuxのXが起動しなくなった

12-20のシステムアップグレードリリースでManjaroを再起動した際、Xが起動しなくなった。

[ 32.722] (II) fglrx(0): Desc: AMD FireGL DRM kernel module
[ 32.722] (II) fglrx(0): Kernel Module version matches driver.
[ 32.722] (II) fglrx(0): Kernel Module Build Time Information:
[ 32.722] (II) fglrx(0): Build-Kernel UTS_RELEASE: 3.18.0-0-MANJARO
[ 32.722] (II) fglrx(0): Build-Kernel MODVERSIONS: no
[ 32.722] (II) fglrx(0): Build-Kernel __SMP__: no
[ 32.722] (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
[ 32.722] (II) fglrx(0): [uki] register handle = 0x00016000
[ 32.722] (II) fglrx(0): DRI initialization successfull
[ 32.722] (II) fglrx(0): FBADPhys: 0xf400000000 FBMappedSize: 0x010e0000
(==) Log file: “/var/log/Xorg.0.log”, Time: Sat Dec 20 23:57:18 2014
(==) Using config file: “/etc/X11/xorg.conf”
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found
/usr/bin/Xorg.bin: symbol lookup error: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D

検索すると事例はかなり多く見つかるが、そのほとんどはaticonfig –initialしろというものだ。

だが、これでうまくはいかなかった。nomodesetしろという声もあったが、それはすでにしてあるし、確認もした。

そのほかにはflgrxを無効にする方法について記述されたものがある程度で、それ以外はインストールしろか、もしくは解決しないままか、だ。

かなり深く調べた。エラーでは0:1:1となっているが、本当にBusIDの不一致を疑って調べると0:1:0だったので、それが原因かと思って調べたりもした。だが、結局解決にはつながらなかった。

バックアップしたイメージでロールバック、ということも考えたのだが、まずは総再ビルド&インストール。もし、パッケージが壊れたためならこれで解決する。もともと壊れていたのなら、ロールバックしてアップグレードしても同じことになる。

やり方は次のようなもの。

for i in $(pacman -Q | cut -f 1 -d " ")
do
yaourt -S --noconfirm "$i"
done

sudo時間は長くしておくほうが良い。

だが、うちの場合、頻繁に、長時間に渡ってネットワークダウンが生じる。上流で起きていること(おそらく、回線、集合回線部分のせいだろう)なので私には手出しできない。フルビルドで回っている間ネットワークがダウンすると失敗する。これはなかなか恐ろしい。

幸いにもネットワークダウンには遭遇せず2回完走したのだが、改善しなかった。そこでロールバックを試みたのだが、dumpしたイメージをrestore(8)しようとしたが、0 inode fileと言われ、14GBもあるファイルにもかかわらずできなかった。

システム再インストールしかなくなってしまったが、せめてもということで、pacman -Qの結果を外部に保存しておく。

再インストールだが、Manjaro 0.8.11 Xfce JPのイメージのインストーラではkeymap選択画面でフリーズしてしまい、進まない。0.8.10 XFce JPイメージでインストールする。

2014-11-05のarticleにある手順でセットアップ。

  • pacman-keyの再構築、無効なキーの削除
  • aticonfig
  • vigrでusersのGIDを500

そしてパッケージを復帰させる。いくつか試したが、sudoのtimeoutを無効にした上で

for i in $(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' )
do
yes Y | yaourt -S "$i"
done

--noconfirmではconfrict時に中止を選択されてしまう。基本的にはこれで通るが、MATE関連でgstreamerかpulseaudioか選べと言われてYを返しても通らないため、チェックしてこの時に一旦INTしてmate関連を手動インストールの上、やり直す。ちなみに、依存関係で入るパッケージもこの方法だと再インストールするため、mozc-utなどはfcitx-mozc-utで入るのだから途中で中断してやり直したほうが早い。

これを避ける方法としては

while p=$(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' | head -n 1)
[[ -n "$p" ]]
do
yes Y | yaourt -S "$i"
done

で、その他の選択肢を要求する場合を除いていけると思う。だだし、そもそもビルドできないパッケージがあると、それはインストールできないため詰んで(ループして)しまう。監視なしにするにはexpectを使うしかない。なお、xpdf関連は無理だった。

この後は次のようにしてセットアップを進める

  • バックアップしたhomeのイメージをrsync。この時、rsync -av /mnt/1/ –exclude share/ /home/としてマウントされるユーザーデータは回避する。
  • このままではユーザーデータがマウントできないので、sudo -u aki mkdir ~aki/share ~aki/.share.encfsとする。
  • /etc/fstabを編集。tmpfsと~/.share.encfs(btrfsサブボリューム)のマウントを設定。 encfsをマウントするためのスクリプトを~/root/binに書く。
  • これでほぼ通常通り。リブートしてakiでログインし、Catalyst Control Centerを起動、設定すればOKだ。復旧に6日もかかってしまった。
  • 今回のようなことがか内容にと、今回はインストール時にLVMを使用する設定とした。ちなみに、ディスクのパスフレーズの強度を大幅に高めた。
  • だが、標準でLVにVG全域を使用してしまうため、「管理やバックアップを容易にするため」と言いながら、実際は全く柔軟性がない。仕方ないので、SystemRescueCDで起動し、luksOpenしてvgscanし、ルートボリュームをe2fsck+resizefs+e2fsckで縮小した後、lvreduce --size 80G ManjaroVG/ManjaroRootでOK。アップデート前にスナップショットを取るようにすればロールバックは容易になる。Manjaroでは運用中にこのような事態に陥ることが既に3回めなので必要だろう。また、rsyncでバックアップしておくことも必要かもしれない。

現在のシステムについて

私のコンピュータシステムについて質問があったのでまとめておく。

とはいえ、Linuxのシステムは全て説明するのは困難なので、概要に留める。

ハードウェア

ASRock FM2+Killer Extreame, AMD A10 7700K, 32GB RAM, 128GB SSD, 3TB HDDx5というのが主な構成。

外付けマルチドライブ、Canon MP630とEPSON GT-S630がある。プリンタ、スキャナはWindowsからは使用していない。

AUDIO I/OはAUDIO 4 DJ(セレクター経由でBOSE)、TASCAM US-366+FOSTEX AP05+VAIO付属スピーカー、アナログ出力のlogicool。US-366はLinuxでは扱えない。通常はClassic Proのヘッドフォン、製作時やリスニングではULTRASONE HFI-580を使用。

キーボードはオウルテックのメカニカルキーボード(青軸)、マウスはサンワサプライのBLUE-TECH有線、マウスパッドはELECOMの滑マウスパッド(大)。ELECOMのゲルハンドリストを使用。

机がL字型の自作となっている。

モニターは21.5インチのFullHDデュアル

システム

ディスクは以下のようになっている。

disk0(SSD)
Linuxシステム(/boot, /, /swap)
disk1,2,3,5
Btrfsボリューム
disk4
Windowsシステム(NTFS/UEFI)

Btrfsボリュームは2レッグミラー(RAID1+0相当)で運用される。サブボリュームを用いた運用で、サブボリュームの直下がEncfsディレクトリとなっており、~/.share.encfsにマウントされる。これをencfsで~/shareにマウントして使用する。

そもそもホームディレクトリの主要なディレクトリやファイルはシンボリックリンクとなっており、これをマウントしないとシステムをまともに使用することができない。システム自体もLUKSで暗号化されており、オフライン攻撃に対する強度を確保する。

Manjaro/WindowsともにUEFIでブートされる。ディスクは全てGPTとなっている。

Linux

ディストリビューション
Manjaro Linux JPを使用。0.8.10からのローリングアップグレード。
カーネル周り

Manjaro kernel 3.17を使用。AMD Catalystドライバで、オーバースキャンの設定をしてある。

ただし、この状態ではデスクトップ環境を問わず、HDMIモニター(セカンダリー)のカーソルがやがてバグる。

デスクトップ環境

XFce, Awesome, KDE, Cinnamonを用意。通常はKDEを使用。

KDEについてはSuper+Leftでウィンドウを左に寄せる、などエッジリサイズオプションを設定してある。

Conkyを使用しているが、KDEではRSSがうまく領域を確保されないことが多いので、あまり使っていない。

日本語環境

fcitx+Mozc-UT。

fontsは、Archで用意されている日本語フォントはだいたい入っている。

インターネット

ウェブブラウザはFirefox latest(binから入れたもの。スクリプト起動)とMaxthon, opera developerを使用。

メールはMaildeliver(自作スクリプト)でチェック、振り分け、フィルタリング、通知などを行い、Claws Mailで読む/出す。通知はデフォルトの通り、SOXとNotify Sendを使用。

TwitterはMikutter(Git)を使用。2chはJD(AUR)を使用。

その他、Skype+Sype Call Recorderを使用。

マルチメディア

半自動でCDをflacとOgg Vorbisに取り込むようになっており、Amarokで音楽コレクションを再生。

PDAPにはスクリプトを用いてOgg Vorbisを転送。Ogg VorbisはV192kbps。

ビデオはVLC/SMPlayer。

音声についてはPulseAudio経由で、出力デバイスはアナログオーディオ、HDMI、そしてNI AUDIO4 DJがあるが、設定によりAUDIO 4DJから音楽のみ出すようにしている。これはPulseAudioで設定してある。現在、Audio 4 DJから鳴るのはAmarokとSMPlyer。

画像は通常はGwenviewだが、Thunar+ViwniorやRistrettoも使用。

画像は投稿時などの変換はImageMagick。その他、GIMPとInkscape。

開発

PDocはmedit、コードはKate、プレーンテキストはTeaを使用。

バージョン管理はGitで、サイトのテキストもGitで管理、大部分はリモートGitを使用している。

リモートGitはCodebreak;, GitHubが主。

開発言語はRubyとZsh

シェル
XFce4 TerminalとZshを使用。Zshはmomongaをベースに拡張したrcで使用している。EXTENDED_GLOBは常にON。

Windows

デスクトップ

外観はU-7imate Final Version for Windows7, MacType, tronnixカーソルテーマを使用。

ランチャーはLaunchy。Rain Meterも控えめに使用。フォントは源柔フォント, 源真フォント, Rounded M+, Noto Sans Japanese, Ricty。

ユーティリティ
  • GeekUninstall
  • PeaZip
ファイラ
  • As/R
  • Hina File Master
日本語入力環境
Google日本語入力
マルチメディア
XnView
音楽制作環境
  • SONAR X3 PRODUCER
  • FL STUDIO Signature Bundle
  • KOMPLETE 9 ULTIMATE
  • Cabuse 6 LE
インターネット
ウェブブラウザ
  • Cyberfox AMD64bit
  • Sleipnir
メール
Oepra Mail
エディタ
  • Uneditor
  • VXEditor
セキュリティ
  • ZoneAlarm Free Firewall
  • Avast! AntiVirus Free

音楽制作環境なので、基本的に余計なものは入れないようにしている。

Windowsでウェブブラウジングを楽しむようなことはない。メールもメインアカウントのIMAPアクセスだけだ。だが、ブラウザは調べ物したりSoundCloudにアクセスしたりで必要となる。

パフォーマンス

Linuxでの並列作業や、WindowsでのDTMで使われているこのコンピュータのパフォーマンスについて述べる。

Linuxにおいて10000プロセスをforkして行う作業は、ほぼ問題ない。が、GUIはフリーズしたり、ひどい遅延を起こす。どちらかというと、fork時が問題になるようだ。ちなみに、Nepomukでシステムが使えなくなるまでには26万プロセスがforkされていたと記憶している。

おおよそ並列作業のために見境なくforkしても問題にはなりにくい。ただし、gccなどでは、やはり多くても12スレッドがいいようだ。並列性は、残念ながらあまり高くない。やはりこの作業ではコア数が必要となるので、FX-8が欲しいな、と思う。

全体にはCPUがボトルネックになっている。システムはSSDからロードされているため、ストレージ性能はそれなりにある。ネットワークもGbEでそれなりの帯域がある。RAMはKDEでも2GBもあればロードできるため、実際は8GBを越えることは稀だ。

しかし、ソフトの起動時に待たされる、特にKDEの起動が遅いことについては、やはりCPUがひっかかっているようだ。これはGIMPやLibreOfficeの待ち時間についても同様。KDEでもひっかかりが生じることがあり、明確にどこでということは読めないのだが、どうもCPUらしい。KDEは明らかにXFceのようにはさくさく動かない。リソースに常に余裕があれば、体感的な速度にはそれほど差がでないはずなので、常にではないが動きが悪いと感じるということはKDEに対して余裕がないのだろう。

ちなみに、パイプでのXZなどCPU中心となるものに関しても結構遅いと感じられる。コンパイルも意外と待つ。「すごく速い!」という印象はない。

IOスピードは、まぁ、この程度だろう。RAMも十分なのだが、それでももう少しあると快適になるシーンというのはある。バッファで使いきってしまうことは結構あるので、その時にはもっとメモリーがあればIO待ちの時間が減る。また、tmpfsに置けるファイルも増えるだろう。とはいえ、64GB化はエクスペリエンスの向上は乏しいだろう。

WindowsのDTMにおいては、ストレージスピード、RAM共に完全に余裕である。ストレージスピードが足りないようならば、ネットワークストレージのRAID0でさらなる高速化を準備していたが、その必要はなかった。

RAMは、Windowsでは逼迫したことがない。WindowsはRAMの使い方が下手だ、ということもあるが。

16トラックのシンセに20本のプラグインエフェクトを入れてもRAMには十分な余裕があったが、問題はCPUだ。上限に張り付くようなことはないのだが、US-366でlowest latencyにしていると、3トラック目あたりからノイズが乗ってくる。DTM作業をストレスなく行うには、かなりパワーが足りない印象だ。

AMP A APUは、クロック周波数がブースト時のものになっているので、その最大周波数で動いてくれるわけではない、というのが結構痛い。見ていると、ひとつのコアが60%くらいになるとノイズが乗り始める。この場合、他のコアは40%程度の使用率となっている。

Highest latencyにしてもノイズが除去できないこともある。結局、モアCPUパワー!な状態だ。

音楽制作においては、比較的低レベルでの動作が多いためか、どうもハードウェア的にインテルのほうがいいことが多いように思う。性能は同じでも、うまく動いてくれる気がする。一方、LinuxではFX 8がとても気になる。

現状、DTMではコアよりパワー、一方Linuxではパワーよりコアである感じがするのだが、まぁこれだけCPUの話ばかりになってしまうほど、CPUが遅い!

ちなみに、CPUについでパワーが足りないのは、ゲームなどしていないにもかかわらず、グラフィックだったりする。Windowsではもたつくというほどではないが、それでもYouTubeなどでは「んっ」と思う時がある。デュアルディスプレイの負荷が厳しいのかもしれないが、安定性も足りなかったりする。Windowsでもだ。

一応、この構成でもFHDx2+4kが可能なようではあるが、相当もっさりしそうだ。

クリエイティブな環境のためには、もっとCPUとGPUが必要だ、という結論に達した。

なおストレージ容量だが、現在はだいたい1.3TB。一時2.7TBまで行っていた。ネットワークが50Mbps程度しか出ていない(しかも、down率が10%を越える)ので増加は抑えめだが、本来限界まで簡単に行くとは思う。btrfsでいくらでもふやせるのはいいのだが、バックアップが難しくなっていくのは難点である。