jo, thank you a lot for your hint. I lowered the downsampling furthermore
to 0.4 and now the preview process time is almost on pair with full process
time. This is huge improvement and finally what I was hoping to. Having
preview more coarse is absolutely no issue for me as I almost do not use
preview for navigation at all. In fact I do not realise any
visible difference in the image quality of the preview. I only realised
that downsampling lowered to 0.6 or 0.4 has some impact on zooming and
panning of the image. It is best visible when I do pan the zoomed in image.
In this case the image first zooms out itself, then it is panned and when I
release the mouse button, it zooms in itself again. So the image "jumps"
out and in during the panning. It is not much pleasant, but for me it is
acceptable tax for the improvement in speed. Moreover I do believe it could
be resolved at some point in the future.
I would definitely vote for being able to set the downsampling rate in
darktablerc again as it was earlier. Thank you.
Suni
2013/12/22 johannes hanika <hana...@gmail.com>
> your preview image will be a little coarser. i don't think it matters
> much. it's used to compute full-image histograms, for the navigation view,
> as well as for a quick preview while panning around in the image.
>
> -jo
>
>
> On Mon, Dec 23, 2013 at 10:44 AM, suni <s...@seznam.cz> wrote:
>
>> 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
