[MPlayer-dev-eng] SFENCE really needed?

[Nick Kurshev]

Hello, Michael!

On Tue, 21 Jan 2003 18:27:45 +0100 you wrote:

> 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 ...
> 
AMD x86-64 Architecture Programmer s Manual Volume 5:
64-Bit Media and x87 Floating- Point Instructions
Publication No. 26569
Revision 3.02
Date August 2002
Page 37

MOVNTQ implicitly uses weakly-ordered, write-combining buffering for the data,
as described in  Buffering and Combining Memory Writes  in volume 2. For data
that is shared by multiple processors, this instruction should be used together
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                  ^^^^^^^^
with a fence instruction in order to ensure data coherency (refer to "Cache and
       ^^^^^^^^^^^^^^^^^                         ^^^^^^^^^
TLB Management" in volume 2).
======================================
7 Memory System from Volume 2:
...
To maintain memory coherency, external bus masters (typically other processors
^^^^^^^^^^^^^^^^^^^^^^^^^^^^           ^^^^^^^^^^^
with their own internal caches) need to acquire the most recent copy of data
before caching it internally.
...

=============================================================

Thus: to use or not to use *FENCE instructions DOES MATTER only
for SMP or several MASTERS!
So really it doesn't matter for mplayer ,imho, (except VIDIX's and mga_vid calls)
As for mplayerxp - it does matter always!!!


Btw, reading of K8 manuals enlightens many dark places ;)
> [...]
> 
> Michael
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


WBR! Nick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030121/520975d8/attachment.pgp>