[Mesa-dev] Plan for merging v3dv in mesa
Jason Ekstrand
jason at jlekstrand.net
Thu Sep 17 17:13:21 UTC 2020
One more comment: Could you make a big WIP MR with the whole driver
to act as a pointer to the branch for now? Then it can be the thing
that gets merged once the stuff in a and b land.
--Jason
On Thu, Sep 17, 2020 at 12:10 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> Good work, all! I'm super-happy to see another Vulkan driver land in Mesa.
>
> On Thu, Sep 17, 2020 at 8:52 AM apinheiro <apinheiro at igalia.com> wrote:
> > 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.
>
> I think that's fine.
>
> > 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.
>
> An ACK from Eric or someone other v3d devs would be good. Not my
> area, though, so I'll let others talk.
>
> > 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.
>
> I'd definitely like to see the patches in a) get real review. I don't
> know how many MRs you want to make there; do what makes sense.
>
> > Does all this sound sensible?
>
> Yup.
>
> --Jason
More information about the mesa-dev
mailing list