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)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
