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