Bug 386 - Evaluate Lavapipe (nee Vallium) instead of Kazan or new Mesa driver
Summary: Evaluate Lavapipe (nee Vallium) instead of Kazan or new Mesa driver
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 54 140
  Show dependency treegraph
 
Reported: 2020-06-16 07:22 BST by cand
Modified: 2020-12-04 07:59 GMT (History)
2 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cand 2020-06-16 07:22:04 BST
http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008007.html

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
further ahead.

Given this, it would make sense to consider moving to it over Kazan, or
at least checking the possibility.
Comment 1 Luke Kenneth Casson Leighton 2020-06-16 11:49:37 BST
"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..."

oh dear.

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.
Comment 2 cand 2020-06-16 11:54:43 BST
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.
Comment 3 Luke Kenneth Casson Leighton 2020-06-16 12:25:47 BST
(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.
Comment 4 Jacob Lifshay 2020-06-26 18:42:24 BST
Vallium also might replace the new Mesa driver -- Kazan is not the only one we should think about
Comment 5 Luke Kenneth Casson Leighton 2020-06-26 18:57:35 BST
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.

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Vallium-Soft-Vulkan

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
actions.
Comment 6 Jacob Lifshay 2020-06-26 19:35:21 BST
(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.
Comment 7 cand 2020-11-11 18:23:16 GMT
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.3-RC1-Released

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.
Comment 8 cand 2020-12-04 07:59:39 GMT
Mesa 20.3 is now out, which includes Lavapipe.