[MPlayer-dev-eng] Adapt config.h's generation with some ffmpeg's commits

[Alexander Strasser]

Hi!

On 2018-01-04 18:27 +0100, Etienne Buira wrote:
> On Thu, Jan 04, 2018 at 12:52:07PM +0100, Alexander Strasser wrote:
[...]
> > 
> > On 2018-01-01 16:38 +0100, Etienne Buira wrote:
> > > On Mon, Jan 01, 2018 at 12:19:24AM -0500, Compn wrote:
> > > > On Sat, 30 Dec 2017 22:12:28 +0100, Etienne Buira
> > > > <etienne.buira at free.fr> wrote:
> > > > 
> > > > probably you can put CONFIG_LINUX_PERF in the block above it
> > > > next to this line
> > > > #define CONFIG_POWERPC_PERF 0
> > > 
> > > Hi, thanks for reviewing
> > > 
> > > Done, also removed unconditional define HAVE_MACH_MACH_TIME_H 0 i did
> > > not notice at first.
> > 
> > Unfortunately it is not good for the VCS history to have all
> > changes in one patch. It's much better to have them separated
> > with individual commit messages. Additionally it is also easier
> > to review smaller patches.
> 
> Head email's text were supposed to be commit message. I did only one
> patch because official repo is svn, that AFAIK does not support local
> patchset, and i were not going to fetch a git svn for this small patch.
> It is still relevant for patch's latest version.

Yeah, I also noticed the commit details you posted in your original
message.

Maybe good to know for you: There is a Git mirror (updated a couple
of times per hour IIRC) for MPlayer SVN at:

  git://git.mplayerhq.hu/mplayer


> > I am currently working on AVX512 myself, because it for sure 
> > breaks the build (for internal FFmpeg).
> 
> That's the very reason i came into this (and wanted to limit console
> spamming while at it).

Yeah, unfortunately I was travelling when I noticed the build was
broken :(

I also noticed the console spam before, but never got around to
fixing it since :(

So again thank you very much for tackling this!

> > If you would be willing to split this up into one patch per topic
> > (ideally accompanied by a commit message), that would be great.
> >
> > I will work on the AVX512 part this weekend. As far as time permits
> 
> A thing i noticed on this topic: ffmpeg only has 'avx512' support,
> although avx512 does not refer to a consistent instruction set, but a
> family of instruction sets (avx512f stands for avx512 Foundation for
> instance).
> In my patch, i tested for avx512f only, as ffmpeg does.

I saw that variation in your patch. I have committed a patch to at
least fix the build by disabling AVX-512. In that patch I used the
AVX512 term as it is used in FFmpeg. I think we shouldn't make a
difference here. As I understand it, in FFmpeg it was chosen to take
AVX512 as a baseline (including F (Foundation)) for supporting CPUs
from maybe 2017 and onwards. See the FFmpeg/x264 rationale in this
commit message:

  http://ffmpeg.org/pipermail/ffmpeg-cvslog/2017-December/111815.html

  "AVX-512 consists of a plethora of different extensions, but in order to keep
  things a bit more manageable we group together the following extensions
  under a single baseline cpu flag which should cover SKL-X and future CPUs:
   * AVX-512 Foundation (F)
   * AVX-512 Conflict Detection Instructions (CD)
   * AVX-512 Byte and Word Instructions (BW)
   * AVX-512 Doubleword and Quadword Instructions (DQ)
   * AVX-512 Vector Length Extensions (VL)"

  

[...]

  Alexander