auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Id28f5699a4a9c0078a1326e81e833b75951f97cc
We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This moves a combination of tools::Time::GetSystemTicks(), canvas
ElapsedTime::getSystemTime() and the opencl timing implementation
into tools::Time::GetMonotonicTicks() as a monotonic microsecond
time source.
Change-Id: I5c9263540b8af55b2eeca6126e288129427f6e8e
Reviewed-on: https://gerrit.libreoffice.org/41991
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Rename the global opencl namespace to openclwrapper. Its public API is
after all declared in a file called openclwrapper.hxx. The confusion
started when part of the OpenCL code was moved out from sc some years
ago.
Change-Id: I98ebd8498b2244804411e5de9169eb619f86070b
If SAL_DISABLE_OPENCL is set we don't want to do any kind of
OpenCL initialization. Put an extra guard in fillOpenCLInfo
(and similar methods in opencl package) to prevent that.
Put the check if OpenCL can be used into one place which checks
SAL_DISABLE_OPENCL and UseOpenCL in configuration.
Change-Id: Icc216d4299d3a7942843117ab9b9411de8075b11
Reviewed-on: https://gerrit.libreoffice.org/30025
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Add a flag to the OpenCLZone indicating whether we are performing the
first-start OpenCL functionality verification, so that if we run into
a crash that is caught by the VCL VCLExceptionSignal_impl() handler,
we terminate the process with the EXITHELPER_NORMAL_RESTART
status after first having disabled OpenCL use. The wrapper process will
then restart soffice.bin. This is for Windows only so far.
This matches what we do if OpenGL fails early during start of
LibreOffice.
Change-Id: Ibb9bf3a86b7521bf16728de2a118ad4323be674b
Reviewed-on: https://gerrit.libreoffice.org/28086
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
OpenCL validation needs to happen before drivers are used in
anger. This should isolate any crashes, and/or mis-behavior to
We use app version, CL driver version and file time-stamp to
trigger re-testing the device. If anything fails: hard disable
OpenCL.
We use an opencl validation sheet (cl-test.ods) and install it.
It is a minimal CL set - it requires a very short formula group
length, and combines several CL functions into few formulae to
test more.
The sheet structure, in particular the manual squaring / SQRT is
necessary to stick within the default CL subset, and ensure that
formulae are CL enabled from the root of the dependency tree up.
Change-Id: I18682dbdf9a8ba9c16d52bad4447e9acce97f0a3
Reviewed-on: https://gerrit.libreoffice.org/27131
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Guard OpenCL calls with OpenCLZone, so if a OpenCL call crashes we
detect this and disable OpenCL so next time the user doesn't encounter
the crash at the same calculation because he has a broken OpenCL
drivers. Similar has been implemented for OpenGL with good results.
Additionaly we persistently remember a known good OpenCL device ID and
driver version so we can match this and perform calculation tests when
they change. This is to ensure that the selected OpenCL device performs
as we expect. In this commit the calculation tests aren't included yet.
Remove complex static initializer in opencl wrapper library.
Change-Id: I1a8b81ee31298731efcf63dc6a476955afc035e9
Reviewed-on: https://gerrit.libreoffice.org/27064
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
This code took tens of second typically, which is utterly pointless.
Instead run the loop for max a second, after which estimate how long
it would have taken to process all of the data.
Don't confuse the "native CPU" term here with a CPU-based device
of an actual OpenCL implementation. That is a completely different
thing. This "native CPU" thing here is just our way to estimate how
much time it takes to do calculations using normal C++ code on the
CPU.
Change-Id: I92f5eedc06bbaaef6a9b5322fefec9d41f0db505
Reviewed-on: https://gerrit.libreoffice.org/26774
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
are actually pointer vars.
Also convert from regex to normal code, so we can enable this
plugin all the time.
Change-Id: Ie36a25ecba61c18f99c77c77646d6459a443cbd1
Reviewed-on: https://gerrit.libreoffice.org/24391
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
changes:
- Clew misses a lot of things, added defines needed for gathering
platform and device info.
- Refactored profile saving and loading to use libxml2 instead
the weird type of saving the profile data.
- Added an additional "log" file which is similar to the OpenGL
but it writes the OpenCL relevant information like which devices
and platforms are available (+ all the extra useful version
information) and which device was selected (if any at all).
Change-Id: I0fe793c756f8f4f1761fe120fc361df36e581903
Reviewed-on: https://gerrit.libreoffice.org/24270
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
libOpenCL.so is just the symbolic link to it, typically from
a development package. (On Fedora, from ocl-icd-devel.)
(Sure, libOpenCL.so.1 is also a symbolic link on Fedora, to
libOpenCL.so.1.0.0. But anyway, libOpenCL.so.1 is not from a
development package, but from ocl-icd.)
Change-Id: I18ca2e52e025001f709b1b57e12cd01d5b52d08e
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
We use only one OpenCL device per context or program, so get rid of
half-implemented (or half-reverted?) "support" for multiple devices per
context.
Change-Id: I951f29e867e5b3f96f6e051567ee38d607bd7ecf
Will make it less demanding on low-end hardware, where the device
driver is unresponsive for too long when an OpenCL kernel handling lots
of data is executing. This makes Windows restart the driver which is
problematic.
I tried several approaches of splitting, both at higher levels in sc
and at the lowest level just before creating and executing the OpenCL
kernel(s). This seems to be the most minimal and local approach. Doing
it at the lower level would have required too much poking into our
obscure OpenCL code, like passing an offset parameter to every kernel.
Use a simple heuristic to find out whether to split. On the
problematic low-end devices, CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT is
4, while for more performant devices it is 1 or 8.
Noel Grandin