Re: Adapt config.h's generation with some ffmpeg's commits

Alexander Strasser <[email protected]>
Newsgroups gmane.comp.video.mplayer.devel
Message-ID <[email protected]>
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
> > > > <[email protected]> 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
_______________________________________________
MPlayer-dev-eng mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.