Re: [MPlayer-dev-eng] Adapt config.h's generation with some ffmpeg's commits
- Date: Thu, 4 Jan 2018 23:26:29 +0100
- From: Alexander Strasser <eclipse7@xxxxxxx>
- Subject: Re: [MPlayer-dev-eng] Adapt config.h's generation with some ffmpeg's commits
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@xxxxxxx> 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
Maybe good to know for you: There is a Git mirror (updated a couple
of times per hour IIRC) for MPlayer SVN at:
> > 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
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
> 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
"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)"
MPlayer-dev-eng mailing list