On Thu, Oct 22, 2026 at 03:30:11PM +0200, Christian König wrote: > > If I'm understanding things correctly we're expecting a change in path > > between > > attach and map time to be rare in practice. Therefore the need to handle > > this > > case is mostly as a fallback to not break things. So instead of pinning > > could > > new attachments just invalidate all existing incompatible attachments on the > > list by setting eg. attach->valid = 0? > > No, that would result in ping/pong behavior which is something we explicitly > try to avoid. > > This is also not something uncommon, it happens multiple times a > second on a standard X11 Linux desktop when a new buffer is started > to be scanned out on an A+A or A+I laptop.
It seems to me to be very similar to an importer not accepting P2P, that already creates a placement restriction that the exporter cannot use VRAM. I don't know how well we handle that, but mapping type is a generalization of that same idea. If the environment is complicated and asymmetric there absolutely are going to be placement restrictions where the GPU driver gets to put the object. You cannot put an object in CPU memory if you have ualink only importers, for example. The best we can do is provide up to date information to the exporter so if it chooses it can make informed placement decisions. This is why I tend to prefer we keep the attachment and somehow update the maping types to reflect any limitations from the importer HW. At least in the AI server world the migrations are rare/non-existent so we do need to keep in mind slightly different usage models for this API than a X11 desktop. Jason
