On Mon, Dec 14, 2015 at 02:59:30PM +0000, Tvrtko Ursulin wrote: > > Hi, > > On 11/12/15 11:33, Chris Wilson wrote: > >Now that we have split out the seqno-barrier from the > >engine->get_seqno() callback itself, we can move the users of the > >seqno-barrier to the required callsites simplifying the common code and > >making the required workaround handling much more explicit. > > What bothers me about this patch, and the one preceding it, is that > I don't see a tangible improvement for the programmer who still has > to know when to read the seqno and when to "read it harder, read for > real". In earlier patches, I called it irq_barrier. It's not reading it harder. It's just that there is a ordering issue with receiving an interrupt and the seqno write being visible. > Barrier in this sense has a relation to the state of things but > somehow feels too low level to me when used from the code. But to be > fair I am not sure how to better define it. > > Would ring->get_seqno paired with ring->read_seqno perhaps make > sense? Implementation for ring->read_seqno would just be a flush > followed by ring->get_seqno then. Or maybe keep the barrier and add > ring->read_seqno which would be ring->seqno_barrier + > ring_get_seqno? No. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
