[DRAFT] cavs-nocodec: drop the extra mixers

[kv2019i]

Draft PR to see how much dropping the two unnecessary mixer components would bring.

Includes:

• patch to measure DSP load (ll_schedule: add a DSP load tracker to ll_tasks_execute #4943)
• documentation fixes (to be submitted separately, I'll add the PR here)
• the actual tplg change

[kv2019i]

Results can be seen now in CI results.

SOF main with mixer:
https://sof-ci.01.org/sofpr/PR4943/build10955/devicetest/?model=ADLP_RVP_NOCODEC&testcase=multiple-pipeline-all
Worst case load when streams are running:
[ 6230869.283657] ( 2323.906250) c0 ll-schedule ./schedule/ll_schedule.c:139 INFO ll avg 43889/38400

Same with this patch (two mixers):
https://sof-ci.01.org/sofpr/PR4948/build10968/devicetest/?model=ADLP_RVP_NOCODEC&testcase=multiple-pipeline-all
Worst case load:
[ 10039033.976085] ( 4546.093750) c0 ll-schedule ./schedule/ll_schedule.c:139 INFO ll avg 37764/38400

So that's a 14% reduction in worstDSP load (115% -> 98%).

The target would be to keep the per-core DSP load under 80%. #4940 and #4944 will both help, but to reach 80%, we should probably consider dropping the unnecessary mixers. @ranj063 is there some reason you added mixers to all?

[ranj063]

@ranj063 is there some reason you added mixers to all?

@kv2019i the reason we added the mixer to all is because of 2 reasons:

1. the SSP port that we want to add the deep buffer pipeline to is different for BXT compared to other platforms. It was easier to make all playback pipelines mixer-based and then just add the deep-buffer pipeline wherever needed. easier to review as well
2. we want to move away from the general idea of pipelines extending all the way from the host to a DAI. So the split to have a from-end pipeline or host -facing pipeline connected to a backend pipeline is the right thing to do

[kv2019i]

@ranj063 is there some reason you added mixers to all?

@kv2019i the reason we added the mixer to all is because of 2 reasons:

1. the SSP port that we want to add the deep buffer pipeline to is different for BXT compared to other  platforms. It was easier to make all playback pipelines mixer-based and then just add the deep-buffer pipeline wherever needed. easier 

Ack, and indeed I broke the APL nocodec config with this version of the PR.

2. we want to move away from the general idea of pipelines extending all the way from the host to a DAI. So the split to have a from-end pipeline or host -facing pipeline connected to a backend pipeline is the right thing to do

Hmm, why? Wouldn't be importat to test both kind of topologies?

Still, even if we agree on that target, it's still not ok to overload the DSP, so we have to find another way to meet the above goal, but do it in a way that keeps the per-core DSP load at sensible level (<80% is good magic number).

I'll wait until @singalsu 's optimization work for mixer and iir-eq are merged and do a re-measurement. If we are still above 80%, we should either drop one (or two mixers), or come up with another way to realize a two part pipeline.

[plbossart]

2. we want to move away from the general idea of pipelines extending all the way from the host to a DAI. So the split to have a from-end pipeline or host -facing pipeline connected to a backend pipeline is the right thing to do

Hmm, why? Wouldn't be importat to test both kind of topologies?

Simple:
a) if you already have a split between host and dai pipeline, it's trivial to add a second source or N sources to a mixer. Or alternatively we can remain with a single source and be iso-feature/iso-load.

b) If we have pre-canned pipelines that go from host to dai in one shot, it's virtually impossible to break-up.

So it's not about adding mixers and new sources for the sake of adding them, it's to enable their addition if we need/want to. It's really a flexibility/capability update.

[kv2019i]

1. we want to move away from the general idea of pipelines extending all the way from the host to a DAI. So the split to have a from-end pipeline or host -facing pipeline connected to a backend pipeline is the right thing to do

@plbossart wrote:

Hmm, why? Wouldn't be importat to test both kind of topologies?

Simple: a) if you already have a split between host and dai pipeline, it's trivial to add a second source or N sources to a mixer. Or alternatively we can remain with a single source and be iso-feature/iso-load.

Ack, so this is really to make the tplg a better starting point for future extensions.

So it's not about adding mixers and new sources for the sake of adding them, it's to enable their addition if we need/want to. It's really a flexibility/capability update.

Ack. Let's see if the mixer optimizations help enough. Having the flexibility is of course better, so if they fit the budget (or can be fitted with reasonable extra work), all the better.

[plbossart]

Simple: a) if you already have a split between host and dai pipeline, it's trivial to add a second source or N sources to a mixer. Or alternatively we can remain with a single source and be iso-feature/iso-load.

Ack, so this is really to make the tplg a better starting point for future extensions.

Note that it's only a starting point, we will also have a need for 'intermediate' pipelines that deal with mode effects, see e.g. how Windows represent their processing tree. The layers don't matter for firmware, the point is that we can have two stages of mixers.

[lgirdwood]

@kv2019i the first two patches can go in, no opens for them IIUC..

[kv2019i]

Seems mixers are needed, so close this.