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
