Open marcinszkudlinski opened 1 year ago
@marcinszkudlinski The list of suggested improvements seem appealing, we should always try to do better, but allow me to put on my 'bad cop' hat to help clarify the directions.
a) What exactly does "Till now such approach was fine but is getting out of hands. Is consuming a lot of memory, is slow" You will have to bring a lot more data to make a case for a change. Most of the memory issues we'd had were because of very large 3rd party modules, it's not clear to me what the pipeline infrastructure costs. The slowness is not clear either.
b) The wording also suggests that it's not possible to support DP scheduling without changing the pipeline level, which is not something I've heard before.
c) "The right moment" looks to me as the "wrong time and wrong place". We are half-way through the IPC4 introduction, there's no way any engineering manager in their right mind would accept to change the plumbing and have to redo all the validation, unless there's a clear showstopper preventing us from reaching the committed goals.
d) Also before we talk about a flag day, have you considered breaking down this feature into smaller more achievable ones? Can we e.g. drop the component API and use the module API? what can be improved in steps to reduce the revalidation cost?
e) And last, please do not forget that there is no replacement for IPC3 for non-Intel platforms. It's not deprecated as you state it. IPC4 is actually the outlier, not the norm.
@marcinszkudlinski I've edited and added some check boxes above to make this like an Epic. It can link to smaller features/PRs if needed. Some of the items above are WIP (module API) and some sound like a regression (the unnecessary cache invalidations), the DP queues are new alongside the single LL pipeline buffer (which I think could be made to the current struct buffer APIs).
I would definitely suggest adding more context on the pipeline APIs you want to change/add/delete, this can make the topic easier to plan/align and move forward.
Lets me clarify
Let me raise one more aspect in context of Pipeline 2.0:
Currently IPC4 handler artificially configures modules/pipelines/buffers direction. Direction is not a part of IPC4 protocol and all these operations are forced by IPC3-like, buffer-based LL scheduler.
It makes a lot of problems in the code. Currently we can find parts where UPSTREAM means Host->DAI direction (e.g. in pipeline schedule), and another parts with opposite meaning (e.g. in Copier DAI configuration). It makes a lot of confusion.
IPC4 protocol assumes that modules are created in order from the source to the sink of pipeline. Scheduler should operate always from the source to the sink. No direction alternative is needed for proper scheduling.
Changing scheduler orientation from buffers to modules is a great opportunity to get rid of direction usage in IPC4.
Changing scheduler orientation from buffers to modules is a great opportunity to get rid of direction usage in IPC4.
Added this to the item list.
Data source/sink interface Currently all data between modules are being passed as memory buffers + metadata. Each module manages buffers itself (i.e. takes care of circular buffering)
It is not enough as:
There's a need for an API like "get data" "data consumed ACK" etc. Each module must use the API - as the procedures for each source/sink type is different no module is allowed to modify any metadata (like read/write pointer, amount of data in buffer) by itself
@marcinszkudlinski changes to the module API are already massively invasive, can we try to make smaller steps and avoid combining changes to module, pipeline, scheduler in the same feature request? Things need to be phased and aligned both with validation resources and program timelines. thank you.
OBSOLETE - the newest version here: https://github.com/thesofproject/sof-docs/pull/497 readable version: https://marcinszkudlinski.github.io/sof-docs/PAGES/architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.html
Is your feature request related to a problem? Please describe.
We're heading fast for firmware fully compatible with current windows driver
I order to achieve this:
IPC3 was set as depreciatedTo fit the requirements into current SOF code:
Till now such approach was fine but is getting out of hands. Is consuming a lot of memory, is slow and with high risk of regression in legacy platforms
Describe the solution you'd like
I think there's a right moment to introduce PIPELINE 2.0
using IPC4 nativelyThe list is not 100% complete
Describe alternatives you've considered Keep modifying current pipeline implementation. I my opinion
Additional context