Closed Bug 1221830 Opened 4 years ago Closed 4 years ago

double maximum realtime convolver stage size

Categories

(Core :: Web Audio, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox45 --- fixed

People

(Reporter: karlt, Assigned: karlt)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

Attachments

(5 files)

ReverbConvolver limits the size of stages on the rendering thread and staggers
their FFT calculations to avoid doing too much work during the processing of a
single block.

RealtimeFrameLimit consists of 11 MaxRealtimeFFTSize stages and the initial
smaller size-doubling stages.  There are 8 phase-offset positions (1024/128)
for the MaxRealtimeStages, and so, at 3 offsets, two MaxRealtimeFFTSize stages
are performing their FFTs at the same time.

Further, all the initial smaller size-doubling stages perform their FFTs while
processing a block that processes two MaxRealtimeFFTSize stages.  The
computation during that block is then similar to performing FFTs for three
MaxRealtimeFFTSize stages.

If doing this much computation during one block anyway, we should instead
double MaxRealtimeFFTSize to double the efficiency of the stage.  And we can
stagger the stages so that the maximum FFT work during any processing block is
reduced.
Depends on: 1221831
I'll submit patches that reduce rendering thread CPU usage for this testcase by 18%.
bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot
Attachment #8683440 - Flags: review?(padenot)
bug 1221830 use WEBAUDIO_BLOCK_SIZE slice size for background convolver thread r?padenot

as with the main thread.

The comment was incomplete as ReverbConvolverStage also supports multiples of
the FFT halfsize, but only values up to WEBAUDIO_BLOCK_SIZE.
Attachment #8683441 - Flags: review?(padenot)
bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot
Attachment #8683442 - Flags: review?(padenot)
bug 1221830 double maximum realtime convolver stage size to 2048 r?padenot

Now, the most FFT work that happens during one realtime processing block is
when one 2048-size stage and the 256-size stage are performed at the same
phase-offset.  Before FFT timing was controlled by initial input buffer offset
(bug 1221831), two 1024-size stages as well as the 512- and 256-size stages
performed FFTs at one offset.  Thus, the maximum work in one block is reduced
by a ratio of about 11 to 9.

Measurements also indicate a similar reduction in total rendering thread
CPU usage.

Previously the alignment of the eleven 1024-size realtime stages was such
that, in three consecutive blocks, two 1024-size stages would peform their
FFTs.  Now, the 2048-size stages is aligned so that none of these perform
their FFTs in consecutive blocks.
Attachment #8683443 - Flags: review?(padenot)
Attachment #8683440 - Flags: review?(padenot) → review+
Comment on attachment 8683440 [details]
MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot

https://reviewboard.mozilla.org/r/24341/#review21843
Attachment #8683441 - Flags: review?(padenot) → review+
Comment on attachment 8683441 [details]
MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE slice size for background convolver thread r?padenot

https://reviewboard.mozilla.org/r/24343/#review21845
Attachment #8683442 - Flags: review?(padenot) → review+
Comment on attachment 8683442 [details]
MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot

https://reviewboard.mozilla.org/r/24345/#review21847
Comment on attachment 8683443 [details]
MozReview Request: bug 1221830 double maximum realtime convolver stage size to 2048 r?padenot

https://reviewboard.mozilla.org/r/24347/#review21857

::: dom/media/webaudio/blink/ReverbConvolver.cpp:138
(Diff revision 1)
> +                phaseLookup[m_stages.Length() % ArrayLength(phaseLookup)];

Hrm, not having much documentation for all the rest of the blink code did not help understanding this, but I think I get it now.  The numbers are a bit magical at first glance though.
Attachment #8683443 - Flags: review?(padenot) → review+
Rank: 12
Priority: -- → P1
https://reviewboard.mozilla.org/r/24347/#review21857

> Hrm, not having much documentation for all the rest of the blink code did not help understanding this, but I think I get it now.  The numbers are a bit magical at first glance though.

They are a bit magical I'm afraid.  I think there is sense in positioning FFTs mid way between FFTs of the previous stage during the doubling process.  For positioning the five MaxRealtimeFFTSize stages across the 16 positions, I didn't come up with the any nice algorithm.  It turned out that there were not many options where these stages were not aligned in consecutive blocks and not aligned with the FFTs of the next two smaller sizes.  I picked the only option where the first MaxRealtimeFFTSize position was consistent with the doubling process and we didn't perform FFTs for two MaxRealtimeFFTSize stages and one MaxRealtimeFFTSize/2 stage in three consecutive blocks.
You need to log in before you can comment on or make changes to this bug.