F5F Stay Refreshed Hardware Desktop Disable GPU without taking it off or damaging the power cable for Linux (batocera)

Disable GPU without taking it off or damaging the power cable for Linux (batocera)

Disable GPU without taking it off or damaging the power cable for Linux (batocera)

X
xStriKed
Member
212
03-23-2019, 10:24 PM
#1
You're facing a tricky setup with your dual GPU system. It seems the GTX980 isn't compatible with Batocera's DVI output when paired with the B550M Pro4 motherboard, even if you try to disable the 2070 Super in BIOS. The best solution appears to be physically removing the card, which would avoid damaging the PSU power connector over time. If that's not feasible, you might need to consider replacing it with an AMD GPU to keep things running smoothly.
X
xStriKed
03-23-2019, 10:24 PM #1

You're facing a tricky setup with your dual GPU system. It seems the GTX980 isn't compatible with Batocera's DVI output when paired with the B550M Pro4 motherboard, even if you try to disable the 2070 Super in BIOS. The best solution appears to be physically removing the card, which would avoid damaging the PSU power connector over time. If that's not feasible, you might need to consider replacing it with an AMD GPU to keep things running smoothly.

I
iXefo
Member
104
03-24-2019, 01:57 AM
#2
This guide appears to explain how to remove a PCI-e graphics card that's not connected.
I
iXefo
03-24-2019, 01:57 AM #2

This guide appears to explain how to remove a PCI-e graphics card that's not connected.

L
Luigi461
Junior Member
21
03-24-2019, 09:26 AM
#3
I'm a bit puzzled, you require a DVI connection to function, likely for your display but DVI is digital not analog. You might find DP or HDMI adapters useful. Besides that, you could turn off the second GPU in BIOS, which is somewhat inconvenient, or adjust your operating system settings to only allow the necessary card. Also, it seems you can operate with a single card without needing changes. If you need an analog output (VGA), there are adapters available as well.
L
Luigi461
03-24-2019, 09:26 AM #3

I'm a bit puzzled, you require a DVI connection to function, likely for your display but DVI is digital not analog. You might find DP or HDMI adapters useful. Besides that, you could turn off the second GPU in BIOS, which is somewhat inconvenient, or adjust your operating system settings to only allow the necessary card. Also, it seems you can operate with a single card without needing changes. If you need an analog output (VGA), there are adapters available as well.

K
kcristan
Senior Member
514
03-24-2019, 11:52 AM
#4
This might assist you. My main concern is whether the suggested commands remain consistent across different GPU manufacturers. I want to ensure drivers can be turned off specifically for the 2070 Super. I should be able to disable only the relevant driver. An adapter won't work for CRT output, which is my setup. I need a real analog signal. The dual link DVI-I is indeed analog. Apologies if this isn't useful. If you know a method to disable it in BIOS or Linux, please share how. Thanks for your response.
K
kcristan
03-24-2019, 11:52 AM #4

This might assist you. My main concern is whether the suggested commands remain consistent across different GPU manufacturers. I want to ensure drivers can be turned off specifically for the 2070 Super. I should be able to disable only the relevant driver. An adapter won't work for CRT output, which is my setup. I need a real analog signal. The dual link DVI-I is indeed analog. Apologies if this isn't useful. If you know a method to disable it in BIOS or Linux, please share how. Thanks for your response.

T
TempLate_YT
Senior Member
424
03-24-2019, 08:11 PM
#5
You're suggesting the OS should ignore a particular PCIe device, making it unaffected by GPU type or device. It sounds like you're highlighting a unique challenge and seeing it as an opportunity to explore Linux. Another idea is disconnecting your GPU from the host system entirely and running your Linux distribution inside a virtual machine. This approach could work well, though I'm unsure about implementing it on Windows. I believe avoiding physical connections is a better solution. The PCIe slot appears designed for 50 cycles, and the power connectors seem similarly limited.
T
TempLate_YT
03-24-2019, 08:11 PM #5

You're suggesting the OS should ignore a particular PCIe device, making it unaffected by GPU type or device. It sounds like you're highlighting a unique challenge and seeing it as an opportunity to explore Linux. Another idea is disconnecting your GPU from the host system entirely and running your Linux distribution inside a virtual machine. This approach could work well, though I'm unsure about implementing it on Windows. I believe avoiding physical connections is a better solution. The PCIe slot appears designed for 50 cycles, and the power connectors seem similarly limited.

T
160
03-26-2019, 02:27 PM
#6
On DVI-I, the four pins surrounding the flat pin transmit analog signals for RGB, synchronization, and ground.
T
TheWheatherMan
03-26-2019, 02:27 PM #6

On DVI-I, the four pins surrounding the flat pin transmit analog signals for RGB, synchronization, and ground.

G
Gekke_Meloen
Junior Member
44
03-27-2019, 09:41 AM
#7
Makes perfect sense, and thanks! Indeed, that’s what I expected as a retro gamer who initially switched to RetroArch for Windows due to its inconsistent switch handling. (RetroArch remains true to its roots on Linux; CRTswitchers still work well there.) Do you have any solid resources for Linux if you run into command issues? You’re already comfortable with SSHing into Batocera, which is great. A VM running through Windows would add an ironic twist to this “CRT emulation machine” experience. Would that impact latency, or is it more about avoiding it when possible? Your support means a lot!
G
Gekke_Meloen
03-27-2019, 09:41 AM #7

Makes perfect sense, and thanks! Indeed, that’s what I expected as a retro gamer who initially switched to RetroArch for Windows due to its inconsistent switch handling. (RetroArch remains true to its roots on Linux; CRTswitchers still work well there.) Do you have any solid resources for Linux if you run into command issues? You’re already comfortable with SSHing into Batocera, which is great. A VM running through Windows would add an ironic twist to this “CRT emulation machine” experience. Would that impact latency, or is it more about avoiding it when possible? Your support means a lot!

V
vdlogt254
Member
74
03-27-2019, 09:42 PM
#8
An alternative approach would involve deploying a different system equipped with that GPU for the particular operating system. A valid reason to upgrade the CPUs in your Windows setup.
V
vdlogt254
03-27-2019, 09:42 PM #8

An alternative approach would involve deploying a different system equipped with that GPU for the particular operating system. A valid reason to upgrade the CPUs in your Windows setup.

E
EnderSlayerDan
Junior Member
5
03-28-2019, 08:11 PM
#9
You're free to execute the VM via any hypervisor such as Proxmox for hosting your VMs. That might feel a bit more cumbersome, though it's not a big deal. Checking online resources can help if you run into issues. I haven't tested it myself, but ChatGPT seems capable with Linux-related tasks—worth a look. Expecting a minor performance drop is possible, but it shouldn't be significant. You'll also need to work around the controller you're using. The simplest option is routing through the full USB controller, which could leave no USB ports available for your host OS. That might require some troubleshooting. The display output should run directly on the GPU without extra virtualization overhead, so latency shouldn't be a major concern there. Still, unknown factors could introduce delays. I'm not setting up anything like that myself, sorry :c
E
EnderSlayerDan
03-28-2019, 08:11 PM #9

You're free to execute the VM via any hypervisor such as Proxmox for hosting your VMs. That might feel a bit more cumbersome, though it's not a big deal. Checking online resources can help if you run into issues. I haven't tested it myself, but ChatGPT seems capable with Linux-related tasks—worth a look. Expecting a minor performance drop is possible, but it shouldn't be significant. You'll also need to work around the controller you're using. The simplest option is routing through the full USB controller, which could leave no USB ports available for your host OS. That might require some troubleshooting. The display output should run directly on the GPU without extra virtualization overhead, so latency shouldn't be a major concern there. Still, unknown factors could introduce delays. I'm not setting up anything like that myself, sorry :c

K
Keelanwolf
Junior Member
17
03-29-2019, 03:04 AM
#10
I've finally started testing it. Unfortunately, it looks like Batocera only works with "GNU coreutils" and not with sudo or a direct install method from the tool. From what I understand, I can't execute the required commands. Regarding the VM, I'm trying to set up a fully functional Linux environment and attempt virtualization there. However, the process keeps breaking down—especially when trying to convert the .img.gdi file into a .vdi format. The error message states: "VD: The given disk size..." which indicates a mismatch in sector alignment. I'm facing issues with VBoxManage.exe and can't create the expected disk image.

I'm considering switching to a completely fresh Linux OS and see if that helps with virtualization. I'm worried that if this fails, I might have to buy another machine to install it on. I'm also trying Qemu via PopOS following a guide, but it's not working well. The command `./runQemu.sh ~/batocera-x86_64-37-20230617.img.gz share.img` fails because it can't find the directory.

I tried extracting the Batocera archive and giving permissions to the share file, but that didn't resolve the problem. I'm exploring different virtual environments if this one doesn't work. In the meantime, I think I'll focus on fixing the IOMMU settings or moving the installation to another drive.

Overall, the forum discussion made me realize that running Batocera inside a VM is the only viable path right now. For anyone with dual GPUs, I'd suggest checking compatibility and possibly using a different setup.
K
Keelanwolf
03-29-2019, 03:04 AM #10

I've finally started testing it. Unfortunately, it looks like Batocera only works with "GNU coreutils" and not with sudo or a direct install method from the tool. From what I understand, I can't execute the required commands. Regarding the VM, I'm trying to set up a fully functional Linux environment and attempt virtualization there. However, the process keeps breaking down—especially when trying to convert the .img.gdi file into a .vdi format. The error message states: "VD: The given disk size..." which indicates a mismatch in sector alignment. I'm facing issues with VBoxManage.exe and can't create the expected disk image.

I'm considering switching to a completely fresh Linux OS and see if that helps with virtualization. I'm worried that if this fails, I might have to buy another machine to install it on. I'm also trying Qemu via PopOS following a guide, but it's not working well. The command `./runQemu.sh ~/batocera-x86_64-37-20230617.img.gz share.img` fails because it can't find the directory.

I tried extracting the Batocera archive and giving permissions to the share file, but that didn't resolve the problem. I'm exploring different virtual environments if this one doesn't work. In the meantime, I think I'll focus on fixing the IOMMU settings or moving the installation to another drive.

Overall, the forum discussion made me realize that running Batocera inside a VM is the only viable path right now. For anyone with dual GPUs, I'd suggest checking compatibility and possibly using a different setup.