Is there any particular reason why "Allow use of OpenCL" is already turned off on first start in 5.2.0.3? I have an A10-7800 with ~2 month old drivers, so I don't see any reason why it should be off (unless it's the new default). I can supply OpenCL profile/log files if needed. I also don't see any information on CL in the About dialog that is already there in 5.1.5.1: Version: 5.2.0.3 Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: hu-HU (hu_HU) vs. (taking Miguel's from another bug report) Version: 5.1.5.1 (x64) Build ID: bb431b2be5fb7772067efc27a3cc98b6927c7b4c CPU Threads: 1; OS Version: Windows 6.19; UI Render: GL; Locale: es-ES (es_ES); Calc: CL
Ah - so - can you turn the setting on, re-start, and then see if it is still off ? If so - then your driver failed to calculate correctly - we test it then and disable if there are problems. Failing that you could tweak the calc OpenCL settings to a small formula-group size, and load the OCL test spreadsheet that we ship in the install - called program/opencl/cl-test.ods - and force it to re-calculate: ctrl-shift-F9 possibly you'd have to do that in an older version that doesn't disable CL on mis-calculation. It would be good to have your cache/cl_device_info.txt file (if I remember the name correctly) if you can attach it. Also - could you update your OCL implementation and try again - we should run nicely on that hardware =) from a clean profile OCL should be on. Thanks !
Created attachment 126352 [details] Screenshot of cl-test.ods Yes, I can turn it on, and it stays on. My driver is actually newer than the one offered on AMD support site (which is Crimson Edition 16.3.2), because I sometimes update with beta Catalysts (that are only offered for desktop GPUs, not for APUs). In cl-test.ods I see a huge difference among certain Stat results (up to 6*10^-1). And not only the difference is big, upon multiple recalculations the 2nd Stat result varies between 6.81 and 7.38, which is quite large (formula is "=VAR(A7;B7)+NORMSDIST(A7)-COVAR(A6:A7;B6:B7)+PEARSON(A6:A7;B6:B7)+SLOPE(A6:A7;B6:B7)"). This is probably the reason why OpenCL gets turned off by default.
Created attachment 126353 [details] opencl_devices.log
Created attachment 126354 [details] opencl_profile.xml
Created attachment 126380 [details] CL test with buggy Stat formulas Here's an expanded version of the buggy Stat formulas. Columns D - H are the individual stat functions, column I is the sum of the values in D-H, column J is the one big formula from the test file. It appears that NORMSDIST() (column E) is the cultprit, but only the ones E5, E6 and E8 (the ones with red border). They aren't only incorrect, but vary after each recalculation, and there's huge variance (E8 is one time -418033919,523, another time 0,921294847). The sums in I and J that should be the same because they're the sum of the same formulas, aren't. Can others with NVIDIA or Intel hardware and OpenCL drivers check if I5=J5, I6=J6, I8=J8 for them, and respective differences ([I,J][18,19,21]) are < 10^12?
Those who test this, set this first: 'Tools -> Options... -> LibreOffice Calc -> Formula -> Detailed Calculation Settings' to 'Custom', then click 'Details...', and change 'Minimum data size for OpenCL use' to 2.
Created attachment 126382 [details] Screenshot in 4.4.0.3 (of the attached test sheet, not cl-test.ods) Also reproduced in 5.0.0.5 with attached spreadsheet and settings described in Comment 6. Not reproduced in 4.4.0.3 (the dialog for the settings looks a bit different, but the same setting can be set), see attached screenshot, which shows differences within threshold, and I and J columns equal. The results are also stable. Tentatively setting regression.
An interesting observation: If only E5-E6 and data A6-A7 are kept in the buggy example, the results are still wrong, and vary. If either E5 or E6 is deleted in addition (so only one formula remains), the remaining formula gives correct result.
Oh, of course it would be correct for a single formula, the least possible minimum data size for OpenCL is 2.
Ah, too bad I had not noticed this bug report and your excellent analysis earlier, as it is exactly the same issue I noticed myself last Friday, and investigated yesterday. I also have an A10-7800. The problem should be fixed now with 4afa88f289de1150850b52d36f2345fd9a9fbc1e in master (which has been cherry-picked to the 5.2, 5.1.5 and 5.1 branches a moment ago): commit 4afa88f289de1150850b52d36f2345fd9a9fbc1e Author: Tor Lillqvist <tml@collabora.com> Date: Mon Jul 25 19:09:32 2016 +0300 No need for own implementation of erfc() in OpenCL The own code was copied from the C++ one we used to have in sal/rtl/math.cxx but which was removed in a62bc6a65abb47adb0e4caff7e38823c15b302fc. However, it did not work correctly on some machines at least, like my AMD A10-7800 running Windows 10. I was unable to figure out why not. This lead to OpenCL being disabled by the Desktop::CheckOpenCLCompute() code we now run early on startup. Anyway, as OpenCL has erfc(), just use that. Change-Id: I7ba6104fc4975cd570358760fa97a19390a54cce
The important thing is that it got fixed, thanks! There was no feedback from Intel/NVIDIA users, but do you think this bug affected devices from those vendors as well?
Unless proven otherwise , I would tend to assume it is very specific to AMD OpenCL software for their integrated CPU+GPU chips.
I didn't notice 5.2.0 missing from the cherry-pick list. Oh well. Verified fixed in 5.1.5.2.