Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 20.09.23 um 16:02 schrieb Thomas Hellström:
[SNIP]
Do you by "relocation" list refer to what gpuvm calls "evict" list or something else? Like the relocaton/validation list that used to be sent from user-space for non-VM_BIND vms?

The BOs send into the kernel with each command submission on the classic IOCTLs.


The vm bos plus the external/shared bos bound to the VM (the external list) are the bos being referenced by the current batch. So the bos on the VM's external list are the ones being locked and fenced and checked for eviction. If they weren't they could be evicted before the current batch completes?

That only applies to a certain use case, e.g. Vulkan or user mode queues.

Multimedia APIs and especially OpenGL work differently, here only the BOs mentioned in the relocation list are guaranteed to not be evicted.

This is intentional because those APIs tend to over allocate memory all the time, so for good performance you need to be able to evict BOs from the VM while other parts of the VM are currently in use.

Without that especially OpenGL performance would be completely crippled at least on amdgpu.

OK, I've always wondered how overcommiting a local VM would be handled on VM_BIND, where we don't have the relocation list, at least not in xe, so we have what you refer to as the user mode queues.

I figure those APIs that suffer from overcommitting would maintain a "current working set" in user-space and send changes as deltas to the kernel as unbinds/binds. Or at least "can be unbound / can no longer be unbound" advises.

This may turn out interesting.

Essentially this is how Windows used to work till (I think) Windows 8.

Basically the kernel is responsible to figure out which BO to move in/out of VRAM for each submission an application does. And it is perfectly acceptable for an application to allocate 8GiB of VRAM when only 4GiB is physical available.

To be honest I think it's one of the worst things every invented, but we somehow have to support it for some use cases.

Christian.


/Thomas




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux