search

strongtz / i915-sriov-dkms

dkms module of Linux i915 driver with SR-IOV support
1.07k stars 132 forks source link

A critical bug happened with HDR(?) encoding #57

Open ghost opened 1 year ago

ghost commented 1 year ago

OS:Proxmox VE 7.3-6 (Using 6.1.6-1-pve kernel)

I tried to use this dkms module on proxmox ve and it worked.

[ 2.911299] Setting dangerous option enable_guc - tainting kernel [ 2.994677] i915 0000:00:02.0: [drm] ERROR Zero GuC log crash dump size! [ 2.994680] i915 0000:00:02.0: [drm] ERROR Zero GuC log debug size! [ 2.994931] i915 0000:00:02.0: [drm] GuC error state capture buffer maybe too small: 2097152 < 2557128 (min = 852376) [ 2.996442] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin version 70.5.1 [ 2.999299] i915 0000:00:02.0: [drm] GuC submission enabled [ 2.999299] i915 0000:00:02.0: [drm] GuC SLPC enabled [ 2.999720] i915 0000:00:02.0: [drm] GuC RC: enabled [ 3.669541] i915 0000:00:02.1: GuC interface version 0.1.0.0 [ 3.671464] i915 0000:00:02.1: GuC interface version 0.1.0.0 [ 3.671664] i915 0000:00:02.1: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.674288] i915 0000:00:02.2: GuC interface version 0.1.0.0 [ 3.676028] i915 0000:00:02.2: GuC interface version 0.1.0.0 [ 3.676186] i915 0000:00:02.2: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.678211] i915 0000:00:02.3: GuC interface version 0.1.0.0 [ 3.678762] i915 0000:00:02.3: GuC interface version 0.1.0.0 [ 3.678898] i915 0000:00:02.3: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.680643] i915 0000:00:02.4: GuC interface version 0.1.0.0 [ 3.681245] i915 0000:00:02.4: GuC interface version 0.1.0.0 [ 3.681401] i915 0000:00:02.4: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.683182] i915 0000:00:02.5: GuC interface version 0.1.0.0 [ 3.683674] i915 0000:00:02.5: GuC interface version 0.1.0.0 [ 3.683810] i915 0000:00:02.5: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.685595] i915 0000:00:02.6: GuC interface version 0.1.0.0 [ 3.686048] i915 0000:00:02.6: GuC interface version 0.1.0.0 [ 3.686202] i915 0000:00:02.6: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF [ 3.687958] i915 0000:00:02.7: GuC interface version 0.1.0.0 [ 3.688467] i915 0000:00:02.7: GuC interface version 0.1.0.0 [ 3.688566] i915 0000:00:02.7: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF

When I passthrough these VFs inside the VM, they work fine too.

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.6-060106-generic root=UUID=59172ee7-9bd2-40e5-a488-51fb7e78f695 ro i915.enable_guc=3 console=ttyS0 [ 0.022307] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.6-060106-generic root=UUID=59172ee7-9bd2-40e5-a488-51fb7e78f695 ro i915.enable_guc=3 console=ttyS0 [ 2.253994] Setting dangerous option enable_guc - tainting kernel [ 2.256039] i915 0000:01:00.0: GuC interface version 0.1.0.0 [ 2.259764] i915 0000:01:00.0: GuC interface version 0.1.0.0 [ 2.260557] i915 0000:01:00.0: GuC firmware PRELOADED version 1.0 submission:SR-IOV VF

But when they use the decoding function in the environment of windows and ubuntu, they have these video errors.

Ubuntu: W(GD$R~S_O8}XQZU$7XS5@P

Windows: J3D)@{UN55JCO)H0B9K1C11

I don't know whether this error is caused by the DKMS module or the SR-IOV function, but what I can confirm is that this problem may be caused by HDR encoding (when I turn off HDR encoding in plex, everything returns to normal) but I can't turn off the HDR function in windows, so I can't know whether it is an error caused by HDR.

Hope this isn't SR-IOV's fault, Intel probably doesn't care much about this feature.

michael-pptf commented 1 year ago

Are you using HDR tone mapping to play HDR content in a SDR output? UHD series of graphcis aren't capable of hardware HDR tone mapping, at least not in SRIOV context. This is not documented anywhere but I've verified it myself.

ghost commented 1 year ago

Are you using HDR tone mapping to play HDR content in a SDR output? UHD series of graphcis aren't capable of hardware HDR tone mapping, at least not in SRIOV context. This is not documented anywhere but I've verified it myself.

Yes, I'm using the HDR tone mapping feature on the SDR client, but this shouldn't theoretically be an error because the UHD770 itself doesn't have this error

ninsama commented 1 year ago

我也遇到了这个问题，宿主机PVE7.4，内核6.1，虚拟机Ubuntu2204，6.1内核，plex勾选HDR后转码出现马赛克，但是虚拟机win11可以正常解码HDR，只是win版的plex解码效率较低，请问老哥现在解决了吗

ghost commented 1 year ago

我也遇到了这个问题，宿主机PVE7.4，内核6.1，虚拟机Ubuntu2204，6.1内核，plex勾选HDR后转码出现马赛克，但是虚拟机win11可以正常解码HDR，只是win版的plex解码效率较低，请问老哥现在解决了吗

已经更新驱动，git clone重新安装一下试试吧

riverscn commented 1 year ago

我更想了驱动还是有这个问题。你的问题解决了？

ghost commented 1 year ago

我更想了驱动还是有这个问题。你的问题解决了？

新驱动在我的Ubuntu虚拟机上运行不起来，所以我还不知道

ghost commented 1 year ago

我更想了驱动还是有这个问题。你的问题解决了？

我刚刚使用了 @zhtengw 的DKMS库进行了测试

在Ubuntu 22.04 LTS（linux kernel 6.3）上，新的DKMS模块正常加载，但是plex依旧花屏 我会重新打开这个issue

1F`CD7_7VXA WHLMKGEJS}I

zhtengw commented 1 year ago

可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 截屏2023-05-04 09 05 57

riverscn commented 1 year ago

VPP色调映射是正常的，但是用到了OpenCL的色调映射结果是破碎的

Aten Zhang @.***>于2023年5月4日 周四09:11写道：

可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 [image: 截屏2023-05-04 09 05 57] https://user-images.githubusercontent.com/3148769/236084597-c636fd57-567c-44cd-9118-aa4014da169f.png

— Reply to this email directly, view it on GitHub https://github.com/strongtz/i915-sriov-dkms/issues/57#issuecomment-1533937591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHQNUR3JBMNQ7FWBHRGE3XEL62LANCNFSM6AAAAAAWIFVIPE . You are receiving this because you commented.Message ID: @.***>

riverscn commented 1 year ago

你的转码原因里没写“动态范围”，看截图画面也是灰蒙蒙的，说明并没有进行色调映射，是直接转换的。

Aten Zhang @.***>于2023年5月4日 周四09:11写道：

可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 [image: 截屏2023-05-04 09 05 57] https://user-images.githubusercontent.com/3148769/236084597-c636fd57-567c-44cd-9118-aa4014da169f.png

— Reply to this email directly, view it on GitHub https://github.com/strongtz/i915-sriov-dkms/issues/57#issuecomment-1533937591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHQNUR3JBMNQ7FWBHRGE3XEL62LANCNFSM6AAAAAAWIFVIPE . You are receiving this because you commented.Message ID: @.***>

ghost commented 1 year ago

可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 截屏2023-05-04 09 05 57

反馈给Plex官方他们表示和Plex程序无关....

riverscn commented 1 year ago

肯定和plex和jellyfin无关，事实上和这个repo都无关，是intel的锅。

Sh_Cby @.***>于2023年5月4日 周四09:18写道：

可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 [image: 截屏2023-05-04 09 05 57] https://user-images.githubusercontent.com/3148769/236084597-c636fd57-567c-44cd-9118-aa4014da169f.png

反馈给Plex官方他们表示和Plex程序无关....

— Reply to this email directly, view it on GitHub https://github.com/strongtz/i915-sriov-dkms/issues/57#issuecomment-1533941759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHQNRUW4ZKQ6M3VXWP6I3XEL7WNANCNFSM6AAAAAAWIFVIPE . You are receiving this because you commented.Message ID: @.***>

ghost commented 1 year ago

肯定和plex和jellyfin无关，事实上和这个repo都无关，是intel的锅。 Sh_Cby @.>于2023年5月4日 周四09:18写道： … 可能不是i915驱动的问题，我用jellyfin打开HDR色调映射，4k HDR10视频播放正常。 [image: 截屏2023-05-04 09 05 57] https://user-images.githubusercontent.com/3148769/236084597-c636fd57-567c-44cd-9118-aa4014da169f.png 反馈给Plex官方他们表示和Plex程序无关.... — Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHQNRUW4ZKQ6M3VXWP6I3XEL7WNANCNFSM6AAAAAAWIFVIPE . You are receiving this because you commented.Message ID: @.>

这是plex forums的帖子:https://forums.plex.tv/t/movie-corruption-when-plex-decodes-4k-hdr/834529

ghost commented 1 year ago

@riverscn 实际上已经给俩个intel的员工发过邮件表示有这么一个问题他们都表示会在week17修复，但是实际上并不是这么一回事，intel根本不care任何人都没有办法，只能open着这个issue表示有这么一个问题了

riverscn commented 1 year ago

week 17 已经过去了，哈哈

ghost commented 1 year ago

week 17 已经过去了，哈哈

实际上就是新发的lts-v6.1.12-linux-230424T063740Z

ghost commented 1 year ago

week 17 已经过去了，哈哈

不过也不好说，等pve官方发6.3版本的新内核吧，可能是部分patch并没有在旧内核里面启用，不过我也不懂内核开发相关的问题，只能让 @zhtengw 解答一下旧内核是否会让所有修复生效了

zhtengw commented 1 year ago

你的转码原因里没写“动态范围”，看截图画面也是灰蒙蒙的，说明并没有进行色调映射，是直接转换的。

可能是FFmpeg版本的关系，我一直用的是官方FFmpeg-4.4.3，我换用FFmpeg-jellyfin-5.1.2，映射正常了。

截屏2023-05-04 11 16 20

riverscn commented 1 year ago

我是软解+硬编+OpenCL映射正常。 硬解+硬编+OpenCL映射异常。

Aten Zhang @.***>于2023年5月4日 周四11:20写道：

你的转码原因里没写“动态范围”，看截图画面也是灰蒙蒙的，说明并没有进行色调映射，是直接转换的。

可能是FFmpeg版本的关系，我一直用的是官方FFmpeg-4.4.3，我换用FFmpeg-jellyfin-5.1.2，映射正常了。

[image: 截屏2023-05-04 11 16 20] https://user-images.githubusercontent.com/3148769/236105582-f37b0b81-13fe-429a-93f1-71aca4798450.png

— Reply to this email directly, view it on GitHub https://github.com/strongtz/i915-sriov-dkms/issues/57#issuecomment-1534035307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHQNQOYD7LWJCWCV3M6RTXEMN67ANCNFSM6AAAAAAWIFVIPE . You are receiving this because you were mentioned.Message ID: @.***>

riverscn commented 1 year ago

你的转码原因里没写“动态范围”，看截图画面也是灰蒙蒙的，说明并没有进行色调映射，是直接转换的。

可能是FFmpeg版本的关系，我一直用的是官方FFmpeg-4.4.3，我换用FFmpeg-jellyfin-5.1.2，映射正常了。

截屏2023-05-04 11 16 20

请问一下，你的Host和Guest分别是什么发行版和内核？谢谢！

zhtengw commented 1 year ago

week 17 已经过去了，哈哈

不过也不好说，等pve官方发6.3版本的新内核吧，可能是部分patch并没有在旧内核里面启用，不过我也不懂内核开发相关的问题，只能让 @zhtengw 解答一下旧内核是否会让所有修复生效了

intel-lts里的改动都是同步的，我做的只是适配不同版本的内核，适配都是用的对应内核版本中同功能的函数替换的，而且改动都能在intel-lts或者linux主线中找到对应的commit。

zhtengw commented 1 year ago

我是软解+硬编+OpenCL映射正常。 硬解+硬编+OpenCL映射异常。

FFmpeg-4.4.4 VAAPI硬解+OpenCL，灰蒙蒙 （PVE Host 6.2.11-1-pve, Gentoo Guest 6.2.13-gentoo） FFmpeg-4.4.4 QSV硬解+OpenCL，灰蒙蒙（PVE Host 6.2.11-1-pve, Gentoo Guest 6.2.13-gentoo） FFmpeg-5.1.2-jellyfin VAAPI硬解+OpenCL，色彩正常（PVE Host 6.2.11-1-pve, Ubuntu 22.10 LXC 6.2.11-1-pve） FFmpeg-5.1.2-jellyfin QSV硬解+OpenCL，色彩正常（PVE Host 6.2.11-1-pve, Ubuntu 22.10 LXC 6.2.11-1-pve）

riverscn commented 1 year ago

原来是用LXC呀。LXC一直都是正常的。 不正常（破碎）的是KVM虚拟机里的。

zhtengw commented 1 year ago

原来是用LXC呀。LXC一直都是正常的。 不正常（破碎）的是KVM虚拟机里的。

原来如此，我在Gentoo Guest里安装了一个FFmpeg-5.1.2-jellyfin，同样VAAPI硬解+OpenCL，确实出现破碎了。

riverscn commented 1 year ago

我又测了一下，确认不是KVM里才有的问题。而是你如果用的是VF（即使用编号>1;128的/dev/dri设备），即便在LXC里也会有破碎的问题。

image

/etc/pve/lxc/xxx.conf 文件里映射如下：

lxc.cgroup2.devices.allow: c 226:1 rwm
lxc.cgroup2.devices.allow: c 226:129 rwm
lxc.mount.entry: /dev/dri/card1 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD129 dev/dri/renderD128 none bind,optional,create=file

原来是用LXC呀。LXC一直都是正常的。 不正常（破碎）的是KVM虚拟机里的。

原来如此，我在Gentoo Guest里安装了一个FFmpeg-5.1.2-jellyfin，同样VAAPI硬解+OpenCL，确实出现破碎了。

ghost commented 1 year ago

我又测了一下，确认不是KVM里才有的问题。而是你如果用的是VF（即使用编号>1;128的/dev/dri设备），即便在LXC里也会有破碎的问题。

image

/etc/pve/lxc/xxx.conf 文件里映射如下：

lxc.cgroup2.devices.allow: c 226:1 rwm
lxc.cgroup2.devices.allow: c 226:129 rwm
lxc.mount.entry: /dev/dri/card1 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD129 dev/dri/renderD128 none bind,optional,create=file

原来是用LXC呀。LXC一直都是正常的。 不正常（破碎）的是KVM虚拟机里的。

原来如此，我在Gentoo Guest里安装了一个FFmpeg-5.1.2-jellyfin，同样VAAPI硬解+OpenCL，确实出现破碎了。

有没有可能把00:00:02.0给VM使用呢

riverscn commented 1 year ago

有没有可能把00:00:02.0给VM使用呢

没可能。而且我用了最新版以后，0在LXC用只有个位数帧率了……可能又出现了新的bug。

ghost commented 1 year ago

有没有可能把00:00:02.0给VM使用呢

没可能。而且我用了最新版以后，0在LXC用只有个位数帧率了……可能又出现了新的bug。

我命大也死了，英特尔的烂活真的很多

zhtengw commented 1 year ago

有没有可能把00:00:02.0给VM使用呢

这就是核显直通了。 把pci设备给虚拟机用会把该设备绑定到vfio-pci驱动，通过i915驱动分配出来的VF就没了

ghost commented 1 year ago

有没有可能把00:00:02.0给VM使用呢

这就是核显直通了。 把pci设备给虚拟机用会把该设备绑定到vfio-pci驱动，通过i915驱动分配出来的VF就没了

那这个问题可能永远无法解决了

zhtengw commented 1 year ago

那这个问题可能永远无法解决了

HDR mapping 是用的intel compute runtime库，最好关注一下https://github.com/intel/compute-runtime 的更新

riverscn commented 1 year ago

那这个问题可能永远无法解决了

HDR mapping 是用的intel compute runtime库，最好关注一下https://github.com/intel/compute-runtime 的更新

即使是最新的intel compute runtime库问题也是依旧的。 另外在Windows Guest上没有这个问题。

nyanmisaka commented 1 year ago

@ShCby As far as I know, intel hasn't officially supported SR-IOV in mainline kernels. So It makes sense that they won't test media-driver and compute-runtime with third-party modified DKMS in such use case.

The broken image seems to be caused by a mismatched DRM format modifier that used to describe the memory layout. You can turn to https://github.com/intel/media-driver for help.

https://github.com/intel/compute-runtime/issues/643#issuecomment-1545453373

riverscn commented 1 year ago

@ShCby As far as I know, intel hasn't officially supported SR-IOV in mainline kernels. So It makes sense that they won't test media-driver and compute-runtime with third-party modified DKMS in such use case. The broken image seems to be caused by a mismatched DRM format modifier that used to describe the memory layout. You can turn to https://github.com/intel/media-driver for help.

intel/compute-runtime#643 (comment)

But it is broken in their lts-kernel too. I should say they didn’t test this use case at all.

magnww commented 1 year ago

I also had this problem after updating to 1.32.5. The 1.32.4 version is completely normal, and there will be a blurry screen after the update. After returning to 1.32.4, HDR transcoding returned to normal. This may be an issue with plex.

OS: pve 7.4-3 Kernel: 6.2.11-2-pve Docker is installed directly on the pve OS without using LXC or VM.

I added 7 VFs, 2 assigned to windows guest. Container has added the --privileged parameter to have full access to /dev/dri,

# ls -l /dev/dri
total 0
crw-rw---- 1 root video 226,   0 Aug 19 13:40 card0
crw-rw---- 1 root video 226,   3 Aug 19 13:40 card3
crw-rw---- 1 root video 226,   4 Aug 19 13:40 card4
crw-rw---- 1 root video 226,   5 Aug 19 13:40 card5
crw-rw---- 1 root video 226,   6 Aug 19 13:40 card6
crw-rw---- 1 root video 226,   7 Aug 19 13:40 card7
crw-rw---- 1 root kvm   226, 128 Aug 19 13:40 renderD128
crw-rw---- 1 root kvm   226, 131 Aug 19 13:40 renderD131
crw-rw---- 1 root kvm   226, 132 Aug 19 13:40 renderD132
crw-rw---- 1 root kvm   226, 133 Aug 19 13:40 renderD133
crw-rw---- 1 root kvm   226, 134 Aug 19 13:40 renderD134
crw-rw---- 1 root kvm   226, 135 Aug 19 13:40 renderD135

1.32.4: https://hub.docker.com/layers/linuxserver/plex/1.32.4/images/sha256-e60b7267cab5da38e681fe1b970513dd2786e8256bf6627c75e217a1a425ebff?context=explore 1.32.5: https://hub.docker.com/layers/linuxserver/plex/1.32.5/images/sha256-d88790ae02a9b3f2185a24ea925851d30e0655e1ae35dcfa324c8fbf04e58f11?context=explore

njzydark commented 6 months ago

还遇到此问题的小伙伴可以试下 @MoetaYuko 的 i915 驱动，详细上下文可见 https://github.com/RROrg/rr/issues/654#issuecomment-2054031288, 直接安装 https://github.com/MoetaYuko/intel-gpu-i915-backports/releases 即可

moetayuko commented 6 months ago

此问题已被 @MoetaYuko 解决 ，详细上下文可见 RROrg/rr#654 (comment), 直接安装 https://github.com/MoetaYuko/intel-gpu-i915-backports/releases 即可

我不知道我发布的驱动存不存在本帖描述的问题，但可以肯定的是我前几天修的和本帖不是同一个问题

njzydark commented 6 months ago

抱歉，那我先删了，不过这两个我都用过，确实遇到的是同一个问题

riverscn commented 6 months ago

抱歉，那我先删了，不过这两个我都用过，确实遇到的是同一个问题

image

实测 @MoetaYuko 的 https://github.com/MoetaYuko/intel-gpu-i915-backports/releases 并没有修复这个问题

nyanmisaka commented 6 months ago

这种规则形状的artifacts图像只能是intel驱动自己的问题。sampler或者modifier导致图像读写不对。 估计intel都没测试过Linux SR-IOV直通给Windows下的QuickSync和OpenCL转码。

riverscn commented 6 months ago

这种规则形状的artifacts图像只能是intel驱动自己的问题。sampler或者modifier导致图像读写不对。 估计intel都没测试过Linux SR-IOV直通给Windows下的QuickSync和OpenCL转码。

恰恰是SR-IOV直通Windows下的Jellyfin没这个问题，有问题的是Linux下的。

nyanmisaka commented 6 months ago

这种规则形状的artifacts图像只能是intel驱动自己的问题。sampler或者modifier导致图像读写不对。 估计intel都没测试过Linux SR-IOV直通给Windows下的QuickSync和OpenCL转码。

恰恰是SR-IOV直通Windows下的Jellyfin没这个问题，有问题的是Linux下的。

以我的了解，他们应该两个都没怎么测试过，基本都是在host上跑。SR-IOV环境的VA-API和OpenCL交互操作。