ラベル Hardware の投稿を表示しています。 すべての投稿を表示
ラベル Hardware の投稿を表示しています。 すべての投稿を表示

2021年11月3日水曜日

Radeon RX 6800 XT の OpenCL を有効化する (スクリプト化編)

Radeon RX 6800 XT の OpenCL を有効化する に記述したレジストリ操作について、毎回手作業で実施することが面倒なため Python スクリプトに起こした。

#! python

import os
import winreg
 
base_path = r"C:\Windows\System32\DriverStore\FileRepository"


def detect_amdocl():
    amdocl_list = []
    for curDir, dirs, files in os.walk(base_path):
        for file in files:
            if not file.lower() == "amdocl64.dll":
                continue
            amdocl_fullpath = os.path.join(curDir, file)
            amdocl_timestamp = os.stat(amdocl_fullpath).st_mtime
        
            amdocl_list.append({'path': amdocl_fullpath, 'ts': amdocl_timestamp})

    if len(amdocl_list) == 0:
        return None

    amdocl_list = sorted(amdocl_list, key=lambda e:e['ts'])
    return amdocl_list[-1]['path']


def remove_old_values(regkey, latest_amdocl=None):
    i = 0
    while True:
        value_name = None
        try:
            value_name = winreg.EnumValue(regkey, i)[0]
            i += 1
        except OSError:
            # Will be here when the enumeration is done.
            break

        if not value_name.lower().endswith("amdocl64.dll"):
            continue

        if latest_amdocl:
            if value_name.lower() == latest_amdocl.lower():
                print("latest value: %s" % value_name)
                continue

        print("delete value: %s" % value_name)
        try:
            winreg.DeleteValue(regkey, value_name)
        except Exception as e:
            print(e)


if __name__ == "__main__":
    amdocl_path = detect_amdocl()
    if not amdocl_path:
	    raise Exception("Could not determine path of amdocl64.dll")

    reg = winreg.ConnectRegistry(None, winreg.HKEY_LOCAL_MACHINE, )
    regkey = winreg.OpenKey(reg, r"SOFTWARE\Khronos\OpenCL\Vendors",
            0, winreg.KEY_ALL_ACCESS)

    # Delete old values.
    remove_old_values(regkey, amdocl_path)

    # Add a new key.
    winreg.SetValueEx(regkey, amdocl_path, 0, winreg.REG_DWORD, 0x00000000)

    winreg.CloseKey(reg)

    print("done")
    

PowerShell での実装がより理想的かもしれないが。今度 cxFreeze による EXE バイナリ化などを試してみようと思う。


2021年4月10日土曜日

高リフレッシュレート対応4K液晶ディスプレイ ASUS ROG Strix XG27UQ を購入した

2022/6 追記

本記事は 144Hz 4K ディスプレイの選択肢がまだほとんどなかった頃に XG27UQ を購入した際の内容です。

どうしても DisplayPort 入力が2ポート欲しい、 4K 144Hz 仕様としては割安なディスプレイが欲しいという理由であれば XQ27UQ を候補になると思いますが、そうれでなければ、現在では LG 27GP850 をはじめ複数の HDMI2.1 対応 4K ディスプレイが流通しています。これから検討される方は他の 4K 144Hz ディスプレイも確認されることをお勧めします。

 ~~


高リフレッシュレートなディスプレイに買い換えようと思って以来半年近くたち、ようやく本命のディスプレイが手元に届きました。



今回のXG27UQは2021年2月に国内向けに発表されたモデルで、これまで秋葉原などでお店を回っても実物を見かけることはありませんでした。発表当初にすぐ予約された方は2月中に入手できたようですが、4月に入ってようやく実物が届いたぐらいで、現時点で欲しくても実物を見られる方は限られていると思います。このモデルは実売で10万円近くしますし、「失敗したくないので少しでも多く情報が欲しい」という方もいらっしゃるかと思います。このため、所感をまとめておくことにしました。

調べてみると、メーカーからテスト機を借り受けたブロガー等がすでにレビュー記事を投稿されていますし、そういった方でカバーされている分については、そういった記事にお任せすることにしました。私の記事では、他の記事ではあまり触れられていない部分について触れていこうと思います。


ファースト・インプレッション編

マニュアル冊子が付属していない

本製品は付属品として製品保証についての冊子、1枚っきりのクイックスタートガイド、およびキャリブレーションレポートが付属していますが、マニュアルは同梱されていません。スタンド部分を外す方法がわからずに困っていたところ、 ASUS のサイトにはマニュアルが PDF で存在していることがわかりました。

https://dlcdnets.asus.com/pub/ASUS/LCD%20Monitors/XG27UQ/XG27UQ_Japanese.pdf

マニュアル冊子なんて一度使い始めたらほとんど見返すこともないのは事実ですし、意図的に省略されているのでしょう。とはいえ、 10 万円近いモニタですし、今回の製品はマニュアルを見ないとよく判らない機能やギミックも積まれているモデルです。紙媒体でマニュアルが付属されていたり、もしくは少なくともURLや検索キーワード、QRコード等でもよいので、マニュアルへの案内があると良かったなと思いました。


日常の利用編

複数ソースの切り替えが面倒。ファームウェア更新による改善を期待

XG27UQ は DisplayPort 2入力、 HDMI 2入力で合計4入力利用できる点がひとつの特長です。ディスプレイです。しかし、ディスプレイの入力を切り替えるためには画面裏側右手の赤いスティックを使い、クリック→下→下→下→右と操作し、その上で入力ソースをスティックで選択する流れになっており、煩雑です。

赤いスティックの下にはゲーミングモードを設定する画面へのショートカットがふたつあります。これらのボタンで、GamePlus設定画面、およびGameVisual設定画面への直接遷移できるようになっていますが、たぶん、私は、どちらもほとんど押す機会がないでしょう。これらのボタンから入力ソースの切り替え画面へ遷移できるような設定が可能となるファームウェアアップデートに期待したいです。複数の入力ソースを接続する方の多くは、同じような感想をお持ちになるのではないでしょうか。


USB3.0ハブ機能は、ディスプレイの主電源と連動/非連動が選べる

XG27UQ は USB3.0 の2ポートUSBハブ機能を搭載しています。私の場合、ダウンストリームには、ディスプレイの付近にあるデバイスとして、Webカメラとして利用している一眼デジタルカメラ(Canon EOS Kiss X6i)とアイトラッカー(Tobii Eye Tracker 5)を接続しています。ディスプレイ自体にこの機能を求めてはいないのですが、セットアップがすっきりした点についてはメリットを感じました。


このUSBハブ機能はディスプレイ機能と独立して動きますが、ディスプレイの主電源がオンの状態でのみUSBハブが動作する連動設定と、ディスプレイの主電源の状態にかかわらず外部電源が供給されていればUSBハブが動作する非連動設定のどちらかを選ぶことができます。

工場出荷時は主電源と連動する設定になっていますが、私の場合で常時通電のデスクトップPCとの組み合わせで利用するため、USBハブが常時動作する設定に切り替えました。


ディスプレイアームとの組み合わせ利用について

XG27UQ はディスプレイアームへの取り付けに対応しています。ただし、アームの取り付け時に標準スタンドの取り外し方がすぐに判からず、マニュアルを見ながら試行錯誤したほか、この機種特有の考慮点があるので、ここで紹介したいと思います。



標準スタンドの取り外し方

この作業には、化粧パーツの取り外しにマイナスドライバー、M4ネジを付け外しするためのプラスドライバーが必要です。

工場出荷時にはスタンド用の足が取り付けられた状態になっています。足のまわりにある半リング形状の化粧パーツを取り外します。スタンドの裏を覗き込むとマイナスドライバーを差し込める隙間があるので、ここにマイナスドライバーを差し込んで化粧パーツを引き上げます。

パーツが浮いてきたら、半リング形状の化粧パーツ2点を、ディスプレイ本体から平行に離すように取り外します。取り外し時に多少力をかける必要がありますが、樹脂パーツ自体は十分な強度があるので、丁寧に外せば問題ありません。この作業を終えると、VESA規格のM4ネジが4本露出します。

足のまわりに見えてきたVESA規格のM4ネジを4本はずすと、標準スタンド用の足がはずれて、ディスプレイアームを取り付け可能な状態となります。

半リング形状の化粧パーツは取り外したスタンドに取り付けられるので、保管時にはスタンドにはめて保管しておくとよいでしょう。


VESAマウントのネジ穴は25mm の窪みの中にある

ディスプレイアームの種類によっては、カメラのクイックシューのように、あらかじめディスプレイ側に小さな部品を取り付けておいて、設置済みのディスプレイアームに固定できるような機能をもった物があります。このような場合VESA標準のネジ穴のまわりに十分なクリアランスが必要です。また、スタンドを非純正品に交換した場合にも注意が必要なポイントでしょう。

今回は colebrook bosson saunders 製の Wishbone ディスプレイアームに取り付けるつもりでいたので、この部分は気になっていましたが、結果的には十分なクリアランスがあり、Wishbone アームに対して、問題なく載せたり外したりできることが確認できました。 


ディスプレイアーム利用時、ビデオ用ケーブルを完全に隠せない

XG27UQ は下側から DisplayPort/HDMI などのケーブルを差し込みます。標準スタンドを利用する場合にはあまり気にならないでしょうが、ディスプレイアームに載せる場合は、ビデオ用のケーブルが正面から見えてしまう可能性があります。

がんばって隠すことも不可能ではないのですが XG27UQ は DisplayPort 1.4 に対応した 4K 144Hz 対応のディスプレイで、これを利用する場合には DisplayPort 1.4 に対応した比較的太いケーブルを使用することになるのではないでしょうか。

しかし、上向きに刺さった太いケーブルをディスプレイの裏側で片付けるだけの十分なスペースがないため、正面から見たときには、ビデオ用のケーブルはディスプレイの下側に少し見えるぐらいのセッティングに落ち着くかと思います。もちろん気合いで見えないように隠してもよいでしょうが、アームを動かしたときにケーブルやコネクタに負担がかからないようにある程度の遊びも必要ですし、この点は諦めることにしました。


その他編

当然ながら 4K 144Hz には高品質なケーブルが必要

これまで、2012年に購入した 7m の DisplayPort 1.2ケーブルでPCとディスプレイを接続し、4K 60fpsで動作させていました。このケーブルを利用していたのは諸事情により「手元で余っていた」というのが最大の理由です。(今でも未使用の新品が1本手元にあります...)

このケーブルでも 4K 144Hz はいちおう映ったのですが、不定期に画面がブラックアウトする現象が発生しました。恐らくケーブルの品質的に映像信号が時々乱れているのだと想像できます。

FullHD 144Hz に対して 4K 144Hz は時間あたりに表示するピクセル数が4倍になります。このためビデオケーブルの中を流れる信号の速度が上がっています。 Wikipedia の DisplayPort ページで調べてみたところ、 4K 144Hz は DisplayPort 1.4 仕様からの仕様で、ケーブルの中を 25.92Gbps の信号が流れているようです。 1.2 の時代は 17.28Gbps だったので、データの転送量が1.5倍になっていて、恐らくそれだけDisplayPortケーブル内のビットクロックも上がっているようです。

ディスプレイに付属する DisplayPort 1.4 ケーブルを利用することも考えましたが、手元では昇降デスクやディスプレイアームを利用しており、 3m 程度のケーブル長を必要としていたので、 3m の DisplayPort 1.4 対応ケーブルを購入して交換しました。

また、ビデオカードの DisplayPort コネクタの片方が緩いようで、本体への衝撃ですぐブラックアウトしてしまう事があったので、もう片方の DisplayPort コネクタに装着して安定を確認しました(ビデオカードのメーカー保証で交換依頼をしてもいいかもしれませんが、手間を考えるとこの対応でいいかなぁと思っています)。


MacBook Pro 16インチ (2019) から HDMI で 4K 60Hz で安定出力できている

MacBook Pro から 4K 解像度で出力する際になかなか安定しないイメージを持っていましたが、XG27UQ では HDMI ケーブルを接続するだけで 4K 60Hz で出力された点が拍子抜けでした。ここ一週間ほど、ノートラブルで動作しています。

LG 社のディスプレイでは 4K 60Hz を受け付けるためには追加の設定(DeepColor)が必要だったりして、この設定を行うと映る時と映らない時があるなどしてストレスを感じたので DisplayPort 接続による 4K 60Hz もしくは HDMI 接続による 4K 60Hz を使い分けていました。

不都合が感じたら DisplayPort での 4K 60Hz に切り替えることを考えるでしょうが、実用上問題を感じないうちは、試しに HDMI の 4K 60Hz で使ってみようかと思います。


まとめ

XG27UQ は、4系統入力の4K解像度・高リフレッシュレートディスプレイとしては期待通りの仕上がりだと感じています。

一点だけ不便な点を挙げるとすれば、入力系統の切り替えに必要な操作数が多いことです。この部分は4系統入力を魅力に感じて購入するユーザーにとっては非常に重要なポイントです。もしエンドユーザ側でファームウェアアップデートが可能な仕組みが用意されているのなら、後からでも改善できる点ですから、ASUSには是非検討を御願いしたいところです。

これまで液晶ディスプレイといえばシャープ、LGなど自社で液晶パネル技術を製造できるメーカーの製品を利用していました。今回のASUS ROG XG27UQは実売価格で10万円近くするモデルで、下手な4Kディスプレイの2倍以上の価格です。ASUS自体は液晶パネルを作れるわけではないので買ってきている(というか製品規格だけで、他メーカーに仕様を指定して生産させている可能性も高い)メーカーですので、正直に言えば、そういったメーカーの製品を選定すること自体に抵抗もありました。最初の一週間から「買わなければ良かった」みたいな悪い印象にもならず、ホッとしています。

To Be Continued

フォトトランジスタを使って応答速度などをの特性を測定しているため、結果がまとまったら続編としてまとめたいと思います。

2021年4月8日木曜日

Radeon RX 6800 XT の OpenCL を有効化する

Radeon RX 6800 XT で OpenCL プログラムを動かそうとすると、OpenCL プラットフォームとして同 GPU が列挙されてこなかったので、調べたら、レジストリをちょっと弄る必要があるっぽい。どうやら OpenCL プログラムはこのキーから OpenCL プラットフォームの実装を見つけてるようだ。


Radeon のドライバをインストールもしくはアップデートしたタイミングで、以下のようなディレクトリ、ファイルができる。

C:\Windows\System32\DriverStore\FileRepository\*.inf_amd64_*\amdocl64.dll


amdocl64.dll のフルパスが確認できたら、 regedit.exe を起動して、 コンピューター\HKEY_LOCAL_MACHINES\SOFTWARE\Khronos\OpenCL\vendors に、以下のキーを作成する。

  • 名前: 上記 amdocl64.dll のフルパス
  • 種類: REG_DWORD
  • データ: 0x00000000 (0)
このキーを作成した後に OpenCL を利用するプログラムを実行すると、 Radeon GPU が OpenCL デバイスとして認識される。もし認識されない場合は amdocl64.dll へのパスがおかしいとか、過去のドライババージョンの amdocl64.dll へのパスになっていないかを確認するとよさそうだ。

手元で Radeon のドライバを更新するたびにコレでひっかかってる気がするが、どうしてドライバのインストール時に自動的にやってくれないのかねえ。何も見ずに何すればいいか思い出せるほどの頻度でやることではないが単純作業ではあるので、いっそのことツールなど書いて自動化すると幸せかもしれない。。。

2021年3月14日日曜日

ゲーミングディスプレイは本当に役に立つのか?

2021年にもなって、久々にFPSとしてApex Legendsをプレイしている。ヘタクソなのはそうなのだが、恐らくこの半年間でPS4 Pro/PC版あわせて700~800時間はプレイしているはずだ。久々にFPSをプレイしているので、ゲーミングディスプレイを試して、比較してみることにした。

ゲーミングディスプレイに対する謳い文句への懐疑感


これまで LG 27UD55-BK と LG 27UL850-W (どちらも 27インチ4K液晶)をデュアルディスプレイにしていて、このうち、 2020 年に購入した 27UL850-W をゲームプレイに使用していた。このディスプレイはどちらかと言えば発色などがキレイなことがウリだ。

もちろんリフレッシュレート60Hzの液晶ディスプレイが十分だとは思っていなかった。もともと私は初めてのFPSといえば液晶ディスプレイが普及する前である1990年代の初代DOOMだし、また2000年前後は三菱のダイアモンドトロン管ディスプレイ RD17V で、100Hz 程度のリフレッシュレートでFPSを遊んでいた経験があるので、液晶ディスプレイかつ60Hzが大きな制約であることは理解していた。敢えていえば液晶になる前なら100Hz程度は当たり前だった。また最近のトレンド Oculus Rift などのヘッドセットを見ていても、60Hz では不足だが 90Hz もあれば脳を騙せることが知られているので、60Hzで足りなくても、100Hzぐらいの頻度で更新されれば十分だろうと思っている。

しかし、周りのプレイヤーからは「60Hzよりも高リフレッシュレートのほうがよい」だけで終わらず、「敵レジェンドが止まって見える」「ディスプレイを変えるだけでキル数が増える」などという主張をされるし、販促ビデオでは相手より素早く反応できると謳われている。果たして、そこまでの効果があるのだろうかと、懐疑的に思っていた。

買おうと決意したものの、欲しいものの在庫がない


とはいえ、そろそろゲームに適したモニタが欲しくなってきた。コロナ禍でほとんど外出することもなく、スノーボードは2シーズン連続でスルーしており、月々の大きな支出としては家賃とメシ代(自炊するようになったため2年前の1/4〜3/1ぐらい)ぐらいなのだ。この半年で FPS を500時間以上プレイしているのだから、多少投資してもいいのではないだろうかと。

実は 11 月頃にゲーミングディスプレイの購入を決意したが思ったようなモデルがなく、2月に ASUS が発表した XG27UQ (4K 144Hz)をバックオーダーしている状態である。手元の古いLG 27UB55(27インチ 4K)で何十秒も残像が出る不具合が出ているので、買い換えるなら、同じ利用感で仕事にも使えるゲーミングディスプレイを、と思い、このモデルにたどり付いた。

しかし、昨今の自動車をはじめとする部品不足問題のためか中々納期が確定せず、少なくとも3月中にも手に入らないことがほぼ確定的になった。この機種に限らず、ある程度スペックや型番にこだわりを持って液晶ディスプレイを購入しようすれば、流通量の少なさにすぐ気づくだろう。正直なところ現時点で表示されている納品時期が守られるのかも判らない。

とりあえず、繋ぎのつもりで買ってみた


今回は MSI Optix G241 を購入してみた。スペックを妥協して市中在庫から選べば3万円でお釣りがくる価格感だ。半年近く「ゲーミングディスプレイの在庫がネェ……」と考える日々が続いていたことを考えたら、さっさと買ってしまったほうが精神的に良かったのではないかとさえ思える。

中途半端なものを買いたくなかった最大の理由は、設置場所の都合だ。27インチ×2+MacBook Proでギリギリだったが、やむを得ず、なんとか3枚目のディスプレイを追加した。ディスプレイアームに載せてあるので利用シーンによってある程度片付けたり引っ張り出したりはできる状態にある。

とりあえずの印象


早速 Optix G241 を Windows PC に繋げてみると、マウスカーソルの動きがかなり滑らかになった(というか見える残像が増えた)のはすぐわかり、印象的だった。ウインドウのドラッグなども全体的に滑らかになっているのもわかる。

Forza Horizon 4 を動かしてみると 60Hz と 144Hz では高速道路を高速巡航しているときに横を流れていく鉄柱の滑らかさが印象的だった。

過去に多少試したことがある Aim Lab を改めて試してみると、これまで 30,000 点ちょっとの印象だったテストで 50,000 点台が出てきて驚いた。ただ、ディスプレイの変更だけでなく自分のプレイスキルの向上もあると思うので、そこは考慮しないといけない(特に最近は Apex Legends の仕様アップデートに伴いウイングマンでの練習をはじめている)。


ゲーミングディスプレイによるメリットはこの時点である程度体感できていたが、もう少し定量的に比較してみることにした。

比較環境のセットアップ


今回は GPU (Radeon RX 6800 XT)から、これまで使っていた 27UL850-W (60Hz 4K 5ms) と今回の Optix G241 (144Hz FullHD 1ms) を DisplayPort で同時接続し、 Windows の機能で両方のモニタに映像をミラーする。なお、 Windows の機能で画面をミラーした場合に遅延が増加するかどうかは判っていなくて、この部分を定量的に測定する方法を持っていないので、この観点については無視する。

フレッシュレートは各ディスプレイの最大値が適用されているので、従来のディスプレイでは 60Hz 、ゲーミングディスプレイでは 144Hz で表示される状況となる。これで、どちらを見るかだけで利用できるディスプレイをスイッチできる環境ができた。

定量的に比較できるように、引き続き Aim Lab を使って、プレイ中のディスプレイの表示状況をデジタルカメラのビデオ撮影機能で 60FPS 撮影し比較することにした。ディスプレイの前に三脚を立てて、富士フィルムのX-T3カメラで両方のディスプレイを撮影できるようにした。ひとつのカメラのセンサで両方のディスプレイの出力映像を記録することで、1コマ単位で見比べて比較できる。

もちろん、本来 60Hz と 144Hz の違いを検証するのなら 60FPS では不十分だ。少なくとも 144Hz の倍の 288Hz(FPS) 前後のフレームレートで撮影したほうがいいだろうが、私はそこまでの機材は持っていないから、手持ちの機材でできる範囲での検証とする。


写真左側が LG 27UL850 、右側が MSI Optix G241だ。

なお、正面からの撮影ではないとはいえ、この写真で見ればわかるとおり、発色については Optix G241 に対して 27UL850 のほうが圧倒的にキレイだ。手元で試している限り、 27UL850 と比較できる環境で見れば、 Optix G241 は全体的に色褪せて見える(色温度などの設定でカバーできる範囲ではない)。これらは両方とも IPS パネルだ。


応答速度を比べてみる


とりあえず動画撮影をしながら、両方のモニタで Aim Lab を比較してみたところ、今回購入した G241 のほうがボヤケが明らかに少ないことがわかった。このため目が疲れにくい印象を受けた。これは動画からフレームを切り出してみても判る。


この写真では下にあったターゲットをエイムしてから上にあるターゲットに移ろうとしているが、その際に27UL850ではひとつ前のフレームが残像として映っている。実物では、この残像がボヤけに見えている。Optix G241では、この残像感がとても抑えられている。60Hz 5msのスペックを謳うディスプレイの残像は、デジタルカメラを用いて60フレーム/秒で撮影したレベルでも十分に記録できるほどだった。

表示遅延を比べてみる


録画を確認するとOptix G241のほうが常に若干新しいフレームが描画されていると感じられる。実際には144Hzのリフレッシュレートで更新されていることもあり、操作に対してダイレクトにフィードバックがかかるので、エイム操作がしやすくなる感覚はあった。

動画の各フレームを確認していくと、以下のフレームが見つかった。28UL850では過去のフレームに対して新しいフレームが表示されようとしており、Optix G241ではより新しいフレームが表示されている。


どちらのディスプレイでも、いちばん右のターゲットにはこれから表示される武器の陰がかぶっているが、このかぶり方が非常に似ているのは面白いポイントだと思う。144Hzのほうが明らかにより新しいフレームが表示されている。しかし、60Hzモニタは更新頻度が低いとはいえ、特別に遅延が大きいわけではないようだ。

遅延がどれぐらいあるかはカウントダウンの瞬間などを比較するとわかりやすい。5,4,3...とカウントダウンがなされる時の60Hzディスプレイでの描画の遅れは、表示開始までの遅延は1フレーム(16.6ms)前後、表示が安定するまで2フレーム(32.2ms)未満だった。



1/144秒毎に更新されているディスプレイとの比較として考えると、1/60秒毎にしか更新されておらず、画面の残像感が1フレーム分残る液晶パネルであることを考慮すれば、妥当な挙動だ。32.2msはデジタルカメラの撮影機能が60FPSであることから想定した最悪値だ。実際の遅延はこれより少ないだろう。

ゲーミングディスプレイの宣伝文句は本当か?


ゲーミングディスプレイの宣伝文句として「フレームレートが高いほど、相手がより早く見える」といった表現がされていたり、それをイメージさせるデモ映像がある。

今回の比較を見る限り、あの宣伝文句はかなり大げさな表現だが、一般的な 60Hz ディスプレイと比べれば確かに10~20ミリ秒ほど早く画面上に敵が映り込んだり、より新しい位置に敵が見えたりするのは事実だろう。

とはいえ、10ミリ秒を切ってくると現在のインターネットにおけるピア間の遅延のほうが大きくなりうるし、それをごまかすための補間や予測などもされているわけなので、まあ、そうね、というレベル感で捉えている。

実際のゲームだとどうなる?


同じように Apex Legends でダミー撃ちする映像をフレーム単位で見てみたが、複雑なApex Legendsの画面は144Hzを60FPSで録画しても、複数フレームが同時に映りこんで逆に破綻した画像になってしまった。体感と異なり144Hzの画像のほうが見づらく、紹介に紹介するような内容にならなかったので、ここでは省略する。

感覚的には、マウス操作による視線移動が発生した場合にダミーや周りの景色がはっきり見えることにより、プレイしやすくなると感じた。

ゲーミングディスプレイはゲーミングディスプレイだった


今回、はじめて60Hzを越えるリフレッシュレートに対応した液晶ディスプレイを買ってみたが、ゲーム画面が見やすくなるなどのメリットが確認できた。特に、 FPS のように視点移動によって画面の表示が大きく変化するようなゲームでは、残像感が大幅に減少するため、疲れにくくなりそうだ。

まだ「ゲーミングディスプレイにするだけでキル数が伸びる」かどうかはわかっていないが、ぼちぼち実践で試してみようと思う。

2018年12月4日火曜日

AMD GPUによるディープラーニング環境の構築

こんにちわ。さくらインターネット 高火力コンピューティングの雑用担当 @hasegaw です。このエントリはさくらインターネット Advent Calendar 2018 4日目のエントリです。なお、前日のエントリは UIT#5 で登壇してきました + 資料への補足 でした。


新しい Radeon GPU が登場

1ヶ月ほど前になりますが、2018年11月6日に、AMDが新しいGPU 「Radeon Instict MI60」を発表しました。4096のストリームプロセッサー、1TB/sの高帯域幅な32GB HBM2メモリを搭載し、PCIe 4.0 16レーンに対応したGPUです。また、ストリームプロセッサーが 3840 に変更された Radeon Instict MI50 というモデルを紹介されています。

AMDが7nm提供開始、Vega「Radeon Instinct MI60」と最大64コアのRomeこと新「EPYC」を発表
http://ascii.jp/elem/000/001/768/1768981/


ディープラーニングと Radeon GPU

Radeon GPUといえば、2018年はマイニングで話題になったりもしましたが、OpenCLによる計算用途にも利用できます。また、最近では ROCm と呼ばれるソフトウェア群によってディープラーニング目的でも使えるようになりました。

本当に動くの?

Radeon でディープラーニングってきちんと動くの?ちょっと試してみないと判らないな……と思われたりするでしょうか?

私は、高火力コンピューティングの仕事をしつつ、サイドプロジェクトで GPU を使ったりもするので、そのときはデータセンターをおいたマシンを使ったりもするのですが、かといって高価な Tesla を常に浪費するのも心が痛むので、最近は 10分の1のコストで済む Radeon で事足りる作業なら Radeon GPU を使ってみています。にわか機械学習マンとしては、現状 Radeon GPU で困ったことはありません。

最近は TensorFlow もアップストリームに追従するかたちで ROCm 対応版が作られており、動かしてみても、だいたいの場合は問題なく動くようです。また、 Radeon Instict シリーズに一気にいかなくとも、秋葉原で手に入る Radeon シリーズでとりあえずの味見をすることも可能です。

「本当に自分が持っているワークロードが動くの?」と気になる方は、 Pegara 社の GPU EATER をお試しになられてはいかがでしょうか。

GPU EATER
https://www.gpueater.com/

なんと1時間あたり1ドル未満で、RadeonシリーズのGPUサーバーを試せます。また、ログインは事前に用意したSSH公開鍵に対応する秘密鍵でSSHするだけ。利用開始も簡単で、最初から ROCm フレームワークや TensorFlow サンプルなども入っています。

root@C-2b457c0e-0884-4f80-94fc-4bbeec7ecb4c-685:~/deep_learning_yolo_v3# python3 yolo.py  image.jpg
Using TensorFlow backend.
2018-10-10 04:56:03.761749: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1519] Found device 0 with properties:
name: Device 687f
AMDGPU ISA: gfx900
memoryClockRate (GHz) 1.622
pciBusID 0000:03:00.0
Total memory: 7.98GiB
Free memory: 7.73GiB
2018-10-10 04:56:03.761786: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1630] Adding visible gpu devices: 0
2018-10-10 04:56:03.761820: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1039] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-10-10 04:56:03.761829: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1045]      0
2018-10-10 04:56:03.761848: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1058] 0:   N
2018-10-10 04:56:03.761907: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1178] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7524 MB memory) -> physical GPU (device: 0, name: Device 687f, pci bus id: 0000:03:00.0)
model_data/yolo.h5 model, anchors, and classes loaded.
(416, 416, 3)
Found 5 boxes for img
person 0.94 (143, 281) (216, 495)
person 0.97 (112, 17) (207, 331)
person 0.99 (239, 297) (317, 514)
person 0.99 (253, 98) (319, 364)
person 1.00 (38, 165) (102, 436)
20.274007220985368
Output => image.jpg.out.jpg


ROCm 環境のインストールって難しくないの? → 思ったより簡単でした

手元に実際の Radeon GPU を用意し、環境を構築するにはどれぐらいの苦労があるでしょうか?実際  Ubuntu 16.04 ベースで試してみたときは、思ったほど難しくはありませんでした。 https://github.com/hasegaw/rocm-tensorflow-ansible/ に、私が環境作成に使用している Ansible role から抜粋したものをおいておきますので、必要に応じて加工して利用してください。何をしているかというと

ROCM 環境の構築)

  • カーネルの更新
  • apt に ROCm レポジトリを追加
  • ROCm 関連パッケージをインストール。カーネルモジュールは DKMS で設定されます
  • /etc/profile.d/ に設定ファイルを展開
  • 必要に応じてユーザ(既存/今後の作成時のデフォルト)のグループ設定を変更
TensorFlow のインストール)
  • virtualenv をインストール
  • virtualenv 上に tensorflow-rocm をインストール
といった感じです。 ROCm は repo.radeon.com からのパッケージを拾えば動きますし、 TensorFlow も AMD 社がポートしたバージョンを PyPI に適宜パブリッシュしてくれているので、 pip install するだけの時代が来ているのです。


利用感はどう?

どちらかといえば、パフォーマンスの面よりも、秋葉原などの店頭でカジュアルに手に入る Radeon Vega 64 は 8GB メモリモデルぐらいしか市場で見かけておらず、 Radeon Vega Frontier Edition (12GB) がほぼ市場から消えている状況で利用できるメモリ量が少ない点が、がつがつワークロードを回そうと思うと、ちょっと気になるかもしれません。

ワークロードによるので一概に言えないのですが、私が試した範囲では Radeon Vega 64 で NVIDIA TITAN X の8割から同等程度のパフォーマンスが得られていました。 GDDR5 搭載の NVIDIA GPU が HBM 搭載の Radeon Vega 64 に対して優位なのは NVIDIA すごいなーと思いますし、 Radeon 上でのチューニングはこれからなのかな、という感じがします。

現状の tensorflow-rocm は、CUDAバージョンのカーネルをコンバートして使っているようなので、このあたりの最適化が進めばさらに性能が伸びる余地もありそうです。例えば  GitHub 上のアクティビティを眺めていると、和算+活性の "Fusion" カーネルの実装なども最近行われていました。どんどんアップデートされているので、今後が楽しみです。


まとめ

AMD Radeon シリーズでのディープラーニングもそろそろ実用段階に入ってきたのではないか、という感じがしています。

ただ、ディープラーニング用途で Radeon 系 GPU をすでに持っている方はほとんどいないでしょう。そんな時でも、ご紹介したとおり、 Pegara 社が非常にお安い価格で Radeon GPU を利用できる GPU EATER を提供されていますので、興味が湧いたら、こちらのサービスを試してみてはいかがでしょうか。

2016年10月16日日曜日

PYNQを買ったので遊んでいる(Project Inq)

久々にFPGAいじりをしています。

今回入手してしまったのはPYNQ。Xilinx Zynq7020シリーズを搭載した評価ボードで、あらかじめ用意されたイメージをSDカードに書き込んであげればJupiterからWebブラウザ経由でもいくらか操作を試せるというお手軽さがウリ。



届いたPYNQのパッケージ

秋葉原の職場に送ってもらったので、受け取ったら早々と部品やでヒートシンクと熱伝導シーツを調達。

SDカードにイメージを焼いて起動したら、当然とはいえ、普通にヘッドレスなARM7 Linuxマシンとして起動してきた。OSはUbuntu 15。 OpenCVは 3.1 で、FFmpegサポートも入った状態でコンパイルされている。……これは色々と便利なのでは?

試しにIkaLogでビデオファイルを解析させてみたら、あっけないほど簡単に動いた。

PYNQにはビデオキャプチャ利用を想定したHDMI Inputポートがあるので、これでキャプチャできるかは大変興味があるところ。Jupiter上でOpenCVの顔認識をするコードを途中まで実行したら、WiiUの画像がキャプチャできた。



ただしPYNQのbase.bitではDDCの応答内容に問題があるのかWiiUからビデオ信号が出てこない。このためHDMIマトリックススイッチやスイッチャーなどの機械を挟んでいる。また、720pだと色々安定していないような感じ……。過去に試していたとき、ZYBOではDigilentのdvi2rgbのEDIDを書き換えたらWiiUの信号を直接、安定して食えるようになったので、そのときの成果を持ってくれば解決するだろう。だいたい解決策は見えているので後回し。ちなみに以前ZYBOで実験していたときの写真がこちら。


Jupter で操作した内容を IkaLog の映像インプットとして使えるようクラスを追加して、とりあえずだけども対応完了。
https://github.com/hasegaw/IkaLog/commit/5b6b9ce55e1ae32e57c2dd6f05ae20aa00c9b3fd

HDMIのキャプチャは実現できたが、PYNQにはHDMI Outputもあるので、こちらにパススルーすると、PYNQがIkaLogマシン+ビデオキャプチャ+HDMIスプリッタを兼ねるという、いままでIkaLogを利用するにあたって必要となる3つのアイテムをワンボードで実現できることになる。

Pynqのドキュメンテーションを読んでいると、じつは上記の設定でHDMIパススルーも実現できていることがわかった。上記の設定を行うとOut側がIn側のバッファからデータを受け取るようなかたちでパススルーしてくれる(プロセッサは通していないと思う……フレームバッファは通しているかも?)

というわけで、数時間でできちゃったIkaLog+PYNQ(キャプチャ機能+映像のみスプリッタ機能)。

Pynqで動くIkaLog、Project Inqと命名。Pynqの利用用途として思いついてはいたけども、思った以上に簡単に実装できてしまった。ここまでの成果については下記 WIki ページを見ていただければ再現できるはず。
https://github.com/hasegaw/IkaLog/wiki/en_Installation_Pynq

これをしばらく動かしてみるといくつか課題が見えてくる。

一つ目の課題は、HDMI Outputから出力された映像がたまに縦にずれたりする。たぶんHDMI映像の伝送が、ARMのDDR3メモリに置かれたフレームバッファを介していて、IkaLogが走っているとメモリ帯域やバス幅が足りなくなるんじゃないかと疑っている。

二つ目の課題は、HDMIのスプリッタ機能といっても HDMI 信号を音無しの DVI 信号としてピクセル情報に落とし、それを DVI 信号として HDMI ポートから出しているだけなので、音が消えてしまう。もちろんレイテンシの問題もあるし、キャプチャ機能はそのまま使うとしても、 HDMI Input から入ってきた信号をできるだけ忠実に HDMI Output に出力するよう変更したい。

Xilinx FPGAなのでHDMIのシリアル信号をISERDESE2で受けて、出力するときはOSERDESE2で送信している(はず)。これらを直結すればナノ秒レベルのディレイでシリアル信号をそのまま伝達できるだろうけど、ビデオキャプチャ機能も必要なので、dvi2rgb IPと共存することは考えないといけない。

とりあえずPYNQについてきたbase.bitは忘れて、dvi2rgb -> rgb2dvi でパススルーするデザインを作ってみた。



WiiU の信号が直接映らないのは相変わらずだけども、画像がたまに縦に1ドット間延びするような現象は解決した。ARMプロセッサ側のDDR3メモリを介さずに、受け取った信号をそのまま送出しているからだろう。

でも、やはり音のデータは消えてしまっている。

手元に高速ビデオ・インターフェース HDMI&DisplayPortのすべて という書籍があった。


これを読み返してみると、オーディオ信号はVSYNC直後のブランク期間などに入っているとのこと。ここが現状どうなっているかを調べると、色々解決しそう。 dvi2rgb がブランク期間中の信号を捨ててしまっているのではないかという想像だ。もし信号が捨てられていない事が分かればラッキーで、今度は送出側 rgb2dvi が信号を捨てていると考えればよさそう。

Integrated Logic Analyzer を追加して信号を眺めてみる。





案の定 dvi2rgb がブランク期間中の信号をゼロでマスクしているようだ。この 000000 になっているところに、本当はオーディオ信号も乗っているはず。ここにあるはずの信号も含めて rgb2dvi の OSERDESE2 に流し込んであげれば、きっとオーディオ含めてスプリッタとして動作してくれるだろう。

とりあえずの調査はここまで。

2014年4月4日金曜日

MySQLの新しいInnoDB ページI/O圧縮機能について解析してみた


InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&D チームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。

参考にしたのは MySQL Server Snapshots (labs.mysql.com) にあるMySQL with InnoDB PageIO Compression のソースコード、およびMariaDBサイトに掲載された下記ブログ記事などを中心に調べています。

Significant performance boost with new MariaDB page compression on FusionIO

従来の InnoDB の圧縮機能については @sh2nd さんの記事が大変詳しいので、本記事とあわせてお読みになられることをお勧めします。
軽くコードを追っかけただけで実際に動作をトレースなどまではしていませんのでウソを書いていたらごめんなさい。その場合には適宜エントリを修正します。


■ 基本的な動作原理 - 従来の InnoDB 圧縮機能編

従来の InnoDB の圧縮機能は ROW 単位もしくはページ単位で圧縮しています。また、圧縮したデータのブロックサイズは KEY_BLOCK_SIZEで決まりますが、こちらはデフォルトで8KBになっています。16KBのページが1KBに圧縮されたとしても、8KBに、10KBに圧縮されても16KBに繰り上げられるということです。KEY_BLOCK_SIZEを4KBに変更した場合、1KBに圧縮できれば4KB、10KBに圧縮できれば12KBに繰り上げられます。

■ 新たに登場した InnoDB ページI/O圧縮の動作原理

これに対して新しい InnoDB の圧縮機能ではページ単位でまるっと圧縮します。これは InnoDB
のデータ構造のレイヤではなく FIL のレイヤで行われます。つまり InnoDB
エンジン自体は普段圧縮処理をせずに動作し、ファイルの読み書きをするときに透過的に圧縮・展開するイメージです。

次に、新しい InnoDB の圧縮機能で特徴的な点として、ページを圧縮したとしても、そのページには論理的に 16KB の容量が割り当てられたままになります。仮に16KBのページが2000バイトに圧縮できたとしましょう。この時でも、このページに16KBのページサイズが割り当てられたままになります。そして、実際にデータが入っていない部分については fallocate() システムコールによってホールに変換されます。つまり、ファイル中でデータが入っていない部分は「データが存在しない」状態にします。



ホールとなった部分の処理はファイルシステムの動作に依存しますので、ホールをうまく扱えないファイルシステムでは直接のメリットはありませんが、Fusion-ioが開発するNVMFSの場合、スパース空間を作成するとデバイス上では512バイトなどの単位TRIMが行われます。ここで新しいInnoDB の圧縮機能がどう動くかですが
  • 16KB のページをファイルにフラッシュしたい
  • ページを 2000 バイトに圧縮できた
  • ファイルに2KB (512B*4) で圧縮されたページを書き込む
  • 続く14KBにはデータは存在しないため fallocate() システムコールにてホール化
という動作になり、従来 16KB 書き込むシチュエーションで 2KB
のみの書き込みで済むことになります。

この実装の場合、圧縮された InnoDB のデータファイルはスパースとしてそこら中に穴が開いた状態になります。ファイルサイズ 1TB 、メディア上では 500GB の割り当て済みブロックを持つデータファイルを迂闊に cp コマンドなどで操作すると、スパースが解除されて突然大きなファイルに化けたりもするので注意が必要になるでしょう。

ここまで読んでいただいて、すでに気付かれた方もいるかと思いますが、この圧縮機能は、ハードディスクのように「論理ブロックアドレス(LBA)と物理ブロックアドレス
(PBA)の関係が1:1である」デバイス上では意味があまりありません。しかし、内部で追記型の動作をしており、LBAへの書き込みにあわせてPBAがマッピングされるフラッシュストレージ等で利用することを前提に設計された圧縮機能だと言えます。

512バイト単位でピンポイントでデータを書き込むため、ホスト−ストレージ間のデータ転送時間を最小化する意味でも有用です。なぜなら、オーバーヘッドが少ないフラッシュデバイスであれば特に、IOPS性能やレイテンシー性能は、転送バイト数と反比例する関係にあるからです。また、データ量が減ればストレージ容量の有効利用に繋がりますし、フラッシュストレージであれば、フラッシュの寿命が結果的に伸びることになります。 
 


■ でも、ぶっちゃけ、遅いんじゃないの?

いくら高効率な圧縮機能があっても性能が出なかったら仕方ありません。実際のところ性能はちゃんと出るのでしょうか。まだ動かしていないので自分での実測値はもっていないのですが、 MariaDB の下記のブログ記事に性能値の比較がありましたので引用します。
Significant performance boost with new MariaDB page compression on FusionIO

1) TPC-C ライクトランザクション性能の比較

MariaDB で TPC-Cライクなワークロードを1時間流した場合のトランザクション処理量の変化を示したグラフで、横軸が時間、縦軸がトランザクション数の性能値です。なおこの
ベンチマークは TPC-C new order のトランザクション性能に着目しています。
 

青が MySQL uncompressed 、すなわち一般的な InnoDB の圧縮無し状態です。従来の圧縮機能を有効にした場合が赤の値になります。非圧縮で約24000トランザクション/分であった性能値が約4000トランザクション/分程度に落ち込んでおり、オーバーヘッドは83%であることを示しています。

新しい InnoDB のページI/O圧縮の場合の性能値が緑色の線です。こちらは21000トランザクション強/分あたりでほぼ安定しており、オーバーヘッドは10%程度のようです。

2) linkbench でのトランザクション性能比較

赤線が MySQL uncompressed、すなわちベースラインの性能で、緑色が従来のInnoDB圧縮の性能です。

20,000秒時点の性能値で比較すると非圧縮時30,000トランザクション/単位時間であった性能が20,000トランザクション/単位時間程度に落ち込んでおり、このケースでは従来のInnoDB圧縮のオーバーヘッドは33%程度のようです。

新しく実装されたInnoDBページI/O圧縮は青(zlib)および紫(LZ4)です。zlib(青線)の場合は、20,000秒時点約27,500トランザクション/単位時間程度でオーバーヘッドは8〜9%です。LZ4アルゴリズムを利用した場合(紫)は Uncompress時とほとんど性能差が生じていません。余談ですが、先ほどのTPC-Cの性能比較はzlibアルゴリズムを使っていたのかもしれません。

3)InnoDBのデータサイズ比較

最後にデータベースの消費ストレージ容量を比べてみます。これは先ほどの linkbench 実行時のストレージ容量を比較したもののようです。
 

counttable, linktable, nodetable の3つが挙げられていますが、もっとも大きな容量を占める linktable で見た場合、従来のInnoDB圧縮では5割弱の容量削減効果に対し、新しいInnoDBページI/O圧縮では6割程度の容量削減が実現しています。counttable は誤差として無視するとして、 nodetable 含めて考慮するとも全体の圧縮率はもう少し低くなりそうですが、それでも十分な効果だと言えるでしょう。

■ おわりに

InnoDBのページI/O圧縮を使うと、これまで512GBクラスのフラッシュストレージでサイジングしていたシステムであれば、控えめに見積って3割の圧縮効果を期待する場合、358GB程度の容量でよいことになります。逆に、1TB程度のフラッシュであれば1.4TBぶんのデータベースが格納できるようになります。また、書き込み量を 3 割削減できれば、書き換え寿命はその分増加しますから、フラッシュストレージが 1.4 倍長持ちするという事でもあります。

フラッシュストレージは容量単価でみれば高いですから容量効率が高まるのは嬉しいことですし、書き込み量が減少すれば、空き容量が増え、書き込み性能の安定化もつながります。MySQLのInnoDBページI/O圧縮機能は、今後のMySQL+フラッシュの構成に大きな影響をもたらすことは間違いないでしょう。

■長所/短所

長所

  • 512バイトなどのピンポイントでデータを書き込むため、ホスト−ストレージ間のデータ転送時間を最小化できる
  • データベースの容量が小さくなるため、ハードディスクと比べ容量単価が高いフラッシュストレージをより効率的に利用できる
  • 書き込み量を削減できるため、フラッシュの寿命の延命が可能
  • ワークロードとの相性、圧縮アルゴリズムによってはオーバーヘッドが少ない(10%前後)
短所

  • フラッシュ用の実装といえ、ハードディスクには向かない
  • ファイルシステムがフラッシュ上で効率的にスパースを実現できる必要がある