low_latency_layer：讓任何 Linux GPU 也能享有 Reflex 級低延遲

競技型 PC 遊戲玩家非常在意 Input‑to‑Photon 延遲——也就是從玩家輸入（例如滑鼠點擊）到畫面真正出現在螢幕上的時間。為了降低這段延遲，GPU 廠商推出了像 Nvidia Reflex 與 AMD Anti‑Lag 這類技術，透過協調 CPU 與 GPU 的工作節奏來減少等待時間。

問題是，在 Linux 上使用這些技術往往受到限制：許多功能依賴 專有驅動程式或 Windows 生態系整合。一個名為 low_latency_layer 的新開源專案提出另一種思路——用 Vulkan layer 在使用者空間實作類似 Reflex / Anti‑Lag 的低延遲控制。

核心概念：用 Vulkan Layer 做跨廠商低延遲

Vulkan 提供一種稱為 Layer 的機制，可以插在應用程式與顯示卡驅動之間。這些 layer 能夠：

• 攔截 Vulkan API 呼叫
• 修改或擴充行為
• 對應新的功能或擴充

low_latency_layer 正是利用這個機制來：

• 向遊戲宣告系統支援低延遲 Vulkan 擴充
• 攔截相關的時間與提交（frame submission）呼叫
• 在 layer 中自行實作 frame pacing 與排程邏輯

因為邏輯主要在 CPU 端的排程與時間控制，而不是 GPU 的硬體專屬功能，所以理論上可以在 AMD、Nvidia、Intel GPU 上運作，而不依賴特定廠商驅動。

關鍵 Vulkan 擴充：現代低延遲技術的基礎

目前 Vulkan 生態中有兩個重要擴充，對應兩大 GPU 廠商的低延遲方案。

VK_NV_low_latency2（Nvidia Reflex 類型控制）

VK_NV_low_latency2 讓應用程式可以控制 CPU 何時開始準備下一幀，從而減少輸入採樣與畫面呈現之間的延遲。

例如應用程式可呼叫 vkSetLatencySleepModeNV 與 vkLatencySleepNV，讓 CPU 在最合適的時間點開始工作，以降低延遲。

更早的 VK_NV_low_latency 則提供查詢 Reflex 能力的機制。

VK_AMD_anti_lag（CPU pacing）

VK_AMD_anti_lag 是 AMD 的對應方案，其核心概念是 限制 CPU 不要跑得比 GPU 太快。

如果 CPU 提前生成太多 frame，GPU 會排隊處理，導致輸入到畫面的延遲增加。Anti‑Lag 透過自動 pacing 來避免這種情況。

這個擴充後來被加入 Vulkan 規格，使 Anti‑Lag 能夠在 非 DirectX 環境中使用。

low_latency_layer 如何實作

low_latency_layer 的做法不是依賴 GPU 驅動，而是由 layer 自己實作。

流程大致如下：

1. 向遊戲宣告擴充支援
   Layer 告訴遊戲系統支援 VK_NV_low_latency2 或 VK_AMD_anti_lag。

2. 攔截 API 呼叫
   當遊戲呼叫低延遲相關函式時，layer 會攔截這些呼叫。

3. 自行實作排程邏輯
   Layer 控制 CPU 開始處理 frame 的時機、提交時間與 swapchain 行為，以減少過度排隊。

由於主要工作是 CPU 時序控制與 frame pacing，因此不需要特定 GPU 的專屬硬體路徑，這也是它能跨廠商運作的原因。

在 Linux 遊戲生態中的運作方式

這個 layer 可以嵌入兩種常見的 Linux 遊戲架構。

原生 Vulkan 遊戲

如果遊戲本身就是 Vulkan（例如部分 Linux 原生版本），只要像其他 Vulkan layer 一樣載入即可。

遊戲會看到系統支援低延遲擴充，而實際邏輯由 layer 處理。

Proton（Windows 遊戲）

大多數 Linux 玩家其實是透過 Proton 執行 Windows 遊戲。這背後依賴兩個重要轉譯層：

• DXVK：Direct3D 9/10/11 → Vulkan
• vkd3d‑proton：Direct3D 12 → Vulkan

例如 DXVK 2.6 已經擴展對 Nvidia Reflex 的支援，在某些 DirectX 11 遊戲中可以透過 VK_NV_low_latency2 啟用 Reflex。

如果 Vulkan 層提供這些能力，Windows 遊戲仍然可以透過轉譯層使用低延遲功能。

與現有 Linux 解決方案的差異

Linux 其實已有一些相關專案。

Mesa Anti‑Lag Layer

Mesa 圖形堆疊已包含一個 Vulkan layer，用於實作 VK_AMD_anti_lag。

但這主要針對 AMD 的擴充。

low_latency_layer 的目標更廣——同時支援 Nvidia Reflex 類型 API 與 AMD Anti‑Lag API。

LatencyFleX

早期也有像 LatencyFleX 的專案，試圖讓支援 Nvidia Reflex 的遊戲在非 Nvidia GPU 上運作。

low_latency_layer 的不同之處在於：

• 直接使用 Vulkan 擴充路徑
• 更貼近 Vulkan 生態

目前的效能與基準測試

目前公開的 low_latency_layer 專門基準測試仍然有限，因此與 Windows 實作的直接比較仍在觀察中。

不過根據低延遲技術的一般特性，可以預期幾點：

• 低延遲機制在 GPU 成為瓶頸時最有效。
• 當 GPU 接近滿載時，限制 CPU 提前生成 frame 可以降低輸入延遲。
• 減少 frame queue 有時會稍微影響 FPS 或 1% low。

此外，開源 layer 無法複製所有專有功能。

例如 Nvidia Reflex 2 新增的 Frame Warp 技術，可以在畫面顯示前根據最新輸入更新 frame，進一步降低延遲。

這類需要深度硬體與驅動整合的技術，很難由通用 Vulkan layer 完整重現。

為什麼這對 Linux 競技遊戲很重要

長期以來，低延遲技術往往被 GPU 廠商與 Windows 平台綁定。

Vulkan layer 的做法帶來幾個潛在改變：

• 延遲控制進入 可審計的開源軟體
• 功能變成 跨廠商而非廠商鎖定
• Linux 遊戲堆疊（Proton、DXVK、Mesa）更容易整合

如果這類技術成熟，Linux 在 電競或高反應遊戲環境中的競爭力可能會顯著提升。

目前仍處於早期階段，但 low_latency_layer 展示了一個重要方向：

把 Reflex 級的低延遲能力帶到整個 Linux GPU 生態，而不只是某一家的驅動。