Thank you guys for your explanation. To be honest, your answers
disappointed me a bit. But I understand that we are talking here about too
much low level logic which darktable is based on so it cannot be changed
easily.
Based on your information I think that one should change his mind on what
the most power demanding process of darktable is in fact. So far I have
been thinking that the most power hungry is processing of the full
pixelpipe. Therefore my strategy was to provide it the most powerful device
available. But now it turns out that it is not the case because the
bottleneck is preview pixelpipe instead.
I did a test and I found that my sample image is processed some 0.5 sec
faster when I force preview to be processed on GPU opencl device instead of
CPU non-opencl device and full pixelpipe on CPU instead of GPU. I tested on
exposure, equalizer and profiled denoise modules. Half of second on single
edit may not look like a big deal, but considering how much edits are
usually done to process one image turns the situation.
The strange thing is that my findings are in contrast to what is written in
user manual regarding the opencl default priority setting: "... if there is
only one GPU owned by your system, preview pixelpipe will always be
processed on CPU, keeping your single GPU exclusively for the more
demanding center image view.". Do you have any explanation why my findings
are different to what is written in user manual?
Suni
2013/12/22 johannes hanika <hana...@gmail.com>
> we do, however, support several gpus and schedule several pixelpipes onto
> those.. at least for export that should work out of the box. has been a
> while since i had a computer with > 1 gpu, so unsure what would happen to
> the preview pipe. it's also a matter of not swapping in/out the sizable
> amounts of memory we require, so scheduling two pipes on one gpu at the
> same time might not be a brilliant idea.
>
> -jo
>
>
> On Sun, Dec 22, 2013 at 9:17 PM, Ulrich Pegelow <
> ulrich.pege...@tongareva.de> wrote:
>
>> Nope, this is not possible without changing significant parts of
>> darktable's architecture. darktable is event driven which means that
>> there is no single place in code where any reliable synchronization
>> between pixelpipes could be managed.
>>
>> Ulrich
>>
>> Am 22.12.2013 00:13, schrieb suni:
>> > OK, it seems that preview processing cannot be avoided, at least for
>> > now. But would it be possible to let it process on the opencl device
>> > instead of the much slower CPU while keeping processing full pixelpipe
>> > on opencl too. It means to let process full and preview in sequence, not
>> > in parallel? It should improve the responsiveness of every single image
>> > edit at least in case only one fast opencl device is available. There
>> > could be a configuration parameter to manage this behaviour. In case of
>> > only one not very fast opencl device or two fast opencl devices it still
>> > may be a good idea to let these two pixelpipes run in parallel as they
>> > do now. I think there cannot be one optimal setting for everyone, it
>> > depends on particular system configuration.
>> >
>> > Suni
>> >
>> >
>> > 2013/12/21 johannes hanika <hana...@gmail.com <mailto:hana...@gmail.com
>> >>
>> >
>> >
>> >
>> >
>> > On Sun, Dec 22, 2013 at 1:52 AM, suni <s...@seznam.cz
>> > <mailto:s...@seznam.cz>> wrote:
>> >
>> > Thank you Tobias, I was not aware of that. But anyway it sounds
>> > a bit strange to me. Why should any module depend on preview
>> > window which carries a lot less image information than the main
>> > image? I can imagine that it may be some remain from past when
>> > opencl was not implemented and cpu code was not so optimized as
>> > it is now. In such situation calculating the histogram from
>> > preview may be huge speed benefit. But I am not sure if such
>> > strategy is still valid even nowadays.
>> >
>> >
>> > absolutely still valid. if you have a full hd monitor and a 25MP
>> > image, you leave > 20x performance lying on the table. and we have
>> > some modules which are still only borderline acceptable in response
>> > time, even if you just process one megapixel instead of the full
>> > image. to get a feeling for it, just export a full res picture, that
>> > will not run any preview pipe, only one full-size pipe. depending on
>> > your history stack that might take around 30 sec..
>> >
>> > j.
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> darktable-devel mailing list
>> darktable-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
