Am 12.02.2018 um 17:57 schrieb Felix Kuehling:
I see that as an advantage rather than a problem, cause it fixes a
couple of problems with the KFD where the address space of the inode
is not managed correctly as far as I can see.
I don't think GEM is involved in the management of address space. That's
handled inside TTM and drm_vma_manager, both of which we are using. We
have tested CPU mappings with evictions and this is working correctly now.
Ok, correct. I was thinking about that as one large functionality. When
you see it like this GEM basically only implements looking up BOs and
reference counting them, but both are still useful features.
We had problems with this before, when we were CPU-mapping our buffers
through the KFD device FD.
That implementation issues never caused problems right now because you
never tried to unmap doorbells. But with the new eviction code that is
about to change, isn't it?
I don't understand this comment. What does this have to do with doorbells?
I was assuming that doorbells are now unmapped to figure out when to
start a process again.
See what I'm missing is how does userspace figures out which address to
use to map the doorbell? E.g. I don't see a call to
drm_vma_offset_manager_init() or something like that.
Doorbells are never unmapped. When queues are evicted doorbells remain
mapped to the process. User mode can continue writing to doorbells,
though they won't have any immediate effect while the corresponding
queues are unmapped from the HQDs.
Do you simply assume that after evicting a process it always needs to be
restarted without checking if it actually does something? Or how does
amd-gfx mailing list