On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote: > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote: > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote: > > > On Wed, 2 Nov 2016, Diego Biurrun wrote: > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote: > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote: > > > >>Technically, having a _neon prefix for them is wrong, but anything else > > > >>(omitting these two while hooking up avg32/avg64 separately) is more > > > >>complication - although I'm open for suggestions on how to handle it > > > >>best. > > > > > > > >Where exactly is the complication? In the way you assign the function > > > >pointers in the init file? > > > > > > Yes, it'd require splitting up those macros a bit; either for assigning > > > the > > > same function pointers, but with a different simd instruction set suffix, > > > or > > > for only assigning the avg function pointer for those sizes. > > > > Try something like > > > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64 > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64 > > > > before the assignment macros. You don't have to somehow drop some of the > > assignments in the macros then. There's precedent for this in some of the > > x86 init files. > > That only fixes the function names but not the cpu_flag based assignment > if I understand it correctly. And it is a little bit silly since neon is > not really optional on aarch64. At least in the Application profile.
I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64 should be assigned to the function pointer unconditionally before checking for neon support. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
