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

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

2014年1月8日水曜日

Windows 8の起動を阻害するドライバを削除する

オープンソースの HFS+ ドライバを Windows 8 環境にインストールしてみたらOSが起動しなくなってしまった。同じタイミングで Adobe Create Cloud もアクティベートした都合システムを過去の復元ポイントに戻したくなかったので多少もがいてみた。

最初はセーフモードならあがってくるだろうと余裕をかましていたんだけど、残念ながらセーフモードでも問題のドライバがロードされてしまう模様。セーフモードがあがらないとなるとアンインストーラすらキックできない。

回復コンソールからドライバのアンインストール用exeファイルを叩いてみたら .NET Framework 4.0 がないためか実行できず。 C:\Windows\ 以下のあやしいファイルを削除してみることにしたがファイル名がわからず。結局 TREE コマンドで調べた。

> TREE C: /F > c:\allfiles.txt
> C:\Program Files\Hidemaru\Hidemaru.exe c:\allfiles.txt


秀丸が起動してくれたのはずいぶん助かった。
 
ああ、これだ。 AppleHFS か。だから H*.* とかで探しても出てこないわけね。該当ファイルを DEL コマンドで消去した後に再度 TREE コマンドを実行して、削除したはずのファイルが他の場所に残っていないことを確認の上シャットダウン、再度起動。

2010年6月14日月曜日

ユーザプロファイルが破損したWindows 7環境の復旧

Windows 7 + BitLocker 環境のユーザプロファイルが破損してログインできなくなったため、ユーザプロファイルを再作成して復旧しました。その時のメモ。

■ セーフモード + プロンプトで起動

BIOS POST画面から Windows 7 のスプラッシュロゴに切り替わる瞬間に F8 キーを押し起動画面を表示します。 BitLocker によりHDD 全体を保護している場合、このタイミングで BitLocker の回復キーを要求されます。

■ ログインし裏口ユーザを作成

コマンドプロンプトだけであればユーザプロファイルが破損していても問題なくログインできました。ここで DOS プロンプトより裏口ユーザを作成し、管理権限を与えておきます。

C:\Users\hasegaw>> net user hasegaw2 /add
C:\Users\hasegaw>> net user hasegaw2 password
C:\Users\hasegaw>> net localgroup administrators hasegaw2 /add

■ 普通に起動し、 hasegaw ユーザを再作成

この段階で、これまで使っていた hasegaw というユーザだけでなく hasegaw2 によるログインも可能な状態になっています。

hasegaw2 でログインした後に下記の順序で作業します。


  • C:\Users\hasegaw を C:\Users\hasegaw.old にリネーム

  • コントロールパネル(もしくはnet user)で hasegaw ユーザをいったん削除、再作成

  • hasegaw ユーザでログイン


  • 必要なファイルを hasegaw.old/ から移動などする

Windows xp ではユーザプロファイルのフォルダ自体がなくなっていれば自動的に再生成されたかと思いますが Windows 7 ではダメだったのでユーザごと再作成しました。 SID が変わってしまいますが、まぁローカルユーザですし特に問題はないでしょう。


■ プロファイル破損時に備えて

あらかじめ裏口ユーザは一つぐらい作っておいたほうがよいかもしれませんね。。。



2010年1月24日日曜日

昼食の時間だけスクリーンセーバをデフラグツールに変更する

こんにちわ。みなさんお仕事は順調でしょうか?

客先の業務量減少に伴い、残業規制やらお昼時間の消灯やらでテンションだだ下がりなブログ主です。お昼の時間 12:00 になるとオフィスの照明が強制消灯されるので、最近は時間どおりに食事に出ることが多くなりました。おかげでお陰で最近、体重がいいかんじにry(関係ない

ところで、お昼の時間って、PCの電源が入ったままなので、この間にデフラグを流してる人なども多いのではないでしょうか。私は別にデフラグジャンキーじゃないのですが、職場のセキュリティポリシーに準じて導入しているツールがファイルをズタズタにしてくれるので、昼休みはデフラグすることにしようと思いました。



  • 使用するデフラグツール

  • スクリプトの作成とテスト

  • タスクの設定

  • 問題が発生……



■ 使用するデフラグツール

ほかに JkDefrag などの選択肢もあるわけですが、Auslogics Disk Defrag が最近のお気に入りなので、このスクリーンセーバーを使いたいと思います。

Auslogics Disk Defrag Screen Saver

http://www.auslogics.com/en/software/disk-defrag-screen-saver/

ただ、私は普段からデフラグスクリーンセーバーを設定するほどのデフラグジャンキーではありませんし、外出先でデフラグがかかると鬱陶しいので、時間指定でスクリーンセーバーを変更することにしました。

■ スクリプトの作成とテスト

まず、スクリーンセーバーを変更する VBScript を 2 つ書きます。

C:\hasegaw\bin\TASK_SCREENSAVER_CHANGER_DEFRAG.vbs …… スクリーンセーバをデフラグツールに

C:\hasegaw\bin\TASK_SCREENSAVER_CHANGER_LOGON.vbs …… スクリーンセーバを普段のものに

以下にスクリプトの例を示します。

C:\hasegaw\bin\TASK_SCREENSAVER_CHANGER_DEFRAG.vbs

'
' スクリーンセーバを auslogics disk defrag に設定する
'

SS_DEFRAG = "C:\Windows\aus_ddss.scr"

HKEY_CURRENT_USER = &H80000001
strComputer = "."

Set objReg = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "Control Panel\Desktop"
objReg.CreateKey HKEY_CURRENT_USER, strKeyPath
objReg.SetStringValue HKEY_CURRENT_USER, strKeyPath, "SCRNSAVE.EXE", SS_DEFRAG

C:\hasegaw\bin\TASK_SCREENSAVER_CHANGER_LOGON.vbs

'
' スクリーンセーバを login.scr に設定する
'

SS_DEFRAG = "C:\Windows\SYSTEM32\logon.scr"

HKEY_CURRENT_USER = &H80000001
strComputer = "."

Set objReg = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "Control Panel\Desktop"
objReg.CreateKey HKEY_CURRENT_USER, strKeyPath
objReg.SetStringValue HKEY_CURRENT_USER, strKeyPath, "SCRNSAVE.EXE", SS_DEFRAG

これらのスクリプトを書いたら、スクリプトが期待通りに動作するかを確認します。


  • 画面のプロパティーを開き、スクリーンセーバーを なし に設定してプロパティを閉じる

  • TASK_SCREENSAVER_CHANGER_DEFRAG.vbs をダブルクリックする

  • 画面のプロパティーを開き、スクリーンセーバーがデフラグツールに設定されたことを確認

  • TASK_SCREENSAVER_CHANGER_LOGON.vbs をダブルクリックする

  • 画面のプロパティーを開き、スクリーンセーバーが普段のものに設定されたことを確認

■ タスクの設定

スクリプトが問題なく動作することを確認したら、続いて Windows のタスクとしてこれらのスクリプトを設定します。


  • TASK_SCREENSAVER_CHANGER_DEFRAG


    • 実行するプログラム …… TASK_SCREENSAVER_CHANGER_DEFRAG.vbs

    • 実行日時/頻度 …… 毎日11:50

    • その他設定 …… ログオン時以外は実行しない

  • TASK_SCREENSAVER_CHANGER_LOGON


    • 実行するプログラム …… TASK_SCREENSAVER_CHANGER_LOGON.vbs

    • 実行日時/頻度 …… 毎日13:00

    • その他設定 …… ログオン時以外は実行しない

  • TASK_SCREENSAVER_CHANGER_LOGON2


    • 実行するプログラム …… TASK_SCREENSAVER_CHANGER_LOGON.vbs

    • 実行日時/頻度 …… ログオン時

    • その他設定 …… ログオン時以外は実行しない

これで、毎日 11:50~13:00にスクリーンセーバが変わるようになりました。

■ 問題が発生……

その後、 Auglogic Disk Defrag のスクリーンセーバを実際に動かしてみて、問題が判明。

このデフラグスクリーンセーバー、実行中はデフラグ対象のファイルの名前がリアルタイムで表示されてしまいます。(^^;;;

この状態でついうっかり「...\秘蔵エロ\...」とか「履歴書.doc」※とかのファイル名を職場の人間に見られると大変なことになってしまうのでちょっと常用はきついなぁ……。スクリーンセーバの設定をみてもこの挙動は変えられないみたい。

※ エロとか履歴書とかはネタだとしても、顧客名などの情報を含むファイル名がスクリーンセーバーにより表示されている状態というのは、普通に考えてもちょっと……。開発元はどういう神経で作ってるんでしょうね。

2009年2月16日月曜日

GPL PV Drivers のパフォーマンス

製品の仮想化技術には、 VMware でも Parallels でも、 Windows をゲストとして動作させる時に I/O パフォーマンスを向上させるためのドライバが用意されています。

このような仮想化デバイスのドライバを使用しない場合、仮想マシン上で動作する Windows などの OS は、仮想マシン技術がエミュレートする PCI バス上のディスクコントローラに対して I/O を行います。これに対して、先のドライバは VMware などの仮想化ソフトウェアと直接 I/O データをやりとりするため、パフォーマンスが向上する仕組みになっています。

さて、 Xen においてもこのようなドライバの仕組みは Paravirtual Driver (準仮想化ドライバ) という形で存在しています。 Xen のソースコードをダウンロードすると unmodified_driver/ などというディレクトリがあったりしますが、それがまさにそのドライバです。

アンオフィシャルですが、 Windows 用のオープンソースな PV ドライバも存在しています。


しかし、ただ単純にベンチマークをとってみると...



【検証環境】

・HP ProLiant ML115 G1
・Athlon64 X2 5600+ (2.8GHz x2)
・8GB PC5300 RAM
・Hitachi HTS72323 320GB 2.5inch HDD
・openSUSE 11.1 + Xen 3.3
・Windows xp SP3 (x86)


あれれ~? PV ドライバを入れた場合のほうがパフォーマンス伸び悩んでますね。というか QEMU のハードウェアエミュレーションと比較し完敗です。何かの間違いでしょう。しかし、再計測しても再計測してもこの結果がひっくり返ることはありませんでした。

そこで、このツールで計測をはじめてから計測が終わるまでの時間を、愛用の G-SHOCK で測ってみました。なお Crystal Disk Mark のソースコードを確認したところ決まった量の I/O 負荷をかけて、それの所要時間から性能を算出しているようです。つまり計測値はアテにならなくても、 I/O に要した"時間"は信用できると考えられます。結果は以下のとおりでした。

PV ドライバ使用時: 3分23秒
PV ドライバ未使用時: 3分31秒

なんだ、やっぱり PV ドライバのほうが早かったんですね。約 6 % の性能アップしていたようです。しかし、これでは本当のスループットがわかりませんね。敢えていえば QEMU エミュレーションから 6% しか性能向上がない PV ドライバというのも随分寂しいものです。( XenSource や Novell が作っているドライバはもっと高いパフォーマンスを示してくれることでしょう)

PV ドライバには I/O パフォーマンスを向上させる以外のメリットとして CPU に対する負荷の低減があります。無意味に低レベルなハードウェアの真似(ゲストによる I/O ポートへのアクセスをトラップしエミュレーション)をする必要がなくなるからです。

I/O パフォーマンスについてはまた計測方法を検討して検証をしてみたいと思います。というわけで、今日はおやすみなさい。