I need to extend the library with at least a one-dimensional convolution including native MKL support for signal processing purposes. When I’m already at it, we can also easily provide two-dimensional convolution with MKL support. Are you interested in this contribution, and if yes, do you have any suggestions about the architecture?
My first idea was to create a static Convolution class with convenience methods and in the backend provide a C# and a native MKL provider for it. The disadvantage of having another MKL provider would be that I’d have to duplicate a lot of code from other MKL providers.
Wouldn’t it make sense to only have one MKL provider that implements all kinds of provider interfaces? I know that’s a major refactoring that’s why I did not want to make this change without asking first.
Yes, a proper convolution implementation would certainly be in scope of Numerics, I’d happly accept a contribution in this area.
The providers are essentially designed as you describe - there is one shared provider backend using Intel MKL which supports and implements multiple frontends/interfaces, like linear algebra and FFT. Other provider backends like OpenBLAS typically support only one of them. Frontends therefore need to be scoped small enough that they can typically be implemented completely also for alternative backends.
Admittedly, the frontends are a bit more than just a C# interface, since there is some need for control (mainly discovery, loading, unloading, compatibility checks and auto-configuration). But beyond the control classes there should not be too much code duplication. Unless I miss something?
That being said, given how closely convolution is related to fourier transforms, it could also be an option to implement convolution within the FFT provider frontend. If we ever build a backend using fftw or cuFFT instead of MKL, IMO it should be feasible to support convolution there as well.