跳至內容

Intel 圖形處理器

出自 Arch Linux 中文维基

由於 Intel 提供並維護開源驅動程序,因此 Intel 顯卡基本上是即插即用的。

有關 Intel GPU 型號以及相應晶片組和 CPU 的全面列表,請參閱 Wikipedia:list of Intel graphics processing unitsGentoo:Intel#Feature support

注意:
  • 開源驅動不支持基於 PowerVR 架構的圖形卡 (比如GMA 3600 系列)
  • Intel 第 N 代硬體不代表 CPU 的代數,它表示不同於 CPU 代數的 GPU 的代數
  • 參見 Xorg#驅動安裝 來識別你的顯卡

安裝[編輯 | 編輯原始碼]

  • 安裝以下任一軟體包,它提供用於 3D 加速的 DRI 驅動程序。
    • mesa 是最新的 Mesa 軟體包,其中包括用於 Intel 第 3 代及更高版本硬體的現代 Gallium3D 驅動程序。這是推薦選擇。
    • mesa-amber 是舊版 Mesa 軟體包,包括用於第 2 代至第 11 代硬體的經典(非 Gallium3D)驅動程序。此驅動程序對於第 7 代和較舊的硬體具有更好的性能和穩定性,但是不再維護。
  • 對於 DDX 驅動支持(可提供對 Xorg 的 2D 加速),安裝以下任一軟體包:
    • 包含在 xorg-server 軟體包內的 modesetting 驅動是對於第 4 代及以上硬體的推薦選擇。它通過 glamor 使用 DRI 來實現加速。
    • xf86-video-intel 軟體包為第 2 代至第 9 代硬體提供了舊的 Intel DDX 驅動。通常不建議使用此軟體包,請參見下面的注釋。

另請參見硬體視頻加速.

注意:

加載[編輯 | 編輯原始碼]

Intel 內核模塊應會在系統引導時自動加載。

如果它沒有自動加載,請嘗試:

  • 由於 Intel 需要內核模式設置,確保您沒有內核參數中添加 nomodeset
  • 請同時確認您沒有在 /etc/modprobe.d//usr/lib/modprobe.d/ 中把 Intel 列入 modprobe 的黑名單導致禁用了 Intel。

啟用 KMS 早啟動[編輯 | 編輯原始碼]

i915 驅動支持內核級顯示模式設置 (KMS),並且從 mkinitcpio v32 開始啟用,因為 kms 鉤子被默認包含。對於其他配置方式,請參考 Kernel_mode_setting#KMS_早啟動獲得有關如何在啟動過程中第一時間啟用KMS的說明。

啟用 GuC / HuC 固件加載[編輯 | 編輯原始碼]

本文或本章節的事實準確性存在爭議。

原因: 儘管 Intel 的文檔沒有說,但是 Tiger Lake 和 Rocket Lake GPU 可能實際上支持 enable_guc=3, 並且默認設置了 enable_guc=1.(在 Talk:Intel graphics#TGL/RKL GuC Submission 中討論)


從第 9 代硬體 (Skylake 及以後的架構) 開始, Intel GPU 都包含了一個用於提供以下功能的圖形微控制器 「Graphics micro (μ) Controller」 (GuC) [6]:

  • 安裝 intel-media-driver 軟體包來啟用硬體視頻加速後,能夠把一些多媒體解碼功能從 CPU 分載(offload)到 HEVC/H.265 微控制器 (micro (µ) Controller) (HuC) 上。該功能於第 9 代推出。
  • 使用 GuC 進行調度、上下文提交(context submission)和電源管理。該功能通過第 12 代硬體於 Alder Lake-P(移動端)推出。

為了使用這些功能,您必須加載 GuC 固件。對於 HuC 支持,一些視頻特性(如 SKL 低功耗編碼模式下的 CBR 速率控制)也需要加載 HuC 固件才能實現。 [7] GuC 和 HuC 的固件文件都包含在 linux-firmware 軟體包中。

GuC 功能由 i915.enable_guc 內核參數控制,用法如下:

enable_guc 的值 GuC Submission HuC Firmware Loading 作為平台默認值 支持的平台
0 Tiger Lake, Rocket Lake, 和 Pre-Gen12 [8] All
1 Alder Lake-P (Mobile) 及更新
2 Alder Lake-S (Desktop) [9] [10] Gen9 及更新
3 Alder Lake-P (Mobile) 及更新 第 9.5 代或更新(某些程度上更好)

如果 GuC submission 或者 HuC 固件加載並未在您的 GPU 上默認啟用,您可以手動啟用它。

警告:即使您的顯卡不支持相關功能,手動啟用 GuC/HuC 固件加載也可能會污染內核。此外,啟用GuC/HuC固件加載可能會導致某些系統出現問題;如果您遇到凍結(例如,從休眠恢復後),請禁用它。

首先確保您已經安裝linux-firmware 軟體包。

配置 i915.enable_guc 內核參數,比如:

/etc/modprobe.d/i915.conf
options i915 enable_guc=2

然後重建 initramfs,在下一次啟動時您可以通過 dmesg 命令來確認 GuC 和 HuC 都已被啟用。

# dmesg
[30130.586970] i915 0000:00:02.0: [drm] GuC firmware i915/icl_guc_33.0.0.bin version 33.0 submission:disabled
[30130.586973] i915 0000:00:02.0: [drm] HuC firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes

如果您的顯卡不支持它們,你會看到:

# dmesg
[    0.571339] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - GuC is not supported!
[    0.571340] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - HuC is not supported!

或者,使用以下方法進行檢查:

# cat /sys/kernel/debug/dri/0/gt/uc/guc_info
# cat /sys/kernel/debug/dri/0/gt/uc/huc_info
注意:從 Linux 4.20.11 起,當 GuC/HuC 被啟用時,不支持通過設置 enable_gvt=1 來使用 GVT-g 圖形虛擬化 功能。i915模塊將無法初始化,如系統日誌所示:
# journalctl
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)
... kernel: i915: probe of 0000:00:02.0 failed with error -5
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)

請注意相關警告並非致命,正如[11] 中解釋的那樣:

# journalctl -b 
... kernel: i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x5916_rid_0x02.golden_hw_state failed with error -2

Xorg 配置[編輯 | 編輯原始碼]

通常不需要為了運行 Xorg 去配置任何東西。

但是如果需要使用一些驅動選項或是 Xorg 未正常啟動,您可以創建一個 Xorg 配置文件。

使用 modesetting 驅動[編輯 | 編輯原始碼]

如果您已經安裝了 xf86-video-intel 軟體包但是想要顯式加載 modesetting 驅動而不是讓 DDX 驅動有著更高的優先級,比如試著去比較它們:

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
  Identifier "Intel Graphics"
  Driver "modesetting"
EndSection

使用 Intel 驅動[編輯 | 編輯原始碼]

注意:以下操作需要安裝 xf86-video-intel 軟體包。

創建一個與下述類似的 Xorg 配置文件:

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
EndSection

您可以在 Driver "intel" 下方開新行添加額外的選項。請參考 intel(4) 手冊頁以獲得完整的選項列表。

注意:您可能需要添加不止一段 device 配置,本文將在需要的地方指出。

AccelMethod[編輯 | 編輯原始碼]

創建配置文件時,您可能需要指定 Option "AccelMethod" 。傳統的選項包括 UXA, SNA (默認) 和 BLT.

如果您在使用默認選項 SNA 時遇到問題 (比如花屏、文字損壞等),嘗試改用UXA 。只需要在配置文件中添加如下一行即可:

Option      "AccelMethod"  "uxa"

另請參閱 intel(4) § CONFIGURATION DETAILS 手冊文件中的 AccelMethod 選項。

對於較新的 GPU 使用 Intel DDX 驅動[編輯 | 編輯原始碼]

從第 8 代 Intel GPU 開始(Broadwell),需要 Iris Mesa 驅動:

Option      "DRI"  "iris"

禁用 TearFree,TripleBuffer,SwapbuffersWait[編輯 | 編輯原始碼]

如果你在使用組合器(在比如 GNOME,KDE Plasma,Xfce 等現代桌面環境中是默認的),那麼 TearFree,TripleBuffer 和 SwapbuffersWait 通常可以禁用以提高性能和省電。

Option      "TearFree"        "false"
Option      "TripleBuffer"    "false"
Option      "SwapbuffersWait" "false"

基於內核模塊參數的選項[編輯 | 編輯原始碼]

i915 內核模塊允許您通過內核模塊參數來配置選項。其中一些選項會影響到省電。

您可以使用以下命令生成所有選項的列表以及簡短說明和默認值:

$ modinfo -p i915

若要檢查當前啟用了哪些選項,請運行

# systool -m i915 -av

您將注意到,許多選項默認為 -1,說明晶片的省電狀態都為默認值。然而,您可以通過修改內核模塊參數來配置更積極的省電策略。

注意:Diverting from the defaults will mark the kernel as tainted from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers.

Framebuffer 壓縮 (enable_fbc)[編輯 | 編輯原始碼]

啟用 Framebuffer 壓縮 (FBC) 功能能夠減少電源消耗,同時減少刷新屏幕所需的內存帶寬。

如果您的硬體支持,此功能將被自動啟用。您可以通過該命令來檢查是否啟用:

$ modinfo i915 | grep enable_fbc
parm:           enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int)

如果 parm 被設為 -1,那您不需要做任何事。如果在其他情況下要強制啟用 FBC,請在內核參數中添加 i915.enable_fbc=1 或在 /etc/modprobe.d/i915.conf 中進行如下配置:

/etc/modprobe.d/i915.conf
options i915 enable_fbc=1
注意:在 Sandy Bridge (第6代)之前的幾代 Intel GPU 上,幀緩衝(Framebuffer)壓縮可能不可靠或不可用。 這導致系統日誌中可能會記錄類似如下信息:
kernel: drm: not enough stolen space for compressed buffer, disabling.

在Sandy Bridge之前的CPU上啟用幀緩衝區壓縮會導致無休止的錯誤消息:

# dmesg
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this
解決方案是禁用幀緩衝壓縮,這將增加些微功耗(約0.06W)。為了禁用它,請在內核參數中添加i915.enable_fbc=0 。 請參閱此處 了解更多關于禁用幀緩衝的影響。

Fastboot[編輯 | 編輯原始碼]

注意:Skylake 和更新的架構,會在默認情況下啟用此參數[12]。以及 Bay- 和 Cherry-Trail (VLV/CHV)[13] 自 Linux 5.1 版本以來也會啟用。[14]

Intel Fastboot 的目標是在 Xorg 啟動之前將幀緩衝區保留為 BIOS 或引導加載程序設置的內容,以避免出現屏閃。[15][16]

要在未默認啟用快速啟動的平台上強制啟用快速啟動,請設置 i915.fastboot=1 內核參數,或在 /etc/modprobe.d/i915.conf 裡作如下設置:

/etc/modprobe.d/i915.conf
options i915 fastboot=1

Intel GVT-g 圖形虛擬化支持[編輯 | 編輯原始碼]

請參考 Intel GVT-g 以了解詳細信息。

啟用性能支持[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因:What does Mesa actually do using the performance counters? What's the effect of this? Some report drastic performance increases on Intel Tiger Lake, attributing it to a support for Dynamic Tuning [17]. (在 Talk:Intel 圖形處理器#Potential performance gains via Observation Architecture 中討論)

從第六代處理器 (Sandy Bridge 及更新的架構) 開始,Intel GPU 提供性能計數器,用於向驅動程序提供內部性能數據。 驅動程序和硬體寄存器將此基礎結構稱為 Observation Architecture (內部稱為 "OA") [18],但英特爾的文檔一般普遍將此功能稱為 提供可觀測性能計數器(Observability Performance Counters)[19] [20].

默認情況下,只有使用 CAP_SYS_ADMIN(相當於root)或 CAP_PERFMON 能力(Capabilities)運行的程序才能使用 OA​ [21] [22]。 大多數應用程式將在沒有這兩種情況下運行,從而導致以下警告:

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

若要在不使用能力(或 root)的情況下啟用性能支持,請按 sysctl 中的描述設置內核參數。

警告:perf_event_paranoid 系列選項默認為限制訪問,因為允許應用程式訪問性能數據存在風險 [23]。話雖如此, dev.i915.perf_stream_paranoid 只會影響對 GPU 性能計數器的訪問,這比訪問 CPU 架構執行上下文寄存器之類的帶來的風險要小。

技巧和竅門[編輯 | 編輯原始碼]

設置縮放模式[編輯 | 編輯原始碼]

這對於某些全屏應用程式很有用:

$ xrandr --output LVDS1 --set PANEL_FITTING param

其中 param 可以為:

  • center: 解析度將完全保持原設置,不會進行縮放
  • full: 縮放解析度,以便使用整個屏幕
  • full_aspect: 將解析度縮放到可能的最大值,但保持縱橫比。

如果它不起作用,請嘗試:

$ xrandr --output LVDS1 --set "scaling mode" param

其中 param 可以為 "Full""Center""Full aspect"

注意:此選項目前不適用於外接顯示器 (比如 VGA, DVI, HDMI, DP). [24]

GMA 4500上的硬體加速 H.264 解碼[編輯 | 編輯原始碼]

對於某些 GMA 4500 系列的 GPU,libva-intel-driver 軟體包只提供對 MPEG-2 解碼的硬體加速,而並不包括 H.264 解碼。要檢查這是否對您的 GPU 有影響,請同時安裝驅動和 libva-utils 軟體包,並檢查 vainfo 命令的輸出結果中是否包含以 VAProfileH264 開頭的項目。

對於 H.264 的解碼支持是在另一個 g45-h264 分支中獨立維護的。您可以安裝 libva-intel-driver-g45-h264AUR 軟體包來使用它。然而,要注意該支持是實驗性的,並且其開發工作已被放棄。在GMA 4500系列GPU上使用VA-API與此驅動程序能夠幫助 CPU 分載(offload),但可能無法實現像非硬體加速那樣平滑的播放。使用 mplayer 進行的測試表明,使用 vaapi 播放 H.264編碼的1080p 視頻可以將 CPU 負載減半(與 XV overlay相比) ,但是播放非常卡頓,而720p 播放效果相當不錯 [25]。這與其他人的經歷相印證 [26]。在 BIOS 中將預先分配的視頻內存大小設置得更高,可以獲得更好的硬體解碼播放效果。這樣做了之後即使是1080p h264視頻也可以流暢播放[27]。同時使用 mpv-gitAURffmpeg-gitAURlibva-intel-driver-g45-h264AUR 也可以流暢播放(1080p/720p)視頻。通過 MPV 和 Firefox 插件「發送到 MPV 播放器」[28] ,可以觀看硬體加速的 YouTube 視頻。

覆寫報告的 OpenGL 版本[編輯 | 編輯原始碼]

MESA_GL_VERSION_OVERRIDE 環境變量可以為任何應用程式覆寫報告的 OpenGL 版本。比如,設置 MESA_GL_VERSION_OVERRIDE=4.5 環境變量將會把 OpenGL 版本報告為 4.5.

注意:您可以使用此變量報告任何已知的 OpenGL 版本,即使 GPU 不支持它。一些應用程式可能不再崩潰,而一些可能反而開始崩潰。所以您可能不希望全局設置這個變量。

監控[編輯 | 編輯原始碼]

本文或本章節可能需要合併到Hardware video acceleration#Verification

附註: This overlaps the content at the previously linked page and would probably be a better fit in a generic page instead of this one dedicated to Intel GPUs. Otherwise, Hardware video acceleration#Verification should be modified to link to each dedicated page instead of duplicating content.(在 Talk:Intel 圖形處理器 中討論)
  • intel_gpu_top — 適用於 Intel GPU 的類似 top 命令的任務監視器。 (需要 root 權限)
https://gitlab.freedesktop.org/drm/igt-gpu-tools || intel-gpu-tools
  • nvtop — 適用於 AMD、Intel 和 NVIDIA 的 GPU 進程監視器(目前對 Intel GPU 僅有非常基礎的支持)
https://github.com/Syllo/nvtop || nvtop

設置亮度和伽瑪值[編輯 | 編輯原始碼]

參見背光

測試新的實驗性 Xe 驅動[編輯 | 編輯原始碼]

為了嘗試(實驗性的)新的 Xe 驅動,你需要:

  • linux 6.8 或更高版本
  • Tiger Lake 或更新的集成顯卡,或者獨立顯卡
  • 官方源的 mesa 軟體包。或者保證 mesa 使用 -D intel-xe-kmd=enabled 進行編譯

運行此命令,然後記錄下您的 PCI ID:

lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01)

然後將帶有合適 PCI ID 的以下內容添加到內核參數裡:

... i915.force_probe=!9a49 xe.force_probe=9a49

確保您有在需要時可以撤銷變更的備用啟動方案。

故障排除[編輯 | 編輯原始碼]

畫面撕裂[編輯 | 編輯原始碼]

使用了 Intel 驅動[編輯 | 編輯原始碼]

SNA 加速方法在一些機器上引起撕裂。要解決這個問題,請在驅動程序中啟用 TearFree 選項,方法是在配置文件中添加以下內容:

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "TearFree" "true"
EndSection

參見原始錯誤報告以獲得更多信息。

注意:
  • SwapbuffersWaitfalse 時,該選項可能不工作
  • 此選項可能會顯著增加內存分配並降低性能。[29]
  • 對於對vsync定時非常挑剔的應用程式來說,這個選項是有問題的,比如 Super Meat Boy.
  • 此選項不適用於UXA加速方法,僅適用於SNA。
  • 對於 Intel UHD 620 或 630 顯卡,您需要添加 Option "TripleBuffer" "true" 選項才能使 TearFree 工作。
  • 通過添加 Option "DRI" "2" 來禁用 DRI3 可能是必須的,不然任意全屏應用(比如視頻播放)會使 TearFree 失效。[30]

使用了 modesetting 驅動[編輯 | 編輯原始碼]

modesetting 驅動在最近才支持 TearFree [31][32]。直到 2023 年 11 月,這個補丁還沒有進入穩定版,所以現在你會需要 xorg-server-gitAUR

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
  Identifier "Intel Graphics"
  Driver "modesetting"
  Option "TearFree" "true"
EndSection

禁用垂直同步 (VSYNC)[編輯 | 編輯原始碼]

適用於以下情景:

  • 由於 GPU 的原因,Chomium/Chrome 有滯後和性能低下的問題,而在使用 --disable-gpu 選項啟動時能流暢運行。
  • glxgears 測試未顯示預期性能

Intel 驅動程序使用三重緩衝進行垂直同步;這允許充分的性能釋放並避免畫面撕裂。若要關閉垂直同步(例如用於基準測試),請在主目錄中使用如下 .drirc 文件:

~/.drirc
<device screen="0" driver="dri2">
	<application name="Default">
		<option name="vblank_mode" value="0"/>
	</application>
</device>
注意:不要使用 driconfAUR 來創建此文件。它有問題,會設置錯誤的驅動程序。

DRI3 問題[編輯 | 編輯原始碼]

DRI3xf86-video-intel 中的默認 DRI 版本。在某些系統上,這可能會導致這樣的問題。要切換回 DRI2,請在配置文件中添加以下行:

Option "DRI" "2"

對於 modesetting 驅動程序,這種禁用 DRI3 的方法不起作用。所以我們可以設置環境變量 LIBGL_DRI3_DISABLE=1

GTK應用程式中的字體和屏顯損壞(掛起/恢復後缺少字形)[編輯 | 編輯原始碼]

如果您在 GTK 應用程式中遇到缺少字形的問題,以下解決方法可能會有所幫助。編輯 /etc/environment 並添加以下行:

/etc/environment
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer

另請參考 FreeDesktop bug 88584.

啟動過程中加載模塊時顯示空白屏幕[編輯 | 編輯原始碼]

這一章節正在考慮移除。

原因:mkinitcpio v32 開始,kms 鉤子被默認包含,因此大部分配置會默認啟動早啟動。 (在 Talk:Intel 圖形處理器 討論)


如果您使用 KMS 晚啟動,然後屏幕在加載模塊(Loading modules)時顯示為空白,您可以試著把 i915intel_agp 添加到 initramfs 中。請參考內核級顯示模式設置#KMS_早啟動

另外,附加以下內核參數似乎也有效:

video=SVIDEO-1:d

如果您需要輸出到VGA,請嘗試以下操作:

video=VGA-1:1280x800

X 窗口系統在使用 Intel 驅動程序時凍結或崩潰[編輯 | 編輯原始碼]

一些關於 X 窗口系統崩潰、凍結或 GPU 掛起的問題,可以通過設置 NoAccel 選項禁用 GPU 來解決。請在配置文件中添加以下內容:

  Option "NoAccel" "True"

或者,嘗試通過設置 DRI 選項來只禁用 3D 加速:

  Option "DRI" "False"

添加未檢測到的解析度[編輯 | 編輯原始碼]

這個問題在 Xrandr 頁面中有詳細的說明。

無法調節背光[編輯 | 編輯原始碼]

如果您的設備從掛起中恢復後,調整屏幕背光亮度的熱鍵失效,請根據 Backlight 一文檢查您的配置。

如果問題仍然存在,請嘗試如下任一內核參數:

acpi_osi=Linux
acpi_osi="!Windows 2012"
acpi_osi=

還要確保您沒有使用 fastboot 模式 (i915.fastboot 內核參數) ,因為它會破壞背光控制

Chromium 和 Firefox 損壞或無響應[編輯 | 編輯原始碼]

如果您在 Chromium 和/或 Firefox 中遇到了損壞、無響應、性能滯後或緩慢的問題,一些可能的解決方案包括:

4.0+ 版本的內核會在使用 Broadwell 或 Core-M 晶片時崩潰[編輯 | 編輯原始碼]

X/Wayland 加載後幾秒鐘,機器將凍結,journalctl 將記錄內核崩潰並提到 Intel 顯卡:

Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
Jun 16 17:54:03 hostname kernel: IP: [<          (null)>]           (null)
...
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G     U     O    4.0.5-1-ARCH #1
...
Jun 16 17:54:03 hostname kernel: Call Trace:
Jun 16 17:54:03 hostname kernel:  [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0
Jun 16 17:54:03 hostname kernel:  [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]
Jun 16 17:54:03 hostname kernel:  [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]
Jun 16 17:54:03 hostname kernel:  [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200
Jun 16 17:54:03 hostname kernel:  [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0
Jun 16 17:54:03 hostname kernel:  [<ffffffff811f6452>] ? __fget+0x72/0xb0
Jun 16 17:54:03 hostname kernel:  [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0
Jun 16 17:54:03 hostname kernel:  [<ffffffff8157a589>] system_call_fastpath+0x12/0x17
Jun 16 17:54:03 hostname kernel: Code:  Bad RIP value.
Jun 16 17:54:03 hostname kernel: RIP  [<          (null)>]           (null)

這可以通過禁用 execlist 支持來解決,該支持在 4.0 內核中被設為為默認值。添加以下內核參數

i915.enable_execlists=0

目前已知該問題直到 4.0.5 內核上仍存在。

Windows 客戶機運行遲緩[編輯 | 編輯原始碼]

VirtualBox 中 Windows 客戶機的視頻輸出有時會掛起,直到主機強制屏幕更新(例如移動滑鼠光標)。刪除 enable_fbc=1 選項可以解決這個問題。

屏幕閃爍[編輯 | 編輯原始碼]

面板自刷新 (PSR), 一種 Intel iGPU (核顯)使用的節能技術已知在某些情況下會導致閃爍 FS#49628 FS#49371 FS#50605. 臨時的解決辦法是通過設置 i915.enable_psr=0 內核參數來禁用該功能。

在 i915 驅動上使用 OpenGL 2.1[編輯 | 編輯原始碼]

正如這篇文章所說,把 mesa 從 13.x 版本更新到 17 可能會導致第三代 Intel GPU (如GMA3100,參閱這裡)上的 OpenGL 2.1 支持失效,並使其降級到 OpenGL 1.4。然而您可以通過配置 /etc/drirc~/.drirc 文件中的選項來手動恢復它:

/etc/drirc
<driconf>
...
    <device driver="i915">
        <application name="Default">
            <option name="stub_occlusion_query" value="true" />
            <option name="fragment_shader" value="true" />
        </application>
    </device>
...
</driconf>
注意:
  • 作出該讓步的原因是 Chromium 和其他應用程式的糟糕體驗。如果有需要,您可以參考 此文 來對 drirc 文件作特定於應用程式的修改,比如專門針對 Chromium 禁用 gl2.1。
  • 新的包含在 mesa 軟體包內的基於 Gallium 的 i915 驅動會一直報告 OpenGL 2.1,所以這些設置對於那個驅動來說不再需要了。

KMS 問題:終端只在很小的一塊區域中顯示[編輯 | 編輯原始碼]

其中一個低解析度視頻埠會在引導時啟用,這將導致終端僅能使用屏幕的一小塊區域。 要修復這個問題,在引導加載程序的內核命令行參數中,使用 i915 模塊參數 video=SVIDEO-1:d 來明確禁用該埠。有關詳細信息,請參閱內核參數

如果這不起作用,請嘗試禁用 TV1 或 VGA1,而不是 SVIDEO-1。視頻埠名稱可以用 xrandr 列出。

Haswell CPU 使用 HDMI 輸出時沒有聲音[編輯 | 編輯原始碼]

根據一個 Linux 內核問題,在設置 intel_iommu=on 參數時聲音不會通過 HDMI 埠輸出。要修復該問題,使用如下內核參數

intel_iommu=on,igfx_off

或者也可以禁用 IOMMU:

intel_iommu=off

低功耗 Intel CPU 會崩潰或凍結[編輯 | 編輯原始碼]

本文或本章節的事實準確性存在爭議。

原因: 在額外的聲明裡提到,enable_dc=0 可能不會影響到電源管理(在 Intel graphics#Incorrect statements regarding power usage penalty of enable_dc=0 中討論)


由於低功耗 Intel CPU 上電源管理功能的問題,低功耗 Intel 處理器和/或筆記本電腦處理器有隨機掛起或崩潰的傾向。如果發生此類崩潰,您將看不到任何報告此問題的日誌。添加以下內核參數可能有助於解決問題。

注意:不建議同時使用以下三個內核參數
intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1

ahci.mobile_lpm_policy=1 能修復部分聯想筆記本電腦和一些宏碁筆記本電腦因 SATA 控制器電源管理問題而出現的掛起故障。該解決方法嚴格來說與 Intel 顯卡無關,但它確實解決了相關問題。添加此內核參數可以將鏈路電源管理(LPM)從固件默認值修改為最大性能,並且還可以解決當您在某些聯想機器上更改顯示器亮度時出現的掛起問題。但這麼做在現代超級本上會增加 1 至 1.5 W 的閒置功耗。有關更多信息,特別是有關其他狀態的信息,請參閱 Linux內核郵件列表Red Hat 文檔

i915.enable_dc=0 會禁用GPU電源管理。這確實解決了某些 Intel 系統上的隨機掛起問題,特別是 Goldmount 和 Kaby Lake Refresh 晶片。但使用此參數會提高筆記本電腦的功耗並縮短電池壽命。

intel_idle.max_cstate=1 會處理器的睡眠狀態,它防止處理器進入深度睡眠狀態。這絕對不是理想的做法,而且確實會導致更高的功率使用和更低的電池壽命。然而,它確實解決了許多 Intel 系統上的隨機掛起問題。如果您使用的是 Intel Baytrail 或 Kaby Lake Refresh 晶片,請使用此參數。Intel Baytrail 晶片由於一個硬體缺陷,在沒有這個內核參數的情況下會隨機掛起[33]。有關 max_cstate 參數的更多信息,請參見內核文檔以及 GitHub 上關於 cstates 的一篇文章。

如果您嘗試通過一次性添加 intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1 等三個參數來解決頻繁掛起的問題,然後成功了,那您應該用排除法找出真正解決問題的那個參數。因為如果實際的問題與 SATA 電源管理有關,並且 ahci.mobile_lpm_policy=1 參數解決了這個問題,那麼禁用 cstate 和顯示電源管理是不可取的。

參考 Linux Reviews 網站以獲取更多信息。

添加對 165Hz 顯示器的支持[編輯 | 編輯原始碼]

本文或本章節可能需要合併到內核級顯示模式設置#強制設置顯示模式與_EDID

附註: 這種技術似乎並不特定於 i915。在合併之前,請驗證安裝腳本是必需的,並且沒有更簡單的方法來將 EDID BIN 添加到 initramfs。(在 Talk:Intel 圖形處理器 中討論)

對於某些 165Hz 顯示器,xrandr 可能不會顯示165Hz選項,且 #添加未檢測到的解析度中的方法並不能解決這一問題。在這種情況下,請參見 StackExchange 上的問答 i915-driver-stuck-at-40hz-on-165hz-screen

注意:除了創建 /etc/initramfs-tools/hooks/edid 文件之外,應該通過以下方式創建 mkinitcpio 鉤子:
/etc/initcpio/install/edid
#!/bin/bash

build() {
    add_file /lib/firmware/edid/edid.bin
}

help() {
    cat <<HELPEOF
This hook add support for 165Hz
HELPEOF
}

然後在 /etc/mkinitcpio.conf 文件的 HOOKS 中添加 edid ,就像下面這樣

/etc/mkinitcpio.conf
HOOKS=(... fsck edid)

最後 重新生成initramfs.

Raptor Lake 和 Alder Lake-P 處理器從睡眠/掛起中恢復時凍結[編輯 | 編輯原始碼]

來自不同供應商的 Raptor Lake 和 Alder Lake-P 第 12 代移動處理器的筆記本電腦的用戶在從暫停狀態中醒來後,遇到了了凍結和黑屏。這是因為根據 freedesktop issue 55316401 的描述,許多筆記本電腦供應商提供了錯誤的 VBT(Video BIOS Table,視頻 BIOS 表),錯誤地描述了連接到 iGPU 的實際埠。在這種情況下,所有被記錄的案例都懷疑是重複的 eDP 條目。

考慮到大多數供應商不會為運行正常的 Windows 作業系統的筆記本電腦發布 BIOS 更新,Linux 用戶只能在內核端解決這個問題。有兩個方法可以防止出現重複的 eDP 條目以影響到內核:修補內核或者加載一個 修改過的 VBT

為了修補內核,重複的 eDP 條目需要通過分析以下命令的輸出被辨別出來:

# intel_vbt_decode /sys/kernel/debug/dri/1/i915_vbt
Child device info:
        Device handle: 0x0008 (LFP 1 (eDP))
        Device type: 0x1806 (unknown)
 ...
 Child device info:
        Device handle: 0x0080 (LFP 2 (eDP))
        Device type: 0x1806 (unknown)

輸出表明這裡確實存在重複的 eDP,內核應該忽略掉第二個,但是用戶還是被鼓勵檢查這個。然後可以使用下面的補丁修補內核,如果有需要的話重複條目的索引可以被替換為 ignoreEntry = 1

--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3688,6 +3688,14 @@
{
       struct intel_bios_encoder_data *devdata;

+       int ignoreEntry = 0;
+
       list_for_each_entry(devdata, &i915->display.vbt.display_devices, node)
-               func(i915, devdata);
+       {
+               if (ignoreEntry != 1)
+               {
+                       func(i915, devdata);
+                       ignoreEntry++;
+               }
+       }
}

第二種解決這個問題的方法是通過直接清除 VBT 內重複條目來修改 VBT。

複製 VBT,使用十六進制編輯器編輯它然後修改重複的 device handle 的 device type 至 00 00

$ cat /sys/kernel/debug/dri/0/i915_vbt > vbt
--- vbt
+++ modified_vbt
@@ -22,10 +22,10 @@
 00000150  00 08 00 20 00 08 00 10  00 08 00 02 00 08 00 01  |... ............|
 00000160  00 08 00 00 01 08 00 00  00 04 00 00 00 40 00 00  |.............@..|
 00000170  00 20 00 00 00 10 00 00  00 02 00 00 00 01 00 00  |. ..............|
-00000180  00 00 01 00 00 02 8b 01  02 04 00 00 27 08 00 06  |............'...|
-00000190  18 00 00 00 00 00 00 00  00 00 00 00 00 0a 00 00  |................|
+00000180  00 00 01 00 00 02 8b 01  02 04 00 00 27 08 00 00  |............'...|
+00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 0a 00 00  |................|
 000001a0  03 00 00 00 c0 00 40 00  20 00 00 00 00 00 00 00  |......@. .......|
-000001b0  00 00 20 00 80 00 06 18  00 00 00 00 00 00 00 00  |.. .............|
+000001b0  00 00 20 00 80 00 00 00  00 00 00 00 00 00 00 00  |.. .............|
 000001c0  00 00 00 00 07 00 00 00  00 00 00 c0 00 10 00 20  |............... |
 000001d0  00 00 00 00 00 00 00 00  00 20 00 04 00 d2 60 00  |......... ....`.|
 000001e0  10 10 00 23 21 10 00 00  00 00 00 07 00 00 02 00  |...#!...........|

這個修改過的 VBT 可以通過複製到 /lib/firmware/modified_vbt 再傳遞 i915.vbt_firmware=modified_vbt 的內核參數來加載,以及如果有需要,重新生成 initramfs

參閱[編輯 | 編輯原始碼]