PyMel

使われてるコードを見ていて気付いたこと。

 とりあえず、名前を変えるような操作を伴う場合にいちいち関連するノード(基本的には、shapeとその親のtransform)の名称の変化を気にしたコーディングの必要がなさそう。
 一旦PyMel Objectを取得すると、Objectがノードを示す一意のデータになるので、名称の変化を気にしないでよかった。

 これはたぶんOpenMayaでもPyMelと同じなんだろう。(試してないけど、オブジェクトを作って、それでノードを操作するものなので。)
 しかし、Python+Maya.cmdsで書いていると名前ベースになってしまうので、renameすると途端にデータを見失いまくる…この辺は非常にめんどくさいと思った。

 こんな感じに書くと、シェイプのリネームに失敗することになる。

 OpenMayaのようにノードをオブジェクト管理している環境の方が、リネーム絡みの処理は楽かと。 (OpenMayaの手続きに慣れる必要はあるけど。)

時間をおいて眺めたら、なんでmaya.cmdsでわざわざrenameしているのか。いや、そもそもなんでshapeを先に取得しているのか…とか疑問のわくコードではある。
単に、元がmaya.cmdsベースのコードにOpenMayaを付け足してたり、途中の処理をバッサリ削除してメモとして仕立てたせいなんだけど…どっちにしろ名前ベースで処理中にrenameしたらいろいろ不味いことが起こる。
OpenMayaだと、ざっくりこんな感じ?(完全にサンプル実装だけど…)

DirectX12のマルチGPU

 OpenCLとかRadeonのCrossFireばかり気にしていたけど、DirectX12のマルチGPUの機能が思ったより凄いかも。
 RX580で2万くらいの出物があったので、手元のRyzen2700X+RX570とセットでTimeSpy(futuremarkのベンチマーク)を試してみた。

 スコアはTotal:7726, Graphic: 7600(Test1:51.58, Test2:42.11), CPU:8534だった。
 ググってみると Ryzen1600X+RX580でTotal:4156というのを見つけたので、どうやらマルチGPUでそこそこ性能が出るというのは嘘じゃなかった。

 しかもDirectX12のEMAという機能は異機種混合を可能にするらしくて、単なるモデル違いだけでなくメーカー違いもサポートする模様。またGTX970x2ではSLI接続より効果が上がったという結果も見つけたので、そもそも技術的にかなり最近のGPUのレンダリング パイプラインを効率化する方法を導き出したということのような気がする。

 …のだが、そんなに凄いという噂を目にしなかったのは、単にそちら方面にアンテナ伸ばしてなかったからなのか、それともじつはそこまでの効果が出ることが稀なだけなのか。

 実のところ、そこら辺がよく判らないでいる。

その後

 DiRT Rallyを動かしてみたら、RX570単体が平均で60fps前後 ⇒ RX580+570では100fps超になっていた。1.6~1.7倍ほど処理が増大した。そもそも、RX570⇒RX580で12,13%早くなってるというのもあるけど、かなり上乗せされてる感じがする。
 DX11のゲームなので、DX12ネイティブなゲームだともっと上乗せされるのかしら。

で、結局OpenCLとは何か?

 それには、「“GPGPU”についてググりなさい。」というのが答えかもしれない。終わり。

 …。
 大雑把には、ベクトル演算ユニットの活用手段のひとつであり応用技術。そのライブラリ。
 名前からも推測できるが、OpenGLを踏襲した仕様体系。手続き的な部分が似ているので、OpenGLを使ったことがあれば、なんとなく使い方が見える感じ。

GPGPUって?

 知るには、まずここからかも。
 「GPGPU(General-purpose computing on graphics processing units; GPUによる汎用計算)とは、GPUの演算資源を画像処理以外の目的に応用する技術のことである」wikiより。
 要するに、最新グラボに搭載されている3DCG系の演算ユニットを汎用的な計算に活用する為の技術体系が、GPGPUと呼ばれている。
 用語的には、ベクトル演算ユニットとGPU(グラボに乗っている計算機)は別物で、コンピュータに直で乗っているのがベクトル演算ユニットで、GPUはそれとは別物。という扱いだけど、これは単純にグラボが専用のメモリを積んでいて、GPUはグラボに積んだメモリしか直接アクセスできない。というのが理由。コンピュータに乗ったメモリにはグラボからはアクセスできないので、グラボはコンピュータにデータを送って貰わないと何も計算できない。また計算結果もコンピュータに読み取って貰わないといけないので、ひと手間掛かる。
 その代わり、GPUはグラボ内のメモリに高速かつ(GPU搭載の複数の計算機による)大量のアクセスができるので、単純な計算を超高速に実行できる。
 単位時間当たりの計算速度はCPUを遥かに超えてきているので、そこに価値ができている。

 ただし、GPUにはいくつかの点でCPUに劣る面があり、計算可能な範囲がCPUに比べると制限を受ける傾向がある。

 長所:メモリにシーケンシャルにアクセスし、かつ条件分岐の無い計算(演算密度の高い処理)に強い。
 短所:条件分岐だらけ、メモリにランダムアクセスが発生する計算は大の苦手。

 また、GPUにより単精度浮動小数点しか対応していなかったり、メモリもCPUほど大きなサイズを持っていない点も短所に挙げられる。

で、結局OpenCLって?

 専用の記述式で計算処理(Kernel:カーネル)を書き、専用の初期化・実行処理で計算処理を実行させる為の環境がOpenCL。
 OpenCLドライバが用意されたGPUと対応するSDKを用意すれば、あとはプログラムを書くだけ。

 (参考)C++でOpenCL(使ってみよう編)

 CPUのような汎用的な処理は苦手だけど、計算処理を一気に処理することに特化した性能を持っているので、画像処理や3次元計算にはとても有用。

Auth0 試してみた。

 “Auth0”がなにか?というと「認証サービス」というもの。

 そもそも、一般に存在しているいろいろなサイトの中には認証処理が一般に公開された状態になっているものがある。Googleだったり開発系だとGithubだったり。
 そういうところにアカウントを持っている場合に、いちいち他のサイトで認証する時にサイトごとにユーザー名やパスワードを用意するのって億劫なわけです。
 なので、サイトによっては一般の認証システムを使って自サイトへのサインインを完了させる機能を用意していたりする。そういうサイトは、そのサイト用のユーザー名やパスワードを特別に作らなくても、Googleアカウントとかでサインインしてサイトのサービスを利用できるようになる。
 でもそういうサービスを提供するにも、認証システムを旨いこと実装してあげないといけないのでいろいろ大変です。

 単純に言えばAuth0はそういう認証処理を一元化して管理できる場(プラットフォーム)を用意しました~って感じのサービス。(このへん読むといろいろわかるかも⇒認証プラットフォーム Auth0 とは?

 WordPressのプラグインに“Auth0”って、そのまんまの名前のプラグインがあったので、利用してみた。

 基本的には、Auth0で自分のアカウント(テナントID)を作って、WordpressのプラグインにそのIDとあとアクセス用のTokenを作って渡してあげればいい感じ。
 Tokenは、Auth0のDashboardからAPI項目を選択。APIがなかったら作成(たぶん1つは作られてる?)して、その中のAPI Explorer項目を選択。そこにTokenが出てくる。(これも、なかったら作成。確かデフォルトでは作成されてない。)

 あと、Wordpress側のダッシュボード > 設定 > 一般 > メンバーシップ のチェックが入っていないと、初回サインイン時にユーザーが作成できない旨のエラーが出るので、はじめてAuth0でサインインする時は必ずチェックを入れておくこと。

[OpenCL] 少し動かしてみたけど、結構情報が当て嵌まらない

 なんだろう? AMD環境って、今OpenCLのメインストリームじゃないのかな?
 検索して出てくる情報は、Intel系…というかMacの情報が多くて、そもそもうちの環境だとCPUがデバイスとして列挙されないんだけど…どゆこと??って感じになっている。

 とりあえず、下記のサイトとかでサンプル拝借しながらdeviceinfoを集めるところからやっているけど、自分で何とかしていかないと試しに人に倣って試してみる、という訳にはいかないかなぁ。

 ちなみに、参考のサンプルはWindowsで動かすと足りないものがあったりするので、処理を省くか、なんとか処理を補完しないと動かせなかった。。

参考

Dakkers/OpenCL-examples
tzutalin/clDeviceQuery.cpp
OpenCLに対応するデバイスの列挙(C言語・Mathematica)

その後

C++からOpenCLをラクに使うためにライブラリを書いてみた

 これも、うちの環境と違う。
 どうやらうちの環境だと、ユニファイドメモリをサポートしてないっぽい…(この方が言うには、「サポートしていないハードがないので動作未確認」とな。そんなに珍しい環境なのかしら?)

ClPyって??

 ClPy(シーエルパイ)なるものを見つけたので、メモ。

 「CuPyをOpenCLで動かすフレームワーク」なんだそうで…CUDA諦めてOpenCL勉強しようとしたら、これだもんなぁ、、
 とりあえず、忘れないようにメモっておく。

 CuPyをOpenCLで動かすフレームワーク ClPy を先行リリースしました

AMD APP SDKが見当たらない…

めも。

 CUDAが環境的にナニだったので、OpenCL調べてみるか…と思ったのだが、調べていくとAMD APP SDKが必要…みたいな話になってきたので、AMDでSDKをDLしなきゃーって思ったのだが、何故だか見当たらない始末。

 理由は不明だが、2018.12.2現在公開されている気配がない。

 で、こんな書き込みを見つけた。
 OpenCL SDK

 どうもここからもらってくる感じになってるみたい。
 AMDのドライバ(Radeonドライバとか)にはそもそもランタイムとしてOpenCLが含まれているらしく、とりあえずそこに置いてある include, libファイルでビルドすれば動くっぽい。

 参考サイト①にあるデバイス確認のコードで、実際に動くことも確認できた。

参考

C++でOpenCL(環境構築編)
SDKなしでOpenCLを使ってみる -導入編-
Khronos OpenCL Registry(仕様策定をしている団体のページ)
公式のリファレンス