GPU、GPGPU 相關
C++ AMP 是微軟在 2011 年發表、在 2012 年推出的一套適用於 GPGPU、大量平行化的 C++ 函式庫。他基本上算是相對高階的 GPGPU 開發方案，由於底層是使用 DirectX 來做的，所以理論上能支援不同廠牌的顯示卡（參考《C++ AMP 相關資料》）。
不過，由於 Heresy 這邊還是有考慮到要跨到 Linux 環境的問題，所以簡單玩了一下後，就沒有去認真研究這個東西了。（不過由於 C++AMP 屬於開放標準，倒也真有人在 CLANG/LLVM + OpenCL 弄出了 C++AMP 的實作；參考《Bringing C++AMP Beyond Windows via CLANG and LLVM》）
而前幾天，忽然和到 Google 推薦的文章《C++ AMPの死について》，這才發現原來 C++AMP 也已經被微軟賜死了…
雖然 Heresy 個人算是滿早期開始接觸 NVIDIA CUDA 的，但是其實已經沒有在碰 NVIDIA CUDA 程式好一段時間了…不過，由於在開發的專案裡面，還是有一些地方有用到別人寫的 CUDA 程式，所以在維護的時候，還是需要去考慮他。
而根據從以前到現在的經驗，NVIDIA 針對 Visual Studio 的支援，一向不是做得很快、很好；往往 Visual Studio 已經出了新版本了，CUDA 才終於支援上一個版本…
某方面來說，這應該也是由於 NVIDIA CUDA 的重點是高速計算、大部分這個領域的用戶，其實都是把程式放在 Linux 叢集上跑的關係吧？但是，這對於一般 Windows 的開發者來說，其實還滿麻煩的…
最近，Heresy 在把手邊的專案移植到 Visual Studio 2017 上，CUDA 又出現問題了… orz
這篇是之前《使用 QGraphicsScene 繪製 widget、產生 OpenGL Texture》和《使用 QGraphicsScene 繪製 widget、產生 OpenGL Texture：續》這兩篇的延伸，主要是針對 Qt OpenGL 裡面，字型的問題做一些研究紀錄。
老實說，最初一直以為 Qt 應該都處理掉了，應該可以一下就弄完，結果沒想到牽扯的問題很多，一堆問題還是無解…
首先，這邊最基本的需求，就是使用 QOpenGLPaintDevice，透過 QGraphicsScene 把 Qt 的圖形介面（QWidget）以 offscreen 的形式、畫成一個 OpenGL Texture。
而現在碰到的主要問題，則是兩個部分：
這一篇，算是自己點單紀錄一下，目前使用 Qt 5 來開發 OpenGL 程式時，碰到的一些問題吧…
基本上，Heresy 對於整個 Qt OpenGL 的使用架構不算非常熟，也是邊寫邊摸，所以本文也不盡然正確，很大的機會應該有不少地方是使用錯誤…不過，基本上就算記錄下來，給自己以後參考用了。
首先，Qt 5 基本上應該算是已經深度整合 OpenGL／OpenGL ES 了～預設下載預先編譯好的版本，都有支援 OpenGL、而不用另外自行編譯了。
而他的主要文件，應該可以從《OpenGL and OpenGL ES Integration》這邊開始看。
在今年五月的時候，Heresy 有寫了一篇《HTC Vive 開發方案：OpenVR 簡介》，大概介紹過 OpenVR（GitHub）粗略的架構了；當時 OpenVR 的版本還是 1.0.0，Heresy 主要是針對他的幾個模組的功用，做簡單的說明，並沒有認真地去講程式到底怎麼寫。
後來，其實 Heresy 算是有真得下去寫他的程式，也根據自己的需求、搭配 freeglut 重寫出一些小範例（GitHub）了。
到現在過了超過半年，OpenVR 也更新到 1.0.4 了，和 Heresy 剛開始研究時相比，不但 API 有做了一些修改，「hellovr_opengl」的程式內容，也做了相當程度的調整。
而這篇，就以「hellovr_opengl」這個官方範例，來大概紀錄一下怎麼寫 OpenVR 的 OpenGL 程式吧。
在去年 GDC2015 的時候，Khronos 就已經發表了將使用新的 3D 圖形 API「Vulkan 」來取代現有的 OpenGL 了～在當時也有提過了，OpenGL 和 Vulkan 上會是完全不相容的 API。（參考《Khronos GDC 2015 新消息：Vulkan 與 OpenCL 2.1》）
只是在發表了之後，其實這段期間都沒什麼大消息，而一般的開發者由於欠缺開發環境，也沒有辦法真的開始寫 Vulkan 的程式…
不過在前幾天，Khronos 終於正式釋出 Vulkan 1.0 的規格了～而同時，桌面電腦的三大圖形晶片廠 NVIDIA、AMD、Intel 也都推出了支援 Vulkan 的驅動程式了！再加上 LunarG 的 Vulkan SDK 也已經可以下載了，所以這也代表一般開發者已經可以開始試著玩 Vulkan 了～
下面就是一些主要的連結：
NVIDIA 的 CUDA 架構，基本上應該算是現階段最成功的 GPGPU 環境之一。他在新一代、專門用來做大量平行計算的環境裡面，算是推出最早的，所以相對起來、發展的也算是最完整的；而後來雖然 Khronos 有推出跨硬體平台的開放標準 OpenCL（Intel、AMD、NVIDIA 都有支援），但是就 Heresy 所知，還是有許多開發人員是偏好 CUDA 的。
而 AMD 在 GPGPU 這一塊…個人是覺得發展的始終有點悲劇吧？Heresy 有紀錄的部分，他最早是推出自家的「Stream SDK」，而之後就徹底捨棄自己的語言、完全轉投向 OpenCL、Stream SDK 也改名為「AMD APP SDK」了。
儘管 AMD 也試著在靠 OpenCL、以及後來所推出、基於 AMD APU 的「Heterogeneous System Architecture」（異質系統架構、官網）來做平行計算的發展方向（AMD 稱之為「Heterogeneous Computing」、異質計算），但是實際上…就個人所知，成效似乎不算是很好。
基本上，目前在 3D 電腦圖學這個領域裡面，並沒有一個真正通用的檔案格式；以 3D 模型來說，格式可以說是有千百種，包括了常見的 OBJ、STL、X3D…等等，各家都有個家的規格。而這一點，也導致了在開發程式、以及檔案交換上的困難。
雖然 Khronos 之前也有訂製「COLLADA」這個標準（官網），但是他並沒有針對傳輸以及讀取做最佳化，所以對目前的 WebGL 來說或許已經不太適用了。（也很久沒更新了…）
而為了解決這個問題，Khronos 推出一個新的標準、glTF（GL Transmission Format），希望可以成為「JPEG for 3D」；而他的設計目標，就是希望可以提供一個有效率、並可以方便傳輸的檔案格式、定義，讓程式開發者，可以方便地儲存、讀取 3D 的場景設定、以及模型。
官方的公告是《Khronos Finalizes glTF 1.0 Specification for Efficient, Interoperable Transmission of 3D Scenes and Models》，官網則是：
這篇算是簡單整理一下 Khronos 在 GDC 2015 發表的一些消息。今年 Khronos 發表的消息，主要是下一代的 OpenGL、「Vulkan」，以及 OpenCL 兩個部分；而實際上，繪圖和計算這兩部分，看來已經越來越一體化了。
整體性的介紹，可以參考官方的投影片：Khronos GDC Press Briefing : Mar15.pdf。
「Variable Rate Shading」（VRS）這項技術（
Heresy's Space 