Improvements to NonStationaryConvolve2D

Aperta
  • Qualcosa non va?
#466 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
data

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
539
Fork
126
Merge medio
2g 17h
PR unite (30g)
21

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di PyLops/pylops

Tutte le issue di PyLops/pylops

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.