[gdal-dev] [NEW] Multi-threaded warping

[Fabian Schindler]

Etienne,

The main advantage of OpenMP is that you can compile the code with 
(-fopenmp on gcc) or without OpenMP support but the output *should* stay 
the same. So you can produce code that is highly optimized for 
multithreaded environments (with little overhead) and still have 
backwards compatibility for systems that lack threads.

When using OpenMP, you give up control when and how you create thread 
contexts, this is managed at compile time (using the #pragma omp 
directives (which btw should stay the only interface to OpenMP)). You 
still have control of atomic sections, thread local/global variables and 
so on.

I hope this explained a little.

Regards,
Fabian

On 06/11/2012 12:22 AM, Etienne Tourigny wrote:
> Even - good stuff!
>
> Can you comment on the usage of openmp for multi-threading?  Is the
> multi-threading in gdal entirely based on pthreads (in linux)?
>
> It's my understanding that openmp is much easier to manage but offers
> less fine-grained control - is that required for multi-thread warping?
> Of course what works best is what is already working!
>
> Sorry for such a generic question, I did not really look into the
> specifics (other than a quick look at mutext handling).
>
> Regards,
> Etienne
>
> On Sun, Jun 10, 2012 at 6:52 PM, Even Rouault
> <even.rouault at mines-paris.org>  wrote:
>> Le dimanche 10 juin 2012 23:44:54, Yogesh Dahiya a écrit :
>>> As far I know gdal1.9 has integrated opencl so we can parallelize by
>>> setting it right.
>>> So what exactly is your addition.
>>> By the way I tried opencl case and was able to get 16x over general case
>>> for lanczos for image of 16000*16000
>> (Replying to list too, as others might have the same question)
>>
>> Yes indeed, GDAL 1.9 can use OpenCL and this implementation is of course still
>> available.
>>
>> Unfortunately, AFAIK, there is not yet any working OpenSource OpenCL
>> implementation (and my experience with some proprietary OpenCL implementation
>> has not always been convincing, like the GUI being totally unresponsive during
>> the processing).
>>
>> The new multi-threaded implementation just uses traditional multi-threading
>> technics that are available on all platforms where GDAL can run.
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev