Don’t think I can. This is also something I was always curious about, but I couldn’t find any info. Based on Intel’s marketing material, the basic approach seems to be very similar to what Apple is doing - shared last level cache and shared memory controllers, but the details are very vague. It’s unclear whether these modern Intel iGPUs can only access certain substance of physical RAM, whether they are subject to the same TLB lookup procedure as the CPU cores and also how all this stuff is interconnected. The “GPU Memory” could very well be an artificial limitation by the OS/driver or there could indeed be some technical limitation.
This is only a small clue (although I do think from the documentation and other references that it does do dynamic video memory allocation, I'm not certain):
Describes the recommended best practices for developing a Metal game or app.
developer.apple.com
The clue I noticed here (and I'm interested in the issue of why lightroom has some issues) is that metal has three different memory resource storage modes: shared, private, and managed. Private for stuff the gpu won't need access to, shared for gpu/cpu access, and managed for a copy being in each (to avoid shifting between the different memory banks). Each with slightly different characteristics for speed and whatnot.
A bit above my knowledge level but would seem that managed wouldn't be needed or be redundant in the unified memory architecture.
Now, one thing, I don't know if lightroom is using metal at all (yet), or using older models and whether those resource models work in OpenCL (or whatever).
Now my speculation: I could very much see that eg. Lightroom if written aggressively (e.g. in full gfx acceleration) would be copying between what it thinks of as different memory banks (core/gpu) and also saving them in both (similar to the managed) and just blow up the amount of memory in use, when it's actually unnecessary. Resulting in the bad swapping and some of the performance issues users are seeing.
To be clear, not saying that this is because of metal - it could be e.g. that Lightroom had some internal tricks/routines to achieve some acceleration similar to above - and that that's what's causing the 'collisions' on M1 systems. (I say not because of metal because I'd guess apple's own drivers would know about this and just present the same memory as managed to programs that called on it.)
[Obviously this could apply to any number of programs that did similar things, I just happen to be interested in lightroom.]
