haze removal OpenCL fails at export

[aurelienpierre]

Describe the bug
With OpenCL enabled on Nvidia and exporting with high-quality resampling, the output of haze removal doesn't match the CPU export, the darkroom preview and the OpenCL export without high quality resampling.

I have tried to remove -cl-finite-math-only in common/opencl.c:404, it's the same.

To Reproduce
Steps to reproduce the behavior:

1. use picture from https://discuss.pixls.us/t/play-raw-underexposed-landscape/14682
2. unzip and apply
   DSC00128.ARW.zip
3. export with high-quality resampling and OpenCL on.

Screenshots

darkroom preview:

valid export (OpenCL without high-quality resampling):

valid export (CPU with high-quality resampling):

faulty export (OpenCL with high-quality resampling):

Platform (please complete the following information):

• OS: Fedora 30
• Driver: Nvidia 430.40, CUDA Version: 10.1, OpenCL version 1.2
• GCC 9
• master with cc15f8d

Additional context
@rabauke

[pitbuster]

Haze removal does export differently depending on export size #2845

[rabauke]

@aurelienpierre Just to narrow the source of the the bug: Have you tried to choose different options for pixel interpolator under core options. To my understanding it should affect high-quality resampling.

[rabauke]

I am unable to reproduce the reported issue. Exports (at full scale) look fine with and without high-quality resampling. Changing pixel interpolator option has not effect either. My configuration:

• darktable git master branch, built today
• Ubuntu 18.04
• Nvidia 390.116
• gcc 8.3

[dt_codepaths_init] will be using HIGHLY EXPERIMENTAL plain OpenMP SIMD codepath.
0.274647 [opencl_init] opencl related configuration options:
0.274663 [opencl_init]
0.274669 [opencl_init] opencl: 1
0.274677 [opencl_init] opencl_library: ''
0.274683 [opencl_init] opencl_memory_requirement: 768
0.274688 [opencl_init] opencl_memory_headroom: 300
0.274693 [opencl_init] opencl_device_priority: '/!0,//'
0.274698 [opencl_init] opencl_mandatory_timeout: 200
0.274704 [opencl_init] opencl_size_roundup: 16
0.274709 [opencl_init] opencl_async_pixelpipe: 0
0.274713 [opencl_init] opencl_synch_cache: active module
0.274718 [opencl_init] opencl_number_event_handles: 25
0.274723 [opencl_init] opencl_micro_nap: 1000
0.274728 [opencl_init] opencl_use_pinned_memory: 0
0.274734 [opencl_init] opencl_use_cpu_devices: 0
0.274739 [opencl_init] opencl_avoid_atomics: 0
0.274743 [opencl_init]
0.274896 [opencl_init] could not find opencl runtime library 'libOpenCL'
0.275017 [opencl_init] could not find opencl runtime library 'libOpenCL.so'
0.275221 [opencl_init] found opencl runtime library 'libOpenCL.so.1'
0.275258 [opencl_init] opencl library 'libOpenCL.so.1' found on your system and loaded
0.295201 [opencl_init] found 1 platform
0.295235 [opencl_init] found 1 device
0.295488 [opencl_init] device 0 GeForce GT 730M' has sm_20 support. 0.295619 [opencl_init] device 0 GeForce GT 730M' supports image sizes of 16384 x 16384
0.295627 [opencl_init] device 0 `GeForce GT 730M' allows GPU memory allocations of up to 501MB
[opencl_init] device 0: GeForce GT 730M
GLOBAL_MEM_SIZE: 2004MB
MAX_WORK_GROUP_SIZE: 1024
MAX_WORK_ITEM_DIMENSIONS: 3
MAX_WORK_ITEM_SIZES: [ 1024 1024 64 ]
DRIVER_VERSION: 390.116
DEVICE_VERSION: OpenCL 1.2 CUDA
0.396487 [opencl_init] options for OpenCL compiler: -w -cl-finite-math-only -DNVIDIA_SM_20=1 -DNVIDIA=1 -I"/usr/local/darktable/share/darktable/kernels"

[junkyardsparkle]

I am unable to reproduce the reported issue. Exports (at full scale) look fine

I think you'll only see this when not exporting at full size?

[junkyardsparkle]

Even when exporting at 640 pixels, though, I can only produce a less dramatic (but still quite apparent) difference (nvidia OpenCL enabled):

Without 'high quality resampling'

With 'high quality resampling':

(It seems to me that 'high quality resampling' is a somewhat misleading description of what that option actually does... it sounds like a way of changing the interpolation algo, really.)

[rabauke]

Exporting the images with a width of 1024 pixels (at the scale used in the bug report by @aurelienpierre ) I am still unable to reproduce the faulty exports, which have been reported for exporting via OpenCL enabled and high-quality resampling. I can, however, reproduce the small effect of high-quality resampling on the output result, which has bee reported by @junkyardsparkle . This can be observed with OpenCL enabled as well as with OpenCL disabled.

[aurelienpierre]

I am unable to reproduce the reported issue. Exports (at full scale) look fine with and without high-quality resampling. Changing pixel interpolator option has not effect either. My configuration:

The high quality resampling processes the full-scale image, then rescales last in the pipe. The other option rescales first, and process the pipe then. Exporting at full scale is the same with both options (no rescaling at all). It is expected for convolutions that the result might be different, but not that much.

The results above are obtained with Lanczos3 interpolator.

I have tried to reproduce the bug today, I can't. Another black magic thing… Sorry for the noise.

[junkyardsparkle]

I have tried to reproduce the bug today, I can't. Another black magic thing… Sorry for the noise.

Not sure this is relevant, but there are some references to a mysterious 'doctor' module in the provided history... ;-)