[MPlayer-dev-eng] SFENCE really needed?

[Michael Niedermayer]

Hi

On Tuesday 21 January 2003 17:51, Nick Kurshev wrote:
[...]
> > well, i only know whats written in the docs from intel & amd and these
> > are not completely clear to me, so IMHO its saver to add the sfence stuff
> > ...
>
> =================================================
> SFENCE Store Fence
>
> Acts as a barrier to force strong memory ordering (serialization) between
> store ^^^^^^^^^^^^^
> instructions preceding the SFENCE and store instructions that follow the
> SFENCE. A weakly-ordered memory system allows hardware to reorder reads and
> writes between ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the processor
> and memory. The SFENCE instruction guarantees that the system completes all
> previous stores before executing subsequent stores...
> ============================================
>
> According on Mans RullGard:
>
> mb() is supposed to block until all outstanding memory operations have
> completed.  On some machines (e.g. Alpha) memory operations are
> allowed to complete out of order.  An mb instructions prevents any new
> loads/stores from issuing before all previous load/stores are
> completed.  This is necessary for MMIO to work.
> ============================================
>
> From K8 manuals:
>
> Memory-Mapped I/O.
> Application software that needs to force memory ordering to memory-mapped
> I/O devices can do so using the read/write barrier instructions: LFENCE,
> SFENCE, and MFENCE.
>
> ============================================
>
> From me:
>
> If you perform out-of-order writing of array[10] with using movnt** insns
> then you may have situation when cpu will write it in order
> 1. array[2]
> 2. array[6]
> 3. array[1]
> 4. array[9]
> and so on
>
> This is useful for writing into graphics memory which can be temporary
> locked by video DAC (SGRAM allows access to the memory chip from side of 2
> units simultaneously except locked memory cells).
>
> And this is not acceptable for writing into MMIO for example. When
> array[10] is memory mapped PCI ports then order of writing DOES MATTER.
>
> IMHO that'c clear!
yes, but there are a few things which are not clear
for example if non temporal & temporal writes are mixed (the first can be done 
out of order) and bypass the cache and the later are done in order over the 
cache is the cpu able to handle the mess?, the case is common if c code is 
used to do the last pixels

perhaps iam just paranoid ;)
we could remove all sfence after the 0.90 release and see what happens ...

[...]

Michael