Quoting Chris Wilson (2017-07-14 00:27:05) > First question is whether or not we should wait for the gpu. Using > peekdata/pokedata implies the target thread is stopped, we could infer > that also means that any gpu tasks are also stopped for the client. (To > be accurate we would have to flush the requests when the tracee handles > SIGSTOP.) But without the serialisation, it does mean that the data may > changed underneath the tracer, which is not intended. (Now there are > other means for that data to change, it is shared between clients.) > > I'm thinking we actually do want the serialisation -- it should reduce > the potential strange behaviour under gdb. A counter point though is that CPU mmaps are not aware of the GPU at all. Neither waiting for the task, nor ensuring that the read is coherent. Oh noes, more pressure for gemfs. (And perhaps not so much as a counter point at all, but that GTT waiting and flushing is the correct implementation?) We could after the call to vm_mmap() copy out the shmem_vm_ops and replace it, or we could add another driver hook to shemfs (but at what point do we realise the midlayer mistake)? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
