enable ops to support span

[tntwise5]

This is from my fork, https://github.com/TNTwise/SPAN-ncnn-vulkan/tree/master. Span can offer faster render times, while beating even some transformer-based super resolution architectures, and is similar in psnr to SwinIR. It works fine with ncnn, as long as some ops are enabled within ncnn. The models in the span repo should just work with upscayl after these changes, and can be exported with some versions of chainner nightly, https://github.com/chaiNNer-org/chaiNNer-nightly/releases/tag/2024-04-07.

[TNTwise]

Clarification: chainner does not work to convert span pytorch models to ncnn, you would need to use a script like https://github.com/TNTwise/SPAN-ncnn-vulkan/blob/master/export_span_spandrel.py

[aaronliu0130]

@NayamAmarshe @TGS963 just changes the config, LGTM

[TGS963]

Yeah looks fine to me as well, waiting for @NayamAmarshe s input

[TGS963]

Probably should test a build though with this branch

[NayamAmarshe]

Thanks for the PR! Could you please explain more how this works? Is SPAN a different algorithm than Real-ESRGAN? If yes, how can the Real-ESRGAN code infer SPAN?

[TNTwise]

Span is a different algorithm than esrgan but Ncnn can inference any layer that is enabled on compile time, and the code is just in the param file. Only thing that needs to line up is the input layer name and the output layer name. If all the ops are enabled, it doesn't matter what is in the middle.

Here is the span code https://github.com/hongyuanyu/SPAN, and you can export models using my script https://github.com/TNTwise/Universal-Pytorch-Upscaler with this example command

./UniversalTorchUpscaler -m . -n 2x_ModernSpanimationV1.5.pth -e ncnn --half

The -m is the path leading to the model, -n is the name of the model, -e is the export option, and half means half precision (this is usually what is exported when it comes to ncnn, as fp32 and fp16 have no difference)