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,
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 I do? Thanks a lot!
darktable -d opencl
[opencl_init] opencl related configuration options:
[opencl_init]
[opencl_init] opencl: 1
[open
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
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 card appears to be a GT 630M. This is what is reported by `optirun nvidia-
smi`
Kevin
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 code, we've h
On Wed, Oct 31, 2012 at 8:42 AM, Jens Fendler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/30/2012 09:21 PM, Ulrich Pegelow wrote:
>> Am 30.10.2012 20:13, schrieb Jens Fendler:
>>> On 10/30/2012 08:43 PM, Ulrich Pegelow wrote:
>>>
>>>
>>> Nope - doesn't work. (Just like the e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2012 09:21 PM, Ulrich Pegelow wrote:
> Am 30.10.2012 20:13, schrieb Jens Fendler:
>> On 10/30/2012 08:43 PM, Ulrich Pegelow wrote:
>>
>>
>> Nope - doesn't work. (Just like the easier variant using just
>> gopacity*1.0f also did not..)
>>
>
Am 30.10.2012 20:13, schrieb Jens Fendler:
> On 10/30/2012 08:43 PM, Ulrich Pegelow wrote:
>
>
> Nope - doesn't work. (Just like the easier variant using just
> gopacity*1.0f also did not..)
>
> btw, when the compilation fails, dt gives me two empty lines of output
> under a "BUILD LOG:" header
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2012 08:43 PM, Ulrich Pegelow wrote:
Nope - doesn't work. (Just like the easier variant using just
gopacity*1.0f also did not..)
btw, when the compilation fails, dt gives me two empty lines of output
under a "BUILD LOG:" header (I'm using "
Am 30.10.2012 19:28, schrieb Jens Fendler:
> Perhaps we're getting a bit closer now.
>
> c) compiles fine (I actually tried that in between as well).
> d) fails again.
>
> The following, however, works:
>
> __kernel void
> blendop_mask_RAW (__read_only image2d_t in_a, __read_only image2d_t
> in_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Perhaps we're getting a bit closer now.
c) compiles fine (I actually tried that in between as well).
d) fails again.
The following, however, works:
__kernel void
blendop_mask_RAW (__read_only image2d_t in_a, __read_only image2d_t
in_b, __write_only
Let's see what the following does:
c) 1:1 copy of blendop_mask_Lab
__kernel void
blendop_mask_RAW (__read_only image2d_t in_a, __read_only image2d_t
in_b, __write_only image2d_t mask, const int width, const int height,
const float gopacity, const int blendif, global const float
*blen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ulrich,
thanks, but both options fail with code -30 just as before.
Jens
On 10/30/2012 07:20 PM, Ulrich Pegelow wrote:
> Hi Jens,
>
> strange, that kernel is probably the least thrilling in there. The
> only thing I could imagine is some problem
Hi Jens,
strange, that kernel is probably the least thrilling in there. The only
thing I could imagine is some problem of your compiler. Here are a few
ad-hoc ideas:
a)
__kernel void
blendop_mask_RAW (__read_only image2d_t in_a, __read_only image2d_t
in_b, __write_only image2d_t mask, const int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
thanks a lot for your support sp far, but so far it seems nothing
really worked. I always get stuck at the same point, which is: other
GL apps run fine through optirun, but darktable's openCL support fails
when it comes to compiling blendop.cl
On Mon, 29 Oct 2012 17:11:53 Jens Fendler wrote:
> Hi all,
>
> I just got a new laptop, which I would like to use for DT processing.
> One problem, however, seems to be the NVidia Optimus graphics card,
> which gives me problems with the OpenCL acceleration in darktable.
> Everything else I've
fwiw, i have an optimus card in my laptop, too, and it runs fine with
opencl through optirun, using the 295 driver.
might be another subtle difference/bug in the compiler (we've had
issues with const/constant memory before between driver versions).
j.
On Tue, Oct 30, 2012 at 9:04 AM, Jens Fendle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> It looks like it.. Is there a way to somehow debug the kernels?
>> Or otherwise get a better idea as to what exactly could be wrong
>> with blendop?
>
> Blendop.cl contains several kernels. You could comment out one
> after the other and try to iso
Am 29.10.2012 20:53, schrieb Jens Fendler:
> Hi Ulrich,
>
> On 10/29/2012 09:41 PM, Ulrich Pegelow wrote:
>> Hmm, what happens when you remove darktable's cached opencl
>> binaries?
>
>> cd $HOME/.cache/darktable rm -r cached_kernels_for_GeForceGT640M
>
>
> This also doesn't make a difference.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ulrich,
On 10/29/2012 09:41 PM, Ulrich Pegelow wrote:
> Hmm, what happens when you remove darktable's cached opencl
> binaries?
>
> cd $HOME/.cache/darktable rm -r cached_kernels_for_GeForceGT640M
>
This also doesn't make a difference. I tried t
Am 29.10.2012 20:41, schrieb Jens Fendler:
>> As to commenting out one of the kernels: all possible things might
>> happen here. We have not designed the code to survive such a case.
>
> Hmm.. ok. But is there perhaps another way to isolate the problem?
> - From one of the combinations I tried it
Hmm, what happens when you remove darktable's cached opencl binaries?
cd $HOME/.cache/darktable
rm -r cached_kernels_for_GeForceGT640M
Then start darktable again. From the outputs it seems that in all cases
darktable gets a precompiled binary from there. Only blendop seems not
to be in there and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ulrich,
>> On 10/29/2012 08:33 PM, Ulrich Pegelow wrote:
>>> For some reason blendop.cl can not be built (compiled+linked)
>>> by clBuildProgram(). The error code is -30 (CL_INVALID_VALUE)
>>> which would indicate we called the routine with wrong
>
Am 29.10.2012 20:15, schrieb Jens Fendler:
> Hi Ulrich,
>
> first of all thanks for the fast response.
>
> On 10/29/2012 08:33 PM, Ulrich Pegelow wrote:
>> For some reason blendop.cl can not be built (compiled+linked) by
>> clBuildProgram(). The error code is -30 (CL_INVALID_VALUE) which would
>>
Hi Ulrich,
first of all thanks for the fast response.
On 10/29/2012 08:33 PM, Ulrich Pegelow wrote:
For some reason blendop.cl can not be built (compiled+linked) by
clBuildProgram(). The error code is -30 (CL_INVALID_VALUE) which would
indicate we called the routine with wrong parameters. This
Hi Jens,
this is something new which we have not seen before.
For some reason blendop.cl can not be built (compiled+linked) by
clBuildProgram(). The error code is -30 (CL_INVALID_VALUE) which would
indicate we called the routine with wrong parameters. This is a bit
surprising as all other kernels
Hi all,
I just got a new laptop, which I would like to use for DT processing.
One problem, however, seems to be the NVidia Optimus graphics card,
which gives me problems with the OpenCL acceleration in darktable.
Everything else I've tried so far sems to work fine with bumblebee's
"optirun".
44 matches
Mail list logo
