With sys-gui, rendering is no longer handled by the CPU but by the GPU?

[queen]

Qubes OS is slow because graphics are rendered on the CPU instead of the GPU.
Did I understand the sys-gui documentation correctly:
Since the iGPU/dGPU is permanently assigned, rendering is no longer done by the CPU but by the GPU?

[Atrate]

There’s conflicting information as far as I can tell: Finally got sys-gui-gpu working - very limited functionality - #6 by ctr

[random1]

From what I understand, no. The gpu is assigned to sys-gui-gpu, but the other qubes still have no gpu access and can only use cpu rendering. It is the same situation as when dom0 is the guivm, but the gpu is isolated from dom0.

[queen]

I’ve read through all the documentation again.
You’re right. It doesn’t make any difference in terms of performance. It’s just a matter of security.
The graphics card driver is moved from dom0 to sys-gui.

[queen]

@Atrate

There’s conflicting information as far as I can tell: Finally got sys-gui-gpu working - very limited functionality - #6 by ctr

Sadly, you’re right.

[corporateblush]

Edited to open new topic instead.

[queen]

I’m totally lost. What do you mean by that?

[corporateblush]

I made a post, but then instead decided to use the text to open dedicated topic.

Sys-gui-gpu qubes full gpu acceleration

Since with sys-gui-gpu, gpu is isolated from dom0, what would be the reason not to allow gpu acceleration to all the qubes to which sys-gui-gpu is guivm? All the non-dom0 qubes are by default already considered as compromised, so sys-gui-gpu then is too? So I imagine a case where the Windows qube is much safer to run in sys-gui-gpu with full acceleration, then without it in dom0? This is especially for cases where for these purposes dGPU can be used on external monitor, while sensitive operat…

[queen]

thx