I lowered the downsampling to 0.6 and it helped a lot. Now preview runs on
CPU non-opencl device 2-3 times faster then on the same device earlier. It
takes some 0.5 - 0.6 sec and full on GPU opencl device takes up to 0.4 sec.
Also subjective responsiveness of image editing is much better now.
Does this change to downsampling have any negative impact?
Suni
2013/12/22 johannes hanika <hana...@gmail.com>
>
>
>
> On Mon, Dec 23, 2013 at 5:22 AM, suni <s...@seznam.cz> wrote:
>
>> 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.
>>
>
> what's your thumbnail size in your preferences excessively large? you
> might want to play around with lower values of
>
> src/develop/develop.c:53:
>
> dev->preview_downsampling = 1.0f;
>
>
> and see if that still has an effect. i think it used to be a darktablerc
> parameter at some point, but not any more. not sure it even still works.
>
> -jo
>
>
>> 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
>>
>>
>
------------------------------------------------------------------------------
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
