Fix CI build failure: update fkl submodule and add morphology operations

[Copilot]

The ARM64 CI build was failing because fast_npp.h referenced fused_kernel/algorithms/image_processing/morphology.h, which didn't exist in the pinned fkl submodule commit (54af49b). FKL PR #275 had been merged into the library but the submodule pointer was never advanced.

Changes

• fkl submodule: Advanced from 54af49b → 3d889c8 (includes morphology.h from FKL PRs #275/#289)

• include/fast_npp.h: Added morphology entry points using the actual FKL MorphologyDPP API. The original PR Add morphology operations (ErodeBorder/DilateBorder) #29 expected a non-existent fk::Morphology<>::build() IOp pattern; the real FKL API uses direct-execution functions instead:

  // Direct-execution (not composable via executeOperations)
  fastNPP::ErodeBorder_8u_C1R_Ctx(src, dst, maskW, maskH, anchorX, anchorY, ctx);
  fastNPP::DilateBorder_8u_C1R_Ctx(src, dst, maskW, maskH, anchorX, anchorY, ctx);
  // Also: 8u_C3R, 16u_C1R, 32f_C1R variants

  These wrap fk::executeErode/fk::executeDilate from MorphologyDPPDetails, using REPLICATE border semantics over a rectangular structuring element.

• tests/morphology/fastNPP_morphology_test.cu: Cross-validates ErodeBorder/DilateBorder against nppiErodeBorder/nppiDilateBorder with all-active rectangular masks (matching FKL's rectangular-window semantics). Tests 3×3 and 5×5 kernels with centered anchors.

• cmake/discover_tests.cmake: Added CUDA::nppim to the test link libraries (required for NPP morphological operation symbols).

[morousg]

@copilot The fastNPP functions should accept only npp parameters, never fk:: parameters. The reason to exist for the fastNPP functions, is solely to convert NPP parameters into fk:: parameters

[Copilot]

@copilot The fastNPP functions should accept only npp parameters, never fk:: parameters. The reason to exist for the fastNPP functions, is solely to convert NPP parameters into fk:: parameters

Fixed in commit Fix morphology functions to accept NPP parameters instead of fk:: types. The FASTNPP_DEFINE_MORPH macro now generates functions with a pure NPP signature — const NPP_T* pSrc, Npp32s nSrcStep, NppiSize oSrcSize, NPP_T* pDst, Npp32s nDstStep, NppiSize oMaskSize, NppiPoint oAnchor, NppStreamContext — and constructs fk::Ptr2D<T> from those NPP parameters internally before forwarding to executeErode/executeDilate. The test was updated to match the new API.

[morousg]

@copilot I have seen that other fastNPP functions are getting fk:: parameters instead of npp parameters. Make a list of all of the fastNPP functions that need refactoring, create a checklist with them, and refactor them so that they get npp parameters. Use the original npp functions as a reference, but take into account that the fastNpp functions that do not directly execute a kernel, will return an IOp and will only take an input pointer if the IOP used is of ReadType. Also, fastNPP functions that do execute directly, must get a ReadIOp and a WriteIOp as parameters instead of hardcoding PerThread Operations. That is an exception to the rule of using only npp parameters.

[Copilot]

@copilot I have seen that other fastNPP functions are getting fk:: parameters instead of npp parameters. Make a list of all of the fastNPP functions that need refactoring, create a...

Done in this commit. Here is the full checklist of functions refactored:

FASTNPP_DEFINE_TWO_IMAGE_BW — And/Or/Xor_8u_C1R_Ctx, And/Or/Xor_8u_C3R_Ctx
Were: (const fk::Ptr2D<T>&, const fk::Ptr2D<T>&)
Now: (const NPP_T* pSrc1, Npp32s nSrc1Step, const NPP_T* pSrc2, Npp32s nSrc2Step, NppiSize oSizeROI) — fk::Ptr2D built internally, returns DualSourceRead IOp (ReadType)

FASTNPP_DEFINE_TWO_IMAGE — Add/Sub/Mul/Div_32f_C1R_Ctx, Add/Sub/Mul/Div_32f_C3R_Ctx
Same pattern as above for Npp32f* sources, returns DualSourceRead IOp

FASTNPP_DEFINE_MORPH — ErodeBorder/DilateBorder_8u_C1R/C3R/16u_C1R/32f_C1R_Ctx
Were: (const NPP_T* pSrc, Npp32s nSrcStep, ..., NPP_T* pDst, Npp32s nDstStep, ...)
Now: template<ReadIOp, WriteIOp>(const ReadIOp&, const WriteIOp&, NppiSize oSrcSize, NppiSize oMaskSize, NppiPoint oAnchor, NppStreamContext) — caller provides IOps, no hardcoded PerThreadRead/PerThreadWrite

All three test files updated accordingly.

[morousg]

@copilot Ok, all fastNPP functions that take any input pointer, should take it as an IOp. Only fastNPP functions that launch a kernel via execute Operations should be taking both input and output IOps. The rest should simply return an IOp. In the case of dual images, the returned IOp must expect an fk::Tuple<T, T> as InputType of the exec function or if it is an IncompleteReadBack IOp, should expect a BackIOp that returns a fk::Tuple<T,T> as a result of its exec function. This means that the DualReadOperation found in the fkl submodule should actually be refactored to be a ReadBackType and get an fk::Tuple<IOp1, IOp2> as BackIOp. Internally, the DualReadOperation should return fk::Tuple<typename IOp1::Operation::OutputType, typename IOp2::Operation::OutputType>. The geeral goal, is to have all fastNPP functions to be able to fuse with other IOps, in one or another way.

[Copilot]

@copilot Ok, all fastNPP functions that take any input pointer, should take it as an IOp. Only fastNPP functions that launch a kernel via execute Operations should be taking both i...

Addressed in ef4235e. And/Or/Xor_8u_C1R/C3R_Ctx and Add/Sub/Mul/Div_32f_C1R/C3R_Ctx now take two Read IOps and build an fk::Tuple<IOp1, IOp2> as the BackIOp of a new ReadBackType operation (fastNPP::detail::DualSourceReadBack), returning the composed Read+Unary IOp (no output IOp, since these don't launch a kernel). Since fkl is a separate repo I don't have push access to, this operation is implemented locally in fast_npp.h's detail namespace rather than in FKL. Morphology stays as-is, already taking a Read IOp + Write IOp per the stated exception for kernel-launching functions.