The kernel (an element of the operating system), is responsible for managing RAM, based on this sentence. The kernel is not the CPU. That is a large chip on my motherboard.
After I asked if the kernel caches to VRAM (a poorly phrased question, as I was more interested in whether or not it's the kernel's job to manage VRAM use generally):
So, above, you state that the kernel "uses free RAM..." Thus, the kernel, software, is responsible for handling the RAM, and that it doesn't do so for VRAM, as "that is the GPU's job."
Managing RAM: kernel's job -> software in the operating system's job
Managing VRAM: not the kernel's job -> is the GPU's job -> is a physical object's job.
It appears from the above, that the kernel manages the RAM, via the firmware (the simpler operating system you mentioned, implementing the x86 instruction set and how the hardware implements it). The absent thing causing my disconnect is the software that tells the GPU firmware when to clear VRAM. If that is not the kernel, what is it?
I am not sure of the answer on this one. I suspect it may be a bit of each, since both are capable of it and the GPU is capable of doing so without the Kernel.
I think my wording created some confusion - The kernel communicates with the CPU - on a system level, just a lot... a lot more than it communicates with other hardware. This may be a cognitive bias in my communication.
I perceive the direct communication to the motherboard as "closer" to the Kernel than I do those components that are not always in use.
That much I think is surely true--no matter what the case, the kernel would have to go through a bus, whether USB, PCIe, SATA, or whatever, for most anything but the CPU.
Based on my own understanding (which is primitive and based on simplifications I have read, thus my questions in case they were oversimplifications), the CPU (and thus, the kernel) issues instructions to the GPU to load things into VRAM. I assume the CPU has to actually access the files on the storage device and ship them off to the GPU via the PCIe bus, as getting the data itself would require the GPU to "understand" filesystems, and I doubt people are writing btrfs code for GPUs. I understand this to be part of why CPUs can bottleneck graphics performance, and it's part of why I was surprised at my interpretation of what you wrote above.
I'm using a lot of "I understand" and "my understanding" to indicate that I could absolutely be completely off-base here.
We likely are in the same boat.
The way I had it figured, since I already am aware you know much about graphics and graphics stacks (probably surpassing me), that your questions were a sign I was either communicating poorly, or I had a fundamental misunderstanding somewhere.
Less than you might think--I used to have lunch with a graphics programmer daily, but given that I am in no way a coder, explanations and conversations were always simplified. There are black box testers, who know nothing of the inner workings of what they're testing, white box testers, who are basically right in the inner workings, and gray box testers who have some insights to the internals, but no access and not the same level of technical expertise. I do some gray and some black box testing (the gray does not include graphics). The intricacies of the graphics stack I understand about as well as I just described it above.
So, You want create a Dual-Boot System with Zorin and Windows 10, yes? Is there a Reason why You want create the Partitions manually? Because You could choose during the Installation the Option ''Install Zorin alongside Windows'' and then it will be automatically created by the Installer. You only choose in the next Step how many Disc space You want use with a Toggle.