LinuxでNvidiaもIntelもおかしなことになっているのでRadeonにかえてみた

もういやだ

パワフルなThinkStation P720ワークステーションだが、最近様子がおかしい。 Nvidiaではおなじみの

  • 画面が点滅する
  • X11 APIでスクリーンキャストするとウィンドウが消えてしまう (だからスクリーンショットでもウィンドウが消える)

という問題は直る気配がない…どころか、従来はVblankとFlippingを禁止すれば抑制できたのだが、最近はダメだ。 さらにいえば、Nvidia固有だったこの問題は、最近ではIntelでも発生する、というかINtelのほうがひどくなっている。

そして、追加で

  • Libreofficeが使っているSAL PLUGINとglibの連携が腐ってしまって、ほとんど操作不能なレベルでフリーズする
  • Vivaldiでありとあらゆる操作においてフリーズする

という問題が追加された。 Libreofficeの問題は最初Nvidiaだけだったが、現在はIntelでも発生するし、SAL_USE_VCLPLUGIN=genで防げたのだが、現在はこれも無理である。

そして、4kディスプレイにしてからビデオメモリが足りないのか、ウィンドウを開いていくとウィンドウ領域がグリッド状に表示され、かすかにウィンドウが見える場合もあるがほとんどの場合見えず、操作もできないという状態になる、ということに悩まされた。 作業効率が恐ろしく悪いことになってしまうため、毎日とてもストレスだし、貴重な時間を、1日で1-2時間程度失っている状態だった。

もうこれは耐えられない。

一方、Godavariはこのような問題を発生しない。 「じゃあGodavariでやれよ」と思うかもしれないが、Godavariは全面的にとっても非力である。よく馬鹿にされるくらいには。

それで、現在の出費は痛いし、TSMCは7mmプロセッサを控えている状態だというのはわかっているが、 結局のところRadeon 3000シリーズは噂の域を出ないということも踏まえて、思い切ってRadeon RX580を購入することにした。

なぜRX580か

最大の理由はLinuxにおけるパフォーマンスである。

WindowsにおいてはVega RXもそれなりの性能を示すようだが、Linuxにおいては多くの場合Vega RXとの性能差は誤差の範疇に留まる。 Vega RXでもGTX1060は越えない、というような所ぅたいだ。

にもかかわらずVega RXはずっと高値を維持しており、相当にコストパフォーマンスが悪い。 しかも、Vega RXはNvidiaと比べても相当燃費が悪いようで、「電気をめちゃくちゃ食う」のである。

そもそも私のP720はQuadro P6000のSLIを想定しているためキャパシティとしては耐えられないこともないのだが、家の電気回線はそうではないし、 無駄な電気は使いたくない。

また、Vega RXのパフォーマンスはVega RX 64であっても「Nvidia GTX1070に届かない程度」というのがWindowsにおいても現実であるようで、 ゲームのことを考えて高性能なカードを選ぶ、という気にもなれなかった。

タイミングは悪いなぁ、やたら高いなぁと思いつつも、Linuxにおいてはベストな選択肢となりそうなRX580を選択したということだ。

製品はAMD専門メーカーSapphireのゲーミング向けNITRO+シリーズSA-RX580-8GDN+001V2 VD6801を選択した。 オーバークロック製品で、発熱量は多いが性能は高いようだ。

P720にSapphire NITRO+ RX580は「ギリギリ入る」

製品が届いてびっくりした。 「大きい」

いやもう、比べるのが無意味なぐらい大きい。 「ミドルクラスだし、GTX960と同じくらいだろう」とか思ってサイズのことは一切気にしなかったのだが、「これはやばいかもしれない」と感じるほど大きかった。 ゲーミング向けトップモデルはこれより大きいのか!?

入らないかもしれない、と懸念したが、結局はギリギリながら収まった。 上下とも入るが、下段に関しては電源配線に触れてしまう。 また、サイドパネルに接触するため、サイドパネルがしめづらくなる。

「普通に入る」とは言い難い、「かろうじて入った」である。 だが、入る。

なお、SA-RX580-8GDN+001V2は補助電源が8ピン+6ピンというGTX1080Ti並の要求で、P720の標準の補助電源は2本であるためこれを全部使ってしまい、SLI構成はできない。 汎用の拡張コネクタがあるのだが、こちらは専用品で、なおかつLenovoとして単体の販売はしていないので、Crossfire構成にしたい場合は予めP6000のような「補助電源を2つ使う」ビデオカードを2枚構成にしておく必要がある。

クーリングパイプがまるでインテークマニホールドのようで、さらにSAPPHIREのロゴが青く輝き、大変かっこいい。 まぁ、P720の場合サイドパネルが透明なわけでもないので、全く見えないが。

消費電力は

4114+Quadro P400構成と比較すると、アイドル時で107Wと、約60W増えた。 運用時も140から220Wで、60W増加と見ていいだろう。 ただし、変動しやすくなったため、平均すると80W増加とみたほうがいいかもしれない。

ただし、変動しやすくなったのは、「今までP400で処理しきれなかった分を即座に処理する瞬発力があるため」と見ることができ、効率的には変わっていないかもしれない。

「省電力」という印象はなくなってしまったが、性能を考えればまぁ想定通りといったところ。

問題は解消したか

ほぼyesである。

  • 画面の点滅はなくなった。代わりにログイン時に画面がおかしくなることがあるが、支障は実際にはない
  • スクリーンショット、及びスクリーンキャスティングでウィンドウが消える不具合はなくなった
  • Libreofficeがフリーズする問題は解消された
  • Vivaldiが異様にフリーズするという問題は 軽減された
  • ウィンドウが表示できなくなる問題は解消された

また、私が非常に不満としていた、私お気に入りのフラゲ1が重すぎるという問題が事実上解消された。

この問題自体はつい先日からChromiumがマルチスレッドでFlashを処理してくれるようになり、最大で12.5%(5スレッド)で処理してくれるためにかなり軽減されてはいたのだが、 ビデオ描画のもたつきがなくなったためか、全く支障なくなった。 不思議なものだ。 まぁ、Flashはビデオアクセラレーションの対象ではあるのだが。

ちなみに、このゲームがあまりにも重いのは「4114が非力で、うち特有の問題」と考えていたのだが、先日Thinkpad X1でやってみたところ、とてもプレイできないくらい重かった。 というわけで、むしろ「このハイパフォーマンスマシンですらもこの程度」という状態だったと考えられる。 恐らくはWindowsであれば支障ないのだろう。

Vivaldiの重さはどこから

RX580になってVivaldiが操作のたびに、あるいはフォーカスするたびに止まる (タブ=レンダリングプロセスが止まるのではなく、Vivaldi全体が止まる)という問題は解消された。

ちなみに、Intelはこの問題はより深刻で、Vivaldiを立ち上げたあとメニュー操作をするとウィンドウマネージャごと固まってしまう。

だが、依然としてふたつの問題がある。

ひとつは、右クリックでメニューを開くとかなり長い時間固まるということだ。 これはstraceしてみると

read(17, "!", 2)                        = 1
write(18, "!", 1)                       = 1
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
munmap(0x7fc6fd5f7000, 8832)            = 0
openat(AT_FDCWD, "/usr/local/share/fonts/Commercial/FONT-COMP-SET21/Fontstyles2/FontGraphic_Mac/UniversalWalk.otf", O_RDONLY) = 251
fstat(251, {st_mode=S_IFREG|0644, st_size=8832, ...}) = 0
mmap(NULL, 8832, PROT_READ, MAP_PRIVATE, 251, 0) = 0x7fc6fd5f7000
close(251)                              = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/DeletedManjaro/UmePlus/umeplus-p-gothic.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/DejaVuSans.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Monospace/font-bh-ttf-1.0.3/luxisr.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/gsfonts/NimbusSans-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/MuktiNarrow.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/malayalam.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Sampige.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/padmaa-Medium-0.5.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/VL-Gothic-Regular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/ipag.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/TSCu_Paranar.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/NanumGothic.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Korean/UnDotumBold.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Commercial/Unknown/CODE2000.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Morisawa/\343\203\222\343\203\251\343\202\256\343\203\216\344\270\270\343\202\264 Pr6N W4.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Morisawa/\343\203\222\343\203\251\343\202\256\343\203\216\344\270\270\343\202\264 Upr W4.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Mathematica6.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Mathematica7.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/AndikaRegular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/Tsuyuzora-bunko/XZBB.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/WadaLab/wlcmaru2004aribu4430/wlcmaru2004aribu.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/FiraSans-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/nukamiso/nukamiso_yamiyootf_beta07.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/OTF/Vollkorn-Regular.otf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/share/fonts/TTF/Ricty-Regular.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Commercial/Motoya/NFbc1kp.ttc", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/Motoya/MTLc3m.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/tfont/TGothic-GT01.ttc", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab69000, 57344, MADV_DONTNEED) = 0
madvise(0x3a38dab8b000, 49152, MADV_DONTNEED) = 0
madvise(0x3a38d9095000, 8994816, MADV_DONTNEED) = 0
access("/usr/local/share/fonts/Japanese/UchidaAkira/OradanoGSRR.ttf", R_OK) = 0
madvise(0x3a38dab8b000, 385024, MADV_DONTNEED) = 0

という感じで、フォントを片っ端から読んでいて、ものすごく時間がかかっている感じだ。 ちなみに、これはChromiumだと起動時に発生するため、フォント数が増えるとChromiumは起動が遅くなるのだが、Vivaldiではコンテキストメニューの表示がすさまじく遅くなる。 また、この問題はフォームをクリックしたときに発生するため、非常にストレスになっている。

もうひとつはページをロードしたときにロードの途中で異様に時間がかかる。 これはstraceを見ても止まるわけではないのだが、特徴的な要素は見つからず、コンソールで見るとただ単に飛んでいる。 これはChromiumでも発生するため、恐らくBlinkの問題だ。

Vivladi固有の問題のほうは時間があるときに報告するつもりだ。

現状では「Firefoxを使う」というのが解決策になりそうだ。 Chromiumは最近とにかく重くなっている。CPUの使い方がえぐいし、異様に処理に時間がかかるようになった。 フリーズしている、と感じるような処理時間で、原因がよくわからないケースが多い。 これがバージョン71から発生していることは認識しているのだが、そもそも「ウェブレンダリングを難しくしすぎている」というのが問題で、 「なんでもかんでもウェブでやろうとするのやめてくれないかなぁ」と心底思う。

だいたいこの流れや、レンダリングエンジンの複雑さがGoogleの胸先三寸になってしまっていることにはとても気持ち悪さを感じている。

Radeon RX580はどうだったか

なお、RTX2000シリーズは通常利用での暴走や出火などが問題視されていることからあまり完成度は高くないと見られており、 AMDは14nmプロセスでNvidiaより圧倒的に性能が低く、それでありながらライバルと位置づけるNvidia製品よりもずっと高い、という状況である。 しかもTSMCは7nmプロセスの新しいカードを用意しており、Radeon VIIという新製品は「RTX2080相当の性能で、価格的にも同等。Vega RX 64比では性能は1.8倍」とのたまっている。 TSMC、及びAMDは7nmで攻勢をかけるつもりのようで、とにかく時期が悪いのは確かだ。

だから、今買うならGTX1080かRTX2070あたりが妥当な判断で、RX580が4万円程度はするという点を考えると普通の(Windowsの、ゲーマーの)ユーザーには「迷わず買う人以外は買わないほうがいい」レベルの製品だろうとは思う。

Linuxにおける性能は、おおよそWindowsにおけるGeForceとの関係と同等。 つまり、NvidiaがWindowsと比べて半分程度の性能しか出せていない以上、AMDのドライバもWindows版と比べて半分程度、と考えれば良いのではないだろうか。 以前はもっともっと差が開いていたのでだいぶ健闘しているといって良さそうだ。現在はNvidiaのプロプライエタリドライバとAMDのオープンソースドライバ(AMDGPU)は同等の出来ということになる。 性能面では、だが

ゲーミング部分で言うと、ドライバの出来と、ゲームにおける最適化の結果として圧倒的にGeForce寄りであり、Radeonはその力を発揮できないという状態が続いている。 だから、ゲーム用途では何も考えずにGeForceでいいというレベルだし、多分それはRadeon VIIが出ても変わらない。

一方、Linuxのワークステーションユースで不満が出るという気はしなかった。 vdpauinfoでは

display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

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

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  52 65536  4096  4096
H264_MAIN                      52 65536  4096  4096
H264_HIGH                      52 65536  4096  4096
VC1_SIMPLE                      1 65536  4096  4096
VC1_MAIN                        2 65536  4096  4096
VC1_ADVANCED                    4 65536  4096  4096
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
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       0 65536  4096  4096
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
HEVC_MAIN                      186 65536  4096  4096
HEVC_MAIN_10                   186 65536  4096  4096
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
R8G8B8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
R10G10B10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 
B10G10R10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8 

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             y
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
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              y        48     4096
VIDEO_SURFACE_HEIGHT             y        48     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

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

また、vainfoは

vainfo: VA-API version: 1.3 (libva 2.3.0)
vainfo: Driver version: Mesa Gallium driver 18.3.1 for Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.20.1-1-MANJARO, LLVM 7.0.0)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

と当初対応しておらず、重大な弱点であった「H.265の非対応」は解消されているようだ。 (ただし、VP8/9には対応していない)

実際に試してみたところ、hevc_vaapiでのエンコードは116fpsと、P400でのNVENCには劣るもののかなりの優秀さを見せた。これだけ速ければ十分に実用的だろう。 画質がNVENCだと実用には厳しいところがあったのだが、VCEの場合いくらか画質がいいためより実用しやすい。 それでも、利用できる場合は「普通は画質を少しでも良く保存したい」ために「速さ優先」とはなりづらく限定的だが。

さらにNvidiaと違い、Waylandのコンポジターがちゃんと動作するというのも大きなメリットだろう。

消費電力的にも、あまり電気を使わないプロセッサを使っているからという事情が前提になってしまってはいるものの、使いづらくなるほどではない。 気持ちとしては「もっと消費電力が少なかったらなぁ」というのと、「2万円台前半だったらなぁ」という気持ちはとてもしてしまうのだが、そうした点を除けば「入れておけばとりあえず安心できるカード」であると言えるだろう。 「とりあえず入れる」には巨大すぎて入れるケースを随分選ぶが。

DVI-Dがひとつ、HDMIとDPがふたつずつで計5出力というところも、使いやすく不満になりにくい。 このビデオカードは大きさ的にも電力的にもそう来やすく選べるものではないが、Linuxでのグラフィックにまつわる不満を感じているのなら、RX580と言わずとも(例えば560でも)Radeonにする価値はありそうだ。

将来的には

「ゲームをする事情」と「デスクトップユースとして普通のアプリを動かす事情」は似ているのだが、「計算力を求める事情」と「Linuxにおいて快適な仕様」とは大きな違いが出てきている。

だから、贅沢を言えば2種類の仕様を用意できると最善で、贅沢を言えば、 「Ryzen + GeForce (主にWindows及びゲーム向け)」と「Ryzen Threadripper + Radeon (Linux及び計算向け)」の2台で編成できたらなぁ、と思う。 Zen2でこれを構成するのはなかなかドリーミーだ。

とはいえ、現実的に1台に絞るとしたら、「Ryzen + Radeon」という構成で「現実的な計算力とLinuxで扱いやすいグラフィック」というのを取るだろう。

現状、P720はどうなのかというと、やはり4114に求めたものと諦めていたものというのが大きい。

「メニーコア」という性能は、それを発揮する場面というのは本当に少ない。 実際、私の普段の運用では4114ですら持て余し気味である。 ところが、普段遣いではあらゆるアプリで処理性能が足りずストレスフルである。 「普通の使い方でモバイルi3程度の快適性しか求められない」というのはわかっていたが、それでもこのマシンのクラスを考えるととても残念な感じがする。

対して、実際にメニーコアを求めるケースでは4114では全然足りないのだが、それでも処理性能はi7とは段違いであった。 「4114はフルコアを活用できたとしてもi7に劣る」と考えていたが、実際は第8世代Core i7よりもずっと高速に動作した。 シングルコア性能も諦めていたほどに低くはなく、「さすがにそれなりに性能はある」と感じることができる。 そもそも、20コア40スレッドであるから、「20スレッドスケールテスト」が手元でできるというのもかなりのメリットだった。 だから、ちゃんと求めたものは実現できているし、価格を考えれば完全に目的を達成できるほどではないというのはわかっていた。

だが、結局のところ現状P720の最大の魅力は「省電力」である。 48Wから90W程度でありながら非常に優れた処理性能を発揮する、というのはかなり魅力的だ。

だが、やっぱりコンピュータは「性能が足りるか否か」であり、エクスペリエンスが良いかと聞かれるとYESとは答えがたい。 部分的にボトルネックになるブラウジングが全体の作業の足を引っ張るという状況も痛い。

「エクスペリエンスは諦めて処理量を増やしたい」というのとは矛盾しているのだが、やはりエクスペリエンスを優先したい気持ちが湧いてくる。 今回RX580にしたことで飛躍的にエクスペリエンスが向上したことも大きな理由になっている。 というより、RX580にしたことでP720がとりあえず不満ないくらいの動作をしてくれるようになった。 だから、バランス的には今の状態は悪くないのかもしれない。

Erina/Surtrに関する研究が一区切りついて、あまりデータプロセッシングすることがなくなったというのも大きい。 圧倒的に重い処理であったことから、これのためにメニーコアを求めたし、それによって成果も挙げたのだが、これがなくなると相当頻繁に回されるタスクを考えても実際8コアもあればあまり支障はなく、16コアのRyzenが用意されるのであれば不満はなさそうに思える。

ただ、ゲームをすることに関していえばGeForce優位は揺るぎそうにもないし、かといってLinuxでは現状NvidiaもIntelもなかなかの惨状ということを考えればRadeon以外選択肢はないという状態であり、 これが2台構成を求める理由ともなっているが、1台を選ぶのであればLinuxエクスペリエンスを優先することになるだろう。

ただ、Zen2の世代ではまだP720は現役で、しかも「非常に高機能で並列処理能力は高いが、通常の使い方ではそれほど性能は高くなく、消費電力はやや少なめで、筐体はとても大きい」マシンをメイン以外で使うというのは非常に難しい。 今Godavariがそうであるように、「主にWindows環境(音楽制作)、必要なときは計算資源または分離された帯域としてのLinux」みたいな使い方になるだろうか。 実際、音楽制作では機材がIntelプロセッサを想定したドライバでAMDドライバだといまいちうまく動かないケースもあり、現在のP720のような構成は非常に好ましい。 多くのVSTプラグインを使う場合も4114はかなり良い働きをしてくれる。 それでも、なんとも微妙な話で、Zen2世代でメイン機の差し替えを行うかは悩ましいところではある。

やはり「それぞれの用途で最適化した理想の2台」なんて夢見がちな話をするに留めるとして、多分本当に多くの人にとって有益なのは現時点で性能的にやや微妙な立ち位置にあるRyzen Gが不満のない性能まで引き上げられること、 あるいはRX 580相当のRadeonがもっと安く、省電力でコンパクトなものとして出てくることだろう。それは、次の世代で実現するかもしれないし、Zen3の世代まで待たねばならないかもしれない。

一方、X11はいよいよ限界を迎えている感もあるが、一方でWaylandがよくなっているわけでもない。 IntelもNvidiaも不具合が出る状態が続けばかなり苦しいことになるだろう。


  1. 具体的にはFlower Knight Girlである。 なお、 18禁バージョンもあるため 検索される際にはくれぐれも留意願いたい。

21.5インチFHDと32インチ 4kディスプレイをLinuxで混ぜる

なにをしたか

あらまし

私はディスプレイは「随時買い足す」スタイルできた。 それも、主にリサイクルショップで買い集める形だ。

台数が多く、並行作業も多いので、接続数の関係上どうしてもディスプレイが増えざるをえない。

そうした中、ずっとメイン環境を支えてきたのがLGの22EN33及び22EN43である。 支えてきた、と言うと良さそうに聞こえるが、私にとっては最悪なディスプレイである。 輝度調節がおかしいし、色味も最初からぶっとんでいて調整の意味がない。挙げ句、ドット抜けはあるし、ちょっと触れただけでも傷はつくし、アダプタは激しくコイル鳴きするし、一度は液晶抜けするし、LGのサポートは「何も問題はない」と突っぱねるし、もう二度とLGのディスプレイは買わないと心に決めるくらいはひどかった。 似たようなサムスンのS22B300は非常に素晴らしいディスプレイなので、サムスンがPCディスプレイをやめたのが残念でならない。

基本的に輝度や色味などのぶっとび度合いは22EN33のほうが悪いが、傷がついたりドット抜けしたり壊れたりとトラブルが多いのは圧倒的に22EN43である。そして、その22EN43が、ついに画面全体に乳白色の何かを浮かべるようになってしまった。

困ったものだと思っていたところ、なんだかちょうどよくアウトレット品の4kディスプレイ、AcerのET322QKがえらい安くで出ていたので即決してきた。

解説

これは、もうちょっと説明がいるだろう。

私のディスプレイは圧倒的に21.5インチFHDが多いが、これはFHDディスプレイとしては安いためである。叩き売られることも多いし、中古も潤沢だ。

基本的にはやや小さいが、DPIとしては101ないし102程度であるため、これ以上大きいと96を下回ってしまう。解像度的には無難な線だ。

4kに変更したい、というのはずーーーっと前から思っていたこと(10万円くらいの4kディスプレイが出始めた頃から)なのだけど、その場合27インチを本命としていた。 これは、視線移動量と視点距離を考えたときにこれ以上大きくなってほしくないからだ。 一方、21.5インチや24インチの場合、4kになることで密度が上がり、必然的に多くの情報を表示できることから、より色々と表示できるし、ウィンドウのクォータータイリングも現実的になる…はずなのだが、24インチや21.5インチの4kではあまりにも表示サイズが物理的に小さいため、結局左右タイルが限界であり、あまり情報量が増えない。 27インチもまぁまぁきついが並べるには限界サイズである。

私のディスプレイは基本的にメイン2+サブ1という使い方なのだが、今回は事情が事情だし、2枚は買えない。 そこで1枚だけ置き換えるのだが、そうするとメインディスプレイ同士で表示サイズが著しく違うという事態が生じる。

32インチはちょっと大きすぎるが、おけないこともない(32インチ2枚は机のサイズを考えても現実的でないくらいは厳しい)し、DPI差が小さく、妥協できるセッティングが出しやすい――このことはこの記事のこのあとの話で延々触れる。

ちなみに、アウトレット(展示品)というといまいち感があるが、ディスプレイの場合保証があったところで対応されづらいのが現実である上、対応されることのないドット抜けや表面の擦り傷というのがあって賭けみたいなところもあるので、動いている実物をチェックした上で買えるのはむしろメリットだと思っている。

今回は、これまで理解はしていたが、実際に混ぜてみたことで改めて実感したことを述べていこう。 もちろん、Linux前提である。

小さい? 大きい?

実測値としてはLG 22EN43は幅47.7cmで1920px (102dpi)、 ET322QKは幅69.3cmで3840px (140dpi) である。

102 / 140 = 0.728571427571… であるため、ドットは72.857%(約3/4)に小さくなったことになる。

逆に、ET322QKをFHD表示にした場合は145.71%に拡大されることになる。これは、単純に21.5インチディスプレイから同一解像度(FHD)のまま32インチディスプレイに変更した場合と同様のことである。

これは一辺を見た数字だし、基本的にコンピュータ上で表示されるものというのはボックス状なので、面積で言うと53.08%まで小さくなっているのでだいたい「半分になった」という感覚だし、FHDのままだと212.31%と「倍になった」感じがする。もちろん、ディスプレイの表示面の面積自体倍以上に大きくなっている。

これをまぜたとき、FHDで統一するともちろん4kディスプレイのほうが物理的に大きいぶん大きく表示される(倍以上に!!)のだが、実はこちらはあまり気にならない。 「大きいテレビで引き伸ばされた画面を見る」というようなことに慣れているからだろうか。実際、その画面を見ると「ギザギザでぼんやりしているなぁ」と私は思うのだが、でもそこまでみづらいということもない不思議だ。

ところが、FHDで適性なサイズにしている状態で4kに表示させると表示サイズが半分になっていながら表示する空間は4倍ある(表示可能な量は4倍にしかなっていないのだが、「半分のサイズで表示されている」「空間は4倍になった」というそれぞれ別の感覚が相乗効果を発揮する)のでやたらがらんとして見えるし、やはり適正サイズの半分というのは小さすぎる。 高密度になっているので意外と文字も読めるは読めるのだが、しかしながら非常にきつい。4kを4kとして運用する以上、元のままのスケールではちょっとやっていられない。

ちなみに、32インチのディスプレイは問答無用で大きい。一枚だけ使うにしてもかなり距離がないと大きすぎるくらいで、マルチディスプレイするサイズではないな、と感じる。

混ぜる場合どうスケールさせる?

4kのほうがいいディスプレイだし、物理的にも大きいので4kをメインに考えるべきだろうと思うのだけど、 72.857%ということは、元の状態でスケールしていなかったとしたらだいたい1.4倍にするとFHD側の元の状態と同じ物理サイズになる。1.5倍だとちょっと大きい。

ところが、1.4倍にスケールさせてしまうと、FHDの論理ピクセル数は1370となるため、HD(FWXGA)と同等になる。縦は771ピクセルである。 21.5インチのHDディスプレイというのは実在したが、ちょっと狭い。ウィンドウをタイルして並べるとやたら文字も大きく表示領域がまるで足りない感覚になる。

だから、間をとって1.2倍(あるいは1.25倍)というのがよさそうではある。フォントサイズは少し大きめにしたほうがいいかもしれない。4k側で文字が小さく感じるかもしれないし、部品が多少小さくなるのに比べて文字が小さくなる影響は大きいからだ。

1.2倍スケールの場合FHDの論理ピクセル数は横1600ピクセル、1.25倍スケールの場合1536ピクセルになる。1.25倍だとちょっと狭いが、1.2倍ピクセルなら「なんか表示が大きい」程度で済ませることもできそうな感じである。 MacなんかはUIが大きくぎっしり表示されるので、それが気にならない人は普通にいるだろうし、悪くないかもしれない。

試した結果は結局「間をとる」という無難な結論になってしまった。

ちなみに、今回の場合21.5インチFHDが2枚で32インチ4kが1枚という構成であるためにあまりFHD側を無視するわけにもいかなかったが、これが4k2枚でFHDが補助ディスプレイであるという話であれば1.4倍スケールでも別に構わないだろう。1370ピクセルあればウィンドウを常に最大化してしまえばそんなに気にならない、というか、そもそもラップトップが実DPIに合わせてスケールするとそれよりも小さくなるのが普通なので(私のThinkPad X1 Carbon(14インチ FHD)は148DPIでスケールされているため論理ピクセル数は1228である)表示スペースが足りずにはみだすようなことはあまりない。

それぞれスケールできない?

できない、らしい。

Windowsだとディスプレイごとに「拡大率」という値を設定できるようになっている。 この拡大というのはまんまスケーリングを意味しているので、ここで175%を設定すると論理1ピクセルに対して1.75ピクセルをカウントするようになる。

だが、この設定が今のところLinuxでは上手くできない。 最もスケーリングが細かくできるのはKDE Plasmaだが、それでもディスプレイごとに独立した設定はできないようになっているようだ。

xrandrを使うことで設定自体は可能だが、少数の値を設定してしまうとフォントがすごく汚く表示されることになる。

だから、現時点ではディスプレイごとのDPI差を適切に埋める完璧な方法はない、ということになるだろう。

フォントだけ合わせるという方法

今回の場合、51.6%に縮小されるもののUIのサイズとしてたいていの場合は51.6%というのは私にとっては許容できるサイズに収まった。

そこで、私がとった方法がこれだ。

実DPIによる影響が最も大きいのは「文字サイズ」であるため、LinuxでもUIスケーリングとは別にフォントはスケーリングできるようになっている。

そして、フォントのスケーリングの構造はちょっとめんどくさい。

フォントの場合96を1として、設定されたDPIの倍率にスケールされる。 つまり、144DPIを設定した場合、144 / 96 = 1.5 なので、1.5倍にスケールされる。

フォントにおける1は1ピクセルであり、1ポイントでもあるのだが、両者は同時にスケールされることになり、基本的には同一視できる。 FontConfigは144DPIを設定した場合、16pxを求めても、16ptを求めても、24実ピクセルで描画する。 問題はビットマップフォントを使う場合だが、その話は割愛する。

基本的に115.2DPIにすれば1.2倍スケールとなる。120DPIで1.25倍スケールだ。 UIと比べ柔軟に設定できるので、このあたりを参考にバランス良い設定になりそうなDPIを設定すると文字側は調整できる。

私は今のところ120-136DPIの範囲で様子を見ている感じだ。 KDE Plasmaの場合、ほとんどのアプリケーションはPlasma Workspace側で設定されたDPIに従うが、ConkyはFontConfig設定ファイルを尊重するため、Conkyのサイズ調整を目的に異なった値を設定する方法もある。

あとは、積極的にフォント側DPIを設定してからUIスケーリングでバランスをとる、という方法もある。 この方法はもっと実DPIに差がある場合の解消方法として使える。 また、フォントのみで解決する場合は細かなUIスケーリングがいらないため、「Hi-DPIのためにKDE Plasmaを使わなくてはならない」という状況を避けられる。 (KDE Plasmaは0.1倍単位でUIスケールできる)

もはや、DPIとかピクセルとかポイントとかいう、定義が明確であるはずの言葉が相対的なものになってしまっていて意味がわからないが。

なお、フォント設定でスケールする場合に特に重要なこととして、「普段GTKデスクトップを使っていて、スケーリングのためにKDE Plasmaにスイッチした人」は、.xprofileなどでexport QT_QPA_PLATFORMTHEME=qt5ctとかしているのであれば、それをやめないとKDEの設定がちゃんと反映されず、GTK2アプリケーションにも反映されない。

また、この方法を取る場合、パネルだけはCinnamonもPlasma Workspaceも高さがピクセル単位になっているため大幅に小さくなってしまう。このため、パネルの高さは再調整が必要だ。 私の場合、サブディスプレイ上にパネルを置いているため問題はなかった。

ブラウザのスケーリング

ウェブブラウザはちょっと特殊な事情を持っているようだ。

Chromium系(ChromeもVivaldiも)ブラウザはフォントのDPI値が約110%以上(103以上?)であるとき、そのDPI値に合わせて10%単位でスケールするようだ。 これはブラウザをズームしたときと同じ挙動だが、困る場合がある。

これによってパーツがはみ出してみづらい場合があるが、これについてはまだズームを落とせばいいので許せる。 問題はフラゲ(フラッシュゲーム)である。 見た目が汚くなる上に動作が遅くなって非常に辛い。

なお、Firefoxはまた事情が違うのだが、layout.css.devPixelsPerPx1にすれば自動スケールは行われなく成り、-1にすると自動的にスケールされる(多分、UIスケールによるのだが、DPIによるのかもしれない)。この機能に関してはlayout.css.dpiも絡む。

実際、メイン/大きな4k * 1 + サブ/小さなFHD * 2 ってどう

だめ。 どうしたってみんな4kを取り合ってしまう。

なにをするにも大概大きい4kっていうのは便利で、できればそこに置きたいという気持ちが強い。 みっちり書かれている文章だとそうでもない(FHDの全画面表示でもテキスト量が多すぎる)けれども、なにかしら情報が付属していたりマルチペインだったりするのが現代なので、たいていのアプリケーション及びコンテンツが4kを奪い合う。

サブは私の場合メール, Discord, Twitterなんかになるのだけど、これらは基本的にリアルタイムで見続けるようなものでもないからそれぞれ全画面化してサブに置いているものの、4kだったらモニタリング機能とか作ってタイルして色々表示させてもいい。

だから特に必要ないものも含めてたいていのアプリケーションは大きな4k(もちろん、適切な大きさの)を欲しがる。 21.5 FHDを回転させて縦にするとバランスはいいが、表示できるものはさらに少なくなる。

32インチを複数置くのは難しいので、やはり27インチ4k*2 + 21.5もしくは24インチFHDというのがバランスがいいと思う。 逆にサブを32インチ4kにして少し離してモニタリングに使う手もあるけど。

Acer ET322QKってどう (2018-12-03 追記)

基本的には悪くないと思う。 少なくとも22EN43/22EN33のように色味がおかしくて輝度もおかしくて視野角も異様に狭いといった問題はない。 特別良いということもないけれど、かといって目立った問題があるわけでもない。

特別良いというわけではなく、色味も標準(というフラット設定)ではフラットではないため、アートワークの作業をするクリエイターにはとても耐えないし、ゲーマーにも無理だろうけれど、 動画視聴程度であれば遅延が気になるということはないし(ただビデオカードのほうは4kなのでちょっと重いけど)。

色味も、特に優れたところはないけれど、別に使えないことはない。一応sRGB 100%らしいので、カラーキャリブレーションすれば結構使えるのかもしれない。

目立った問題としては入力端子が3系統(HDMI 2.0×2, DP 1.2×1)であることだろう。 台数が多いとなるべく集約したいので、端子はなるべく欲しい。 私の環境だとDVI-Iが多いけど、別にDVI-ItoHDMIは可能なのでHDMIで良しとして…

メーカー モデル ポート
IO DATA EX-LD4K271DB D-Sub, HDMI(2), HDMI 2.0, DP
IO DATA KH2750V-UHD D-Sub, HDMI(2), HDMI 2.0, DP
BenQ EL2870U HDMI 2.0(2), DP
LG 27UK650-W HDMI(2), DP
iiyama ProLite B2875UHSU B2875UHSU-B1 DVI, D-Sub, HDMI 2.0, DP
JAPANNEXT JN-IPS27FLUHD HDMI 2.0(2), DP(2)
DELL S2817Q HDMI(2), DP, miniDP
ASUS VP28UQG HDMI 2.0(2), DP

JAPANNEXTがIPSで消費電力も最大35Wと低いのに安くてなんか強い。 それはともかくとして、以前のように端子数5を越えるものは減っている感じだけど、3というのは結構少なめ。 端子数4は普通に狙えるので、そこは残念ポイントな感じがする。

最大の難点は、起動が遅いということだろう。 EIZOとかも遅いので、品質の問題ではないけれど、結構遅い。そして、切り替えも遅い。信号がなくなってから再び信号を捉えるまでが長い。

「待てばいいじゃん」と思うかもしれないが、実は KDE Plasmaでは深刻な問題になる

KDE Plasmaで思わぬ問題 (2018-12-03 追記)

KDE Plasmaの場合、ディスプレイに対してディスプレイの接続方法ではなく、「ディスプレイの認識上の番号で」識別する。 KDE Plasmaはディスプレイを中途半端に重ねることも可能で柔軟なのはいいのだが、応答の早いLG及びサムスンのディスプレイはすぐつくのだが、このときKDE Plasmaは「ディスプレイが2台しか接続されていないように見間違う」。

つまり、左から

  • LG HD
  • ET332QK
  • サムスン HD

と並んでいて、パネルはサムスンの上にあるのだが、 このときこの並び順に最初にKDEにログインした時点では認識されている。 だから、パネルは3番ディスプレイにある。

ところが、一時ブランクスクリーンになって復帰すると、ET332QKの認識が遅れるためにサムスンが2番になり、ET332QKが3番になる。 結果としてサムスンとET332QKの壁紙が入れ替わり、パネルはET332QK上に移動してしまう。 さらに、なぜか中心座標を見失ってしまって、Conkyが1920pxずれる。

3台であれば右にあるディスプレイをプライマリディスプレイにすることで1番を固定すればET332QKが最後にくるように固定できるから問題は軽減される。 だが、アンバランスな配置のせいかPlasmashellがバグることが多い。さらに、どうしても左側のディスプレイをy:1081に固定するのが難しい。y:0になってしまう。

また、マルチディスプレイではKDEはフルスクリーンにしたときにパネルの表示がおかしくなる。 パネルの表示の上に古いパネルの表示がかさねられたようになる。つまり、以前同アプリケーションでフルスクリーンにしたときと同じ状態になる。 確実になるわけではないが、一度発生するとフルスクリーンにするたびに再現しつづける。

結局、私はCinnamonに戻した。 フォントのスケーリングを中心としてUIスケーリングしないことにしたため、これでも問題はない。

CinnamonのフォントスケーリングはDPIではなく倍率になっている。 0.1倍単位だが、1.25倍で120DPI, 0.1倍あたり9.6DPIというのを基準に考えれば良いだろう。 今の状況を考えるとこちらのほうが素直だろう。

このままではQTアプリケーションが小さいので、.xprofileQT_SCALE_FACTORを設定しておくと良いだろう。 1.2とか1.25あたりが無難な値になるだろうか。

ところがCinnamonでも… 原因はDP (2018-12-05 追記)

Cinnamonなら大丈夫と油断していたところ、Cinnamonでもブランクスクリーンに落ちるとおかしなことになってしまった。 パネルがおかしくなるといったことはないのでKDE Plasmaよりはマシではあるものの、好ましい状態ではない。

どうも他のディスプレイでは発生しない症状として、「電源がオフになると切断される」らしく、問題はディスプレイの電源を切っても発生する。 そして調べていくと、「DPの仕様」らしいとわかった。なるほど、確かに他の2台はminiDP→DVI-Iで接続しているのでDPではささっていない。

WindowsだろうがLinuxだろうが、ディスプレイのホットプラグで問題が生じないなんてことはないので、これは大迷惑である。ディスプレイを共有して作業していることなんて普通にあるのだし… 実際、この挙動は相当強く嫌われているようだ。

なんとかしようとがんばって/etc/X11/xorg.conf.d/90-mhwd.conf

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
        Option "NoLogo" "1"
        Option "UseHotplugEvents" "false"
        Option "AllowEmptyInitialConfiguration" "true"
EndSection

などと書いてみたものの残念ながら効果はなし。

ただ、この場合問題ははっきりしているので、本気になればやりようはある話だと思う。 とりあえずは私の場合ディスプレイの電源を切らないように設定してしのいでいるが、困るのは「通し作業のときにディスプレイを切って節電する」という方法がとれないことだと思う。

そのうち何か考えて対応したい。

がんばって解決した人がいるようです (2018-12-16追記)

Twitterでのやりとりを経てエヌユルさんがxrandrを使う方法で解決した旨ブログにかかれていました

実はこの方法、私にとっては既知で、以前のスケールとDPIのアーティクルを含めて「あんまよくないので言及を避けていた」方法だったりする。 しかし、参考にしてもらえるなら、もっとちゃんと説明すればよかったな、この方法でよかったなら悩ませずに済んだのに…と割と後悔している。

手順、及び結果はどうブログの記事の通りである。 ちなみに、ディスプレイ位置が上限に合わせられてしまうのは「0,0にディスプレイを欲しがる」からで、左のディスプレイが4kなら問題ないのだが、そうでないとFHDディスプレイを上にあげたがる。 Plasma Workspaceだと勝手に修正されてしまったりする。

私が言及を避けたいと思う理由は次の通り

  • ディスプレイをネイティブ解像度以外にしたときのようなもやっと感がある
  • xrandrのスケーリングはFTより後段にあるため、字の描画が大変汚い
  • Plasma Workspaceはひょんなことでこの設定をリセットしてしまうのでえらいことになる(パネルが吹っ飛んだりする)。 これは、ワークスペース切替時、アクティビティ切替時、ロック時などに発生しがち
  • DPのホットプラグ切断による問題がより深刻化する
  • 私としてはUIサイズはそれほど気にしないがフォントサイズの落差が辛い、ということを問題にしているので、FHD側を1/4角にするというのはフォントサイズの設定において事情が変わらない(単に元はFHDが4倍角だっただけの話なので、DPIをだいたい中間に設定するという話から動かない)

UIスケーリングに関しては、現代においては「ブラウザ(特にBlink系)がフォントDPIに従って勝手にスケールしやがるので、中間DPIを設定しておけばだいたい許せる結果になる」というのが私の感想である。 画像を見たり、VSCodeとかAtomを使う分には割とどうとでもなるので(ディスプレイを4k/FHD間で動かすのは大変だけど)、「フォントサイズさえ妥協できるサイズにしとけばいいや」が私の現状の結論。 もちろん、言うまでもなく「ディスプレイごとに適切スケールさせろ」と言いたいところだけど、未だにNvidiaがLinuxでマルチヘッドディスプレイに対して雑な対応を続けているあたりを考えると、多分無駄な主張になるだろう。 世の中マルチヘッドディスプレイが当たり前になっていっているわけでもないし。

あと、本題とは関係ないが

世の中のwebサイト巨大ディスプレイに最適化されてなさすぎですね.

これについてはDPIと画面サイズとスケーリングとピクセルの話で書いているけど、基本的に現代においては「1ピクセルが物理的1ピクセルを意味しない」というスケーリングの方向であり、 14インチのThinkPad X1 Carbonですら横の論理ピクセルは1288pxである。12.5インチのThinkPad X280では1047pxしかない。 この方法は、そもそも「物理的にピクセル数が増えても論理ピクセル数は増えない」というものなので、XPS13の4kを使ったところで、論理ピクセル数は1200pxに満たないのだ。

私はFCとしては120dpiに設定しているので、ブラウザは1.2倍にスケールするのだが、それでも4k側だと3200pxも幅があることになる。 さすがにこれを「想定しろ」というのは無理な注文だと思っている。 4kを使うならウィンドウをタイルする、で良いのではないだろうか。大きな4kディスプレイを持っている人はある程度知識がある人のほうが多いし、安全側に倒すならそちらを優先した設計はできない。

どちらかといえば私が考慮すべきなのではないかと考えるのはChromium及びFirefoxのテーマだ。 あれらは全くスケールしないため、4kで最大化すると画像サイズが足りずすっかすかになる。

4GBの人権

ことの起こり

最近「会社の支給PCのメモリが4GBであることが悪行である程度」が話題になっている。 もちろん、これが意味するのは「会社の支給PCのメモリが4GBであることは許されざる罪である」という点に関しては異論を差し挟む者は基本的にいない。

この手のことは何度か話題になっているのだけど、今回特段話題になっているのは論点が広がったためであると思う。 今までは「エンジニアのPCがメモリ4GB」という話題だったのだが、ここにきてそれ以外にも

  • バックオフィスのメモリは4GBでいいのか
  • エンジニアとオフィスワーカーのスペックに差があって良いのか
  • 16GBのマシンを支給しているところは名乗り出てみろ、の煽り → タイミングよくサイボウズがバックオフィスにも32GBを支給していると公表

おおまかにはNTTがGAFAに引き抜かれてて処遇改善を考えているよ、という話と、NTTをやめてGoogleに行った人のブログがバズったから…というところにあると思う。

なお、今回の記事の基本的なところはLinuxのメモリの本当の必要量を考える(メモ)を読んでほしい。

自己紹介

私が使っているマシンは今かなり幅広い。普段から使っているものだけに限定しても

  • 40コア IntelスケーラブルXeon (Skylake) / 128GB RAM
  • 4コア Xeon (Bloomfield) / 20GB RAM
  • 4コア APU (Godavari) / 32GB RAM
  • (サーバー) 2コア Turion II Neo (Geneva) / 2GB RAM
  • (ラップトップ) 4コア Core i5 (Kabylake) / 8GB RAM
  • (ラップトップ) 2コア Celeron (Haswell) / 16GB RAM
  • (タブレットPC) 4コア Atom (Bay Trail) / 2GB RAM
  • (ラップトップ, ルーター使用) 1コア Celeron(Netburst) / 1GB RAM

とかなり様々だ。

メモリ4GBのマシンがタブレット(実体はPavilion x2 10-j000)とサーバーしかないが、実際のところマシンラインナップとしてはもっと色々あって2GB/4GBのマシンも何台かあるし、そもそも先代主力機だったBloomfield Xeonワークステーションは結構な間4GB RAMでがんばっていた。

そもそも、Turionのサーバーはメインマシンの不調やシステムの組み直しで結構な期間(トータルで3ヶ月くらい)メインマシンを担ったことがある。しかも最近の話である。

なお、OSはタブレットだけがWindows 10で、他は全てManjaro Linuxなのであまり参考にならないだろう。

使用マシンの経験も幅広い。最初に使ったのはIBM JX3だし、RAMはわずか128kB(単位に注意)でしかなかった。さのあとのSunワークステーションはなにするにもパワー不足だったし、AptivaはOSの起動すら危うかった。 ようやくひと心地つけたのは当時ハイエンドクラスだったVAIOだけれど、メモリは64MBにすぎず、やはりなにをするにも足りなかった。

そして今でも192MBに拡張したもののVAIOは現役だし、練習機のメモリは1GBである。

一方で今の40コアXeonに代表されるように一般的なPCの次元からは逸脱したマシンの利用歴もある。 さすがに現役でEPYCを使っている人にはかなわないが、それでも有り余る性能を使い切るような経験もある。

普通の人が経験するよりもずっと幅広いマシンで、そのマシンでできる限界の作業をするという経験 をたくさん積んでいる、と言えるだろう。

また、私はメモリの利用状態を常にConkyで監視しているし、一定以上に高まったときにはメモリの利用状況をダンプする(自動で行われるものと、ワンクリックで実行できるものの2種類。実行内容は/proc/meminfopmap -xによるもの)という運用をしている。 つまり、メモリの使用量というのは一般に感覚やメーターで把握するよりはかなり厳密に把握している。

「メモリの使い方」の話

適切さの話は置いておいて、「エンジニアが4GBでまともに仕事ができない」というのは、特に個人的なコンピュータが4GBで使えないというのは、私としては無能な印象を受ける。

実際、Manjaro Linuxは結構「全部盛り」方向の環境なのだが、それでもブート時はそれほど重くない。 XFce4, Cinnamon, KDE Plasmaいずれでもだいたい1GB前後、せいぜい1.3GBといったところである。そして、このまま普通に(タスク切り替えで)利用していても4GBを突破することはあまりない。

私にしてみれば、制限的環境としては4GBというのはものすごく余裕がある。 普通にAtomやVSCodeも使えるし、Chromiumでウェブブラウジングもできる。 これが2GBになるといきなりきつい。実用的なデスクトップ環境だと1GB近くメモリを使ってしまうので、Chromiumでブラウジングするともたない。「Chromiumを諦める」でも「デスクトップを制限する」でも使い勝手に非常に大きな影響を感じる。

だが、4GBあれば普通に使える。 といっても、「4GBを前提としていれば」だ。 「あまりメモリを使わない使い方をする」ことによって「4GBで不足することは稀である」という状況を作り出せるという話なので、ある程度のスキルがいる。 つまり、一般エンドユーザーにとっては4GBというのは難しい。だから、事務職に4GBのPCを与えるのは率直に言って罪な無知である。

だが、エンジニアだと話は違う。4GBで作業に支障をきたす、というのは修練が足りない。 4GBという枠を与えられてその枠内に抑えた進め方ができないということは、開発しているものが許容されるパフォーマンスの制限やリソースの制限に収めた最善を尽くすことができないということなので、その意味でも能力の欠如を晒すことになる。

前提が変わる要素は多い

言うまでもなくこれにはいくつかの観点がある。

まず、4GBで「十分でない」ことは明らかなのである。

そもそもメモリの性質を考えてみよう。メモリというのは余っていることによってなにか嬉しい効果があるわけではない。もちろん、使っていて余剰があればそれをさらに使うことはできるが、つかっていないのであれば余っているものは余っているだけなのだ。 だから、「足りなければ工夫する、余っていれば使い方を増やす」というのが基本になる。 そして、「工夫しなければ足りなくなる」4GBというメモリ量は「足りない」ということは揺らがない。

そして、使用するメモリというのは「何を」するかで話が大きく変わってくる。 まずChromiumやChromeを使っている時点で使い方としては重いわけだから、「ウェブブラウジングをする」というのを前提に話は進められない。 そもそも「これが当たり前」に言っている人は想像力も経験も足りないし、可能性を追求したり工夫したり想像したりしない人はエンジニアに向いてすらいない。

私がやっている中ではメモリを軽くするのが難しいのはホスト間接続テストである。 かなり多くのVMを接続する必要があることから、極限まで軽くしてもかなりのメモリが必要になる。 だが、少ないホスト数でテストする、ホストそのものを極限まで軽くする、という手段はとれるので20ホスト4GBとかで動作しているが。

もっと厳しいのは利用方法がそもそも制限されている場合である。

もっとも致命的な制限は「Windows 10を使う」だと思う。 最近のWindowsのリソースマネジメントは私には理解しがたい。 いくら性能を積んでもエクスペリエンスが改善しないのだ。Windows 7の頃は「リソースが有り余っているのに全然活用しない」という問題だったが、今はWindowsシステム側でリソースを食いつぶしてしまう。 40コア128GBのシステム(ディスクはサムスン製NVMe SSD)を以てしても「フォアグラウンドプロセスがバックグラウンドプロセスに邪魔されてスリップする」という不毛極まりない事態を起こす。 「馬鹿じゃないの!?」と大声で叫びたくなる。

なにをしてもとにかく無駄な処理が多いのだ。単純なプログラム起動時間も、かなり遅い部類に入るLinuxと比べても果てしなく遅い。

Windowsで重い作業をすることがなく、Windowsで8GBを使い切るのをみたことは一度もないが(少なくともシステムモニター上では)、Windowsの挙動なら必要のないメモリを食いつぶしてもおかしくはない、と思う。 もっとも、このマシン(40コアXeon)でもメモリを使い切る以前に「プロセスの起動待ち、その間他の作業は阻害される」みたいなことが頻繁にあるので、叩き壊したくなるほどエクスペリエンスが悪いし、メモリが増えたところで作業効率が上がるとは到底思えなかった。 それが気にならずメモリの容量を問題にしている人は、スマホを平気で使っているんだろうな、と思う。1

もちろん、Windowsはエクスペリエンスが悪すぎるから開きっぱなしにしている、という可能性もあるが。ただ、Windows10はウィンドウスイッチングも結構遅い。 (ビデオカードももちろん良いものを使っているのだが)

また、メモリを食いつぶすことで有名なアプリケーションと言えばEclipseである。 Eclipseを使うと一気にメモリ8GBでは怪しい、という事態になる。 これは今どき使わなければいいとか、果てはそもそもJavaを使わなければいいとかいう話にもなるのだが、Eclipseを強要されるケースは普通にあるようなので、こういう場合はやはり状況が変わってくる。

ただ、例えばGitの操作でメモリが128GBもあれば押し切ることのできる通常はできない操作というのもあったりするのだが、「メモリ8GBじゃ力押しできないから」というのはさすがに頭が悪い。 それは方法を考えるべきだ。実際、メモリ8GBだと重めのソフトウェアはYaourtのデフォルト設定でAURからのビルドはできないのだが、それは普通に実ディスクを使ってもらうようにすれば解決する。潤沢なときに許される力技ができないことに文句をつけるのは筋合いではない。

しかし、基本的には労働者にとっては必ずしも支給されるPCの性能というのは重要ではないと思う。 個人の裁量で他のマシンが使えるとなると結果的に労働者に対して負担を強いることになるため、非常に不適正といえるけれど、皆が同じマシンを使うのであればそれは統一された前提条件である。 コンピュータの性能は生産性とできることへの制限だから、業務効率やビジネス展開を制限することになるのだけど、それは労働者にとってはストレスだろうけれども、その時間でできることをすれば良いわけで、その問題に向き合う必要がない。その問題に向き合うべきは経営者だからだし、現に存在する「性能の低い(あるいは制限の厳しい)コンピュータで開発したくないから出ていく」というエンジニアのことを考えれば「人材の流出」という問題でもあり、それもまた経営者が向き合うべき問題である。

どのようなコンピュータを支給するかは経営戦略への影響も大きく、労働者側から不満を言うのはもちろん自由だが、その是非を断じるのはかなり難しい。 そして、それが「本当に不足なのか」あるいは「スキルでカバーできないエンジニアの戯言」なのかという点も、どのような条件に基づいているのかわからなければなんともいえないので十把一絡げに言えるものではない。

グレーディングの問題

コンピュータの性能が「上下」や「優劣」に使われる、という問題は、まぁわからなくはない。 というか、実際に私が思い描いている「会社経営像」でも「何をする人か」そして「どのような方法でする人か」「どのくらいのスキルがあるか」によって(さらにいえばもっと様々細かなことまで含めて)「個別に選定する」ことを想定している。 もちろん、これは顔の見える範囲でしかできない方法だが、コンピュータのグレードが揃っていないことは私はそれほど問題だとは思わない。

そもそも、メモリやCPUを「使う技術」と「使わない技術」はそれぞれ別にある。 私が使っているようなコンピュータは一般的なパソコンとは比較にならないほどリソースがあるし、これを単に「快適」などということで終わらせず、しっかりそのリソースを活用できるようになるにはそれなりにスキルがいる。 同時に、非常に性能の限られたマシンを最大限に活躍させるのにもスキルがいる。

だから「欲しい」で最大限与えるのは不毛なのだけれど、特別な理由がなければ特別な使い方をしない限り通常は不足しないように設定するのが好ましい。 そして、その「通常の使い方におけるリソース要求量」が「なにをどうやってしてるか」によってかなり差が出るのだ。

だから、その違いによって異なる性能のコンピュータを設定するのは悪くないだろうと思う。

だが、そこに変な要素が加わるのはさすがにまずい。

例えば、グレードの上下が地位の上下に比例するようにするとか。 これはもう、柔軟な更新ができず、まとめて更新なんてなったらすさまじい費用と税金がかかる最悪なパターンだと言っていい。

それから、「エンジニアよりもバックオフィスが下」というのもだ。 どちらかといえば日本のITはMS Officeに依存しているような面があり、効率がよくないMS Officeで、無駄に巨大なExcelシートを開くというようなことも割と珍しくないだろう。 そう考えると、「メモリ使用量が8GBを越える普通な使い方」は事務方のほうが想定しやすいほどだ。

現実的には

4GBというのは相当に厳しい制約だと思う。 普通に使えなくはないけれども、普通の人が普通に使える、にはならない。 経営者側からみれば、そこまでケチって生産性を下げることはメリットがないだろう。従業員が優秀か否かによらず4GBメモリのマシンを採用したならば、せっかくの人員を無駄遣いすることになるのはほぼ間違いないだろう。

8GBか16GBかということはやや難しい。 16GBあれば安心だとは思うが、ラップトップだと簡単に16GBを選択できるモデルは少なく、ハイエンド構成を要求されることが多いのが2018年の事情だ。 だから、「無難な線」という意味ではデスクトップでは16GB、ラップトップでは8GBになると思う。

デスクトップの場合8GBと16GBの金額差は割と小さいことが多く、ちゃんと選べば全体での価格差もあまりない場合が多い。そもそも、調達先はその程度の自由度をもって選択できるところと付き合ったほうがいいだろう (DELLとhpは大変無難な調達先として有名である。DELLはベンダー経由でも入りやすい)。

ラップトップまで16GBを投入するか…ということには著しい疑問があるのだが、会社支給のPCとしてはデスクトップを主軸として16GBにして、必要な場合に限りラップトップを8GBで追加支給するというのが無難なのではないかと思う。

「16GBが必要になる条件なんて限定的だから必要ない」という考え方は避けたほうがいいと思う。経営者ならば、労働者にとって争点になることを余計に作り出すべきではないように思うのだ。 8GBで不足することは稀だが、それを不満に思う人が少なくないし、実際に条件によっては不足するのだから差が小さいのならそこまでケチるよりは16GBを支給するほうが良い経営判断なのではないか。

サイボウズがやっているような32GBだが、私は過剰だと思う。 凄腕も揃うサイボウズで統一するという意味では別に構わないだろうけど、「サイボウズがやってるんだから32GBにすべき!」みたいなのは無視して良い意見だと思う。 4GBに留まっていた時代が異様に長かったが、8GBに移行してからも16GBへの進展はなかなかない。 採用されているメモリ容量は増加がかなり鈍っているのだが、実際のところ16GBを越えると一般ユーザーが活用するのはとても困難なので、10GbEが普及しないのと同じような感じで普及していかないのだと思う。 実際、私もデスクトップユースで16GBを超過することはかなり稀である。以前はあったのだが(使っていると20GBちょっと使っているという時期があった。特にMageiaを使っている時に)、現在は8GBにも到達していないことのほうが多い。

ちなみに、実際のところラップトップで作業しているときは画面スペースがないことから多くのアプリケーションによる並行作業をすることは少なく、また非常に大きなデータを扱うこともないことから8GBで不足気味になることもあまりない (もちろん、これは私が8GBしかメモリがないことを前提として負担をかけないようにしているからだが)。 一方、マルチディスプレイや大型高解像度ディスプレイ、さらには高速ストレージなどを採用して全体的に性能が向上するとマルチタスク性能も上がっていくためそれに伴って必要なメモリ量が増えて8GBを越える傾向がある。

そのため、コンピュータの固定資産としての価値が設定された3年以内に16GBメモリが「不十分な量」になることは考えがたいし、一般的なサポート上限である5年以内でも可能性は相当低いと思う。 だから余程特別な理由がなければ16GBあれば良いだろう。 あればあったで快適な状況や、できることもあるのだが、それは限定的だろうから支給PCの標準とする動機としてはとても弱い。

ハッカー(あるいはワナビー)が個人所有するPCであれば現状16GBしか使っていないとしてもよりメモリを必要とするテクニックを試すためにもより大きなメモリを積んでおいたほうがよかろうとは思うけれど。


  1. 私のスマートフォンはSnapdragon835搭載機だが、Wi-Fi使っててもあまりにおそすぎる。だから私はスマートフォンを必要がなければ触らない。 UXとしては、操作した結果が0.3秒以内に得られないのは失格だ、というのが私の設計方針である。 これは、「遅い」と感じる平均閾値に基づく。

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

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

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しても何度も戻ってしまい、ちょっと苦労した。

hp pavilion x2 10 修理へ

hp Pavilion x2 10のカメラが動作しないために、修理送りとなった。

Skype for Windows Desktop起動時に「全面緑」で動作しない。カメラはインジケータランプはついているのにだ。 Firefox Helloで試すと真っ白。

そして、今回はチャットサポート。 前回と同じ方の対応で、やりやすかった。

「カメラ」アプリでテスト、ドライバ削除からの再起動、BIOSリセットからの再起動と試したものの改善せず、引き取り修理へ。

ついでに、先の液晶の傷?問題も見てもらうことに。

2時間もお付き合いいただき、ありがとうございました…

しかし、私、ハードウェア不良ひく確率高くないか。先日もカメラ初期不良で送ったばかりだし、その前はThinkPadをファクトリー送りにしたし、電熱スリッパも送ったし、なんか憑いてる。

LGディスプレイの顛末

まぁ、次の通りだ。

LGの回答
LGの回答
  • 色がおかしい→否定&交換(下記と同一)
  • 画像がおかしい→肯定&交換
  • アダプタが鳴く→否定&交換

結果としては

  • 画像がおかしい、という点は直った
  • 色はやはり白いが、色が出ていないという部分は直った
  • アダプタの鳴きは多分直った
これでみても右が白っぽく色も出ていない
これでみても右が白っぽく色も出ていない

結論としては

  • フォームで散々サポートを拒否した上、今回も受け取りも経過報告も一切なしで送ってきたので、結構苛立つ
  • 製品品質もひどい
  • 今後LG製品を買うことはないだろう
  • 素直に交換されているので、最終的にはダメだったわけではない(品質は悪いが)。経過や品質を気にしない人はいいと思う。
  • 少なくとも詐欺商品の類ではない
  • 品質に関して、高級なやつは違うのかもしれないけれど、それは分からない。22EN43と22EN33がこれだけ品質が違うので大いにありうる

hp ProLiant MicroServerとCentOS 7とZFSonLinuxの話

ProLiant MicroServerにHDD組み込み

先週秋葉原で買ったHDDが、初期不良対象期間が土曜日までだったので、金曜日にProLiant MicroServerにHDDの組み込みを行った。

実際に開けたり調べた限りで分かるのは次のことだ。

  • HDD搭載個数は4個。ホットプラグではない
  • eSATA端子を装備。
  • 5インチベイ用はSATAでケーブルは付属せず。ただし、ここはIDEとして動作し、低速

とりあえず開けてみる。これが非常によくできていて、扉は鍵で開ける。工具は不要、付属の鍵を使うのだ。ちなみに、上部の5インチベイ部分については、扉を開けた上で後方のボルトヘッドを手で回し(ダイアル状になっていて、工具は完全に不要)スライドする。ボルトは外れるようにはなっていない。

扉は開くが、横倒しにしていると外れることがある。外れると横倒しのままではなかなか正しくはまらないので注意。正しく置いた時に上下とも下側に突起があり、穴に突起がはまるようになっている。なかなか考えられた構造だ。簡易でコストが安く、扱いやすく、壊れにくい。

ハードディスクはホルダーを介して止まっている。リリースボタンを押してレバーを解除し、レバーを引く。レバーが押しこみ防止になっているもので、若干この動作が恐い感触があるが、精度はしっかりしていてブレる心配はない。封印された4台が備えられ、左に500GBのハードディスクが収まる。このハードディスクは裏面がカバーされたサーバー向けのタイプ。具体的にはWD5003ABYX。7200rpmのエンタープライズ、イエローだ。

今回は4TBx1,3TBx3に換装する。ホルダーについては特殊なネジで止められているが、扉の裏側にホルダー用のネジと工具がある。ちょっと探してしまったが、上手いものだと思う。紛失の心配もなく、コンパクトで、面倒もない。また、ホルダーのネジは予備もある。5インチベイ用のネジもここにある。こちらは六角。

順次固定していく。非常に簡単な作業だ。若干ネジまわしが疲れるくらいか。特にケース側はしっかり入っているのと、ネジを落とさないようにしなくてはいけないのが疲れる。数も多いし。

固定したらこれらを閉めて各種インターフェイスを接続、USB光学ドライブを接続しSystemRescueCDで起動。for i in /dev/sd[a-d]; do smartctl --all "$i"; done | lessとして問題がないことを確認した。

ProLiant MicroServerについて

15000円ほどの安価な、いわゆる安鯖、廉価サーバーだ。非常に安価でありながら現代的な性能を持つコンピュータであり、特にまともなコンピュータを持つもたない人にとってはとりあえず購入しておいてもいいというような代物といっていい。

ただし、普通のデスクトップコンピュータ、今の感覚で言うと普通ではないが、とは差異があることを理解しておかなくてはならない。つまり:

  • サスペンドはできない。ハードウェア的にサポートされていない
  • グラフィックスは非力であり、出力はVGA(D-Sub15)である
  • 基本的に枯れたハードウェアを採用。また、CPUは低速で消費電力が低いものを使用
  • OSなし
  • このモデルについては光学ドライブもない
  • ハードウェアがサーバー向けであるため、Windowsではサポートされない可能性がある

だが、サーバーだからこそのメリットもある

  • 24時間稼働に対応
  • ECCメモリーを使用
  • 低消費電力
  • 高信頼性

だが、このProLiant MicroServer Turion II NEO N5 F1F35A0-AAAEに関して言えば、PCI-E x16をロープロファイルながらサポートするため、普通にデスクトップとして使用できる。電源が200Wなのでハイパワータイプはとてもではないが使えないが、ローエンドモデルの接続は可能だ。ただし、ディスクを最大5台積める仕様なので、それだけでいっぱいいっぱいではあるだろう。

とはいえ、別に高性能を目指すようなものではないし、VGAで十分だと私は思う。CPUの性能も高くないし、デスクトップとしてバリバリ使うものではないだろう。だが、ちょっとした用途には十分事足りる。

サーバーとして見ると、この小さな筐体にHDDを4台搭載した上にeSATAディスクも搭載可能、というのは非常に大きい。ただし、eSATAの使いどころはかなり難しい。台数が多いケースは高いし、内蔵に使うにしても引き込めない。予備インターフェイスと考えたほうが良さそうだ。

しかし単純に考えて、筐体自体はHDD6台がCapableであるというのはすごい。しかも、小型の筐体だけに中に手を突っ込めるようにはなっていないが、上部パネルと同じく手回しボルトをゆるめることでMB全体を引き出すことができる、と非常に考えられた設計だ。

さらにECCメモリを搭載するということもあるが、それ以外を見ても非常に安定している。自作機とは比べるべくもないが、厳しく検証を重ねて安定したものと比べても非常に安定している。

さらにBIOS画面の待ち時間はやや長く、しかも入力のためのステップを複数用意する。もしブートデバイスがみつからなくても、そこでブータブルメディアを挿入すると自動的に認識して起動してくれる。つまり、とりあえず起動してからディスクを挿入することが可能。さらに、起動や終了のタイミングでのトレイオープンも可能。デスクトップだと起動時に起動される前にトレイオープンができないため、メディアの挿入/排除が結構大変だ。しかも、ProLiantならゆっくりメディアを入れても大丈夫。

いくつかの問題も発生しているが、ハード自体は極めて安定しており、信頼性も高い。

その上に扉、トレイ、固定方法など非常に心配りのされたつくり。hpが好きになった。

CentOS7

一方、なかなか手ごわいのがCentOS 7だ。

Linuxはサーバー向け、という人がいるが、実際にLinuxのサーバー向けディストリビューションというのは多くない。どちらかといえばEnterprise Server向けだ。

一般的な選択肢は、まず最大シェアのRHEL/CentOS/Scientific Linux/Oracle Linux/Whitebox Enterprise Linux。その対抗馬はSLES、あるいは無償のUbuntu Server、サーバーユースにも耐えるとされるDebian/GNU Linux、あとは枯れた仕様・原始的なシステムのSlackware Linuxくらいのものだ。

この中でフリーというと、RHELクローンか、Ubuntu Serverか…と選択肢は非常に少ない。別にサーバーユースにはできるが、サーバー向けにはなっていないため、長期の安定運用には不安が残るし、実績の問題もある。

CentOSがダメだとは全く思っていないのだが、やはりFirewalldとNetwork Managerという新しいシステムの導入が厳しい。その設定について覚えなくてはならないからだ。

それになんだか動作がおかしい。設定したLUKSロングパスフレーズが、有効に働かないのだ。調べてみると

ディスク選択時に「データを暗号化」+LVMでPVを暗号化
Dracut内で復号できない。他システムでならば復号可能
ディスク選択時に「データを暗号化」+パーティションを暗号化
正しいはずのLUKSパスフレーズを受け付けない
ディスク選択時に暗号化を選択せず、パーティションを暗号化
正常に動作する

openSUSEでもLUKSが突然パスフレーズを受け付けなくなることがあり、正直「LUKSっていまいち」と感じている。もしくはcryptsetupがいまいちなのかもしれない。今回もなんども再起動し、SystemRescueCDと入れ替え、インストールし直し、と繰り返すこととなった。

かなり疲れてしまった。また、インストーラがかなり扱いにくく、自由にパーティションが切れない。予めパーティションを切っておき、ディスクを選択してから、その他を選択して進めるのがよさそうだ。ちなみに、GPT用パーティションを切っていないと警告される。openSUSEのインストーラはそこが不完全だったので嬉しいところ。

まずはdm-cryptの直接暗号化を使ったスーパーディスクが使えるかを試してみる。

$ <kbd>dd if=/dev/urandom of=keyfile bs=512 count=1</kbd>
$ <kbd>sudo cryptsetup –hash=sha512 –cipher=twofish-xts-plain –offset=0 –key-file=/home/aki/keyfile –key-size=512 open –type=plain /dev/sdb enc</kbd>
$ <kbd>sudo mkfs.ext4 /dev/mapper/enc</kbd>
$ <kbd>sudo mount /dev/mapper/enc /mnt</kbd>
$ <kbd>su -c ‘echo Hello, world &gt; /mnt/hello'</kbd>
$ <kbd>less /mnt/hello</kbd>

問題なし。次にZFS環境のセットアップに入る。


zfsonlinux.org/epel.html
を参考にするが、既にバージョンが進み、ファイル名は2015-02-06時点でepel-release-7-5.noarch.rpmとなっていた。

また、

Qiita
ではインストールしただけではダメというようにあるが、実際はインストールしただけで大丈夫だった。

以下はZFSの作成作業。

# <kbd>zfsmount.zsh</kbd> #各デバイスをループで暗号化。zfs_*という名前。オープンしていたものは事前にclose
# <kbd>zpool create ReasonZpool /dev/mapper/zfs_*</kbd> #Zpoolを作成
# #ここでプールをテスト。問題なし
# <kbd>zfs create ReasonZpool/world</kbd> #worldファイルシステムを作成。マウントポイントは<tt class="puredoc_pathname">/ReasonZpool/world</tt>
# <kbd>zfs get all ReasonZpool/world</kbd> #プロパティの確認
# <kbd>zfs set compress=gzip-9 ReasonZpool/world</kbd> #Gzip最高レベルでの圧縮。低速。
# <kbd>zfs set primarycache=metadata ReasonZpool/world</kbd> #キャッシュはメタデータのみ。メモリ消費量を削減。
# <kbd>zfs set acltype=posixacl ReasonZpool/world</kbd> #POSIX ACLを有効に
# <kbd>zfs set relatime=on ReasonZpool/world</kbd> #Relatime(atimeの記録を遅延させる)
# <kbd>#zfs set dedup=on ReasonZpool/world</kbd> #重複排除機能をON。メモリを大ぐらいするらしい。全域に使えるだけのメモリはない。1TBで32GBのメモリを必要とし、操作できないほどの状態になるとのことで今回は諦める。
# <kbd>zfs set setuid=off ReasonZpool/world</kbd> #nosuid+nodev

dedupの難しさについてはこんな記述がある。

しかし,この機能,ディスクは節約されるが,メモリをたくさん使うのだ.なぜかというと,メモリ上に DeDuplicationTable (DDT) と呼ばれるテーブルを準備することによって,重複を見つけているのである. 計算手順は省略するが,1TBを利用している場合に最大で約32GBのメモリを必要とし.メモリから溢れた分はディスク上のキャッシュに退避され,検索パフォーマンスが劇的に低下する.

著者が試したときにはあまりのメモリ不足のために,データセットの削除ができない程の状態となった.(1週間程度経っても完了せず,あきらめてプールごと破壊することにした)

恐らくはおとなしくHDDを増やしていくほうが現状マシだ。

さらに、usersグループを規格に沿って500に変更し、ユーザーのグループをusersに変更する。

あとはお約束。

  • ストレージを使う前にzfsmount.zshを実行する
  • ReasonZpool/worldを使う

ラップトップの選定と今昔

最新ラップトップ

先日、川崎に行った際に時間があったのでヨドバシカメラに行ってきた。早々に店員に捕まってしまったが、せっかくなので「まだ見ている段階」としつつ色々聞いてみた(知識は大いに不足だったが…

今回チェックして分かったのだが、私の要求を満たすラップトップはかなり難しい。e440の携行性を問題にしているのだが、どちらかというと増やす方向だ。e440はレコーディングを考えて用意して、携行性はむしろギリギリを狙った。だが、様々なイベントに持ち出すようになり、携行性が重要になってきている。e440を持っていくほどではないがラップトップはもちたいことが普通にあるのだ。

そこで将来的に(というか来年に)e440と共存する形でモバイルラップトップを追加し、e440を普段彼女(妻)に使わせる、ということを検討した。これは、低スペックのユニットを与えるのよりも簡単で効率的な方法ではないかと考えたのだ。

だが、多くのラップトップはその操作性と携行性において、一長一短の様相を呈していた。キーボードが打ちづらいか、一体型となったタッチパッドが極めて使いにくいか、そのどちらかがほとんどだ。そうでないものは、1.5kgを越えるか、10時間を切る駆動で携行性においてe440と大差ない。

奇妙なボタンのないタッチパッドは今や主流のようだ。なぜこんな使いにくいものになってしまったのか?と聞いたところ、「コストダウンのため」という回答だった。わからなくはないが、取り替えの効かないUIをコストダウンでこのように犠牲にするのは明らかに違うだろう。普通に考えればこれが使いやすいと考えているか、もしくはなんらかの犠牲になったと考えるべきだろう。

にしても、実に使いにくい。ThinkPad e440のマジックパッドの場合、マルチタッチによるスクロールが可能ということだが、それについてはかなり古いハードウェアでもLinuxならSynapticsを使用することができることが分かり、やはり何のメリットもない。クリック時に意図したボタンが押せず、しかもタッチパッドも反応する。かなり最悪に近い代物だと思う。

もはやタッチパッド嫌いでは通用しなくなってしまった。今やThinkPadもこのように使いにくいタッチパッドを採用する。一方、アイソレーションキーボードに関しては以前と比べて打ちやすいものが増えたと思う。しかし、昔のThinkPadのような明確なクリック感があって打ちやすいキーボードというのは、もはや失われてしまったようだ。今やラップトップのキーボードは曖昧なキータッチで打ちにくいものだ。私がスマホ用に使っているキーボードはパンタグラフ式でとても打ちやすい。

つまり、第一にUIで絞り込まれる。キーボードが打ちやすく、タッチパッドが嫌にならない、という条件で既にかなり絞られてしまう。私の印象では、hpと富士通がかなりよかったのだが、今回試した範囲だといまいちだった。

また、最近はイーサネットポートがないのも困る。有線は使えるが無線は使えないケースは多いと思うし、有線のメリットをないがしろにしすぎではないか。ちなみに、最近は有線ルーターも入手困難だ。

結局のところ、候補はPanasonic Let’s noteしか残らないようだ。Panasonicのラップトップは昔からIBM ThinkPad(Lenovo ThinPadでは断じてない)と並び信頼できるラップトップだった。特に軽量・頑丈・長時間駆動に関しては圧倒的なアドバンテージを持っていた。ただし、近年はマイレージ性能は富士通が検討し、その後NECが圧倒的な性能を見せてたために存在感が薄れていた。

だが、そのトラディショナルな構成は非常に安心感がある。本命はPanasonicの特徴であるシェルドライブとホイールパッドを搭載するSXだろろうと思ったのだが、実際はSXに関しては右下のほうにあるキーが非常に打ちづらく、”.”がとても打ちにくいし、かな打ちだと「ね」「る」「め」「ろ」と普通に打つキーがそこに配置されているのがとてもとてもしんどい。句読点もしょっちゅう使うだろうに、日本市場を考えた設計には全く見えない。

軽量でプレゼンにも便利なコンバーチブルタイプのMXも同様のキーになっている。感触がよかったのはLXで、e440が2.12kg, 7.7hという仕様なのに対して1.395kg/16-23hという仕様は非常に魅力的だ。ただし、バリエーションが少なく、Office+BDドライブモデルしか選べないため、30万円近いのが厳しい。

30万円というと、もうこの計画自体に現実味がない。

だが、帰ってからカタログを眺めていて気づいたのだが、Let’ Note RZ4という、745gの10.1inchモデルが存在するようだ。NEC LZの対抗的なモデルだろうか。プロセッサがIntelの新型、14nmの小型プロセッサであるCore Mを採用しており、これが大きなメリットなのだろう。1kgを切ると本当に軽く感じるので、745gというのは本当にメリットが大きいと思う。そしてみたところまともなキーだ。アイソレーションキーで、Let’s Noteでキー自体が(小さいとかいう理由以外で)打ちにくいと感じたことはないし、配置がイカれているということもないので、これはいいかもしれない。

128GB SSDのOfficeなしという最安価モデルCF-RZ4CDDJRで14万円程度。来年春くらいならこれが候補かもしれない。256GBモデルはOfficeなしモデルがなく、素直にSSDを週末秋葉原でゲットするのが正しい道だろう。1ファイルが10GBくらいということは普通にあるので、128GBの2OSでの運用は相当厳しい。sshfsなどに直接保存するのが現実的かというとなかなか厳しい。ストリーミング保存においてはUSB-HDDへの保存もためらわれるので悩ましいところだ。

だが、結局はこうして2台にわけることで携行性を求める場合は携行性に特化するのが素直なアプローチとなりそうだ。色々な意味でのパワーが必要な場合はe440を使えば良い。ただし、本来的な意味ではパワフルなラップトップがほしいのならば、Celeronのe440は明らかにパワー不足。だが実際のシーンを考えると、ストレージがそこそこ大きくてまともに動作し、そこそこ画面サイズが大きければ困らないとも言える。

おんぼろラップトップ

だが、いきなり14万円が用意できるはずもなく、そもそも仮に用意したとしても今e440を渡すわけにはいかない。

彼女の練習用ラップトップはやっぱり必要だ。そこで秋葉原にいった際にリユースショップに寄って見繕ってきた。

8800円ほど出せばそこそこ魅力のあるものが買えそうだった。30000円以下でかなり魅力的なものもあったが、3万円出すならばもうちょっと出してhpのラップトップを買ったほうがいいだろう。hp ProBook 450 G2/CTは41900円から。ただし光学ドライブと無線LANがオプションなのでちょっとしんどいかもしれないが。しかし今ならそれを入れても50000円はいかない。e440も47000円からとそんなものだ。HP14-r200だと35000円程度でも可能。

あくまで練習用と割りきって安いのを探すと、2800円と3800円を発見。2800円はCeleron Mに256MB RAMのFMV、3800円はPentium Mに512MB RAMのFMVとCeleron Mに756MB RAMのDynabookだ。いずれもOSなし。WindowsXP法人モデルの廃棄品だろう。

OSなしとあるが動作自体は確認しているのか?と聞くとYESとのことだった。256MB RAMは厳しすぎる。動かないわけではないが、普通には使えない。Dynabookに決めかけたが2ボタンであることに気がついてやめた。だが、結果的にはSynapticsを入れれば関係なかったし、FMVの中央ボタンはクリックすると上下スクロールというあまり使いやすいものではなかった。

ただし、それでもちょっとした利便性だったりするし、PCUは優れている。また、ディスプレイが1280×800というサイズなのでちょっと特殊ではあるがXGAと比べるとやはり使いやすい。ストレージは60GBに対して40GBと劣っていた。だが、60GB程度ならばあまり変わらないだろう。

しかし使ってみると、やはりこの世代のラップトップは良い。インターフェイスが充実していて、打鍵感もしっかりしているし、今からすればタッチパッドもずっと使いやすい。今と違い重く大きく熱く、そしてマイレージ性能も劣るが、それ以外については非常に優れている。蓋がロックされるようになることになっているのも魅力だろう。

近年は改良として成立していないぞと正直思う。使い心地の良いラップトップだ。インターフェイスの配置も良い。

ちなみに、モデルはFMV-C6310。天面はシルバーで、ボディはブルーグレイ、裏面はブラックとなかなか洒落ている。ただし、おそらく彼女は2800円のFMVのほうがいいと言っただろう…

これだったらルーターにしてもいいかもしれない。少なくともThinkPad G40よりはずっと性能的にも優れているし、あの凶悪な電気の消費もないだろう。USB5ポート、PS/2、光学ドライブ、イヤホン、マイク、PCカードx2、SDカードリーダー(ほぼ使えないか?)、プリンタ(使わない)、D-Sub15、シリアル(使わない)そして謎端子ととても充実している。

ちなみに、当然ながらバッテリーは死んでいる。

PCLinuxOS

いつも私が公言・提案しているように、販売時OSなどないほうがいいくらいで、古いPCでもLinuxによっていくらでも使いようがある、ということを実現していく。

512MBというRAMがネックだが、幸いにもPAEが有効なPentium Mだった。今ならば、Intel Core世代になれば面倒は少ないが、x86_64への移行が進み、32bit CPUだとそれなりに面倒な部分がある。だが、PAEが有効ならばまだ使える。

まずはBerry Linux 1.17で動作チェック。何も問題ない。どころか、マウス接続時用にタッチパッド無効ボタンがあるが、これがちゃんと働いてすごく使いやすい!これ、今のラップトップにもほしい。

Berry 1.19はメディアは正しく作成されたことを確認しているが、まともに動かない。まず試してみようと思ったのがPCLinuxOS LXDE 32bitだったのだが、これが非常に快適でよく動き、感動的だった。512MBでもなんとかなるものだ。極端な軽量を狙わなくても今のこのクラスの中古がちょっとした工夫で普通に動く。これは重要な情報だろう。

一応、EnlightenmentとiceWMも入れてみた。iceWMがWindows XPそっくりな見た目にカスタマイズされている。e19はしっかり設定されていて素敵だが、困ったことにシステムトレイにアイコンが出ない。

ディスプレイ解像度に関しては特殊であるせいかPCLOSでは1024×800と認識されてしまうので手動設定が必要。GUI上で可能。

おおまかな手順としては

  1. ライブ起動。キーボードレイアウトはJapaneseにして起動したほうがいい
  2. インストーラ起動
  3. インストーラに従ってインストール(ただし、私は/をReiserFS、/homeをXFSとした)
  4. ディスプレイを設定
  5. Synapticで一覧を更新、アップグレード(su -c ‘apt-get update && apt-get upgrade’でもいい)
  6. Synapticのソースを日本国内のものとし、かつspecialを加える
  7. 一覧を更新
  8. addlocaleを使って日本語をインストール(Localization Manager。ウィザードで進む)
  9. Fcitx-Mozcをインストール。FcitxとMozcは自動インストールされる。ちなみにlibkkcも利用可能
  10. 入力メソッドの選択、を使ってFcitxをセレクト
  11. fonts-ttf-japanese, fonts-ttf-japanese-extra, fonts-ttf-japanese-vlgothincをインストール
  12. ~/.config/fontconfig/fonts.confを設定
  13. FirefoxにJapanese Language Packをインストール(Firefox-jaをインストールしてもダメだった)
  14. gksu, sudoをインストール
  15. su -c ‘usermod -a -G wheel user; visudo’ #Wheelグループのsudoを有効に
  16. Synapticsの設定
  17. Configuration your systemからPolicyKitの設定でユーザーのパスワードを聞くようにする
  18. Zsh, Rubyなど必要なものをインストール
  19. Copy.binは公式からインストール
  20. .zshrcの設定
  21. EnlightenmentとiceWMのインストール

以下参考

<?xml version="1.0" ?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="antialias" mode="assign">
<bool>true</bool>
</edit>
<edit name="rgba" mode="assign">
<const>rgb</const>
</edit>
<edit mode="assign" name="lcdfilter">
<const>lcddefault</const>
</edit>
<edit mode="assign" name="hintstyle">
<const>hintfull</const>
</edit>
</match>

<alias>
<family>sans-serif</family>
<prefer>
<family>M+1VM+IPAG circle</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>IPAMonaPMincho</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Ume Gothic</family>
</prefer>
</alias>
</fontconfig>

Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
Option "VertEdgeScroll" "1"
Option "TapButton1" "1"
Option "VertTwoFingerScroll" "on"
Option "HorizEdgeScroll" "on"
Option "CircularScrolling" "on"
Option "CircScrollTrigger" "8"
Option "EmulateTwoFingerMinZ" "40"
Option "EmulateTwoFingerMinW" "8"
Option "CoastingSpeed" "0"
Option "FingerLow" "35"
Option "FingerHigh" "40"
Option "PalmDetect" "1"
Option "PalmMinWidth=" "4"
Option "PalmMinZ" "25"
EndSection

ちなみに、Synapticsは、パームレストに圧力がかかっていると(タイプ中に)タッチパッドを向こうにする、二本指でなぞることでスクロールする、エッジをなぞることでスクロールする、角からはじめて回転させることでスクロールする、という機能を有効にしている。このような古いラップトップでもこの機能を使うことができ、最新型をWindowsで使っているよりも便利で快適だ。