Phoronix recently reported that the Vallium cpu implementation of
vulkan was already able to render Talos Principle. If work on it keeps
on at that pace, by Oct when Jacob is free again it will be much
Given this, it would make sense to consider moving to it over Kazan, or
at least checking the possibility.
"While there has been the CPU-based "Kazan" Vulkan driver (formerly Vulkan-CPU as a Google Summer of Code project) and Google's SwiftShader has been implementing CPU-based Vulkan support, it turns out Red Hat's David Airlie has been working on a Mesa/Gallium3D-inspired Vulkan software renderer..."
this is the same david airlie who screwed luc verhaegen over, disrupting
years of careful negotiations to get access to AMDGPU documentation.
in addition, LLVMpipe, as i understand it from the previous conversations
with jacob, is single-threaded.
I understand the issues with Airlie's work, but if (assumed) Vallium is relatively complete by Oct, can we afford not to use it? Getting Kazan to the same point would take months and EUR.
llvmpipe is only single-threaded in some parts, its normal GL rendering does benefit from more cores. See Phoronix tests of it where it does scale to big amounts of cores.
(In reply to cand from comment #2)
> I understand the issues with Airlie's work, but if (assumed) Vallium is
> relatively complete by Oct, can we afford not to use it?
it will need significant evaluation. the usual mistake is to optimise
vector intrinsics out early in the SPIR-V passes.
this is one of the reasons why we cannot start from SwiftShader because
the *fundamental* assumption is that it is going to be software-only
therefore why bother sustaining vectors, subvectors, predication and
swizzle through to the final IR pass?
> Getting Kazan to
> the same point would take months and EUR.
there's a fundamental reason for that: jacob is doing a proper shader
compiler and is taking into consideration the vector and predication
intrinsics right from the start.
if those have not been sustained right the way through from the SPIR-V
through to when they go actually into the LLVM IR conversion phase to
assembler, they have to be *REINTRODUCED* using a massive complex costly
and timeconsuming "auto-vectorisation" phase.
> llvmpipe is only single-threaded in some parts,
jacob explained last year - we'll have to wait until U.S. timezone for
confirmation - these "some parts" are what killed gallium3 performance
and would also severely hamper performance for us.
bottom line is: it's extremely unlikely to be suitable.
Vallium also might replace the new Mesa driver -- Kazan is not the only one we should think about
my understanding of that one was that it uses llvmpipe, which i recall
you said a couple years ago was single-threaded (single-process?) and
therefore a major performance bottleneck.
it's also developed by david airlied, who has caused enormous problems
for 3D software libre development, and has not come forward to explain his
(In reply to Luke Kenneth Casson Leighton from comment #5)
> my understanding of that one was that it uses llvmpipe, which i recall
> you said a couple years ago was single-threaded (single-process?) and
> therefore a major performance bottleneck.
some critical parts of it were single threaded last I checked
Just mentioning that Vallium should be considered just as much for replacing the new Mesa driver as for replacing Kazan, especially since Vallium is part of Mesa anyway (though maybe not upstreamed -- didn't check).
I'm probably not going to give my opinion as to if we should use Vallium instead of Kazan since it's probably somewhat obvious that I am partially biased towards Kazan since it is kinda my pet project.
Vallium is now renamed to Lavapipe and merged to mesa master. It will be a part of the next release, 20.3. It currently passes 99% of the Vulkan conformance test suite.
Mesa 20.3 is now out, which includes Lavapipe.