On jeudi 5 mars 2020 22:05:59 CET John Daniel wrote: > Hello everyone, > I am investigating adding support for Apple Metal to GPU resampling in GDAL. > This is what I've learned so far: > > 1) Currently, OpenCL is only used for resampling operations via gdalwarp. > RasterIO resampling via gdal_translate does not use OpenCL. This makes > gdal_translate, and RasterIO, much slower for resampling operations. 2) Not > even taking OpenCL into account, there are two independent resampling > paths. Resampling via RasterIO uses routines in gcore/overview.cpp. > Resampling via warp uses a different set of resampling implementations in > alg/gdalwarpkernel.cpp, for the same resampling algorithms. > > So, if I wanted to implement a new set of resampling routines using Apple > Metal, is there a reason why I should not implement it in the overview.cpp > path and then have warp use that same path for resampling? Am I missing > something?
> Is one set of resampling implementations better than the other? Not really. The RasterIO / overview resampling can make extra assumptions in comparison to the warping resampling that make its CPU implementation normally faster. In warping mode, pixels of a same target line do not correspond to a single line in the source image, whereas for overviews, they do. The fact that warping resampling has a OpenCL acceleration path is just because only it was targetted during the work where it was implemented. There's no fundamental reason why RasterIO / overview resampling couldn't have one. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
