Okt04175

回覆 990# cdlp
喺4K 4:4:4 (無壓縮)支援方面，HDMI 2.0只做到4K @ 60Hz, 8-bit, 4:4:4，HDMI 2.1先至做到4K @ 120Hz, 10/12-bit, 4:4:4，用HDMI 2.0硬上4K 120Hz係會做有損壓縮降做8bit 4:2:0(損失咗色彩精確度)，所以咁先話HDMI 2.0係糟蹋緊4K 120Hz Panel，就算折衷降做1080P咁開120Hz模式都一樣係糟蹋緊4K 120Hz Panel。

要享受4K 120FPS 無損畫質嘅話，要有全套真正HDMI2.1嘅 電視機/電腦螢幕、顯示卡(RTX3000系或上N卡/RX6000系或以上A卡)、有標示可以上8K嘅真正HDMI 2.1線。

P.S. 有Display Port 2.1嘅電腦螢幕都可以入到4:4:4嘅4K 120Hz 10/12Bit訊號，Display Port 1.4都係唔夠頻寬要做DSC壓縮咁過4K 120Hz 10/12Bit訊號不過8Bit嘅話就啱啱好夠應付唔使壓縮。當然Display Port 2.1嘅電腦螢幕目前仲係比較貴嘅。

smoke_cheese

A卡 Linux driver 唔支持 HDMI 2.1（HDMI forum 唔批）
N卡唔開源所以做到
A卡用 Active DP 轉 HDMI 2.1 adapter 係可以嘅（出到 4k 120Hz 4:4:4，只係好似唔見有 adapter 支持 VRR）

HDMI 2.0 應該出到 1080p 120Hz，不過啲 driver 點決定畀唔畀你用個解像度有時真係神神化化的，可能取決於個 Mon 嘅 EDID 點寫

aazz

不過暫時 2K 已經覺得足夠了;
要上 4K 顯示器如果最少沒有 32吋;
應該不好看;
現在放的位放不下;
也沒有銀兩

cdlp

回覆 991# Okt04175


    原本忘記了舊電視需要手動force 1080p 120hz自訂 漸進式
並非dock 或者 hdmi 2.0

hker2021

咁display port cable 有無分 1.4, 2.1呢啲嘢？

via HKEPC Reader for Android

cdlp

回覆 991# Okt04175


    想問下玩portal第一代,team fortress 2
我用r5 2600 3060ti在3440p 175hz gsync oled
同4k 120hz oled
比較steam deck oled run兩款遊戲
我在兩部oled裝置4k解析度定是1080p 一開始進入遊戲場景是有12xfps
但用傳送搶射槍就畫面freeze左半秒，因為fps瞬間跌去88fps
至於tf2在呢部pc run除左移動3d鏡頭有撕裂再加上以上講的fps跌導致的畫面敞口 stuttering

但steam deck oled run portal 可以全程90fps不會stuttering 射傳送槍也不會freeze，至於tf2 在deck可以較80fps 80hz運行沒有stuttering和3d視角鏡頭移動的畫面撕裂

好奇怪portal第一代在deck會有新的ui介面是類似家用console果d ui interface，但portal 1在windows pc run就沒有呢ui

呢pc 接av amp去電視run far cry 3 1080p都維持不到在100fps只會是6x to 8x fps

Okt04175

回覆 996# cdlp
首先硬體部份，你部PC嘅CPU屬於Zen+架構(等如1.5代)而Steam Deck係Zen2架構，你部PC點都係DDR4 RAM(你未講幾多GB)而Steam Deck係用緊LP-DDR5 RAM有16GB(同GPU兩份用，GPU最多可以用到12GB至13GB做VRAM)，就咁睇你部PC應該就只有顯示卡GPU勁過Steam Deck嗰粒(但前提係遊戲食VRAM未超過8GB嗰陣），你部PC應該係屬於頭重腳輕唔夠力應付近代遊戲大場景內大量物件嘅運算處理(粒CPU唔夠力及時分派運算畀GPU，主要樽頸位喺舊架構CPU度，其次係RAM度)。

然後軟體部份，你未講 用邊款Linux系統、系統版本號、(GPU圖形運算API Driver包)Mesa嘅版本號，舊版本系統加上用舊系統核心 又或者用緊舊版本嘅Mesa都係Stutter成因之一。
仲有系統係幾耐之前安裝，對上一次做全系統組件係幾耐之前？(太耐冇更新，咁就享受唔到Mesa新版啲最佳化同埋Fixing)

最後，無論PC用Linux系統定Windows甚至MacOS想喺Steam度用遊戲機UI係要 開Big Picture模式，喺Steam普通模式UI嘅縮小視窗掣旁邊就係Big Picture模式切換掣，撳遊戲手掣嘅Logo掣/Home掣都係同樣效果。
而Steam Deck係改咗開機直入遊戲機UI同埋背後暫時唔Run桌面環境以及玩遊戲唔需要用嘅系統服務，所以遊戲機UI就特別改咗名叫 遊戲模式。
其實 Big Picture模式 同 遊戲模式 都係開返同一套遊戲機UI出嚟，不過後者會慳返資源用嚟提升遊戲嘅表現。

Okt04175

Wine已經出咗11.x系列一段時間，Wine11.0正式版改良咗好多野，基本上實現晒NT6.x核心絕大部份嘅功能，解決咗好多相容問題。
而家可以直接執行16bit、32bit、64bit嘅Windows版程式，Wayland整合方面搞掂咗剪貼簿同輸入法嘅支援，改善埋遊戲全螢幕獨佔模式嘅支援，支援更多遊戲手掣同其他週邊裝置，Windows版程式可以同藍牙裝置通訊，可以如常用到多功能Printer同埋掃描器嘅Scan功能，可以正常播放MIDI音樂，介面主題功能正常運作，改善咗MSHTML支援解決咗一啲奇怪設計安裝程式嘅相容問題(例如Adobe啲程式），可以透過Vulkan實現D3D11影片解碼。
而家就差Valve未整合Wine 11.0版嘅改動去出Proton 11.0版，不過最遲4月應該會出。

Wine11.0主要改動：
[WoW64]
• 最初在 Wine 9.0 中作為試驗性質功能所推出的全新 WoW64 模式現在已得到全面支援，而且該功能與舊版 WoW64 模式基本相同。
• 新的 WoW64 模式支援 16 位元應用程式。
• 可以透過設定變數來強制舊的 WoW64 安裝以新的 WoW64 模式運作WINEARCH=wow64。這要求前綴已建立為 64 位元（預設值）。
• 使用純 32 位元前綴建立的前綴WINEARCH=win32已被棄用，並且在新的 WoW64 模式下不受支援。
• wine64移除了載入器執行檔，取而代之的是一個能夠根據正在執行的執行檔選取正確模式的單一wine載入器。對於同時安裝了 32 位元和 64 位元版本的執行檔，預設使用 64 位元版本。然後可以透過明確路徑啟動 32 位元版本，例如wine c:\\windows\\syswow64\\notepad.exe

[同步/執行緒(線程)]
• 可用情況下，則會使用 NTSync Linux 核心模組來提高同步原語的效能。從 Linux 核心 6.14 版本開始，所需的核心模組已隨核心一起提供。
• 執行緒優先權變更在 Linux 和 macOS 上均已實作。在 Linux 上，執行緒優先權變更受系統 nice 值限制，目前發行版需要進行一些設定才能將 nice 值的硬性限制變更為負值（範圍在 -19 到 -1 之間，通常 -5 就足夠了，不建議使用較低的值）。man limits.conf(5)更多資訊請參閱相關檔案。
• 已實現 NTDLL 同步屏障。
• 在 macOS 系統中，%gs暫存器會在系統呼喚分工協調程式中進行交換。這樣可以避免 Windows TEB 和 macOS 執行緒描述符之間的衝突。

[核心]
• NT 重分析點已實現，支援掛載點和符號連結類型的重分析點。
• Write Watch 會利用 Linux 上的 userfaultfd（可用情況下），以避免在使用者空間處理分頁錯誤的開銷。
• NT 系統呼喚使用與最新 Windows 相同的系統呼喚編號，以支援硬編碼系統呼喚編號的應用程式。
• 在 ARM64 架構上，支援在較大的主機分頁（通常為 16K 或 64K）之上模擬 4K 分頁大小。這對於簡單的應用程式來說是可行的，但由於無法完全消除差異，因此對效能要求更高的應用程式可能無法正常運作。強烈建議使用 4K 分頁核心。

[圖形]
• 移除了 OSMesa 依賴項，並使用硬體加速的 OpenGL 執行組件實作了 OpenGL 點陣圖渲染。
• EGL OpenGL 後端已擴展，並且在 X11 平台上預設使用。 GLX 後端已被棄用，但仍可用，並在 EGL 不可用時用作備用方案。也可以透過設定登錄檔項 HKCU\Software\Wine\X11 Driver 的設定值 GLXUseEGL=N 來強制使用該後端。
• 已實作VK_KHR_external_memory_win32、VK_KHR_external_semaphore_win32、
VK_KHR_external_fence_win32、VK_KHR_win32_keyed_mutex擴充以及相關的 D3DKMT API。
• 在新的 WoW64 模式下，可用情況下，OpenGL 緩衝區將使用 Vulkan 擴充對應到 32 位元記憶體空間。
• 對於不支援原生 OpenGL 渲染的平台，會模擬前緩衝區 OpenGL 渲染。
• wglShareLists 中的 OpenGL 上下文共享實作得到了改進。
• 支援 Vulkan API 版本 1.4.335。
• WindowsCodecs 對影像元資料處理的支援較好。
• WindowsCodecs 支援更多不同像素格式之間的轉換。

[桌面整合]
• X11 視窗管理器整合已改進：視窗啟動請求被傳送到視窗管理器，並使用 EWMH 協議來保持 X11 和 Win32 活動視窗的一致性。
• 支援專屬全螢幕模式，並改進了 D3D 全螢幕模式，尤其改進了舊版 DDraw 遊戲。
• 試驗性質的 Wayland 驅動程式支援非標準形態和顏色匹配的視窗。
• 透過使用共用記憶體進行處理程序之間的通信，提高了幾個與視窗相關的功能的效能。
• Wayland驅動程式中實現了剪貼簿支援。
• Wayland驅動程式支援輸入法。

[Direct3D]
• 透過 Direct3D 11 視訊 API 對 H.264 視訊進行硬體解碼是基於 Vulkan 視訊(指令集)實現的。請注意，必須使用 Vulkan 渲染器。與先前的 Wine 版本一樣，可以透過(renderer = vulkan)設定登錄檔項Direct3D 或環境變數WINE_D3D_CONFIG 來啟用Vulkan渲染器。
• GL_ARB_texture_filter_minmax（使用 GL 渲染器時）或VK_EXT_sampler_filter_minmax（使用 Vulkan 渲染器時）可用情況下，則會實作 Direct3D 11 取樣器最小/最大縮減過濾。
• 以下傳統 Direct3D 功能已在 Vulkan 渲染器中實現：
  °控制筆畫大小。
  °點狀精靈控制。
  °頂點混合。
  °固定功能凹凸貼圖。
  °抽屜中的顏色標記。
  °平面著色。
  °Alpha 測試。
  °使用者裁剪平面。
  °多種資源格式。
• 此外，捆綁的 vkd3d-shader 版本對 Shader Model 1、2 和 3 著色器進行了多項改進，尤其值得一提的是支援 Shader Model 1 像素著色器和基本的 Shader Model 1 紋理。 Vulkan 渲染器尚未達到 GL 渲染器的水準，因此目前還不是預設渲染器。

[Direct3D 輔助庫]
• D3DXSaveSurfaceToFileInMemory已重新實現對 PNG、JPEG 和 BMP 檔案的支援，從而能夠支援 WindowsCodecs 不支援的格式和其他特殊情況。它還支援將表面儲存為 TARGA 檔案。
• D3DX 11 紋理載入功能已實現，使用與早期 D3DX 版本共用的程式碼。
• 所有版本均支援框選過濾。
• D3DXSaveTextureToFileInMemory支援將紋理儲存為 DDS 檔案。
• D3DX 9 支援讀取 1 位元、2 位元和 4 位元索引像素格式，以及 CxV8U8 格式。
• D3DX 10 和 11 支援壓縮和解壓縮 BC4 和 BC5 格式。
• D3DX 10 和 11 支援在載入紋理時產生 mipmap 等級。
• ID3DXEffect::SetRawValue()已部分實現。
• ID3DXSkinInfo::UpdateSkinnedMesh()已實施。

[輸入/HID裝置]
• 透過後端改進，可與更多遊戲手把(手掣)裝置相容hidraw。
使用者可以按廠商和裝置登錄選項，選擇性地加入 Hidraw 後端。
• 力度回饋支援得到改進，對操縱桿和方向盤的相容性增強，效能更佳。
• 在 Windows.Gaming.Input API 和 evdev 後端中，當 SDL 不可用或已停用時，更好地支援遊戲手把(手掣)。
• 遊戲控制器的控制台小程式中有一個用於設定 Windows.Gaming.Input API 的標籤。
• DirectInput 與使用動作對應和裝置語義的舊遊戲的相容性得到提升。
• 實作了來自 Windows.Devices.Enumeration 和 cfgmgr32 的更多裝置枚舉 API。

[藍牙]
• 藍牙驅動程式支援掃描和配置主機裝置發現功能，並提供透過 API 和配對精靈的基本支援。目前，此功能僅支援安裝了 BlueZ 的 Linux 系統。
• Windows 應用程式可以識別藍牙無線電和裝置（包括經典型和低功耗型）。
• 應用程式可以使用 winsock API 與遠端裝置建立底層 RFCOMM 連線。
• 初步支援藍牙低功耗 (BLE) 通用屬性設定檔 (GATT) 服務和特徵，使其可透過 Win32 BLE API 可見。

[掃描器支援]
• 已支援DAT_IMAGENATIVEXFER。
• 掃描器的選擇和配置儲存在登錄檔中。
• 實作了用於掃描的 TWAIN 2.0 API，這使得掃描功能可以在 64 位元應用程式中如常運行。
• 支援多頁掃描和自動送稿掃描。
• 使用者介面會顯示掃描進度和錯誤訊息。
• 掃描器使用者介面不再阻止使用該掃描器的應用程式運作。
• 如果已在 Wine 中安裝 Windows 原生掃描器驅動程式，則可以載入這些驅動程式。

[多媒體]
• 多媒體串流庫為 DirectDraw 串流實作了自訂分配器，從而減少了支援下游自訂分配器的篩選器所需的緩衝區副本數量。
• DMO Wrapper、AVI Decoder 和基於 GStreamer 的解復用器和轉換過濾器均支援動態格式變更。
• 基於 GStreamer 的解復用器過濾器支援 Indeo 5.0 編解碼器。
• DirectSound Renderer 濾波器能夠更準確地發出流結束訊號。先前，串流結束訊號可能發出過早，導致音訊串流結尾被截斷。
• ASF Reader 過濾器支援搜尋功能。
• AVI解碼器過濾器支援非常規的來源矩形和目標矩形。

[DirectMusic]
• SoundFont(SF2)支援更多功能：
  °解析預設、樂器和預設調製器。
  °許多SF2樂器需要分層支援。
  °重複使用已下載的波形和零複製存取採樣資料，以防止記憶體不足錯誤。
  °樂器歸一化。
• 合成器效能提升：
  °延遲時鐘源自主時鐘，用於修復某些曲目播放不均勻的問題。
  °語音關閉是即時的，合成器能夠更好地處理通道壓力事件和 LFO 連接。
  °支援設定音量，並且在建立合成器或新增連接埠時會自動完成。
• 支援 DX7 版本的樣式表單。
• 改進了載入器中的快取管理。

[Mono / .NET / WinRT]
• XNA4 應用程式基於 SDL3 運行，預設使用新的 SDL_GPU API 進行渲染。
• WPF（Windows Presentation Framework）新增了一個支援 System.Windows.Documents API 的文字佈局引擎。
• 主題功能可在 Windows Forms 中使用。
• WinRT 元資料檔案可以透過以下方式生成widl，並且載入器類別有一個初始實作。

[國際化]
• 區域設定資料由Unicode CLDR資料庫版本48所產生。
支援以下附加區域設定：
bqi-IR、bua-RU、cop-EG、ht-HT、kek-GT、lzz-TR、mww-Hmnp-US、oka-CA、pi-Latn-GB、pms-IT、sgs-LT、suz-Deva-NP 以及 suz-Sunu-NP
• Unicode 字元表基於 Unicode 標準 17.0.0 版本。
• 時區資料是基於 IANA 時區資料庫的 2025a 版本。

[網際網路及網路]
• MSHTML 以符合標準的模式將 DOM 屬性公開為正確的 DOM 節點。
• 支援 JavaScript 類型化數組。
• MSHTML 物件 DOMParser、XDomainRequest 和 msCrypto 已實作。
• Ping 功能是為 ICMPv6 實現的。

[資料庫]
• MSADO支援向資料庫寫入變更。
• MSADO Recordset 的大部分功能已實現。
• ODBC 將 Unicode 字串重新對應，以支援僅支援 ANSI 的 Win32 驅動程式。

[偵錯]
• DbgHelp 中的 PDB 檔案載入器已重新實現，以支援大檔案（> 4G）、更快的載入速度和更少的記憶體資源。
• 可以使用 NT 系統呼喚進行追蹤WINEDEBUG=syscall。
與 WINEDEBUG=relay 不同，這對應用程式是透明的，並且避免破壞那些鉤住系統呼喚入口點的應用程式。
• 在一次建置過程中，可以同時產生 DWARF 和 PDB 偵錯資訊。

[內建應用程式]
• WineCfg 的音訊選項頁允許配置預設 MIDI 裝置。
• 命令提示字元工具cmd可以使用 和 建立重新解析點mklink /j，並在目錄清單中顯示它們。
• 命令提示字元工具cmd支援更複雜的指令，並且在互動式提示字元中支援檔案名稱自動補全。
• 主控台主機應用程式conhost支援使用 F1 和 F3 鍵擷取歷史記錄。
• timeout應用程式已實現。
• find此工具支援選項/c（顯示相符的計數）和/i（不區分大小寫的相符）。
• whoami此工具支援輸出格式指定符。
• subst該指令有一個基本實現。
• 已有初步實現runas工具。

[雜項]
• Common Controls 版本 5 和版本 6 是完全獨立的 DLL，為了更好地相容，v6 特有的功能已從 v5 DLL 中移除。
• BCrypt 支援 PBKDF2 金鑰衍生演算法。
• 支援常用的 shell 資料夾User、ProgramFiles、AccountPictures以及Screenshots。

[開發工具]
• IDL 編譯器可以使用 --winmd 這個選項 去產生 Windows 執行組件元資料檔案(.winmd)。
• winedump此工具支援傾印 MUI 資源、系統呼喚號碼、嵌入式 NE 模組和大型 PDB 檔案（>4G）。
• wine/unixlib.h此頭檔案已作為開發包的一部份安裝，這是支援第三方模組使用 Unixlib 介面的第一步。這項工作仍在進行中。

[建置基礎]
• 基於 X11 的install-sh腳本已用 C 語言重新實現，從而可以在一次程式呼喚中安裝多個檔案。這使得檔案複製階段的速度提高了make install一個數量級。
• 使用 Clang 為 64 位元 MSVC 目標建置時，編譯器異常會用於實作__try/__except程式碼區塊。
• WineHQ Gitlab CI 支援 ARM64 建置。

[捆綁的程式庫]
• 已捆綁LLVM Compiler-RT 執行組件程式庫8.0.1版本，並在以 MSVC 模式建置模組時使用。
• TomCrypt 函式庫版本 1.18.2 已捆綁並用於在 RsaEnh 和 BCrypt 模組中實作加密原語。
• Vkd3d 已更新至上游版本1.18。
• Faudio 已更新至上游版本 25.12。
• FluidSynth 已更新至上游版本 2.4.2。
• LCMS2 已更新至上游版本 2.17。
• LibMPG123 已更新至上游版本 1.33.0。
• LibPng 已更新至上游版本 1.6.51。
• LibTiff 已更新至上游版本 4.7.1。
• LibXml2 已更新至上游版本 2.12.10。
• LibXslt 已更新至上游版本 1.1.43。

[外部依賴項]
• 已不再使用OSMesa函式庫。 改用EGL實作OpenGL點陣渲染。
• HwLoc 函式庫用於 FreeBSD 上的 CPU 偵測。

詳情：https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0

cdlp

回覆 998# Okt04175


    我用非G-Sync的4K 120Hz電視玩Portal 2，畫面設定設為1080p 120Hz，R5 2600+ 3060ti配置運行這款遊戲相當流暢。

在半小時的遊戲過程中，只有一次幀數低於120fps。

這台電腦上的Portal 2運作流暢度堪比Steam Deck OLED，90fps，刷新率90Hz，解析度800p。

為了提升動態清晰度，我將幀數上限設為120fps，並開啟了120Hz BFI功能。

Portal 2的3D動態畫面在開啟快速同步之前會出現撕裂線，開啟後撕裂線完全消失。

無論我在BIOS裡如何調整設置，GPU-Z都只顯示PCIe x2，但正確的應該是x16。

可能是 PCIe 延長線限制了頻寬，我已經更新了 AM4 BIOS，安裝了主機板晶片組驅動和顯示卡驅動，

但問題依舊。

PCIe x2 的頻寬對 3060ti 來說夠用嗎？

Okt04175

回覆 999# cdlp
越早期推出嘅遊戲就越依賴CPU嘅單核心效能/IPC，越後期推出嘅遊戲喺多核心CPU最佳化方面做得越好。
遊戲嘅最佳化做得唔好，就需要靠硬體規格去撐住。

PCI-E x2嘅頻寬喺打機用途嚟講係唔夠嘅，就算PCI-E行緊4.0模式最起碼都要x4嘅頻寬先夠用，如果行PCI-E 3.0模式嘅話就要上到x8先至夠用。
你最好搵過一條好啲嘅PCI-E延長線，呢種延長線平嘢冇好嘢。