GPU Quadmesh support

[jonmmease]

This PR adds support for aggregating quadmesh glyphs using cuda. The cuda codepath is invoked when the data backing the provided xarray.DataArray is a cupy.ndarray.

I'm seeing 20-50x speedups in both the rectilinear and curvilinear cases.

Here are some examples: https://anaconda.org/jonmmease/gpu_quadmesh_pr/notebook

[jbednar]

Fabulous! Looks good to me, for what I can see. A release is planned for tomorrow or soon thereafter, so I won't merge now, but let me know when it's ready and I'll merge after release.

[philippjfr]

Wow! Great stuff, looking forward to trying this, the PR to add support for this in HoloViews should only be a couple of lines.

[jonmmease]

Tests passing now, so this is good-to-go from my end

[philippjfr]

I certainly wouldn't mind to announce this along with the other GPU support in HoloViews 1.13.0.

[jonmmease]

FWIW, I'm starting to look at GPU support for raster, but that's going be much more involved and not ready for a while. So, I'd say go ahead with releasing Quadmesh support (whenever that is) separately from raster.

[jbednar]

Would it be possible to run a benchmark where you convert a raster to a quadmesh and compare GPU quadmesh vs. CPU raster? That might be a speedup already, and then we can wait for the real raster speedup when it's ready.

[jonmmease]

Would it be possible to run a benchmark where you convert a raster to a quadmesh and compare GPU quadmesh vs. CPU raster?

Sure, that's a good idea.

[jonmmease]

Unfortunately there's not much benefit (at least on my workstation). The raster implementation is parallelized well on the CPU and is much faster than the single threaded quadmesh implementation.

The GPU quadmesh is about on par with the raster (with a factor of 2 either way depending on input size).

[jbednar]

Good to know, thanks! It's always interesting to see how hardware and algorithm choice interact to give the final performance on any particular problem.