black or garbled info on left half of darkroom view when openCL enabled on Mac OS X
System: 15" macbook pro, early 2011, Mac OS X 10.7.5, AMD Radeon HD 6750M 1024 MB
running dark table 1.1.2 from dmg downloaded from sourceforge
When OpenCL is enabled, I see a black or garbled rectangle on the left half of landscape orientation images in darkroom view. when I resize the image, I see the image ungarbled with 'working' written across it for a moment, and then the left half appears garbled. This doesn't happen with portrait orientation images.
If I disable OpenCL, the problem goes away.
#2 Updated by Ulrich Pegelow over 7 years ago
Really seems to be an OpenCL bug.
Could you please from a terminal start 'darktable -d opencl -d perf' and post the output here? Of course OpenCL needs to be activated.
Is there any module this effect is linked to? I.e. from your screenshot it appears that only few modules like sharpen are activated. Does the effect go
away if you deactivate all possible modules?
#3 Updated by Warren Baird over 7 years ago
Here's the output. It isn't linked to a module - it happens even on unmodified files. However, it does seem to be related to specific files in some way - it's happening to all landscape mode raw files from my canon 5D mk II, but doesn't seem to happen to some older files from another camera, it also doesn't happen when I export one of the raw files to jpeg. Unfortunately the raw files I have are around 25mb, so I can't attach it here, but if there's an preferred alternative place to upload 'em, I can provide a file that reproduces it for me.
#4 Updated by Ulrich Pegelow over 7 years ago
- Assignee set to Ulrich Pegelow
According to the debug output you supplied, there is no obvious OpenCL problem. At least there is none that
the OpenCL driver could detect.
The symptoms you show in your screenshots indicate that we have an issue with tiling here. FYI the limited
memory of the OpenCL device forces darktable to split the image into tiles for the demosaic step, then process
those tiles sequentially and combine them again. In your screenshots we see that the left tile is garbled,
the right tile is OK. Garbled tiles can happen if we have a wrong assumption on the exact width and height of
a tile. We didn't have any reports on tiling problems since months, but that doesn't mean there is no bug left
in our code. Most likely this issue happens for very specific geometric combinations of input image dimensions,
tile dimensions forced by memory limits and final output image dimensions.
Do you observe any change of the effect if you resize the darktable window or if you take the crop&rotate module
and slightly crop the image?
I will need to dig deeper into the topic and try to simulate your specific situation on my system. Input image
should be no issue as I own a 5DMkII myself. Debugging might take some time. Please stay tuned as I might
need to ask you for some further details.
#5 Updated by Warren Baird over 7 years ago
I'm at work right now, so can't test the crop/rotate module until this evening (eastern time) - but I can tell you that resizing the darktable window didn't make the problem go away, but it did change the nature of what showed up in the garbled tile - at some window sizes it was completely black, and at other window sizes the image was garbled in different ways --- it did look a bit like issues with the line length usually - like it was reading the data assuming the width was X, but it was actually Y...
It seems like it impacts all of my landscape mode raw files. Portrait files are fine. and as I said above, converting a raw file that fails to jpeg (at the same resolution) and importing the jpeg does not fail, which I find a bit strange - is the tile processing different for RAW files?
#6 Updated by Ulrich Pegelow over 7 years ago
Problem happens in module demosaic when it comes to tiling. Demosaic is only used by RAW files, JPEGS are not affected. Module demosaic does the main
scaling job for us, which differs for screen output (scaled down) and for file output (1:1). As a consequence a different tiling codepath is taken. Only the one for the scaled-down output image seems to be broken. Unfortunately it is the by far more complex codepath...
#8 Updated by Ulrich Pegelow over 7 years ago
An 5DmkII image seems to be just at the borderline where your device with its specific limits needs to do tiling for demosaic.
I was able to generate the same tiling pattern like yours (i.e. tile sizes) here on my system after tweaking the limits a bit. However, in no
case I observed garbled output with my 5D landscape images. Do you always get the problem for uncropped landscape images of your 5D or
is it specific to certain images? If yes you might want to upload an example image e.g. with dropbox or sendbigfiles.
From my test it appears that we probably don't have an issue with the tile size calculations. That would be good news because fixing it would
have been really tedious.
I suspect that there is some problem with the interplay of tiling and your OpenCL device. The bad news is that we would need to test it
on your specific hardware. Would you be able to compile a patches version of darktable yourself for testing?
#9 Updated by Warren Baird over 7 years ago
I'm not set up to build darktable from source now - but I wouldn't object to getting it set up... The 'from source' instructions on the website seem to be linux-centric, but there is a blog post from last august that has mac instructions. I'll give it a try tonight and see if I can make it work...
#10 Updated by Ulrich Pegelow over 7 years ago
If you manage to get it compiling, here is proposed test: in file src/develop/tiling.c there are four occurrences of CL_FALSE. Please replace all of them by CL_TRUE.
In case you have issues compiling darktable we will certainly be able to somehow supply you a test image for download. I put parafin (Igor Kuzmin) in copy as he might be able to help.
#11 Updated by Warren Baird over 7 years ago
Hi Ulrich and Igor,
Some help from Igor might be useful --- I was trying to set up ports to at least have the dependancies installed - I already had a ports setup configured to get gimp and a few other tools on my mac - but I will admit I'm not that experienced with ports. I did a selfupdate/update outdated this morning, then followed the instructions from the blog to add "+no_gnome +no_x11 +quartz -x11" to the variants.conf, and tried to install the dependancies. It installed a few things succesfully, but when it tried to install libgphoto2 (the first thing that depended on gtk, I think), I got the following error.
Error: gtk2: Variant quartz conflicts with x11
Error: Unable to open port: Error evaluating variants
Error: Unable to execute port: upgrade gtk2 failed
I did a quick googling about and saw a mention of doing an upgrade with --enforce-variants to resolve these kinds of errors, but it didn't seem to work, and I'm offically supposed to be working now, so can't spend more time on it at the moment...
Igor - if there are quick and obvious things you can recommend, that'd be great (you can also move this to email if it's easier - my email is my username here followed by @alumni.uwaterloo.ca ) - otherwise I'll look at it more tonight...
#12 Updated by Igor Kuzmin over 7 years ago
Maybe you have both x11 and -x11 in variants.conf? I would try forcibly uninstall gtk2 port, might help... I'm not an expert on macports, so my solutions usually kind of brute force :)
Anyway, I could just produce DMG image with proposed changes, but only if it won't become a habit ;)
#13 Updated by Warren Baird over 7 years ago
well, I still don't particularly understand ports - but I found that if I started at the bottom of the dependancy stack - cairo, apparently, and explicitly install the packages with 'port install <package>' it seems to rebuild the new variant without complaint... kinda tedious... but we'll see if it all works at the end of the day... Or the end of the next day.... ;-)
#14 Updated by Warren Baird over 7 years ago
Ok - got it working... Was a bit more of an adventure than I thought... I couldn't get the darktable-1.1.2 source to build with the current mac ports - it looks like the GTK mac os integration API changed a bit. had to make a few changes like changing gtk_osxapplication_attention_request to gtkosx_application_attention_request to get it to work. I'll open a separate issue for that and attach a patch file.
Unfortunately, changing the CL_FALSE to CL_TRUE didn't change the behaviour... I did try tweaking things a little bit, and I did notice one thing that might be of interest. I forced the tile sizes to be a lot smaller and square in tiling.c
- 1415,1420 **
--- 1415,1424 ----
width = height = floorf(sqrtf((float)width*height));
+ /* force small square tiles */
+ width = height = floorf(sqrtf((float)width*height)) * 0.3f;
/* Alignment rules: we need to make sure that alignment requirements of module are fulfilled.
Modules will report alignment requirements via xalign and yalign within tiling_callback().
This made it make 20 tiles instead of just 2, and it looks like all of the tiles except the row of 4 on the right are garbled...
The debug output looked like this:
[default_process_tiling_cl_roi] use tiling on module 'demosaic' for image with full input size 5634 x 3753
[default_process_tiling_cl_roi] (5 x 4) tiles with max input dimensions 1228 x 1228
[default_process_tiling_cl_roi] tile (0, 0) with 1144 x 958 at origin [0, 0]
[default_process_tiling_cl_roi] tile (0, 1) with 1144 x 968 at origin [0, 918]
[default_process_tiling_cl_roi] tile (0, 2) with 1144 x 968 at origin [0, 1858]
[default_process_tiling_cl_roi] tile (0, 3) with 1144 x 958 at origin [0, 2786]
[default_process_tiling_cl_roi] tile (1, 0) with 1163 x 958 at origin [1114, 0]
[default_process_tiling_cl_roi] tile (1, 1) with 1163 x 968 at origin [1114, 918]
[default_process_tiling_cl_roi] tile (1, 2) with 1163 x 968 at origin [1114, 1858]
[default_process_tiling_cl_roi] tile (1, 3) with 1163 x 958 at origin [1114, 2786]
[default_process_tiling_cl_roi] tile (2, 0) with 1163 x 958 at origin [2238, 0]
[default_process_tiling_cl_roi] tile (2, 1) with 1163 x 968 at origin [2238, 918]
[default_process_tiling_cl_roi] tile (2, 2) with 1163 x 968 at origin [2238, 1858]
[default_process_tiling_cl_roi] tile (2, 3) with 1163 x 958 at origin [2238, 2786]
[default_process_tiling_cl_roi] tile (3, 0) with 1163 x 958 at origin [3384, 0]
[default_process_tiling_cl_roi] tile (3, 1) with 1163 x 968 at origin [3384, 918]
[default_process_tiling_cl_roi] tile (3, 2) with 1163 x 968 at origin [3384, 1858]
[default_process_tiling_cl_roi] tile (3, 3) with 1163 x 958 at origin [3384, 2786]
[default_process_tiling_cl_roi] tile (4, 0) with 1115 x 958 at origin [4518, 0]
[default_process_tiling_cl_roi] tile (4, 1) with 1115 x 968 at origin [4518, 918]
[default_process_tiling_cl_roi] tile (4, 2) with 1115 x 968 at origin [4518, 1858]
[default_process_tiling_cl_roi] tile (4, 3) with 1115 x 958 at origin [4518, 2786]
If you have other ideas you'd like me to try, let me know... I'm not sure I'm feeling up to digging into the code more tonight...
#15 Updated by Ulrich Pegelow over 7 years ago
So unfortunately no good news but thanks for all your tests. At least the issue is not caused by hitting some upper limit of your OpenCL device. Else it should have gone away with your smaller tile sizes.
I need to consider how to isolate the problem.
One quick test would be the following: please add a line:
Just close to line 1597 of tiling.c, so before dt_opencl_release_mem_object(input) is called. And another dt_opencl_finish(devid) close to line 1593 just before we call dt_opencl_read_host_from_device_raw(). I want to make double sure that all OpenCL processing is finished before we read the results and free our GPU buffers.
#17 Updated by Ulrich Pegelow over 7 years ago
As there is no improvement when we add dt_opencl_finish() it doesn't seem to be some kind of OpenCL synchronization problem.
About the right column of tiles. These are typically a bit more narrow as they only have to take over the remaining part of the
image in terms of width. Except of that they are handled as all other tiles.
If you are still willing to do some test, attached you find a replacement version of tiling.c
All it does is replace function _default_tiling_cl_roi() with a mockup. This mockup behaves exactly the same as the original
one in terms of tile size calculations. The only difference is that it does the final tile processing on CPU instead of GPU.
This should tell us if there is any issue with wrong tile size calculatios (an issue which is really complicated as we need to
deal with four different views of each tile) or if the real problem lies within OpenCL. The latter would be a completely different
#20 Updated by Ulrich Pegelow over 7 years ago
Yepp, the test confirms that it is really an OpenCL bug - not necessarily in darktable, maybe in the driver.
The key functions here are dt_opencl_write_host_to_device_raw() and dt_opencl_read_host_from_device_raw(), which in turn use OpenCL API calls clEnqueueWriteImage() and clEnqueueReadImage(). It looks like in one or both of them parameter row_pitch is not interpreted correctly.
I experienced several issues with ATI OpenCL drivers in the past. Do you have a chance to upgrade to the latest one? Catalyst 13.1 was released a few weeks ago and delivers quite some stability improvements as far as I can see.