You are not logged in.

#1 2024-11-23 12:52:27

halfapage
Member
Registered: 2024-11-23
Posts: 5

make Arch default to iGPU at boot

Hello everyone!

I probably have a dummy question. Couldn't find anyone with the same problem, so solution is probably very obvious.

I have a PC with an AMD iGPU and nvidia dGPU. iGPU is assigned to Arch and connected to both of my physical monitors. dGPU is passed through to a VM inside Arch, and has a DP cable plugged into it so it can be used with Looking Glass. This setup works beautifully and I am very happy with it's performance.

However, there is one slight annoyance that I would like to take out of the equation.

During boot with a DP cable plugged into the dGPU, Arch tries to use it as a default while a vfio-pci dummy driver is assigned to it. It breaks the boot of course, and the system is stuck until I unplug the DP cable and reboot through command line.

So my question is the following: is it possible to tell Arch to use iGPU as a default during boot and ignore dGPU after loading the vfio-pci driver?

Thanks in advance!

Offline

#2 2024-11-23 12:57:27

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,327
Website

Re: make Arch default to iGPU at boot

Which bootloader is this? How are you assigning the vfio-pci driver? Have you added the drivers to the initramfs?


Para todos todo, para nosotros nada

Offline

#3 2024-11-23 14:13:29

halfapage
Member
Registered: 2024-11-23
Posts: 5

Re: make Arch default to iGPU at boot

I'm using Grub.

Wiki suggested using gpu-passthrough-manager to configure vfio-pci and it did a great job. My manual attempts before did not fully work.

Drivers are passed through:
/etc/mkinitcpio.conf
MODULES=(vfio vfio_pci vfio_iommu_type1)
If I understand correctly, it means they are added to initramfs after regeneration.

I've found several posts related to this problem after all. Apparently passing vfio-pci too early breaks the boot. But in my case it only breaks if dGPU has any connector plugged in.

Offline

#4 2024-11-24 01:00:32

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,327
Website

Re: make Arch default to iGPU at boot

Did you add the modconf hook?


Para todos todo, para nosotros nada

Offline

#5 2024-11-24 10:26:58

halfapage
Member
Registered: 2024-11-23
Posts: 5

Re: make Arch default to iGPU at boot

Yes, it was there before too.

/etc/mkinitcpio.conf
HOOKS=(base udev microcode autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

Offline

#6 2024-11-24 11:27:35

Head_on_a_Stick
Member
From: The Wirral
Registered: 2014-02-20
Posts: 8,327
Website

Re: make Arch default to iGPU at boot

halfapage wrote:

Wiki suggested using gpu-passthrough-manager to configure vfio-pci and it did a great job. My manual attempts before did not fully work

I have no idea how that abstraction tool works, sorry. Perhaps if you post your manual attempts and the errors resulting? I might be able to help more then.


Para todos todo, para nosotros nada

Offline

#7 2024-11-24 12:50:45

cryptearth
Member
Registered: 2024-02-03
Posts: 1,010

Re: make Arch default to iGPU at boot

the issue is the framebuffer implementation of your motherboard - as it controls which device is used as primary efifb - which is already set before any screen outout happens
so when your bootloader shows up on the dgpu you already lost and have to look for options in your uefi - something like "primary display" or something along those lines
this comes from the igpu is usually disabled or at least not used when a dgpu is detected during post

Last edited by cryptearth (2024-11-24 12:51:09)

Offline

#8 2024-11-25 17:43:47

halfapage
Member
Registered: 2024-11-23
Posts: 5

Re: make Arch default to iGPU at boot

Head_on_a_Stick wrote:

I have no idea how that abstraction tool works, sorry. Perhaps if you post your manual attempts and the errors resulting? I might be able to help more then.

I see. Still, thank you for your time. I hoped it would be something obvious that I'm just not yet aware of. Seems it's more complicated. It's just a simple annoyance, not worth digging too deep.

Maybe I'll try to figure out how does DP/HDMI plug detection works hardware side and make an appropriate dummy plug. That's more my speed.

cryptearth wrote:

the issue is the framebuffer implementation of your motherboard - as it controls which device is used as primary efifb - which is already set before any screen outout happens
so when your bootloader shows up on the dgpu you already lost and have to look for options in your uefi - something like "primary display" or something along those lines
this comes from the igpu is usually disabled or at least not used when a dgpu is detected during post

Yeah, I checked the BIOS options. There is indeed a section where I can "force" defaulting to iGPU, but it doesn't seem to make a difference. Not sure if I misunderstand the function's purpose, or if it doesn't work. I'll leave it be for now. Thanks for your time!

Offline

#9 2024-11-25 18:56:30

cryptearth
Member
Registered: 2024-02-03
Posts: 1,010

Re: make Arch default to iGPU at boot

well - it heavily depends on the actual implementation of the system
some take "force igpu" to just keep it enabled no matter if a dgpu is detected or a display is connected to the igpu
others take it quite literally and only use the igpu when its set no matter if a display is connected or a dgpu detected
I would go as far as to assume that there're some very basic and stupid implementations out there which either ignore a dgpu or even active disable any present on the system bus - but to give them the benefit of the doubt lets just say its some bug caused by some faulty optimization
combine a cpu with an igpu along with a board connecting ports to the igpu and a dgpu is usually something done on purpose - or by mistake - so I guess it's fair to assume that one of the common options is to prefer an output connected to the dgpu
so the question comes done to: can you enforce the main framebuffer to be set to the igpu no matter if a screen is connected to the dgpu?
if not you can run into the problem that the dgpu is fully initialized and has to be reset before it can be passed to the vm - I don't know if or how this can be done as hardware is usually reset on cold/warm reboot - i.e. when the system actually hard resets
in the past I also experienced the problem that one has to dump the vbios from the dgpu and give it to the vm - for whatever reason
also: with nvid as the dgpu up until some recent driver update it often caused the famous error 43 in windows (according to what I read this was fixed sometime around the rather recent 53x/54x series of drivers) - so even if you're able to successfully passthru your dgpu to the vm it still can lead to issues within the guest

as an alternative there's virgl and venus - with virgl for opengl and venus for vulkan - but venus is still in development and even following the instructions to build it your own I wasn't able to get it done
with that the guest is able to take advantage of the hosts gpu without passthrough - and it's currently only available for linux guests
so if you want to use the passthru for a windows guest - you have to do that anyway

Offline

#10 2024-11-25 19:39:15

halfapage
Member
Registered: 2024-11-23
Posts: 5

Re: make Arch default to iGPU at boot

Thank you for your insight.

This MB definitely "forces" the iGPU on, with also initializing dGPU at the same time. There are some PCIe control switches and I played with them a little, but suprisingly they don't seem to work either. Or maybe there are failsafes that won't let users turn everything off at once? Either way, it's probably as you say - even if the dGPU remained powered down and unused, other issues would stem from that. It's a matter of conscious choice of one or the other device, fully powered up, loaded and ready, which may not be possible on this MB.

I dove into BIOS once again after my last post, but this time went deeper inside menus that I previously deemed unrelated to the issue. The amount of options is staggering. Option descriptions are unfortunately not very informative. I remember BIOS menus always being fairly sparse. Either much has changed during the last decade, or maybe I have just always played with low end devices in the past.

Offline

Board footer

Powered by FluxBB