Quoting Jason Ekstrand (2017-07-11 01:01:20) > Given that domain tracking is global, we can also run into interesting issues > if process A does a CPU map, writes to it, and then hands it to process B which > uses it from the GPU. Without being very aggressive about set_domain, we have > no knowledge that this is a problem. Yes, set-domain has always been a bit nebulous in that it is a one-sided barrier for a critical section. If we wanted to start from scratch, it would instead move the desired region into a cache domain and return an exclusive fence that the user must then signal. (Exclusive for writing, shared for concurrent reads.) And if the kernel were to even stop tracking the cache domain and leave it to userspace that would probably be even better. (That would have to mean that by convention, the bo is always coherent when the fence is released, but that could be relaxed if the only two parties are private.) Hmm. Actually, this can be inserted into current operations without breaking backwards compatibility. If we assume old userspace is correctly calling set-domain prior to accessing the bo through a mmapping (and if it is not, then it is deliberately using unsynchronised access) then it will wait for the fences become beginning. The only problem is allowing userspace to create an unsignaled fence for indefinite periods of time. The alternative would be something like breaking it after X seconds and sending a signal to the process (depending on how easy it is to add a new signal or even if it desirable, that may just be SIGKILL!). SVM is an interesting thorn in the side. At present, we simply have no means of implicit tracking (or KMS/prime integration) nor do we have any means of tracking which pages each operation uses. Hmm, we should have userspace at least provide a list of bo that are affected by the svm operation so that the implicit tracking just works. And of course, it assumes that userspace has made everything coherent. (Or we need to be even heavier handed and force pagefaults between coherency domains, that's certainly plausible, see HMM.) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
