[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Evaluation of DPC++ compiler for Krita to support GPU computations
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2023-01-05 13:54:27
Message-ID: CAEkBSfUQkQWox3o=ur7wf7gm68z3e+YU66jpW_J-T40jcGUdZA () mail ! gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">Hi, Amyspark!<div><br></div></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">SPIR-V is (if I recall \
correctly) Vulkan, which will require the user to<br> use a somewhat updated GPU \
driver. Can you confirm if this is the case,<br> and if not, whether DPC++ will \
supply the relevant library?<br></blockquote><div><br></div><div>SPIR-V is not \
strictly Vulkan, it is something lower-level. <br><br></div><div>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?).</div><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 2) There \
is also a library called oneAPI. It is built on the top of that<br> > DPC++ \
compiler. We can use it to optimize the Gaussian Blur and other<br> > filters, but \
I don't think we can use it for brushes and composition.<br> <br>
Have you researched this in depth? I've not heard of a profiling of our<br>
filters, so I lack the knowledge to ascertain where our current<br>
bottlenecks are in that alley.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 4) As far as I \
can tell, DPC++ is supported only on Linux and Windows.<br> > I'm not sure we \
can use it on Android or MacOS.<br> <br>
I think we should address the elephant in the room: is this API x86 only<br>
or does it support Arm users out there as \
well?<br></blockquote><div><br></div><div>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?) (<a \
href="https://github.com/intel/llvm/pull/2333">https://github.com/intel/llvm/pull/2333</a>). \
There is also an alternative implementation by Codeplay (afair, bought by Intel) that \
officially supports it (<a \
href="https://developer.codeplay.com/products/computecpp/ce/home">https://developer.codeplay.com/products/computecpp/ce/home</a>)</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex">> 5) Not only will we have to switch to \
an unstable branch of Clang, we<br> > will also have to build the compiler \
ourselves (at least on Windows).<br> > Official builds support only MSVC, but we \
need a MinGW environment.<br> > <br>
<br>
FTR, we use MinGW due to the performance optimizations; remember I use<br>
MSVC as a daily Krita driver so it's not strictly \
needed.<br></blockquote><div><br></div><div>Well, I'm not sure that we will be \
able to deprecate our XSIMD optimizations with that.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
> 6) I have managed to compile and run this compiler with MinGW, but this<br>
> process is extremely manual and flanky right now. More work will have to<br>
> be done for that. Most probably, we will have to do cross-compilation<br>
> from Linux, actually :)<br>
<br>
Could you elaborate on this? Does it rely on shell scripts or (woe<br>
betide us) the Linux process forking model for speed, Ã la building \
LLVM?<br></blockquote><div><br></div><div>MinGW building scripts use autoconf and \
automake, so MinGW cannot be built natively on Windows. </div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex">Qt 6 *still* hasn't returned ANGLE, so \
such an upgrade would still<br> involve writing at the very least three such copies \
(OpenGL, DirectX,<br> OpenGL ES) to maintain HDR \
support.<br></blockquote><div><br></div><div>I don't think will will write three \
implementations. We will just readd ANGLE back into Qt6.</div><div> \
</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Dmitry \
Kazakov</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic