Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DNM] Direct use of cached / not-cached shared memory alias instead of coherent.h in case of buffers #8106

Closed

Conversation

tobonex
Copy link
Contributor

@tobonex tobonex commented Aug 28, 2023

DO NOT MERGE - the PR will be spit to several PRs

All info and context: #8006

@lgirdwood
Copy link
Member

@tobonex fyi - some conflicts (will block CI).

@tobonex tobonex force-pushed the shared_memory_comp_buffer_localcopy branch 24 times, most recently from 62ec1df to 7cfd878 Compare September 4, 2023 09:13
@tobonex tobonex changed the title [CI TEST ONLY] Direct use of cached / not-cached shared memory alias instead of coherent.h in case of buffers Direct use of cached / not-cached shared memory alias instead of coherent.h in case of buffers Sep 4, 2023
@tobonex tobonex marked this pull request as ready for review September 4, 2023 09:22
buffer_acquire and buffer_release are no longer in use
remove stubs from the code

Signed-off-by: Marcin Szkudlinski <[email protected]>
to verify that shared structures are used in a proper way
a debug check is introduced

If compiled with COHERENT_CHECK_NONSHARED_CORES flag
each usage of shared structures will be verified
against proper memory alias usage

Signed-off-by: Marcin Szkudlinski <[email protected]>
@marcinszkudlinski marcinszkudlinski force-pushed the shared_memory_comp_buffer_localcopy branch from 8f30aa9 to 756705c Compare September 6, 2023 08:47
@kv2019i
Copy link
Collaborator

kv2019i commented Sep 6, 2023

Ok, let's do final review going through the details better. Please ack in your approve comment which parts of the patchset you covered (if not all). Target is to merge this PR today.

@marcinszkudlinski
Copy link
Contributor

the most important is to check sparse: remove buffer_acquire / buffer_release

second huge commit -
sparse: remove all sparse_cache from struct sink/source api is created 100% by editor "replace all" so is much less likely be incorrect

other commits have already been discussed and approved

@tobonex
Copy link
Contributor Author

tobonex commented Sep 6, 2023

While working on it I noted some significant changes, some may be outdated:

copier_ipcgtw_process() in copier_ipcgtw.c

mux_get_processing_function in mux_generic.c - buffer was not released here for some reason

dai_dma_cb in dai-zephyr.c err label is hanging after deleting buffer_release here, should we just break the list
loop? If yes what is the best way to do that?

audio_steram.h:1074 above audio_stream_get_source - do we want to delete comment above it now?
also do we want to delete buffer_acquire and buffer_release definitions now?

host_legacy.c: host_common_update() - had to leave the logic here
host_zephyr.c: host_common_update() - had to leave the logic here

module_adapter.c : check if I refactored those correctly: module_adapter_sink_src_prepare,
module_adapter_sink_source_copy

module_adapter_audio_stream_type_copy - leaving variables as they are, just removing sparse_cache. I want to avoid changing multiple functions for this one.

generic.h module_source_info_acquire() : is removing it from coherent ok?

some rebased files to check(all commits):
multiband_drc.c
volume.c

@marcinszkudlinski
Copy link
Contributor

marcinszkudlinski commented Sep 6, 2023

  1. copier_ipcgtw_process() in copier_ipcgtw.c

What about it?

  1. mux_get_processing_function in mux_generic.c - buffer was not released here for some reason

image

  1. dai_dma_cb in dai-zephyr.c err label is hanging after deleting buffer_release here, should we just break the list
    loop? If yes what is the best way to do that?

something worth to look twice.
BTW. please add such comments in the code as review - it is easier

  1. audio_steram.h:1074 above audio_stream_get_source - do we want to delete comment above it now?
    removed

5)also do we want to delete buffer_acquire and buffer_release definitions now?
removed

  1. host_legacy.c: host_common_update() - had to leave the logic here
    ?????

7)host_zephyr.c: host_common_update() - had to leave the logic here
????

  1. module_adapter.c : check if I refactored those correctly: module_adapter_sink_src_prepare,
    module_adapter_sink_source_copy
    module_adapter_audio_stream_type_copy

checked, is OK

  1. generic.h module_source_info_acquire() : is removing it from coherent ok?
    not at this step, left in the code

@tobonex
Copy link
Contributor Author

tobonex commented Sep 6, 2023

mux_get_processing_function in mux_generic.c - buffer was not released here for some reason ????? image

this is dmux_get_processing, i meant the one above, mux_get_processing, sink_c was not released for some reason

@marcinszkudlinski
Copy link
Contributor

marcinszkudlinski commented Sep 6, 2023

this is dmux_get_processing, i meant the one above, mux_get_processing, sink_c was not released for some reason

right, there was no release in mux_get_processing_function
looking as those 2 were called I bet is just a forgotten release
image

as long as the buffer was not shared such lack of release have had no negative effects

@lgirdwood
Copy link
Member

ok, this is a problem. We need to play safer here. Can we

  1. Create a new PR that will merge 1st and make coherent.h APIs a NOP i.e. turns then into empty static inline functions for all configurations.
  2. Update this PR on top of PR 1 above and split patch per file. This could even mean breaking this PR into more PRs and incrementally removing coherent APIs. i.e. its no longer a big bang.

This approach means we have remove the performance penalty from coherent and break the work down into more manageable chunk that we can bisect and individually revert patches if needed with no impact to other modules.

@kv2019i
Copy link
Collaborator

kv2019i commented Sep 6, 2023

Checked (potentially less coverage in upstream CI):

  • src/audio/module_adapter/module/cadence.c
  • src/audio/module_adapter/module/dts/dts.c
  • src/audio/module_adapter/module/waves/waves.c

/* NOTE: this func is called from IPC processing task and can be potentially
* called before pipeline start even before buffer has been attached. In such
* case do not report error but return 0 bytes available for GET_DATA and
* 0 bytes free for SET_DATA.
*/
buf_c = NULL;
comp_warn(dev, "copier_ipcgtw_process(): no buffer found");
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

about " copier_ipcgtw_process() in copier_ipcgtw.c" I just meant this if block,
I did not substitute buf for buf_c here, as we do not need to NULL it now

@kv2019i
Copy link
Collaborator

kv2019i commented Sep 6, 2023

@tobonex Can you add the comments inline so it's easier to discuss specific points in the context of the code in question. The comment on dai-zephyr.c sounds a bit scary, but I guess you mean with "hanging" that the error label is left to code where it really is not needed anymore, right? Code is not actually hanging...

@tobonex
Copy link
Contributor Author

tobonex commented Sep 6, 2023

@tobonex Can you add the comments inline so it's easier to discuss specific points in the context of the code in question. The comment on dai-zephyr.c sounds a bit scary, but I guess you mean with "hanging" that the error label is left to code where it really is not needed anymore, right? Code is not actually hanging...

Yes, I'm making the comments now. And yes I meant the label is pointing at the end of block, not execution stopping.

@marcinszkudlinski
Copy link
Contributor

@tobonex Can you add the comments inline so it's easier to discuss specific points in the context of the code in question. The comment on dai-zephyr.c sounds a bit scary, but I guess you mean with "hanging" that the error label is left to code where it really is not needed anymore, right? Code is not actually hanging...

I'm double checking dai-zephyr right now

}
}
err:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at it again I think I made a mistake here, I moved the label out of the list loop. It seems the loop does not stop after an error, and just continues on to the next iteration, as error label was there to just release the buffer. Will it jump correctly if it points to end of a loop block?

Copy link
Contributor

@jxstelter jxstelter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Module_adapter, ipc

@kv2019i kv2019i changed the title Direct use of cached / not-cached shared memory alias instead of coherent.h in case of buffers [DNM] Direct use of cached / not-cached shared memory alias instead of coherent.h in case of buffers Sep 6, 2023

if (!comp->is_shared)
comp_make_shared(comp);
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks bogus


processed_data.source_bytes = 0;

/* convert format and copy to each active sink */
for (i = 0; i < num_output_buffers; i++) {
struct comp_buffer __sparse_cache *sink_c;
struct comp_buffer *sink_c;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we drop "_c" from sink_c and src_c

@marcinszkudlinski
Copy link
Contributor

closing, this PR has been split to several smaller parts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants