On 09/18/2015 12:26 PM, Ville Syrjälä wrote: > On Fri, Sep 18, 2015 at 07:44:34PM +0100, Chris Wilson wrote: > Yeah I guess that was a crappy example. Trying to think of a better one, > I figure execlist status could be read from memory, but apparently > that's just mmio. I guess the context update + ELSP write is something > we do from the irq handler, but there are plenty of barriers between > those two it seems. Maybe there's no good example here. > >> >> Anyway, I thought we had strongly ordered reads on x64/x32? > > The cpu won't reoder reads vs. reads, or writes vs. writes for that > matter if you ignore the nt stuff and whatnot. But AFAIU the whole > point of _relaxed() on x86 is that it allows the compiler to reoder > memory vs. mmio any which way it wants. If you mean the top level readX_relaxed() functions, those were more about re-ordering on a large I/O fabric than compiler re-ordering. I'm not sure how the compiler handles things these days; I thought maybe the volatile accesses would imply a re-order barrier as well, since they could have side effects the compiler can't anticipate (i.e. re-ordering even read after read could change behavior). But it would be good to double check... and according to memory-barriers.txt we should be safe there, from the readX_relaxed() section: "Note that relaxed accesses to the same peripheral are guaranteed to be ordered with respect to each other." Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
