Use more descriptive ElementwiseKernel names in cucim.skimage

[grlee77]

This PR is mainly for convenience when profiling or otherwise inspecting custom kernels produced by the cucim.skimage package.

This PR makes all kernel names start with cucim_skimage_ which helps to differentiate them from kernels originating elsewhere.

Most CuPy kernels start with cupy_ or cupyx_. I opened a similar PR upstream to fix some inconsistencies there: cupy/cupy#5551

[jakirkham]

Thanks Greg! 😄

This seems like a nice change. Would these be picked up by NVTX?

Am curious if we can automate the name generation a bit like using the module and function __names__. WDYT?

[grlee77]

Would these be picked up by NVTX?

I think so, but haven't tried it. I wrote a script that would create a temporary CuPy cache directory and then run the full CuCIM test suite, saving any runtime-generated kernels. Each .cu file ends up named with a hash generated by CuPy, but it is fairly easy to extract the kernel name from the file (since there is only one kernel defined per file) and rename the files accordingly. I was doing this just out of curiosity of how many kernels get generated at runtime from local kernels vs. cupy vs. cupyx.scipy, etc.

It turns out about 2,000 kernels get generated while running the test suite! This doesn't count the use of precompiled kernels in libraries like cuBLAS or cuFFT, just the ones compiled by NVRTC at run time.

Am curious if we can automate the name generation a bit like using the module and function names. WDYT?

We could, but I'm not sure it is worth the trouble at this point. It is still sometimes helpful to append some additional info such as boundary mode or number of dimensions, etc to kernel names.

[jakirkham]

Gotcha. Well I'd hope we wouldn't need to understand the hashes used to read an NVTX trace, but maybe this is a separate discussion.

That doesn't surprise me. Particularly with the combination of different types, shapes (if relevant), etc.

Just for context, am thinking something like this...

def func():
    pass

print("_".join([__name__, func.__name__, ...]))

[quasiben]

Is this now ready to be merged in ?

[grlee77]

I think so

[quasiben]

@gpucibot merge