could you please also answer the question about your settings re:thumbnail
size? maybe you don't need the other switch at all.


On Mon, Dec 23, 2013 at 12:42 PM, suni <s...@seznam.cz> wrote:

> 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

Reply via email to