Automating Module to work for all type of memory types.

[yashrajsapra]

For automating any module , which can take any type of memory pin as input ( CPU, DMA or CUDA ) and that module should give some output frame. We can use a Strategy pattern for handling which Strategy to be used based on input memory type. But if we need to automate the module in such a way that each module is capable of sending any type of output memory. Which approach we should use?

I think we can't use an approach in which input mem type should be the same as output mem type because internally we do some operations that will convert one memory type to other. So Should we pass output memory type in props? Or should we do something else

[kumaakh]

IMHO It is not a good idea to have variability in output pins, each module should support a definitive output pin type. Now if the pipeline author needs a different output they can always use another module to do the conversion to their desired output type. Also It is also OK to have the output pin type depend on input pin type, though that is not a must.

In your current example it means that the If input pin is CPUMem, output will be CPUMem, if input in CUDAMem, output will also be CUDAMem. If pipeline author wants to move the output from CUDAMem to CPUMem, she will have to use a MemoryConversionModule to achieve the same which is another reusable module.

[yashrajsapra]

One use case of supporting multiple input mem type can also be -> to use a single module for doing an operation irrespective of what the input mem type is. If we will have support to variable output pin we don't need to write a separate module for that. For example, if a module input pin is DMA for that we don't need to do memcpy ,we just wrap that inside DMAFDWrapper class and we get CPU or CUDA ptr so we can also directly send those frames even the input is DMA. For CPU and CUDA ptr it's true that input should be same as the output and then we can do any mem conversion. But for DMA I think we need to give this support.

[kumaakh]

Yes I agree we should avoid memcpy at all costs, So here the idea should be that the Module looks at it's input pin and next module's input pin to decide what to do. This is called as "resolve pin" so here the input out pairs are as follows Input Output CPUMem CPUMem CUDAMem CUDAMem DMA CPUMem (if next Module requires CPUMem) DMA CUDAMem (if next Module requires CUDAMem) Again the intention is to avoid "automatically" memcpy. If the Pipeline author wants something else they will add a MemoryTransferModule to achieve that

…

On Thu, Feb 3, 2022 at 11:14 AM yashrajsapra ***@***.***> wrote: One use case of supporting multiple input mem type can also be -> to use a single module for doing an operation irrespective of what the input mem type is. If we will have support to variable output pin we don't need to write a separate module for that. For example, if a module input pin is DMA for that we don't need to do memcpy ,we just wrap that inside DMAFDWrapper class and we get CPU or CUDA ptr so we can also directly send those frames even the input is DMA. For CPU and CUDA ptr it's true that input should be same as the output and then we can do any mem conversion. But for DMA I think we need to give this support. — Reply to this email directly, view it on GitHub <#68 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWFNAQRSONOF45UIEUOVBTUZKSYFANCNFSM5NO7VCRA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>