Qubes does allow for the use of accelerated graphics (e.g. OpenGL) in dom0’s Window Manager, so all the fancy desktop effects should still work. App qubes use a software-only (CPU-based) implementation of OpenGL, which may be good enough for basic games and applications.
From Faq
Won’t good GPU enhance performance of APP qubes based on “software-only (CPU-based)” in above sentence? Will it help if I play video in APP qube?
I think Qubes OS can’t display without dedicated GPU if CPU doesn’t have iGPU, so GPU must have some usages, what are the usages?
What is the relationship between GPU passthrough and use GPU to display?
I am confused because I am not familiar with GPU or the display mechanism of Qubes OS.
I guess the answer is already in the question: GPU will not affect the CPU-based performance, by definition. AppVMs do not have the access to the GPU for security reasons.
GPU passthrough requires a second GPU, which will be used by an HVM exclusively.
OK, I’ll try an answer to the best of my knowledge. Others might jump in to correct me or explain in more detail.
What is a GPU used for (mostly)?
What you see on your screen are pixels, each of them represented by multiple values in (V)RAM. Software needs to push these bitmaps (maps of pixels) into the respective RAM area. This is the data that then gets used to tell your monitor which color, hue (“values”) each pixel has.
The GPU might in some way be involved in moving that data, but the speed difference between a low-end and a high-end GPU might not be as much as you imagine.
A GPU is a graphics processing unit, which means it can do calculations. So instead of pushing the pixels for a e.g. triangle into the respective RAM position, the software can tell the GPU: “draw a triangle at this position with these properties”. A triangle is a relatively simple example, but there are more complex operations like 3D rendering, calculating shadows etc. When the GPU is calculating those things and putting the pixels into the respective memory area we talk about “hardware accelerated” because the GPU is specialized in doing this kind of calculation and moving it into the memory really fast. The opposite would be “software-rendering” when these calculations are done by software on the main CPU and the result is then moved into memory.
So what about Qubes OS?
The software running in your qubes has no access to the GPU. Besides technical challenges, this also has security reasons. You don’t want software in qube A to be able to “see” what software in qube B draws into the respective memory / on screen. Instead the software in each qube renders graphics into a shared memory area it only has write access to. Qubes OS makes sure each qube can only push data in that area of the memory that represents it’s share of the screen (think: where the respective window is).
Software in dom0 or sys-gui can take advantage of the GPU to draw window decorations and other graphical effects, but obviously only things that are requested by software running in dom0/sys-gui like XFCE or KDE. The contents of the windows comes from the various qubes and has already been rendered there by software. So the GPU might be involved in moving this data to the screen, but it cannot help in “drawing” it with “hardware acceleration” because that hardware is not available in the respective qubes.
I hope this helps a little and doesn’t create more questions than it answered. Also consume with a pinch of salt, because I am not really familiar with the Qubes OS mechanism of how the data moves from the qubes to dom0. It’s more a summary of my understanding coming out of other discussions.
I think I only need a cheapest GPU that can work on Qubes OS if GPU is only used in DOM0 without passthrough to HVM? There are many other posts think high end GPU will make display more smooth without passthrough, are they wrong?
You need a graphics interface, something that connects to your monitor and moves the bits from the memory to your display. Older computers used to have graphics cards (VGA, SVGA) that didn’t have any GPUs as I remember it. But there was still some logic on there to move the bits. Today most CPU come with an iGPU, so it can handle all that’s needed to move the bits plus some basic GPU stuff.
For use with Qubes OS if you choose an Intel processor, the iGPU that comes with it likely just works and does everything you need. Any dedicated graphics card (GPU) is bound to give you headaches when it comes to driver support. See also this troubleshooting guide. I admit total ignorance when it comes to AMD, but I am sure other community members will jump in.
I am not aware of any posts that claim output to be more “smooth” with a high end GPU in the Qubes OS context. If they exist, they are probably more motivated by wanting to justify the investment than by any actual benefit. Possibly “wobbly” windows in KDE work smoother with an external GPU (if you get it to run at all that is). Maybe an external GPU supports higher refresh rates especially on 4K+ displays. That kind of benefit. Mostly I’d say it’s not worth the trouble (or the money) … in case of Qubes OS.
If you plan to also use the same machine for native Windows gaming that’s an entirely different conversation, but you are probably still better of running Qubes OS on the iGPU even if there is an external GPU present.
Finally there are folks who need GPUs for scientific applications or to heat the planet while creating pretend money. In those cases one would use the iGPU for dom0/sys-gui and then passthrough the dedicated GPU to a qube for said calculations.
Instead the software in each qube renders graphics into a shared memory area it only has write access to. Qubes OS makes sure each qube can only push data in that area of the memory that represents it’s share of the screen
Is the “shared memory” memory of GPU or PC? If it’s GPU, then higher Memory clock rate (MHz) and bandwidth of GPU can help render in APP qubes.
And I think RAMDAC speed (MHz) (Random Access Memory – Digital Analog Converter) can help render in APP qubes. RAMDAC is used only for analog output, e.g. over a VGA connection, so don’t need to consider it here.
Speed at which the image can be translated to an analog signal when it is sent to the DAC (Digital-to-Analog Convertor).