Quoting Chris Wilson (2018-03-07 17:13:03) > Currently, we only allow ourselves to prune the fences so long as > all the waits completed (i.e. all the fences we checked were signaled), > and that the reservation snapshot did not change across the wait. > However, if we only waited for a subset of the reservation object, i.e. > just waiting for the last writer to complete as opposed to all readers > as well, then we would erroneously conclude we could prune the fences as > indeed although all of our waits were successful, they did not represent > the totality of the reservation object. > > v2: We only need to check the shared fences due to construction (i.e. > all of the shared fences will be later than the exclusive fence, if > any). > Testcase: igt/drv_hangman As it turns out, that is pretty much the only way we can observe this bug. (At least not without drinking more than one cup of tea.) You could construct something to try and overwrite the reader on another engine, tricky to observe though. However, it is the goal of selftests/live_coherency and gem_exec_flush to try and catch this type of error, so should try harder. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
