Ulrich Pegelow wrote:
Hi!
> Forgot to mention. If you have other applications which consume
> significant amounts of GPU memory this could also cause OpenCL in
> darktable to fail. Unfortunately there is no way to find out at any
> time which amount of GPU memory is still available. Therefore
>
Forgot to mention. If you have other applications which consume
significant amounts of GPU memory this could also cause OpenCL in
darktable to fail. Unfortunately there is no way to find out at any time
which amount of GPU memory is still available. Therefore darktable
assumes it can have all m
Hi,
then the only chance which I still could see is testing another driver
version, assuming that a driver might be the root cause. I am currently
successfully running version 346.59 (although my GPU is an ancient GTS450).
Ulrich
BTW here are my settings:
[opencl_init] opencl: 1
[opencl_init]
Hi,
thanks. 500 leads to
...
[opencl_pixelpipe] couldn't copy image to opencl device for module colorin
[opencl_pixelpipe] failed to run module 'colorin'. fall back to cpu path
[opencl_pixelpipe (b)] late opencl error detected while copying back to
cpu buffer: -5
[opencl] frequent opencl errors e
You could try an even higher values of opencl_memory_headroom of 500.
If this does not help please try with lower settings for
opencl_event_handles.
Ulrich
Am 31.05.2015 um 23:37 schrieb joeni:
> Hi,
>
> thanks. Tried that. Same, or similar, result (and I'm seeing colour
> effects where parts o
Hi,
thanks. Tried that. Same, or similar, result (and I'm seeing colour
effects where parts of some lines of pixels anywhere on the screen turn
strange colours)
(350)
...
dev] took 0.000 secs (-0.000 CPU) to load the image.
[pixelpipe_process] [full] using device 0
[dev_pixelpipe] took 0.010 se
Hi,
first thing you should try is increase opencl_memory_headroom to 350 or 400.
Ulrich
Am 31.05.2015 um 14:33 schrieb joeni:
> Hi,
>
> not sure this is the right place to send this to: I'm having trouble
> with OpenCL and my new GPU (darktable 1.6.6, GeForce GT 730, Ubuntu
> 15.04). What shall
Hi,
> But now i have update my gnome version (from 3.12 to 3.14) &
> gnome-shell was always crashing with ati-drivers
> So i now using the radeon (free) drivers in X11.(with kms)
I'm afraid you have to decide to either use the free radeon
driver, or use the fglrx ("ati-drivers"). You can't use b
On 2015-03-19 19:59, Wolfgang Goetz wrote:
> Taahir Ahmed wrote:
>
>> I recall having a similar error, unrelated to darktable. The problem
>> may be with one of the /dev/ati* devices -- it either needs to be
>> world readable/writable, or the user accessing needs to have a
>> certain capability [1
Taahir Ahmed wrote:
> I recall having a similar error, unrelated to darktable. The problem
> may be with one of the /dev/ati* devices -- it either needs to be
> world readable/writable, or the user accessing needs to have a
> certain capability [1]. Unfortunately, I've forgotten precisely which
>
I recall having a similar error, unrelated to darktable. The problem may be
with one of the /dev/ati* devices -- it either needs to be world
readable/writable, or the user accessing needs to have a certain capability
[1]. Unfortunately, I've forgotten precisely which capability it was.
Taahir
I don't have any access to the system you describe, so all I can do is
guess. Most likely the problems are caused by the OpenCL compiler
implementation for the specific hardware. At least the unusal number of
compiler warnings points into that direction - neither AMD nor NVIDIA
show these warni
Somewhat. There were some efforts put into OpenCL on OS X, but it seems
they weren't enough. OpenCL is disabled by default on OS X for that
reason. If you're interested in helping fix it, I suggest creating a
bug report in redmine and attaching output of
/Applications/darktable.app/Contents/MacOS/d
Am 05.11.2014 um 19:22 schrieb parafin:
> Try disabling option "Use GPU acceleration via Clutter library" in
> Edit->Preferences->Preferences...->Image
First of all I have to correct myself: The issue happens even with geeqie idle.
At least when geeqie is idle in the sense that I only have opene
Try disabling option "Use GPU acceleration via Clutter library" in
Edit->Preferences->Preferences...->Image
On Wed, 05 Nov 2014 16:49:39 +0100
Matthias Bodenbinder wrote:
> Am 03.11.2014 um 21:09 schrieb Dariusz J. Garbowski:
> > Shot in the dark -- try and disable "Preload next image" and make
OK, thanks for testing.
Then I would say that - given the inherent limitations of GPU memory -
darktable does a pretty decent job :)
We cannot influence other applications claiming GPU memory. All we can
do is deal with this situation - fall back to CPU but continue trying to
use the GPU if po
Am 03.11.2014 um 21:09 schrieb Dariusz J. Garbowski:
> Shot in the dark -- try and disable "Preload next image" and make "Decoded
> image cache size" a small
> value in Preferences -> General in Geeqie?
I did that and it does not help. I did also check what an idle geeqie will do,
as suggested
Interesting observation! Does you issue only happen while you are
actively working with geeqie or does it also occur when geeqie is idle?
Ulrich
Am 03.11.2014 um 12:30 schrieb Matthias Bodenbinder:
> I made some more tests also with newest NVIDIA driver 343.22. What I found so
> far is that the
Shot in the dark -- try and disable "Preload next image" and make "Decoded
image cache size" a small
value in Preferences -> General in Geeqie?
Regards,
Dariusz
On 03/11/14 11:30 AM, Matthias Bodenbinder wrote:
> I made some more tests also with newest NVIDIA driver 343.22. What I found so
>
I don't know ristretto and gwenview, but this might be related to opengl,
do you no which of these three might use opengl for rendering ?
On Mon, Nov 3, 2014 at 12:43 PM, Matthias Bodenbinder <
matth...@bodenbinder.de> wrote:
> With gwenview I can not even provoke the error with
> opencl_memory_h
With gwenview I can not even provoke the error with opencl_memory_headroom: 300
Matthias
--
___
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://list
I made some more tests also with newest NVIDIA driver 343.22. What I found so
far is that the picture viewer geeqie seems to play an important role in that.
When watching JPG pictures with geeqie while exporting from DT I get the memory
issue as soon as geeqie has opened a few pictures. When I q
Hi Matthias,
unfortunately I did not find anthying helpful in there. I had the faint
hope that you might be using some seldomly used module that might have a
memory leak in its OpenCL code - this would have explained your issues.
However, nothing like that is the case. You have the same modules
Am 21.10.2014 um 07:12 schrieb Ulrich Pegelow:
> @Matthias:
>
> In order to better understand the issues on your system I'd like you to
> generate a full debug output with 'darktable -d opencl -d perf'. I would
> like to see everything from the start and all output during export until
> the pro
@Matthias:
In order to better understand the issues on your system I'd like you to
generate a full debug output with 'darktable -d opencl -d perf'. I would
like to see everything from the start and all output during export until
the problem occurs.
Best wishes
Ulrich
Am 20.10.2014 um 18:23
* Patrick Shanahan [10-20-14 09:59]:
> * Matthias Bodenbinder [10-20-14 01:24]:
> > Am 19.10.2014 um 21:32 schrieb Patrick Shanahan:
> > >
> > > just installed 340.46 but on openSUSE-Factory and using darktable from
> > > git. Will report anomalies if observed.
> > >
> > Can you please export
Some more input from my side. I tried to reproduce your issue on my AMD
Radeon HD7950. For simplicity reasons I exported 340 duplicates of the
same image. All with profiled denoise active. I took an image big enough
to force tiling in that module.
All images were exported without any problems.
In terms of numbers this fits. The tiling code splits this image
processing step as the full image would be too big. The tile to be
processed is 5172 x 3666 pixels in size. This requires an image buffer
of 289MB. We need four full buffers (in, out, tmp, U2) and we need
additional four small buf
Am 20.10.2014 um 07:39 schrieb Ulrich Pegelow:
> What denoising method did you chose in that module? Non-local means or
> wavelet?
>
> Best wishes
>
> Ulrich
>
I am always using non-local means. I have attached an example dtstyle file.
Here the output of "darktable -d opencl -d perf" when it
* Matthias Bodenbinder [10-20-14 01:24]:
> Am 19.10.2014 um 21:32 schrieb Patrick Shanahan:
> >
> > just installed 340.46 but on openSUSE-Factory and using darktable from
> > git. Will report anomalies if observed.
> >
> Can you please export several hundred pictures in one shot and observe
> C
What denoising method did you chose in that module? Non-local means or
wavelet?
Best wishes
Ulrich
Am 20.10.2014 um 07:22 schrieb Matthias Bodenbinder:
> Am 19.10.2014 um 21:32 schrieb Patrick Shanahan:
>>
>> just installed 340.46 but on openSUSE-Factory and using darktable from
>> git. Will r
Am 19.10.2014 um 21:32 schrieb Patrick Shanahan:
>
> just installed 340.46 but on openSUSE-Factory and using darktable from
> git. Will report anomalies if observed.
>
Hello Patrick
Can you please export several hundred pictures in one shot and observe CPU load
resp. console output of "darkta
* Patrick Shanahan [10-19-14 15:32]:
> * Ulrich Pegelow [10-19-14 14:11]:
> > I don't know for sure but most likely neither of the two uses OpenCL.
> > Concerning that graphics driver version maybe some other people using it
> > can tell us their experiences.
> >
> > Ulrich
> >
> >
> > Am 19
* Ulrich Pegelow [10-19-14 14:11]:
> I don't know for sure but most likely neither of the two uses OpenCL.
> Concerning that graphics driver version maybe some other people using it
> can tell us their experiences.
>
> Ulrich
>
>
> Am 19.10.2014 um 19:26 schrieb Matthias Bodenbinder:
> > Am 1
I've not had any problems, but I have only been exporting a few pictures at
a time, so perhaps not a useful datum.
On 19 October 2014 19:09, Ulrich Pegelow
wrote:
> I don't know for sure but most likely neither of the two uses OpenCL.
> Concerning that graphics driver version maybe some other pe
I don't know for sure but most likely neither of the two uses OpenCL.
Concerning that graphics driver version maybe some other people using it
can tell us their experiences.
Ulrich
Am 19.10.2014 um 19:26 schrieb Matthias Bodenbinder:
> Am 19.10.2014 um 15:55 schrieb Ulrich Pegelow:
>> I don't
Am 19.10.2014 um 15:55 schrieb Ulrich Pegelow:
> I don't think that values as high as 600 really make sense as I can't
> imagine that typical gui and driver related requirements are much higher
> than 300MB. I see two possibilities: either there is another application
> or background job on your
I don't think that values as high as 600 really make sense as I can't
imagine that typical gui and driver related requirements are much higher
than 300MB. I see two possibilities: either there is another application
or background job on your system that uses OpenCL memory, or the
graphics drive
Am 19.10.2014 um 11:34 schrieb Matthias Bodenbinder:
> Am 18.10.2014 um 14:42 schrieb KOVÁCS István:
>> http://www.darktable.org/2012/03/darktable-and-opencl/
>> If you get “-4” errors, go into file
>> $HOME/.config/darktable/darktablerc, where DT stores its configuration
>> parameters and look for
Am 18.10.2014 um 14:42 schrieb KOVÁCS István:
> http://www.darktable.org/2012/03/darktable-and-opencl/
> If you get “-4” errors, go into file
> $HOME/.config/darktable/darktablerc, where DT stores its configuration
> parameters and look for opencl_memory_headroom.
Thanks for this hint. I tried it
Hi,
the error code -4 in opencl means that a memory object could not be
allocated. It is not uncommon that the whole memory management on your
graphics card has issues once this happens so that only a reboot helps.
My best guess would be that your setting of opencl_memory_headroom
should be in
http://www.darktable.org/2012/03/darktable-and-opencl/
If you get “-4” errors, go into file
$HOME/.config/darktable/darktablerc, where DT stores its configuration
parameters and look for opencl_memory_headroom.
On 18 October 2014 14:27, Matthias Bodenbinder wrote:
> I made some additional tests.
I made some additional tests.
1) DT is not recovering from the loss of opencl functionality. A restart of DT
does not help. opencl performance is still not available although it is
activated in the GUI. Only a reboot of the computer brings back the opencl
performance.
2) The issue is difficult
On 13.6.2014 at 7:22 AM Ulrich Pegelow wrote:
> Hi Sven,
>
> nice to hear of you. I think we talked a bit in the breaks of Pat's
> portrait retouching session.
>
Yes, we did ;-)
Thank you for your precious tips!
To have consistent OpenCL support in GEGL I think one single version
there saves ou
Hi Sven,
nice to hear of you. I think we talked a bit in the breaks of Pat's
portrait retouching session.
When we started with OpenCL in darktable we could only rely on OpenCL
1.0, as drivers for higher versions were not widespread. Therefore even
today we only use the basic set of 1.0 command
On 16/05/14 17:18, Gonçalo Marrafa wrote:
> I've tried the mesa opencl implementation with DT. I get a segfault but can't
> make anything of it, so maybe one of you
> guys can. What i would like to know is if the problem is within DT or my own
> setup.
You need either the nVidia or ATI binary dr
Hi
> Modern GPUs are ways faster than CPUs usally. Only nvidia cards/drivers have a
> problem on profiled denoise as discussed on IRC yesterday. In general nvidia
> cards seem to have a bad OpenCL performance if you look at [1]. And still my
> low budget passive cooled GT 640 outperforms my i7-260
> If you have two GPUs with the same speed, it makes a lot of sense to set
> parallel_export to 2. However, in most cases users have only one GPU
> that is often much faster than the CPU. Or few people have two GPUs with
> a big performance difference. In these cases you only profit from
> multipl
On Thu, Mar 27, 2014 at 7:14 PM, Ulrich Pegelow wrote:
> Am 26.03.2014 22:33, schrieb Christian Kanzian:
> > Am Mittwoch, 26. März 2014 schrieb jerome:
> >
> >> So is this normal ?
> >> I mean, core use and the fact I need export only one at time ?
> >>
> >> Sorry for long story but it help to un
Am 26.03.2014 22:33, schrieb Christian Kanzian:
> Am Mittwoch, 26. März 2014 schrieb jerome:
>
>> So is this normal ?
>> I mean, core use and the fact I need export only one at time ?
>>
>> Sorry for long story but it help to understand how and why.
>>
>> And sorry for my bad english ;)
>>
>> Thank
Am Mittwoch, 26. März 2014 schrieb jerome:
> So is this normal ?
> I mean, core use and the fact I need export only one at time ?
>
> Sorry for long story but it help to understand how and why.
>
> And sorry for my bad english ;)
>
> Thanks to all
Within OpenCL the GPU does the parallel thing
Regarding OpenCL, thanks for the responses :/
On 11 March 2014 21:20, Ulrich Pegelow wrote:
> In short: currently there is no open source OpenCL driver, neither for
> AMD nor for NVIDIA.
>
> Ulrich
>
> Am 11.03.2014 12:58, schrieb Dave:
>> Hello all.
>>
>> I may get shot for this question, but he
In short: currently there is no open source OpenCL driver, neither for
AMD nor for NVIDIA.
Ulrich
Am 11.03.2014 12:58, schrieb Dave:
> Hello all.
>
> I may get shot for this question, but here goes:
>
> Is it possible to have darktable use libOpenCL without installing
> proprietary graphics driv
Ulrich;
I still have the problem running Nvidia version 331.20 on the latest
Fedora-20
David
On 01/08/2014 10:21 PM, Ulrich Pegelow wrote:
> Hi Mark,
>
> it's a known bug in NVIDIA's OpenCL-compiler of that version number
> 304.xx. Please try to upgrade your driver to a later version like 319.xx
Hi Mark,
it's a known bug in NVIDIA's OpenCL-compiler of that version number
304.xx. Please try to upgrade your driver to a later version like 319.xx
or better.
Ulrich
Am 09.01.2014 02:05, schrieb Mark Garrow:
> As I'm on IRC when most are sleeping I thought I'd post.
> I just got a new card i
After updating to the latest Catalyst 13.12 driver [*] I could not
trigger this screen corruption yet. So, the problem seems to be solved
for me.
Thank you for your feedback that your "similar" cards are working. I
wonder, if they are really similar, as there are for example HD7950s
with turbo and
David,
attached is a patch that tries another workaround for NVIDIA's OpenCL
bug. Maybe you can give it a try.
Ulrich
Am 02.12.2013 20:26, schrieb David Vincent-Jones:
After installing the latest Nvidia drivers my machine appears to go a
long way towards fully implementing the compiles neede
Am Dienstag, 3. Dezember 2013 schrieb David Vincent-Jones:
> On 13-12-03 01:10 AM, Christian Kanzian wrote:
> > I don't know what system your are using, but on Debian you can do:
> >
> > #dpkg -l | grep opencl
> >
> > and look for:
> > nvidia-opencl-icd
> > nvidia-opencl-common
> > nvidia-libopen
On 13-12-03 01:10 AM, Christian Kanzian wrote:
> I don't know what system your are using, but on Debian you can do:
>
> #dpkg -l | grep opencl
>
> and look for:
> nvidia-opencl-icd
> nvidia-opencl-common
> nvidia-libopencl1
I do not find those files that you report!
I am only seeing from my sear
Once more.
> Gesendet: Dienstag, 03. Dezember 2013 um 07:12 Uhr
> Von: "Ulrich Pegelow"
> An: darktable-devel@lists.sourceforge.net
> Betreff: Re: [darktable-devel] OpenCL Question
>
> This is a bug in NVIDIA's OpenCL compiler. I reported it to them a year
&g
This is a bug in NVIDIA's OpenCL compiler. I reported it to them a year
ago and they confirmed it's a bug. Seems that they did not fix it in the
304.xx legacy series of their driver.
I guess there are only two chances for you to get OpenCL running. Either
you switch to a newer driver version an
Am 23.11.2013 16:21, schrieb Michael Born:
> Am 23.11.2013 15:09, schrieb Ulrich Pegelow:
>
> Nobody would be surprised about driver bugs, but I have to say, that
> this problem isn't there all the time.
> So, I have to find something to trigger/reproduce the bug :-(
>
Please also take hardware is
Am 23.11.2013 15:09, schrieb Ulrich Pegelow:
> Looks like a driver bug. I am running the same HD7950 device with
> Catalyst 13.8.beta1 without any issues. Maybe you should try that one.
>
> Ulrich
Nobody would be surprised about driver bugs, but I have to say, that
this problem isn't there all t
Am 23.11.2013 16:04, schrieb Togan Muftuoglu:
>> "Ulrich" == Ulrich Pegelow writes:
>
> Ulrich> Looks like a driver bug. I am running the same HD7950 device with
> Ulrich> Catalyst 13.8.beta1 without any issues. Maybe you should try that
> Ulrich> one.
>
> You want him to downgr
> "Ulrich" == Ulrich Pegelow writes:
Ulrich> Looks like a driver bug. I am running the same HD7950 device with
Ulrich> Catalyst 13.8.beta1 without any issues. Maybe you should try that
Ulrich> one.
You want him to downgrade himm, nevertheless that sure is an option.
I am using C
Looks like a driver bug. I am running the same HD7950 device with
Catalyst 13.8.beta1 without any issues. Maybe you should try that one.
Ulrich
Am 23.11.2013 13:11, schrieb Michael Born:
> With the GIT version of yesterday (I had this with older GIT versions,
> too) I had massive picture corrupt
Am 12.08.2013 18:57, schrieb Robert William Hutton:
> Thanks. From what I can tell by looking at the link in the comments at the
> top of the file, which seems to be the
> source of the card identifiers:
>
> https://developer.nvidia.com/cuda-gpus
>
> The asterisks refer to a note at the bottom of
On 12/08/13 17:40, Ulrich Pegelow wrote:
> Am 12.08.2013 18:22, schrieb Robert William Hutton:
>> I have an old nvidia graphics card that self-identifies as a "GeForce GT
>> 330". The opencl build fails (see attached
>> log). However, if I modify src/common/nvidia_gpus.h line 168 to read:
>>
>>
Am 12.08.2013 18:22, schrieb Robert William Hutton:
> Hi All
>
> I have an old nvidia graphics card that self-identifies as a "GeForce GT
> 330". The opencl build fails (see attached
> log). However, if I modify src/common/nvidia_gpus.h line 168 to read:
>
>"GeForce GT 330","1.0",
>
> Instea
Am 17.06.2013 21:13, schrieb David Vincent-Jones:
> Attached is full dt/opencl output from terminal:
> I have ensured now that:
> /etc/OpenCL/vendors/nvidia.icd .. looks correct and
> /usr/lib/nvidia-current/libnvidia-opencl.so.1 also looks correct
>
> The attached appears to indicate that some
Attached is full dt/opencl output from terminal:
I have ensured now that:
/etc/OpenCL/vendors/nvidia.icd .. looks correct and
/usr/lib/nvidia-current/libnvidia-opencl.so.1 also looks correct
The attached appears to indicate that something in 'blendop' is now the
cause of the problem. Is this
Am 17.06.2013 00:37, schrieb David Vincent-Jones:
> I have just made a fresh install of dt and despite OpenCL apparently
> being correctly found it was unable to be initiated.
>
> What does "could not get platforms" indicate?
Hi David,
it's clearly related to a buggy OpenCL installation. Your lib
Am 11.06.2013 20:22, schrieb Roumano:
> Hi,
>
> Two exemple create.
Hi Roumano,
both of your cases hardly need to go into tiling. In order to force
heavy tiling on a Tahiti you will need to go for images with 5000x5000
pixels or higher. If the images in your example are of a typical size
for y
Hi Roumano,
thanks for giving my code changes a try!
I should mention that the isolated profiling data from OpenCL not always
give a good indication. Some devices/drivers for example do not account
for the full host<->device transfer timings. It's better to rely on the
total time spent in the
for 2) the answer is probably that when you enable opencl you process the
image faster but you need to move your image to/from the CPU, which is
quite long
when opencl enabled modules are next to each othe in the pipe we don't need
to copy the image around, but when there is a non-opencl module, w
Hi,
Ok for this response but i still don't understand 2 problem with that :
1) module watermak on dev version is 3 times slower on the dev version than
the stable version :
stable darktable, module watermark with opencl : 0.476 secs
dev darktable, module watermake with opencl : 1.351 secs
On Wed, Jun 5, 2013 at 1:08 AM, Roumano wrote:
> Hi,
>
> (Only) just now (with the new ati-drivers 13.6) , I can enable the
> opencl on darktable
>
> [opencl_init] device 0 `Tahiti' supports image sizes of 16384 x 16384
> [opencl_init] device 0 `Tahiti' allows GPU memory allocations of up to
> 10
For reference: https://bugs.launchpad.net/bugs/1169695
However, the chances someone fixes this bug are quite low, my
experiences regarding launchpad bugreports are rather bad.
Maybe you better set up a script to create the required symlinks for
you, running ldconfig like suggested by Ulrich did no
Am 16.04.2013 21:27, schrieb David Vincent-Jones:
> Ulrich;
>
> I have moved the 2 missing files into place except do not know how to
> create the link file.
>
> David
Normally it should be sufficient to run program ldconfig as root.
Ulrich
-
Thanks Markus ... this is all a bit over my head and a tad frustrating.
My system may be a bit complicated as I am running Bumblebee in an
effort to achieve good battery performance as well as having the ability
to use OpenCL as needed.
My nvidia.icd appears to have not even been located in the
Ulrich;
I have moved the 2 missing files into place except do not know how to
create the link file.
David
On 13-04-16 08:28 PM, Ulrich Pegelow wrote:
> Am 16.04.2013 19:29, schrieb David Vincent-Jones:
>> I have copies of the link libnvidia-opencl.so.1 located in both
>> /usr/lib/nvidia-current
I am filing a bug report against the ubuntu package right now. It
deletes the nvidia.icd symlink in /etc/ all the time and now it does not
even create sane symlinks for libnvidia-opencl. I just "fixed" the issue
by manually creating a nvidia.icd containing the line
"libnvidia-opencl.so.304.88"
Reg
Am 16.04.2013 19:29, schrieb David Vincent-Jones:
> I have copies of the link libnvidia-opencl.so.1 located in both
> /usr/lib/nvidia-current as well as in /usr/lib32/nvidia-current Both are
> broken links that were to linked to libnvidia-opencl.so.304 84 this
> library no longer exists
> The
Those links do not exist at my system.
(Ubuntu 12.04 x64, same nvidia driver version)
Regards,
Markus
Am 16.04.2013 19:29, schrieb David Vincent-Jones:
> I have copies of the link libnvidia-opencl.so.1 located in both
> /usr/lib/nvidia-current as well as in /usr/lib32/nvidia-current Both are
>
On Sat, Mar 9, 2013 at 12:25 PM, David Vincent-Jones
wrote:
> My system just went through a video/Xorg update and darktable now does
> not start with opencl. .. The opencl test program (glxspheres) runs
> just fine.
it's an open_GL_ test program, not cl.
> I found that my /etc/OpenCL/vendors
can you check if your vendor configuration is about reasonable? e.g.
mine looks like that
cat /etc/OpenCL/vendors/nvidia.icd
libnvidia-opencl.so.1
for an nvidia card.
-jo
On Sat, Mar 2, 2013 at 1:31 PM, David Vincent-Jones
wrote:
> Trying to start OpenCL on my system I get the following messag
Running it directly from the terminal with -d opencl appears to start
without any error messages and running with the same extension from a
normal icon is also running correctly and shows the opencl box checked
in the preferences list. . thanks ... I guess it is working
correctly :=))
Dav
Am 18.12.2012 21:31, schrieb David Vincent-Jones:
> After installing bumblebee on my Nvidia-Optimus graphics system I ran
> "optirun darktable -d opencl" . after which I was able to check the
> opencl box in the setup preferences.
>
> Can I now infer that opencl is correctly running on the s
Am 01.11.2012 18:03, schrieb Jens Fendler:
>
> Thanks a lot for the pointer!
>
> Jens
You're welcome :) Scanning through the forum I just found a tool that
might help in your case:
https://devtalk.nvidia.com/default/topic/483496/cuda-programming-and-performance/clcc-an-nvidia-opencl-command-lin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2012 05:15 PM, Ulrich Pegelow wrote:
> Am 31.10.2012 20:02, schrieb Ulrich Pegelow:
>> Am 31.10.2012 15:34, schrieb Jens Fendler:
>>
>> So, at the moment there is no real solution except of the
>> work-around you found yourself. In the past t
Am 31.10.2012 20:02, schrieb Ulrich Pegelow:
> Am 31.10.2012 15:34, schrieb Jens Fendler:
>
> So, at the moment there is no real solution except of the work-around
> you found yourself. In the past there used to be a user forum at
> www.nvidia.org with a dedicated section for opencl. Unfortunately
I'll just keep on trying things out which might have an effect and see
if I can find any other solution. At least we've reached a point where I
can make reasonable use of darktable on the new machine.
In the meantime getting in contact with NVidia might be a good idea to
perhaps get them workin
Am 31.10.2012 15:34, schrieb Jens Fendler:
> On 10/30/2012 10:39 PM, johannes hanika wrote:
>>> i would also try to remove all `const' from the code, we've had
>>> issues with that in the past (went away with the next driver
>>> version and came back with the one after that..).
>
> I tried that (r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2012 10:39 PM, johannes hanika wrote:
>> i would also try to remove all `const' from the code, we've had
>> issues with that in the past (went away with the next driver
>> version and came back with the one after that..).
I tried that (removi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2012 12:47 PM, Ulrich Pegelow wrote:
> Am 30.10.2012 22:13, schrieb Jens Fendler: If you are anyhow going
> to do some further testing, please also give this one a try:
>
> __kernel void blendop_mask_RAW (__read_only image2d_t in_a,
> __read_
Am 30.10.2012 22:13, schrieb Jens Fendler:
> Hi Johannes,
>
> On 10/30/2012 10:39 PM, johannes hanika wrote:
>
>>> GT540M here.
>
> Apart from the nvidia driver, do you think the version of VirtualGL or
> Bumblebee might have an influence?
>
>>> i would also try to remove all `const' from the c
On Wed, 31 Oct 2012 07:58:16 Jens Fendler wrote:
> I'm sorry if my mail sounded pressuring - it wasn't supposed to give
> anybody the impression they're obliged to respond quickly.
If I thought that you were "pressuring" me I would not have responded! :)
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2012 12:57 AM, Kevin wrote:
> On Tue, 30 Oct 2012 17:37:55 Jens Fendler wrote:
>> PS: Johannes and Kevin: you both mentioned running dt on optimus
>> cards as well. Does one of you happen to also have the same card
>> (i.e. GT640M)?
>
> My ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kevin,
On 10/31/2012 01:05 AM, Kevin wrote:
> On Tue, 30 Oct 2012 21:42:46 Jens Fendler wrote:
>> My previous question regarding anybody using the same hardware
>> (GT640M) has not yet been answered, but I would assume people
>> are actually using
On Tue, 30 Oct 2012 21:42:46 Jens Fendler wrote:
> My previous question regarding anybody using the same hardware
> (GT640M) has not yet been answered, but I would assume people are
> actually using (more or less) different adapters. If this is so, I
> believe it's a problem between this particular
1 - 100 of 123 matches
Mail list logo
