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?
> 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.