Skip to content

dask+cupy geodesic slope eagerly materializes full lat/lon grids on GPU #2762

@brendancol

Description

@brendancol

Describe the bug

_run_dask_cupy_geodesic in xrspatial/slope.py calls cupy.asarray(lat_2d) and cupy.asarray(lon_2d) while building the dask graph (around line 274). That densifies the full (H, W) lat/lon grids onto a single GPU at graph-construction time, before any compute runs. On large rasters it allocates roughly 2 * H * W * 8 bytes of GPU memory up front and can OOM before the computation starts.

Aspect already fixed this. In xrspatial/aspect.py (around line 286), _run_dask_cupy_geodesic keeps lat/lon as dask-of-numpy on the broadcast views and converts each block to cupy lazily with map_blocks(_to_cupy_f64). A regression test guards it at xrspatial/tests/test_geodesic_aspect.py:309.

Expected behavior

The dask+cupy geodesic slope path should keep lat/lon chunked and convert blocks lazily, the same way aspect does, so graph construction does not allocate the full lat/lon grids on the GPU.

Additional context

Port the lazy-block pattern from aspect.py into slope.py, and add the matching regression test that asserts graph construction stays well under one full lat/lon grid of GPU memory.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdaskDask backend / chunked arraysgpuCuPy / CUDA GPU supportperformancePR touches performance-sensitive code

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions