just_another_person@lemmy.world
on 14 Oct 2024 18:18
collapse
They have enough trouble with their drivers and software ecosystem. I’m surprised they’re adding more onto that pile.
davidgro@lemmy.world
on 14 Oct 2024 19:40
nextcollapse
I don’t see evidence in the article that it even is ‘their software’ being discussed here - just a framework they are suggesting for compositors to have new functionality (regardless of GPU brands).
It even says “They aren’t going into this alone but at this year’s DisplayNext Hackfest it was also backed up by AMD for going a similar route.”
This isn’t really driver related. It is the Wayland compositor’s job to properly handle multiple GPUs, which is lacking in some (a very popular, Wayland library that lacks proper multi-GPU support is wlroots) compositors. Vulkan drivers and DRM are already enough to properly handle multiple GPUs. I guess Wayland implementers just haven’t cared enough about the issue, or maybe are figuring out a “perfect” way to address it (a la 3 year long pull request on wayland-protocols repo incoming)
threaded - newest
They have enough trouble with their drivers and software ecosystem. I’m surprised they’re adding more onto that pile.
I don’t see evidence in the article that it even is ‘their software’ being discussed here - just a framework they are suggesting for compositors to have new functionality (regardless of GPU brands).
It even says “They aren’t going into this alone but at this year’s DisplayNext Hackfest it was also backed up by AMD for going a similar route.”
This isn’t really driver related. It is the Wayland compositor’s job to properly handle multiple GPUs, which is lacking in some (a very popular, Wayland library that lacks proper multi-GPU support is wlroots) compositors. Vulkan drivers and DRM are already enough to properly handle multiple GPUs. I guess Wayland implementers just haven’t cared enough about the issue, or maybe are figuring out a “perfect” way to address it (a la 3 year long pull request on wayland-protocols repo incoming)