Open jgcodes2020 opened 2 years ago
It's interesting. Has anyone tested whether the vgpu driver is available on windows?
Is the test environment using alder Lake's iGPU or arc dGPU? Is it a test using a normal desktop PC instead of a server? How much does vGPU performance lose in VM environment?
- SRIOV upstream task is on-going, ETA Q4'23
- Yes, we already test Windows VM and works well.
Hi, I managed to create a DKMS module using the driver source here. But the GPU driver in my WIndows VM fails with Error 43. I wonder if you're using a modded driver?
My DKMS module: https://github.com/strongtz/i915-sriov-dkms more information: https://www.reddit.com/r/VFIO/comments/xoeika/sriov_on_intel_uhd_graphics_770_xe_12th_gen
Is the test environment using alder Lake's iGPU or arc dGPU? Is it a test using a normal desktop PC instead of a server? How much does vGPU performance lose in VM environment?
Is there any update on whether SR-IOV will be "only" possible on iGPUs or also on Arc dGPUs too? Is it correct that this feature will be available both on desktop machines and notebooks?
@krispan-intel Does Arc A770 support SR-IOV?
I noticed that the Flex 170 might support SR-IOV , but no card to verify. It would be exciting if customer graphics cards(Arc A770, A750) could also support SR-IOV. Many enthusiasts will buy Intel graphics cards because of this.
2023.04.18 Update :
I tested Arc 770 under Ubuntu 22.04 Server. It is support GPU Passthrough, but need install Intel Indirect Display Driver to support stream work(ex Sunshine). Not support SR-IOV!
# lspci -nn | grep "VGA"
00:02.0 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)
03:00.0 VGA compatible controller [0300]: Intel Corporation Device [8086:56a0] (rev 08)
# lspci -vs 03:00.0
03:00.0 VGA compatible controller: Intel Corporation Device 56a0 (rev 08) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 1020
Flags: bus master, fast devsel, latency 0, IRQ 154, IOMMU group 16
Memory at 81000000 (64-bit, non-prefetchable) [size=16M]
Memory at 6000000000 (64-bit, prefetchable) [size=16G]
Expansion ROM at 82000000 [disabled] [size=2M]
Capabilities: [40] Vendor Specific Information: Len=0c <?>
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+
Capabilities: [d0] Power Management version 3
Capabilities: [100] Alternative Routing-ID Interpretation (ARI)
Capabilities: [420] Physical Resizable BAR
Capabilities: [400] Latency Tolerance Reporting
Kernel driver in use: i915
Kernel modules: i915
without
Capabilities: [***] Single Root I/O Virtualization (SR-IOV)
2023.03.22 Update :
I tested Data Center GPU Flex 140 under Ubuntu 22.04 Server. Currently only available in passthrough mode. A single card has two addresses, so one flex 140 card support two vm. Relatively stable, no crashes during testing.
# lspci -nn | grep "Display"
d0:00.0 Display controller [0380]: Intel Corporation Device [8086:56c1] (rev 05)
d4:00.0 Display controller [0380]: Intel Corporation Device [8086:56c1] (rev 05)
SR-IOV driver not ready now.
Works on win10 guest, with some code modification personally. while it is better to wait for official stable release.
with some code modification personally
What does this mean? Your XML seems different, do you mean you edited the XML?
Mine (as generated by virt-manager) - getting Code43 in the guest:
Yours:
Unlike PCI passthrough, which bound the entire hardware resource to one specific VM, this fancy function enables you to share one GPU with multiple VMs, then you can see the GPU address shows 00:02.x, which is called VF(virtual function), rather than 00:02.0, the physical hardware on host. And it requires support from both the motherboard chip(i915 in my case) and GPU. Your SRIOV function is not powered up, so neither your hardware nor software driver does not compatible.
@strongtz , question for you, does that modified driver only work on 6.0.2, as mentioned from your latest commit message, or would that work on 6.0.9?
Been trying to get it working for days but no luck.
Basically get to the point where you echo to the sys device, but no matter what it returns permission denied I'm on Fedora though, if that's the issue.
Otherwise dkms status shows the sriov-dkms driver from your repo, and I know it is loaded as it throws me an error in dmesg, which isn't there with the in-tree i915 module.
[ 66.468702] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec [ 66.468883] hdaudio hdaudioC0D2: Unable to configure, disabling
Thanks in advance!
@truvatech 6.0.9 works well on Arch Linux here, both in host and VM. VA-API video acceleration in VM works.
If you're using my modified dkms driver, you will see debug prints in dmesg like
i915 0000:0b:00.0: i915_virtualization_probe: entry
Did anybody manage to verify if Arc supports any kind of SR-IOV?
Did anybody manage to verify if Arc supports any kind of SR-IOV?
SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html
:(
Too bad, it looks like nobody will buy Intel Arc after all :(
Too bad, it looks like nobody will buy Intel Arc after all :(
Indeed, there is no advantage in performance compared to competing products. The SR-IOV support in the promotion can be said to be the only bright spot. Now even this advantage does not exist. I really can’t think of anyone who would buy such a meaningless product.
I really can’t think of anyone who would buy such a meaningless product.
There is one very small use case left: av1 decoding/encoding on a budget. The lowest end Arc GPUs could make sense if all you need is a decoding/encoding accelerator, at least until RDNA3 budget cards get released.
There is one very small use case left: av1 decoding/encoding on a budget. The lowest end Arc GPUs could make sense if all you need is a decoding/encoding accelerator, at least until RDNA3 budget cards get released.
This is usually one of the few selling points in their commercial propaganda. The disadvantages are obvious, poor drivers, poor performance, and poor prices. It can be said that there are almost no advantages, but if SR-IOV is supported, then these disadvantages can be tolerated.
Even limiting the number of VFs in SR-IOV to one is much better than the current state.
The Arc dGPU is a better description of the fact of wasting sand than the i7-11700K.
I learned that the transistor size is the same for all Arc dGPU multimedia codecs, which makes Arc dGPU only valuable as the lowest-end A370.
SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html
That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.
That's quite sad.
SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html
That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.
Could the drivers be patched to enable unofficial support? Or does this really require firmware support?
SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html
That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.
Could the drivers be patched to enable unofficial support? Or does this really require firmware support?
I would assume that it was missing there on a physical level altogether or was fused off.
Could it be that it would only work for integrated graphics because of connections?
I'd say just lack of willingness to sell any card.
I'd say just lack of willingness to sell any card.
Nailed it.
- SRIOV upstream task is on-going, ETA Q4'23
- Yes, we already test Windows VM and works well.
Is this still the case?
I hope so
I hope so
I wouldn't be so sure, their lack of transparency in that regard lost me as a customer on iGPUs as well. I was planning to buy a 12th Gen Intel laptop but I'm moving towards a Ryzen 7000 series instead: what's the point of buying the worse APU if none of them supports SR-IOV?
I wouldn't be so sure, their lack of transparency in that regard lost me as a customer on iGPUs as well. I was planning to buy a 12th Gen Intel laptop but I'm moving towards a Ryzen 7000 series instead: what's the point of buying the worse APU if none of them supports SR-IOV?
Well, I don't trust AMD's software quality, plus Intel is still much better when it comes to video decoding, and MTL might be epic.
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
@krispan-intel thanks. Do you know if Intel still cares about GVT-g? I've never managed to get it working on my Broadwell APU: https://github.com/intel/gvt-linux/issues/222
@darkbasic This issue should not be about flaming intel or their business strategy. I am also disappointed, because I can not use sr-iov atm. It was a buyers argument for my current cpu, but I am sure intel devs are just smart devs who do their work and have no influence on business strategy.
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
Does this mean it's included in v6.2 kernel?
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
Does this means it's included in v6.2 kernel?
Presumably not. That appears to be upstream of the official linux source code. I assume "mainline tracking" just means they try to keep up with changes to the kernel until they're ready to submit their changes. So they probably stopped porting 6.2 as soon as 6.3 came out, and so on.
If you're using a "normal" linux distro, you have to wait for intel's changes to get added to linus's "official" version of linux, and then you have to wait for your distro to add linus's changes to your distro's kernel. This process can take a few months.
How would I go about making a patch that will add sriov support to my fedora kernel?
How would I go about making a patch that will add sriov support to my fedora kernel?
I think you may be looking for this?
maybe, although I build my own custom kernel using the fedora one anyway, so unsure if that's the best option compared to patching something I build anyway. and unsure what happens with the original module in this setup.
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
Have patches been submitted for merging into mainline Linux at this point?
Have patches been submitted for merging into mainline Linux at this point?
I don't think so.
Hi, has Intel's SRIOV been merged into the mainline? If not, is there a schedule?
Same question here, when will this to be merged into mainline.
To be honest, this is the main cause why I bought an Intel CPU this year.
How would I go about making a patch that will add sriov support to my fedora kernel?
I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently.
YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.
How would I go about making a patch that will add sriov support to my fedora kernel?
I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently.
YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.
I think maybe it's easier to upgrade you Fedora kernel with linux-intel-lts:
How would I go about making a patch that will add sriov support to my fedora kernel?
I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently. YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.
I think maybe it's easier to upgrade you Fedora kernel with linux-intel-lts:
- download linux-intel-lts
- build it into rpm package for installation
- install it on Fedora
- reboot Fedora
- ‘uname -ra’ to cat your kernel version
To be honest, If there were a patch, I would be very excited, because it's very much easy for me to build kernel.org source code for supporting SR-IOV function.
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
Have patches been submitted for merging into mainline Linux at this point?
No, sorry. Postpone due to DRM interface rework.
As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV. Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.
As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV. Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.
Uh works fine for me with TF2 and stuff on 2256x1504 resolution last time I test. Maybe not new games like CS2. It's better than skylake graphics which could barely drive a 1080p monitor at 60fps, so I expect it to be less useless than GVT-g. If you can change the dimensions of the virtual monitor, it could be pretty useful for productivity cause QXL is really slow and I don't feel like rebooting into windows sometimes.
As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV. Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.
Uh works fine for me with TF2 and stuff on 2256x1504 resolution last time I test. Maybe not new games like CS2. It's better than skylake graphics which could barely drive a 1080p monitor at 60fps, so I expect it to be less useless than GVT-g. If you can change the dimensions of the virtual monitor, it could be pretty useful for productivity cause QXL is really slow and I don't feel like rebooting into windows sometimes.
That's really good performance. It'll be only better with the new intel SOC coming out soon.
If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.
Have patches been submitted for merging into mainline Linux at this point?
No, sorry. Postpone due to DRM interface rework.
I ran into this problem when making a kmod with the new version of the i915 module, and discovered that the DRM module lacked the required symbols to run properly.
I then tried to build a new version of the DRM module, but couldnt get past "symbols exported twice errors" and gave up. I am back to using strongz DKMS version.
@krispan-intel Any update on official SR-IOV for Kernel 6.5?
any news?
Since drivers for SR-IOV have already been completed in this fork, could these drivers be mainlined into the kernel?