2018-12-17 8:37 GMT+01:00, Lauri Kasanen <c...@gmx.com>: > On Mon, 17 Dec 2018 01:03:36 +0100 > Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> 2018-12-16 10:06 GMT+01:00, Lauri Kasanen <c...@gmx.com>: >> > This function wouldn't benefit from VSX instructions, so I put it >> > under altivec. >> > >> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt >> > grayf32le \ >> > -f null -vframes 100 -v error -nostats - >> > >> > 3743 UNITS in planar1, 65495 runs, 41 skips >> > >> > -cpuflags 0 >> > >> > 23511 UNITS in planar1, 65530 runs, 6 skips >> > >> > grayf32be >> > >> > 4647 UNITS in planar1, 65449 runs, 87 skips >> > >> > -cpuflags 0 >> > >> > 28608 UNITS in planar1, 65530 runs, 6 skips >> > >> > The native speedup is 6.28133, and the bswapping one 6.15623. >> >> > Fate passes >> >> I wonder a little how, given that grayf32 already breaks fate as-is... > > Are the tests for it disabled? fate.ffmpeg.org reports 100% success for > many platforms.
Iirc, it is broken with --disable-sse >> Note that this function / this pix_fmt currently has no real use-case >> afaict. > > Is there a list of which pix fmts are useful? Of course I don't want to > waste both my and reviewers' time, if the format is considered for > removal or otherwise broken. The pix_fmt is not deprecated (it's new), what I meant was that it is currently only used for obscure monochrome Photoshop images and one filter, so I am not sure optimizing this colour conversion will help often. But this is of course not very much related to this patch, sorry for the noise! Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
