[opus] opus Digest, Vol 72, Issue 17

[Viswanath Puttagunta]

On 3 February 2015 at 01:31, Phil Wang <Phil.Wang at arm.com> wrote:
> Hi all,
>
> I have already added support for scaled forward non-power-of-2 floating-point FFT:
> https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9
>
> Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled.
> By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will
> scale the output. So we can remove need for one buffer on stack mentioned below.

Thanks Phil, I have tested this in my **local setup** and it works for
**non-power-of-2**, mainly for nfft = 60, 120, 240, 480. But any
reason why this functionality cannot be extended to power-of-2 as
well?

Note: Actually, I can no longer even compile latest NE10. What is
working in my local setup is if I just take last patch from commit
(79c3d7873) and apply it to old commit (660c6787). You can see my
working NE10 code at
https://git.linaro.org/people/viswanath.puttagunta/Ne10.git (branch:
rfcv2_ne10_fft)

My compile instructions:
git clone https://github.com/projectNe10/Ne10.git
cd Ne10 && mkdir build && cd build
cmake -DNE10_BUILD_SHARED=ON -DCMAKE_TOOLCHAIN_FILE=../GNUlinux_config.cmake ..
make -j6

Timothy/All.
Having scaling capability for non-power-of-2 will work for non-custom
modes(nfft = 60, 120, 240 and 480).

What should we do for power-of-2? I really want to avoid putting
runtime checks if nfft is power of 2 in opus_fft_float_neon.

>
> As for the _t API style, it may confuse existing users if we provide two API for the same functionality or if we modify the existing API. How about we keep the typedefs in Opus? For example:
> typedef ne10_int32_t ne10_int32;
> typedef ne10_fft_cpx_float32_t ne10_fft_cpx_float32;
>
> It would not be too ugly if we put them together somewhere and document them well enough. It is a tiny cost to integrate a 3rd party library.

Timothy/All,
Can we please get some guidance/consensus on this so we can move forward?

>
> What's more, we have provided a wrapper for NE10_FREE, so that we can make sure memory allocated by Ne10 will be freed by Ne10:
> https://github.com/projectNe10/Ne10/commit/24cecb105d238e5629cecff60968b31d74e54c2a
>
>
> Best Regards,
> Phil Wang
>
>> Date: Fri, 30 Jan 2015 17:41:22 -0600
>> From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org>
>> Subject: Re: [opus] [RFC PATCH v1 2/2] armv7(float): Optimize encode
>>       usecase using NE10 library
>> To: "Timothy B. Terriberry" <tterribe at xiph.org>
>> Cc: "opus at xiph.org" <opus at xiph.org>
>> Message-ID:
>>       <CAE+8thixRitZx8XBpQJZSHTOHDA-F4tQ7kR-
>> uANHghGdRHhUCQ at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 30 January 2015 at 02:38, Timothy B. Terriberry <tterribe at xiph.org>
>> wrote:
>> >
>> > Viswanath Puttagunta wrote:
>> >>
>> >> Is the peak stack usage a complete blocker in current form?
>> >
>> >
>> > Since this only affects people who enable NE10, I don't think this is a blocker.
>> I discussed this and comment about _t with Phil at NE10_ARM. He committed
>> to two changes:
>> 1. Change API to address usage of _t from NE10 api for following types:
>>    ne10_int32_t              ------> will become ----> ne10_int32
>>    ne10_fft_cpx_float32_t ------> will become ----> ne10_fft_cpx_float32
>>    ne10_fft_state_float32_t ------> will become ---> ne10_fft_state_float32
>>    ne10_fft_cfg_float32_t   -----> will become ----> ne10_fft_cfg_float32
>>
>> 2. Provide scaling as argument to ne10_fft_c2c_1d_float32_neon() and
>> remove need for one buffer on stack (ALLOC(tempin, st->nfft,
>> ne10_fft_cpx_float32_t);). We will still need cfg->buffer. So, peak stack usage
>> goes up by ~3.8K instead of ~7.5K.
>>
>> Hope to get the RFCv2 by end of next week.
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
>
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus