https://bugs.kde.org/show_bug.cgi?id=522991

--- Comment #10 from Joe Alec <[email protected]> ---
Here are my results

# The good
- OpenGl games like Antichamber no longer drop FPS massively, the game was
running at 60 FPS all the time
- Vulkan games like GTA IV no longer exhibit the insufferable jitter, frame
timing is very smooth

# The bad
- Both OpenGl and Vulkan games can no longer use the integrated Intel GPU.
Error message
```
MESA: error: dri3_alloc_render_buffer:1654 xcb_dri3_pixmap_from_buffer[s]
failed
MESA: error: X error: 11
```

I don't know how to feel about this, the env var `KWIN_DRM_DEVICES` definitely
made a difference, and for my use case it partially serves the purpose, but it
makes the internal GPU non-usable by all games, there are also some differences
compared to the older kwin v6.6.4:

- Older kwin 6.6.4 may have prefered the external Nvidia GPU, but it allowed me
to force the internal Intel GPU when I need that
- Older OpenGL games were previously free to choose which GPU to use, and they
prefered the internal/Intel one almost all the time, but with the kwin env var
they all now prefer the external Nvidia GPU, which is overkill

For completeness, this is for example how I force a game to use the internal
GPU:
```shell
export DRI_PRIME=pci-0000_00_02_0

export
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

export __GLX_VENDOR_LIBRARY_NAME=mesa

export
VK_DRIVER_FILES=/usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json:/usr/share/vulkan/icd.d/intel_icd.i686.json:/usr/share/vulkan/icd.d/intel_hasvk_icd.i686.json:/usr/share/vulkan/icd.d/intel_icd.x86_64.json

export
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json:/usr/share/vulkan/icd.d/intel_icd.i686.json:/usr/share/vulkan/icd.d/intel_hasvk_icd.i686.json:/usr/share/vulkan/icd.d/intel_icd.x86_64.json

export __VK_LAYER_NV_optimus=non_NVIDIA_only

exec "$@"
```

My `lspci` output is this:
```shell
$ lspci -nnD | grep -i vga

0000:00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P
GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c)
0000:01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104
[Geforce RTX 3070 Ti Laptop GPU] [10de:24a0] (rev a1)
```

The inconviniences with this whole issue is:
- It wasn't really clear to me in any way what GPU did the compositor use for
the render buffer, I only suspected it was related to copying buffers because
moving the game window to the internal monitor (connected to Intel GPU) made
everything magically work just fine.

To me it makes sense that whatever monitor the window of the game/app is
located in, should tell the compositor what GPU should be used, and based on
that, the render buffer should be created on that GPU, no copying around.

If for example the game window is inside monitor 2 (external monitor) and that
monitor is connected to Nvidia GPU, then why would the compositor choose Intel
GPU and copy buffers around, that seems unnecessary.
Even for power optimization, no one would expect a game/app to render on their
internal GPU while the physical window is on the external monitor.

I appologize if this sounds obviously wrong, I lack the required technical
knowledge and I don't know the limitations of composition/rendering, but just
as a regular user I definitely want my external GPU to be fully utilized if I
use it, the power optimization concerns are valid I cannot argue, but please
don't let that be on the cost of performance especially if the GPU is capable
enough, this just becomes a forced under utilization of the GPU than a
reasonable power optimization.
I assume you would agree with me on that point.

- As you pointed earlier, this was also an issue (or at least similar to it)
back in 2022, is it possible, please for the love of anything, to have an
option in the "System Settings" app > "Display & Monitor", so that users can
choose the primary GPU whenever they want.

I didn't even know there was a dedicated env var to choose which GPU is the
primary one, because in "Display & Monitor" I selected the external monitor
(connected to Nvidia GPU) as the "primary one", so to me it seemed like that
would be logical to make games prefer Nvidia GPU over Intel.

Coming from Windows OS, this seems very confusing, because on Windows I choose
which GPU an app should use/prefer from either Nvidia Control Panel or from
Windows Settings app, it was always a choice per app which GPU is selected.
On linux (or Plasma desktop) I never really understood how to do that, and in
older kwin versions everything just worked as expected.

- From your hint regarding the slow buffer copying being an issue in the Nvidia
driver, I searhed around and found this:
https://forums.developer.nvidia.com/t/nvidia-please-get-it-together-with-external-monitors-on-wayland/301684/152

So I'm aware it isn't kwin issue, but because nothing was clear to me, and I
couldn't downgrade just kwin without downgrading the entire KDE apps stack, I
ended up using another desktop environemnt for gaming, luckily now I can use
Plasma for gaming.

Maybe the new code to help laptops in power efficiency is the right direction
logically, it isn't very good practically as it just regresses what used to
work perfectly. When mangohud for exmaple detects the external GPU being used,
and with 0% usage on the internal GPU, I would not expect the internal GPU to
be used for the render buffer. The fact that a game's render buffer could be on
a different GPU than the one it is using is just very confusing to me.
I appologize if this sentence is too harsh or just wrong for technical reasons,
but that's how things look/feel from a user prespective.

Please, at least can we have that option in the Settings app to manually select
the prefered GPU for now as a first step, it doesn't have to be per-app or
anything complex, just a global modifier like the env var `KWIN_DRM_DEVICES`.
That way whenever the compositor logic changes again over time, users don't
have to complain over time due to logic change/breakage, and they can simply
override the compositor behavior if the default doesn't work.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to