[Mesa-dev] Plan for merging v3dv in mesa

[apinheiro]

Hi everybody,

As some of you already know, we have been working on a Vulkan driver 
(v3dv) for the Broadcom V3D GPU present in the Raspberry Pi 4. So far we 
have beenworking on a personal branch, rebasing regularly, and we would 
like to start discussing about the process to merge the driver in Mesa.

First, here is some data about the current state of the driver:

Currently, we are targeting Vulkan 1.0 as our first milestone. At the 
moment, our Vulkan CTS results look like this:
[701251/701251] Pass: 106776 Fail: 18 Skip: 594454 ExpectedFail: 0 
UnexpectedPass: 0 Crash: 0 Timeout: 1 Missing: 0 Flake: 2

So we we are hoping to be able to submit the driver for conformance soon.

We have not done much testing beyond CTS yet, however, we know that we 
can run all Vulkan ports of the Quake 1-3 classics as well as OpenArena 
and we also know that there is a PSP simulator that uses Vulkan that 
some people have used to run some games on the Rpi4 as well. We can also 
run many of the Sascha Willem's demos.

So all in all, it seems that the driver can be useful already to people 
who want to start playing around with Vulkan on the Rpi4, and we would 
also like to start seeing more people doing exactly that so we can get 
feedback to continue polishing and improving the driver for real world 
usage.

As for our proposal to merge the driver, following are our initial 
thoughts. We would like to know if this sounds reasonable before we 
start making preparations.

Our development branch is ~525 patches on top of master, categorized as 
follows:
    a) Patches that touch common Mesa infrastructure (NIR, Vulkan WSI, 
Meson, etc): ~5 patches.
    b) Patches that touch common Broadcom infrastructure under 
src/broadcom (V3D backend compiler mostly): ~20 patches
    c) Patches that are independent and specific to the V3D Vulkan 
driver (under src/broadcom/vulkan): ~500 patches.

Since we are talking about a very large amount of patches, we are 
expecting that we can merge most of them without a review, particularly 
those in c) that implement the bulk of the Vulkan driver.

The patches in b) are mostly about extending our compiler backend to 
support Vulkan intrinsics and requirements as well a a few more general 
fixes or improvements. Our plan is to at least have someone in our team 
review them internally and grant Rbs, I think the only other person who 
might want to review these would be Eric if he has the time and is 
interested in doing so. We have sent some of these for early review 
[1][2] when we found they were more generic fixes or improvements to the 
compiler, but we might not want to do this for each and every one of 
them unless we see there is interest in reviewing them separately.

For the patches in a) we would like to at least get an Ack from other 
Mesa devs. They are mostly very simple things that just add an option to 
a NIR pass or a new intrinsic for use in our driver backend, so maybe it 
is not needed to create dedicated MRs and it is fine to just ping 
specific Mesa devs for reviews on those patches when we propose the 
large MR for the bulk of the driver. We did send one of these as an RFC 
some time ago [3] and it would be nice to get some more feedback there 
if possible.

Does all this sound sensible?

BR

[1] "v3d/compiler: allow to batch spills" (MR#6632)
[2] "broadcom/compiler: Allow spills of temporaries from TMU reads" 
(MR#6606)
[3] "[RFC] vulkan/wsi: allow non-PCI devices to avoid the prime blit 
path" (MR#5917)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200917/37033fab/attachment.htm>