Evaluation of DPC++ compiler for Krita to support GPU computations

[Dmitry Kazakov]

Hi, Amyspark!

SPIR-V is (if I recall correctly) Vulkan, which will require the user to
> use a somewhat updated GPU driver. Can you confirm if this is the case,
> and if not, whether DPC++ will supply the relevant library?
>

SPIR-V is not strictly Vulkan, it is something lower-level.

As far as I can tell, the driver should support either CUDA or openCL or
AMD HIP or Intel Level Zero API and the SPIR-V representation will be
passed to it (with recompilation?).


> > 2) There is also a library called oneAPI. It is built on the top of that
> > DPC++ compiler. We can use it to optimize the Gaussian Blur and other
> > filters, but I don't think we can use it for brushes and composition.
>
> Have you researched this in depth? I've not heard of a profiling of our
> filters, so I lack the knowledge to ascertain where our current
> bottlenecks are in that alley.
>

Well, we use FFTW transformation with AVX optimizations, so it is hard to
optimize further. I'm not sure we should really spend time on optimizing
them (since they work quite well with Instant Preview). But there was a MR
recently that proposed the usage of Gaussian Blur for the colorsmudge
brush. That could be an interesting usecase.


> > 4) As far as I can tell, DPC++ is supported only on Linux and Windows.
> > I'm not sure we can use it on Android or MacOS.
>
> I think we should address the elephant in the room: is this API x86 only
> or does it support Arm users out there as well?
>

I'm not sure. Theoretically, SYCL itself should be available on ARM. There
is a MR saying that it can build and run something on ARM (on CPU?) (
https://github.com/intel/llvm/pull/2333). There is also an alternative
implementation by Codeplay (afair, bought by Intel) that officially
supports it (https://developer.codeplay.com/products/computecpp/ce/home)


> > 5) Not only will we have to switch to an unstable branch of Clang, we
> > will also have to build the compiler ourselves (at least on Windows).
> > Official builds support only MSVC, but we need a MinGW environment.
> >
>
> FTR, we use MinGW due to the performance optimizations; remember I use
> MSVC as a daily Krita driver so it's not strictly needed.
>

Well, I'm not sure that we will be able to deprecate our
XSIMD optimizations with that.


>
> > 6) I have managed to compile and run this compiler with MinGW, but this
> > process is extremely manual and flanky right now. More work will have to
> > be done for that. Most probably, we will have to do cross-compilation
> > from Linux, actually :)
>
> Could you elaborate on this? Does it rely on shell scripts or (woe
> betide us) the Linux process forking model for speed, à la building LLVM?
>

MinGW building scripts use autoconf and automake, so MinGW cannot be built
natively on Windows.


> Qt 6 *still* hasn't returned ANGLE, so such an upgrade would still
> involve writing at the very least three such copies (OpenGL, DirectX,
> OpenGL ES) to maintain HDR support.
>

I don't think will will write three implementations. We will just readd
ANGLE back into  Qt6.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230105/630a2ce4/attachment.htm>