Those are two very different things. Virtual address is what your application sees, the hardware uses a sophisticated mechanism to translate it to the actual physical address. This enables a bunch of useful features (e.g. the address might point to a file on disk instead of physical RAM, you get additional safety, and the OS can move/compress the physical memory without you even noticing, etc. etc.).
For unified virtual memory you need to use the same address space on the CPU and the GPU, so that if you copy a memory address between devices it will be valid and point to the same data. I do not know why Apple does not support this, one would think that their hardware would be perfectly capable of sharing memory page descriptors. Maybe there is still some legacy reason, or maybe there are additional complications. But who knows, it is also possible that Metal 4 will have unified virtual memory on Apple Silicon but will drop Intel-based Macs or something like that.
What notes are you referring to beyond what I see on the screen which does not say this.
The issue, as far as I can tell is not one of physical or virtual access, it is one of API.
I am NOT a Metal expert, but this is my understanding:
Metal wants you to use Handles (essentially indices into a table of address ranges) not raw pointers. This is not because raw pointers won't, in some sense, "work", it's because the Metal API depends on being told how and when blocks of data are being used.
This is because the L1 caches are not coherent, and *SW conventions* are required to handle coherency.
After every unit of work (called a "kick", but you can think of this as a shader) the L1 caches are flushed to L2, so that subsequent shaders that depend on the results of this shader, but which may run on a different core, can see the work that was done.
This mechanism for flushing data from L1 to L2 is very sophisticated in terms of flushing the minimum amount of data, and in terms of scheduling non-dependent kicks to execute at the same time that flushing is happening, BUT it depends on knowing which address ranges are used in what way by each kick – ie which address ranges were read, which were written.
If you start passing around raw pointers without informing Metal of how the associated data ranges are being used, you will lose this flushing/coherence.
This is not an issue for Vulkan, or more precisely it's a DIFFERENT issue, because Vulkan has a different model of who is responsible for flushing L1 caches. Apple's solution is not wrong, it's just different from Vulkan's, and assumes different packaging of the information about who is responsible for flushing what data ranges when.
It's like Apple is Java or Swift, with memory management happening behind the scenes – but you don't use raw pointers – while Vulkan is like C with manual calls to malloc and free.
Corrections welcome if I got anything wrong!
