CUDA pipeline for computing APR by krzysg · Pull Request #185 · AdaptiveParticles/LibAPR

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg · 2024-08-23T11:45:12Z

No description provided.

…imizations

…ch direction

…adding), still float number differences between CPU and GPU

…PU gives same results.

…added.

…PU gives same results.

…ated

…side)

…sions

…ccess

cheesema · 2024-08-27T14:32:11Z

Can't wait to give this a go amazing!

LinearAccess structure on GPU (so it does not support old random or sparse data structures).

Good decision those are all that are needed / suited for the GPU anyhow.

krzysg · 2024-10-30T09:44:11Z

Cool thanks! I think develop is stale, and maybe we should point this at main?

Sure - as we talked lately I have change target branch to 'master'.

krzysg · 2024-11-05T09:36:19Z

Hi, there are two parts of LIS that probably require some explanation:

'bool boundaryReflect' additional parameter to all calc_sat_mean_*

At some point CPU impl. was change to padd/unpadd pixels before running LIS (according reflect_bc_lis parameter). At first I was trying to avoid it for GPU since I was trying to avoid additional mem allocation for padded pixels. And I managed to do that for 1D. Unfortunately it does not work for 2D or 3D cases (which is obviuos since in CPU impl. cals_sat_mean_* when run also change padded pixels so when you run that in Y-dir it has some influance on running later X-dir and so on).
Anyway I decided to leave it as a option for super fast processing of 1D data (without allocation of additional memory, double mem copy for padd and unpadd). So I decided to upgrade also CPU impl. with that 'feature'.

And now we got second part - as you know I really pay attention (no matter if this is important or not) to correct math and having same results for same data even if some differences would be caused by some minor float operations differences only (like because of different order of execution or so). So in case if I have some date put in Y-dir and when I run calc_sat_mean_y I want to have same results as when I put same data transposed (same date in X-dir) and run calc_sat_mean_x. Unfortunately those functions in CPU impl. where giving little bit different results (+/- some float precision on 6th or 7th digit after decimal point - enough to make me angry ;-) ).
Since I first managed to have proper behavior on GPU code so I have 'equalized' code on CPU side to GPU side. So the good things because of that are:
(a) code is still doing same thing that old code (+/- mention float precision) but behaves in a same way in all directions (it is already removed from code but during development I wrote tests comparing outputs of both old/new LIS to check if all is correct).
(b) naming of variables is same of GPU/CPU side so in case of any changes it is easy to fix/update both sides since they look similar.

…puted in constructor and memory for them is preallocated

…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

…rator to VectorData

…ly one ARP object - use it only for speed for now

…mpling

…ed for backup reasons only

…init in APRConverter for GPU not needed anymore

…s and limit log messages for benchmarking purposes

krzysg added 30 commits August 1, 2022 14:39

Bspline filters fixed for CUDA pipeline
e6aa9c9

Debug messages turned off
b563da4

Fixed Inv Bspline in X direction (CUDA pipeline)
3db510f

Inverse Bspline pipeline for CUDA fixed
18fce44

Downsample and downsample gradient corrected to match GPU
ad5f194

GPU pipeline fixes - Full Gradient test is working now
557eff3

Merge branch 'develop' into cuda
57765a7

Merge branch 'develop' into cuda
3da13ba

GPU and CPU give same resutls in Release mode - turned off unsafe opt…
d958161
…imizations

Quick fix of processOnGpu() - not it gets correct bspline data for ea…
4ace238
…ch direction

Added new test file for LIS CUDA, GPU now handles boundary (without p…
b050e07
…adding), still float number differences between CPU and GPU

Local Intensity Scale (LIS) not works in X-dir as expected. GPU and C…
570ab20
…PU gives same results.

Local Intensity Scale (LIS) now works in Z-dir as expected. GPU and C…
17e5d8e
…PU gives same results.

Updated compareMeshes to show maximum error found
5ad9865

LIS in X-dir redesigned so code is clearer and faster. Also new test …
af1c3ac
…added.

LIS in Z-dir redesigned so code is clearer and faster. Also new test …
521d826
…added.

Local Intensity Scale (LIS) now works in Y-dir as expected. GPU and C…
b297adf
…PU gives same results.

Whole LIS pipeline is matching exactly CPU implementation + tests upd…
2cdf3fe
…ated

Quick fix of linking error
e093c01

maximum error diff. GPU vs CPU for compute gradient set to 0
053380d

rescaleAndThreshold in now only rescaling (to reflect changed in CPU …
97cf75e
…side)

rescaleAndThreshold in now only rescaling (to reflect changed in CPU …
83c2a31
…side)

constant_intensity_scale handling in LIS added for GPU
5b5a719

Removed unused threshold functions
5d0375a

FullPipeline test moved to new file
53ef94b

PixelDataDim updated with maximum dimension lenght and nuber of dimen…
ac2c22e
…sions

GradLisLevels test working now
122a96a

full pipeline tests fixed
6a5db35

Changes from old branches added + modified to GenInfo instead of APRA…
4088e9d
…ccess

Added debug printout to GenInfo
b8f2504

krzysg changed the base branch from develop to masterOctober 30, 2024 09:42

krzysg added 26 commits March 17, 2025 16:17

Linear acces now is using correct cuda stream, bspline params are com…
9604c63
…puted in constructor and memory for them is preallocated

added error handling for bspline y-dir
9572e10

Removed (most of the) warnings
514c03c

added error handling for bspline x-dir, other steps temporarily blocked
005a4ba

added error handling for bspline z-dir
5534860

Stream operations on GPU are working now as expected. All tests are f…
1b54cd0
…ixed. Still APRConverter for streams must be fixed/improved since there is a draft code.

Reverting APRCOnverter type to previoius value
7f6e2d3

Fixed CUDA-streams sync issues when copying back to CPU
b01df31

Little bit cleanup of CUDA in APRConverter, Added move assignment ope…
bf4cdb0
…rator to VectorData

Fixed move construtor/assignment - pinned memory is now also moved.
cd7d594

Fixes needed by CUDA 13.0 - now code compiles
0c702f3

Initial impl. of CUDA multistreams, it takes many images but STILL on…
1f27876
…ly one ARP object - use it only for speed for now

Fixes needed by CUDA 13.0 - now code compiles also on CUDA 12.x
0ba2f45

CUDA version of getMinMax added (for finding bspline offset)
0a44736

Bspline Offset is now computed on GPU + copy of original image for sa…
4093552
…mpling

Added some useful methods to GenInfo (size and dimension)
e686349

Sampling on GPU added - THIS CODE is to being cleaned up - it is push…
1db4abf
…ed for backup reasons only

Reverting CUDA-pipeline related changes
8415a52

Initial draft of Example_get_multiapr
629f806

Added Example_get_multiapr for CUDA parallel processing
3a11834

localScaleTemp is not anymore passed to GpuProcessinTask, CPU memory …
c20fac6
…init in APRConverter for GPU not needed anymore

Removed unnecessary comments
890283c

get_multiapr can now repeat processing of input data, skip saving APR…
d9527e6
…s and limit log messages for benchmarking purposes

Final (yupi :-) ) version of multistream computing on GPU
2682562

Parallel copying to pinned buffer
9592d98

Added support for multi-GPU
5f62f14