Repository navigation
Fixes for multi-core support - #7835
serhiy-katsyuba-intel wants to merge 2 commits into
Conversation
ipc4_create_buffer() uses comp_get_attribute(, COMP_ATTR_BASE_CONFIG, ) which returns module's struct processing_module::priv.cfg.base_cfg. Since buffer and module could be created on different cores, this fix makes sure module's struct processing_module is allocated in non-cached memory and can be read from any core. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
pipeline_get_dai_comp_latency() iterates over all pipelines and reaches to struct pipeline::pipeline_id. This fix ensures that struct pipeline can be read from any core. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
| dev->drv = drv; | ||
|
|
||
| mod = rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM, sizeof(*mod)); | ||
| mod = rzalloc(SOF_MEM_ZONE_RUNTIME_SHARED, 0, SOF_MEM_CAPS_RAM, sizeof(*mod)); |
There was a problem hiding this comment.
Please use kconfig option - non_coherent_pipeline_workaround or similar
this is not a target sollution, not a fix at all
There was a problem hiding this comment.
how can a buffer and a module, attached to it, be allocated on different cores? Shouldn't both be done on the target core, where the pipeline will run? However, if this is for the case when parts of a stream are running on different cores, then this is still not supported and we still have bigger issues to fix for that. It is good to gradually prepare for that and fix parts that we come across, but I'd agree with @marcinszkudlinski that this needs to be considered carefully: ATM we don't have such use cases so for now it doesn't fix anything, but it probably will slow things down somewhat.
There was a problem hiding this comment.
That ipc4_create_buffer() was called for buffer between two components on different pipelines and pipelines are on different cores. To get obs size ipc4_create_buffer() reaches component's base_cfg. The problem is that ipc4_create_buffer() was called from one core but that componet's base_cfg was allocated and written on another core.
Seems such problem only happens for buffers between pipelines on different cores, not sure.
So, yes, probably, this problem should be fixed by ensuring ipc4_create_buffer() is called from correct core.
There was a problem hiding this comment.
@serhiy-katsyuba-intel connecting components or pipelines on different cores is unsupported ATM
There was a problem hiding this comment.
we need to fix it, cross core bind LL-DP is something we DO need and we need it soon
There was a problem hiding this comment.
@marcinszkudlinski sure, so somebody has to get to work on this and get it done ASAP
| dev->drv = drv; | ||
|
|
||
| mod = rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM, sizeof(*mod)); | ||
| mod = rzalloc(SOF_MEM_ZONE_RUNTIME_SHARED, 0, SOF_MEM_CAPS_RAM, sizeof(*mod)); |
There was a problem hiding this comment.
how can a buffer and a module, attached to it, be allocated on different cores? Shouldn't both be done on the target core, where the pipeline will run? However, if this is for the case when parts of a stream are running on different cores, then this is still not supported and we still have bigger issues to fix for that. It is good to gradually prepare for that and fix parts that we come across, but I'd agree with @marcinszkudlinski that this needs to be considered carefully: ATM we don't have such use cases so for now it doesn't fix anything, but it probably will slow things down somewhat.
|
|
||
| /* allocate new pipeline */ | ||
| p = rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM, sizeof(*p)); | ||
| p = rzalloc(SOF_MEM_ZONE_RUNTIME_SHARED, 0, SOF_MEM_CAPS_RAM, sizeof(*p)); |
There was a problem hiding this comment.
mostly the same for this: no, let's not do this now. We'd need to make almost all pipeline / component / module allocations uncached now.
|
This workaround is also required to make DP modules working on secondary cores |
|
Closing, properly fix in #7951 |
(1)
module_adapter: Fix for multi-core usage
ipc4_create_buffer() to get ibs/obs size uses comp_get_attribute(, COMP_ATTR_BASE_CONFIG, ) which returns module's struct processing_module::priv.cfg.base_cfg. Since buffer and module could be created on different cores, this fix makes sure module's struct processing_module is allocated in non-cached memory and can be read from any core.
(2)
Fix pipeline allocation for multi-core usage
pipeline_get_dai_comp_latency() iterates over all pipelines and reaches to struct pipeline::pipeline_id. If pipeline was created on core different from the core making pipeline_get_dai_comp_latency() call, reading pipeline_id returns wrong value. This fix ensures that struct pipeline can be read from any core.
WARNING: these fixes could potentially affect performance. I did not do any performance measurements with and without these modifications.
It might be possible to fix same problems without simply using non-cached memory but with some more complex solution. So the ideas are welcomed whether we can merge these fixes as is or we could come out with better solutions.
These are backports of fixes we already have on mtl-005-drop-stable.