Hi ,
Using darktable 1.5+1906~g394a139,
Darktable crash when exporting with $(LABELS) .
*** Error in `darktable': munmap_chunk(): invalid pointer:
0x7f4f3d273119 ***
Abandon (core dumped)
--
Slashdot TV. Videos for Ner
Am Montag, 6. Oktober 2014, 17:03:38 schrieb parafin:
> Ah, I thought they fixed it when I wrote my previous mail. If they
> didn't, then my point isn't even theoretical.
Couldn't Debian just patch data/darktableconfig.xml.in to have a changed
default for opencl_library?
Tobias, moving back unde
parallel_export has been dropped from the preferences dialogue some time
ago because of the explained intrinsic parallelization.
Regards,
Markus
Am 06.10.2014 um 15:11 schrieb KOVÁCS István:
> Hmm... strange. The documentation is a bit confusing:
> - http://www.darktable.org/usermanual/ch06s02.ht
Hmm... strange. The documentation is a bit confusing:
- http://www.darktable.org/usermanual/ch06s02.html.php 'number of
background threads: This controls how many parallel threads are used
to create thumbnails during import. On 32bit systems it is strongly
recommended to set this to 1. Needs a rest
Ah, I thought they fixed it when I wrote my previous mail. If they
didn't, then my point isn't even theoretical.
On Mon, 6 Oct 2014 14:52:16 +0200
"Michael Below" wrote:
> Hi parafin,
>
> see my last mail with the quote from Vincent Danjean: NVidia, AMD and ocl-icd
> agree that the current ABI
Perfect example of exactly what I was talking about:) Vendor had his
own ideas about SONAME. It's good that Intel fixed that, but it
highlights the problem of standards existing only de-facto - Intel
used SOVERSION=1 only because AMD and NVidia already chose this number.
Let me make another point -
Because it is not just one thread ;)
darktable exploits parallelization at different levels. Most, if not all
modules distribute their computations automagically to different
threads. Adding more concurrency by running several rendering pipes in
parallel will most likely have a negative performanc
Hi parafin,
see my last mail with the quote from Vincent Danjean: NVidia, AMD and ocl-icd
agree that the current ABI is soversion=1. Intel doesn't include a soversion,
but their libOpenCL.so isn't legally redistributable anyway. So I think Intel
might need a workaround, not AMD, Nvidia & co.
C
> I'm not too sure how this is supposed to work. Probably I am doing
> something wrong.
>
> I took an HDR Tiff file in camera (for comparison purposes), and then I
> took 5 RAW files of the same scene, bracketing across 5EV. With the 5 RAWs
> in darktable, I pressed the HDR button to get a DNG file
That's all good and well, and makes much sense, but my question was
where can we find what exactly SOVERSION=1 means for libOpenCL? Is it
guarantied that every vendor uses this version (and not 0 or 2)? I
wasn't asking to make an exception for darktable, I was asking to make
an exception for OpenCL
Why do you limit yourself to just 1 thread? On my system (4 GB RAM,
old dual-core CPU) 2 threads work fine with 8 GB of swap space.
On 6 October 2014 11:38, Markus Jung wrote:
> Hello Bernhard,
>
> most likley, something with your darktable configuration went wrong.
> Please take a look at your c
* Michael Below [10-06-14 08:23]:
[...]
> I think referencing a shared library without an ABI version is avoided
> with a reason. I don't see the need to introduce an exception for
> darktable. Like any other program, darktable might run into problems if
> a future libOpenCL.so.2 omits parts of
Another relevant quote from Vincent Danjean, author of ocl-icd-libopencl1, in a
bug report to Intel, because Intel were using libOpenCL.so as soname in their
Linux SDK: https://software.intel.com/en-us/forums/topic/277598
"The Linux SDK for OpenCL provides the libOpenCL.so library with "libOpenC
-Ursprüngliche Nachricht-
Von: Michael Below [mailto:be...@judiz.de]
Gesendet: Montag, 6. Oktober 2014 14:20
An: 'parafin'
Betreff: AW: [Darktable-users] OpenCL detected by clinfo, not detected by dt,
ideas?
Hi parafin,
I think referencing a shared library without an ABI version is av
Il giorno lun 6 ott 2014 alle 12:26, Michael Below ha
scritto:
Hi Tomas,
Thanks for your input. For me, OpenCL is now working, (nearly)
without workarounds, using the packages from Debian testing (nvidia
driver v. 340).
My steps:
- Debian testing, ocl-icd-libopencl1 is providing
l
On Mon, 6 Oct 2014 12:26:05 +0200
"Michael Below" wrote:
> 2. And darktable doesn’t use the correct SONAME when it tries to load
> libOpenCL.so instead of libOpenCL.so.1. This works only if
> nvidia-cuda-toolkit (or, probably, any other OpenCL development package) is
> installed, which p
Hi Tomas,
Thanks for your input. For me, OpenCL is now working, (nearly) without
workarounds, using the packages from Debian testing (nvidia driver v. 340).
My steps:
- Debian testing, ocl-icd-libopencl1 is providing libOpenCL.so.1
- Purge all nvidia packages
-
Hello Bernhard,
most likley, something with your darktable configuration went wrong.
Please take a look at your core preferences:
http://www.darktable.org/usermanual/ch06s02.html.php
I am using (with the same amount of RAM):
mipmap cache: 1536
background threads: 1
host memory limit: 4096
minimum
Hi,
if I export only a few pictures (around 10 pictures with 8-10 modules
aktiv) in dt I abserved that dt takes all the memory that is just abailable
(in this case 5gb) and also allocate most of the swap (10gb). often it
crashes. change settings for number of used cores do not change this
behavior
Hi,
>From what I've read so far this may be slightly different situation. However
I thought sharing it may help in some way? I am running Mint 17 (based on
Ubuntu 14.04). I just bought a new GeForce GTX 980 graphics card and
installed drivers 343 following these notes - http://www.binarytides.com
20 matches
Mail list logo
