ブックマーク

Linuxの基本の基本。Linuxの基本的なディレクトリ構成
https://oxynotes.com/?p=5987

Loss Functions for Neural Networks for Image Processing
https://arxiv.org/abs/1511.08861
# 画像処理ニューラルネットワークのための損失関数

A recent approach for subsurface scattering
https://computergraphics.stackexchange.com/questions/5214/a-recent-approach-for-subsurface-scattering/5238
# 少し前の stackexchange の投稿だが、SSS 実装の手法

When global_variables_initializer() is actually required
https://stackoverflow.com/questions/44299666/when-global-variables-initializer-is-actually-required
# いつ、global_variables_initializer のコールが必要か

[Unity]無限平面を描画する過程でGPUの理解を深める
https://qiita.com/yuji_yasuhara/items/158bab01cfff3c39214b
# 勉強になりました

NTTコミュニケーションズのソフトウェアエンジニア向け研修内容・資料を公開します
https://developer.ntt.com/ja/blog/7bd554e6-30df-4c33-9e94-7e4202bdf2c0

Stadiaのリアルタイムストリーミングを実現する技術
https://qiita.com/kkoiwai/items/584b7a9317afd3ca9406

32-bit to 16-bit Floating Point Conversion
https://stackoverflow.com/questions/1659440/32-bit-to-16-bit-floating-point-conversion
http://www.fox-toolkit.org/ftp/fasthalffloatconversion.pdf

TensorFlow Model Optimization Toolkit — Pruning API
https://blog.tensorflow.org/2019/05/tf-model-optimization-toolkit-pruning-API.html

Generative Adversarial Network とは――トップ研究者が解説
https://blogs.nvidia.co.jp/2017/06/21/generative-adversarial-network/

Photo Editing with Generative Adversarial Networks (Part 1)
https://devblogs.nvidia.com/photo-editing-generative-adversarial-networks-1/

Linux での GUI

OS が GUI 機能を提供している裏側では、レイヤー構造になった非常に多くのコンポーネントが共存して動いています。

ウィンドウシステム

X Windows System (X11) ※X11 自体プロトコル(規約・取り決め) の事で、そのプロトコルの実装が、X.Org

wayland、新しいプロトコル?Direct Rendering Manager というGPU 描画のためのインターフェイスを活用。

https://en.m.wikipedia.org/wiki/Direct_Rendering_Manager

デスクトップ環境

KDE, GNOME

GUI ツールキット

GTK, Qt

Ubuntu 18.04 インストール

mac book air 2015 に Ubuntu を入れてデュアルブートさせる。
mac book air で快適に使うための個人的な設定。

Wifi 接続

Ubuntu インストール直後は wifi が使用出来ないため、Thunderbolt – Ethernet アダプタを使って有線LAN接続。

ターミナルで以下のコマンド
sudo apt update
sudo apt upgrade
sudo apt-get install bcmwl-kernel-source

これで問題なく wifi に繋がった。最後のは apt-get ではなく、apt でも良いのかな?

日本語入力

ibus-mozc をインストールし、Region & Language のインプットソースから Japanese (mozc) を追加。mac book キーボードだと、command + space で日本語切り替えが可能

  • Apple Aluminium (JIS)
  • Japanese – Japanese (Macintosh)

参考
https://www.hiroom2.com/2018/04/29/ubuntu-1804-ibus-mozc-ja/
https://yaruki-strong-zero.hatenablog.jp/entry/ubuntu_switching_ja_ime

テーマの切り替え

Activities で GNOME3 Tweaks を検索してインストール。Fonts から全体の文字スケーリングを 0.85 に変更。

Appearace からテーマを Adwaita-dark に変更

Ctrl と Command Key の変更

Copy & Paste が Control キーに割り当たっているため、mac とデュアルブートして使っていると、キーバインディングに戸惑う。Command (Super) Key に割り当てたい。

Control と Command の位置の変更は、インストールした Tweaks を使用する。Keyboard & Mouse から、Additional Layout Options を選択する。

Ctrl position から変更可能。

Input Source の切り替え

Control と Command 位置を変更すると、今度は Input Source (Japanese と Japanese (mozc)) の切り替えが不便に感じる。

設定の Keyboard から、switch to next input source のキーを変更する。

スクリーンショット撮影

Show Applications の Utility の中に、Screenshot アプリがあるためそれが使える。Favorites に登録しておくと便利。

HDD 容量確認

Lounch the System Monitor app from Show Applications button.
It is can check a system monitoring, such as CPU, Memory and Storage.

Mac <-> Ubuntu 切り替え

通常起動するのは Ubuntu。Ubuntu から再起動後 OS が起動する前に、Option を押し続ける。

DirectX12 のサンプルはなぜ WM_PAINT で更新と描画をしているのか?

DirectX12 のサンプルを読んでいて不思議に思うのは、Update 関数と Render 関数が、メッセージループでは無くてウインドウプロシージャで処理されていることです。

DirectX9, 10, 11 のサンプルだと、更新と描画関数はメッセージループで処理されていたため、そのやり方が DirectX のお作法だと思っていたのですが、DirectX12 のサンプルからは突如として WndProc の WM_PAINT で処理されるように変更されました。

特に調べてもこれと言った理由にはたどり着けなかったのですが、推測も含めて自分なりの答えをメモとして残します。

なぜ、 WM_PAINT で更新と描画を行なっているのか?

恐らく UWP とコードの共通化を行いたかったためと思われます。DirectX12 のサンプルから、UWP と Desktop (WindowsAPI) のそれぞれに対応したサンプルが提供されています。

UWP の場合は Windows API のような、低レベルのメッセージループ処理を書く必要はありませんが、イベントに対応する関数をシステムに登録して、必要に応じてイベントドリブンで処理されます。この部分が、Windows API のウインドウプロシージャと同じなため、アプリケーション側はイベントハンドラー内で呼び出される関数のみを用意すれば良く、それが OnUpdate と OnRender として定義されており、Windows API からはウインドプロシージャで処理するようになったと推測します。

だがしかし、UWP 側は View::Run() の中で、ループを回して処理しているので、Windows API 側も似たようにメッセージループ内に書けば良かった気もし無いでも無いです。

なぜ、WM_PAINT が毎フレーム発行され続けるのか?

この挙動が不思議でした。Windows API の DirectX のサンプルの挙動を見ていると、WM_PAINT メッセージが毎フレーム呼び出されています。

通常、WM_PAINT は UpdateWindow() や InvalidateRect() が呼び出されて、再描画が必要な時に発行されるはずです。これらの関数呼び出しを行なっている箇所も見当たらないため、なぜ、毎フレームWM_PAINT に来るのか疑問でした。

少しテストしてみたら、WM_PAINT が発行された後に BeginPaint() などで描画処理を行わないと、WM_PAINT が発行され続ける挙動があるみたいです。DirectX ではウィンドウの更新は全て DirectX API が行うため、Windows API の描画命令が呼び出されることはありません。そのため、Windows は、再描画の依頼を出し続ける事により、連続的に WM_PAINT が呼び出される事で、毎フレームの更新が実現されています。