I see some open bugs already with similar symptoms, but none has an answer. Basically I'm trying a very simple thing, clicking enabled OpenCL, restarting the LibreOffice and the checkbox is still disabled, no errors reported in logs.
Please post the opencl_devices.log and opencl_profile.xml from your user profile. Should be ~/.libreoffice/4/cache or similar.
$ cat ./.config/libreoffice/4/cache/opencl_devices.log Device Index: 0 Selected: false Device Name: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 20.1.6, DRM 3.63, 6.15.4-200.fc42.x86_64) Device Vendor: AMD Device Version: OpenCL 3.0 Driver Version: 25.1.4 Device Type: gpu Device Extensions: cl_khr_byte_addressable_store cl_khr_create_command_queue cl_khr_expect_assume cl_khr_extended_versioning cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_il_program cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_integer_dot_product cl_khr_spirv_no_integer_wrap_decoration cl_khr_suggested_local_work_size cl_khr_spirv_linkonce_odr cl_khr_gl_sharing cles_khr_int64 cl_khr_3d_image_writes cl_khr_depth_images cl_khr_pci_bus_info cl_khr_device_uuid cl_khr_subgroup_shuffle cl_khr_subgroup_shuffle_relative Device OpenCL C Version: OpenCL C 1.2 Device Available: true Device Compiler Available: true Device Linker Available: true Platform Name: rusticl Platform Vendor: Mesa/X.org Platform Version: OpenCL 3.0 Platform Profile: FULL_PROFILE Platform Extensions: cl_khr_icd cl_khr_byte_addressable_store cl_khr_create_command_queue cl_khr_expect_assume cl_khr_extended_versioning cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_il_program cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_integer_dot_product cl_khr_spirv_no_integer_wrap_decoration cl_khr_suggested_local_work_size cl_khr_spirv_linkonce_odr cl_khr_gl_sharing cles_khr_int64 cl_khr_3d_image_writes cl_khr_depth_images cl_khr_pci_bus_info cl_khr_device_uuid cl_khr_subgroup_shuffle cl_khr_subgroup_shuffle_relative
$ cat ./.config/libreoffice/4/cache/opencl_profile.xml <?xml version="1.0" encoding="UTF-8"?> <profile> <version>LibreOffice v1</version> <device> <type>opencl</type> <name>AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 20.1.6, DRM 3.63, 6.15.4-200.fc42.x86_64)</name> <driver>25.1.4</driver> <time>max</time> <errors>false</errors> </device> <device> <type>native</type> <time>1947648</time> <errors>false</errors> </device> </profile>
Device Index: 0 Selected: false Device Name: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 20.1.6, DRM 3.63, 6.15.4-200.fc42.x86_64) Selected: should be 'true' if enabled. Check Tools -> Options -> OpenCL 'Allow use of OpenCL' is checked enabled.
(In reply to V Stuart Foote from comment #4) > Device Index: 0 > Selected: false > Device Name: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 20.1.6, DRM > 3.63, 6.15.4-200.fc42.x86_64) > > Selected: should be 'true' if enabled. > > Check Tools -> Options -> OpenCL > > 'Allow use of OpenCL' is checked enabled. That's the whole purpose of this BZ, when I select OpenCL, click Apply, when it asks me, I click Restart Now -> it restarts with OpenCL disabled again
Here is a link how it looks: https://e.pcloud.link/publink/show?code=XZKq16Z0W35sQIxyNjBHhQwnSaPzu39c0D7
Fact that the OpenCL device is identified in opencl_devices.log and the opencl_profile.xml is generated suggests the device is seen and "tested" in OpenCLconfig::checkimplementation() If the vendor string reported is "AMD" but the denylist test [1] looks for "Advanced Microsystem Devices" could be an issue there. But not clear to me how the allowed profile matches are curated, if at all, and mostly will just fallback rejection to not use OpenCL with Calc. @quikee, anything to add? Anyhow, seems dupe of bug 105106 =-ref-= [1] https://opengrok.libreoffice.org/xref/core/opencl/source/openclconfig.cxx?a=true&r=d573e2ae17d2ff589ec7adc0dddf6a78db4cc93a&h=35#35
(In reply to V Stuart Foote from comment #7) > ... > https://opengrok.libreoffice.org/xref/core/opencl/source/openclconfig. > cxx?a=true&r=d573e2ae17d2ff589ec7adc0dddf6a78db4cc93a&h=35#35 Reading the link, it seems AMD is ok since there's: // For now, assume that AMD, Intel and NVIDIA drivers are good maAllowList.insert(ImplMatcher(u""_ustr, u""_ustr, u"Advanced Micro Devices, Inc\\."_ustr, u""_ustr, u""_ustr)); so it's in "maAllowList" not in "maDenyList"
(In reply to Julien Nabet from comment #8) > (In reply to V Stuart Foote from comment #7) > > ... > > https://opengrok.libreoffice.org/xref/core/opencl/source/openclconfig. > > cxx?a=true&r=d573e2ae17d2ff589ec7adc0dddf6a78db4cc93a&h=35#35 > > Reading the link, it seems AMD is ok since there's: > // For now, assume that AMD, Intel and NVIDIA drivers are good > maAllowList.insert(ImplMatcher(u""_ustr, u""_ustr, u"Advanced Micro Devices, > Inc\\."_ustr, u""_ustr, u""_ustr)); > > so it's in "maAllowList" not in "maDenyList" Right I had seen that, but reading the opencl_devices.log posted to comment 2 where it is log'd with "Device Vendor: AMD" and not as "Advanced Micro Devices, Inc" So does an "AMD" ident actually get allowed?
After having installed rusticl, I could debug a bit. The pb is in evaluateScoreForDevice see https://opengrok.libreoffice.org/xref/core/opencl/source/opencl_device.cxx?r=235ae98ae614315cfe3bb2baf52ca442bcc2f592&mo=3466&fi=138#138 LO searches extensions cl_khr_fp64 and cl_amd_fp64. If none is present, it considers there's no "64-bit float support present", so it can't calculate an fTime. The result is it doesn't retain the device. Anyway, I tried to force this part but it still fails.
(In reply to Julien Nabet from comment #10) > The result is it doesn't retain the device. > > Anyway, I tried to force this part but it still fails. So does this help? Launch with 'RUSTICL_FEATURES=fp64'? https://www.phoronix.com/news/Rusticl-OpenCL-FP64-Doubles And maybe update to distro's build of rusticl from latest (2 July 2025) MESA 25.1.5 release?
(In reply to V Stuart Foote from comment #11) > (In reply to Julien Nabet from comment #10) > > > The result is it doesn't retain the device. > > > > Anyway, I tried to force this part but it still fails. > > So does this help? Launch with 'RUSTICL_FEATURES=fp64'? > > https://www.phoronix.com/news/Rusticl-OpenCL-FP64-Doubles > > And maybe update to distro's build of rusticl from latest (2 July 2025) MESA > 25.1.5 release? No difference with or without RUSTICL_FEATURES=fp64, I've also tried 25.1.5 and main branch of mesa.
V Stuart: export RUSTICL_FEATURES=fp64 helped indeed! The fTime is no more the pb now but it's the allow/deny list. I'm trying some changes in opencl/source/openclconfig.cxx by adding new lines in maAllowList but even after: make opencl make make postprocess rm -rf ../user when I test with: SAL_LOG=+INFO SAL_INFO_LOG="+opencl.device" ./soffice &> /tmp/logs.txt I don't see the new entries in logs. I suppose I miss something obvious but for the moment I'm stuck.
Created attachment 201695 [details] opencl logs I made some progress here. In fact, this allow list isn't used at all, at least during the opencl test. Here's what I did: diff --git a/officecfg/registry/schema/org/openoffice/Office/Common.xcs b/officecfg/registry/schema/org/openoffice/Office/Common.xcs index 869790296884..4be502790d38 100644 --- a/officecfg/registry/schema/org/openoffice/Office/Common.xcs +++ b/officecfg/registry/schema/org/openoffice/Office/Common.xcs @@ -5499,7 +5499,7 @@ <info> <desc>Like OpenCLDenyList, but for combinations known to be good.</desc> </info> - <value oor:separator=";">Linux//Advanced Micro Devices, Inc\.//1445\.5 \(sse2,avx\);//Advanced Micro Devices, Inc\.//;//Intel\(R\) Corporation//;//NVIDIA Corporation//</value> + <value oor:separator=";">Linux//Advanced Micro Devices, Inc\.//1445\.5 \(sse2,avx\);//Advanced Micro Devices, Inc\.//;//Intel\(R\) Corporation//;//NVIDIA Corporation//;Linux//Mesa%2FX.org//</value> </prop> <prop oor:name="SelectedOpenCLDeviceIdentifier" oor:type="xs:string" oor:nillable="false"> <info> and now, I collected the logs attached. I noticed these: 109462:warn:opencl:59292:59292:opencl/opencltest/main.cxx:84: Device not found: AMD Radeon RX 570 Series (radeonsi, polaris10, ACO, DRM 3.61, 6.12.33+deb13-amd64) 109463:opencltest: /home/julien/lo/libreoffice/opencl/opencltest/main.cxx:85: void runTest(const char *, const char *): Assertion `false' failed. 109467:warn:opencl:59262:59262:desktop/source/app/opencl.cxx:96: CL driver test failed - disabling: 134
Created attachment 201696 [details] patch This patch has 2 parts: 1) adding Mesa/X.org in officecfg/registry/schema/org/openoffice/Office/Common.xcs 2) the other part is more important and was made with the help of ChatGPT. Since I know too few about OpenCL, it needs some people to review this. In addition of this patch, I had to change the precision in cl-test.ods (it's in ./instdir/program/opencl/cl-test.ods) B2 cell contains the precision, I changed 10-12 by 10-7. According to ChatGPT this last change is needed (at least in my case) because "kernel returns values in single precision (float), while the test and Calc use double precision (double, IEEE-754 64-bit). With only 23 bits of mantissa, the rounding error of a float quickly exceeds 1e-12." I haven't yet proposed the patch on gerrit since it's mainly done by ChatGPT.
@Julien, Good that it makes enough sense that you're able to add the "Mesa/X.org" vendor that the rusticl reports and get a response as logged. But not too suprised that it then can't use it and fails it disabled. That part of the core looks pretty dusty. Maybe Tomaž or Eike (cc'd here) can spot the issue for testing/activation of the fp64 for rusticl--or at least help you to not spin your wheels over getting to to activate and function in some sense.
The runtime tests are there for a reason, and if they fail that specific OpenCL driver remains disabled on purpose. While ChatGPT in general is right on "the test and Calc use double precision (double, IEEE-754 64-bit). With only 23 bits of mantissa, the rounding error of a float quickly exceeds 1e-12", I don't know if "kernel returns values in single precision (float)" is actually correct (though it seems it is here); why would the OpenCL driver use float single precision even though RUSTICL_FEATURES=fp64 was requested that allegedly should use 64-bit floating-point double precision? Of course lowering precision requirements eventually will let the test pass, but the purpose of the test is to ensure that OpenCL results are sufficiently close to non-OpenCL results. Other known-good OpenCL drivers pass the test, so lowering the test threshold to make this driver pass sounds much ill-advised to me.
(In reply to Eike Rathke from comment #17) > The runtime tests are there for a reason, and if they fail that specific > OpenCL driver remains disabled on purpose... Thank you Eike for the feedback, I expected that lowering the threshold would be wrong but what about the rest? I mean, do you think it worths it I submit the patch without the change of threshold or will it be rejected because mainly provided by ChatGPT ?
Just for the record, I've submitted 2 patches: 1) https://gerrit.libreoffice.org/c/core/+/187591 which just adds Mesa/X.org in allowList 2) https://gerrit.libreoffice.org/c/core/+/187603 which tries to improve opencltest and comes from ChatGPT Remark: I quote the IA not for the advertisement (I think it doesn't need it), but for transparency (I wouldn't have been able to do this patch since I know too few openCL). However I could test it and without it even when lowering the threshold of the ods file, openCL wouldn't be enabled. Also, I read the changes and it seems relevant (eg CL_MEM_COPY_HOST_PTR instead of CL_MEM_USE_HOST_PTR). Remark 2: of course it doesn't fix the pb here since the pb might be in rusticl.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9ad8b4b9e1b4e2ffb6533bc119f24ad326a97a07 Related tdf#167365: declare "Mesa/X.org" as openCL driver on Linux It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Remove target since the patch doesn't fix the pb.