Quoting Kenneth Graunke (2017-07-22 00:17:41) > With the advent of asynchronous maps, domain tracking doesn't make a > whole lot of sense. Buffers can be in use on both the CPU and GPU at > the same time. In order to avoid blocking, we stopped using set_domain > for asynchronous mappings, which means that the kernel's tracking has > lies. We can't properly track it in userspace either, as the kernel > can change domains on us spontaneously (for example, when un-swapping). > > I915_GEM_SET_DOMAIN combines two aspects: cache flushing, and waiting > for a buffer to be idle. In order to stop using it, we'll need to do > clflushing ourselves, and use I915_GEM_WAIT to wait on buffers. > > For cache-coherent buffers (most on LLC systems), we don't need to do > any clflushing - the CPU and GPU views are coherent. For non-coherent > buffers (most on non-LLC systems), we currently only use the CPU for > read-only maps, and we explicitly clflush when necessary. > > One downside to this is that we'll stall unnecessarily if we do a > read-only mapping of a buffer that the GPU is reading. I believe > that's pretty uncommon.
Pretty please add some of the warning comments about GTT from earlier. For bonus paranoia, the *gtt_map trick as well. :) You should be able demonstrate the issue if you do *brw_bo_map_gtt(bo) = 1; assert(*brw_bo_map_cpu(bo) == 1); Can we add unit tests to this file? -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
