Quoting Chris Wilson (2019-01-21 22:21:13) > In preparation for enabling HW semaphores, we need to keep in flight > timeline HWSP alive until the entire system is idle, as any other > timeline active on the GPU may still refer back to the already retired > timeline. We both have to delay recycling available cachelines and > unpinning old HWSP until the next idle point (i.e. on parking). > > That we have to keep the HWSP alive for external references on HW raises > an interesting conundrum. On a busy system, we may never see a global > idle point, essentially meaning the resource will be leaking until we > are forced to sleep. What we need is a set of RCU primitives for the GPU! > This should also help mitigate the resource starvation issues > promulgating from keeping all logical state pinned until idle (instead > of as currently handled until the next context switch). I was resisting adding all the i915_vma_move_to_active() thinking that it was overkill, but perhaps that is exactly what I mean by rcu_read_lock(). Hmm. More so that I was trying to avoid having to keep moving the HWSP from one request to the next (for the write lock), but that should be for the normal case covered by the context pinning itself, and for the realloc we can add a write lock to the next rq. How does that help? Good question. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
