openSUSE Touts Improved Multi-GPU Switching Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quackdoc
    replied
    Originally posted by the-burrito-triangle View Post
    Weird. The multiplexer should be able to switch inputs in real time... WTF are the laptop vendors / OS people doing wrong here? Maybe it's a BIOS problem, where the low level settings aren't accessible to the OS due to "security" reasons?

    Anyways, on a desktop machine with multiple GPUs, I have no problem using the dGPUs headless (without a display attached) and outputting all video through the iGPU. The multiplexer approach is much more performant since the PCIe bus isn't being used to send data from one GPU to the other, but clearly it is still a shit show because no one understands how to configure the BIOS setting from the OS and maybe do a rescan of the PCIe bus if the dGPU was powered off and then on with the mux state change. This honestly shouldn't be that hard to do...
    as far as I know, this is more of a compositor problem.

    Leave a comment:


  • Alexmitter
    replied
    Originally posted by the-burrito-triangle View Post
    Now that I think about this, shouldn't the mux be accessible via i2c (or i3c)?
    i3c WHAT? the 2 in i2c stands for it containing 2xi. Inter-Integrated Circuit​.

    Leave a comment:


  • pWe00Iri3e7Z9lHOX2Qx
    replied
    Originally posted by the-burrito-triangle View Post
    Weird. The multiplexer should be able to switch inputs in real time... WTF are the laptop vendors / OS people doing wrong here? Maybe it's a BIOS problem, where the low level settings aren't accessible to the OS due to "security" reasons?
    To a large degree this already works out of the box on all AMD (as in multu-gpu) systems, and I assume all Intel systems (and probably Intel + AMD and AMD + Intel if anyone builds those). With an AMD iGPU + AMD dGPU, it will automatically run Vulkan workloads on the dGPU. For OpenGL, you have to force it yourself (or through .desktop entry metadata). It's the same experience as using a Zen 4 / Zen 5 desktop with the displays wired up to the motherboard iGPU ports but having a dGPU installed.

    Leave a comment:


  • ahrs
    replied
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

    But most people don't want to reboot at all to select which GPU to use. The system should be smart enough to use the dGPU by default for things you are likely to want to run on the beefier GPU (e.g. Vulkan games). And give them the ability to override / manually set as necessary.
    We could have solved this problem ages ago with metadata in .desktop files using PrefersNonDefaultGPU​, except in typical Linux fashion apparently this was generalised to the point of uselessness where nobody knows what it's supposed to mean. Taken literally (which is its actual meaning apparently) it means to run on whichever GPU is the non-default GPU which could very well be the systems iGPU but could also be some other discrete card, there's no way of knowing:

    counter-part to #7089 PrefersNonDefaultGPU is broken by design, intended to mean "Use the Discrete GPU if possible" but instead generalized to mean "Use anything that we aren't using by default" wh...

    Leave a comment:


  • the-burrito-triangle
    replied
    Now that I think about this, shouldn't the mux be accessible via i2c (or i3c)?

    Leave a comment:


  • the-burrito-triangle
    replied
    Weird. The multiplexer should be able to switch inputs in real time... WTF are the laptop vendors / OS people doing wrong here? Maybe it's a BIOS problem, where the low level settings aren't accessible to the OS due to "security" reasons?

    Anyways, on a desktop machine with multiple GPUs, I have no problem using the dGPUs headless (without a display attached) and outputting all video through the iGPU. The multiplexer approach is much more performant since the PCIe bus isn't being used to send data from one GPU to the other, but clearly it is still a shit show because no one understands how to configure the BIOS setting from the OS and maybe do a rescan of the PCIe bus if the dGPU was powered off and then on with the mux state change. This honestly shouldn't be that hard to do...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

    But most people don't want to reboot at all to select which GPU to use. The system should be smart enough to use the dGPU by default for things you are likely to want to run on the beefier GPU (e.g. Vulkan games). And give them the ability to override / manually set as necessary.
    exactly this, swapping muxes should also be real time, if only bad enough for the screen to flicker as the compositor swaps.

    Leave a comment:


  • pWe00Iri3e7Z9lHOX2Qx
    replied
    Originally posted by carguello2 View Post

    A mux switch only makes the dual-gpu thing easier IMHO, for example:

    Finish working, restart the Laptop...
    Reboot to BIOS...
    Choose the GPU to boot with...
    Restart...


    That's my workflow when I'm gaming on my Laptop and I've not run into issues.
    But most people don't want to reboot at all to select which GPU to use. The system should be smart enough to use the dGPU by default for things you are likely to want to run on the beefier GPU (e.g. Vulkan games). And give them the ability to override / manually set as necessary.

    Leave a comment:


  • carguello2
    replied
    Originally posted by Quackdoc View Post
    mux switch stuff gets even more complicated.
    A mux switch only makes the dual-gpu thing easier IMHO, for example:

    Finish working, restart the Laptop...
    Reboot to BIOS...
    Choose the GPU to boot with...
    Restart...


    That's my workflow when I'm gaming on my Laptop and I've not run into issues.

    Leave a comment:


  • pWe00Iri3e7Z9lHOX2Qx
    replied
    Some aspects of using NVIDIA GPUs has certainly gotten better on OpenSUSE distros in the last year or so for people who wanted to do everything in a GUI. If an NVIDIA GPU is detected, YAST Software Repositories would suggest enabling the NVIDIA repo. Then in YAST software it would suggest installing all the correct NVIDIA packages for the driver + CUDA. I haven't tried any Tumbleweed installs on an Optimus setup in ~2 years though. The last time I did, the kernel boot params for blacklisting nouveau and the right modeset option weren't set up correctly. If you were new to Linux you'd have no idea how to fix it.

    Leave a comment:

Working...
X