Re: RFC: New bus_space routine: bus_space_sync

[Michael <macallan1888%gmail.com@localhost>]

Hello,

On Fri, 20 Jan 2012 13:53:23 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> >> Even if originally intended for something else, [...]
> 
> > Why do you think BUS_SPACE_BARRIER_SYNC was intended for something
> > else ?  I can't see how a write barrier that doesn't ensure the write
> > has reached the target (main or device memory) can be usefull.
> 
> I can't comment on why someone else thinks something.  But barriers
> that have nothing to do with write completion to the target can still
> be useful.  There are algorithms that don't require that writes
> complete on any particular schedule, but do require that _this_ write
> complete before _that_ one.  When faced with write coalescing and
> reordering, a write barrier that does nothing but enforce ordering (in
> the sequence A-barrier-B, the barrier enforces the constraint that
> there is no time at which write B has completed but write A hasn't) can
> be useful.

Exactly. With many graphics chips you write parameters in a bunch of registers 
with the last write starting the blitter by some means. Here we don't care when 
exactly the writes complete ( in most cases they're going into a pipeline first 
anyway ) or in which order the parameters are written, but the trigger has to 
be the last that does. And that one has to complete ( being written to the 
hardware, not necessarily do anything right away ) before the parameters for 
the next one are written to the hardware. And so on. As Matt said, completely 
different problem. One is about enforcing order, the other is about writing 
stuff out NOW ( which in a way also enforces order but with a lot more baggage 
).

have fun
Michael