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