Open ytoaa opened 11 months ago
I think we've identified the cause of the problem. There seems to be a problem between virtual monitor technology, or "idd," and Intel's latest graphics driver. I don't think this will be resolved for the time being...
My host machine enables Intel's GVT-g, which can provide some vGPUs (virtual GPU) for Virtual Machine to use. I create a Virtual Machine on the host with vGPU passthrough, and I run sunshine in the Virtual Machine. Everything works fine except sunshine's Intel QSV encoding. It seems that Intel QSV encoding fail due to 'First packet type is not an IDR frame'.
I think this is just a bug in sunshine, because OBS works fine in that Virtual Machine. I have tested OBS with DXGI screen capture and H264 encoding with Intel's QSV encoder, everything is fine.
I found #1460 in issues, maybe it is relevant too.
Any bug fix will be appreciate. Thanks in advanced.
Info: Host: Intel i7-10700 (UHD 630), proxmox system VM : Win11 22H2, sunshine 20.0, vGPU (with virtual display)
내 호스트 컴퓨터는 가상 컴퓨터에서 사용할 일부 vGPU(가상 GPU)를 제공할 수 있는 Intel의 GVT-g를 활성화합니다. vGPU 패스스루를 사용하여 호스트에 가상 머신을 생성하고 해당 가상 머신에서 sunshine을 실행합니다. sunshine의 Intel QSV 인코딩을 제외하고는 모든 것이 잘 작동합니다. '첫 번째 패킷 유형이 IDR 프레임이 아닙니다'로 인해 Intel QSV 인코딩이 실패한 것 같습니다.
내 생각엔 이것이 Sun의 버그일 뿐이라고 생각합니다. 왜냐하면 OBS가 해당 가상 머신에서 잘 작동하기 때문입니다. DXGI 화면 캡처 및 Intel QSV 인코더를 사용한 H264 인코딩으로 OBS를 테스트했는데 모든 것이 정상입니다.
문제에서 #1460을 찾았습니다 . 어쩌면 관련성이 있을 수도 있습니다.
모든 버그 수정에 감사하겠습니다. 미리 감사드립니다.
정보: 호스트: Intel i7-10700(UHD 630), proxmox 시스템 VM: Win11 22H2, sunshine 20.0, vGPU(가상 디스플레이 포함)
Rustdesk confirmed that hardware encoding is correct. This is something strange. Is the parsec remote control working normally?
i face similar probloem, this is my test env: Host: Intel 12400 (UHD 730), proxmox system with sriov enabled. VM: win10 2021 ltsc (with sriov igpu, intel graphic driver version 3222)
i found h264_qsv always fail but hevc_qsv works(use ffmpeg for qsv transcode testing).
So i recompile sunshine to disable all h264/av1 check and only enable hevc_qsv. This works fine for first moonlight connection, but black screen for other connections. Then trace & debug, i found AcquireNextFrame function always return DXGI_ERROR_ACCESS_LOST when connection fails. i guess maybe there is some bug for intel driver ... (or something leak ? not sure)
비슷한 문제에 직면했습니다. 이것은 내 테스트 환경입니다. 호스트: Intel 12400(UHD 730), sriov가 활성화된 proxmox 시스템. VM: win10 2021 ltsc(sriov igpu 사용, Intel 그래픽 드라이버 버전 3222)
h264_qsv는 항상 실패하지만 hevc_qsv는 작동한다는 것을 알았습니다(qsv 트랜스코드 테스트에는 ffmpeg를 사용하세요).
그래서 Sunshine을 다시 컴파일하여 모든 h264/av1 검사를 비활성화하고 hevc_qsv만 활성화합니다. 첫 번째 달빛 연결에서는 잘 작동하지만 다른 연결에서는 검은 화면이 나타납니다. 그런 다음 추적 및 디버그를 해보니 연결이 실패하면 AcquireNextFrame 함수가 항상 DXGI_ERROR_ACCESS_LOST를 반환하는 것으로 나타났습니다. 아마도 인텔 드라이버에 버그가 있는 것 같아요... (또는 뭔가 누출이 있는 걸까요? 확실하지 않습니다)
I checked the old version driver that works properly "https://www.intel.co.kr/content/www/kr/ko/download/741626/780560/intel-arc-pro-graphics-windows.html " but sad that this isn't the latest version. There certainly seems to be a problem with the Intel driver. Not even parsec
I encountered the same issue. I tried uninstalling and reinstalling older drivers listed on the official Intel website, but none of them worked properly on my win10 VM with 12th SRIOV GPU passthrough. see also #1460
I am not sure if I understood correctly.
By the way, I just found a new fork made by itsmikethetech.
I am looking for a solution to host a couple VMs with good 4K remote desktop experience, and recent developments of Sunshine & Intel SR-IOV GPU in Proxmox I read about seemed very promising. But for performance reasons hevc_isv is a must.
Have you tried more than one VMs at once, one Moonlight session each?
itsmikethetech
I'd trust this one. They are a content creator on YouTube who creates tutorials for Sunshine.
I am not sure if I understood correctly. #1460 was just closed with comment "On Windows, Sunshine requires that a display is connected to the GPU." But your comments here imply that on older versions of Intel GPU driver, "virtual" display was enough to fulfill this requirement. Which one? Is it ge9's release of IDD? By the way, I just found a new fork made by itsmikethetech.
I am looking for a solution to host a couple VMs with good 4K remote desktop experience, and recent developments of Sunshine & Intel SR-IOV GPU in Proxmox I read about seemed very promising. But for performance reasons hevc_isv is a must.
Have you tried more than one VMs at once, one Moonlight session each?
In fact, if you connect the vm with the older version driver above installed, it is possible without a physical displayer connector.
Thank you. I'll try to get the hardware then. By the way, who can reopen #1359? I don't want to tag random contributors.
No reason to have multiple issues open for the same thing.
That's different, about seemingly incompatible Intel HEVC encoding parameters used by Sunshine, on older hardware and with no virtualization. Issue #1359 was closed automatically with no acknowledgement from any of the devs, and I haven't found similar open ones. It seems likely it's exactly what I encountered today – same error message, same GPU generation.
내가 올바르게 이해했는지 잘 모르겠습니다. #1460은 "Windows에서 Sunshine을 사용하려면 디스플레이가 GPU에 연결되어 있어야 합니다."라는 설명과 함께 닫혔습니다. 그러나 귀하의 의견은 이전 버전의 Intel GPU 드라이버에서는 "가상" 디스플레이가 이 요구 사항을 충족하기에 충분하다는 것을 의미합니다. 어느 것? ge9의 IDD 출시인가요? 그런데 방금 itsmikethetech에서 만든 새 포크를 발견했어요.
저는 우수한 4K 원격 데스크톱 경험을 갖춘 몇 개의 VM을 호스팅할 수 있는 솔루션을 찾고 있으며, 제가 읽은 Proxmox의 Sunshine 및 Intel SR-IOV GPU의 최근 개발은 매우 유망해 보였습니다. 그러나 성능상의 이유로 hevc_isv는 필수입니다.
한 번에 두 개 이상의 VM, 각각 하나의 Moonlight 세션을 사용해 보셨나요?
https://www.reddit.com/r/unRAID/comments/182b79m/intel_12th_gen_i512400_windows_10_vm_igpu_sriov/ Additionally, I brought some posts from Reddit that could help.
I confirm all the findings listed in this issue. I used Proxmox with SR-IOV to split & passthrough iGPU to the VM, with itsmikethetech's virtual display driver. In a few hours of gaming on VM everything was just perfect. Sunshine worked correctly using hevc_qsv on 13gen with Intel driver 31.0.101.4338 as described in the first post. Hardware encoder broke when drivers were updated by the system (mid-December, don't remember exact version). By the way, 31.0.101.4338 can be downloaded from Windows Update repository, it cannot be found on Intel website.
I won't investigate this further, the idea of using Proxmox VMs with Sunshine/Moonlight (instead of a few regular PCs) was dropped because of very low disk I/O performance (unrelated).
Thank you all for the help, especially for Sunshine & Moonlight developers!
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
It seems to be a problem with Intel's driver, but I think we need to check further to see if the sunshine can solve the problem on its own.
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
Then bump, as it is still an issue.
I guess Intel broke H.264 while HEVC and AV1 is still functional? And since sunshine probes a lot of encoders, it writes off the encoder as non-functional if it fails basic H.264 validation. Not sure what we should do here, we can add some special flag to quicksync encoder that will change this behavior, but this will also slow down the probing for people not affected by the bug, and in the end it's the problem in Intel's driver.
Not sure about projects internal architecture, but if that's the case then probably having some "debug feature" that allows to enforce it is a better idea, instead of adding it into a default probe chain. As you wrote, this is a rather obscure thing affecting a very specific use case. And most likely a vendor problem - but we know how working with vendors is like.
If anyone can suggest a code change(s) to test (just to pinpoint what workaround can possibly solve this issue) then I'm happy to get build env working and do some testing. With the workaround available and confirmed it would make more sense to discuss how to possibly implement that :)
Have the same problem with PVE+SRIOV and 13th Intel CPU. But it's all fine using Parsec, don't know what the technology difference between Sunshine and Parsec.
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
Starting with Intel's latest graphics drive using the uhd 770 igpu, quicksync does not work properly. The current known-good drive is 31.0.101.4338. Later versions have not been tested, but are currently not available in 31.0.101.4676. I checked if this is a problem that only occurs in sunshine, but parsec, a similar program, did not work normally. However, rustdesk works normally. I'm sure this is Intel not working, but I'm leaving an issue here just in case.
Expected Behavior
Hardware encoding failed on Intel cpu using uhd 770.
Additional Context
No response
Host Operating System
Docker
Operating System Version
windows 11 22h2
Architecture
64 bit
Sunshine commit or version
0.20.0 and nightly
Package
Windows - installer
GPU Type
Intel
GPU Model
intel igpu uhd 770 (i7 12700)
GPU Driver/Mesa Version
31.0.101.4676
Capture Method (Linux Only)
none
Config
Apps
No response
Relevant log output