[FFmpeg-devel] [PATCH 7/9] hevc: use intreadwrite
michaelni at gmx.at
Thu Jul 10 19:35:03 CEST 2014
On Thu, Jul 10, 2014 at 04:08:21PM +0200, Christophe Gisquet wrote:
> 2014-07-10 14:53 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> > On Thu, Jul 10, 2014 at 06:47:54AM +0000, Christophe Gisquet wrote:
> >> When dealing with MVs, both components may be processed at a time.
> > mixing memory access sizes can lead to speed penalties on some cpus
> > when such mixed accesses are close together
> > did you benchmark this ?
> I only have a x86 platform to test it on. No, I haven't benchmarked,
> nor analyzed the disassembled code. Indeed I would better, as things
> sometimes work the opposite of what seemed obvious.
> (also replying to Ronald) Maybe adding some DECLARE_ALIGNED(4, ...)
> where applicable would fix the alignment issue?
> Second point, can someone more used to those macros than me document
> them? I guessed that in AV_[RW][BLN]:
> - R/W means read/write
> - Big/Little/Natural endianness
N = Native endianness
> Other aspect of this documentation: indicate that aligned addresses
> may provide better performance or may be required to prevent crashes
> (e.g. the 128 ones).
AV_COPY, AV_SWAP, AV_ZERO
AV_[RW]N[8-64]A need aligned memory
AV_COPY*U doesnt need aligned memory, but might be faster if its
These might be slower than the "aligned only" variants
> Some of these might be obvious to most for most platforms, but still.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel