Hi,
the issue should now be fixed in master and in darktable-2.0.x branch.
Ulrich
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Hi,
short update from my side. Looks like I have found a way to restore the
original OpenCL performance of NVIDIA devices with recent driver versions.
Currently we have some other issues with the OpenCL codepath in master
which prevents me from working there. If this gets sorted out soon, I
Thanks. As in another case discussed before your OpenCL system does not
seem to be limited by memory tranfer. host<->device transfers account to
below 50% of the time spent in the pixelpipe and I regard this as a
healthy value. Changes in the memory transfer method don't help here and
you proba
I am attaching my logs
this is darktable 2.0.6
copyright (c) 2009-2016 johannes hanika
darktable-...@lists.darktable.org
compile options:
bit depth is 64 bit
normal build
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 3.0.0
Colord support enabled
gPh
Guys,
what commands do you issue in order to provide Ulrich with log files and
system info?
I am sorry trying to learn and don't know them trying to help
somehow...
Regards,
B
On 2016-09-16 06:16 AM, Patrick Shanahan wrote:
* Chester [09-16-16 08:56]:
Well, I have go back to
* Chester [09-16-16 08:56]:
> Well, I have go back to old Nvidia driver:
>
> Graphics: Card: NVIDIA GF106 [GeForce GTS 450]
>Display Server: X.Org 1.18.3 drivers: nvidia (unloaded:
> fbdev,vesa,nouveau)
>Resolution: 1680x1050@59.88hz, 1920x1200@59.95hz
>GLX Re
* Chester [09-16-16 08:56]:
> ULrich: here are my config and the two files:
>
> darktable --version
> this is darktable 2.0.6
> copyright (c) 2009-2016 johannes hanika
> darktable-...@lists.darktable.org
>
> compile options:
> bit depth is 64 bit
> normal build
> OpenMP support enabled
>
Thanks for sharing. Yours is a good example of an OpenCL system that is
not limited by host<->device memory transfers. In a typical export job
your system spends about 30% of its time in memory transfer, the rest is
pure computing. That's a very good situation in which pinned memory does
not gi
Hi,
Core2-Duo E6550 @ 2.33GHz +Nvidia GeForce GTX 650 / 2 GB, driver
361.42, OpenCL 1.2 CUDA, darktable 2.0.6 from PPA.
With pinned memory, performance is slightly (about 10%?) worse.
There are lines like
[opencl_profiling] spent 0,3774 seconds in [Map Buffer]
that are only seen in the 'pinned' l
Thanks. That's a small advantage for opencl_use_pinned_memory=TRUE.
Still even with the flag set to TRUE we loose quite some time in the
host_memory->device_memory step. I expect that I can change our code to
get some further improvements there in the next days.
Ulrich
Am 15.09.2016 um 16:10
Am 15.09.2016 um 09:31 schrieb Tobias Ellinghaus:
With a speed difference like that, couldn't we run a small benchmark at init
time (we already compare the speed to the CPU) and set the flag accordingly at
runtime?
Probably we should.
Ulrich
Am Mittwoch, 14. September 2016, 18:56:03 CEST schrieb Ulrich Pegelow:
[...]
> There is a quick fix for that in darktable. You can switch config
> variable opencl_use_pinned_memory to TRUE (can be found in darktablerc).
> At least here on my this makes a difference of up to a factor of 30
> (oldi
Well, in your case I see the differences as only marginal - the time
spent in the OpenCL pixelpipe differs only by 2% between the two setting
(in favor of TRUE). Not sure if differences persist if you would repeat
profiling several times to get out any fluctuations.
So it seems that your combi
Hi Ulrich,
Just want to say a big Thank You for "switch config variable
opencl_use_pinned_memory to TRUE"
For me the speed improvement is very noticeable.
When set to "TRUE" - I am exporting the control image for 34s and worse
is 39s
When set to "false" - I am exporting the same image for ab
The flag will mostly effect situations where tiling comes into play.
That's the case for GPUs with low memory and for modules with high
memory demand (e.g. equalizer).
Am 14.09.2016 um 19:39 schrieb Colin Adams:
Yes, it's working now. I guess the crash must have been a coincidence.
Slower if a
Yes, it's working now. I guess the crash must have been a coincidence.
Slower if anything, but there isn't much in it. I can't be sure.
Running with NVIDIA 370.28 driver.
On Wed, 14 Sep 2016 at 18:37 Ulrich Pegelow
wrote:
> Do I understand correctly that you can run with the flag set to TRUE?
>
Do I understand correctly that you can run with the flag set to TRUE?
What are your findings in terms of speed improvements (if any)?
Am 14.09.2016 um 19:34 schrieb Colin Adams:
No.
Doesn't happen anymore.
On Wed, 14 Sep 2016 at 18:26 Ulrich Pegelow mailto:ulrich.pege...@tongareva.de>> wrote:
No.
Doesn't happen anymore.
On Wed, 14 Sep 2016 at 18:26 Ulrich Pegelow
wrote:
> Any backtrace?
>
> Am 14.09.2016 um 19:12 schrieb Colin Adams:
> > It causes darktable 2.0.5 (Fedora) to crash. Switching back to false
> > cures the problem. So please don't change.
> >
> > On Wed, 14 Sep 2016 at 1
Any backtrace?
Am 14.09.2016 um 19:12 schrieb Colin Adams:
It causes darktable 2.0.5 (Fedora) to crash. Switching back to false
cures the problem. So please don't change.
On Wed, 14 Sep 2016 at 17:56 Ulrich Pegelow mailto:ulrich.pege...@tongareva.de>> wrote:
Well, there obviously is an iss
It causes darktable 2.0.5 (Fedora) to crash. Switching back to false cures
the problem. So please don't change.
On Wed, 14 Sep 2016 at 17:56 Ulrich Pegelow
wrote:
> Well, there obviously is an issue with OpenCL and NVIDIA. However, a
> quick check reveals that this is not related to 2.0.6 versus
Well, there obviously is an issue with OpenCL and NVIDIA. However, a
quick check reveals that this is not related to 2.0.6 versus 2.0.5.
In fact it seems that NVIDIA did some changes to their drivers in the
way they handle memory transfers over the IDE interface.
There is a quick fix for that
I find it strange...
When I upgraded from 14.04 to 16.04 - DT was at version 2.0.5 and nvidia
361. I actually experienced speed "gain" - did not clock it but it was
very noticeable. I worked in this state for several weeks - all happy,
no changes in settings to DT.
2.0.6 was installed on 201
There was a thread on the -dev list with someone else having slowness
on Ubuntu 16.04 with OpenCL on nVidia and it looked like a driver
issue. They switched from version 361 of the nVidia driver to 340 and
saw an improvement, might be worth trying.
Thread here:
https://www.mail-archive.com/darkta
This should be a bit better
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT
525M] (rev a1)
Regards,
B
On 2016-09-1
It is an older Dell XPS X2 laptop (5 years old) with 2 graphic cards.
Intel and nvidia. I am using the nvidia as I have a second monitor and
the only way to make it work is by using the HDMI output (nvidia should
be on). The processor is second generation Intel (Sandy Bridge) and the
intel card
On Mon, 12 Sep 2016 21:12:42 -0700
"I. Ivanov" wrote:
>Did somebody notice slowing down since DT 2.0.6? I am on ubuntu
>16.04 64 bit. 8Gig RAM. I noticed somewhat slower performance of DT.
>Experimented with turning off Open CL and it looks like the speed
>improved. My security patches are up to
26 matches
Mail list logo
