Improvements to NonStationaryConvolve2D

Abierto
  • ¿Algo no está bien?
#466 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python
Área
data

Línea de trabajo

Start by comparing the CPU implementation in pylops/signalprocessing/nonstatconvolve2d.py with the CUDA implementation in pylops/signalprocessing/_nonstatconvolve2d_cuda.py. The issue bundles interpolation refactoring, CUDA launch and iteration changes, and a new operator, without naming tests or defining a complete acceptance check; clarify the scope and expected behavior before starting.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

This issue collects a few improvements for the NonStationaryConvolve2D as raised in https://github.com/PyLops/pylops/pull/465 (and a couple of others):

  • Refactor bilinear interpolation
    The CUDA bilinear interp is the same as the CPU one. It then makes sense to wrap the same code under a same function. This can be done by coding a pure Python function and then defining a device function from it. For example:

    # CPU
def fun(a, b):
   return a + b

# GPU
dev_fun = cuda.jit(device=True)(fun)

  • Move CPU to auxiliary file
    Since the GPU functions are in another file and taking into account the above refactor, it makes sense to move it to another file.

  • Improve thread launch parameters and iteration model
    Currently, there is a limit to the size of the model, imposed by the number of blocks and threads in the call. There are two approaches to fixing this. The first is by making the total number of threads depend on the model. For example, if the model is 1000 x 1000, launch 1 block of 1024 x 1024. There is a problem which appears when very large models are used: the number of threads that are required exceed the number that the GPU can provide.
    Grid stride looping can help with this as allows arbitrarily sized models to be processed by a smaller number of threads. For example, set 1 block of 1024 x 1024 and you can process any model of any size. The issue with naive grid-stride looping is that it may not be optimal in the number of threads. For example, a 32 x 32 model always launches 1024 x 1024 threads.
    A solution to that is to combine both techniques: use an input-dependent number of blocks/threads (that are powers of 2), but set a maximum number of total threads launched. This can even be set per GPU, but is probably ok to hardcode for a reasonable number obtained from the MAX_GRID_DIM_X attribute (see here).

  • Create operator that takes filters as input
    Currently, our operator takes a generic 2d signal as input and filters as parameter. However, an alternative operator that takes the 2d signal as parameter and the filters as inputs is desirable as it could be used to estimate the best non-stationary filters that match a given data and input signal. This is kind of equivalent to pylops.avo.prestack.PrestackWaveletModelling for the 1D case. I suggest making a completely new operator and calling it NonStationaryWavelets2D or NonStationaryFilters2D.

Lenguaje dominante
Python
Estrellas
539
Forks
126
Merge medio
2 d 17 h
PR fusionados (30 d)
21

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PyLops/pylops

Todos los issues de PyLops/pylops

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.